Оценка объема работы менеджера проекта - что такое хорошая методология? - PullRequest
6 голосов
/ 01 октября 2009

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

Полагаю, лучший вопрос - как мы оцениваем занятость руководителя проекта изо дня в день?

Ответы [ 6 ]

5 голосов
/ 01 октября 2009

Помните, что ЛЮБЫЕ метрики, которые вы можете придумать, скорее всего, будут игровыми .

[Получу ли я значок для тематической ссылки на Joel On Software? :)]

Сказав это, вы можете попробовать объединение следующих подходов:

  • Отзыв разработчика !!! (например, обратная связь с хорошим PM была бы такой: «У меня были проблемы X, Y и Z, и он заставил их исчезнуть»). Не очень хорошо, чтобы измерить, насколько «занят» PM, но действительно хорошо, чтобы измерить, насколько он эффективен.

  • Объем и номинальная четкость планов проекта (легко поддаются)

  • Скорость изменения планов проекта (легко поддается)

  • Количество встреч / времени встреч (легко поддаётся игре)

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

2 голосов
/ 01 октября 2009

Расписания будут измерять количество работы в одном смысле (вы можете видеть, как распадается их день и т. Д.), Но я не думаю, что вы хотите.

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

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

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

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

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

Для этого:

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

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

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

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

1 голос
/ 03 октября 2009

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

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

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

0 голосов
/ 03 февраля 2016

Извините, если я нахожусь в пуристе, но тег и вопрос требуют Agile. Каким будет менеджер проекта в Agile? Возможно, вы пытаетесь оценить работу, выполняемую владельцем продукта или мастером схватки?

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

Например, мастер схватки - "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". В основном это тренер и фасилитатор. Блокирование деструктивных запросов или отвлекающих факторов, создаваемых более высокими уровнями управления путем переговоров или убеждения следовать методам схватки, является одним из навыков, обычно используемых мастерами схватки. Некоторые из этих программных навыков трудно измерить как «работу», поскольку они не связаны с работой на компьютере или созданием отчета.

Я думаю, что показатель, от которого ваш босс извлечет наибольшую выгоду, больше связан с тем, насколько эффективна команда, и как описывается мастер схватки, чтобы облегчить работу его товарищей по команде. Тогда у DVK есть очень верная точка зрения, метрики, которые вы создаете, могут быть «игровыми», поэтому лучше всего полагать, что ваши менеджеры заняты, если ваши проекты развиваются, а ваши команды счастливы и работают как команда.

0 голосов
/ 13 февраля 2010

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

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

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

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

0 голосов
/ 05 октября 2009

Я бы предложил вам использовать тот же Burn Down и Level of Effort, который вы используете для разработчиков. Задача премьер-министра в Agile-среде немного отличается (и от магазина к магазину - по-разному), но премьер-министр должен быть в состоянии предоставить список задач и т. Д. Я считаю позитивным и вижу в этом подход ваших боссов к определению насколько доступен PM.

...