Кто же является главным: Скрам-мастер или Руководитель проекта

Кто же является главным: Скрам-мастер или Руководитель проекта

Перевод статьи " Let’s End the Debate Over Scrum Master versus Project Manager "

Автор статьи - Стивен Старк. Перевод - Евгений Пикулев.

За последние несколько лет состоялось много дискуссий и путаницы относительно роли руководителя проекта в то время как, большинство организаций подвергались Agile-трансформациям. На деле, данные ИТ-индустрии показывают, что примерно 53% организаций смешивают в своей практике методы Agile и Waterfall.

Результатом этих сейсмических преобразований стало то, что руководители проектов стали покидать организации, исчезали целые офисы управления проектами – все это из-за внедрения методологий развертывания Agile. И руководители проектов не одиноки в этом смысле. Введение Agile также значительно повлияло на роль продукт-менеджера так как организации одновременно стремились обосновать роль продукт-оунера.

Я не буду рассказывать вам, сколько я прочел статей и постингов на LinkedIn на эти темы. Наилучший материал на эту тему резюмирует, что руководитель проекта – это НЕ скрам-мастер, и наоборот. Несмотря на то, что описание роли скрам-мастера в подобных дискуссиях дается очень четко, никто не смог подробно и хорошо объяснить как эти две роли (Скрам-мастер и Руководитель проекта) сосуществуют и как началась путаница между этими ролями, поставленная во главу угла.

Если честно, то я никогда не понимал эту дискуссию. Я начал руководить проектами в далеком 2001 году используя XP (Экстремальное Программирование) и никогда не имел проблем с командой относительно путаницы ролей в процессе выполнения проекта. Agile был не вреден – Agile работал. Ну, давайте все-таки переместимся в 2012 год и увидим, что эта дискуссия обостряется. В конце концов у меня закончилось терпение наблюдая эти бесконечные дебаты и я решил ввязаться в драку. Я закончил курсы, прошел тест и стал сертифицированным Скрам-мастером. И после всех потраченных денег и времени я могу с полной уверенностью сказать, что я не скрам-мастер – Я руководитель проекта!

По существу я думаю, что основная причина дискуссии заключается не в противоречии между ответственностью скрам-мастера и руководителя проекта. Причина кроется в фундаментальном определении проекта. В царстве Agile, где существуют минимально определенные фичи, продукт-бэклоги и продолжающаяся интеграция, контуры традиционного проекта теперь стали туманны и расплывчаты. Я отмечаю, что скрам-команда не имеет проблем со своей ответственностью перед продукт-оунером и скрам-мастером, в то время как по некоторой причине, совокупная команда проектане чувствует себя подотчетной руководителю проекта.

Цель написания этой статьи – покончить с путаницей и дискуссией раз и навсегда. Чтобы сделать это, я хочу напомнить вам кто такой руководитель проекта и как эти две роли (Скрам-мастер и Руководитель проекта) должны быть увязаны. Для начала я дам несколько кратких определений, чтобы структурировать свои мысли:

Скрам-мастер : Скрам-мастер фокусируется на процессе разработки и является наставником своей команды. Основные обязанности скрам-мастера следующие:

  • Поддержание ритма и устранение помех
  • Управление процессом Скрам
  • Планирование релиза
  • Планирование спринтов
  • Защита команды от внешних воздействий
  • Содействие проведению скрам-митингов
  • Обеспечение четких и прозрачных коммуникаций между всеми заинтересованными в проекте сторонами

Скрам-мастер, как правило, является лидером команды. Скрам-мастер в идеале должен иметь баланс между следующими навыками:

  • Техническая экспертиза
  • Понимание намерений продукт-оунера
  • Хороший командный игрок и наставник
  • Понимание возможностей команды
  • Хороший мотиватор
  • Решение проблем

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

Проект : Временное предприятие для создания уникального продукта, услуги или результата. В большинстве организаций наши «временные предприятия» определяются через конкретные бизнес-инициативы.

Программа : Серия взаимосвязанных проектов для достижения конкретного результата.

Чтобы быть кратким, роль руководителя проекта – управлять всеми (от идеи до поддержки после запуска) аспектами проекта для достижения ожидаемых результатов, которые ассоциируются с определенной бизнес-инициативой (инвестицией) – не только скрам-команды. Размер, границы и сложность бизнес-инициативы определят объем всего проекта. Достижение осязаемых результатов с учетом инвестиций может потребовать реализации серии взаимосвязанных проектов – это называется программой. В которой, теперь уже руководитель программы подотчетен за управление всеми аспектами своей программы, также как и руководители проектов и другие менеджеры подотчетны за свои меньшие куски проекта.

Прямо сейчас определим четыре возможных категорий «временности» из определения проекта:

  1. Реализация линейки продукта – «Временно» относится к одногодичному циклу планирования. В основном покрывает небольшие улучшения уже существующей линейки продуктов.
  2. Большие проекты, включая разработку новых продуктов.
  3. Внутри продуктовой линейки – специальные «краткосрочные» инициативы/проекты. Например, апгрейд SQL-сервера.
  4. Кросс-функциональные инициативы, в которых задействованы разные подразделения. Например, ребрендинг, переезд центра обработки данных и т.п.

Эти проекты/ «временные предприятия» в большинстве организаций укладываются в эту схему:

Диаграмма 1

Или в эту:

Диаграмма 2

Или в эту:

Круговая диаграмма

Если у вас проект, то руководитель проекта должен быть единственной подотчетной персоной, которая отвечает за все аспекты управления этой работой (или для понимания и управления КАК мы собираемся получить ответы на вопросы в каждом круге вышеприведенной диаграммы). Они не отвечают за ответы на эти вопросы.

Для простого понимания – руководитель проекта отвечает за совокупное управление всеми элементами (блоками диаграмм выше) для того чтобы достичь желаемого в проекте результата. Он может отвечать, а может и не отвечать за управление отдельными элементами (блоков в диаграмме). За реализацию выполнения отдельных блоков отвечают назначенные эксперты.

Как вы видите, разработка по Agile и скрам-команда присутствуют только в одном блоке!

Конкретно, руководитель проекта отвечает за:

  • Понимание желаемых результатов проекта и обеспечение их реализуемости и измеримости. Ему необходимо осознать результаты проекта на основании бизнес-инициативы!
  • Совместную работу с командой по определению объема работы (т.е. каждый закрашенный блок на диаграммах выше, что в нем, какой результат ожидаем), кто отвечает за доставку результата, и когда это произойдет.  Конкретнее:
    o Ресурсы, необходимые для завершения всех работ
    o Назначения ресурсов из других подразделений
    o Оценки для завершения работ и зависимости между отдельными работами
  • Понимание ключевой фигуры каждой функциональной команды, которая будет исполнять работу (каждый закрашенный блок) и как они будут назначены для управления своими работами. Если определены возможности по решению проблем, то такая ключевая фигура должна отвечать за наставничество и решение всех ресурсных конфликтов.
  • Основная задача руководителя проекта – устранить неясность в ролях и ответственности за конкретные задачи путем ясного соответствия ожидаемым результатам и срокам выполнения. Определение взаимозависимостей между результатами и функциональными командами будет лучше определять -  каким образом команды должны быть составлены и в какой период времени, по отношению к совокупному процессу разработки продукта.

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

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

Например, поставки аппаратного или программного обеспечения, инсталляция, конфигурирование – Руководитель проекта, отвечающий за прикладные решения (Application Operation). Или, разработка продукта с использованием Agile – Продукт-оунер/Скрам-мастер.

  • Понимание процессов управления проектом и требуемых инструментов для преобразования входов в выходы в соответствии с бизнес-инициативой.
  • Понимание метрик и процесса достижения показателей проекта в соответствии с этими метриками/целями. Если у проекта есть определенная метрика, чтобы проект завершился в рамках установленного бюджета, то руководитель проекта должен отвечать за использование соответствующих инструментов и процессов, которые требуются для прогнозирования бюджета и отслеживания его выполнения. Руководители проекта НЕ отвечают за создание или разработку этих процессов – конечно если это не рассматривается как отдельный проект!
  • Руководители проектов отвечают за все коммуникации с заинтересованными сторонами в рамках всего проекта (не только в ходе разработки продукта). Они являются единственными полномочными источниками информации для обеспечения понимания ключевых параметров проекта:
    o Содержание
    o Управление стоимостью
    o Сроки реализации
    o Допущения / ограничения
    o Риски / проблемы
    o Ресурсы
    o Качество
    o Исключения
    o Рассмотрение методологии разработки
    o Члены команды, их роли и функции
    o Политики и процедуры

Таким образом, если вы согласны со всем, что написано выше, разве существует почва для дискуссии о функциях двух ролей (Скрам-мастер и Руководитель проекта).

Без вариантов, пройдя обучение скрам-мастера, я не могу быть ответственным за все функции руководителя проекта. Это недостижимо и рано или поздно приведет к неуспешному завершению проекта. Проще говоря, руководитель проекта – это НЕ синоним скрам-мастера. Ключевые функции скрам-мастера – наставничество и наблюдение за работой скрам-команды. Но скрам-мастера не отвечают за все компоненты процесса разработки продукта. В общем, скрам-мастер должен быть подотчетен руководителю проекта в оргструктуре проекта (на диаграмме связь показана пунктиром).

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

По существу, руководитель проекта должен только знать обо всем, что касается хода выполнения проекта, чтобы убедиться в правильных решениях и достигнутом прогрессе выполнения задач по достижению осязаемых результатов. Нереально, чтобы руководитель проекта был в курсе каждого совещания и нюансов каждой отдельной задачи. Однако, им необходимо знать какие совещания произошли и когда ожидаются решения и взаимодействия для обеспечения эффективной работы команды проекта. Естественно, в рамках соглашения об объеме проекта и критериях его успешного завершения.

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

 

  • Открытость поставленным задачам и прозрачность прогресса по задачам
  • Регулярные и постоянные коммуникации
  • Обязательства по достижению критериев успеха
  • Смелость говорить правду
  • Взаимоуважение

Заимствуя описание ответственности скрам-команды перед продукт-оунером и скрам-мастером я адаптировал список функций, как список ответственности совершенной проектной команды перед руководителем проекта:

  • Коммуникации, основанные на приоритезации (и изменении) требований, фич, элементов бэклога спринта, задач
  • Обязательства по достижению результатов к каждой ключевой точке
  • Коммуникации по оценке усилий команды для реализации юзер-сторий (User-Stories) и задач в рамках завершения проекта
  • Коммуникации по обсуждению зависимостей между задачами и членами команды
  • Идентификация рисков и информирование руководителя проекта когда эти риски могут случиться и когда они уже произошли
  • Самоорганизация – отдельные команды в проекте должны быть самоорганизованными и не должны надеяться на директивный стиль руководителя проекта. Однако, самоорганизация означает информирование руководителя проекта по вопросу как идет процесс самоорганизации и когда этот процесс завершится. Руководитель проекта должен создать условия для этого.
  • Команда имеет право делать все необходимое в границах проекта для достижения целей проекта.

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

Рассказать друзьям: