Унифицированная модель организации внедрения решений в методологии Microsoft Solutions Framework (MSF)

Команда проекта - модель проектной группы MSF

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

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

Можно выделить три направления, в которых осуществляется масштабирование проектной команды.

Первое - создание групп направлений. Группы направлений (feature teams) - это компактные мини-команды, отвечающие за определенные компоненты создаваемого решения и образующие матричную организационную структуру (см. рис. 3.2). В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от планирования и кончая запуском в эксплуатацию.

Рис. 3.2. Разделение проектной команды на группы направлений [5]

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

Рис. 3.3. Разделение проектной команды на функциональные группы [5]

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

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

Рекомендации MSF по возможностям объединения ролей приведены на рис. 3.4.

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

Организация взаимодействия между проектной командой и заказчиками (заинтересованными лицами) распределяется среди ролевых кластеров "Управление программой" и "Управление продуктом". "Управление продуктом" обеспечивает отчетность в части характеристик решения, а "Управление программой" - отчетность о ходе проекта.

Рис. 3.4. Возможности объединения ролей в малых проектах [5]