В шапке
Роль руководителя проекта и его компетенций

Роль руководителя проекта и его компетенций

За десяток лет управления проектами я привык к полной ответственности за проект, которую некуда спихнуть и не с кем разделить. В ставшем уже почти классикой PMBOK руководитель проекта отвечает за все ключевые аспекты проекта: за достижение его целей в плановый срок и бюджет. Хороша работка ) А что делать руководителю проекта, если требования к продуктам проекта на старте еще слишком сырые, а заказчик проекта не готов принимать по ним решения? Я в таких случаях брал ответственность на себя и потом мог получить негативную реакцию от заказчика: типа сделали неплохой продукт, но не совсем то, что я ожидал. А мне в такие моменты очень хотелось спросить: «А где ты был, уважаемый заказчик, когда так нужно было твое решение по требованиям к продукту проекта?».

В последних проектах, которыми я руководил, для разработки и улучшения продукта мы использовали фреймворк scrum. Тогда я понял, как сильно заказчик может помочь команде проекта.

Поэтому первой я и написал заметку о роли заказчика проекта. От его компетентности успех проекта зависит в той же степени, что и от компетентности руководителя проекта.

Но вернемся к теме заметки: в чем же роль руководителя проекта?

Что интересно, роль руководителя проекта в разных методологиях управления проектами выглядит по-разному. Чего стоит, например, подход к команде проекта, используемый в MSF (Microsoft Solutions Framework)! Он заключается в том, что за успех проекта ответственна вся команда, состоящая из ролевых кластеров. Перечислю эти ролевые кластеры:

  • управление программой (program manager) — этот кластер отвечает за разработку архитектуры решения, административные службы;
  • разработка (developer) — отвечает за разработку приложений и инфраструктуры, технологические консультации;
  • тестирование (QAE) — отвечает за планирование, разработку тестов и отчетность по тестам;
  • управление выпуском (release manager) — отвечает за инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;
  • удовлетворение заказчика (user experience) — отвечает за обучение, эргономику, графический дизайн, техническую поддержку;
  • управление продуктом (product manager) — отвечает за бизнес-приоритеты, маркетинг, представительство интересов заказчика.

На мой взгляд, очень хорошо написано о команде в MSF здесь: http://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework

Лет 10 назад, когда я впервые ознакомился с моделью распределения ролей в команде по MSF, у меня возник вопрос: так кто же тот единственный герой, который отвечает за успех проекта в методологии MSF? И тогда я так и не смог принять идею о том, что в этой методологии ответственность за успех коллективная. Хотя, как мне представляется, есть все же и в этой модели тот, кто больше других будет переживать за успех проекта, и это - program manager. Но само по себе наличие модели команды с распределенной ответственностью уже интересный факт. Правда, в модели команды MSF ничего не сказано про роль заказчика проекта )

Вторая модель распределения ответственности за успех проекта, с которой я ознакомился уже на практике в нескольких проектах, – это модель проектной группы в фреймворке scrum. В scrum роль руководителя проекта в явном виде отсутствует. В модели проектной группы присутствует три ключевых роли - Scrum master, product owner (о роли которого я писал в заметке про заказчика проекта) и команда проекта. Scrum master отвечает за развитие команды, улучшение процессов работы над продуктом, соблюдение ритуалов scrum и ведение артефактов проекта. Он в большей степени отвечает за выполнение взятых командой обязательств за одну итерацию, но при этом ответственность за результат итерации с ним разделяет вся команда.

В одном из проектов мне довелось быть руководителем проекта и scrum master. При этом для управления проектом я использовал PMBOK, а для управления созданием одного из продуктов проекта, а именно программного продукта для автоматизации оперативного учета, мы использовали scrum. Scrum внутри PMBOK? Да, именно так ) И это сработало!

На примере этого проекта я понял, что руководитель проекта и scrum master – это не одно и то же. В большом проекте scrum master, скорее всего, будет отвечать за один из результатов проекта или пакетов работ, и будет подчиняться руководителю проекта. 

И вот мы подобрались к теме компетенций руководителя проекта. Какими навыками должен обладать руководитель проекта, чтобы справляться с серьезной неопределенностью, которая есть в проекте?

Я считаю, что он, в первую очередь, должен обладать soft skills, такими как:

  • умение собирать правильных людей и создавать из них команду
  • навыки ведения переговоров
  • умение повести за собой
  • умение выбрать более подходящую методологию (или их симбиоз) управления проектом для данного проекта и адаптировать ее под команду и окружение проекта
  • навыки использования и внедрения нескольких программных продуктов по управлению проектами

 

Умение собирать правильных людей и создавать из них команду – группу людей, разделяющих общую цель и ответственность за ее достижение, - это самый сложный навык, который нужно приобрести руководителю проекта.

Второй важный навык – это ведение переговоров, коих на проекте проходит огромное количество. Не владея этим навыком на высоком уровне, руководитель проекта будет получать массу проблем с принятием решений.

Третий навык, который стоит развивать РМу, – это умение повести за собой (или лидерство). Этот навык, на мой взгляд, можно «прокачать». Даже если от рождения у вас недостаточно харизмы, ее можно приобрести. О том, как стать лидером, пишут книги, этому учат на семинарах и тренингах.

Четвертое, о чем стоит побеспокоиться, – это опыт использования нескольких методологий управления проектами, желательно как минимум одной тяжелой и одной гибкой. Речь идет о реальном использовании методологий на проектах, а не изучении их по книгам. Чем больше методологий знает РМ – тем лучше для его команды. Он сможет выбрать более подходящую методологию для проекта и адаптировать ее под команду и окружение проекта.

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

Наверно, вас, как и меня в свое время, интересует вопрос: «А должен ли руководитель проекта разбираться в предметной области проекта, которым он руководит?». Большинство людей скажет - да. А я не соглашусь. Эти знания не помешают, но они не являются необходимыми. Если руководитель проекта никогда не программировал, это не значит, что он не сможет привести к успеху проект по разработке софта. Ему достаточно найти помощника (технического лидера), который разбирается в программировании, и выстроить с ним доверительные отношения так, чтобы он занимался технической частью проекта, а РМ – командой, план-графиком, бюджетом проекта и т.п.

Пора закругляться, для одной заметки и так многовато получилось букв )

Замечу лишь, что все, что написано в этой заметке, – всего лишь мой личный взгляд на роль руководителя проекта через призму двух десятков проектов, выполненных в этой роли. Если у вас другая точка зрения – я с удовольствием ознакомлюсь с вашими комментариями!

В следующий раз  я планирую поднять тему создания и развития команды проекта. Том самом сложном, но важном навыке руководителя проекта, без которого ему никак не стать успешным.

Удачи вам в проектах, коллеги!

Комментарии (0)
Войти как