Кейс восстановлен по материалам выступления на TAC 2021. Смотреть запись.
Почему это было проблемой бизнеса
Четыре команды развивали разные бизнес-линии, но выпускали изменения через одно мобильное приложение. Поэтому локальная эффективность отдельной команды почти ничего не говорила о скорости выхода функции на рынок.
Работа скапливалась между аналитикой, разработкой, review, тестированием и общим регрессом. Заблокированные задачи переносили в отдельный статус и фактически убирали из поля зрения. Приоритеты менялись быстрее, чем команды завершали начатое. Бизнес видел срыв срока, но не мог отличить нехватку мощности от очереди, блокировки или неверного правила работы.
Нанять ещё людей означало бы добавить нагрузку в уже перегруженную систему. Мы выбрали другую цель: повысить отдачу существующего контура и сделать причины задержек наблюдаемыми.
Три управленческих решения
1. Прекратить скрывать стоимость ожидания
Блокировку сделали свойством карточки и добавили возраст работы в каждом состоянии. Отдельный статус Station Hold убрали. Руководители и команды начали видеть, сколько инициатив стоит, где именно и по какой причине.
Первая инвентаризация показала качество портфеля незавершённой работы:
- около половины отложенных карточек уже потеряли актуальность;
- ещё 20–30% могли двигаться и не имели реальной блокировки;
- часть результата уже была выпущена в составе других изменений;
- отдельные задачи находились в review 100–150 дней.
Для C-level это важнее цвета карточек на доске: организация финансировала работу, которая не приближала выпуск и создавала ложное представление о загрузке.
2. Управлять завершением, а не занятостью
Ежедневный разбор перестроили вокруг движения работы: от ближайшей к выпуску карточки к более ранним. Главный вопрос звучал так: что должно произойти, чтобы результат перешёл дальше?
Решение изменило поведение без изменения оргструктуры. Разработчики и тестировщики начали вместе разбирать регресс и очереди. Нехватка автоматизации стала ограничением общего потока, поэтому команды смогли обоснованно выделять ёмкость на технический долг.
3. Ограничить объём одновременно начатых инициатив
После очистки потока ввели лимиты незавершённой работы. Это было решение о распределении капитала и внимания: меньше параллельных ставок, быстрее обратная связь по каждой из них.
На регулярном обзоре поставки команды изучали длительность завершённых задач, блокировки, возвраты и acceptance-баги. Спор о том, кто занят сильнее, заменили разбором конкретного задержанного результата.
Результат
В одной из команд медиана Lead Time сократилась с 49 до 17 дней. Пессимистичная оценка срока — хвост распределения, важный для обещаний бизнесу, — уменьшилась примерно со 100 до 48 дней.
Эффект получен при прежних 54 специалистах, без реорганизации и сокращения объёма ответственности. Система стала быстрее за счёт меньшего числа очередей, возвратов и забытых задач.
Что здесь можно масштабировать
Переносить в другую компанию названия встреч и настройки доски бессмысленно. Масштабируется последовательность управленческих действий:
- определить общую единицу поставки и стоимость её ожидания;
- убрать места, где незавершённая работа становится невидимой;
- ограничить число параллельных ставок;
- регулярно принимать решения по фактам завершённой работы;
- после стабилизации искать следующее ограничение выше — в приоритизации, зависимостях или продуктовом портфеле.
Ограничения кейса
Данные относятся к четырём командам и конкретному мобильному контуру. Изменение не решало продуктовую приоритизацию и экономику инициатив. Кроме того, первые циклы держались на внешней фасилитации. Для устойчивости я обучил внутренних ведущих; три-четыре команды смогли проводить обзоры самостоятельно.