Из Jira в Kaiten: как в АльфаСтраховании поменяли инструменты и воркфлоу

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

Что было до переезда: сложности с оплатой

У нас в компании много продуктов: есть корпоративное страхование, медицинское, автомобильное и другие. Еще есть системы для агентов, внутренние медицинские кол‑центры — сфер очень много. За каждым продуктом закреплена одна или несколько команд продуктовой разработки, поэтому количество команд непостоянно: всего их от 30 до 35.

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

Jira ориентирована на облачную работу, чтобы клиенты переходили в облако. Мы же больше тяготели к on‑premise‑решению: мы обрабатываем большие объемы конфиденциальных данных и нам комфортнее и безопаснее работать на своих серверах.

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

Как выбирали трекер: сравнивали несколько сервисов

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

• давно присутствует на рынке;
• транслирует продуктовый подход к разработке;
• имеет четкий роадмап развития.

Механизм отчетов. Если при работе на досках вносить в карточки всю необходимую информацию, автоматически будут создаваться детальные и понятные отчеты.

Удобный интерфейс. В Kaiten можно кастомизировать типы карточек под себя, создать неограниченное количество различных шаблонов, а в Jira в этом плане ограниченная функциональность.

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

Возможность поставить on‑premise‑версию. По умолчанию Kaiten облачный, но есть и on‑premise‑вариант, который можно развернуть на собственном сервере. Для нас, как для страховой компании, это было крайне важно — никак не зависеть от разработчика и самостоятельно отвечать за сохранность данных.

Возможность мигрировать из Jira по кнопке. Есть автоматический импорт задач и данных из сервисов Atlassian.

Роадмап развития. Продукт давно на рынке, у инструмента есть поддержка и регулярные обновления.

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

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

Как проходил переезд: два месяца и три этапа

Сотрудников переводили в три волны.

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

Каждой команде была дана неделя на «переход в кайф» и адаптацию в Kaiten. У нас был администратор, который осуществлял миграцию: он занимался техническими моментами и следил, чтобы все прошло хорошо. Ему в помощь мы выделили группу поддержки. В нее вошли адепты Kaiten, понимающие, как инструмент работает, чем он удобен и почему хорош. На каждого адепта было примерно по пять продуктовых команд. Он помогал командам настроить инструмент под привычные задачи, обустроиться в новой среде.

При этом Jira осталась у нас в урезанном функционале. Мы не блокировали ее, но меняли модель доступа в проекте команды. Теперь можно только почитать информацию, но не корректировать данные. Jira осталась как архив.

Миграция в Kaiten прошла хорошо и без нареканий, сейчас у нас on‑premise‑версия на наших серверах.

Как работаем сейчас: упрощаем и расширяем

Переезд в Kaiten помог нам сделать небольшое ревью задач: мы проверили, как устроены процессы, нужно ли такое количество этапов или какую‑то работу можно сделать проще. В итоге процессы, которые были большими и громоздкими в Jira, мы смогли сделать удобнее в Kaiten: они распались на несколько досок с договоренностями и правилами.

Например, когда клиенты обращаются в поддержку через внешний Service desk, запросы автоматически попадают в карточки Kaiten, поэтому сотрудникам нет необходимости держать на контроле оба сервиса. Все, что нужно, попадает к ним напрямую и обратно. Это стало возможным благодаря интеграции, настроенной группой Kaiten Extension.

Мы готовы прикручивать дополнительные сервисы, которые добавят в наш Kaiten новые функции. Сейчас, например, мы делаем систему автоматического информирования о релизах.

Что особенно понравилось в Kaiten

Отдельно хочется отметить интересный скрытый фактор, на который мы раньше не обращали внимания, — это счастье людей.

В Kaiten много маленьких опций, плюшек, которые делают работу удобнее и приятнее. Например, система запоминает, какие поля вы редактировали в карточке, или, если вы блокируете карточку, подсказывает причины блокировки на базе предыдущих карточек, которые вы смотрели. И таких функций, которые не описаны, много. Они совсем небольшие, но сильно повышают удобство работы.

У нас нет негативных кейсов по работе с Kaiten, всем командам инструмент нравится. Мы видим удобный UX‑дизайн, стабильную работу сервиса, удобные фишки вроде функционала User‑Story.

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