Когда я пришла развивать sovcombank.ru, средний эпик в команде поддоменов жил около шести месяцев. Причина была не в скорости разработки: сам код писался быстро, cycle time выглядел вполне здоровым. Время съедалось не туда, куда обычно смотрят. Его съедали простои: задача ждала уточнения требований, потом ждала своей очереди в бэклоге, потом возвращалась на доработку постановки, а на финише выяснялось, что у команды просто нет свободной емкости в этом спринте.

Если посчитать flow efficiency, то есть долю времени, когда над задачей реально кто-то работает, картина была неприятной: большую часть lead time эпик проводил в статусе ожидания.

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

Прозрачная приоритизация Первое, что я убрала из процесса, это вопрос «а чья задача важнее». Пока приоритет определяется весом голоса стейкхолдера, любой конфликт интересов превращается в эскалацию, а эскалация стоит минимум неделю простоя.

Мы перешли на кастомный фреймворк приоритизации, близкий по логике к RICE и WSJF, но адаптированный под специфику департамента. Инициатива оценивается по вкладу в продуктовые цели: влияние на выручку и конверсию, регуляторная критичность, стоимость реализации, риски. Спор о статусе превратился в спор о цифрах, а такой спор закрывается за одну встречу, без выхода на уровень выше.

Регулярный груминг с заказчиками Бэклог, который рефайнится только внутри команды, всегда расходится с реальностью бизнеса. Мы стали разбирать его вместе с заказчиками: что ещё актуально, что потеряло смысл, где изменилась формулировка гипотезы. Побочный эффект оказался ценнее основного. Заказчики начали приходить с более зрелыми запросами, потому что заранее знали, какие вопросы им зададут на груминге. Фактически мы сдвинули часть discovery на сторону бизнеса.

Стандартизация требований Мы зафиксировали этапы, обязательные артефакты и ввели прозрачные DoR и DoD. Задачи перестали уходить в реворк из-за неполноты постановки: команда больше не бралась за эпик, который не проходит входной чек-лист. Этап сбора и согласования требований сократился на 30%: просто потому что все участники заранее понимали, какой набор артефактов нужно принести.

Контроль загрузки Последний блок это учет часов и бюджетов с распределением емкости между заказчиками и командами. До его внедрения планирование было гаданием: мы называли срок, не имея честной картины по тому, чем реально занята команда. После появления capacity planning сроки начали сходиться, потому что опирались на доступную емкость, а не на оптимизм. Заодно стало видно узкие места: где именно очередь копится и какая роль является bottleneck.

Time-to-market почти никогда не сокращается за счет «работать быстрее». Он сокращается за счет устранения ожиданий: ожидания решения, ожидания уточнения, ожидания свободных рук. Каждая из четырёх мер по отдельности давала немного, единицы процентов к скорости потока. Вместе они убрали половину срока, потому что работали не с производительностью людей, а с эффективностью самого процесса поставки.