Проектный менеджмент: свой, чужой, свой

«Кто такие вообще эти проектные менеджеры? Зачем их придумали? Одни беды от них — процесс затягивается из-за дополнительного посредника, так он еще и не всегда может объяснить как команда собирается решать мои задачи, и со сроками нет-нет обманет….уж лучше напрямую работать с разработчиками….»

Так иногда говорят заказчики, когда команды разработчиков ведут все общение через проектных менеджеров.

• “Проектные менеджеры это просто люди, которые не смогли стать разработчиками”.
• “Опять он долбит из-за сроков — ну чего непонятного — не получилось по плану! Бывает”.
• “Что сложного было объяснить заказчику сразу — почему мы именно так сделать не сможем, а будем по другому. Это же проще простого!”
• “И зачем он все время требует оценивать задачи по срокам исполнения? Это же так тяжело предсказать!”
• “Опять клиенты хотят какую-то ерунду! Да как он вообще согласился это делать? Это же бред!”

А это уже слова разработчиков про все тех же менеджеров.

Стоп! Но если они так тупят, затягивают, далеко не все понимают в разработке и вообще усложняют всем жизнь на первый взгляд, какая от них может быть польза? Те, у кого опыта в процессах разработки побольше, и так знают, для остальных эту самую пользу можно разложить примерно на такие факторы:

• Кто спасет разработчиков с тонкой душевной организацией (а таких абсолютное большинство) от регулярного (примерно несколько раз в день) выедания мозга заказчиком? Ну хорошо, это далеко не всегда можно и следует называть выеданием мозга, но даже если тебе просто несколько раз в день задают вопросы по теме и вне ее, не давая погрузиться в задачу и спокойно работать — в этом тоже мало приятного.
• Кто человеческим языком объяснит заказчику все эти жуткие и непонятные термины (зачем вообще их употреблять при решении его задачи — ведь все так просто)?
• Кто без лишних эмоций, эпитетов и прочего мусора разъяснит суть и цель задачи разработчикам с первого раза (предварительно потратив на это несколько дней или даже недель)? А потом еще и письменно разложит это по пунктам?
• Кто прикроет неуспевающих вовремя закончить задачи разработчиков и объяснит заказчику, что вообще то именно так и должно быть, потому что задачу решили сделать с заделом на будущий хитровые..аный функционал, а не так как оценивали в начале? Да так, что заказчик потом еще и спасибо скажет.

Теперь получается, что ПМы это просто спасители проектов и без них никуда. Так и есть. Почему же их тогда несправедливо обижают?

А потому, например, что грамотного ПМа, так же как и разработчика нужно еще вырастить и воспитать =) И это дано не каждому, несмотря на кажущуюся легкость решаемых задач (ну по сравнению с разработчиками конечно). Ведь если разработчики общаются в основном между собой и с менеджерами, то менеджеры помимо них взаимодействуют и с заказчиками, уровень которых варьируется от «сделайте мне то, сам не знаю что и вообще еще вчера» и до «хочу вот так, и, пожалуйста, с красными бантиками, на фоне зеленой травки, и чтоб все двигалось…», не говоря уже о «да, я понимаю, что на прошлой неделе я хотел интернет-магазин игрушек, но сегодня я хочу социальную сеть как Вконтакте, а клиент всегда прав, поэтому вы просто обязаны все срочно переделать, причем совершенно бесплатно!»

К счастью, заказчики далеко не все такие, но ведь взаимодействовать то приходится СО ВСЕМИ! А по сему, воспитывая проектного менеджера, не забудьте обучить его следующим приемам самообороны принципам работы для лучшего баланса:

• Заказчик не всегда прав, но всегда должен иметь возможность видеть на какой стадии находится проект и прямая обязанность ПМа это обеспечить;
• Разных клиентов волнуют разные вопросы, а некоторые и вовсе настолько переживают за свой проект, что просто выносят мозг менеджеру, постоянно о чем-то спрашивая. Взаимодействовать с клиентом нужно постоянно, а нервы свои по этому поводу оставлять дома, ну или в крайнем случае в тренажерном или на ринге;
• Донесение информации прежде всего. Не всегда получается выполнять задачи по IT разработке в срок, но клиент всегда должен быть заранее предупрежден о задержке (а не по факту прое..ной поставки);
• С клиентом нужно говорить на его языке, а не на языке разработки, в которой он скорее всего ничего не понимает. Чем доступнее клиенту, то что объясняет менеджер, тем меньше вопросов в процессе;
• Разработчикам лучше доносить суть задачи/проблемы если не техническим языком, то хотя бы в простых предложениях и по пунктам. Чем проще понять тех задание, тем меньше возможности ошибиться в оценке или вообще сделать что-то не то;
• Заказчик — не враг, который пытается замучить разработчиков. Он — тот, кто платит. Ему и заказывать музыку.

И конечно потенциально хороший проектный менеджер должен обладать некоторыми базовыми качествами или чертами характера, если хотите. Ну например, он должен быть пунктуальным — опоздание на встречи никак не приветствуется ни заказчиками, ни разработчиками, хотя последние зачастую сами еще те любители все на свете проспать (разумеется, потому что кодили всю ночь, а то и вовсе хакатонили все выходные). А еще — ответственным, иначе задачи и сроки будут про…раны. Очень поможет во взаимодействии с заказчиками и разработчиками гибкость и спокойствие, ведь порой выслушивать все стороны и приводить их к общему знаменателю совсем не просто.

Ошибки ПМа, которые утащат твой проект и команду на дно

Самое главное (для него даже отдельный абзац) — искреннее желание помочь решить проблему заказчика. Ведь именно с проблемой он пришел. И задача менеджера убедить заказчика, что проблема будет решена в лучшем виде. И убеждение должно быть искренним. Потому что заказчик может смириться с тем, что команда обходится ему дороже, чем он ожидал. И с тем, что проект делается дольше, чем он рассчитывал. Но фальши он не простит точно.

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

Каждому свое место и своя роль в проекте. А лишних держать незачем.

И немного классики: