Почему гибкие подходы не дают ожидаемой скорости. Серия 1. «Код замедления»
Всем привет. Мы решили попробовать нестандартный формат, чтобы поговорить о важных для нас и индустрии ИТ темах. Предлагаем вашему вниманию экспериментальный детектив. Все герои вымышлены, а ситуации собирательны. Не ищите точных совпадений :)

Представьте себе кино в жанре нуар. Начинаются вступительные титры, звучит мрачная мелодия. Мы видим мегаполис с высоты птичьего полёта, подлетаем к офисному небоскрёбу. На столах мигающие мониторы с диаграммами, графиками lead time и строками кода, силуэты людей за столами.
Прослеживается каргокульт Agile, а скорости и системы нет…
В тёмной комнате на стене висела доска с фотографиями, заметками и соединяющими их стрелками. Среди них — распечатки с метриками: Time‑to‑Market, Cycle Time, WIP, график с растущим бэклогом.
За столом сидел Марк Воронов — опытный аналитик с острым умом и привычкой замечать то, что ускользает от других. В его глазах была смесь усталости и азарта: он чувствовал, что за рутинными отчётами скрывается нечто большее. Листая один из них, он остановился и пробормотал:
— Time‑to‑Market… без изменений. Cycle Time растёт. WIP зашкаливает…
Воронов нахмурился.
— Потуги в сторону правильных гибких практик должны были всё ускорить… Но почему мы всё ещё топчемся на месте?
Взяв маркер, подошёл к доске и написал крупными буквами:
«Дело № 01. Замедление»
Чуть ниже вывел пункты:
Ключевые решения по тактическим шагам ‑прерогатива совета директоров, а не отдельной экспертизы
Общий бэклог: тысячи инициатив (часть без «живых» владельцев).
Доски команд перегружены.
Lead time определяется ожиданием, а не приоритетом.
Обратная связь от рынка — после релиза.
Ответственность формальная (единое ответственное лицо есть, но не работает).
Воронов остановился и задумался. Потом добавил ещё одну строку:
Agile на бумаге есть, а скорости нет.
Марк долго стоял и смотрел на надпись, о чём‑то глубоко задумавшись. Затем, словно о чём‑то вспомнив, резко развернулся и направился к двери.
Встреча с руководством
Воронов вошёл в конференц‑зал. Посреди просторного помещения стоял длинный полированный стол с сидящими вокруг руководителями подразделений компании. Воронов сел на свободное место.
Генеральный откинулся в кресле во главе стола:
— Марк, когда мы запускали масштабную трансформацию компании, мы с вами сформулировали чёткие метрики эффективности. Ведь так? Абсолютно верно! Тогда давайте поймём, что не работает и почему, и что надо сделать, чтобы заработало?
Воронов спокойно и твёрдо взглянул на генерального:
— Мы внедрили модные практики, но не изменили систему. Формально у нас есть спринты, ретроспективы, бэклоги… Но внутри…. Количество встреч выросло, ролей стало больше, процессов — тоже. А скорость вывода изменений на рынок почти не увеличилась: все инициативы проходят через Portfolio Kanban, комитеты, согласования… и попадают в общий бэклог. Который уже измеряется тысячами задач.
Оживился заместитель генерального:
— Но у нас есть формула приоритизации.
— Есть. Но сроки определяются не приоритетом, а самым перегруженным участком системы. Даже важнейшая задача не может пройти быстрее узкого места, — ответил Воронов.
За столом повисла пауза. Сидящие переглянулись. Директор окинул Воронова взглядом:
— К завтрашнему утру жду от вас подробный план по исправлению ситуации.
И, обращаясь к остальным:
— Руководители подразделений окажут вам всю необходимую поддержку.
Начало расследования
Воронов шёл по коридорам офиса и заходил в помещения, мимо которых проходил, что‑то спрашивал у сотрудников. В отделе аналитиков люди сосредоточенно смотрели в мониторы. Усталый мидл на вопрос Воронова ответил так:
— Мы закрываем задачи, но не всегда понимаем, как это влияет на клиента. Да и на что‑либо ещё, если честно.
Подобный ответ Марк услышал и от разработчиков: парни слабо представляли, как их код влияет на конечный продукт и пользователей, они просто закрывали задачи в трекере. Та же история повторилась и в отделе тестирования, и у архитекторов. Каждый отдел оптимизировал собственную загрузку и собственные показатели, плохо понимая, как они связаны не то, что с общей целью, а даже с работой смежников.
Воронов остановился у Kanban‑доски в одном из отделов. Сотни карточек, многие в статусе «Ожидание». Марк сфотографировал их и задумался. «Команды организованы вокруг собственных функций, а не вокруг создания общей ценности, а ведь клиентов интересует только она, а не как мы её создаём. Каждая передача задачи между отделами — это ожидание, а каждое ожидание — потеря времени. Каждая зависимость — риск увеличения всё того же ожидания. Кто‑то должен отвечать за общий результат, но в сложившейся системе ответственность размазана по всем. А значит, никто не отвечает за общий результат».
С этими мыслями Воронов снова направился в отдел разработчиков.
Первая зацепка
Аня, энергичная девушка, последние полтора года руководившая разработчиками, настойчиво выговаривала Марку:
— Мы работаем по Scrum. Спринты, ретро, планирование — всё есть. Но бэклог растёт быстрее, чем мы успеваем его разгребать! Только возьмёшь одну задачу, как приходится бросать и брать другую! — А кто управляет приоритетами вашего бэклога? — Комитеты, через Portfolio Kanban. Так вот, сделаешь какую‑нибудь фичу пилишь целый квартал, отдаёшь, а в ответ тишина. Чего хотели? Что получилось? Нужно ли развивать дальше? Непонятно. Для себя мы считаем результатом релиз, но никто не проверяет, изменилось ли что‑то для клиента.
— Значит… вы управляете работой, а не результатом, — тихо проговорил Воронов.
Поблагодарив Анну, он направился к архитекторам.

Технологический тупик
Воронов спустился в зал, где его встретил Сергей, старший архитектор. Крупный, бородатый мужчина, он горячился, выплёскивая Марку наболевшее:
— Мы не можем двигаться быстрее, потому что тащим за собой груз прошлых решений. Постоянно говорим о проблемах в архитектуре, но время на их исправление в план не заложено, и они просто переходят в новые проекты. Техдолг растёт, скорость падает, дефектов становится больше.
— И что, совсем нет времени на их исправление?
Сергей горько усмехнулся:
— Нет. Все хотят новые фичи, а старые проблемы… Они как призраки: не видны, но мешают.
— Получается, что техдолг — невидимый тормоз…
— Через нас проходят все сложные решения.
— Сколько у вас задач?
— Всегда больше, чем мы можем сделать.
— Очередь?
— Постоянная.
Воронов задумался:
— Значит, именно от вас зависит реальный срок поставки функциональности…
Сергей кивнул:
— Приоритетов много, а экспертиза — одна. Самые перегруженные отделы создают «свои» бэклоги, а если подключаются другие команды, то возникает цепочка зависимостей. Когда на одну команду валится несколько важных задач, возникает конфликт приоритетов. А там ещё и цепочки согласований…
Марк уже вполне ясно понимал сложившуюся в компании ситуацию.
Ответственность
Сгустился вечер, и по панораме города рассыпались тусклые огни. Воронов изучал схему ролей. Судя по документам, на всех этапах Kanban‑процесса везде были единые ответственные лица (ЕОЛ). Но когда возникали сложные вопросы, ситуация становилась менее очевидной. В разных командах роль владельца продукта трактовали по‑разному. Некоторые сотрудники одновременно участвовали в нескольких командах. Часть критически важных компетенций находилась за пределами продуктовых команд.
В результате многие решения принимали коллективно. Из‑за этого возникала парадоксальная ситуация: владельцы есть…
Воронов закрыл файл, и со вздохом пробормотал.
— А ответственности нет.
Первые выводы
В офисе почти везде уже выключили освещение, лишь слабые лампы с трудом разгоняли темноту в коридорах. Воронов задумчиво стоял перед белой доской, машинально постукивая себя по носу маркером. В левой части доски красовался список:
Функциональная структура → зависимости и ожидание.
Portfolio Kanban → потерявший актуальность бэклог.
Инициативное мышление → нет управления результатом.
Перегруженные отделы → узкие места.
Поздняя обратная связь → риск инвестиций.
Техдолг → скрытое замедление.
Формальная ответственность → отсутствие владельца результата.
Воронов перестал наконец терзать маркером свой нос и подписал ниже:
Система оптимизирована для запуска работ, но не для потока создания ценности.
Марк подошёл к панорамному окну и долго всматривался в городскую панораму. Затем, словно обращаясь к кому‑то, произнёс:
— Умеем запускать проекты, но не умеем быстро получать результат.
Финальная сцена
На столе пиликнул смартфон, мигнув экраном. В мессенджере было сообщение от уже удалённого аккаунта:
«Вы на верном пути. Но смотрите не на тот уровень».
Воронов замер, глядя на слова. Появилось ещё одно сообщение:
«Чтобы ускориться, нужно изменить не процессы. Нужно изменить систему».
И после этого всё исчезло, словно никто и не писал.
Воронов обернулся к доске.
Камера приближается к надписи:

Титры:
Продолжение следует…
Команда консалтинга Т1
Автор: T1_IT

