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

1. По моему мнению Jira и сформировавшаяся вокруг нее экосистема Atlassian (Confluence, Bitbucket) — лидер рынка по набору и качеству предоставляемого функционала.

2. Продукт очень гибкий и предоставляет из коробки все необходимые на текущий момент функции. Особенно мы прочувствовали на себе отсутствие готовых досок Kanban со swimlane и отчетов по метрикам, когда с Jira пришлось уйти — но об этом позже.

3. Минимальный порог вхождения для разработчиков, так как практически все они с Jira уже работали на предыдущих проектах.

4. Интуитивно понятный интерфейс — так как до этого именно с ним большинство и работало.

5. Большое комьюнити, которое помогает решать проблемы и неординарные задачи.

6. Большое количество расширений в виде плагинов.

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

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

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

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

1. Прежде всего, ориентировались на Российского вендора — на тот момент (март 2022) круг сузился до Yandex Tracker и Kaiten (наверняка, были какие-то еще, но мы остановились на тех, что были на слуху).

2. Далее смотрели набор предлагаемых функций:
   

   1. Минимально необходимый набор — это описание таких сущностей, как задачи, создание новых атрибутов и типов задач

   2. Задачи должны объединяться в проекты по командам или активностям

   3. Для группировки и работы с задачами нужны доски

3. Так же смотрели на интерфейс — он должен был быть интуитивно понятным, так как у нас уже сложились ожидания и паттерны работы с трекером за годы работы с Jira.

4. Автоматизация и интеграция — перевод статусов при релизе на стенд, комментарий в задаче при прохождении автотестов, нотификации в Телеграм при изменении статусов задач.

5. Встроенный язык запросов.

6. Стоимость.

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

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

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

1. Выполняется. Сервера и команда разработки находятся на территории РФ.

2. Весь перечень присутствует в инструменте. Да, некоторые вещи называются и выглядят по другому, но к этому можно быстро привыкнуть.

3. Инструментарий трекера (макросы, триггеры, автодействия) предоставляют большой потенциал для развития автоматизации поверх трекера и его интеграции с производственными процессами команды.

4. Как писал выше, к интерфейсу привыкли, а позже команда Yandex выкатила более современную версию.

5. Стоимость была более чем приемлемая в сравнении с аналогами.

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

1. Команда Yandex провела для нас несколько демонстраций продукта.

2. Дело было на старте проекта, так что мы руками перенесли только нужные задачи, заодно прочистили бэклог.

3. Настроили первые доски и начали пробовать интеграцию.

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

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

1. Язык запросов — он другой. Менее богатый, к нему нужно привыкать. Язык в значительно меньшей степени предоставляет возможности для работы с атрибутами связанных задач. Например, найти все задачи, с которыми связаны такие-то … у которых такие-то значения определенный полей.

2. Интерфейс — некоторые привыкают до сих пор.

3. Метрики и дашборды — они есть, но их мало и предоставляемого набора очень не хватает. В итоге реализовали свой ETL процесс, льем события из трекера в Clickhouse и с помощью DataLens строим свою аналитику. Затратно, но решаемо.

4. Оказалось, что «подключиться» к событиям трекера и куда-то их сливать можно только через API.

5. Вообще, часть функций предоставляется только через API, например, корректировка залогированного времени или редактирование описания полей — очень разработчикоориентированный инструмент, менеджеры иногда страдают.

6. Недооценили отсутствие плагина Структура и его аналогов в трекере, а также отсутствие магазина плагинов.

7. По личным ощущениям инструмент развивается медленно, хотя кажется, что внешняя ситуация способствует обратному.

8. С Yandex Tracker переехать куда-то еще не так просто, как с Jira (об этом напишу в конце статьи).

Бонусы

1. За счет интеграции через API и встроенной в сам Tracker автоматизации мы также перевели в Tracker некоторые процессы, не относящиеся к производству.

2. Сократили время реакции и скорость принятия решений по многим событиям, генерируемым в Tracker. 

3. При рассмотрении аналогов команда сейчас говорит, что не готова снова куда то переезжать и Tracker на новый инструмент не поменяет - возможно, для нас появился новый стандарт вместо Jira.

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

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

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

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