Автор: Карлтон Неттлетон (Carlton Nettleton)
Переведено с английского проектом Agile Translations.
Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(
Когда я первый раз прочитал это сообщение, я задался вопросом: "А кто же такие Аджайл Менеджеры Проектов?” Поэтому я решил поискать различные статьи о том, когда этот термин появился (примерно в начале 2008) и почему компании отдают предпочтение им, а не Скрам-мастерам.
Лично я никогда не понимал, почему кто-то вообще берет на себя такую ответственность. Обычно менеджеры проекта не занимаются непосредственно разработкой, так как они могут отвечать за качество или сроки? Менеджеры проекта не определяют бизнес-цели, так как они реально могут управлять границами проекта? И должны ли они в принципе принимать решения по границам проекта, если бизнес-область подвержена постоянным стремительным изменениям? Менеджеры проекта обычно не являются функциональными менеджерами, так как они могут отвечать за персонал или его производительность? Я понимаю, что, возможно, Институт управления проектами (PMI) хочет определить роль менеджера проекта именно так, но я тоже много чего хочу, например, чтобы у меня был пони, но это не значит, что я действительно собираюсь его покупать.
Из своего опыта, я склонен считать, что менеджеры проекта и Скрам часто взимоисключают друг друга. Если вы читали Кена Швабера, то он говорит нам о том, что менеджеры проекта нарочно не были добавлены в Скрам. По его мнению, менеджеры проекта пагубно влияют на умственную работу, а также снижают творческий потенциал и интеллект команды (мне кажется, я слышу дружное “Гип-гип-ура!” от людей, поддерживающих данное высказывание, и не менее дружное “Что за бред!” от людей, которые не согласны с Кеном). Строгое следование определению менеджера проекта по версии PMI, скорее всего сделает из менеджера либо человека, который говорит людям, как нужно делать их работу, либо няньку для проектной команды. Оба варианта крайне негативно воспринимаются высококвалифицированными профессионалами и сводят на нет уважение, доверие и самоорганизацию в команде, а также принятие командой обязательств и фокусирование на главном. Когда люди говорят мне, что их компания сократила Скрам-мастеров в пользу Аджайл Менеджеров Проектов, то мне становится очевидно, что в компании хотят обозначить одного определенного человека, которого можно обвинить в случае неудачи проекта.
Разумеется, было бы хорошо посмотреть на схему, увидеть чье-то имя в рамке наверху пирамиды и сказать “Конечно же … Карлтон. Вот причина провала проекта – плохой менеджер.” Это было бы просто замечательно (также, как и иметь пони), но далеко не всегда это соответствовало бы истине. Проекты терпят неудачу по многим причинам. Среди них довольно много факторов, которые я называю начальными условиями проекта: как был начат проект (нехватка времени или ресурсов), отсутствие доступа к лицам, уполномоченным принимать решения, или организационные ограничения, такие, как бюрократия и ориентированность на неудачи.
В Скраме мы полагаемся на самоорганизованные команды, которые выполняют всю работу и несут ответственность за качество продукта, коммуникацию в проекте и технический риск. Владелец Продукта отвечает за бизнес-риски, коммуникацию с заинтересованными лицами, стоимость и границы проекта. Хотя Скрам и не предполагает выделенной роли менеджера, в сложных или очень больших проектах все же необходимо выполнять некоторые управленческие обязанности. Такие менеджерские активности, как работа с персоналом, закупки, общение с представителями бизнеса будут выполнены наилучшим образом в случае наличия в команде кого-то с первостепенной функцией – менеджер. Однако, обратите внимание, что этот человек должен не управлять командой, а лишь заботиться о выполнении определенных управленческих активностей.
Переведено с английского проектом Agile Translations
Алина Проскурина, Дарья Ершова, Тимофей Евграшин
Оригинальная статья: "What is an Agile Project Manager?" by Carlton Nettleton
Переведено с английского проектом Agile Translations.
Когда я первый раз прочитал это сообщение, я задался вопросом: "А кто же такие Аджайл Менеджеры Проектов?” Поэтому я решил поискать различные статьи о том, когда этот термин появился (примерно в начале 2008) и почему компании отдают предпочтение им, а не Скрам-мастерам.
- Что такое “Аджайл Менеджмент Проектов” – краткое описание от Майка Кона (Mike Cohn) в основном совпадает с официальной версией Скрама о менеджменте в Скрам-командах.
- Управление проектами по гибкой методологии – VersionOne дает свое определение Аджайл Менеджеру Проектов и приводит много доказательств в пользу своей точки зрения. Однако, это неудивительно, если учесть тот факт, что VersionOne разрабатывает и продает программные продукты для менеджеров, работающих по гибкой методологии.
- “Почему Аджайл Менеджер Проектов – это секретный компонент успеха проекта” – в этой статье на InfoQ Леонардо Абдала (Leonardo Abdala, @leonardoabdala) объясняет, почему он считает, что большие проекты нуждаются в Аджайл Менеджере Проектов, основываясь на своем опыте с распределенными командами.
- Профессионал по управлению проектами (PMP) против Аджайл Менеджеров Проектов: Столкновение Титанов – в этой статье на сайте Scrum Alliance Хуан Банда (Juan Banda, @juanbandajara) сравнивает сертифицированных PMP (по определению PMI – Института по управлению проектами) с Аджайл Менеджерами Проектов.
- Гибкость и Институт по управлению проектами (PMI) – также существует мнение Кена Швабера (Кеn Schwaber), основанное на его многолетнем опыте применения и внедрения Скрама вместе с Джеффом Сазерлендом (Jeff Sutherland) .
Лично я никогда не понимал, почему кто-то вообще берет на себя такую ответственность. Обычно менеджеры проекта не занимаются непосредственно разработкой, так как они могут отвечать за качество или сроки? Менеджеры проекта не определяют бизнес-цели, так как они реально могут управлять границами проекта? И должны ли они в принципе принимать решения по границам проекта, если бизнес-область подвержена постоянным стремительным изменениям? Менеджеры проекта обычно не являются функциональными менеджерами, так как они могут отвечать за персонал или его производительность? Я понимаю, что, возможно, Институт управления проектами (PMI) хочет определить роль менеджера проекта именно так, но я тоже много чего хочу, например, чтобы у меня был пони, но это не значит, что я действительно собираюсь его покупать.
Из своего опыта, я склонен считать, что менеджеры проекта и Скрам часто взимоисключают друг друга. Если вы читали Кена Швабера, то он говорит нам о том, что менеджеры проекта нарочно не были добавлены в Скрам. По его мнению, менеджеры проекта пагубно влияют на умственную работу, а также снижают творческий потенциал и интеллект команды (мне кажется, я слышу дружное “Гип-гип-ура!” от людей, поддерживающих данное высказывание, и не менее дружное “Что за бред!” от людей, которые не согласны с Кеном). Строгое следование определению менеджера проекта по версии PMI, скорее всего сделает из менеджера либо человека, который говорит людям, как нужно делать их работу, либо няньку для проектной команды. Оба варианта крайне негативно воспринимаются высококвалифицированными профессионалами и сводят на нет уважение, доверие и самоорганизацию в команде, а также принятие командой обязательств и фокусирование на главном. Когда люди говорят мне, что их компания сократила Скрам-мастеров в пользу Аджайл Менеджеров Проектов, то мне становится очевидно, что в компании хотят обозначить одного определенного человека, которого можно обвинить в случае неудачи проекта.
Разумеется, было бы хорошо посмотреть на схему, увидеть чье-то имя в рамке наверху пирамиды и сказать “Конечно же … Карлтон. Вот причина провала проекта – плохой менеджер.” Это было бы просто замечательно (также, как и иметь пони), но далеко не всегда это соответствовало бы истине. Проекты терпят неудачу по многим причинам. Среди них довольно много факторов, которые я называю начальными условиями проекта: как был начат проект (нехватка времени или ресурсов), отсутствие доступа к лицам, уполномоченным принимать решения, или организационные ограничения, такие, как бюрократия и ориентированность на неудачи.
В Скраме мы полагаемся на самоорганизованные команды, которые выполняют всю работу и несут ответственность за качество продукта, коммуникацию в проекте и технический риск. Владелец Продукта отвечает за бизнес-риски, коммуникацию с заинтересованными лицами, стоимость и границы проекта. Хотя Скрам и не предполагает выделенной роли менеджера, в сложных или очень больших проектах все же необходимо выполнять некоторые управленческие обязанности. Такие менеджерские активности, как работа с персоналом, закупки, общение с представителями бизнеса будут выполнены наилучшим образом в случае наличия в команде кого-то с первостепенной функцией – менеджер. Однако, обратите внимание, что этот человек должен не управлять командой, а лишь заботиться о выполнении определенных управленческих активностей.
Переведено с английского проектом Agile Translations
Алина Проскурина, Дарья Ершова, Тимофей Евграшин
Оригинальная статья: "What is an Agile Project Manager?" by Carlton Nettleton