Рекомендации по декомпозиции работы
При создании WBS полезно учитывать следующие рекомендации:
· Затраты на каждую задачу должны быть реалистично оцениваемы.
· Оценка времени исполнения каждой задачи не должна быть менее одного или более 40 дней (для IT-проектов).
· Каждая задача должна иметь однозначное описание как её самой, так и ожидаемого результата.
· Задачи выделены правильно, если их выполнение может производиться без существенных пауз.
· Ответственность за каждую задачу должна быть поручена одному работнику.
· Каждая задача может предполагать дальнейшее разбиение на элементарные подзадачи.
· Деятельность, сопряженная с большими рисками, должна детализироваться больше, чем деятельность, сопряженная с меньшими рисками.
· За исключением двух верхних уровней, задачи должны формулироваться в повелительном наклонении (например, “Спроектировать схему базы данных” вместо “Схема базы данных”).
· В WBS должно быть от трех до пяти уровней определения задач.
· По ходу работы над проектом WBS последовательно дорабатывается, но обычно ее формирование производится на фазе планирования.
Оценка снизу вверх
В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. следует получать от тех, кто будет затем выполнять оцениваемую работу. Оценка снизу вверх (bottom-up estimating) – это процесс выработки и интеграции оценок многими членами команды. Такой подход обладает следующими преимуществами:
|
|
|
Большая точность. Оценки, сделанные непосредственными исполнителями, являются более точными, поскольку у этих людей есть опыт аналогичной деятельности.
Ответственность. Те, кто использует в работе собственные оценки, чувствуют большую ответственность, как за свою работу, так и за адекватность сделанных оценок.
Уполномоченость (empowerment) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.
Интегрирование представленных проектной группой оценок
Каждый лидер ролевого кластера ответственен за оценку необходимого своему отделу времени. К примеру, лидер команды разработчиков подготавливает оценки времени разработки.
Ролевой кластер “Управление программой” координирует подготовку оценок трудозатрат и интегрирует их в сводный календарный график и бюджет проекта.
Оценки в проектах по разработке программного обеспечения
Значительный вклад в стоимость IT-проектов вносит стоимость рабочей силы, поэтому оценки трудозатрат – это существенная часть информации, необходимой для оценивания стоимости и календарного графика проекта.
|
|
|
Формирование реалистичных ожиданий
Предварительные сметы влияют на дальнейшие ожидания заказчика. По этой причине правильное понимание заказчиком точности этих смет не менее важно, чем применяемая методика их получения. Ролевые кластеры “Управление программой” и “Управление продуктом” должны провести тщательную работу по формированию реалистичных ожиданий в отношении следующего:
Оценки зависят от спецификации. Создание IT-решений во многом напоминает построение дома под заказ. Пока не известны все детали заказа, невозможно назвать цену дома. Однако не одни лишь спецификации определяют стоимость проекта. Другие составляющие проектной работы, такие как переговоры с заказчиком, совещания, подготовка отчетности и др. занимают определенное время и, следовательно, должны быть учтены в оценках затрат.
Будьте готовы к компромиссам. Работа с треугольником компромиссов и установление базовых приоритетов с использованием матрицы компромиссов помогают проектной группе и заказчику сформировать ожидания.
Нельзя достичь абсолютной точности. Поскольку процесс разработки решения включает в себя уточнение деталей, все оценки имеют определенную погрешность.
На каждой вехе происходит переоценка. По мере продвижения работы над проектом необходимо проводить уточнения оценок трудозатрат.
Дата добавления: 2019-07-15; просмотров: 140; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!