Продуктовый подход воплощают собой Agile-пропагандисты, а проектный — последователи PMBOK. В условиях динамичности современного мира и постоянных изменений, нужно быть гибким, чтобы не только быть на плаву, но и чтобы продукт, над которым мы работаем не потерял актуальность к моменту его выхода. Поэтому многие компании переходят на гибкие методологии разработки. Возьмем для примера, скрам и посмотрим, как она относится к проектной деятельности.
Scrum: a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
— Scrum Guide 2017
То есть скрам, как яркий представитель agile-подхода, не является методом управления проектами, а является «фреймворком для решения комплексных проблем в процессе создания и доставки продуктов». Он может использоваться внутри проекта, так же, как и другие agile-методы. С другой стороны, разработка практически любого IT-продукта является проектом, и в вакансиях компаний можно наблюдать запрос на Agile Project Management.
Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов
— PMBOK
Любой продукт, который создает IT-компания уникален, так как он создается с нуля, а не просто копируется.
Откуда берётся противопоставление agile/не-agile проектов или проектного/продуктового подходов?
PMBOK — непростой свод знаний для поверхностного изучения проектного менеджмента. Точнее различный для применения, если мы говорим про разработку сложного интеллектуального ПО или про конвейерную сборку велосипедов на заводе.
Рассмотрим ближе проектное управление как предметную область и что для него свойственно, на примере треугольника управления проектом.
- Треугольник управления ограничения проекта. Суть его в балансе между временем, содержанием и затратами для повышения качества. На практике часто бывает смещение фокуса с создаваемой ценности на ограничения. То есть, успешным считается проект, который попал в границы сроков, не превысил бюджет и в ходе которого были выполнены запланированные работы.
Даже если продукт, получившийся в итоге за время выполнения проекта, потерял свою актуальность. Например, мы построили метро в районе, все жители которого съехали из-за обнаруженной радиации.
- Фокус на ограничениях заставлять этому много внимания еще на старте проекта. Чтобы определить сроки и бюджет, нужно тщательно определить объем, скоуп работ. Это направляет нас на каскадный метод работы.
- В ограничениях срока и бюджета вынуждает мы вынуждены использовать имеющиеся ресурсы очень эффективно, учитывать риски, чтобы прийти к успешности проекта. Приходится абстрагироваться от людей и исполнителей как от индивидуальностей с уникальным набором знаний, умений и характеров, и начать воспринимать их как усреднённых исполнителей. Отсюда мы можем получить ряд заблуждений в этой концепции «люди — ресурсы».
Во-первых, иллюзия о преимуществах разделения труда Адама Смита и фордовского конвейера. Это когда специально обученная группа делает один этап работ. Потом другая группа, заточенная под другую деятельность, делает другой и так далее. Этот подход показал свою эффективность в деле булавок и приготовления гамбургеров, но поможет ли он в разработке программного обеспечения?
Очевидно, что нет.
Выигрыш от повторяющихся процедур убьётся координационными расходами и потерями времени на этапе передачи задачи от команды к команде. Которые в еще более реальной картине будут повторяться, поскольку на каждом этапе будут выявляться проблемы и необходимость изменений и исправлений на предыдущем уровне.
Весьма неплохо рассмотрен миф «масс-продакшена» в видео об упаковке конвертов.
Во вторых, еще одно заблуждение концепции «люди — ресурсы» — необходимость стопроцентной утилизации. Если каждая группа — разработчики, аналитики, тестировщики, задействованы на проекте только треть времени (ведь разработка конкретного ПО — это не непрерывный конвейер), пусть в остальное время трудятся на других проектах. Ну чтобы эффективно использовать доступные ресурсы.
Однако, ввиду того, что ни один проект никогда не шёл по плану, картина в среднем выглядит, скорее, как-то так:
Как результат — борьба за ресурсы, дерганье людей, увеличение буферов запланированных задач и поиск виновных в срывах сроков. Чтобы виновных искать было легче, формируется так называемая матричная структура. Где есть ответственные за функциональные подразделения и исполнителей, а есть руководители проектов.
Итого, почитав PMBOK и попытавшись реализовать проектный подход «наиболее очевидным эффективным образом», получаем:
Фокус на ограничениях:
- ригидность (низкая адаптация к изменениям):-
- возможно, неактуальный продукт на выходе;
- возможно, ненужная работа;
- отношение к людям, как к ресурсам, что, в свою очередь, приводит к новым негативным факторам:
- рост административных расходов;
- медленное развитие людей (рутинные повторяющиеся операции);
- низкая вовлечённость и мотивация;
- низкое качество продукта (вследствие низкой вовлеченности людей с низкой скоростью развития)
PMBOK не заставляет так делать. Но он не проводит четкой разницы между проектом по возведению памятника в парке и проектом по созданию новой операционной системы.
Разница между продуктовым и проектным подходом в целостном подходе. Например, мы сдали проект со статуей в парке. На этом проект окончен. Если нам требуется дальнейшая доработка/модернизация, заказчик может изменится, вместе с ним и вся продуктовая история этой идеи. Разные заказчики могут хотеть разного от этого проекта, здесь нет единения.
Результат проектного подхода - когда мы видим ценность в прибыли от выполнения проекта, а не от развития и поддержки продукта. Обычно проектные команды наследуют от проекта и свой временный характер.
В случае же продуктового подхода мы получаем другую картину. Развивать продукт лучше стабильной в своём составе командой. Продуктовой командой, которая знает от и до, что было с этой статуей, материал, подводные камни с администрацией парка, особенности грунта и т.п. С полным видением будет проще работать над модернизацией продукта для дальнейшего закрытия нужд потребителей.
Тут на помощь к нам приходят agile-методики:
- Кросс-функциональные стабильные команды для сохранения знаний по продукту и повышения эффективности от накопления знаний и навыков, а также наращивания сработанности и транзактной памяти.
- Владелец продукта — единое «лицо принимающее решения», интегрирующее запросы различных заказчиков, пожелания высшего руководства и видение технических архитекторов, возможно частично оформленные в единый road map.
Рекомендую посмотреть это 15-минутное видео про задачи и роль product owner’a.
В проектном методе нет ничего плохого, он имеет место быть.
Но в большинстве случаев важно менять мышление на продуктовое и идти от потребностей пользователя, особенно в условиях неопределенности.