SAFe — это Agile-подход, который помогает крупным компаниям синхронизировать работу множества команд, связать стратегию с ежедневными задачами и выстроить общее планирование по единым циклам. Обычно внедрение такого фреймворка ассоциируется с Jira и специализированными плагинами, однако в этом кейсе компания пошла другим путем.
Команда самостоятельно реализовала SAFe в Kaiten, без внешних подрядчиков и сложных интеграций. За полтора года это решение дало заметный результат: показатель Plan-to-Fact вырос с 35% до 75%.
Компания поделилась этим опытом анонимно.
С чего началась трансформация
Компания разрабатывает и выпускает собственное IT-оборудование, а также ведет внутренние цифровые продукты. В их числе — инфраструктурные и безопасностные решения, личные кабинеты, учетные системы и другие сервисы для внутренних заказчиков. Общая численность сотрудников — около 7000 человек.
Во внутренних проектах уже использовали продуктовый подход. Он помогал быстро реагировать на запросы бизнеса и сохранять высокую скорость поставки. Пока команды оставались компактными, работа строилась короткими итерациями, а горизонт планирования обычно не превышал двух недель.
В 2023 году стало очевидно, что дальнейший рост требует новой системы управления. Компании было важно не просто расширять разработку, а делать ее более предсказуемой, устойчивой и согласованной. Именно поэтому продуктовый подход усилили практиками SAFe.
Сейчас внутренними продуктами занимаются около 500 сотрудников. Из них примерно 200 человек работают непосредственно в Kaiten. Дополнительно в систему вовлечены 50–70 ключевых заказчиков и стейкхолдеров, которые инициируют IT-изменения и участвуют в планировании.
Почему прежний подход перестал работать
Часть подразделений, отвечающих за внешние продукты, продолжала работать в Jira. Этот вариант рассматривали и для внутренних инициатив, однако под задачи SAFe он оказался неудобным. Интерфейс воспринимался перегруженным, а изменение структуры требовало слишком много времени и усилий. Быстро адаптировать систему под живые процессы не получалось.
Рассматривали и Miro, но этот инструмент не подходил для полноценной операционной работы. Артефакты там оставались скорее визуальными объектами, чем рабочими сущностями, а значит, поддерживать их в актуальном состоянии пришлось бы вручную.
Дополнительные сложности создавала сама организация процессов:
- не было единого PI Board для общего квартального планирования;
- изменения в рабочих схемах проходили слишком долго из-за внутренних SLA;
- версии файлов конфликтовали между собой;
- часть типовых проблем в Jira можно было решить через SAFe-плагины, но на старте это выходило слишком дорого.
Команде нужна была система, которая соответствовала бы нескольким критериям:
- позволяет быстро настраивать доски и структуру;
- не требует тяжелого администрирования;
- дает возможность легко вносить изменения;
- остается в рамках бюджета, поскольку трансформацию запускали собственными силами.
Сначала попробовали описывать Features и User Stories в Excel. На раннем этапе это работало, но по мере роста числа участников формат таблиц стал неудобным для восприятия, обсуждения и поддержки.
В итоге выбор остановили на Kaiten по трем причинам:
- гибкая настройка — канбан можно было использовать не только как доску статусов, но и как инструмент планирования по периодам;
- интерактивность — карточки и элементы были рабочими объектами, а не просто визуальными блоками;
- простота — структуру и правила можно было менять быстро, без длительных согласований.
Как проходил переход на Kaiten
Полный переход занял около полутора лет — от первых попыток внедрить SAFe до почти полного отказа от Jira в качестве основного инструмента.
Октябрь 2023
Стартовали с Excel. Практически сразу стало ясно, что таблицы плохо подходят для работы с SAFe-артефактами: их сложно читать, обсуждать и использовать в масштабном планировании.
Ноябрь 2023
Команда перешла в Kaiten. Сначала протестировали пилотный сценарий, затем развернули полноценную On-Premise-версию. Параллельно начали собирать бэклоги и проектировать доски для ближайшего квартального планирования. За 2–3 месяца удалось самостоятельно перенести процессы и выстроить базовую архитектуру. Внутри системы появились отдельные типы сущностей, включая Features и User Stories.
Февраль 2024
Провели первое PI-планирование в Kaiten. В нем участвовало около 200 человек.
Лето 2024
Началась основная волна миграции. Более 20 команд перешли на постоянную работу в Kaiten. В Jira остались только 5–6 команд.
Январь 2025
Появилась портфельная доска с Timeline и BI-дашбордами, где стали вести Epic на более зрелом уровне.
Переезд воспринимался неоднозначно. Многие сотрудники не видели смысла менять привычный инструмент, если Jira уже использовалась в компании. Сопротивление удалось снять через обучение: подключили Scrum-мастеров, подготовили инструкции по постановке задач и работе с карточками. После того как команды увидели преимущества на практике, новый подход закрепился. За год Kaiten стал основным рабочим пространством почти для всех команд.
Как SAFe разложили в Kaiten
В основе SAFe лежит понятная иерархия артефактов:
- OKR — стратегические цели и измеримые результаты;
- Epic — крупные инициативы, влияющие на стратегию и затрагивающие несколько команд;
- Features — продуктовые или пользовательские функции в рамках Epic;
- User Stories — конкретные сценарии и требования, из которых складывается реализация 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. Например, один из 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 также просматривают через диаграмму Ганта. Это помогает разложить инициативы по периодам, увидеть сроки реализации, оценить потребность в ресурсах на разных этапах и понять, какой процент выполнения уже достигнут.
Бизнесовые и технические карточки выделяют разными цветами, чтобы быстро отслеживать баланс между задачами разного типа.
Каких результатов удалось добиться за 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-аналитику, чтобы сотрудники могли получать нужные данные без дополнительных согласований.
Вывод
Этот кейс показывает, что внедрение SAFe не обязательно требует дорогих экосистем, сложных интеграций и участия внешних консультантов. При грамотной архитектуре процессов и гибком инструменте компания может самостоятельно выстроить масштабируемую систему управления разработкой.
Kaiten в этом случае стал не просто заменой привычным инструментам, а основой для серьезной организационной трансформации. Благодаря этому компания смогла кратно увеличить масштаб разработки, повысить предсказуемость поставки и сделать работу команд заметно более прозрачной и управляемой.
Смотрите также: