Роль Проджект-менеджера в Agile-компаниях

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

Функциональная оргструктура

Функциональная структура, как следует из названия, собрана вокруг функций. Есть команда маркетологов с лидом во главе, есть команда мобильных разработчиков, веб-разработчиков и так далее. Каждый отдел сфокусирован на своей области компетенции, что упрощает работу по поддержке текущего бизнес-процесса. В функциональной структуре все люди — «винтики» и делают только какое-то одно действие. Общей картинки они, как правило, не видят и не заинтересованы в улучшении продукта. Это обязанность вышестоящих менеджеров.

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

Под каждый проект нужно выделить людей, часто задействовать их на какой-то процент их времени, что само по себе создает сложности в управлении такой командой. Кроме того, необходимо согласовать бюджеты, что требует усилий и времени, а также выделить руководителя проекта и запустить команду, а значит «выдернуть» их из текущей деятельности. Не говоря уже о том, что каждый раз у нас добавляется новая организационная единица. И если проектов много (а в более-менее крупной функциональной организации таких изменений одновременно могут быть десятки), ими становится довольно сложно управлять.

Функциональная оргструктура с теми или иными особенностями долгое время была доминирующей ввиду простоты масштабирования, прозрачной структуры ответственности и разделения труда. Но со временем описанные выше недостатки стали перевешивать плюсы, особенно в IT. Изменения производились медленно ввиду зависимостей между разными инициативами, люди разрывались между основной деятельностью и проектами. Руководитель одного проекта зачастую не знал, что происходит в другом, а их цели могли вступать в конфликт. 

И проектное управление стало ассоциироваться со всеми этими недостатками. Хотя по факту проектный подход как инструмент в этом не виноват. Проблема заложена в самой организационной структуре, так как она заставляет тасовать ограниченные ресурсы, создавая иллюзию, что все под контролем и мы все успеем. Ведь проценты выделения людей на проекты обозначены, сроки поставлены, менеджеры назначены – что может пойти не так? Оказывается, практически всё, начиная с прозрачности реализации проектов и заканчивая попаданием в срок и конечной ценностью, которую этот проект принесет.

Продуктовая оргструктура

Одним из решений этих проблем может являться продуктовая оргструктура (это не единственное решение и не единственный тип структуры, но о других мы поговорим в других статьях – прим. автора). Команды в продуктовой компании строятся не вокруг функций, а вокруг продуктов. Это кросс-функциональные подразделения, фокусирующиеся на создании конечной ценности. Сотрудники в таких командах – не «винтики», делающие кусочек большой задачи, при этом не видя результата. Они знают цель и несут ответственность за её достижение.

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

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

Проекты в продуктовой компании

Agile и переход на продуктовую оргструктуру снижает потребность в проектах и руководителях проектов, но не закрывает их на 100%. Как бы вы ни «нарезали» вашу организацию, у вас всё равно в какой-то момент появится необходимость во взаимодействии между продуктовыми, канальными или ещё какими-то подразделениями. И часть из них решается при помощи проектов.

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

В некоторых случаях имеет смысл реализовывать такую инициативу не по проектной логике, а по продуктовой. Ведь поддержка и развитие того же ЭДО может вполне превратиться во внутренний сервис – подразделение, которое на постоянной основе оказывает какую-то услугу другим отделам. Если ЭДО требуется не только однократно внедрить, но постоянно поддерживать и развивать, то проектная логика с ограниченным скоупом и дедлайном уже не подойдёт. 

Возьмём другой пример — внедрение единой CRM-системы. Основные пользователи CRM-системы – продуктовые и канальные подразделения. И конечно, они должны иметь возможность работать с CRM в будущем как с продуктом: самостоятельно развивать и вносить изменения в него через бэклог продукта. Но прежде чем развивать, нужно сначала выбрать, купить коробочное решение или разработать свою систему, развернуть и связать с другими системами, а может, даже и мигрировать из старой системы в новую. Всё это логично упаковать в проектную логику, ведь у нас есть не только понятный скоуп задач, дедлайн, но и множество рисков, за которые отвечает Менеджер проекта.

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

Что происходит с Менеджерами проектов после Agile-трансформации?

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

Scrum Master

Если в компании применяются Agile-подходы (Scrum, LeSS, SAFe® или Nexus), опыт и навыки руководителей проектов будут полезны для роли Скрам-мастера. В первую очередь это создание и развитие команды, а также навыки управления процессами. Опыт планирования и управления рисками будет бесценен для совместной работы с командой и Владельцем продукта.

Release Train Engineer

Во фреймворке SAFe® есть также роль Release Train Engineer (RTE) – человек, ответственный за поставку ценности в контуре целого продукта на большое количество команд. Он общается с заинтересованными лицами, эскалирует решение проблем на руководителей более высокого уровня, помогает управлять рисками и активно драйвит развитие подразделения. Опыт управления масштабными проектами с большим количеством зависимостей и участников поможет освоить эту роль.

Владелец продукта (Product Owner) и Владелец канала

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

Это довольно редкий сценарий, так как в классическом понимании роли Менеджер проекта больше отвечает за техническую поставку результата и управление ограничениями. Формулирование ценности возложено на ключевого заказчика (Спонсора/Куратора проекта).

Роль Владельца канала близка к Владельцу продукта по набору навыков. Он также отвечает за максимизацию ценности, только за счёт развития канала продаж и/или коммуникации с пользователем. Эта роль актуальна, когда у продуктовой компании несколько отличных по клиентскому пути каналов взаимодействия с клиентами. Владелец канала отвечает за привлечение, конверсию и клиентский опыт в канале. 
В разных подходах роль Владельца продукта может различаться. Подробнее описано в статье Владелец продукта во фреймворках масштабирования: LeSS, Nexus, SAFe®.

Менеджер команды

В компаниях, где не используется Scrum или иная гибкая методология, также встречаются роли, близкие к роли Скрам-мастера. Они могут называться по-разному, например Лидер команды\Тимлид, Менеджер команды (в Prince2 Agile) или Delivery Manager. Человек на этой роли отвечает за построение эффективного процесса и за развитие команды.  

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

Менеджер, в сфере ответственности которого находится процесс поставки на большое количество команд, часто называется Delivery Manager. У него в подчинении могут находиться несколько команд и их руководители. Эта роль схожа по области ответственности с ролью RTE в SAFe®.

«Менеджер Agile-проектов»

Когда в данной статье мы говорим о «проектном и продуктовом подходе», имеются в виду единицы управления. Однако часто в сознании людей «проект» ассоциируется с предиктивной (водопадной) логикой, а «продукт» – с итеративно-инкрементальным (Agile) подходом. Этот стереотип неверен, ведь согласно PMBoK проекты могут реализовываться по итеративно-инкрементальному или гибридному жизненному циклу. Выбор жизненного цикла не зависит от того, заводим ли мы проект или идёт работа в рамках продукта, а зависит только от уровня неопределённости и особенностей создаваемого продукта. Согласно данным исследования «Agile в России», которое мы проводим в течение нескольких лет, во многих компаниях, которые адаптируют Agile-подход, сохраняется роль Менеджера проекта.

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

Таким образом, во многих компаниях семейство Agile-методологий заняло нишу «ещё одного инструмента для реализации проектов». Теперь при запуске проекта определяется жизненный цикл проекта – классический или гибкий – и выбирается методология и соответствующая ролевая модель. 

На практике Менеджер проекта вместе с Куратором проекта и/или Заказчиком определяют, можно ли реализовать содержание проекта по классическому предиктивному жизненному циклу, итеративно-инкрементальному циклу или даже по какому-то гибридному для достижения максимального результата.

Если в проекте достаточно понятны и конечная цель, и способ её достижения, например, строительство склада, то Менеджер проекта приступает к сбору требований и далее к анализу, расчёту бюджета и его согласованию. Но если в той же компании требуется автоматизировать работу этого же самого склада, то Agile-подход подойдёт значительно лучше. В таком проекте гораздо выше риск упустить требования и получить множество ошибок при интеграции, от чего нас смогут уберечь короткие циклы обратной связи и небольшие релизы. В таком проекте Менеджер проекта с высокой долей вероятности возьмёт на себя роль Скрам-мастера или Менеджера команды, а Заказчик или Куратор – Владельца продукта.

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

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

Заключение

Необходимость в проектах как объекта управления в продуктовых организациях нередко сохраняется, даже если применяются Agile-практики. Сохраняется и роль руководителя проекта. 

Когда компания в «чистом виде» применяет Scrum, LeSS, SAFe® или иные стандартные гибкие подходы, потребность в роли Менеджера проекта снижается. В этом случае Менеджеры проектов применяют свои навыки и опыт руководства проектами в других ролях: Скрам-мастер, RTE, Delivery Manager, Владелец продукта.

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

1. компания, которая в силу своего небольшого размера или иных причин не решается на изменение оргструктуры и соответствующие расходы;
2. IT-интегратор, консалтинговая или иная компания, выступающая в роли подрядчика; 
3. проекты внедрения каких-либо систем внутри компании (например, CRM).

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