Оценка объема менеджера проектов работы - что такое хорошая методология? [закрытый]

Расписания будут измерять количество работы в одном смысле (вы можете видеть, как разбивается их рабочий день и так далее), но не я думаю в том смысле, в котором вы хотите. 1284] В конечном счете, я не верю, что существует полезная метрика для менеджеров проектов в этом смысле, но я не думаю, что это проблема.

Я думаю, что в конечном итоге вы должны измерять успех проекта, а не «занятость». В конце концов, почему вас волнует, насколько занят PM, если они реализуют успешные проекты?

Один менеджер проекта может потратить полдня на составление журнала рисков и плана смягчения, который содержит 20 рисков, другой может потратить 2 дня на составление одного, в котором всего 5 рисков, но ни одно из этих чисел не является более полезным в качестве метрики, чем строки кода. Главное не в том, сколько времени вы на это потратили, сколько рисков вы определили, насколько велики ваши планы по смягчению последствий, но действительно ли вы успешно управляли рисками по проекту .

Вам лучше посмотреть, что должен делать менеджер проекта, а именно выполнять проекты на- время, бюджет и удовлетворенность клиентов (которые я бы использовал как конечную меру качества, а не дефектов).

В конце концов, вы измеряете, насколько «занят» генеральный директор? Или его просто судят по прибыли, которую получает компания?

Для этого:

• Время - Единственный способ, которым это действительно возможно, - это массовое дополнение оценок и планов, и это можно свести к минимуму, просмотрев планы и оценки и согласование их со всеми заинтересованными сторонами (разработчиками, PM, клиентом). Другая сторона этого состоит в том, что премьер-министр должен согласиться с планом, а не навязывать ему или ей дату реализации. Возможно, вы захотите измерить это либо по общей реализации, либо по каждой вехе.

• Бюджет - измеримый, но игровой. Для большинства проектов разработки ключевым моментом для нее являются честные табели учета рабочего времени от разработчиков, и лучший способ обеспечить это - сделать так, чтобы PM был PM, а не их непосредственным руководителем. Таким образом, у разработчиков есть с кем бороться (например, технический директор), если их заставляют заполнять табели учета рабочего времени, чтобы сократить бюджет. И снова премьер-министр должен согласовать бюджет, неразумно ожидать, что он выполнит то, что он сказал вам неразумно.

• Удовлетворенность клиентов - трудно измерить, поэтому я бы посоветовал вам не усложнять и писать прямолинейный пост рассмотрение проекта с менеджером по работе с клиентами и оценка из 10 баллов за общение, доставку и все остальное, что важно. Это субъективно, но, в конечном счете, удовлетворение клиентов тоже.

Но многое зависит от культуры компании. Для некоторых организаций ключевым моментом будет оплачиваемое рабочее время, в других - удовлетворенность разработчиков.

Я пытаюсь понять, ПОЧЕМУ вас попросили оценить объем работы, которую менеджер проекта выполняет над проектом. В лучшем случае это всего лишь просьба о практическом правиле, в противном случае это означает, что ваш босс просто ничего не знает о запуске проекта. Даже когда проекты выглядят очень похожими, в проекте всегда будет что-то уникальное:

• Команда не идентична (обучение новый парень веревки требует времени)
• Спецификация может отличаться совсем немного (и этот крошечный кусочек может удвоить рабочая нагрузка)
• Даже сезон может влиять на результат
• и так далее, и так далее

Каждое условие проекта может изменить рабочую нагрузку менеджера проекта, поэтому это всегда будет субъективная оценка.

Я бы посоветовал вам использовать то же самое Burn Down и уровень усилий, которые вы используете для разработчиков. Задача менеджера проекта в среде Agile немного отличается (и от магазина к магазину они разные), но PM должен быть в состоянии предоставить список задач и т.д.

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

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

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

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