Презентация на тему "Организация проектных групп"

Содержание

• 
  Слайд 1
  

  ИНТЕГРИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ Лекция №13 Организация проектных групп

• 
  Слайд 2

  ИСУ. Организация проектных группОбзор модели команды MSF

  MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением. Шесть ролевых кластеров модели проектной группы – это “Управление продуктом” (product management), “Управление программой” (program management), “Разработка” (development), “Тестирование” (test), “Удовлетворение потребителя” (user experience) и “Управление выпуском” (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

• 
  Слайд 3
  

  ИСУ. Организация проектных группОбзор модели команды MSF Модель проектной группы MSF подчеркивает важность построения ролевых кластеров в соответствии с нуждами бизнеса. Группировка связанных областей компетенции, каждая из которых имеет свою специфику, обеспечивает хорошую сбалансированность команды. Четкое определение целей повышает уровень ответственности и способствует лучшему их восприятию проектной командой, что незамедлительно сказывается наилучшим образом на качестве выпускаемого продукта. Поскольку каждая из целей одинаково необходима для успешности проекта, все роли находятся в равноправных партнерских взаимоотношениях с равной значимостью при принятии решений. Заметим, что использование ролевых кластеров не подразумевает и не навязывает никакой специальной структуры организации или обязательных должностей. Административный состав ролей может широко варьироваться в разных организациях и проектных группах. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.

• 
  Слайд 4

  ИСУ. Организация проектных группОбзор модели команды MSF

• 
  Слайд 5
  
• 
  Слайд 6
  
• 
  Слайд 7
  

  ИСУ. Организация проектных группРолевые кластеры модели проектной группы

• 
  Слайд 8

  ИСУ. Организация проектных группОбъединение ролей

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

• 
  Слайд 9
  

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

• 
  Слайд 10