Обусловлен ли срыв дедлайна ошибками менеджмента

Некоторое время назад в своем маленьком Телеграм-канале я делал опрос на тему срыва дедлайнов и ответственности за них. Вопрос звучал так: «Обусловлен ли срыв дедлайна в большинстве случаев ошибками менеджмента, а не команды разработки?»

• 7% за ответ «Нет»
• 20% за ответ «Да»
• 73% за ответ «Все не так однозначно»

Итак, почему я придерживаюсь позиции «Да».

Давайте представим среднестатистическую кросс-функциональную команду разработки: продакт, возможно деливери менеджер, бэкенд, фронтенд, DevOps, QA, которые все дружно работают над новым проектом, фичей или серьезными изменениями в продукте.

У бизнеса¹ есть цель заработать денег или завоевать определенную долю пользователей или рынка, а лучше и то, и другое в некоторой временной перспективе. Таким образом, бизнес ставит задачу команде, а команда коммитится на результат. Погнали.

Но уже на самом старте менеджмент может столкнуться со сложностями договоренностей с бизнесом. Как правило, менеджер продукта обсуждая с бизнесом результат, ставит перед собой и командой дедлайн. Бизнес, конечно же, не сильно интересует команда, ее состав, опыт, сработанность и др. факторы — он ожидает некую временную отсечку, после которой можно смотреть на достижение поставленных целей и дальнейшее изменение стратегии. Если менеджеры договорились между собой о дедлайне, не вовлекая в процесс оценки команду и не заложив дополнительное время на непредвиденные обстоятельства, то практически всегда мы в итоге получаем срыв этого самого дедлайна: скоуп задач оказался слишком большим, затянулись этапы подготовки (анализ, описание требований и спецификаций, инфраструктуры и др. операционные вопросы), команда посмотрев требования высказала свою точку зрения, оценки менеджера и команды разошлись и т. п. Приехали.

Ок, даже если так случилось, и менеджер вдруг понял, что команда не вложится в оговоренные сроки, то вырулить все еще можно порезав скоуп задач и цели, а затем пойти передоговариваться с бизнесом (в счет не берем ситуации «сделай или умри», когда бизнес запускается под какой-то ивент). И на этом этапе решает умение управлять ожиданиями заказчика и стекхолдеров. Если менеджер этого не делает, то с большей вероятностью, исходная ситуация будет усугубляться при приближении даты дедлайна: менеджер и команда будут пытаться вкидывать больше ресурсов, принимать рискованные решения. За счет этого увеличиться уровень стресса и напряжения внутри команды. Здесь мы видим вторую ошибку менеджмента, которая может оказаться фатальной для всех — бизнеса, который пребывал в неведении и ждал результатов от команды; команды, которая в поте лица пыталась все же выполнить срок и выгорела; менеджера, который показал, что не в силах спланировать разработку, управлять ожиданиями и рисками.

Вот и получается, что на малую часть срывов всех дедлайнов остаются внешние факторы, которые случились либо перед самым запуском: например, ваш провайдер инфраструктуры внезапно упал из-за урагана, либо кто-то из команды заболел (но и в этой ситуации вы, как менеджер, тоже просчитались — допустили bus factor на проекте), либо вы совместно с бизнесом поняли, что не стоит выпускать на рынок сырой продукт, и репутация компании стоит дороже тех изменений, которые вы планировали показать конечным пользователям.