Менеджер проектов? Давай, до свидания!

Какие основные вопросы возникают при разработке любого проекта (это не обязательно продукт, может быть и сервис, whatever)? Это Что, Когда, Как, Кто и Сколько. Вопрос Зачем оставим за бортом, допуская, что клиент это знает и знает правильно (если мы это допущение уберем, ничего существенно не изменится).  Остается рассмотреть 5 комбинаций.

PM и Что.


Очевидно, PM не особенно представляет, что нужно построить. Он же менеджер, а менеджер не обладает видением. Он только обеспечивает выполнение видения.  Он может понимать видение и транслировать его команде. Но такая ретрансляция всегда будет терять полезную информацию и вносить свой собственный шум. Зачем нам это надо?

PM и Как.


PM явно недостаточно квалифицирован, чтобы указывать разработчикам, тестировщикам и дизайнерам как работать. Следовательно, он не имеет права навязывать процесс разработки, лезть в код, лезть в тесты и тп. Возникает вопрос, кто должен решать, скажем, писать юнит тесты или нет? Ответ прост. Это должна решать команда, либо как минимум борд, состоящий из представителей команды и представителей заказчика. Если команда вообще нулевая и не знает ответа на вопрос Как. То, конечно, результаты проекта будут печальны в любом случае. Такую команду надо учить. PM заниматься обучением никак не может, потому что он не программист, не тестировщик и не дизайнер. Помочь ставить процесс команде может “консультант” (внутренний или внешний). А если вы не верите в полезность консультантов, то команда сама с успехом может взяться за это дело и набить нужные шишки на нужных местах.

PM и Когда.


PM недостаточно квалифицирован, чтобы оценивать работу разработчиков, тестировщиков, ну вы поняли. Значит сам он никогда не сможет дать достаточно аккуратный ответ по срокам. Более того, обычно и команда не может дать достаточно аккуратного ответа по срокам. Сроки могут быть спущены выше, но тогда должна быть гибкость по объему работ и тут нужна помощь представителя заказчика (PO?). Если сроки заказчиком не установлены, а он настаивает на определенном объеме работ, то предсказать время выпуска проекта с приемлемой точностью практически нереально. Только ближе к концу становится ясно, когда ожидать релиза. Так что роль PM и здесь не особенно помогает. Если проекты достаточно похожи, с достаточно стабильной командой и так далее (ну, скажем, веб-сайты вы штампуете пачками), то тут можно делать достаточно точный план и весело работать вотерфолом. У вас наверняка есть статистика завершенных проектов, которую можно использовать для предсказаний будущего. Но и тут PM не нужен, и так все ясно.



PM и Кто.


Считается, что задача PM — сформировать команду. На мой взгляд, этим с успехом может заниматься борд, состоящие из представителей разных профессий. Я могу допустить, что PM может достаточно хорошо знать, что из себя представляют 30-40 человек, но с большим числом людей ни один PM работать не способен. Борд в совокупности может легко знать, что из себя представляют 200-300 человек, и он способен обеспечить более грамотное планирование на уровне всей компании. PM всегда стремиться вырвать себе на проект лучших людей, пораждая конкурентную борьбу между всеми PM и оптимизирую свою локальную область. Однако, его мало заботит вся компания. И часто он даже не обладает всей информацией, чтобы думать в таком контексте. Так что на вопрос Кто он не должен отвечать.



PM  и Сколько.


Если PM не знает когда, то он не знает и сколько. Либо бюджет есть фиксированный, и тогда объем проекта будет плавать. Либо объем фиксирован, и тогда можно, конечно, прикинуть бюджет, но шансов дать точную оценку практически нет. А корректировки всего этого можно делать после каждого майлстоуна, ведь нормальная команда выпускает релизы часто, да?

devby 17 лет!

Вспоминаем наш (и ваш) переходный возраст и делимся виш-листом