Помогите мне совместить мою должность руководителя проекта с выполнением ролей скрам-мастера

Я PMP, и меня назначили на проект по разработке программного обеспечения, и я получил звание менеджера проекта. Для этого проекта нет технического менеджера проекта, и это сбалансированная матричная организация, где надо мной есть портфельный менеджер, и моя команда назначена на полный рабочий день для этого проекта, где я выступаю в качестве их функционального менеджера (хотя технически мой начальник является их менеджером). босс).

Я занимаюсь типичными для ПМ задачами, такими как управление элементами объема работ, согласование рабочих элементов с BRD/SRS, отправка запросов на изменение и обеспечение соблюдения сроков. Тем не менее, мы работаем в гибкой манере с двухнедельными спринтами, и команда пытается вести себя как можно более «схваточно». Это означает ежедневные скрамы, расставленные по приоритетам невыполненные работы, встречи по планированию спринта и т. д. Однако в скраме роль менеджера проекта не существует, и в некотором смысле роль менеджера проекта противоречит идее скрама, поскольку многие PMI-измы построен на концепции модели водопада. Мы также делаем некоторые вещи, не связанные со схваткой, например, произвольно распределяем невыполненные работы на несколько спринтов вперед, чтобы «знать, что произойдет», и дать руководству план на будущее.

Как можно описать это расположение? Что происходит, когда менеджера проекта помещают в скрам-команду? Это действительно просто работает по-agile, поскольку мы не придерживаемся точных правил схватки, поэтому мы не можем так это назвать? (как игристое вино, сделанное за пределами Шампани, Франция)

TBH Я бы меньше беспокоился об описании (или даже о том, насколько вы придерживаетесь процесса), а больше о менталитете, гибких целях и культуре в более крупной организации. Можете ли вы предоставить больше информации о том, кто или что движет переходом к большей гибкости и использованию схватки? При этом мне любопытно, кто или что выполняет роль Владельца Продукта/Управления Продуктом — прокси для пользователей, понимание предметной области и конкурентов, определение и распространение видения продукта, расстановка приоритетов в отношении ценности для пользователя и т. д.
Я думаю, что сердце каждого находится в правильном месте, но это «падение скрамеров», и вы действительно не можете полностью совместить две роли. Бонус за то, что вы делаете все возможное в плохой ситуации!
Я определенно думаю, что это тот случай, когда руководство хочет быть модным и крутым с помощью Scrum, но когда мы интернациональная команда с более чем 50 членами команды, такого понятия, как Scrum, на самом деле не существует. @JeffLindsey Я в некоторой степени выполняю роль владельца и определенно управляю продуктом. Мы производим программное обеспечение для клиента, и этот клиент участвует в нашем еженедельном совещании по планированию спринта, во всех наших обзорах дефектов, и они разрабатывают функциональность параллельно с нами (но для других функций).
@BrianR - на самом деле вы можете быть довольно неряшливым с большими распределенными командами, но это определенно требует больше работы и еще более глубокого согласования и ясности в отношении причин, целей и т. Д. Мой совет: получить хороший коучинг с реальными историческими результатами . вокруг распределенных команд, организационного дизайна/ценностей и, возможно, даже домена вашего продукта. Я видел, как в таких ситуациях организации «действовали в одиночку», и обычно это просто превращалось в своего рода застойную схватку, в которой плюсы и минусы компенсируют друг друга, и, как вы указали, нет простых ориентиров для движения вперед. больше.

Ответы (6)

Я работал менеджером проекта, скрам-мастером и менеджером проекта над тем, что в общих чертах называют скрамом.

Как вы правильно заметили, есть большая разница между тем, как вы работаете менеджером проекта и скрам-мастером. Вероятно, самое важное отличие заключается в том, что Scrum-мастер — это не менеджер, а лидер-слуга. Это принципиальное и непримиримое различие.

Сказав это, можно иметь звание менеджера проекта, но взять на себя роль скрам-мастера. Самая большая проблема будет не с командой, а с вашими отношениями с руководством и людьми, не входящими в команду. Придет время, когда руководство потребует чего-то, чего они справедливо ожидают от менеджера проекта, но чего скрам-мастер никогда не сделает.

Один из возможных подходов — взять на себя роль Скрам-мастера и потратить некоторое время на обучение менеджеров и тех, кто не входит в команду, тому, как работает Скрам. Если вы сделаете это и у вас будет непредубежденное руководство, вы сможете создать успешную команду Scrum.

Если мы сосредоточимся на ролях, а не на должностях, а PM также будет ролью с действиями, то вы поймете, что Scrum разделяет традиционное командное PM на PO и SM. PO управляет Продуктом, в то время как SM управляет процессом.

Там нет роли менеджера проекта, когда речь идет о команде, но менеджер проекта может работать на владельца продукта и помогать ему организовывать клиентов и доставку.

Как только вы поставите роль менеджера проекта под надзор за командой, вы убьете преимущества, которые составляют ценность Scrum.

Если вы продакт-менеджер, который пытается работать с Agile-командой, вам нужно выбрать то, что вас волнует, процесс или продукт. Не может быть и то, и другое...

Я думаю, вам нужно помнить, что Scrum Master — это роль, а не обязательно звание. Теоретически вы можете называться главным менеджером проекта и по-прежнему выполнять роль скрам-мастера.

На моей предыдущей должности я был менеджером ИТ-проектов, но моя повседневная роль была скрам-мастером.

Почему так сосредоточен на названии, а не на работе?

Меня не волнует название (в любом случае, я предпочитаю PM как название), но я чувствую, что роли очень разные, а иногда и полностью противоположные друг другу. Например, как продакт-менеджер я хочу иметь возможность управлять командой, расставлять приоритеты в работе, выступать в качестве основного канала связи и корректировать деятельность людей в соответствии с графиком. В схватке идея очень невмешательна, и очень важно, чтобы кто-то действовал как «босс». Я становлюсь гибким, и мне нравится такой подход, но когда руководство хочет, чтобы я использовал скрам, я не думаю, что они знают, о чем просят.
@BrianR: В Scrum именно владелец продукта делает большую часть того, что вы хотите сделать, за исключением власти над командой. Расстановка приоритетов осуществляется с точки зрения «это наиболее важно сделать в первую очередь», а не «сделай это сейчас», но в основном это связано с тем, как это представляется.

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

Конкретные задачи, которые вы упомянули, как правило, связаны с обязанностями владельца продукта. Управление элементами содержания, согласование рабочих элементов с BRD/SRS и отправленными запросами на изменение ничем не отличается от управления бэклогом продукта путем добавления, удаления и определения приоритетов историй, а также работы с командой разработчиков, чтобы обеспечить достоверность историй. Соблюдение сроков также является частью роли владельца продукта, поскольку часть работы владельца продукта заключается в том, чтобы гарантировать, что ценность доставляется пользователю, когда это необходимо.

Вы не говорите, насколько велика ваша команда разработчиков. В Scrum всего три роли: владелец продукта, скрам-мастер и член команды разработчиков. Не исключено, что старший член Команды Разработки (желательно с некоторыми практическими знаниями Scrum) может перейти на роль Scrum Master, продолжая функционировать в качестве члена Команды Разработки, оставив вам полную роль Владельца Продукта. , что будет соответствовать вашим текущим обязанностям. Если по какой-то причине после этой корректировки вы недостаточно загружены, подумайте о том, чтобы взять на себя некоторую работу по тестированию (в первую очередь приемочное тестирование) или в качестве эксперта в предметной области (при условии, что ваша команда еще не имеет опыта работы с предметной областью).

Что касается ваших «не схваточных» вещей, я бы не слишком беспокоился о них. Ваш конкретный пример, когда вы даете руководству представление о том, какие истории могут быть назначены для предстоящих спринтов, может быть хорошей идеей. Это может помочь им в переходе от методологий, основанных на планах, где каждая задача имеет точную дату, к более гибким методам. Ключевым моментом здесь является обеспечение того, чтобы все осознали, что за пределами текущего спринта все является предварительным — приоритеты могут меняться и меняются, поэтому не следует брать чрезмерное количество твердых обязательств слишком далеко в будущее.

Имейте в виду, что Scrum — это фреймворк. Есть некоторые пуристы, но вам нужно помнить, что вы переходите от методов, основанных на планировании, к гибким методам, и требуется время, чтобы изучить новый подход и полностью развернуть его — это не просто щелкнуть выключателем. Вы также должны адаптировать структуру, где это уместно, принимая во внимание уроки, полученные от людей, которые совершили переход до вас.

Сравнение ролейНе пытайтесь придерживаться имен, ролей и методов. Выбирайте те, с которыми вам и вашей команде интересно работать.

Две мысли: 1. если вы еще не прошли обучение CSM (например, Scrum Alliance), так как это предоставит теорию, лежащую в основе метода доставки Scrum. 2. Признайте, что PM в Scrum означает, что вы коуч и проводник, а не лидер. Роль лидера – в команде. Это вызов для премьер-министра не быть премьер -министром- ваша роль заключается в том, чтобы обеспечить команду всеми ресурсами, необходимыми для выполнения спринта в установленные сроки. Это включает в себя доступ к МСП, а также технический материал. Это также необходимо для того, чтобы роли Scrum были понятны всем — команде и заинтересованным сторонам. Владелец продукта должен быть в бизнесе. Скрам-мастер находится в команде (можете быть вы). На практике я также думаю, что вам нужно посмотреть, существует ли роль архитектора - «появление» архитектуры заставляет некоторых людей в управлении бизнесом / ИТ нервничать. Кроме того, установление границ (бизнес-архитектура и технологическая архитектура) не является чем-то плохим — позволяет сфокусировать процесс принятия решений. Идеал - экспериментируйте! Попробуйте поменяться ролями и посмотреть, что улучшится. Спросите команду, что им нужно. То же самое для владельца продукта. Это просто может быть весело!

Помогите мне совместить мою должность руководителя проекта с выполнением ролей скрам-мастера
СпросиСетьПолитика конфиденциальности1y, 0v