Практически в каждом проекте, в котором я участвовал, для трекинга задач или уже использовалась Jira, или мы быстренько выбирали ее и начинали работать. По сути, никакого выбора то и не происходило. И вот какое объяснение я этому нахожу:

По моему мнению Jira и сформировавшаяся вокруг нее экосистема Atlassian (Confluence, Bitbucket) — лидер рынка по набору и качеству функций.
Продукт очень гибкий и предоставляет из коробки все необходимые на текущий момент функции. Особенно мы прочувствовали на себе отсутствие готовых досок Kanban со swimlane и отчетов по метрикам, когда с Jira пришлось уйти — но об этом позже.
Минимальный порог вхождения для разработчиков, так как практически все они с Jira уже работали на предыдущих проектах.
Интуитивно понятный интерфейс — так как до этого именно с ним большинство и работало.
Большое комьюнити, которое помогает решать проблемы и неординарные задачи.
Большое количество расширений в виде плагинов.

Так произошло и с нами на текущем проекте — мы сделали «выбор», или Jira сама выбрала нас и довольные, что снова работаем с любимым инструментом пошли выполнять задачи. Получили самую последнюю версию (облачную), красивую, современную. Быстро ее настроили и адаптировали под себя, благо, было достаточно опыта с предыдущих проектов.

Но в какой то момент Jira запретила устанавливать новые плагины на территории РФ, а позже Confluence заблокировал доступ по некоторым аккаунтам. И тогда мы озадачились поиском альтернатив.

Параметры для сравнения: что мы искали

Как правильно выбирать трекер? Мы начали вести сравнительную таблицу и попытались определить, какие функции важны при выборе трекера.

Прежде всего, ориентировались на Российского вендора — на тот момент (март 2022) круг сузился до Yandex Tracker и Kaiten (наверняка, были какие-то еще, но мы остановились на тех, что были на слуху).
Далее смотрели набор предлагаемых функций:
1. Минимально необходимый набор — это описание таких сущностей, как задачи, создание новых атрибутов и типов задач
2. Задачи должны объединяться в проекты по командам или активностям
3. Для группировки и работы с задачами нужны доски
Так же смотрели на интерфейс — он должен был быть интуитивно понятным, так как у нас уже сложились ожидания и паттерны работы с трекером за годы работы с Jira.
Автоматизация и интеграция — перевод статусов при релизе на стенд, комментарий в задаче при прохождении автотестов, нотификации в Телеграм при изменении статусов задач.
Встроенный язык запросов.
Стоимость.

Yandex Tracker и Kaiten: делаем выбор

Рассмотрев аналоги Jira остановились на Yandex Tracker. Тогда Tracker выиграл по автоматизации, объему функций и готовности команды продукта идти на диалог. На тот момент мы уже использовали инфраструктуру Yandex Cloud и были знакомы с продуктами экосистемы Yandex.

Раскладывая Yandex Tracker по вышеописанным пунктам, мы получили такую картину:

Выполняется. Сервера и команда разработки находятся на территории РФ.
Весь перечень присутствует в инструменте. Да, некоторые вещи называются и выглядят по другому, но к этому можно быстро привыкнуть.
Инструментарий трекера (макросы, триггеры, автодействия) предоставляют большой потенциал для развития автоматизации поверх трекера и его интеграции с производственными процессами команды.
Как писал выше, к интерфейсу привыкли, а позже команда Yandex выкатила более современную версию.
Стоимость была более чем приемлемая в сравнении с аналогами.

Примерно за месяц мы переехали в новый трекер:

Команда Yandex провела для нас несколько демонстраций продукта.
Дело было на старте проекта, так что мы руками перенесли только нужные задачи, заодно прочистили бэклог.
Настроили первые доски и начали пробовать интеграцию.

В целом, ничего сложного.

С какими проблемами столкнулись в Yandex Tracker

Язык запросов — он другой. Менее богатый, к нему нужно привыкать. Язык в значительно меньшей степени предоставляет возможности для работы с атрибутами связанных задач. Например, найти все задачи, с которыми связаны такие-то … у которых такие-то значения определенный полей.
Интерфейс — некоторые привыкают до сих пор.
Метрики и дашборды — они есть, но их мало и предоставляемого набора очень не хватает. В итоге реализовали свой ETL процесс, льем события из трекера в Clickhouse и с помощью DataLens строим свою аналитику. Затратно, но решаемо.
Оказалось, что «подключиться» к событиям трекера и куда-то их сливать можно только через API.
Вообще, часть функций предоставляется только через API, например, корректировка залогированного времени или редактирование описания полей — очень разработчикоориентированный инструмент, менеджеры иногда страдают.
Недооценили отсутствие плагина Структура и его аналогов в трекере, а также отсутствие магазина плагинов.
По личным ощущениям инструмент развивается медленно, хотя кажется, что внешняя ситуация способствует обратному.
С Yandex Tracker переехать куда-то еще не так просто, как с Jira (об этом напишу в конце статьи).

Бонусы

За счет интеграции через API и встроенной в сам Tracker автоматизации мы также перевели в Tracker некоторые процессы, не относящиеся к производству.
Сократили время реакции и скорость принятия решений по многим событиям, генерируемым в Tracker.
При рассмотрении аналогов команда сейчас говорит, что не готова снова куда то переезжать и Tracker на новый инструмент не поменяет - возможно, для нас появился новый стандарт вместо Jira.

Почему уйти с Jira и так сложно, и так легко?

Сложно, потому что привыкли, потому что удобно и не знали ничего другого долгое время. Легко, потому что все ориентируются на лидера рынка (по моему мнению) и предоставляют возможность миграции с Jira на свои инструменты. С Confluence похожая история.

Но «незаменимых трекеров нет» и проект движется дальше. Мы продолжаем развиваться дальше и искать новые решения и подходы.

Поделитесь в комментариях своими историями переноса процессов из Jira: как это было у вас, какой путь прошли и скучаете ли по Jira до сих пор.

Выбор трекера для проекта: что вместо Jira? Наш опыт поиска и сравнений