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

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

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Практически в каждом проекте, в котором я участвовал, для трекинга задач или уже использовалась 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 до сих пор.

Источник: https://habr.com/ru/articles/747844/


Интересные статьи

Интересные статьи

Меня зовут Максим Кульгин, и моя компания clickfraud занимается защитой от скликивания контекстной рекламы в «Яндекс.Директ». Мы получили статус резидента Сколково в конце прошлого года, и я...
Привет, Хабр! Я Алексей Булахов, инженер по обеспечению качества в Tele2. Одним из самых нетривиальных вопросов, которым может задаться QA-инженер, который планирует тестировать функционал мобильного ...
Недавно я написал про p2p-экосистему, чем вызвал бурную и интересную реакцию в комментариях. Поэтому решил продолжить. В экосистеме есть возможность покупки-продажи товаров и услуг – при этом все тран...
К читателюАвтор статьи не обладает специализированными знаниями в классическом кризисном менеджменте, единственное что он уже отличает кризисное управление (управление в кризис) от антикризисного упра...
Несколько недель назад мне удалось успешно сдать сертификационный экзамен на статус PMP (Project Management Professional), и на самом деле в этом нет ничего особенного, кроме того, чт...