Методы вычисления реальных сроков задач

⇐ ПредыдущаяСтр 9 из 18Следующая ⇒

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

Выходом является использование статистических методов прогнозирования. Рассмотрим типовые приемы.

1 В Microsoft просто добавляют 30% к общей длительности плановых задач (Buffer time в 30%). Этот резерв расходуется на покрытие рисков.

2 Метод Load Factor (или на сколько умножить слова программиста), рекомендуемый группой XP. Статистический анализ проектов в малых группах разработки показал, что можно достаточно точно узнать реальный срок задачи, просто умножив слова исполнителя на некий коэффициент. Вот ориентировочные значения коэффициента:

- X = 2 — оптимистичная оценка;

- X = 3 — нормальный проект;

- X = 4-5 — применение нестандартных технологий.

3 Схема PERT вычисления реального срока. Часто бывает, что разные оценки дают разные сроки; в этом случае можно применить метод расчет реального срока по следующей формуле:

Реальный_Срок =

( Оптимистичный_Срок +4* Ожидаемый_Срок + Пессимистичный_Срок )/6. Коэффициенты в данной формуле (4 и 6) получены путем анализа статистики большого количества проектов. Следует отметить, что схема PERT эффективна только в том случае, если действительно имеются различные оценки. Если менеджер хочет через PERT просто убедить себя, что его решение единственно правильно, то подгонка статистики не даст ничего, кроме положительного ответа. О том, как использовать средства автоматизации PERT-вычислений в Microsoft Project речь пойдет ниже.

4 Методика Монте Карло. Система моделирования рисков на базе Монте Карло более точны чем PERT (точность выше примерно на 10%), плюс такие средства позволяют задавать уровень риска в проекте. Примером такого средства для Microsoft Project является Turbo Risk Manager.

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

Калибровка сроков

Как это часто и бывает на практике, расчет реалистичных сроков для проекта менеджер стал выполнять после его начала. Если проект для менеджера новый, то подобная ошибка почти неизбежна.

Используя Load Factor, менеджер оценил пессимистичные сроки. В качестве ожидаемых сроков менеджер взял те, что получились путем согласования через Team Assign с исполнителями. За оптимистические взял свои первоначальные. Методом PERT пересчитал ожидаемые сроки. По сравнению с планом была недооценка трудоемкости в 226 человеко-часов.

Советы.

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

2 Используйте копирование через Clipboard колонок PERT-диаграммы, таким образом вы сэкономите время.

Формальное закрытие проекта

Обычно после тщательной проработки сроков на основе достоверной статистики проект идет в графике до тех пор, пока не подходит к своему завершению, в этот момент на него начинают влиять новый вид риска — политический. Рассмотрим технику завершения проектов.

Измеряемая цель

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

Подобная ситуация является типичным признаком потери контроля. Это понял и заказчик, назначив крайний срок сдачи (Dead Line). В MS Project существует средство для отметки Dead Line и оповещении о подходе к нему.

Рассмотрим причины потери контроля и способы его восстановления.

Иллюзия простоты (80%/20%)

Следует помнить правило 80/20. Иными словами 80% работы делаются за 20% времени (рисунок 1.27). Как следствие, первые успехи могут вскружить голову и можно потерять ощущение реальности. Это является особенностью человеческой психологии и характерно для большинства людей. В этом заключается, однако, одна из причин заниженных исполнителями оценок сроков.

Рисунок 1.27

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

В нашем случае менеджер зарезервировал необходимое время на обеспечение качества. Возникшие причины проблем носят политический характер. Рассмотрим их.

1.4. План и требования должны изменяться совместно

Если проанализировать ситуацию, видно, что фактически происходит изменение задания (задач) проекта в результате процедуры приемки. На рисунке 1.28 приведен цикл изменения плана при корректировке задач по методике PMI.

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

Требования и план неразрывны, — это простое положение не так просто достигается на практике. Очень часто Заказчик только на сдаче проекта обнаруживает, что требования к проекту и его ожидания — несколько разные вещи. Часто Заказчик начинает настаивать именно на выполнении своих ожиданий.

Рисунок 1.28

В нашем случае причина в другом. Менеджер предусмотрел в плане работы по составлению задания и утвердил его у Заказчика. Заказчик был заранее предупрежден, что многие его ожидания в данном проекте реализованы не будут. Для правильного планирования необходимо завершить этап постановки задач. Это было сделано. Проблемы заключаются в другом. Необходимо изначально ставить измеримые цели, чтобы избежать субъективизма при оценке, исполнен проект полностью или нет. В начале данного примера этот шаг был намеренно пропущен, чтобы показать последствия данной ошибки и как можно ее постараться исправить по ходу дела.

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

Планирование итеративно, следующие стадии предсказуемы лишь статистически

Итак, в чем же заключаются настоящие проблемы данного проекта? Заказчик раздражен постоянным удорожанием проекта и спорит о толковании пунктов задания. Таким образом, разделим мотив и формальную причину.

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

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

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

Заказчик, получив большие статистические оценки, требует составить план работ из конкретных задач и начинает убирать оттуда " завышенные" и " ненужные" работы.

Если это произошло, проект обречен на потерю контроля.

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

⇐ Предыдущая 4 5 6 7 8910 11 12 13 Следующая ⇒