- 01-02-2008
Субъективно о CMMI (часть 5)
Переходим к описанию очередной процессной области второго уровня зрелости. Это Project Planning.
Назначение процессной области
Назанчение данной процессной области состоит в создании и последующем поддержании плана, в котором определены проектные активности.
Перечень специальных целей
В рамках этой процессной области определены три специальные цели:
SG 1: Подготовить оценки: Оценки необходимые для проектного планирования созданы и поддерживаются в актуальном состоянии.
SG 2: Разработать проектный план: Проектный план создан и поддерживается, как основа для управления проектом.
SG 3: Получить обязательства по плану: Обязательства по плану получены со всех участников проекта и поддерживаются в актуальном состоянии.
Уже сейчас можно понять, что основными процессными артефактами будут проектный план (или план по управлению проектом) и, так называемый, work breakdown structure (WBS), который содержит оценки трудоемкости, необходимые для планирования.
Диаграмма специальных целей и практик
Для начала рассмотрим диаграмму связей описанных специальных целей.
Обратите внимание на связь с процессной областью, которая называется Project Monitoring and Control. Это следующая процессная область, которую я буду рассматривать, поэтому обсуждение этой связи я предлагаю перенести в следующий раздел.
Следующая диграмма описывает практики, относящиеся к первой специальной цели.
Все достаточно прозрачно: делаем вспомагательные оценки, которые сводятся к подготовке самого важного – оценок по трудоемкости и стоимости. После этого мы переходим непосредственно к планированию.
Забегая немного вперед, я скажу, что результатами каждой из перечисленных практик будет являться соотвествующая секция одного из самых важных артефактов на проекте – плана по управлению проектом.
Все специальные практики в рамках третьей специальной цели тоже интуитивно понятны и делаются большинством менеджеров как бы между делом. Но в этом и состоит пожалуй основной плюс от ознакомления с CMMI моделью: она заставляет уделять больше внимания подобным мелочам.
Итак, переходим к табличке с примерами прямых/непрямых артефактов, а так же с описанием примеров подпрактик.
Идентификатор спец. практики | Пример реализации практик | Примеры прямых артефактов | Примеры косвенных артефактов |
SG 1: Подготовить оценки | |||
SP 1.1. Оценить мастабы проекта | 1. Разработать WBS на основе проектной архитектуры; 2. Идентифицировать и сгруппировать работы для определения оценок, ответственных специалистов и графика; 3. Определить продукты, которые нужно закупить дополнительно; 4. Определить продукты (или компоненты), которые будут переиспользоваться; | · Документ, который содержит перечень задач проекта (work breakdown structure - WBS) · Диаграмма Ганта, содержащая верхнеуровневые задачи | · Коммерческое предложение, в котором содержится раздел, посвященный верхнеуровневым задам на проекте; · Контракт, в котором содержится перечень выполняемых работ · Раздел плана управления проектом, посвященный обзору задач проекта |
SP 1.2. Подготовить оценки продуктов разработки и проектных задач | 1. Определить технический подход, который будет использоваться на проекте; 2. Использовать соответствующие методы для определения аттрибутов разрабатываемых продуктов и задач, которые будут использоваться для для оценки ресурсных требований; 3. Оценить аттрибуты разрабатываемых продуктов и задач; 4. Оценить оборудование, материалы и методы, которые будут использоваться на проекте; | · Исторические данные по оценкам различных задач на проектах, которые хранятся на корпоративном уровне (желательно графики и диаграммы); | · Отчеты о проверках подготовленных оценок; · WBS; · Переписка с обсуждениями оценок внутри команды · Методология оценивания проектов на основе исторических данных принятая в компании и задокументированная; |
SP 1.3. Определить фазы жизненного цикла проекта | · Раздел плана управления проектом, посвященный описанию жизненного цикла проекта; · Фазы проекта, описанные в соответствующих документах; | · Задачи, категоризированные по фазам проекта; · Диаграмма Ганта; · Описание стандартных моделей жизненного цикла, принятых в компании; | |
SP 1.4. Оценить трудозатраты и стоимость | 1. Собрать исторические данные, который позволят трансформировать продукты работы и задачи в оценки по трудоемкости и стоимости; 2. Включить в оценки затраты на инфраструктуру; 3. Подготовить оценки на основе исторических данных или выбранных моделей; | · Коммерческое предложение; · Контракт; · Оценки трудоемкости и стоимости в соответствующих документах; | · Соответствующий раздел WBS; · Файл Microsoft Project в котором содержится информация по стоимостям; · Описание процесса определения оценок и стоимости, принятого в компании; |
SG 2: Разработать проектный план | |||
SP 2.1. Определить бюджет и график работ | 1. Определить основные вехи проекта; 2. Определить допущения по длительности работ; 3. Определить ограничения; 4. Определить зависимости задач; 5. Определить бюджет и график работ; 6. Определить корректирующие мероприятия и критерии для их применения; | · График работ по проекту, например, в виде диаграммы Гантта; · Проектный бюджет (либо в специализированной системе, либо в соответствующих документах); | · Протоколы обсуждения с Заказчиком вех проекта, предполагаемой длительности и т.д.; · Описание допущений, зависимостей и т.д. в соответствующих документах; |
SP 2.2. Определить проектные риски | 1. Определить проектные риски; 2. Задокументировать риски; 3. Просмотреть полученный документ с нужными участниками проекта и получить согласие о его полноте и правильности; 4. Регулярно пересматривать риски; | · Реестр проектных рисков; | · Еженедельные статус отчеты, с информацией о регулярном пересмотре рисков; · Общий перечень рисков, на основании которого осуществлялось определение проектных рисков; |
SP 2.3. Спланировать управление проектными данными | 1. Определить требования и процедуры для обеспечения конфиденциальности и безопасности данных; 2. Организовать механизм архивирования данных, с последующим доступом к ним; 3. Определить, какие данные на проекте должны идентифицироваться, собираться и распределяться; | · План по управлению данными; · Соответствующий раздел в плане управления проектом; | · Документ, который содержит описание всех информационных источников, которые используются на проекте; · Корпоративное хранилище, на котором находятся все данные по проекту; |
SP 2.4. Спланировать проектные ресурсы | 1. Определить требования по процессам, применяемым при управлении проектом; 2. Определить требования к проектной команде; 3. Определить требования по оборудованию; | · Перечень аппаратного обеспечения, которое используется на проекте; · Описание состава проектной команды; | · Заявки на аппаратное и программное обеспечение; · Заявки на сотрудников; |
SP 2.5. Подготовить план по необходимым навыкам | 1. Определить знания и навыки, которые необходимо применять на проекте; 2. Оценить какие знания и навыки доступны; 3. Выбрать механизм для получения необходимых навыков и знаний; 4. Учесть выбранный механизм в проектном плане; | · Раздел коммерческого предложения, которое содержит перечень необходимых навыков; · Раздел плана по управлению проектом; | · Описание состава проектной команды с указанием навыков и знаний; |
SP 2.6. Спланировать вовлечение участников | 1. Обсудить с участниками проекта возможность их вовлечения на различных этапах; 2. Подготовить план на основе полученной информации; | · Раздел плана по управлению проектом, содержащий перечень всех участников и их роли и обязанности; | · Протоколы встреч, по обсуждению ролей участников; |
SP 2.7. Подготовить проектный план | 1. Собрать результаты всех практик данной цели в одном документе; | · План управления проектом; | · Документы, содержащие информацию по согласованию плана с участниками проекта; |
SG 3: Получить обязательства по плану | |||
SP 3.1. Посмотреть планы, которые влияют на проект | · Результаты обсуждения проектного плана с заказчиком; | · Измененный план управления проектом; · Запрос на изменение по результатам обсуждения; | |
SP 3.2. Согласовать необходимые работы и доступные ресурсы | · Измененные графики работ и списки доступных ресурсов; | · Протоколы встреч по обсуждению графика работ и необходимых ресурсов; | |
SP 3.3. Получить обязательства по проектному плану | 1. Определить уровень необходимой поддержки и обсудить обязательства с участниками; 2. Задокументировать все обязательства, заручившись подписью лица, необходимого уровня; 3. Проверить с менеджментом все внутренние обязательства; 4. Проверить с менеджментом все внешние обязательства; 5. Определить обязательства, связанные с взаимодействием различных элементов проекта и обязательства, связанные с взаимодействием с другими проектами и организационными юнитами; | · Задокументированные запросы на подтверждение своих обязательств; · Задокументированные подтверждения обязательств; | · Письма, с обсуждением замечаний и вопросов к плану управления проектом; |
Обратите внимание на то, что в некоторых случаях, я вставлял косвенными артефактами документы корпоративного уровня (например, «Методология оценивания проектов на основе исторических данных принятая в компании и задокументированная» или «Описание стандартных моделей жизненного цикла, принятых в компании;»). Так вот это не приветствуется аудиторами. Логика простая: наличие документов на корпоративном уровне не является подтверждением их использования. В этом, кстати, и состоит одно из основных отличий CMMI модели от ISO подхода: CMMI, в первую очередь, уделяет внимание тому, чтобы все принятые инструкции использовались, а не пылились на полках.
Еще раз отдельно оговариваю, что последовательность действий, приведенная выше для каждой практики, не является обязательной. Например, в рамках практики SP1.4, в компании может существовать специальный комитет, задача которого утверждать выданные оценки перед тем как они будут представлены заказчику. В этом случае протокол заседания такого комитета может быть очень «сильным» косвенным артефактом.
Несколько комментариев под занавес:
1. По моему мнению, план управления проектом – это один из самых важных документов на проекте. В первую очередь потому, что он очень хорошо «прочищает мозги» руководителю проектов, позволя обозреть проект вцелом еще фактически до его начала. Кроме того, обычно составление такого документа не занимает много времени, как это может показаться. Разумеется, если Вы его составляете не первый раз. Исходя из приведенной выше таблицы можно понять какие именно секции он должен содержать. Я еще раз повторю их здесь:
a. Обзор проекта (цели, рамки, этапы, зависимости, допущения)
b. Организация (роли, обязанности, график взаимодействия, и т.д.)
c. Управление (рисками, информацией, и т.д.)
d. Техническая часть (работа с требованиями, интеграция, тестирование)
e. Ресурсы (аппаратное и программное обеспечение, человеческие ресурсы)
f. Знания и навыки
g. Доставка
h. Поддержка
2. Вы наверное уже обратили внимание, что мы рассматривали специальную практику «Идентифицировать риски» в то время как на третьем уровне зрелости есть целая процессная область посвященная рискам. В этом нет противоречия, этот как раз наглядно показывает, что третий уровень является естественным продолжением второго.
By AAM
| Комментарии к статье "Субъективно о CMMI (часть 5)" (0) |