14 нояб. 2007 г.

Один руководитель — один проект

…он [PM] живет, ест и дышит проектом. Он намерен выполнить его или умереть. В любое время он держит руку на пульсе проекта и знает как он идет…
© Фергус О’Коннэл

Фигня война, как-нибудь прорвемся!
© Я

Думаю, что среди нас не найдется никого, кто бы никогда не находился в состоянии аврала или не испытывал чувство, когда проектов столько, что ни за один невозможно взяться, руки опускаются.

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

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

Есть такие люди (я к ним отношусь), которые вроде бы делают много проектов, все у них выполняется «одноврЕменно» © Гришковец, со стороны может показаться, что дела спорятся. Но на самом деле это не так.

Порассуждаем. От чего отказывается амбициозный (или бесхребетный) PM (Project Manager) в первую очередь, видя, что проект нужно выполнять только в свободное от других занятий время? Правильно. В первую очередь идет снижение объема формального описания проекта (в простонародии, ТЗ). В худшем случае выполняется полный отказ от такого описания. В лучшем случае — снижается акцент или не затрагиваются вовсе темы завершающей стадии проекта, финальных ПСИ (приемо-сдаточных испытаний), этапов внедрения, передачи на сопровождение, вопросы оформления факта завершения проекта.

Также страдает подготовительная стадия, на которой много сил и энергии отнимает процесс общения с заказчиком, который, естественно, не разделяет подобного энтузиазма («вам нужно — вы и делайте, а мне нужно, чтобы все работало как надо»). Понятно, что PM, для которого этот проект не единственный, не сможет уделить достаточно внимания клиенту, процессу вытаскивания из него жил и ценных сведений, а также убеждению клиента в том, что он не прав. :-)

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

Что мы получаем на выходе? Недостаточно продуманный проект, успешно реализованный профессионалами в программировании, но приносящий множество проблем при первой инсталляции, первичном тестировании, запуске в эксплуатацию. Впоследствии, поскольку не проработана стадия передачи проекта на сопровождение, возникает уйма вопросов, которые решить под силу только программистам. Возникают какие-то пожелания заказчика, вопросы, по которым PM-у приходится вести переписку, в результате ставить в план реализации новой версии или срывать ресурсы на быстрое латание дыр. Таким образом, PM вынужден-таки отдать проекту то время, которым он обделил его на начальной стадии. И частенько возврат этот выполняется сторицей.

Но хуже всего то, что внимание и время, которое вроде бы завершенный (и поэтому, не учитываемый при планировании новых задач) проект требует к себе, влечет повышение уровня рутины в рабочем дне горе-PM и, как следствие, уменьшение объема времени, которое бедолага может уделить новому, супер-приоритетному и стратегически важному (а они всегда такие!) проекту.

Ранее я придерживался более мягкой позиции, считая, что на одного руководителя можно вешать максимум 2–3 проекта. Но теперь мое мнение вполне категорично: «один руководитель — один проект». Возможно, это покажется роскошью, кто-то скажет, что при такой формуле не удастся сделать такое количество проектов, которое выполняется сейчас. Я полностью согласен — не удастся. А нужно ли? Возможно, подходя более тщательно к выбору проекта, можно будет бить по самым перспективным направлениям? Возможно, детальная проработка финальной стадии проекта позволит легко клонировать большее количество полученного материала? Может быть, хорошо выполненная проработка бизнес и технической модели на начальной стадии, позволит не отклоняться от пути стратегического развития компании?

Подписаться на новые статьи:  RSS (Что это такое?) или Email