Delivery-трансформация 20+ продуктовых команд: срок 85% инициатив сократился на 64%

Этот кейс не про внедрение Kanban

В начале 2025 года delivery-контур во многом был непрозрачным. Команды работали в разных ритмах, кросс-командные зависимости отслеживались вручную, а цели часто представляли собой перечень работ. Метрики либо отсутствовали, либо оставались отчётностью, которая не влияла на решения.

Для бизнеса ИТ выглядело «чёрным ящиком». Было сложно ответить на три базовых вопроса: что происходит с инициативой сейчас, где находится ограничение и когда ждать результат.

Первая реакция на такую ситуацию почти всегда одинакова: внедрить больше правильных практик. Мы тоже начали с Kanban и delivery-ритуалов. Это дало общий словарь, но быстро обнаружило ограничение: ритуалы не создают ценность сами по себе. Если они не помогают решить реальную бизнес-проблему, команда учится выполнять процесс, а система остаётся прежней.

Разворот: от практик к проблемам бизнеса

В августе 2025 года мы изменили формулировку задачи. Вместо «внедрить процессы» появилась цель «сделать ИТ управляемым и полезным для бизнеса».

Это не косметическая смена слов. В центре оказались конкретные ограничения:

1. непрозрачность текущей работы команд;
2. неуправляемые зависимости;
3. отсутствие общей картины через метрики;
4. цели, подменённые объёмом работ;
5. длинные паузы между этапами и аналитика «в стол»;
6. высокая связанность систем, из-за которой изменение затрагивало соседние команды.

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

Общая единица потока

Чтобы обсуждать delivery на уровне бизнеса, понадобилась единица крупнее отдельной задачи.

RFC стал инициативой — запросом на изменение и единицей планирования потока ценности. Epic помогал видеть реализуемую часть инициативы. Для обеих сущностей начали измерять два времени:

• SLT, System Lead Time — от постановки инициативы в аналитику до завершения;
• LT, Lead Time — от момента, когда работа запланирована в todo, до завершения.

Мы отслеживали медиану и 85-й процентиль. Медиана описывает типичный случай, а p85 показывает срок завершения 85% инициатив и делает видимыми самые длинные истории.

Этап 1. Создать общий язык

В конце 2025 года появились пять опорных элементов системы.

Pulsar как единый слой данных

Pulsar собрал delivery-метрики в одном контуре. Команды перестали сверять разные версии отчётов и начали обсуждать причины задержек в потоке.

Унификация процессов

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

Цели вместо списка задач

Разговор постепенно сместился с «что мы собираемся сделать» на «какой результат хотим получить». Для 2026 года и первого квартала сформировали цели, которые можно связать с инициативами и проверить по факту.

Аудиты зрелости

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

Передача run-процессов

Операционное сопровождение начали возвращать Tech Leads и самим командам. Delivery Manager освобождался от роли диспетчера и получал пространство для системных изменений.

Этап 2. Использовать данные в управлении

В первом полугодии 2026 года базовую унификацию распространили на большинство digital-команд. Управленческий фокус сместился с набора задач на Epic и RFC как реальные единицы планирования и потока ценности.

Зависимости начали визуализировать системно, а ручное ведение схем в Miro заменили более устойчивым контуром в Structure. Параллельно появились регулярные отчёты на основе данных: статус инициатив, достижение целей, риски, дайджест для Tech Leads и отдельная панель для CTO и руководителей.

К delivery добавили экономический слой. Для RFC стали фиксировать примерную стоимость, ожидаемый результат и поле для фактического эффекта. Это ещё не полноценный P&L инициатив, но уже мост между скоростью выполнения и ценностью решения.

Что изменилось в цифрах

В сравнении с 2025 годом поток стал одновременно быстрее и производительнее:

• RFC SLT на уровне p85 сократился с 295 до 106 дней — на 64,1%;
• RFC LT p85 сократился с 223 до 78 дней — на 65%;
• медиана Epic SLT снизилась с 67 до 38 дней — на 43,3%;
• Epic SLT p85 снизился со 145 до 112 дней — на 22,8%;
• средний выпуск RFC вырос примерно с 4 до 6,7 в месяц;
• средний выпуск Epic вырос с 16 до 54 в месяц;
• выполнение плана Q2 достигло 77% при цели 80%.

Epic LT на уровне p85 немного вырос — с 98 до 101 дня. Этот показатель оставили в кейсе: метрики должны показывать следующее ограничение, даже когда оно портит общую картину результата.

Снижение p85 означает, что меньше инициатив «зависают» на неопределённый срок. Выросли и средняя скорость, и предсказуемость поставки.

Как изменилась роль Delivery Manager

В 2025 году DM в основном внедряли практики, потому что считали их правильными. К первому полугодию 2026 роль сместилась: DM начали принимать решения, опираясь на реальные бизнес-проблемы и поведение метрик.

Delivery Manager перестал быть исполнителем процесса и стал владельцем изменений в delivery-системе. Run-процессы постепенно переходят командам, а DM работает со следующим системным ограничением.

Следующее ограничение — левее по потоку

После улучшений внутри ИТ стало видно, что дальнейшее ускорение нельзя получить только настройкой разработки. Следующий участок работы находится до попадания инициативы в delivery:

1. сделать приоритизацию и ожидания от инициатив более прозрачными;
2. повысить качество расчёта ожидаемого результата до старта изменений;
3. улучшать процессы в бизнес-подразделениях, влияющие на общий Lead Time;
4. искать быстрые и дешёвые проверки до запуска крупных RFC;
5. передать Tech Leads владение устойчивостью командных процессов;
6. сместить фокус Delivery Managers с разработки на весь поток бизнес-функции.

Главный вывод: delivery-зрелость внутри ИТ необходима, но недостаточна. Ускорение потока ценности требует изменений в приоритизации, формировании RFC, работе с зависимостями и скорости принятия бизнес-решений.