Я уже не первый раз сталкиваюсь с вопросом, должен ли PM быть технически подкованным человеком или нет. Иными словами, должен ли у него быть опыт работы программистом или QA, для того, чтобы успешно вести проекты, связанные с разработкой ПО. И собственно, вопрос здесь даже не в том, возможно это или нет - опыт показывает, что есть нетехнические PM, которые с разной степенью успешности ведут проекты. Но в то же время тот же опыт показывает, что а) таких людей довольно мало, б) им иногда бывает сложнее, в) общественное мнение в лице различных IT-специалистов иногда отрицает эффективность такого PM. Столкнувшись с этим вопросом, я решил провести небольшой опрос среди моих друзей и сотрудников (бывших и нынешних). Выборка была порядка 20 человек (знаю, нерепрезентативная, но я и не старался делать соцопрос, скорее, получить дополнительную пищу для размышлений), люди абсолютно разного уровня и позиций: программисты, QA, BA, девлиды/тимлиды различного плана, и несколько ребят, которые так или иначе выполняют функции PM на своих проектах или ими являются. Задавал я, как правило, один и тот же вопрос, в краткой форме приведенный в заголовке данной заметки, а потом, по ходу дела, спрашивал детальнее, уточнял подробности, иногда дискутировал :) Ответы были разными, некоторые совпадали с моим мнением, некоторые - нет. Но в любом случае, я благодарен всем, кто согласился ответить на эти вопросы, в независимости от точки зрения, т.к. вы помогли мне увидеть бОльшую картину, чем была у меня в голове до опроса. Все-таки опыт у разных людей разный, поэтому одна голова - хорошо, а двадцать лучше. Также я немного потерроризировал гугл, а также сайты вроде www.stackoverflow.com, www.rsdn.ru и прочие уважаемые ресурсы.
Если очень коротко, то результаты опроса были следующими: где-то 40% людей так или иначе высказывались в пользу идеи, что у PM должен быть технический опыт, и что технический PM лучше нетехнического, причем неоднократно подчеркивались 2 мысли: лучший PM - PM-бывший программист, и лучший PM - PM-бывший QA. Я думаю, не стоит уточнять, у кого какое мнение ;) Остальные говорили, что либо технический опыт не имеет никакого значения, а иногда даже мешает, либо нетехнический PM способен эффективно руководить проектом, но все же не любым. Я же хотел бы высказать свои мысли по этому поводу, в том числе навеянные и общением на эту тему.
Чем занимается менеджер проекта
Менеджер проекта обычно отвечает за то, что проект будет выполняет в срок, в рамках выделенного бюджета, что результатом проекта будет продукт, который является тем, что хотел заказчик, и что продукт этот будет надлежащего качества. При этом в принципе, не особо важно, является ли продукт заказным или нет, кто заказчик - твой начальник, пользователи продукта или дядя за океаном, а также какие методологии/подходы/технологии были выбраны для реализации продукта. Это все варьируется, но цели - качественный продукт, удовлетворенный "клиент" и финансовая рентабельность разработки - остаются.
Для достижения этих целей, менеджер проекта занимается самыми различными активностями:
- планирование работ (или хотя бы помощь в этом в случае хорошей самоорганизации)
- распределение задач и отслеживание их выполнения (или хотя бы помощь в этом в случае хорошей самоорганизации)
- налаживание и управление различными процессами
- управление рисками
- управление командой (начиная от ее создания и заканчивая разрешением конфликтов)
- налаживание коммуникаций (с "клиентом", внутри команды)
- создание эффективно работающей команды, мотивация ее членов
- создание среды для эффективной и плодотворной работы всех остальных членов команды
- и т.д.
В разных проектах, с использованием различных методологий менеджеры могут выполнять все эти активности или только часть их, но в любом случае они в какой-то степени организовывают команду, мотивируют, помогают достичь результата и успеха. В идеале, работа менеджера должна быть вообще не видна. Процитирую своего хорошего друга: "Класснее всего когда работа ПМ явно не заметна, проект как бы сам собой выполнился. Там Вася постарался, тут Петя что-то классное придумал, а потом все само получилось. А ПМ _как-будто_ ничего не делал". Спольски тоже об этом писал в одной из своих статей.
Вы заметили, что здесь нигде не прозвучало "умение программировать", "умение тестировать", "понимать технологии", "умение строить архитектуру приложения", даже анализа требований и написания спецификаций и прочих документов не было. Почему? Потому что это знания, умения и активности, связанные с совершенно другими ролями на проекте.
Чем отличается должность от роли на проекте
Должность и роль - это разные понятия. Должность - это позиция человека в команде, которая вроде бы как хотя бы теоретически описывает то, чем человек занимается, а вот роль - это уже некая практическая сфера деятельности и ответственности, некий набор активностей. В идеале, позиция соответствует роли, но очень часто они связаны соотношение один-ко-многим. Человек на определенной позиции может выполнять несколько ролей на проекте. Также возможна и ситуация многие-ко-многим, когда несколько человек выполняют одну и ту же роль.
PM, менеджер проекта - это как должность/позиция, так и роль, и это часто сбивает людей с толку. Еще более сбивает с толку наличие кучи других лидерских позиций: Project Lead, Team Lead, Tech Lead, Dev Lead, QA Lead, Software Architect, можете продолжить сами. Я тоже раньше не мог точно сказать, кто за что отвечает, чем отличается, и вообще, кто все эти люди и что они здесь делают. Связано это с тем, что в разных компаниях и даже на разных проектах люди на этих позициях выполняют зачастую различные обязанности, а единого реестра как бы и нет... Расскажу, как я это понимаю, а вы если что поправляйте. Проще всего разобраться с Dev Lead и QA Lead - это явно выраженные технические позиции, которые четко совпадают с соответствующими ролями: они отвечают за техническую сторону реализации проекта, то есть разработку и проверку качества продукта. Программируют и тестируют они при этом или нет - не так важно, хотя чаще всего да. Позиции Tech Lead и Team Lead более размыты, человек на этих позициях может выполнять как чистую роль Dev Lead, так и несколько ролей: DL, QAL, иногда также PM, SA, BA. К тому же должность Team Lead может относится и к совсем другим сферам деятельности, по сути, это просто руководитель команды: системных администраторов, технических писателей, дизайнеров, бизнес-аналитиков и т.д.
Позиции Project Lead и Project Manager - самые интересные в этом списке, так как человек на каждой из этих позиций может выполнять кучу ролей: PM, DL, QAL, BA, SA, и др., в зависимости от проекта, и того, что понимается под этой позицией в отдельно взятом государстве, в данной конкретной компании, на конкретном проекте и т.д. Но все же разница здесь тоже присутствует. Обычно PL все-таки является техническим товарищем, объединяющим в себя как управляюще-аналитические роли (PM, BA), так и технические (DL, SA, иногда QAL), а вот PM'ами называют зачастую либо людей, играющих только роль PM, либо роли PM и BA, хотя в общем и целом это тоже далеко не гарантия.
Факторы, влияющие на то, может ли PM быть "нетехническим"
Таким образом, активности роли PM очень слабо связаны с техническими умениями. Но означает ли это, что можно взять классного нетехнического PM, поставить его на проект и тот приведет его к успеху? Нет, не всегда.
Для успешного выполнения проекта в команде должны быть представлены все роли, необходимые для этого. Здесь мы подходим к первому фактору, который влияет на ответ на наш вопрос - специфика проекта. Если на проекте есть готовые требования, скорее всего, вашей команде не нужен человек, выполняющий роль BA (это не значит, что для успеха проекта совсем не нужен BA, просто его работа уже выполнена кем-то другим выше вашей команды), если вам прислали готовые документы по архитектуре и дизайну, значит, вам скорее всего не нужен SA, если проект технически не слишком сложен, возможно, вам достаточно не самой сильной команды, но роль DL все равно придется на кого-то возложить, и этот "кто-то" должен соответствовать уровню этой роли.
Таким образом, если в команде есть кому занять роли DL, QAL, SA, BA (а также роли программистов и QA :)), то на должность менеджера проекта можно поставить человека, у которого нет опыта программирования, тестирования, бизнес-анализа, написания документации, но который будет заниматься исключительно менеджерскими активностями, которых тоже очень много. И, как показывает практика, профессионализм и сильный уровень в этих активностях зачастую еще более редки, чем профессионализм и желание постоянно повышать свой уровень у программиста.
Еще один немаловажный фактор, который определяет, какие роли будет выполнять человек на должности менеджера проекта - это размер проекта. На небольшом проекте особо не разгуляешься. Если каждому человеку в команде назначить одну роль, то будет, как на картинке, где один копает, а остальные смотрят :), потому что объем "чистых" активностей одной роли невелик или продолжается незначительный период времени, а работы по разработке или тестированию продукта очень много. Поэтому очень часто на небольших проектах PM (или уже скорее PL) выполняет не только менеджерские функции, но еще и является основным техническим специалистом на проекте, который и анализирует требования, и пишет спецификации, и продумывает архитектуру, и руководит тестированием, в общем, и швец, и жнец. Не говоря уже о том, что в таком случае разработка выходит намного дешевле, т.к. достаточно взять одного самородка, дать ему в команду 25 джуниоров - и дело пойдет ;) Шучу, конечно, но в каждой шутке, как известно, доля шутки - я такие ситуации видел не раз. Поэтому это тоже нужно учитывать.
Кроме того, не стоит забывать, что в оффшорном аутсорсинге, которым многие из нас занимаются, есть такая проблема, как общение с клиентом. Безусловно, клиенту намного удобнее иметь одного человека, с кем он будет общаться по всем вопросам, начиная от требований и заканчивая обсуждениями технических решений. Конечно, клиенту можно объяснить, что по разным вопросам нужно обращаться к разным людям, но это его зачастую смущает. Поэтому нередки ситуации, когда нетехническому PM приходится "общаться" с клиентами на технические темы, по сути, являясь прокси между клиентом и техническими специалистами, что не доставляет удовольствия ни PM'у, ни этим самым техническим специалистам.
Таким образом, нетехническому PM часто приходится так или иначе вникать в технические детали, но если он умеет правильно наладить коммуникации и работать с людьми, это не должно создавать для него особых проблем. И это подводит нас к следующему вопросу.
Есть ли минимальный набор "технических" знаний, необходимых PM?
На мой взгляд, хороший менеджер проекта, при условии заполнения остальных ролей другими членами команды, не обязан знать программирование или тестирование даже на минимальном уровне. НО (!) он все-таки должен хотя бы на каком-то уровне понимать, что такое разработка ПО, какие процессы в него вовлечены, в каком порядке и почему, что такое требования и запросы на изменение функциональности (change requests), как с ними работать, что такое качество продукта, что делают те или иные члены команды, в конце-концов. То есть, по сути, понимать специфику разработки ПО. Во всем остальном ему помогут другие члены команды.
Это же помогает найти ответ и на другой вопрос: можно ли взять успешного менеджера проектов, скажем, в рекламе, и поставить менеджером проекта по разработке ПО? Или можно ли научить человека проектному менеджменту в университете, а потом взять на работу? Можно, но этот человек все-таки должен для начала разобраться в "предметной области" IT-индустрии, прочитать кучу книг, статей, возможно, сдать определенные экзамены, а еще лучше своими глазами увидеть реальные IT-проекты и потренироваться на небольших и не особо критичных. Если у человека есть опыт и он умеет думать и учиться, то все возможно.
Так, может, лучше взять DL или QAL и сделать менеджера проекта из них?
Возможно, в некоторых ситуациях это не только "лучше", но еще и единственный возможный вариант. В нашей стране именно так и случается в большинстве случаев - менеджерами проектов становятся бывшие программисты, тестировщики или бизнес-аналитики, которые дошли по карьерной лестнице до самого верха, и не имея дальнейшей возможности развиваться технически или увеличивать свою зарплату, просто сделали шаг в сторону на другую лестницу, менеджерскую. Или этот шаг в сторону сделали за них. Или никакого шага и не было, и человек просто стал выполнять дополнительные задачи, в дополнение к своим техническим обязанностям, являясь, по сути Project Lead'ом.
Но важно понимать, что это не всегда обязательно, и что выполнять обязанности PM может и человек, который не имеет опыта работы программистом, QA или кем-то еще. Конечно, при условии, что вы понимаете, какие роли будет выполнять человек, которого вы ставите на должность PM и учитывать факторы, которые были изложены выше.
Насколько мне известно, на западе сейчас довольно активно пытаются внедрять в работу "нетехнических" менеджеров, поскольку у людей, обогащенных техническим опытом, точно такое же количество проблем при переходе на медеджерские должности, что и у "нетехнических" менеджеров проектов, которые сталкиваются с техническими вопросами. Более того, у PM вообще своя карьерная лестница, идущая параллельно технической лестнице. Так 100% работает Microsoft, наверняка, и другие крупные (и не только) компании. В таком случае у технического специалиста есть возможность развиваться технически по-максимуму, в том числе и по зарплате, а вот как раз выход на параллельную лестницу, как правило, означает снижение зарплаты, потому что твой текущий менеджерский уровень еще очень низок по сравнению с теми, кто имеет в этом вопрос намного больше опыта.
Поэтому в случае с переходом технического специалиста в менеджеры нужно понимать, что роль управления проектами довольно слабо связана с теми активностями, которые выполнял этот специалист раньше. И, в первую очередь, это нужно понимать самому этому специалисту. Кроме того, у бывших программистов и QA (хоть у последних и в меньшей степени) есть свои проблемы с выполнением менеджерских обязанностей. Не все хорошие технические специалисты становятся хорошими менеджерами - это давно известно, но об этих проблемах мы поговорим как-нибудь в другой раз - это тоже обширная тема. Но если Вы - именно тот человек, у которого это получается, и это вам интересно, то почему бы и не попробовать? Не получится - всегда можно вернуться в техническую сферу :) И тем более стоит пробовать, если вы нетехнический PM - у вас также есть хорошие шансы.
Успехов вам!
PS. Еще раз спасибо всем, кого я доставал своими глупыми вопросами :)
