Как меняется работа менеджера проекта при переходе от водопада к Agile?

Я сделал переход и помог другим сделать переход (с разной степенью успеха :-)

Изменения высокого уровня:

1. Вы будете больше в роли сервера, чем в роли «капитана корабля» (но у вас все еще есть ответственность и ответственность...)
2. Вы быстро обнаружите, что ваше время на управление делами (например, на отслеживание табелей учета рабочего времени) сокращается.
3. Ваше межведомственное и командное общение (лицом к лицу) резко улучшится
4. Вы будете меньше сосредотачиваться на статусе и больше на проблемах и рисках
5. Вы потратите большую часть своего времени на общение с клиентами или менеджерами по продукту/владельцами в поисках участия, разъяснений и информации.
6. Ваш уровень комфорта будет снижаться до тех пор, пока вы и ваша команда не начнете доверять друг другу.

Многие из них спорны. Я знаю многих людей, которые не откажутся от многих «старомодных» методов управления проектом, даже если команда не находит в них ценности, а методы Agile не поддерживают их с готовностью (Earned Value — отличный пример этого). ) Кроме того, есть Agile PM, которые не очень хорошо взаимодействуют с командой, поэтому решение проблем и «устранение препятствий» перекладываются на другие функции / людей.

Особенности повседневной деятельности трудно обобщить, но... (многие из приведенных ниже предполагают, что Scrum — это ваш Agile-метод)

1. Вы будете участвовать в ежедневных стендап-митингах с командой
2. Вы будете потеть над бэклогом продукта, чтобы убедиться, что он актуален.
3. Вы потратите некоторое время на просмотр (и поддержание) графиков выгорания и выгорания.
4. Вы будете просматривать ретроспективные заметки и вносить предложения для команды по улучшению их процесса.
5. Вы будете организовывать отзывы клиентов о производимом продукте
6. Надеюсь, вы будете сидеть с командой и слушать их обсуждения и использовать свой опыт, чтобы помочь с личными и межличностными проблемами и препятствиями.

ммм!

Во-первых, вы можете взглянуть на очень близкий вопрос о роли PM в agile-проектах .

Затем конкретный переход во многом зависит от типа проектов, которыми вы управляете. Если вы работаете над решением, над которым у вас есть полный контроль, например, над внутренними проектами без платного клиента за пределами организации, вы можете оказаться в ситуации, когда в проектной команде не будет формальной роли PM. Это был бы классический пример внедрения Scrum по правилам. Часто в таких ситуациях PM становится скрам-мастером, но это непростое решение, поскольку скрам-мастер больше коуч, чем руководитель проекта. Другая идея, и лучшая, состоит в том, чтобы перейти к роли владельца продукта, хотя это больше касается работы с продуктом, чем с проектом. В любом случае Scrum распределяет часть обязанностей типичного PM по команде.

Другой тип проектов — это когда у вас действительно есть какой-то внешний клиент, и этот клиент, вероятно, привык запускать проекты более формальным образом. В конце концов, если переход — это что-то новое для вас, то, вероятно, оно будет новым и для ваших клиентов. В этом случае наиболее важной ролью менеджера проекта является трансляция того, как работает команда, клиенту (и наоборот) и заполнение любых пробелов, которые могут быть. Эти пробелы обычно связаны с формальной стороной управления проектами, поскольку agile-команды обычно стараются свести их к минимуму, хотя клиенты иногда ожидают довольно много формальных артефактов. Подробнее о таком подходе можно прочитать в вопросе о слиянии разных подходов PM в рамках одной организации .