Менеджер челенджит команду и это хорошо
Посвящается моему другу у которого на проекте ПМ просрал всё, что можно и их ждёт 2 месяца хардкора и овертаймов.
Problem statement
При выполнении fix price проекта был допущен ряд ошибок, что привело к проблеме со сроками сдачи. В Fix Price проектах определены объем работ (scope) и бюджет, но с течением времени может возникнуть ситуация известная как «scope creep», когда объем работы неожиданно расширяется, в то время как бюджет остается прежним.
Как обычно
Традиционные подходы решения данной проблемы:
Загнобить команду и сделать виноватыми — криворукие багоделы развели багодельню, ничего не могут и не умеют.
Утопить команду в овертаймах, чтобы через несколько недель или месяцев люди напоминали лошадь, загнанную до кровавой пены.
Залить проблему людьми в надежде, что кровавые боги деливери примут жертву и это как-то поможет ситуации.
В результате этих действий между командой и менеджером растёт напряжение и теряется доверие.
Также становится общепринятым, что менеджер проекта подвергает сомнению (или даже отвергает) оценки команды по времени выполнения задач. Это делается в попытке сократить время выполнения и попасть в запланированные сроки.
Типичный диалог между менеджером проекта (ПМ) и командой (К):
К: Мы оценили эту задачу в 120 часов.
ПМ: На фазе дискавери эта задача была оценена архитектором в 40 часов! Мне надо чтобы она была сделана за 40 часов!
К: Но задача на 120 часов.
ПМ: Она должна быть сделана за 40 часов и точка!
На этом этапе полезно остановиться и попробовать понять мотивацию каждой стороны.
Для менеджера проекта ключевая проблема заключается в сроках выполнения задачи. Если задача не выполнена в срок, это означает потерю денег и, возможно, штрафы. Плюс над ним всегда босс (портфолио или програм менеджер, или заказчик) который ставит его в коленнопреклонную позу по той же самой причине — сроки/деньги. Поэтому за сроки и возможность их сокращения ПМ загрызёт всех и каждого в команде (заказчика же страшно).
С другой стороны, команда может видеть менеджера проекта как человека, который не слушает их мнение. Они понимают, что даже если задача будет оценена в 40 часов, это не сделает ее выполнение быстрее.
В этом моменте начинается ключевое задание — найти способ достичь общей цели.
Выполнить проект в срок, без овертаймов и в соответствии с требованиями клиента.
Как надо
Сложность этого задания в том, что нужно работать осознанно и слаженно всем. Вот простой способ для решения этой проблемы:
К: Эту задачу мы оценили в 120 часов.
ПМ: На фазе дискавери задача была оценена в 40 часов. Почему сейчас она выросла до 120? Вы можете мне, пожалуйста, объяснить?
К: Мы декомпозировали задачу она состоит из подзадач А, Б и В. Подзадача А — 40 часов, Б — 40 и В тоже 40 часов.
ПМ: Задачу В мы уже решали в рамках проекта. Мы можем переиспользовать её?
К: Думаю да, но нам понадобится 10 часов на интеграцию.
ПМ: Коллеги, я понимаю, что мы смогли ужать задача до 90 часов. Но как нам ужать её до 40?
К: Можно выкинуть вот это, это и ещё это. Но кое-что надо утвредить с заказчиком. Но всё равно получается 50.
ПМ: Хорошо. Я постараюсь решить вопрос с заказчиком. Но если вы видите, что мы ещё можем сэкономить 10 часов, дайте немедленно об этом знать.
В ситуации, когда менеджер челенджит команду и подвергает сомнению их оценку нет ничего плохого. Различия в оценке задач между менеджерами и командой разработчиков — обычное явление. Важно понимать, что вызывать вопросы и обсуждать оценку не является негативным действием, если это делается с нужной целью и подходом. Причины могут быть разными:
Усталость команды: когда команда работает над проектом долгое время, её взгляд может стать «замыленным». Иногда нужен взгляд со стороны, чтобы помочь рассмотреть задачу с разных сторон или сподвигнуть к этому на фоне усталости.
Переусложнение задачи: иногда команда может усложнить задачу, стремясь обеспечить слишком высокую совместимость, масштабируемость или иные нефункциональные требования. Здесь менеджер может ограничить уровень сложности и сохранить фокус на основной задаче.
Отсутствие связи с заказчиком: команда может не иметь прямого доступа к заказчику, и поэтому может быть лишена возможности влиять на объем работ. В этой ситуации менеджер может вступить и обсудить, какие функции действительно необходимы, и есть ли возможность сократить объем работы.
Повторение задач: иногда команда может не заметить, что она решает одну и ту же задачу несколько раз. ПМ может помочь, обозначив ранее решенные задачи и избегая повторного выполнения одних и тех же работ.
Завышение оценок. Команда может давать завышенные оценки просто потому, что. Здесь менеджер может помочь, обсудив и выравнив оценки.
К сожалению, это обычная ситуация, когда изначальная оценка проекта оказывается недостаточно точной, а исправлять все это приходится команде. В отдельной статье мы рассмотрим, как избежать подобных проблем для менеджеров проектов.
Я специально не рассматриваю в этой статье проблемы people management’a т.к. это достаточно обширный тема для отдельный статьи и что-то уже из этого я рассматривал в своём личном блоге.
