Переезд из Jira в Kaiten: Опыт Х5 Group

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

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

Что стало толчком к изменениям?

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

Это решение разработчиков оставило нас перед двумя крупными проблемами:

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

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

Применение Jira в X5

Jira была основой для ряда критически важных корпоративных операций.

• Во-первых, этот инструмент служил для координации задач разработчиков ПО и обработки сервисных запросов в рамках наших систем. В Jira каждая задача обладала своим жизненным циклом, а карточки задач включали всю необходимую информацию для их выполнения, в том числе данные об ответственных.
• Второй значимый процесс, который контролировался через Jira, касался управления портфелем инициатив. Это процесс включал привлечение различных центров компетенций для реализации изменений в IT-структуре на всех этапах: от исследования инициативы до её анализа, оценки выполнения, последующей поддержки и завершения. Вся жизненная цепочка этих задач также документировалась в Jira.

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

В результате анализа всех процессов, управляемых через Jira, мы получили следующую картину:

Критерии выбора новой системы

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

Вот что мы искали в новой системе:

• Возможность размещения системы на корпоративных серверах, т.е. наличие on-premise версии;
• Достаточный уровень зрелости продукта, подтвержденный отзывами пользователей;
• Функциональные возможности, которых нам не хватало в Jira, например, блокировка задач;
• Соответствие высоким стандартам информационной безопасности и возможности интеграции с существующей IT-инфраструктурой;
• Разумная стоимость решения.

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

Старт пилотного проекта

Предварительные обсуждения и поиск оптимального решения заняли около двух месяцев. После этого мы запустили пилотный проект. Для участия в нём было выбрано около 15 команд из 250 возможных, которые наиболее подходили для тестирования новой системы в реальных условиях работы.

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

• Первоначально мы хотели проанализировать, насколько Kaiten подходит в качестве основной системы управления задачами на производстве.
• Задачи второго этапа пилота включали установку, конфигурацию и оценку совместимости системы с нашими IT-инфраструктурами.
• Также мы проводили функциональные и нагрузочные тесты системы.

Финальные корректировки перед внедрением

Завершив пилотный период, мы выявили, что для успешного полномасштабного внедрения Kaiten требуется ряд дополнительных улучшений.

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

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

Обучение персонала и начало миграции

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

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

Миграция и оптимизация процессов

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

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

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

В качестве примера, рассмотрим визуализацию процесса архитектуры решений:

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

Например, на картинке ниже видно, как выглядит декомпозиция инициативы и взаимодействие разных команд. Стрелки показывают связи между карточкой инициативы на доске «Входящие инициативы» и карточками на других досках, а текущий статус каждой задачи отображается в соответствующей колонке.

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

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

Какие изменения произошли в результате?

• Зоны ответственности стали понятнее, благодаря четкому разделению процессов.
• Работа всех направлений стала более прозрачной, благодаря наглядному отображению процессов и управлению блокировками.
• Иерархия взаимодействия между процессами теперь более систематизирована, за счет визуализации взаимосвязей.

Маршрутизация задач

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

Как это работает? При создании карточек для привлечения других компетенций, действуют специальные правила. Пользователь, заполняющий карточку, определяет, куда она должна быть перенаправлена для выполнения. Исходя из заданных параметров, дочерняя задача автоматически перемещается на соответствующую доску исполнителя, а взаимосвязи между карточками формируют структуру вложенности.

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

На изображении каждая доска представлена как маршрутизатор:

А так мы настраивали каждый маршрутизатор в автоматизациях:

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

Таким образом, если в поле «Получено согласование ДИБ» стоит отметка «нет», дальнейшее перемещение карточки запрещено.

Система отчётности

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

Учитывая, что в наших разработках задействовано около 7 500 человек, можно оценить значимость и объёмы собираемых данных и насколько важна автоматизация процессов отчётности.

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

Интеграции сторонних сервисов с Kaiten

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

Один из примеров — это автоматизация передачи заявок от второй линии поддержки к третьей

В X5 внедрена система MFSM, которая обеспечивает работу службы поддержки. В ней ведётся обработка обращений от пользователей информационных систем.

Служба поддержки структурирована по трем уровням:

• Колл-центр занимается первичной регистрацией обращений;
• Специалисты второй линии решают стандартные проблемы;
• Специалисты третьей линии занимаются решением сложных задач и устранением дефектов. Команды третьей линии обычно работают не в MFSM, а в Kaiten.

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

Второй пример интеграции: синхронизация справочников

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

Результаты внедрения Kaiten

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

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

Этот процесс постоянно сопровождался обсуждениями и корректировками, которые затрагивали все команды, самые крупные из которых насчитывают до 300 человек.

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

Успешные компании уже используют Kaiten Попробуйте полный набор функций на своем проекте бесплатно

Попробовать