Еще до того, как Agile был повсюду, наличие менеджера по проектам во всех проектах, кроме небольших, считалось необходимым. Теперь только в самых крупных проектах есть люди, назначенные только в качестве PM.
Я предполагаю, что у меня есть две части этого вопроса: для каких проектов по-прежнему требуются менеджеры проектов? Что могут сделать менеджеры проектов, чтобы повысить ценность в гибком мире?
Я уверен, что вы слышали народную поговорку:
Процессы не дают сбоев, это делают люди
Я всегда считал, что менеджеры проектов нужны, когда у вас есть среда, в которой «процессы» слишком сильно терпят неудачу. В agile у вас есть много итераций, называемых спринтами, которые решают список улучшений или дефектов.
Первое место, где я вижу, что PM добавляют ценность:
Важно убедиться, что у вас есть правильный процесс для записи, отслеживания и определения приоритетов списка функций, над которыми вы собираетесь работать в следующем спринте.
Кроме того, продакт-менеджеры помогают свести к минимуму перерывы в работе разработчиков, если только у вас нет бизнес-аналитика, который в конечном итоге выполняет часть работы продакт-менеджера или наоборот.
Менеджеры по проектам также могут добавить ценность, следя за тем, чтобы разработчик не переплачивал и не недоделывал, что является очень распространенной проблемой среди неопытных разработчиков. Tangent: Разработчики в душе архитекторы, они хотят решать проблемы, не ожидайте, что они будут часто говорить «нет».
Сказав все это. Важно помнить, что ПМ стоят дорого. Вы должны убедиться, что ваша фирма может их поддерживать. В долгосрочной перспективе вы можете увидеть значение PM в течение первых 90 дней.
Надеюсь, это поможет вам прояснить вопросы.
В agile есть своя роль для PM, но PM должен быть готов принять тот факт, что не все проекты могут выполняться так, как раньше. Agile — это метафора принятия изменений, и менеджеры проектов должны использовать их в своей профессии.
Вероятно, на 75% я работаю менеджером по проектам, а остальные 25% я выполняю в качестве дизайнера, архитектора, тестировщика, главного мойщика бутылок и так далее. Я работаю исключительно над тем, что люди считают небольшими проектами — от 2-3 до 10 технических специалистов. Большинство наших проектов являются «гибкими», и я чувствую, что моя роль менеджера проектов важнее и ценнее, чем когда-либо. Просто возьмем приведенный выше пример Гео: спринты — это популярная техника управления тайм-боксингом, популяризированная Scrum , но, возможно, не лучший выбор для каждого проекта. PM должен уметь работать с командой и объяснять заказчику, будет ли проект X использовать «спринты» или какой-либо другой метод тайм-боксинга , или, может быть, даже фич-боксинг.
Большинство проектов не являются «чисто гибкими» или «чисто ориентированными на планирование». Я никогда не работал над проектом, который рабски придерживался бы какой-либо единой методологии процесса. Хороший Agile PM должен знать, как использовать множество техник, моделей и методов, чтобы создать проектную команду, которая работает гладко и эффективно в среде своей организации.
Agile не означает «без управления проектами», в agile-проектах происходит много управления, просто в agile -проектах больше внимания уделяется различным артефактам проекта, чем в традиционных проектах, управляемых планом. У гибкого PM все еще есть много возможностей для работы с отдельными людьми и взаимодействиями , а не с процессами и инструментами, сотрудничеством с клиентами , а не обсуждением контрактов, и реагированием на изменения , а не следованием плану.
Чтобы ответить на этот вопрос, я бы начал с разграничения руководителя проекта как роли, одной из важнейших даже в проектах с одним человеком , и менеджера проекта как титула.
Теперь у вас в основном всегда будет человек или группа из них, которые выполняют роль менеджера проекта , однако это совершенно нормально, если ни один из них не имеет в своей подписи «менеджер проекта».
На самом деле, в отличие от других, я не считаю наличие PM решающим фактором в agile-проектах. Если мы возьмем Scrum, который является самым популярным agile-методом, мы нигде не найдем руководителя проекта. Это связано с тем, что роль управления проектом в Scrum распределена по всей команде, с какой-то особой позицией владельца продукта.
Это означает, что Scrum-команды, особенно более опытные, могут прекрасно обходиться без того, кого называют менеджером проекта.
Примечание: я использую Scrum только как один из примеров — я знаю команды Kanban, которые также следуют той же схеме.
Обычно причиной введения менеджера проекта в agile-команды является то, как заказчик хочет запустить проект. Если agile-команда работает с клиентом, который предпочитает, чтобы проект управлялся классическим или формальным, или как вы это называете, вы, вероятно, захотите, чтобы на вашей стороне был менеджер проекта — кто-то, кто будет переводить то, как работает команда, в то, как она работает. клиент хочет это видеть.
Если agile-команда может работать напрямую с клиентом, используя нужные им методы, например, владелец продукта на стороне клиента, демонстрация после каждой итерации, активное участие клиента в определении приоритетов работы для каждой итерации и т. д., вы, вероятно, не найдете менеджера проекта в такой ситуации. команда.
Еще одна причина ввести менеджера проекта в agile-команды — это когда ваша организация по каким-то причинам хочет, чтобы проекты выполнялись классическим способом. С другой стороны, вы можете захотеть, чтобы PM был на вершине команды, чтобы у вас был кто-то, кто соединяет оба мира.
Это самая важная задача менеджера по проектам в agile-командах — наводить мосты, поскольку некоторым командам эти мосты нужны для преобразования их собственных методов работы во что-то, чего ожидают за пределами команды. Это естественно, поскольку гибкие методы мало что говорят нам о формальной стороне управления проектами, поэтому они не оправдывают ожиданий всякий раз, когда это необходимо.
ОБНОВЛЕНИЕ: Крис добавил в комментарии одну вещь, на которую стоит обратить внимание и которая не была указана прямо: PM в agile-командах в меньшей степени относится к типу командования и контроля, поскольку право принимать многие решения, связанные с проектом, делегируется команде. Я бы не стал заходить так далеко, чтобы сказать, что Scrum Master — это гибкая версия PM, потому что это не так, но, тем не менее, если вы считаете, что у команды больше власти, у кого-то она должна быть меньше, и обычно это PM.
Руководители проектов — это люди, которые устраняют барьеры. На этих встречах схватки разработчики отвечают на вопрос: «Что мешает вам достичь ваших целей и какие у вас проблемы?». Работа менеджера проекта состоит в устранении этих барьеров и устранении препятствий на пути к успеху.
Руководители проектов также являются мастерами на все руки. У них есть навыки программирования, маркетинговый и деловой опыт, они могут общаться с клиентами и заинтересованными сторонами и быть убедительными, когда необходима поддержка со стороны руководства, команды или других отделов.
В agile менеджеры проектов важны, потому что среда постоянно меняется и постоянно возникают новые проблемы. Менеджер проекта может не только держать все вместе, но в процессе также знакомится со всеми аспектами проекта, чтобы принимать наилучшие, обоснованные решения относительно его будущего направления.
«Управление проектами» происходит, когда группа людей создает какой-либо продукт или услугу с ограниченным количеством времени и ресурсов. «Менеджер проекта» — это тот, кто отвечает за применение инструментов и методов управления проектами к управлению проектами.
Если нет явно определенной роли менеджера проекта, то инструменты и методы применяются кем-то другим или не применяются вообще.
Таким образом, ответ заключается в том, что для каждого проекта требуется руководитель проекта .
В Agile-поставке продукта нет роли менеджера проекта (определяемой Prince2/PMI). Это связано с тем, что традиционные обязанности менеджера проекта (называемые управлением проектами) разделены между следующим:
Я использую терминологию Scrum, так как ее приняли более 90% тех, кто занимается Agile. Обратите внимание, что Agile Project Manager, также придуманный в Prince2 и PMI, является оксюмороном, и его следует избегать. Это волк, одетый в овечью шкуру, и он, скорее всего, окажет негативное влияние на ваш продукт. (См. отчет Standish Group о хаосе, в котором обнаружена обратная связь между практикой PMI/Prince2 и ценностью, предоставляемой клиентам.)
Чтобы облегчить переход от традиционной разработки программного обеспечения к гибкой разработке программного обеспечения, вашей организации необходимо перейти от концепции проекта к концепции продукта. Это очень важно для создания отличных продуктов, отвечающих потребностям ваших клиентов, и является одним из самых сложных переходов для организации.
Дэмиен Роше
Аль Биглан
MrHinsh - Мартин Хиншелвуд