Как компания внедрила SAFe в Kaiten и масштабировала разработку в 5 раз
Сложные фреймворки в разработке можно внедрять не только в Jira. Делимся историей инженерной компании, которая реализовала SAFe в Kaiten собственными силами.
SAFe — Agile-фреймворк, который помогает компаниям синхронизировать десятки команд: связать стратегические цели с задачами и планировать работу общими циклами. Быстро внедрить SAFe обычно не получается, помогают только Jira и специальные плагины. Но в этой истории путь получился другим: компания реализовала SAFe в Kaiten своими силами, без внешних интеграторов, и уже через 1,5 года получила измеримый эффект — Plan-to-Fact вырос с 35% до 75%.
С чего все началось
Компания разрабатывает и производит собственное IT-оборудование и параллельно развивает внутренние продукты: занимается инфраструктурой и безопасностью, создает цифровые сервисы — например, личный кабинет и учетные системы. Всего — около 7000 сотрудников.
Во внутренних проектах используют продуктовый подход: он помогает быстро подстраиваться под новые запросы заказчиков и сохранять темп. Пока команды были небольшими, работа шла короткими циклами — задачи планировали максимум на две недели.
В 2023 году стало понятно, что пора масштабироваться. Целью был не только рост, но и управляемость: повысить предсказуемость, надежность и наладить взаимодействие между командами. Поэтому к продуктовому подходу добавили SAFe.
Сейчас внутренними продуктами занимаются около 500 человек. Примерно 200 из них работают в Kaiten. Еще 50–70 ключевых заказчиков-стейкхолдеров, которые запускают IT-инициативы, тоже используют таск-трекер.
Почему как прежде уже не могло быть
Часть подразделений, которые развивают внешние продукты, ведут работу в Jira. В компании тоже рассматривали этот вариант, но для SAFe он оказался неудобным: интерфейс перегружен, а любые изменения в структуре занимают слишком много времени. Настроить систему под живые процессы не получилось.
Смотрели и в сторону Miro — но там элементы больше похожи на статичные стикеры. Значит, артефакты SAFe пришлось бы поддерживать вручную и постоянно синхронизировать изменения.
К этому добавлялись организационные ограничения: не было единого PI-борда (Planning Interval-борд), изменения в схемах проходили через долгие SLA, а версии файлов конфликтовали между собой. Для Jira существуют SAFe-плагины, которые разом закрывают часть этих проблем, но на старте для компании это оказалось слишком дорого..
Команде важно было найти систему, которая:
- умеет быстро настраивать доски и структуру;
- не имеет сложных настроек администрирования;
- позволяет легко вносить изменения;
- не выходит за рамки бюджета — трансформацию запускали своими силами.
Первую попытку сделали в Excel: описали Features и User Stories при помощи таблиц. Но когда число пользователей увеличилось, поддерживать этот формат стало сложно.
В итоге выбрали Kaiten — по 3 причинам:
- Гибкая настройка. Канбан использовали не только как доску со статусами, но и как визуализацию по периодам.
- Интерактивность. Элементы — не просто картинка: с ними можно работать и настраивать систему под себя.
- Простота использования. Структуру и правила можно менять быстро, без долгих согласований.
Переход занял 1,5 года: от старта SAFe до почти полного отказа от Jira
Октябрь 2023. Стартовали с Excel. Очень быстро стало ясно, что таблицы не подходят: в таком виде Features и остальные артефакты тяжело воспринимать и обсуждать.
Ноябрь 2023. Перешли в Kaiten. Сначала попробовали пилот, затем развернули полноценную On-Premise версию. Параллельно начали собирать бэклоги и доски под ближайшее квартальное планирование. За 2–3 месяца сами перенесли все процессы и выстроили базовую структуру. Внутри завели отдельные типы сущностей, включая Features и User Stories.
Февраль 2024. Провели первое PI-планирование: около 200 участников, все через доски в Kaiten.
Лето 2024. Началась основная волна переезда. Более 20 команд стали использовать Kaiten на постоянной основе. В Jira остались 5–6 команд.
Январь 2025. Появилась портфельная доска с Timeline и BI-дашбордами, где размещен Epic.
Не всем сразу понравилась идея с переездом. Многим сотрудникам казалось, что менять систему бессмысленно, ведь Jira и так работает. Помогло обучение: подключали Scrum-мастеров, делали инструкции по постановке задач и работе с карточками. Когда сотрудники увидели преимущества на практике, сопротивление ушло. В итоге за год почти все команды закрепились в Kaiten, а Jira перестала быть основным инструментом.
Разложили SAFe в Kaiten на 5 уровней досок
В SAFe есть понятная вертикаль артефактов:
- OKR (Objectives and Key Results) — стратегические цели и измеримые результаты;
- Epic — крупные инициативы, которые двигают стратегию вперед и требуют участия нескольких команд;
- Features — пользовательские или продуктовые функции, которые нужно реализовать в рамках Epic;
- User Story — конкретные сценарии и требования, из которых складывается реализация Feature.
Компания перенесла эту логику в Kaiten так, чтобы у каждого уровня был свой бэклог и свой центр управления. В итоге получилось пять отдельных пространств.
Уровень 1. ART
Общая доска для всех команд: сюда стекаются идеи и карточки — добавили единый Upstream и Downstream. При этом механика намеренно нестандартная: столбцы показывают периоды, а строки — команды. При планировании задач на квартал карточка попадает на эту доску.
Уровень 2. Strategy
Здесь находятся OKR из Jira.
Уровень 3. Portfolio (дорожная карта)
Канбан-доска для инициатив: здесь переводим стратегию в Epic и согласовываем с руководством.
Для Epic создали поэтапный Upstream: ревью идей → анализ → подготовка к постановке в очередь.
А также Downstream (реализация идей → продолжение → развитие MVP). Если инициативу останавливаем — она уходит в столбец «Отменен». Если доводим до результата — в «Завершен».
Уровень 4. PI-Board (квартальное планирование)
Здесь собрали группы из 5–12 команд — примерно по 100–150 разработчиков. Каждую такую группу назвали Train. Например, Agile Release Train HR Tech занимается внутренними сервисами для сотрудников.
У каждой команды есть свой слой бэклога с карточками Features. На канбан-доске они проходят три стадии: идея → анализ → подготовка к приоритизации. Здесь же фиксируют цели и риски на квартал.
Уровень 5. Командный канбан
Классическая рабочая доска. На этом уровне Features разбиваются на User Stories, и дальше работа идет по потоку — от идеи до реализации по этапам процесса.
Epic, Feature и User Story разделили на два подтипа — бизнесовые и вспомогательно-технические. Для каждого подтипа настроили свой набор полей.
Примеры наполнения:
- User Story: описание и оценка в Story Points.
- Feature: описание функциональности, расчет приоритета по WSJF, риски, критерии приемки, метрики для проверки гипотезы и оценка в Story Points.
- Epic: гипотеза и финансовые показатели.
Уровни связаны иерархически: User Stories входят в состав Features, а Features объединяются в Epic, поэтому всю цепочку можно проследить в одном месте.
Карточки Feature ведутся сразу на двух досках. Первая — обычная канбан-доска, где команда двигает их по этапам. Вторая — статичный PI Board: он показывает период, а статус меняется через поле. Такой PI Board живет один квартал, а после окончания периода уходит в архив.
Features и Epic дополнительно просматриваются на диаграмме Ганта. Команда использует ее, чтобы разложить работы по периодам. Так видно, когда будет реализован конкретный Epic, сколько ресурсов понадобится на разных этапах и какой процент выполнения уже накопился.
Итоги за 1,5 года
За первые 1,5 года работы по SAFe на базе Kaiten компания получила такие результаты:
- Plan-to-Fact вырос с 35% до 75%.
- Uptime поднялся с 75% до 99,95%.
- Число разработчиков увеличилось с 45 до 220.
Изначально трансформация задумывалась, чтобы масштабироваться и сделать работу более управляемой — и цель была достигнута. Именно Kaiten стал для команды основой изменений и помог наладить управление бэклогами.
Параллельно в 2024 году компания выстроила более зрелые инженерные процессы: запустила конвейеры сборки и начала прогонять десятки тысяч тестов каждую неделю перед релизом. В результате доступность продуктов выросла до 99,95% даже на фоне стремительного роста команд.
Что пока мешает
Есть и слабые места. В первую очередь — ручное дублирование Features и ограниченная автоматизация, из-за чего часть времени уходит на рутину. Со временем эти проблемные точки планируют закрыть.
Планы на будущее
В будущем компания планирует развивать несколько направлений. Во-первых, доработать правила работы с бэклогами и единые требования к описанию артефактов. Во-вторых, связать OKR с работой команд через метрики — чтобы по каждому OKR было видно, какие Epic и задачи его поддерживают, кто за них отвечает, в какие сроки они выполняются и с каким прогрессом. В-третьих, поставить flow-метрики на поток и регулярно считать Lead Time и Throughput на всех уровнях бэклогов, чтобы управлять потоком системно. И, наконец, запустить self-service аналитику — чтобы сотрудники получали нужные данные без дополнительных согласований.
