Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
KPI
LeSS
OKR
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

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

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

Кто такой 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, Алексей Воронин
Другие статьи
Agile манифест
20 сен 2020, Василий Савунов
Как появился Agile. Часть 3. Призыв

Это завершающая часть статьи про причины появления Agile.

Agile поиски
1 сен 2020, Василий Савунов
Как появился Agile. Часть 2. Поиски

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

agile history
24 авг 2020, Василий Савунов
Как появился Agile. Часть 1. Предтечи

Чтобы исчерпывающе ответить на вопрос «Что такое Agile?», надо сперва понять, в каких исторических условиях он зарождался, какие условия рынка привели к его появлению, и что двигало его создателями. Ничто не появляется “на пустом месте”, всегда есть влияние как прошлого, так и настоящего. Из исторического контекста можно понять логику подхода и применять предложенные им решения с умом, не сваливаясь в карго-культ.