Введение в методологию Microsoft Solutions Framework
Microsoft Solutions Framework (MSF) — это универсальная методология, не привязанная к конкретному программному продукту или специфической организации работы. Она подходит для создания традиционного ПО, внедрения информационных систем (в том числе класса АСУП), распределенных сетевых приложений и других решений.
Центральным, основополагающим элементом MSF является
модель процессов. Она определяет, какие работы, в каком порядке и с какими задачами необходимо выполнять. Ее ключевые особенности:
• Фазовая и итеративная структура: Проект развивается по спирали, проходя повторяющиеся циклы.
• Ориентация на создание «решения» — комплексного продукта, адаптированного под нужды заказчика и включающего само ПО, процесс внедрения, документацию, обучение и поддержку.
Продукт — это результат для массового рынка, «коробочное» решение, требующее установки.
Решение — всегда индивидуальный комплекс, требующий обязательного внедрения и подгонки под бизнес-процессы заказчика.
Весь жизненный цикл проекта состоит из вложенных циклов, каждый из которых включает пять фаз:
1.
Разработка концепции
2.
Планирование
3.
Разработка
4.
Стабилизация
5.
Внедрение
Фазы разделяются
вехами (milestones) — ключевыми контрольными точками для подведения итогов и синхронизации. Только после успешного завершения всех работ на этапе проект переходит к следующей фазе. Вехи бывают двух типов:
• Главные вехи: Обязательные для любого ИТ-проекта, разделяют фазы. Это точки смены производственной ответственности — лидирующая роль переходит от одного ролевого кластера к другому. Привычного «менеджера проекта», руководящего всем от начала до конца, здесь нет.
• Промежуточные вехи: Рекомендуемые, разбивают работу внутри фазы. Команда вправе выбирать их по своему усмотрению.
Итеративность в MSF означает создание системы версиями. Рекомендуется начать с базовой версии и далее наращивать ее функциональность. Это может происходить как последовательно, так и параллельно по разным аспектам.
Другой ключевой принцип — «живая документация». Ни один документ не появляется в законченном виде, а претерпевает изменения. Это требует процедур управления изменениями и поддержки версионности.
Методология MSF интегрированная: процессы разработки и внедрения информационной системы неразрывно связаны. Цель — не просто создать систему, а обеспечить ее работающей у заказчика и приносящей бизнес-отдачу.
Модель проектной группы
Проектная группа в MSF состоит из трех сторон:
заказчики,
потребители и
исполнители.
•
Заказчик — тот, кто ожидает бизнес-отдачи от системы.
•
Потребитель — тот, кто будет непосредственно с ней работать.
Их требования к системе различны, поэтому за их удовлетворение отвечают разные роли. Для организации работы исполнителей выделяются шесть
ролевых кластеров:
1.
Управление продуктом: Удовлетворение заказчика. Отвечает за качество создаваемой системы и ее соответствие бизнес-требованиям. Должен обладать знаниями в маркетинге, представлять интересы заказчика и планировать продукт.
2.
Управление программой: Достижение результата в рамках проектных ограничений. По сути, управление проектом: сроки, бюджет, организационные аспекты. В его зону также намеренно включена выработка архитектуры решения для поиска баланса между желаемым и возможным.
3.
Разработка: Создание решения в соответствии со спецификацией (проектирование, программирование, настройка).
4.
Тестирование: Обеспечение качества путем проверок и отладки.
5.
Удовлетворение потребителя: Обеспечение эффективной работы пользователей с системой. Включает компетенции в техподдержке, обучении, эргономике и графическом дизайне.
6.
Управление выпуском: Организация поставки и установки финальной версии решения заказчику.
Масштабирование проектной команды
Численность команды не фиксирована. MSF определяет
сложный проект не через количество людей или модулей, а через наличие рисков. Если уникальность или неопределенность порождают риски — проект сложный. Если стандартное внедрение выполняется в 10-й раз без рисков — он простой, несмотря на объем.
Масштабирование возможно в двух направлениях:
1.
Расширение (для сложных проектов): Внутри ролевых кластеров выделяются функциональные группы или специалисты под конкретные задачи (например, графический дизайнер, специалист по общедоступности). Второй вариант — создание полуролевых групп для разработки отдельных подсистем.
2.
Объединение ролей (для простых проектов): Роли можно рационально совмещать. Например, «Управление программой» и «Управление выпуском» объединить можно. Однако есть критичное правило:
ролевой кластер «Разработка» ни с кем не объединяется. Это позволяет сократить команду до 2–4 человек без потери эффективности.
Управление и разрешение конфликтов. Чтобы избежать безответственности и «безвластия», в MSF зафиксирована ответственность команды перед заказчиком через два кластера: «Управление программой» (отчитывается за сроки и ресурсы) и «Управление продуктом» (отчитывается за характеристики системы). Конфликты эскалируются до уровня «Управления программой», чей лидер имеет право принимать окончательное решение.
Фазы жизненного цикла проекта
1. Фаза выработки концепции
На этом этапе формируется общее видение проекта. Сначала ядро проектной группы создает черновой вариант концепции. После его согласования с заказчиком достигается главная веха
«Концепция утверждена». Итоговые документы: общее описание и рамки проекта, перечень рисков и описание структуры проекта.
2. Фаза планирования
Здесь проект детализируется. Основные промежуточные вехи:
• Создание базовой версии спецификации (требований к системе).
• Создание базовой версии плана проекта.
• Формирование календарного плана-графика (диаграммы Ганта) с работами, связями и длительностью.
• Развертывание отдельных сред: для разработки, тестирования и эксплуатации. Это необходимо, чтобы текущие доработки не разрушали уже работающую систему.
Завершается фаза главной вехой
«Планы проекта утверждены». Важно, что план проекта — это комплекс документов, за создание отдельных элементов которого отвечают разные ролевые кластеры.
3. Фаза разработки
Начинается с вехи
«Концепция подтверждена», за которой следует создание решения. MSF рекомендует регулярные (вплоть до ежедневных) сборки (
билды, от англ.
build), каждая из которых наращивает функциональность системы. Для проектов внедрения типовых решений ежедневные билды не имеют смысла, поэтому здесь сборка — это подключение очередного модуля. Фаза завершается, когда создание программного продукта закончено, но до его полной проверки.
4. Фаза стабилизации
Фаза посвящена тестированию и устранению дефектов. Динамика процесса отслеживается по вехам:
• Точка конвергенции: Количество выявляемых и устраняемых ошибок сравнялось.
• Точка достижения нуля: Все выявленные на данный момент ошибки впервые устранены.
• Версии-кандидаты: Полнофункциональные сборки, которые можно пытаться внедрить. После тестирования и доработки появляются новые версии-кандидаты.
• Тестирование приемлемости для потребителей: Подтверждение, что система выполняет запланированные функции.
• Пилотное внедрение: Внедрение на технических средствах заказчика, но с ограниченным числом рабочих мест и объемом данных.
Успешное пилотное внедрение ведет к главной вехе
«Решение готово».
5. Фаза внедрения
Система разворачивается на полном объеме технических средств заказчика, переносятся все данные. Достигается промежуточная веха
«Внедренное решение стабилизировано». Проводятся финальные проверки, доработка документации, и проект подходит к главной вехе
«Внедрение завершено». На этом один виток спирали жизненного цикла заканчивается, после чего можно переходить к следующему для усовершенствования системы.
Специфика управления проектом в MSF
В MSF отсутствует должность «менеджер проекта» как такового. Есть специалист, осуществляющий методическое руководство. В сложных проектах управление программой может разделяться: один человек отвечает за организационные аспекты, второй — за архитектуру решения. Распределение ключевых областей знаний по ролевым кластерам выглядит так:
• Управление стоимостью полностью лежит на «Управлении программой». Другие кластеры к нему не допускаются, чтобы избежать внутреннего «перетягивания одеяла» и борьбы за бюджеты.
• Управление коммуникациями разделяют «Управление программой» (отчитывается по срокам и ресурсам) и «Управление продуктом» (отчитывается по характеристикам системы).
• Управление снабжением также разделено: «Управление программой» ведет договорную работу с субподрядчиками, а «Управление выпуском» — материально-техническое обеспечение (закупку ПО, оборудования).
Управление проектной документацией начинается с документа общего содержания проекта (Scope Document) и фиксации его рамок. До начала детального планирования составляется
матрица компромиссов на основе проектного треугольника (время, ресурсы, возможности). В ней фиксируется, какой из параметров неизменен (например, срок), какой подлежит обсуждению, и какой станет результатом согласований. Это позволяет в дальнейшем вносить изменения без конфликтных ситуаций.
Конус неопределенности иллюстрирует, что на старте ИТ-проекта точность оценок по времени и стоимости минимальна. Погрешность может быть очень велика, и первоначальные оценки практически никогда не бывают реальными. Осознание этого факта приводит компании (как, например, оператора связи, прокладывавшего сети) к изменению стратегии: не фиксировать стоимость на первом этапе, а сначала провести бесплатный аудит проекта для грамотной оценки.
Краткие итоги
В основе любого успешного ИТ-проекта, выходящего за рамки простой поставки «коробочного» ПО, лежит переход от мышления категориями продукта к мышлению категориями решения. Это означает, что техническая реализация неотделима от процессов обследования, внедрения, обучения пользователей и последующей поддержки. Игнорирование любого из этих компонентов неизбежно ведет к разрыву между формальной сдачей системы и реальным получением бизнес-отдачи. Именно этот разрыв призвана устранить интегрированная природа MSF.
Ключевым организационным вызовом является отказ от иллюзии единоначалия в пользу модели распределенного лидерства. Передача ответственности между ролевыми кластерами по мере движения по фазам — это не просто административная формальность, а механизм синхронизации интересов. На старте доминирует видение продукта (бизнес-требования), затем на первый план выходит архитектура и план, далее — создание, и наконец — проверка потребителем и выпуск. Конфликт между этими центрами ответственности — не баг, а суть модели. Методология предлагает не избегать его, а легализовать через эскалацию к «управлению программой», которая принимает окончательное решение, балансируя между желаемым и возможным.
Практическое применение этих идей требует принципиально иного подхода к планированию и документообороту. Признание конуса неопределенности обесценивает попытку зафиксировать точный бюджет и сроки на старте. Это ведет к стратегическому сдвигу: начальный этап превращается в оплачиваемый аудит или, в смелых бизнес-моделях, в бесплатную инвестицию в точность оценки. Параллельно с этим концепция «живой документации» и матрицы компромиссов превращает процесс изменений из хаотичного реагирования на претензии в управляемый переговорный процесс. Команда не просто фиксирует срыв сроков, а осознанно предлагает заказчику выбор в рамках проектного треугольника: жертвовать ли функциональностью, бюджетом или временем.
1. Методология Microsoft Solutions Framework (MSF) универсальна и не привязана к конкретным продуктам или типам организаций.
2. Центральное понятие в MSF — «решение», которое, в отличие от «продукта», требует индивидуальной адаптации, внедрения и нацелено на бизнес-отдачу заказчика.
3. Модель процессов состоит из пяти фаз (концепция, планирование, разработка, стабилизация, внедрение) и носит итеративный характер.
4. Главные вехи разделяют фазы и являются точками смены ответственности между ролевыми кластерами.
5. В проектной группе MSF выделяется шесть ролевых кластеров, каждый со строго определенной зоной ответственности.
6. Сложность проекта в MSF определяется не объемом работ, а наличием рисков, порождаемых уникальностью и неопределенностью.
7. Масштабирование команды допускает как расширение ролей за счет создания функциональных групп, так и слияние ролей, однако кластер «Разработка» не объединяется ни с кем.
8. В методологии отсутствует единый менеджер проекта: управление распределено, а конфликты эскалируются до ролевого кластера «Управление программой».
9. Для безопасного наращивания функциональности и поэтапного внедрения обязательно развертывание трех изолированных сред: разработки, тестирования и эксплуатации.
10. Матрица компромиссов на основе проектного треугольника позволяет заранее формализовать, чем из трех параметров (сроки, ресурсы, возможности) можно пожертвовать в случае необходимости.
11. Конус неопределенности обосновывает нецелесообразность точных оценок стоимости и сроков на начальном этапе проекта.
12. Документация в MSF рассматривается как «живая», постоянно изменяемая и требующая процедур версионного контроля.
1. Чем понятие «решение» в трактовке Microsoft принципиально отличается от понятия «продукт»?
2. Какие две смысловые нагрузки несут в себе вехи в модели процессов MSF?
3. За достижение каких целей и соблюдение каких ограничений отвечают ролевые кластеры «Управление продуктом» и «Управление программой» соответственно?
4. Почему в ролевом кластере «Управление программой» намеренно объединены функции управления проектом и выработки архитектуры решения?
5. Какой критерий, предложенный в MSF, отличает сложный проект от простого, и почему нельзя ориентироваться только на объем работ?
6. Какое ключевое правило масштабирования проектной команды существует для объединения ролевых кластеров и чем оно обосновано?
7. Опишите процесс эскалации и разрешения конфликтов в проектной группе MSF.
8. В чем состоит практическая необходимость создания трех отдельных сред (разработки, тестирования и рабочей) и на какой фазе это планируется?
9. Для чего нужны и чем отличаются друг от друга промежуточные вехи «Точка конвергенции» и «Точка достижения нуля» на фазе стабилизации?
10. В чем заключается смысл и назначение пилотного внедрения?
11. Объясните логику распределения ответственности за управление стоимостью проекта исключительно на один ролевой кластер.
12. Каким образом матрица компромиссов помогает снизить количество конфликтов с заказчиком при неизбежных изменениях в проекте?
