Как известно, в скраме о роли менеджера проекта (Agile PM) не сказано ни слова. Хотя в других гибких методологиях, таких как, например, Feature Driven Development (FDD), роль менеджера проекта (PM) предусматривается, однако его обязанности сводятся к выполнению административных задач по проекту, ресурсному управлению и возможной помощи в координации команды разработчиков. Это, разумеется, является малой часть того перечня обязанностей, которые описаны в руководстве по управлению проектами PMBOK. Например, в соответствии с FDD, эти обязанности отводятся роли менеджера по разработке (Development Manager), а не менеджеру проекта. Менеджер Agile-проекта (далее Agile PM), действуя за рамками тактической роли PM, занимается общей стратегией и координацией проектов. Agile PM дополняет свои кросс-дисциплинарные навыки традиционного PM уникальным умением принимать решения и действовать в контексте стремительных, изменчивых проектах в условиях разработки по гибким методологиям.

Так кто же такой Agile PM и каковы его функции? Можно рассматривать Agile PM как уникального специалиста с весьма специфическим набором навыков, которые позволяют ему/ей владеть, по мере необходимости, частью обязанностей двух или нескольких ролей одновременно. В скраме эти роли могут включать в себя роль владельца продукта (PO) и скрам-мастера, то есть в рамках одного проекта Agile PM может действовать больше как скрам-мастер, а в другом — как PO, в зависимости от потребностей каждого проекта, не в полной мере заменяя, но дополняя работу скрам-мастера или PО. Agile PM использует опыт управления проектами, чтобы помочь обеим сторонам (PO и скрам-мастер плюс команда разработчиков), заполняя пробелы и при этом всегда стремясь к лучшему результату для проекта и выполняя больше работы.

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

Agile PM отвечает за следующие задачи (но не ограничивается этим):

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

В частности, на стороне PO, Agile PM может быть ответственным за проведение вводной встречи, а также за планирование и организацию других совещаний по проекту по мере необходимости. В этой ситуации Agile PM будет отвечать за подготовку и передачу письменных и устных отчетов для членов команды и заинтересованных лиц, а также за обновление и архивирование проектной документации по мере необходимости (например, если проектный офис (PMO) компании требует ведения проектной документации в определенном формате, то для создания таких документов в баклоге должны быть заведены соответствующие истории).

Agile PM может оказывать помощь PO в правильной передаче своего видения команде разработчиков (например, путем создания/поддержания вбаклога продукта с использованием методов оптимизации стоимости (Value Engineering)). Также Agile PM помогает скрам-мастеру быть уверенным, что у проекта есть некто, играющий роль владельца проекта, и что за процессом следят на стороне заказчика, а не только внутри команды разработчиков.

Менеджер проекта Agile в действии

Чтобы полностью понять работу Agile PM, рассмотрим в качестве примера один из недавних проектов одной фармацевтической компании, входящей в список Fortune 50. Компания выполнила разработку программного обеспечения и начальную миграцию данных с помощью распределенной команды разработчиков, состоящей из скрам-мастера и команды, ответственной за выполнения работ из баклога продукта в соответствии с целями спринта. В состав команды входили три программиста с разными специализациями (кодер, веб-дизайнер, специалист по работе с СУБД), один тестер и один архитектор программного обеспечения. В дополнение к удаленной команде разработчиков, владелец продукта и Agile PM, также были частью проектной команды. Проект длился 66 дней и состоял из пяти этапов.

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

На протяжении всех спринтов (продолжительность спринта составила 16 дней) Agile PM играл важную роль в организации проектных коммуникаций, включая организацию ежедневных совещаний с командой, совещаний с клиентом и проверку баклога для обеспечения своевременного завершения частей проекта, которые характеризовались определенным темами (theme), коучинг скрам-мастера с точки зрения способностей предвидеть возможные препятствия. Команды разработчиков, практикующие скрам, верят, что они способны обеспечить контроль над баклогом и доведением задач до завершения. Однако данная команда сделала вывод, что с учетом особенностей географического расположения команды и заказчика, процесс лучше выстраивается выделенным менеджером, отслеживающим выполнение задач.

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

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

В течение следующих 14 дней, команда разработчиков занималась реализацией и участвовала в утренних 15-минутных ежедневных совещаниях (daily scrum meeting). В ходе этих совещаний, Agile PM, с помощью веб-камеры, обсуждал с командой, что было сделано накануне, что будет сделано сегодня и выяснял, какие препятствия возникают по ходу спринта. Agile PM также принимал участие в отдельном ежедневном, 30-минутном совещании с PO, посвященному обсуждению всех препятствий и поискам решений. Последний день каждого спринта был посвящен одночасовой демонстрации. Команда разработчиков представляла клиенту и всем заинтересованным сторонам результаты спринта.

Преодоление географических границ и улучшение коммуникаций

Из-за того, что команда разработчиков и клиент находились в разных регионах (команда разработчиков находилась в Бразилии, в то время как PO находился в Нью-Джерси), Agile PM был ответственным за каждый из спринтов. Стоит отметить, что поскольку команда разработчиков и клиент находились в одном часовом поясе, от Agile PM требовалось меньше усилий по организации коммуникаций.

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

Опыт прошедших этапов и создание репутации

С учётом того, что в скраме обучение в проекте так же важно, как поставка конечного продукта на протяжении всего проекта, команда проводила ретроспективы в конце каждого этапа, во главе с Agile PM, который находился в постоянном контакте со скрам-мастером и командой разработчиков. Целью этих сессий было определение путей улучшения совместной работы, с учетом того, что было, по мнению команды, сделано правильно или неправильно по ходу спринта.

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

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

Понимание успеха

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

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

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

Об авторе

Леонардо Абдала является менеджером проектов, ответственным за agile-проекты с участием Amazon Cloud (AWS), Microsoft, Drupal, а также за мобильные приложения и веб-сайты, совместимые с мобильными устройствами, разрабатываемые компанией Ci&T для своих международных клиентов, в том числе фармацевтической компании, входящей в список Fortune 50, корпорации маркетинга и рекламы, входящей в список Fortune 200 и организации в сфере здравоохранения LOB, входящей в список Fortune 500. Он отвечает за руководство географически распределенными командами разработчиков Ci&T, базирующихся в Бразилии, Аргентине и Китае, и работает с Agile более 5 лет и в рамках PMI более 9 лет. Леонардо имеет несколько сертификатов компании Microsoft (MCP, MCTS, MCPD, MCITP), а также «Certified Scrum Master (CSM)» и «Certified Scrum Professional (CSP)» от Scrum Alliance, а также сертификат «Project Management Professional (PMP)» от PMI. Лео также является профессором колледжа, в настоящее время он находится в отпуске, в Белу-Оризонти, Бразилия. Он имеет степень бакалавра наук (бакалавр) и степень аспиранта в изучении управленческих информационных систем.

Перевод

Савицкий Андрей участвовал в различных проектах в качестве разработчика, архитектора и руководителя проектов. Занимался разработкой автоматизированной банковской системы и интернет-банка для ОАО «Промсвязьбанк». Руководил проектами для Министерства Здравоохранения и Социального Развития. Окончил Московский Государственный Университет Приборостроения и Информатики и аспирантуру по специальности «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных систем».

Владимир Завертайлов
Генеральный директор в Сибирикс

Хорошая статья.

Российские реалии: Разумно считать, что Product Owner-ов на стороне заказчиков сейчас не бывает. Особенно в корпоративном сегменте.

Там же надо брать ответственность, быстро принимать решения, обладать достаточным временем, компетентностью, видением... И самое главное — не на кого свалить, если fuckup. Перебирал в уме, вспоминал — ну может быть 2-3 человека за последний год. И то — скорее исключение.

С этим нужно что-то делать, и поэтому из кустов появляется PM. В нашем случае его основной задаче является проксирование заказчика (или его команды). Proxy Product Owner.

Делает он все то же, что и должен делать Product Owner в классическом Agile. Но агрегируя требования от клиента. Иногда — самостоятельно их интерпретируя (или помогая интерпретировать клиенту). PM так же существенно влияет на приоритеты — по сути, он предлагает изначальный ход проекта. Однако PM не вмешивается в сферу деятельности команды, например — распределение задач.

Юрий Гугнин
Управляющий партнер в Бизнес-школа РИК

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

Однако, при прочтении статьи у меня на секунду промелькнула мысль о том, что автор рекомендует применять Agile PM в роли скрам-мастера. На всякий случай заострю на этом внимание, потому что некоторые читатели могут случайно принять это как руководство к действию.

Я считаю, что в Agile менеджеру проекта опасно быть скрам-мастером, потому что у менеджера в силу его роли есть свои интересы в проекте. Мало того, эти интересы подвержены постоянным колебаниям из-за потока изменений, свойственного Agile-проектам. Это ведет к тому, что менеджер будет отклоняться от процесса вплоть до полного отказа от него, не говоря уже о том, чтобы выделять свое время на совершенствование процесса, на то, чтобы посмотреть на него со стороны. Именно поэтому скрам-мастером должен быть отдельный человек, который находится над конкретным проектом.