Rose debug info
---------------

Срыв дедлайна — в 99% случаев вина менеджмента, а не команды разработки

В своем маленьком Телеграм-канале я делал опрос на тему «Срыв дедлайна — в 99% случаев вина менеджмента, а не членов команды разработки?». Проголосовали 15 человек — почти половина канала:

  • За ответ «Нет» 7% — один человек
  • За ответ «Да» 20% — три человека включая меня
  • За ответ «Все не так однозначно» 73% — одиннадцать человек

Итак, почему я считаю, что почти всегда срыв дедлайна — вина и ошибки менеджмента.

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

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

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

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

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

Поделиться
Отправить
 51   7 мес   Менеджмент