CASE-технологии

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

Введение
Стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустил пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий.
Эти знания базируются на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft, разрабатывавших проекты на предприятиях заказчиков, и лучшем из того, что накопила на данный момент IT‑индустрия.
Все это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).

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

MSF
Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов.
Информация по MSF доступна в Internet по адресу http://www.microsoft.com/msf/

MOF
MOF призван обеспечить организации, создающие критичные (mission-critical) IT‑решения на базе продуктов и технологий Microsoft , техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability).
MOF затрагивает вопросы, связанные с организацией персонала, процессов, технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред.

MOF
MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Агентством коммерческой палаты правительства Великобритании (Office of Government Commerce ‑ OGC).
Информация по MOF доступна в Internet по адресу http://www.microsoft.com/mof/

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

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

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

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

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

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

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

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

Что такое управление проектом?
Управление проектами (project management) – это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений.
В некоторых компаниях и странах под термином программа (program) понимается скоординированная группа проектов. Во избежание путаницы с наименованием ролевого кластера “Управление программой” группа проектов будет именоваться портфелем проектов (project portfolio).

Области управления проектами

Области управления проектами

Области управления проектами

Области управления проектами

Области управления проектами

Управление проектом осуществляется не только менеджерами
Термин “менеджмент” может относиться как к роли/должности, так и к области профессиональных навыков и знаний. Например, можно сказать: “Наш менеджмент хочет, чтобы это было сделано”, – или “Менеджмент проектов космических агентств должен находится на высочайшем уровне”.
Данное различие существенно, поскольку в управление проектами как деятельность может быть вовлечено множество людей, не являющихся менеджерами по должности.

Управление проектом осуществляется не только менеджерами
В MSF термин управление проектами (project management) всегда указывает на специфическую область знаний и навыков, упомянутых выше, а не на роль или должность.
Термин менеджер проекта (project manager) будет указывать на специалиста в области управления проектами.

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

Отношение между MSF и дисциплиной управления проектами.
В этом случае специфической моделью отрасли является пятифазовая модель процессов MSF. Пример специфической отраслевой деятельности – мониторинг ошибок (bug tracking). Общие знания об управлении проектами схематически изображены слева. Их примером являются рекомендуемые методики для управления контрактами и мониторинга бюджета. Пересечение областей соответствует специфичным для MSF методикам.

Характеристики управления проектами MSF
Принятый в MSF подход к управлению проектами имеет три отличительные характеристики:
Большая часть ответственности по менеджменту проекта возлагается на ролевой кластер “Управление программой”.
В больших проектах, использующих масштабированную модель проектной команды, деятельность по управлению проектами осуществляется на многих уровнях.
Для некоторых больших и сложных проектов требуется наличие специалиста или группы по управлению проектами.

Роль менеджера проекта возлагается на кластер “Управление программой”
Ролевой кластер “Управление программой” включает в себя следующие области компетенции: “Управление проектом”, “Выработка архитектуры решения”, “Контроль производственного процесса” и “Административные службы”.
Как правило, в небольших проектах все эти функции осуществляются одним менеджером программы.
Но по мере роста объема и сложности проекта в этом ролевом кластере выделяются две ветви специализации: работа над архитектурой/спецификациями и управление проектом.

Взаимодействие “Управления программой” с лидерами командных ролей
Окончательное распределение деятельности по управлению проектом во многом зависит от масштаба и сложности проекта.
Методология MSF легко масштабируема и может применяться в любых проектах: начиная с малых, в которых задействовано 2‑3 человека, и заканчивая очень большими. Проектные группы, работающие над продуктами Майкрософт, включают в себя сотни или даже тысячи членов. MSF обобщил уроки, извлеченные из опыта организации команд в Майкрософт, для широкого спектра IT‑проектов.

Взаимодействие “Управления программой” с лидерами командных ролей
Окончательное распределение деятельности по управлению проектом во многом зависит от масштаба и сложности проекта.
Методология MSF легко масштабируема и может применяться в любых проектах: начиная с малых, в которых задействовано 2‑3 человека, и заканчивая очень большими. Проектные группы, работающие над продуктами Майкрософт, включают в себя сотни или даже тысячи членов. MSF обобщил уроки, извлеченные из опыта организации команд в Майкрософт, для широкого спектра IT‑проектов.

Масштабируемость MSF
Значительная часть масштабируемости MSF обуславливается моделью проектной группы, которая расширяема в двух направлениях:
Ролевые кластеры являются набором областей компетенции, а не специфическими рабочими должностями. В силу этого ни одна из ролей не привязана к только лишь одному исполнителю. Ролевой кластер может быть расширен и содержать собственные подкластеры, каждый из которых имеет более специфические зоны ответственности. Они, в свою очередь, могут быть заполнены как одним, так и многими сотрудниками.
Для создания больших командных структур могут использоваться в различных сочетаниях группы направлений (feature teams) и функциональные группы (function teams).

Функциональные группы
Функциональные группы – это подкоманды, существующие внутри ролевых кластеров. Они формируются, когда стоящие перед ролевым кластером задачи столь масштабны, что требуют выделения специальных ресурсов. Ключевой момент здесь – разделение стоящих перед ролевым кластером задач, а не потребность ролевого кластера в более чем одном сотруднике.
Лидеры групп (team leads) являются ключевыми фигурами, интегрирующими свои коллективы в общую проектную деятельность. Они несут ответственность за управление проектом на уровне своих подкоманд.

Функциональные группы

Группы направлений
Группы направлений – это многопрофильные подкоманды, организуемые для создания определенной составляющей решения. Они компонуются из ролей модели проектной группы.
Исполнитель роли “Управление программой” также является лидером группы и обеспечивает интеграцию с общей проектной командой.
Создание групп направлений может быть разумным решением при организации удаленных или “офшорных” (off-shore) подразделений, разрабатывающих в значительной мере независимые компоненты решения.

Группы направлений

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

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

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

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

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

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

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

Лидеры команд не отвечают за:
Управление стоимостью проекта обычно осуществляется централизовано кластером “Управление программой”. Распределение этой функции среди лидеров команд было бы не рационально и могло бы привести к хаосу в работе.
Функции снабжения обычно осуществляются ролевыми кластерами “Управление программой” и/или “Управление выпуском” без участия других лидеров команд. “Управление программой” руководит закупками и заключением контрактов на предоставление необходимых для проекта услуг. Например, это может быть привлечение в проектную команду в качестве субподрядчика сторонней фирмы, занимающейся веб‑дизайном. “Управление выпуском”, будучи ответственным за обеспечение работы проектной группы, осуществляет закупки аппаратного и программного обеспечения, способствует приобретению другого имущества, необходимого для команды разработчиков, лабораторий тестирования и создания разрабатываемого решения в целом.

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

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

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

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

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

Ответственность перед заказчиком
Модель проектной группы MSF предусматривает следующую ответственность перед заказчиком:
Ролевой кластер “Управление продуктом” поддерживает связь с заказчиком и представляет его интересы в проектной группе. Эта роль служит целям удовлетворения заказчика.
Задача ролевого кластера “Управление программой” – успешная поставка решения в рамках проектных ограничений.
Ролевые кластеры “Управление продуктом” и “Управление программой” совместно работают над удовлетворением нужд заказчика в рамках проектных ограничений. Они имеют общую ответственность за успех проекта, но добиваются при этом различных целей.
Как только возникает проблема, которую “Управление продуктом” и “Управление программой” не способны решить совместно, выполняется эскалация по единой проектной иерархии подотчетности.

Управление рамками проекта
Целью управления рамками (scope management) проекта является гарантия включения в проект всей работы, необходимой для создания решения, и предотвращение возникновения дополнительной нагрузки, которая могла бы быть добавлена в проект без должного рассмотрения и одобрения.

Определение рамок на этапе выработки концепции
В самом начале работы над проектом должен быть выявлен и документирован круг имеющихся целей и задач.
Во время фазы выработки концепции (envisioning phase) проектная группа формирует общее видение решения. Затем, исходя из этого видения, определяется начальная версия рамок (scope) решения и проекта. Все это представляется в документе “Общее описание и рамки проекта” (vision/scope document) и подлежит одобрению со стороны проектной группы, заказчика и других заинтересованных сторон до того, как работа над проектом продолжена. Во время этой фазы есть лишь общее понимание рамок на уровне описания функциональности.

Рамки решения и рамки проекта
Термин “рамки” может обозначать как рамки решения (solution scope), так и рамки проекта (project scope). Рамки решения – это совокупность его составляющих и функциональности, которая должна быть создана. Рамки проекта – это объем работы, который необходимо выполнить для создания решения.
Для создания рамок решения в MSF служит процесс проектирования.

Определение рамок (scope definition)
Во время фазы планирования общий объем работы над проектом должен быть разбит на меньшие, более простые и легко исполнимые части. Этот процесс выявляет некоторые области, выходящие за рамки проекта. С ними обычно связаны риски неоднозначного толкования.
Определяя рамки, проектная группа выявляет типы задач и навыков, необходимых для создания каждой составляющей решения. Данная информация вносится в документ описания иерархической структуры работ (Work breakdown structure - WBS), который подробно рассматривается ниже.

Управление изменениями рамок (scope change control)
Управление изменениями рамок начинается с момента выработки их базовой версии. Изменения рамок проекта или решения могут быть приняты только лишь после их рассмотрения и одобрения как проектной группой, так и заказчиком.
Полноценное управление рамками включает в себя принятие компромиссных решений. Используемые в MSF треугольник компромиссов (trade-off triangle) и матрица компромиссов (trade-off matrix) облегчают управление изменениями.

Подготовка планов
Планирование как вид деятельности осуществляется на протяжении всего проекта. На фазе выработки концепции проектная группа создает высокоуровневые подходы к достижению целей проекта. Например, подход к тестированию описывает необходимые в проекте способы, инструментарий и навыки тестирования. В зависимости от размера проекта, такое описание может занимать 1‑2 страницы или всего абзац. Хотя уточнение планов выполняется на каждой из фаз, основная деятельность по планированию приходится на фазу планирования (planning phase).

Последовательность процессов фазы планирования
Вот общая последовательность процессов этой фазы:
Процесс проектирования (design - что создавать?)
Процесс планирования (planning - как создавать?)
Разработка календарного графика (scheduling - когда создавать?)
До некоторой степени эти процессы могут перекрываться, но перед углублением в каждый последующий процесс должна быть подготовлена базовая версия документации процесса предыдущего.

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

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

ориентировочный набор планов, покрывающий основные аспекты проектов по разработке ПО и внедрению инфраструктуры

Иерархическая структура работ
Иерархическая структура работ (Work Breakdown Structure - WBS) – это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. Для лидеров групп и ролевого кластера “Управление программой” WBS – это инструмент управления проектом, облегчающий создание планов и календарных графиков.
В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы. В больших проектах может возникнуть необходимость отдельного определения объема работы подкоманд (функциональных групп и/или групп направлений). Для этого ими может быть проведен мозговой штурм, результаты которого должны документироваться лидерами команд и представляться на рассмотрение всей проектной группе. “Управление программой” затем синтезирует эти составляющие в общую WBS.

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

WBS помогает:
Оценивать будущие затраты. Формируемая базовая версия списка проектных задач позволяет оценить материальные и временные затраты на реализацию проекта.
Распределять ресурсы. После того как определен фронт работ, становится понятным, какие кадровые ресурсы необходимо задействовать. WBS также помогает в случае необходимости обосновать имеющиеся потребности в ресурсах перед заинтересованными сторонами проекта.
Упорядочивать (по времени) выполнение задач. С помощью анализа списка проектных задач выявляются их взаимозависимости и ресурсные ограничения и, исходя из этого, составляется календарный график.
Выявлять риски. Наличие четкого определения каждой из проектных задач помогает проектной группе в их рассмотрении с целью выявления рисков.
Специфицировать ответственность. WBS может быть использован при создании матрицы ответственности (responsibility matrix).

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

Соответствие между WBS, функциональными спецификациями и сводным планом проекта
Сводный план проекта и WBS дополняют друг друга. WBS кратко перечисляет стоящие перед проектной группой задачи. Планы же проекта детально документируют, как каждая из имеющихся задач должна выполняться, какие установлены критерии качества (quality bars), какие есть элементарные подзадачи и чеклисты (контрольные списки - checklists) и т.д.

использование WBS в качестве инструмента поддержки соответствия между спецификациями, планами и календарными графиками

Создание WBS
Каждый ролевой кластер определяет объем своей работы, необходимой для создания решения, и описывает его в форме планов, чеклистов и т.п.
В MSF наибольшая детализация фронта работ осуществляется не в WBS, а в сводном плане проекта. В WBS же перечисляются задачи, для которых целесообразно вводить отчетность и проводить их мониторинг на уровне всего проекта.
Для создания WBS лидеры ролевых кластеров проводят собрания своих команд. При определении фронта необходимых работ и его разбиении на меньшие части, члены ролевых кластеров совместно анализируют спецификации составляющих решения. Этот процесс называется декомпозицией работы (work breakdown / work decomposition).

Создание WBS
Один из результатов процесса управления рисками MSF – появление дополнительных задач, являющихся реакцией на имеющиеся риски. Эта работа может быть включена в WBS, оценена, спланирована и внесена в календарный график точно так же, как и другие задачи. Рассмотрите возможность совмещения процесса составления WBS с мозговым штурмом по выявлению рисков.
Первый уровень структуры WBS может соответствовать фазам жизненного цикла проекта. Фазы модели процессов MSF очень хорошо подходят для этого. Предлагаемые в MSF промежуточные вехи фаз проекта соответствуют созданию базовых или рабочих версий определенных составляющих решения, поэтому их естественно использовать как второй уровень структуры WBS. Ниже этого уровня работа структурируется при помощи процесса декомпозиции работы/задач (work/task decomposition).

Рекомендации по декомпозиции работы
Затраты на каждую задачу должны быть реалистично оцениваемы.
Оценка времени исполнения каждой задачи не должна быть менее одного или более 40 дней (для IT-проектов).
Каждая задача должна иметь однозначное описание как её самой, так и ожидаемого результата.
Задачи выделены правильно, если их выполнение может происходить без существенных пауз.
Ответственность за каждую задачу должна быть поручена одному работнику.
Каждая задача может предполагать дальнейшее разбиение на элементарные подзадачи.
Деятельность, сопряженная с большими рисками, должна детализироваться больше, чем деятельность, сопряженная с меньшими рисками.
За исключением двух верхних уровней, задачи должны формулироваться в повелительном наклонении (например, “Спроектировать схему базы данных” вместо “Схема базы данных”).
В WBS должно быть от трех до пяти уровней определения задач.
По ходу работы над проектом WBS последовательно дорабатывается, но обычно ее формирование выполняется на фазе планирования.

Оценка снизу вверх
В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. следует получать от тех, кто будет затем выполнять оцениваемую работу. Оценка снизу вверх (bottom-up estimating) – это процесс выработки и интеграции оценок многими членами команды. Такой подход обладает следующими преимуществами:
Большая точность. Оценки, сделанные непосредственными исполнителями, являются более точными, поскольку у этих людей есть опыт аналогичной деятельности.
Ответственность. Те, кто использует в работе собственные оценки, чувствуют большую ответственность, как за свою работу, так и за адекватность сделанных оценок.
Уполномоченость (empowerment) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.

Интегрирование представленных проектной группой оценок
Каждый лидер ролевого кластера ответственен за оценку необходимого своему отделу времени. К примеру, лидер команды разработчиков подготавливает оценки времени разработки.
Ролевой кластер “Управление программой” координирует подготовку оценок трудозатрат и интегрирует их в сводный календарный график и бюджет проекта.

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

Формирование реалистичных ожиданий
Предварительные сметы влияют на дальнейшие ожидания заказчика. По этой причине правильное понимание заказчиком точности этих смет не менее важно, чем применяемая методика их получения. Ролевые кластеры “Управление программой” и “Управление продуктом” должны провести тщательную работу по формированию реалистичных ожиданий в отношении следующего:
Оценки зависят от спецификации. Создание IT-решений во многом напоминает построение дома под заказ. Пока не известны все детали заказа, невозможно назвать цену дома. Однако не одни лишь спецификации определяют стоимость проекта. Другие составляющие проектной работы, такие как переговоры с заказчиком, совещания, подготовка отчетности и др. занимают определенное время и, следовательно, должны быть учтены в оценках затрат.

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

Неопределенность и точность оценок
Оценки при разработке программного обеспечения предполагают постоянное уточнение.
Конус неопределенности” (“cone of uncertainty”), демонстрирующий процесс сходимости оценок программного обеспечения.

Неопределенность и точность оценок
На ранних этапах работы над проектом оценки затрат могут сильно отклоняться от реальных величин. Однако по мере прогресса работы над проектом это отклонение сходит на нет.
Заметим, что на вехе “Концепция проекта утверждена” оценки могут отличаться от реальных величин в большую или меньшую сторону в 2 раза. Показанные на рисунке значения, взятые из статистических данных за середину 1990-х годов, не должны восприниматься буквально. Действительно важным является понимание порядков отклонения оценок от реальных величин на каждой из фаз.
Из представленной информации можно увидеть, что во время фазы выработки концепции проектная группа получает лишь определенные границы (иногда называемые диапазонами оценок - “ballpark estimates”) для временных и материальных затрат. Никогда нельзя утверждать, что полученные на этой фазе оценки окончательны – отдавайте себе отчет в том, что после прохождения вехи “Концепция проекта утверждена” они могут варьироваться в несколько раз.

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

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

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

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

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

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

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

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

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

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

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