Команда не медленная. Она ждёт решения: как измерить пропускную способность руководителя

Команда укомплектована. Задачи оценены. Все заняты. Разработка конкретной функции занимает несколько дней - но до ПРОДа она добирается несколько недель.

Остальное время работа ждёт: приоритета, доступа, архитектурного выбора, согласования изменения API, подтверждения scope, решения о допустимом риске или ответа человека, который оказался обязательной точкой согласования.

У инженерной команды есть два конвейера.

Первый - delivery pipeline: разработка, review, тестирование и релиз. Обычно он хорошо виден в таск-трекере и инженерных метриках.

Второй - decision pipeline: вопросы, варианты, согласования, эскалации и решения. Он часто существует только в чатах, встречах и голове руководителя. Поэтому команда выглядит медленной, хотя основная часть календарного времени уходит не на выполнение работы, а на ожидание возможности продолжить её.

В докладе рассмотрим управленческие решения как отдельный поток с входящей нагрузкой, очередью, состояниями, владельцами, пропускной способностью и SLO. Научимся измерять Decision Lead Time, возраст открытых решений, время фактической блокировки delivery, концентрацию решений на одном человеке и долю вопросов, которые попали на избыточно высокий уровень управления.

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

Аудитория станет руководителем, к которому одновременно поступят 15 запросов. Сначала попробуем отвечать быстрее. Затем наймём дополнительных разработчиков - и обнаружим, что вместе с производительностью команды вырос входящий поток решений, а очередь стала только длиннее. После этого перепроектируем систему: классифицируем решения по обратимости и blast radius, зададим decision SLO, определим владельцев, правила эскалации, решения по умолчанию и явные границы автономии.

Участники получат шаблон карточки решения, карту полномочий, минимальный dashboard руководителя и план внедрения системы за 30 дней.

Главная мысль доклада: задача руководителя - не стать самым быстрым человеком в очереди и не передать все решения вниз. Его задача - построить систему, в которой каждое решение принимается на минимально необходимом уровне, с достаточным контекстом, полномочиями и контролируемым риском.