Оценивайте задачи нижнего уровня декомпозиции

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

Затем для каждой простой подзадачи необходимо получить все необходимые оценки. Их суммирование дает общие оценки для соответствующих элементов WBS.

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

Более точной и рекомендуемой методикой является использование трех значений оценок: оптимистической, пессимистической и наиболее правдоподобной величин оценок трудозатрат для каждой из задач. Необходимо ввести критерии, разъясняющие значения этих терминов – пессимистическая величина не должна соответствовать наихудшему из всех возможных сценариев событий. Оптимистические и пессимистические оценки должны учитывать только обоснованные и вероятные риски.

Таким образом, после объединения элементарных подзадач в задачи WBS для каждой из них существуют три значения оценок. Лидеры команд представляют эту информацию на рассмотрение “Управлению программой” для проведения анализа стоимости, а затем используют оценки при составлении календарного графика.

Анализ PERT

После того как получены оценки по каждой из указанных в WBS задач, “Управление программой” (или специалисты по управлению проектами) приводят эти оценки к единым правдоподобным значением используя различные методы статистического анализа. Наиболее часто применяется метод PERT (метод оценки и пересмотра плана - Program Evaluation and Review Technique). Он рассматривает в качестве наиболее вероятного времени работы средневзвешенную величину трех значений оценки. Также этот подход дает возможность оценить границы общих временных затрат проекта исходя из вариаций оценок всех задач критического пути (critical path) проекта.

Полное описание метода PERT не входит в рамки этого документа. Существующие на рынке инструменты автоматизации управления проектами, такие как Microsoft® Project®, позволяют легко осуществлять PERT-анализ.

Рекомендации по составлению календарного графика

Управление календарным графиком включает в себя мероприятия, обеспечивающие своевременное завершение проекта.

Упорядочивание задач

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

Ограничение времени

Внутренние временные ограничения (известные как “временной ящик” - “time-boxing”) мобилизуют проектную группу и заставляют ее приоритезировать функциональность и деятельность. Они не должны приводить к произвольному сокращению временных оценок, произведенных проектной группой. Адекватные временные рамки вырабатываются исходя из обоснованных оценок и с пониманием того, что некоторая функциональность может подвергнуться сокращению для обеспечения следования календарному графику.

Выбирайте приоритеты, учитывая риски

Реализация важной функциональности и компонент решения, с которыми связаны наибольшие риски, должна быть запланирована на возможно более ранний срок (risk‑driven scheduling). Это максимизирует доступное для реакции на проблемы время.

Создание временных буферов

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

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

При выборе временного буфера рекомендуется учитывать следующее:

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

· Буферное время должно выделяться как будто бы под дополнительно существующую задачу. Обычно буфера создаются перед главными вехами, особенно позднейшими из них. Временные буфера всегда должны дополнять критический путь проекта (project’s critical path). Критический путь – это наидлиннейшая цепь зависимых проектных задач, непосредственно определяющая сроки проекта.

· Использование буферного времени по ходу проекта должно подвергаться жесткому контролю.

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

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

Заключение

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

Информация, содержащаяся в настоящем документе, представляет текущую точку зрения корпорации Майкрософт по обсуждаемым вопросам на момент публикации. В условиях меняющейся рыночной конъюнктуры, требующей соответствующей корректировки ведущихся разработок, данную информацию не следует рассматривать в качестве какого бы то ни было обязательства со стороны Майкрософт; корпорация не может гарантировать точность информации, представленной после даты публикации.

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

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

© Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены.

Microsoft и Project являются либо охраняемыми товарными знаками, либо охраняемым товарными знаками корпорации Майкрософт в США и других странах.

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

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf.

[*] Подробную информацию о рекомендуемом MSF процессе проектирования можно почерпнуть из пятидневного учебного курса Microsoft 2710 “Analyzing Requirements and Defining Microsoft.NET Solution Architectures” (Прим. редактора перевода).

[1] PMI, Inc., A Guide to the Project Management Body of Knowledge, 2000 Edition (Newtown Square, PA: Project Management Institute, 2000), стр. 4-6. Сходные определения, используемые в европейских странах и Великобритании, могут быть найдены в G. Caupin, H. Knopfel, P. Morris, E. Motzel, O Pannenbacker, IPMA Competence Baseline (Bremen, Germany: International Project Management Association, 1999), стр. 23 и Central Computer and Telecommunications Agency, Managing Successful Projects with Prince2, (London: UK Stationery Office, 1998), стр. 7.

[2] Адаптировано из A Guide to the Project Management Body of Knowledge, стр. 39. IPMA содержит 28 областей знаний, 9 из которых описаны PMI. Prince2 имеет 8 “компонент управления проектами”, лишь 3 из которых точно соответствуют областям PMI. Области IPMA надлежащим образом соответствуют как PMI, так и Prince2.

[3] A Guide to the Project Management Body of Knowledge, стр. 4-6. WBS также определена в IPMA Competence Baseline, стр. 34.

[4] Адаптировано для MSF из “Cost Models for Future Lifecycle Processes: COCOMO 2.0” Boehm, et. al., 1995. Взято из Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996), стр. 168.