Кто должен давать оценки проекта на высоком уровне?

Question

Я только что пришел из дискуссии о том, кто лучше всего дает оценки по данной работе.

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

Мне напомнили о главе 5 в Peopleware, которая дает результаты австралийского исследования с 1985 года - лучшая ссылка, которую я мог найти, - here.

Меня особенно интересует ваше внимание здесь - вы отвечаете как разработчик, архитектор, руководитель проекта или что-то еще?

Answer 1

Я отвечаю на это как на менеджера (настоящего), так и на разработчика (прошлое).

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

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

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

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

Answer 2

1. Разработчики обычно должны делать первоначальную оценку. Менеджер должен иметь возможность добавить к нему фактор риска в зависимости от того, кто его реализует. (например: если разработчик, внедряющий его, обладает лучшими знаниями, чем тот, кто дал оценку, риск будет ниже). Разработчик также может не иметь представления о других областях разработки проекта (предполагая его огромный). Здесь оценивается оценка Менеджера. Если проект мал, оценка разработчика достаточно хороша.

Answer 3

Лицо, ответственное за подписание оценки, должно быть действительно менеджером проекта. Это их ниша.

Я не говорю, что PM должны составить оценки.

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

Любая техническая оценка должна оцениваться техническим специалистом.

Но, тем не менее, любой нетехнический должен оцениваться соответствующим экспертом (типы CPA называют эти МСП - экспертами по предмету). Архитектор мог оценить техническое решение. A BA анализ пробелов. Менеджер может выполнить реализацию бизнес-процесса. И так далее.

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

Answer 4

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

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

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

Answer 5

Каждый должен дать оценку менеджеру проекта: функциональным аналитикам, аналитикам и старшим разработчикам.

Это задача премьер-министра, чтобы убедиться, что они несколько реалистичны и суммируют их.

Answer 6

Я отвечаю на это как на менеджера (настоящего), так и на разработчика (прошлое).

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

Бизнес-консультант связывает пользовательские истории со мной (техническим менеджером команды) и разработчиком.

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

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

Обычно оценка высокого уровня будет задаваться в диапазоне от x до x раз в 3 дня.

Например: 40 до 120 дней.

Очевидно, что мы оцениваем только время разработки/тестирования/развертывания. X будет добавлен для управления проектами и технического управления, рисков и накладных расходов.

Answer 7

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