Знакомство с методологией Microsoft Solution Framework (MSF), основные компоненты и принципы методологии, дисциплина управления проектом MSF

Масштабирование функций управления проектом

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

Рис. 3.3.

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

Во втором проекте всем (либо почти всем) ролевым кластерам соответствуют подкоманды, у каждой из которых есть свой лидер. Эти лидеры осуществляют управление проектом на уровне своих подкоманд. Ролевой кластер "Управление программой" осуществляет общее управление проектом. Заметим, что на рисунке не показаны группы направлений, хотя они также являются подкомандами, в каждой из которых имеется собственный лидер - "Управление программой".

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

• Большой размер или затраты.
• Географическая удаленность работников.
• Члены проектной группы работают на разные компании, организации или субподрядчиков.
• Фиксированный или крайне ограниченный бюджет или календарный график.
• Контрактные взаимоотношения или юридические проблемы, требующие дополнительного времени и специальных навыков.

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

Обязанности лидеров групп и ролевого кластера "управление программой" по управлению проектами

Рис. 3.4.

Планы проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Не добавляйте буферы в качестве резерва времени для запланированных задач. Так как работа всегда разрастается на все отведенное ей время (закон Паркинсона), такой буфер будет поглощен этими же самыми запланированными задачами, а не использован для реакции на непредвиденные события.
• Буферное время должно выделяться как будто бы под дополнительно существующую задачу. Обычно буфера создаются перед главными вехами, особенно позднейшими из них. Временные буфера всегда должны дополнять критический путь проекта (project's critical path). Критический путь - это наидлиннейшая цепь зависимых проектных задач, непосредственно определяющая сроки проекта.
• Использование буферного времени по ходу проекта должно подвергаться жесткому контролю.
• Если потребовалось расширить функциональность решения или уменьшилось количество доступных ресурсов, не компенсируйте это использованием буферного времени. Если вы поступите таким образом, вы ослабите свою возможность адекватного реагирования на риски. Согласовывайте баланс возможностей, ресурсов и сроков при помощи треугольника компромиссов.
• Если буферное время исчерпано, поставьте в известность всю проектную группу о том, что любой сбой или задержка будут ударом по работе над проектом и создадут опасность выхода за временные рамки.