1. Введение

"Царь Вызывает антирес Ваш технический прогресс: Как у вас там сеют брюкву С кожурою али без?.. Посол Йес!" Л. Филатов "Сказ про Федота-стрельца..."

Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление. В руководствах по MSF кроме методов, моделей и концепций встречаются практические советы и приёмы, отнюдь не лишенные рациональности. Структурно пакет руководств MSF разделён на пять документов, так называемых «белых книг», каждый из которых охватывает определенную дисциплину или модель MSF : «Модель процессов MSF», «Модель проектной группы MSF», «Дисциплина управления проектами MSF», «Дисциплина управления рисками MSF» и «Дисциплина управления подготовкой MSF». Эта статья посвящена в большей степени первой книге «Модель процессов MSF», в которой будет рассмотрена модель жизненного цикла IT -проекта, а также базисные концепции и принципы методологии MSF.

Предметной областью рассматриваемой методологии является IT -проект (разработка ПО, внедрение/адаптация уже разработанных систем, разворачивание сетевой инфраструктуры или всё вышеперечисленное в комплексе). На мой взгляд, возможность применения данной технологии возникает в любом проекте, в котором задействовано более 4-6 человек. Итак, на чём же зиждется успех гиганта?

2. Базовые концепции и принципы модели процессов MSF

2.1. Единое видение проекта

Любой коллективный труд, а тем более такой нетривиальный как разработка и внедрения программного обеспечения, имеет мало шансов на успех, если все участвующие стороны не представляют (или еще хуже не правильно представляют) конечной цели проекта, иначе говоря, не имеют единого видения (shared vision) проекта. Все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат. Всем должна быть понятна цель проекта. Подход MSF не зря акцентирует внимание на этом, казалось бы, умозрительном принципе. На практике не всегда так просто обеспечить единое понимание целей и задач проекта. Зачастую эта единая цель вступает в противоречие с интересами некоторых участников проекта. Или эти участники видят выгоды только от одной подсистемы проекта, которая касается их непосредственно. Например, бывает очень тяжело на последних этапах проекта объяснить сотрудникам склада, зачем им вводить номер накладной на отпущенный товар. Им он не нужен. Зато он нужен бухгалтерии. Конфликт возникает, потому что кладовщики думали, что автоматизируют склад, а не предприятие в целом. Поэтому MSF выделяет в жизненном цикле проекта целую фазу для обеспечения единого видения проекта.

2.2. Управляйте компромиссами

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

2.2.1. Треугольник компромиссов

Часто бывает очень полезно изобразить эту зависимость заказчику в виде треугольника компромиссов

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

2.2.2. Матрица компромиссов

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

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

2.3. Проявляйте гибкость – будьте готовы к переменам

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

2.4. Концентрация на бизнес-приоритетах

При создании любого решения необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить потребитель решения. Если проект нацелен на предприятие, то точкой концентрации будет бизнес-отдача (business - value). В отношении персональных программ, как, например, компьютерная игра, отдачу можно выразить в виде эмоционального удовлетворения потребителя. Можно сказать уверенно, что MSF не подходит для волонтёрских проектов, удовлетворяющих чьи-то амбиции или являющихся творческой отдушиной для разработчиков – творцов с рождения.

2.5. Поощряйте свободное общение

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

2.6. Создавайте базовые версии

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

3. MSF – симбиоз итеративного и фазового подхода

3.1. Итеративный подход

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

Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации. Такой подход позволяет планировать возможности для последующих версий, делать учёт опыта предыдущих циклов, обеспечивая гибкость и устойчивость к переменам требований. Таким образом, обеспечивается ведение «живой» документации, которая изменяется по мере эволюции проекта. В рамках одной итерации все документы (равно как и программный код) тоже развиваются итеративно. Например, план тестирования или концепция проекта (shared vision document) распространяется среди всех ролей проекта в виде «подходов» (approaches) еще до утверждения и затем итеративно эволюционируют благодаря обратной связи участников проекта до формы, подлежащей утверждению. Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями, и часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии. Создание базовой версии всех проектных документов на самых ранних этапах дает возможность всем членам проектной группы осмыслить свои задачи и цели проекта, а так же приступить к работе с минимальными задержками.

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

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

3.2. Подход, основанный на фазах и вехах

Что может быть ближе отечественной АСУшной душе, чем такой подход. Десятилетиями наши системы внедрялись поэтапно. Поковыряли ложкой в тарелке, что-то подправили, подмазали – совещание. Не годиться – на доработку. Подправили – совещание. После пятой фрикции (в лучшем случае) с горем пополам закрыли этап. И так далее. Нет-нет, мы не будем возвращаться в ностальгическое прошлое. Майкрософт не предлагает то же самое, только с перламутровыми пуговицами. В рамках одной итерации, жизненный цикл выпуска версии разбивается на пять фаз (выработка концепции (единого видения), планирование, разработка, стабилизация (тестирование), внедрение). Каждая фаза цикла заканчивается главной вехой (контрольной точкой). Соответственно главные вехи будут иметь названия: концепция продукта утверждена, планы продукта утверждены, разработка завершена, готовность решения утверждена, внедрение завершено. Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых кластеров (разработка, тестирование, внедрение, управление проектом и пр.).

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

3.3. Модель проектной группы MSF

Вот здесь начинается самое интересное и, на мой взгляд, новаторское в подходе MSF. Этой теме уделена целая «белая книга» из пакета руководств MSF и здесь мы рассмотрим только основные подходы к построению проектной группы. Существуют основные принципы и концепции модели проектной группы, которые во многом являются чуждыми большинству IT компаний. Здесь разрушаются некоторые стереотипы (например, диктаторские полномочия и соответствующая ответственность менеджера проекта) и предлагается несколько иная, более органичная структура организации рабочих групп. Подход, по меньшей мере, весьма интересен.

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

• Управление продуктом
• Управление программой
• Разработка
• Тестирование
• Удовлетворение потребителя
• Управление выпуском

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

• Распределяйте ответственности при фиксации отчетности
• Наделяйте соответствующими полномочиями ролевые кластеры.

Таким образом, все ролевые кластеры в команде равноправны . Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды. Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Что важнее решать вам – о управленец! Однако, по мнению Майкрософт, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца. Перечислю основные области ответственности ролевых кластеров.

Управление продуктом	Представление интересов заказчика; аналитика; обоснование бизнес-отдачи; формирование единого видения и рамок проекта; управление требованиями заказчика; определение приоритетов факторов (время/рамки/ресурсы); PR продукта; план коммуникаций.
Управление программой	Управление процессом разработки с целью получение продукта в рамках проектных ограничений; формулировка спецификации и разработка архитектуры; управление совещаниями и коммуникациями; формирует сводный план; управление рисками; сетевой график работ; отчётность.
Разработка	Определяет дизайн решения; оценка времени разработки; разработка; консультирование.
Тестирование	Планирование тестирования; тестирование.
Удовлетворение потребителя	Представляет интересы потребителя (на заказчика, а конечного пользователя системы); сбор требований потребителя; формирует требования к эргономике, справочной системе и учебным материалам.
Управление выпуском	Внедрение; обеспечение сопровождения; материальное обеспечение и логистика; инфраструктура поставок.

Для малых проектов возможно совмещение ролевых кластеров, например Тестирование и Удовлетворение Потребителей. Однако MSF настоятельно рекомендует не объединять кластер Разработка, ни с каким из других потому же, почему нельзя отвлекать хирурга во время операции. И Управление Продуктом с Управлением Программой, потому что, как известно, единство и борьба противоположностей рождает качественное диалектическое развитие.

Рассмотрим каждую из фаз жизненного цикла проекта подробнее.

3.4. Фаза выработки концепции

Это первая фаза жизненного цикла проекта. Начинается она с формирования ядра проектной группы (если конечно это первая итерация продукта). Затем закладывается основа, фундамент, будущего решения на основе единого видения проекта (ничем не ограниченное представление о целях и задачах, стоящих перед проектной группой). После этого очерчиваются рамки (чётко описанные задачи, которые предстоит решить), однозначно описывающие то, что предстоит сделать в рамках проектных ограничений, и оцениваются риски. Нельзя смешивать эти два понятия, но и нельзя рассматривать одно в отрыве от другого. Если программист будет создавать продукт, не владея документом единого видения (shared vision document) только на основании описания рамок (scope document), он вероятнее всего не сможет создать то, что ожидает заказчик, ведь основные цели, представления и ожидания заказчика сконцентрированы именно в документе единого видения. Оба эти документа должны создаваться итеративно и тщательно, минимизируя дальнейшие отклонения от них.

Главной вехой этой фазы будет событие «Концепция утверждена». К этому моменту у заказчика и проектной группы уже сформированы устойчивые представления о задачах, функциональности и ограничениях проекта. К моменту этой вехи должны быть готовы следующие документы: общее описание и рамки проекта (vision \ scope document), документ оценки рисков, описание структуры проекта. Задачи проектной группы на этой фазе распределяются следующим образом:

Ролевой кластер	Фокус
Управление продуктом	Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта.
Управление программой	Цели дизайна; концепция решения; структура проекта.
Разработка	Прототипирование; анализ технологических возможностей; анализ осуществимости.
Удовлетворение потребителя	Необходимые эксплуатационные характеристики решения и их влияние на его разработку.
Тестирование	Стратегии тестирования; критерии приемлемости, их влияние на разработку решения.
Управление выпуском	Требования внедрения и их влияние на разработку решения; требования сопровождения.

MSF рекомендует обозначить следующие промежуточные вехи в течение фазы:

• Ядро проектной группы сформировано
• Черновой вариант концепции проекта составлен

3.5. Фаза планирования

Наступает важнейший этап разработки решения. Фаза планирования включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Всё начинается с анализа и документирования проектных требований с разделением их на категории: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования. Затем при создании функциональной спецификации нужно следить за соответствием (traceability) функциональности и существующих требований. Детализация требований происходит по известному всем аналитикам сценарию, прибегая к моделированию вариантов использования, (use - case modeling) и стори-боардингу (story-boarding), хотя у каждого опытного аналитика наверняка есть свой арсенал методов. Затем работа переходит в область проектирования (дизайна), где разрабатываются концептуальный, логический и физический дизайны, служащие уже инструментами для разработчиков. Результаты проектирования документируются в функциональную спецификацию, которая детально описывает вид и поведение всех составляющих решения. На основании спецификации работает команда разработчиков (с учётом синхронизации действий между собой), производится оценивание работ, достигается чёткое соглашение с заказчиком о том, что должно быть сделано. Как только создана спецификация, руководители ролевых кластеров смогут создать детальный план, относящийся к его роли. Примерами планов могут стать: план внедрения, план тестирования, план обучения, план мер безопасности и т.п. Затем проектная группа коллективно анализирует планы и выявляет зависимости между ними. Эти планы в последствии объединяются в сводный план проекта и сводный сетевой график работ. На этом же этапе создается также план управления рисками, к составлению которого есть смысл привлекать всех участвующих в проекте лиц.

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

Основные задачи проектной группы на фазе планирования:

Ролевой кластер	Фокус
Управление продуктом	Концептуальный дизайн; анализ бизнес-требований; коммуникационный план.
Управление программой	Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет.
Разработка	Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates).
Удовлетворение потребителя	Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение.
Тестирование	Оценка дизайна; требования тестирования; план и календарный график тестирования.
Управление выпуском	Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения.

MSF рекомендует создавать следующие промежуточные вехи:

• Верификация технологий
• Базовая версия функциональной спецификации создана
• Базовая версия сводного плана проекта создана
• Базовая версия сводного календарного графика работ создана
• Среды разработки и тестирования развернуты

3.6. Фаза разработки

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

Задачи ролей во время этой фазы:

Ролевой кластер	Фокус
Управление продуктом	Ожидания заказчика.
Управление программой	Управление функциональной спецификацией; мониторинг проекта; доработка планов.
Разработка	Разработка программного кода и инфраструктуры; документирование конфигураций.
Удовлетворение потребителя	Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн.
Тестирование	Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования.
Управление выпуском	Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists).

Рекомендуемые промежуточные вехи:

• Концепция подтверждена
• Билд n завершен, билд n +1 завершен…

3.7. Фаза стабилизации

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

Задачи проектной группы на этой фазе:

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

3.8. Фаза внедрения

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

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

Задачи группы на фазе внедрения:

Ролевой кластер	Фокус
Управление продуктом	Получение отзывов и оценок заказчика; акт о приеме выполненной работы.
Управление программой	Сопоставление рамок проекта с поставленным решением; управление стабилизацией.
Разработка	Разрешение проблем; поддержка эскалации.
Удовлетворение потребителя	Обучение; управление календарным графиком обучения.
Тестирование	Тестирование производительности.
Управление выпуском	Управление внедрением; одобрение изменений.

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

3.9. Замечания

Существуют проекты, в которых может отсутствовать фаза внедрения или разработки (например, разработка игры, или адаптация 1С).

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

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

Длительность фаз может быть совсем не одинакова, как изображено на картинках (суть это замечания взята с текста MSF, я бы в жизни не догадался его написать).

4. Резюме

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

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

Удачных проектов!