Роли в модели команд msf

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

Роли в модели команд MSF.

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

• Менеджер программы (program management) несет ответственность за разработку и поставку решения заказчику в полном соответствии с ограничениями проекта.

• Разработчик (development) обеспечивает разработку технологического решения в соответствии со спецификациями, предоставленными менеджерами решения.

• Тестировщик (testing) отвечает за выявление и устранение всех неполадок и проблем с качеством продукта и дает окончательное «добро» на выпуск и поставку решения. Эта роль оценивает и проверяет корректность набора функций и его соответствие общей концепции и области действия проекта.

• Менеджер по выпуску (release management) отвечает за развертывание и работу продукта. Он проверяет корректность инфраструктуры и определяет возможность развертывания и поддержки продукта.

• Специалист по удобству использования (user experience) анализирует потребности и проблемы, возникающие у пользователей, и оценивает продукт на предмет соответствия таким потребностям.

В небольшом проекте отдельные члены проектной команды часто совмещают несколько ролей. Объединение ролей проекта довольно рискованно, поэтому важно назначать участникам проекта «совместимые» роли.

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

Другие члены команды

Кроме уже описанных ролей, в проектную команду также входят заинтересованные в проекте лица (stakeholders), хотя они и не учитываются в модели команд MSF.

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

• Заказчик (или бизнес-спонсор) — одно или несколько лиц, которые планируют получить выгоду — повышение ценности бизнеса — от внедрения решения.

• Конечный пользователь — одно или несколько лиц или систем, которые непосредственно взаимодействуют с решением.

• Организация, занимающаяся поддержкой решения, — отвечает за сопровождение решения после его развертывания.

Дисциплины MSF

Три ключевые дисциплины MSF — управление рисками, готовностью и проектом.

Управление рисками в MSF

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

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

1. Определение рисков позволяет выявлять их, благодаря чему команда получает

информацию о возможных проблемах.

2. Анализ рисков — преобразование оценок и информации о конкретных про-

ектных рисках, обнаруженных на предыдущей стадии, в форму, пригодную

для принятия решения об их важности.

3. Планирование рисков — использование результатов предыдущей стадии для

формулировки стратегий, планов и мероприятий.

4. Мониторинг рисков — наблюдение за конкретными рисками и документиро-

вание планов мероприятий по управлению ими или устранению.

5. Управление рисками — процесс исполнения планов мероприятий по управле-

нию и устранению рисков и отчетность о состоянии дел в этой сфере.

6. Извлечение уроков — формализация приобретенного опыта и соответствую-

щих проектных документов и инструментальных средств и сохранение при-

обретенных знаний в форме, доступной для их повторного использования в

командах и во всей компании.

Управление готовностью в MSF

Это процесс разработки знаний, навыков и возможностей, необходимых для создания и управления проектами и решениями. На рис. 1-4 показаны четыре стадии процесса управления готовностью: определение, оценка, изменение и анализ.

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

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

• Оценка (assess). Именно на этой стадии в команде начинается анализ текущих навыков и их связи с различными ролями. Цель — определить набор навыков каждой роли, который затем сравнивается с набором, определенным на предыдущей стадии. Сравнение текущей квалификации с требуемой, необходимо для разработки плана обучения, который «подтянет» членов команды до заданного уровня.

• Изменение (change). На этой стадии члены команды совершенствуют свои знания и навыки в процессе стр> ктурированного обучения, необходимого для повышени квалификации до указанного уровня.

Эта стадия состоит из:

• обучения ~ наставничества и тренингов в соответствии с планом обучения;

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

• Анализ (evaluate). На этой стадии определяют эффективность планов обучения и выясняют, применяются ли полученные знания при работе над проектом.

Управление проектом в MSF

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

• обеспечения единых принципов планирования и управления изменениями;

• определения и управления областью действия проекта;

• подготовки бюджета и управления затратами;

• подготовки и контроля графиков;

• выделения для проекта подходящих ресурсов;

• управления контрактами и поставщиками и поставки ресурсов для проекта;

• поддержки внешних связей и общения внутри команд;

• поддержки процесса управления рисками;

• документирования и мониторинга процесса управления качеством.

В модели команд MSF не предусмотрена роль менеджера проекта, однако большинство функций по управлению проектом отведены роли менеджеру программы.

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

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

После принятия решения команда работает в обычном режиме, предполагаю-

щем равноправие ее членов.

Управление компромиссами

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

Главная причина подобных проблем — нечетко описанная область действия

проекта. Область действия (scope) определяет, какие задачи решает продукт, а

какие не относятся к его компетенции. Для эффективного определения рамок

проекта и управления ими необходимо:

• определить ограничения проекта;

• организовать управление компромиссами;

• организовать управление изменениями;

• обеспечить мониторинг проекта.

В процессе определения и управления компромиссами не обязательно су-

жать функциональность решения, но все же зачастую компромисса избежать не

удается и набор функций приходится сокращать. Управление компромиссами —

это структурированный метод достижения баланса всех составных частей проек-

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

задач. И команда, и заказчик должны анализировать компромиссы и быть гото-

выми к нелегкому выбору. Для этого в MSF предлагаются особые инструменты:

треугольник компромиссов и матрица компромиссов проекта.

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

В проектах существует вполне определенная связь между такими параметрами

проекта, как ресурсы, график и функциональность проекта (рис. 1-5).

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

Треугольник компромиссов позволяет разобраться в ограничениях и предложить варианты решения.

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

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

Матрица компромиссов проекта — инструмент, который команда и заказчик используют при принятии решений о компромиссах. Подобные решения следует принимать на ранних стадиях проекта. Пример матрицы компромиссов проекта показан на рис. 1-6.

Матрица позволяет разделить функции на обязательные, необязательные, но

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

Учитывая, что зафиксировано ______________ , мы определим ________________ и в случае необходимости скорректируем ___________________,

Вот некоторые возможности.

• Учитывая, что зафиксированы ресурсы, мы определим график и в случае необходимости скорректируем функциональность.

• Учитывая, что зафиксированы ресурсы, мы определим функциональность и в случае необходимости скорректируем график.

• Учитывая, что зафиксирована функциональность, мы определим необходимые ресурсы и в случае необходимости скорректируем график.

• Учитывая, что зафиксирована функциональность, мы определим график и в случае необходимости скорректируем ресурсы.

• Учитывая, что зафиксирован график, мы определим необходимые ресурсы и в случае необходимости скорректируем функциональность.

• Учитывая, что зафиксирован график, мы определим функциональность и в случае необходимости скорректируем ресурсы.

Порядок применения итераций в проектах

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

Есть несколько видов итеративного подхода к разработке проекта:

• версии;

• обновляемые документы;

• периодические сборки (еженедельные или ежедневные).

Версии

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

Рис. 1 -7 иллюстрирует расширение набора функций с каждой последующей версией. Временной интервал между версиями зависит от размера и границ проекта.

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

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

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

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

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

Обновляемые документы

Чтобы не тратить слишком много времени на совершенствование проекта на начальной стадии, рекомендуется создавать обновляемые документы (living documents), то есть такие, что изменяются вместе с корректировкой проекта. «Живые» документы позволяют команде оперативно обновлять любую часть дизайна проекта и продолжать разработку на основании обновленных требований. Такой процесс гарантирует, что конечное решение будет удовлетворять финальным, а не только начальным требованиям Документы в MSF-проекте разрабатываются итерационно.

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

Периодические сборки

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

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