Кейс восстановлен по материалам выступления на FlowDays 22. Смотреть запись.
Сильный результат, который оказался хрупким
Несколько команд мобильного банка примерно вдвое сократили Lead Time. Появились регулярные обзоры поставки, ретроспективы и ограничения незавершённой работы. Команды умели пользоваться новыми инструментами, а метрики подтверждали эффект.
Я счёл изменение завершённым и ушёл в другой контур. После этого встречи стали проходить реже, договорённости начали нарушаться, очередь Service Desk снова выросла, а регресс у отдельных команд замедлился.
Провал был не в обучении. Команды знали, что делать. Провал был в конструкции ответственности: владельцем нового способа работы оставался лидер изменений.
Почему повторное обучение не помогло
Я вернулся с привычным набором действий: снова объяснял смысл, показывал инструменты и обучал ведущих. Были дашборды, бот для планирования регресса, инструкции по дежурствам и встречи с поддержкой.
Инфраструктура изменения была готова, но у команд не появилось собственной причины защищать его при конфликте приоритетов. Пока внешний человек напоминал о правилах, они соблюдались. После его ухода локальная оптимизация снова становилась рациональным выбором.
Для руководителя это неприятный, но полезный диагноз: внедрение практики ещё не меняет модель управления. Число обученных сотрудников и проведённых встреч не показывает, кто примет решение, когда скорость поставки столкнётся с выполнением квартального плана.
Где находилась настоящая точка управления
Перелом произошёл, когда CPO обозначил накопившийся Service Desk как недопустимый риск для продукта. После этого очередь примерно из ста обращений сократилась до трёх-четырёх.
Похожая динамика была с регрессом. Когда длительность релизного цикла стала частью управленческой повестки, команды сократили регресс примерно с 13–17 до 5–6 дней.
Инструменты при этом не изменились. Изменились источник приоритета и владелец последствия. Проблема получила связь с клиентским опытом, риском продукта и обязательством руководителя.
Новая модель изменений
После этого опыта я разделил три уровня ответственности.
Руководитель задаёт ставку
Он формулирует, какой бизнес-риск или возможность требуют изменения, какой результат важнее локальной загрузки и где проходит граница допустимого.
Лидер изменений проектирует эксперимент
Он помогает найти системную причину, предлагает способ вмешательства и определяет метрику проверки. Его задача — не добиться послушания процессу, а снизить риск управленческого решения.
Команда владеет рабочим способом
Команда адаптирует правила под контекст и получает полномочия их поддерживать. Если практика работает только при участии консультанта или Delivery Manager, передача ответственности не состоялась.
Вывод для C-level и фаундера
Трансформация становится хрупкой, когда её делегируют вниз как набор практик. Устойчивость появляется, когда одновременно существуют:
- проблема, важная на уровне бизнеса;
- руководитель, отвечающий за последствия бездействия;
- команда, способная менять способ работы;
- данные, по которым можно остановить или продолжить эксперимент;
- план выхода внешнего лидера из контура.
Поэтому первый вопрос к программе изменений должен звучать не «кого обучить», а какое решение руководители будут принимать иначе после изменения.
Ограничения кейса
Нельзя приписать весь эффект одному управленческому сигналу: команды уже знали инструменты и имели необходимые дашборды. Кейс показывает сочетание готовой способности и лидерского приоритета. Без первого сигнал превратился бы в давление, без второго способность оставалась бы невостребованной.