Agile-трансформация
Beyond Budgeting
DevOps
HR
Kanban
LeSS
PMI
Project management
SAFe
Scrum
Scrum-мастер
Бюджетирование
Игра
Конфликты
Обучение
Фасилитация
Применить

Роль Project Manager в Agile-проектах

Профессия Project Manager с распространением гибких подходов теряет актуальность. В Agile-командах руководителям проектов часто нет места. Почему так происходит, где теперь Project Manager применять свой опыт и компетенции, и как меняется их роль.

Роль Project Manager в Agile-проектах

Кто такой Project Manager

Посмотрим на профессию Project Manager на примере IT-компании. Роль руководителя проектов в таких компаниях предполагает большой спектр действий: общение с заказчиком, планирование работ и постановку задач проектной команде, ведение документации, контроль за выполнением задач, соблюдением сроков, мотивация команды, работа с подрядчиками, партнерами и многое другое. Это, безусловно, важная роль при тех подходах к разработке, которые использовались раньше.

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

В чем проблема с такой структурой компании и организацией работ в ней? Основная проблема — это большой time-to-market (время реализации проекта, продукта или инициативы). Одна из основных задач каждого из функциональных менеджеров (руководителей отделов) в такой структуре — это эффективное использование ресурса каждого из отделов. Каждый из сотрудников отдела постоянно загружен работой. Это хорошо с точки зрения сокращения себестоимости работ, но очень плохо с точки зрения скорости реализации проектов, продуктов и инициатив. Подумайте, если сотрудник загружен на 100%, то перед ним образуется очередь из новых задач, которые ожидают выполнения. И так происходит с каждым сотрудником в компании — перед каждым образуются очереди. Соответственно, при появлении новой инициативы, проекта или продукта в компании, задачи падают в очереди каждого из исполнителей, но попадают в них с разными приоритетами: у кого-то с первым приоритетом, у кого-то со вторым, а у кого-то с десятым. В результате, если вы построите временной график выполнения работ по проекту, основанный на данных тайм-трекера, то вы увидите, что основное время задачи вашего проекта простаивали в очередях, вместо того, чтобы находится в работе. Поэтому одна из основных задач руководителя проекта — это «пропихивание» задач в очередях исполнителей и функциональных подразделений.

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

Более того, в угоду скорости внутри такой команды используется самоорганизация, то есть задача организации процесса работы, планирования работ и контроля исполнения распределяется среди участников команды. Иначе вы получаете в команде bottleneck в виде человека, который планирует работы и распределяет задачи среди участников команды.

Взаимодействие с заказчиками и заинтересованными лицами, как правило, также производится самой командой.

Поэтому в компаниях нового типа необходимость в классическом руководителе проектов отпадает.

Project Manager и Agile-разработка

Давайте посмотрим на пример из практики. В одном крупном банке есть CRM-система. Традиционно доработки в этой системе банк отдавал на аутсорс подрядчику. Как с одной, так и с другой стороны для реализации данных доработок были выделены руководители проектов, которые планировали работу и собирали временные команды: как со стороны банка, так и со стороны подрядчика. Доработки в таком режиме реализовывались от 6 до 9 месяцев с момента включения в производственный план. Если мы еще начнем учитывать сколько времени эти доработки простаивали в очереди перед производственным планом с момента появления идеи или потребности, то картина становится еще печальнее.

Для исправления ситуации банк пошел на кардинальные изменения: была собрана стабильная пилотная команда, в которую входят аналитик, архитектор, владелец продукта со стороны банка, разработчики и тестировщики со стороны подрядчика. Сотрудники подрядчика на 100% времени выделены в данный проект и сидят внутри команды на территории банка. Коммуникация с заинтересованными лицами и заказчиками внутри банка происходит напрямую. В итоге тот объем работ, который планировалось по старой схеме сделать за 6 месяцев, такая кросс-функциональная команда реализовала за 2 месяца с учетом дополнительных требований, которые возникли по ходу реализации.

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

Три новых роли руководителя проекта в Agile

Что происходит с ролью руководителя проектов в Agile-командах в различных ситуациях и продуктах? У Project Manager есть несколько путей развития в компаниях, которые используют или начинают использовать Agile.

Владелец Продукта (Product Owner)

Первое направление развития — это позиция Владельца Продукта (Product Owner). Ее может занять Project Manager, который очень близок к бизнесу или сам является выходцем из бизнес-среды. Это человек, который хорошо понимает потребность бизнеса и конечного пользователя, имеет предпринимательский склад ума и может отвечать за максимизацию ценности продукта для потребителей, покупателей и компании. На моей практике такие ситуации встречаются крайне редко, так как зачастую руководитель проектов больше отвечает за поставку проекта или продукта, то есть больше за техническую, чем бизнес-составляющую.

Scrum-мастер

Это человек, который отвечает за создание крутой (самоорганизованной) команды. На этой позиции важно отказаться от старых привычек «делать все самому», чтобы это начала делать команда. Обычно с этой позицией справляются (после хорошей переподготовки) руководители проектов, работавшие в слабой матрице. То есть работавшие со своими проектными командами не напрямую, а через функциональных руководителей. У таких специалистов, как правило, хорошо развиты soft skills, которые позволяют им приводить людей к согласию.

Vendor Manager

Третья роль — это участник Agile-команды, который обладает компетенциями по обслуживанию внешних зависимостей (Vendor Management).

Традиционный руководитель проектов

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

Итоги: Agile, Project Manager и будущее

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

Тенденция к сокращению time-to-market только усиливается. Вероятнее всего, подходы будущего будут своего рода эволюцией Agile, так что «проскочить» этот этап все равно не получится. Потребность в Project Manager в классическом понимании стремительно падает сейчас, и будущее этой профессии видится туманным через 5–10–20 лет. Сейчас самое время принять решение и перейти в новую роль, пока рынок только в процессе изменений. Project Management Institute для таких целей предлагает программу сертификации PMI ACP — Agile Certified Practitioner.

5 июл 2017, Алексей Воронин
Тренинги по теме
Другие статьи
lego1
22 ноя 2017, Сергей Рогачев
Совместное планирование #4

Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 4

lego1
16 ноя 2017, Сергей Рогачев
Совместное планирование #3

Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 3

lego1
11 окт 2017, Сергей Рогачев
Совместное планирование #2

Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 2