- 08-02-2008
Субъективно о CMMI (часть 6)
В данном разделе мы продолжим разговор о процессных областях напрямую связанных с управлением проектом и поговорим о процессной области Project Monitoring and Control.
Назначение процессной области
Задача процессной области предоставить понимание прогресса на проекте, чтобы была возможность предпринять соответствующие корректирующие действия в тот момент, когда актуальная проектная производительность будет значительно отклоняться от запланированной.
Перечень специальных целей
В рамках данной процессной области выделены две специальные цели:
SG 1: Контролировать ход проект согласно плану: Текущая производительность и прогресс на проекте контролируются согласно проектного плана.
SG 2: Управлять корректирующими действиями до их закрытия: Осуществляется управление корректирующими действиями до их щакрытия в том случае, когда проектная производительность или результаты значительно отклоняются от плана.
В общем, понятно, что были выделены две основные задачи: следить за ходом проекта и предпринимать соответствующие действия, в случае возмникновения отклонений от плана. И исходя из этих задач и были определеные именно эти специальные цели. Разумеется ключевым артефактом данной процессной области будет проектный план. Очень много завязано на различных отчетах, поскольку именно отчеты предоставляют актуальную информацию, что называется, «с фронтов».
Диаграмма специальных целей и практик
Ниже представлена диаграмма специальных целей и практик, а также связи между ними.
Как я уже говорил выше: все вращается вокруг проектного плана. Контролируются риски, обязательства, различные параметры планирования, вехи (milestones), общий прогресс. Все это делается с помощью регулярных отчетов. Оптимальным интервалом для таких отчетов является неделя. По структуре они очень напоминают сам план по управлению проектом, но при этом содержат исключительно актуальную информацию и вопросы, которые необходимо закрыть в кратчайшее время.
Идентификатор спец. практики | Пример реализации практик | Примеры прямых артефактов | Примеры косвенных артефактов |
SG 1: Контролировать ход проекта согласно плана | |||
SP 1.1 Контролировать параметры планирования | 1. Контролировать прогресс согласно графика работ; 2. Контролировать проектные затраты и израсходованную трудоемкость; 3. Контролировать аттрибуты проектных продуктов и задач (такие как сложность, размер, длительность и т.д.); 4. Контролировать предлагаемые и используемые ресурсы; 5. Контролировать знания и навыки проектной команды (для определения необходимых трейнингов, например); 6. Документировать значительные отклонения от проектного плана; | · Записи в специализированной системе о стоимости, длительности и другим параметрам работ; · Записи о навыках и знаниях всех членов команды; | · Регулярные отчеты об изменениях параметров планирования; · Еженедельные статус -отчеты; |
SP 1.2 Контролировать обязательства | 1. Регулярно просматривать обязательства (внешние и внутренние); 2. Определять обязательства которые не могут быть выполнены или по которым возникают риски, связанные с невыполнением; 3. Документировать результаты контроля обязательств; | · Диаграмма Ганта, на которой отображены участники и назначенные на них задачи; | · Еженедельные статус-отчеты |
SP 1.3Контролировать проектные риски | 1. Периодически просматривать перечень рисков в контексте текущего статуса проекта; 2. Исправлять описание рисков по мере поступления дополнительной информации; 3. Сообщать статус рисков соответствующим участникам; | · Еженедельные статус-отчеты и раздел посвященный рискам; · Реестр рисков; | · Письма, содержащие обсуждения проектных рисков с соответствующими участниками; · Протоколы встречь, на которых обсуждались риски по ходу проекта; |
SP 1.4 Контролировать управление данными | 1. Периодически просматривать активности, связанные с управлением данными, и сравнивать их с соответствующими описаниями в плане; 2. Определять и документировать существенные проблемы и их влияние; 3. Документировать результаты обзора активностей, связанных с управлением данными; | · Результаты аудита проектных данных; | · Раздел плана управления проектом, посвященный управлению данными на проекте; · Перечень данных, которые должны управляться в рамках проекта; |
SP 1.5 Контролировать вовлечение участников | 1. Периодически просматривать статус вовлечения участников; 2. Определять и документировать существенные проблемы и их влияние; 3. Документировать результаты обзора процесса вовлечения участников проекта; | · Перечень участников различных встреч, содержащийся в соответствующих протоколах; | · Раздел плана управления проектом, посвященный участникам проекта, их ролям и ответственностям; · Расписание встречь с перечнем участников, которое содержится в плане управления проектом; |
SP 1.6 Проводить пересмотр прогресса проекта | 1. Регулярно сообщать статус работ соответствующим участникам проекта; 2. Просматривать результаты сбора метрик для контроля проекта; 3. Идентифицировать и документировать важные проблемы и отклонения от плана; 4. Документировать запросы на изменение и проблемы, обнаруженные в проектных продуктах и процессах; 5. Документировать результаты обзора; 6. Отслеживать запросы на изменение и проблемы до их завершения/устранения; | · Еженедельные статус-отчеты; | · Протоколы еженедельных встреч команды проекта; |
SP 1.7 Проводить пересмотр вех проекта | 1. Проводить пересмотры значимых точек в проектном расписании (таких как, например, закрытие фазы) с соответствующими участниками; 2. Просматривать обязательства, планы, статус и риски проекта; 3. Определять и документировать существенные проблемы и их влияние; 4. Документировать результаты обзоров, принятые решения и ключевые действия; 5. Отслеживать определенные ключевые действия до их завершения; | · Секция с информацией по проектных вехам, в еженедельном статус отчете; · Перечень открытых проблем, которые могут повлиять на вехи (содержащийся, например, в Bug Tracking системе или в специальном разделе еженедельного отчета); | · Протоколы встреч команды проекта по обсуждению ближайших вех; |
SG 2: Управлять корректирующими действиями | |||
SP 2.1 Анализировать существующие проблемы | 1. Накапливать проблемы для анализа; 2. Проанализировать проблемы для определения необходимых корректирующих действий; | · Перечень всех открытых проблем (содержащийся, например, в Bug Tracking системе или в специальном разделе еженедельного отчета); | · Протоколы обсуждения на регулярных встречах проектной команды; · Регулярный общекорпоративный отчет, содержащий информацию о проектных метриках; |
SP 2.2 Принимать корректирующие действия | 1. Определить и задокументировать соответствующие действия необходимые для устранения идентифицированных проблем; 2. Просмотреть эти действия с соответствующими участниками проекта и заручится их согласием для осуществления действий; 3. Договориться о необходимых изменениях во внешних и внутренних обязательствах; | · Перечень всех открытых проблем с предлогаемыми корректирующими действиями, содержащийся в специальном разделе еженедельного статус-отчета; | · Протоколы обсуждения на регулярных встречах проектной команды; |
SP 2.3 Контролировать управление данными | 1. Контролировать корректирующие действия до момента их завершения; 2. Анализировать полученные результаты для определения их эффективности; 3. Определить и задокументировать соответствующие действия для исправления отклонений от запланированных результатов корректирующий действий; | · Перечень всех открытых проблем с предлогаемыми корректирующими действиями и результатами этих действий, содержащийся в специальном разделе еженедельного статус-отчета; | · Протоколы обсуждения на регулярных встречах проектной команды; |
Вы наверное уже обратили внимание на то,что все примеры реализации практик достаточно очевидны и следуют даже из определения (читай, названия) самих практик. В этом нет ничего удивительного. В конце концов, это же не «rocket science». Я бы предложил относится к рассматриваемому перечню приблизительных действий как к некому контрольному списку, позволяющему ничего не забыть и не упустить. Вы наверное лучше меня знаете, под каким объемом рутинных или спонтанно возникающих активностей может быть погребен руководитель проекта в течении дня. Поэтому я считаю, что данные действия он должен помнить как «отче наш», что безусловно не позволит ему не упустить ничего действительно важного.
Регулярные (чаще всего еженедельный) статус-отчеты – основной инструмент работы в данной процессной области. Я уже говорил это и хотел бы еще раз подчеркнуть дополнительно. При этом, статус-отчет должен содержать полный набор необходимой информации даже если Вам кажется, что часть этой информации будет, мягко говоря, не очень благодушно воспринята руководством. Помните о том, что мальнькие проблемы становятся большими очень быстро, если их не решать. Поэтому страусиное поведение ни к чему хорошему не приведет. И обязательно убедитесь в том, что все ключевые участники получают Ваш отчет регулярно. Даже если Вам кажется, что они его не читают. Получать они его должны всегда.
Ну и пожалуй надо сказать о том, что совсем уж увлекаться правдорубством не стоит. Политика в управлении проектом тоже много значит. У Вас могут быть раздельные отчеты для руководства и для заказчиков. Правило «не выносить сор из избы» отлично работаеть в таких ситуациях.
Не забывайте писать протоколы встреч. На это уходит не так уж много времени, но они не позволяют Вам и, что более важно, другим участникам проекта забыть о принятых решениях или обнаруженных проблемах. В любом случае заказчик уже не сможет так просто откреститься от вопроса о котором Вы его уведомили о чем недвусмысленно будет говорить Ваше письмо в его электронном почтовом ящике.
Еще несколько комментариев:
1. Основным (и, кстати, самым простым) инструментом является еженедельный статус-отчет. Вспомагательными: план управления проектом и протоколы всех встреч.
2. Исходя из таблицы, представленной выше, ориентировочная структура еженедельного статус отчета должна содержать следующие ключевые разделы:
a. Краткое резюме проекта, содержащее общий прогресс и акцентирующее внимание на основных проблемах и открытых вопросах;
b. Вехи прокта, их статус и прогресс;
c. Сделанные и запланированные активности;
d. Риски
e. Открытые вопросы и проблемы, а так же предлагаемые действия по их устранению;
Остальное можно добавлять по желанию;
3. Отчеты и протоколы должны рассылаться всем заинтересованным участникам РЕГУЛЯРНО.
By AAM
| Комментарии к статье "Субъективно о CMMI (часть 6)" (0) |