Как выбрать российский аналог Jira: с чего начать, если не хочется потом переделывать Ч1

С 2022 года российские компании уходят с Atlassian Jira — кто-то вынужденно, кто-то планово. И в какой-то момент встаёт вопрос: на что переходить?

Вместо спокойного выбора новой системы вы получаете примерно такую картину: 500 проектов, по которым непонятно кто и как работает. И сразу: страх ошибиться с выбором, непонятный объём работы — и никто не торопится это брать на себя.

Мы прошли этот путь с несколькими клиентами и выработали подход, который даёт осознанный ответ на этот вопрос. В этой серии статей разберём его по шагам.

Почему нельзя просто сравнить системы по табличке

Клиенты часто просят: «Сравните Jira, EvaProject, Kaiten, Яндекс Трекер по галочкам».

Так можно, но толку немного. Посмотрите документацию — функционал у всех вроде есть, вроде даже похож на нужный. Но дьявол в деталях.

Вот почему сравнение в лоб не работает:

У каждой команды свои процессы. Одна таблица не опишет 500 проектов с разными воркфлоу.

Jira — это не только задачи. Там ещё плагины, интеграции, автоматизации, скрипты. Их нужно анализировать отдельно.

Руководству нужны конкретные отчёты. Нельзя потерять их при переезде.

Миграция может стоить столько же, сколько сама система, а то и больше. Это надо знать до выбора, а не после.

Поэтому наш подход начинается не со сравнения, а с аудита того, чем вы реально пользуетесь.

Предупреждаем сразу: процесс не будет ни простым, ни быстрым. Зато вы узнаете свою систему так, как не знали раньше (актуальная документация по вашей Jira — это примерно из области фантастики), и примете решение, которое потом не придётся переделывать. Плюс — это одновременно подготовка к миграции, что сэкономит силы, когда придёт время.

Аудит для выбора системы состоит из 6 этапов:

1. Технический анализ
2. Сбор требований бизнес-пользователей
3. Группировка и ранжирование требований
4. Проверка критичного функционала в системах-аналогах
5. Оценка миграции
6. Выбор системы

В одной статье всё не уместим — будет серия. Начнём с технического анализа.

Этап 1. Технический анализ: не гадаем, а проверяем

Цель этапа — получить объективные данные о том, что реально используется в системе, и оценить объём данных для последующей миграции.

Что смотрим:

• - Объёмы данных — сколько активных проектов, задач, пользователей
• - Плагины — какие используются, а какие просто установлены
• - Автоматизации и скрипты — что сломается при переезде
• - Интеграции — кто и как обращается к Jira через API

Объёмы данных

Мало кто знает, сколько актуальных объектов в системе. А это критично для выбора — некоторые аналоги Jira просто начинают тормозить или падать при большом количестве проектов, кастомных полей или воркфлоу.

Самый простой способ — пройтись по базе селектами. Что берём:

Проекты. Общее количество, разбивка на архивные и активные. Проекты, в которые никто не заходил больше 6 месяцев — они не в архиве, но реально не используются.

Issues. По статусам, по типам, количество в активных проектах.

Пользователи. Активные за последние 90/180 дней. Это покажет реальную потребность в лицензиях.

Вложения. Их объём важен для оценки времени и сложности переноса.

Кастомные поля

Здесь чуть подробнее, потому что это частая ловушка.

В Jira кастомных полей обычно пруд пруди. Где, кто и как их использует — непонятно. При этом в системах-аналогах может не оказаться типов полей, на которых держатся критические процессы.

Пример: в EvaProject нет поля типа VersionPicker. Для большинства компаний это не проблема. Но у некоторых клиентов на этом поле завязаны несколько ключевых процессов — и если выяснить это в середине миграции, придётся срочно придумывать воркараунды. Лучше знать заранее.

Что смотрим по кастомным полям:

• - Разбивка по типу
• - Заполненность (в скольких задачах поле реально заполнено)
• - Активность использования (бывает, что полгода назад активно заполняли, а сейчас нет — потому что процессы изменились)

Бизнес-процессы (воркфлоу)

Смотрим общее количество и количество статусов — это влияет на объём ручной настройки в новой системе.

Отдельно обратите внимание на встроенные автоматизации на переходах: системные валидаторы, кондишены, пост-функции. Их делают не плагины, а сама Jira. В системы-аналоги они практически никогда не переезжают автоматически — их нужно переписывать вручную. Это тоже надо учитывать в оценке трудозатрат.

Дашборды и фильтры

Просто считаем, сколько их есть. Эти сущности практически нигде не мигрируют — всё настраивается с нуля. Поэтому важнее будет разобраться с пользователями: что именно они смотрят на дашбордах и зачем, чтобы воспроизвести это в новой системе.

По результатам этого этапа у вас будет:

• - Таблица с реальными объёмами данных системы
• - Понимание, какие данные переносить, а что можно оставить в архиве
• - Требования к типам полей
• - Реальное количество лицензий
• - Список системных автоматизаций, которые нужно переписать

Дальше — плагины, скрипты и интеграции. Разберём в следующей статье.

---

Хотите чек-лист для самостоятельного аудита? Напишите слово «чеклист» на support@teamlead.ru — пришлём. Не хотите разбираться самостоятельно — мы можем провести анализ и помочь с выбором системы. Напишите нам.

Это первая статья из серии «Переезд с Jira». Чтобы не пропустить следующие — следите за серией в нашем блоге.