Национальный исследовательский университет "Высшая Школа Экономики"
Опубликован: 09.12.2008 | Доступ: свободный | Студентов: 5901 / 1739 | Оценка: 4.60 / 4.23 | Длительность: 13:39:00
ISBN: 978-5-94774-944-1
Специальности: Руководитель
Лекция 3:

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

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >

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

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

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

Таблица 3.2. Ролевые кластеры команды проекта
Ролевой кластер Цель Область компетенции Функции
Управление продуктом Удовлетворение Заказчиков
  • Маркетинг
  • Бизнес-отдача (бизнес-приоритеты)
  • Представление интересов Заказчика
  • Планирование продукта
  • Выступает в роли представителя Заказчика
  • Формирует общее видение/рамки проекта
  • Организует работу с требованиями Заказчика
  • Развивает сферы применения в бизнесе
  • Формирует ожидания Заказчика
  • Определяет компромиссы между параметрами "возможности продукта / время / ресурсы"
  • Организует маркетинг, PR
  • Разрабатывает, поддерживает и исполняет план коммуникаций
Управление программой Достижение результата в рамках проектных ограничений
  • Управление проектом
  • Выработка архитектуры решения
  • Контроль производственного процесса
  • Административные службы
  • Управляет процессом разработки с целью получения готового продукта в отведенные сроки
  • Формулирует спецификацию продукта и разрабатывает его архитектуру
  • Регулирует взаимоотношения и коммуникацию внутри проектной группы
  • Следит за временным графиком проекта и готовит отчетность о его состоянии
  • Проводит в жизнь важные компромиссные решения
  • Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта
  • Организует управление рисками
Разработка Создание продукта в соответствии со спецификацией
  • Технологическое консультирование
  • Проектирование и осуществление реализации
  • Разработка приложений
  • Разработка инфраструктуры
  • Определяет детали физического дизайна
  • Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна
  • Разрабатывает или контролирует разработку элементов
  • Подготавливает продукт к внедрению
  • Консультирует команду по технологическим вопросам
Тестирование Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены
  • Планирование тестов
  • Разработка тестов
  • Отчетность по тестам
  • Обеспечивает обнаружение всех дефектов
  • Разрабатывает стратегию и планы тестирования
  • Осуществляет тестирование
Удовлетворение потребителя Повышение эффективности пользователя, увеличение потребительской ценности продукта
  • Обеспечение технической поддержки
  • Обучение
  • Эргономика
  • Графический дизайн
  • Интернационализация
  • Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)
  • Представляет интересы потребителя в команде
  • Организует работу с требованиями пользователя
  • Проектирует и разрабатывает системы поддержки производительности
  • Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта
  • Определяет требования к системе помощи и ее содержание
  • Разрабатывает учебные материалы и осуществляет обучение пользователей
Управление выпуском Беспроблемное внедрение и сопровождение продукта
  • Инфраструктура
  • Сопровождение
  • Бизнес-процессы
  • Управление выпуском готового продукта
  • Представляет интересы отделов поставки и обслуживания продукта
  • Организует снабжение проектной группы
  • Организует внедрение продукта
  • Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта
  • Организует сопровождение и инфраструктуру поставки
  • Организует обеспечение проектной группы

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.4. Возможности объединения ролей в малых проектах [5]
< Лекция 2 || Лекция 3: 1234 || Лекция 4 >
Надежда Артюх
Надежда Артюх
Курс Методологии проектирования и внедрения корпоративных информационных систем
Олег Антонов
Олег Антонов