Роль Проджект-менеджера в Agile-компаниях
Продуктовый подход и продуктовая организационная структура не отменяют и не запрещают использование такого инструмента как проекты, несмотря на противопоставление продуктов и проектов в Agile-сообществе и литературе (#NOPROJECTS, From Project to Product).
В 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 и подобных гибких подходов часто используется проектный подход, а роль менеджера проекта сохраняется с незначительными изменениями. Например, в следующих ситуациях:
- компания, которая в силу своего небольшого размера или иных причин не решается на изменение оргструктуры и соответствующие расходы;
- IT-интегратор, консалтинговая или иная компания, выступающая в роли подрядчика;
- проекты внедрения каких-либо систем внутри компании (например, CRM).
В последнем случае компания вполне может иметь продуктовую оргструктуру. Это не запрещает вести подобные работы как проекты, а не как продукты. Тем не менее в продуктовых компаниях проектов намного меньше, а потребность в роли Менеджера проектов ниже.

В этой статье разбираемся, что на самом деле значит «дать команде полномочия», и какие условия необходимо создать руководителям, чтобы это работало.

Если команда задается вопросом «Зачем нам эти daily?», вероятно, ваш Daily Scrum напоминает скорее скучный круговой отчет, чем живую синхронизацию. Но есть способ сделать встречу полезной. В статье рассказываем, как помочь команде включиться в обсуждение и ясно видеть прогресс на пути к цели спринта.

Жесткие сроки и гибкий Agile – вечный конфликт? Не обязательно. В статье расскажу, как превратить вашу Scrum-команду в предсказуемую силу.