Каково типичное отношение часов PM/EM к «рабочим» часам в проекте?
Каково отношение правила к большому пальцу между менеджером Project Manager/Engagement Manager и общим временем проекта (например, человеко-часов для рабочих продуктов) в проекте? Меня особенно интересует ответ в контексте участия профессиональных служб, хотя я полагаю, что также будет общий ответ.
Например, предположим, что у нас есть проект на 1000 часов, в котором работают два штатных сотрудника. Сколько часов следует ожидать от Project/Engagement Manager в проекте? 1/10, 1/20, 1/5?
Есть ли такое типичное соотношение? Является ли он масштабированием/изменением в зависимости от количества участников проекта? Например, меняется ли это, если проект составляет 2000 часов с четырьмя пользователями FT за те же 500 календарных часов (
Накладные расходы Framework
Все фреймворки влекут за собой некоторые издержки процесса. Некоторые из этих накладных расходов — это часы, отработанные менеджером проекта, но некоторые из них являются побочным продуктом доставки на элементарные элементы управления и артефакты. Последняя форма накладных расходов часто значительно больше, поскольку она имеет тенденцию влиять на всех в проекте, а не на одну роль.
Например, Scrum описывается как легкий процесс, но он несет существенные издержки процесса, которые увеличивается по мере сокращения времени цикла. Типичный расчет служебных расходов Scrum при использовании двухнедельных спринтов может выглядеть следующим образом:
- 4 часа планирования Sprint на итерацию. (32 часа в команде).
- 2 часа обзора Sprint за итерацию. (16 часов в команде).
- 2 часа Retrospective Sprint за итерацию. (16 часов в команде).
- 15 минут в день для ежедневных стоянок. (2,5 часа в команде).
- 2 часа отставания за каждый сеанс. (4 часа на пару Scrum Master/Product Owner).
- 1 час в день (минимум) для отчетности или генерации артефактов, таких как графики выгорания, или препятствия для связи с родительской организацией. (10 часов на Scrum Master)
Таким образом, типичный двухнедельный спринт с шестью членами команды Scrum, Scrum Master и владельцем продукта будет потреблять 98 человеко-часов накладных расходов. Это охватывает только утвержденные рамками собрания и, как таковые, является разумной базой для некоторых дополнительных расчетов.
An 8-man team averages 320 man-hours in a two-week sprint, of which we’d be expecting 84 hours to be consumed in Накладные расходы Framework, with an additional 14 man-hours allocated against the Scrum Master and Product Owner. That’s 30.63% for the project as a whole.
Мастер Scrum Master на полный рабочий день усредняет 80 человеко-часов в двухнедельном спринте, из которых 22,5 часа будут считаться минимальным уровнем участия Scrum Master в каждой команде при использовании ожиданий, определенных выше. Это составляет 28,13% доступных человеко-часов мастера Scrum Master для каждой итерации.
Очевидно, что вычисления могут изменяться в зависимости от длины спринта (более продолжительное время цикла спринтов для более низких издержек процесса), размера команды или длины встречи. Тем не менее, это, безусловно, разумная основа для понимания уровня взаимодействия, требуемого Scrum Master.
Уровень участия
Вышеприведенные расчеты представляют собой минимальный уровень участия для Scrum и исключают участие в других организационных мероприятиях, таких как встречи Scrum-of-Scrums, встречи с заинтересованными сторонами, «встречи в коридорах команды» и другие повседневные задачи, которые необходимый для основных обязанностей Scrum Master для коучинга и судейства в процессе.
С зрелыми командами и процессом на месте мастер Scrum может напрямую участвовать в 3-4 проектах одновременно, но риски «управления движением» и сбоя процесса возрастают экспоненциально по мере того, как тенденции участия в команде к минимуму ,
С практической точки зрения, Scrum Master должен быть неотъемлемой частью команды, а не сторонником неполного рабочего дня, чтобы максимально использовать структуру. Однако это решение, которое каждая организация должна сделать для себя на основе своих уникальных обстоятельств.
Обобщение для других рамок
Большинство вышеперечисленных расчетов были основаны исключительно на Scrum. Тем не менее, всем здоровым проектам необходимо выделять одинаковые блоки времени для участия в собраниях, сбора/распространения статуса и создания артефактов фреймов.
Некоторые методологии обмениваются служебными данными времени ( a la Scrum) для управления отчетами или артефактами. Другие методологии накладные расходы команды (например, меньшее количество собраний команд) для накладных расходов менеджера проекта (например, более анализ показателей или более подробные отчеты об артефактах). Однако в моем личном опыте это фактически не приводит к снижению накладных расходов для проекта в целом.
Ваш пробег может отличаться, но вы можете как минимум оценить его, выполнив аналогичные вычисления для выбранной вами рамки.
Источник: