Зрелость проектных организаций. Методология CMM

Замечательный практический инструмент, созданный в рамках процессного подхода к описанию деятельности проектной организации, в частности, организации, разрабатывающей информационные системы, демонстрирует методология СММ. CMM расшифровывается как Capability Maturity Model, что по смыслу означает примерно "модель зрелости системы управления". В литературе CMM чаще называют моделью зрелости организации, и я тоже буду следовать этой традиции.

История возникновения СММ такова. В конце 80-х гг. прошлого века Министерство обороны США заказало Институту программной инженерии^{1англ. SEI - Software Engineering Institute} Университета Карнеги-Меллон работу по созданию системы критериев для выбора субподрядчиков в проектах разработки программного обеспечения. Работа была закончена в 1991 г., и результатом ее стала модель CMM. Нужно сразу оговориться, что модель не содержит никаких финансово-экономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем.

Структура CMM

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

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

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

Предположение 3. Переход возможен только на следующий по порядку уровень. "Перескочить" через уровень нельзя (точнее, риски для организации при этом резко возрастают).

Таким образом, уровни образуют "лесенку", по которой подымается организация по мере собственного развития. Каждый уровень характеризуется определенными составом и свойствами процессов организации. "Лесенка уровней" СММ получила широкое признание и распространение. Вот как она выглядит.

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

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

Уровень 3 "Определенный". Производственный процесс документирован и стандартизован как для управленческих работ, так и для проектирования. Этот процесс интегрирован в стандартный производственный процесс организации. Во всех проектах используется утвержденная адаптированная версия стандартного производственного процесса организации.

Уровень 4 "Управляемый". Собираются подробные количественные показатели производственного процесса и качества создаваемого продукта. Как производственный процесс, так и продукты оцениваются и контролируются с количественной точки зрения.

Уровень 5 "Оптимизирующий". Постоянное совершенствование процесса достигается благодаря количественной обратной связи с процессом и реализации в нем передовых идей и технологий.

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

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

Рис. 7.1. Структура модели СММ

На рис. 7.1 присутствуют следующие понятия.

Группа ключевых процессов. Как говорится в (Paulk, и др., 1995), "каждая группа ключевых процессов определяет блок связанных работ, в результате выполнения которых достигается совокупность целей, значимых для повышения продуктивности производственного процесса. Например, для группы ключевых процессов "Управление требованиями" (см. рис. 7.2) цель состоит в том, чтобы согласовать требования, выдвигаемые к проекту разработки ПО заказчиком и разработчиком".

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

Рис. 7.2. Распределение групп ключевых процессов по уровням зрелости

Группы ключевых процессов в CMM сопоставляются уровням зрелости ( рис. 7.2), т. е. все практики на уровне взаимодействуют только друг с другом и не взаимодействуют с практиками других уровней. Это позволяет гарантировать полную работоспособность всех процессов на конкретном уровне и, значит, соотносить уровень с законченным этапом развития организации.

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

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

Если эти цели реализуются для всех проектов, то это означает, что организация достигла того уровня зрелости производственного процесса, которому соотнесена данная группа ключевых процессов.

Раздел. Разделы (их на каждом уровне пять и они всегда одни и те же) представляют собой свойства групп ключевых процессов, которые должны быть реализованы на соответствующем уровне. Эти свойства описывают, как процессы реализованы и насколько они легализованы в организации, т. е. официально утверждены и согласованы с корпоративными процедурами, политиками, другими процессами. Вот эти пять разделов.

Обязательства по выполнению

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

Необходимые предпосылки

Описывают предварительные условия, которые должны выполняться в проекте или организации для компетентного внедрения производственного процесса; обычно касаются ресурсов, организационных структур и требуемого обучения.

Выполняемые операции

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

Измерения и анализ

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

Проверка внедрения

В разделе "Проверка внедрения" описываются шаги, позволяющие убедиться в том, что операции выполняются в соответствии с установленным процессом. В этот раздел обычно входят проверки и аудиты со стороны руководства и работы по обеспечению качества ПО.

Ключевые практики. Составляющие разделов, которые выше описывались словами "действия", "работы", "условия, которые должны выполняться", "шаги", "операции" и т. д., имеют в СММ общее название - "ключевая практика". Вот цитата из (Paulk, и др., 1995):

"Каждая группа ключевых процессов выражается ключевыми практиками, выполнение которых способствует достижению целей группы. Ключевые практики описывают инфраструктуру и операции, которые дают наибольший вклад в эффективное внедрение и установление группы ключевых процессов.

Каждая ключевая практика состоит из одного предложения, часто раскрываемого более подробным описанием, в которое могут входить примеры и уточнения. Ключевые практики, иногда называемые ключевыми практиками верхнего уровня, устанавливают основные политики, процедуры и операции для группы ключевых процессов. Компоненты подробного описания часто называются субпрактиками".

Ключевые практики описывают, ЧТО необходимо сделать, но их не следует воспринимать в виде догм, устанавливающих, КАК нужно достигать целей. Цели группы ключевых процессов можно реализовать с помощью альтернативных практик. Интерпретация ключевых практик должна быть разумной, допускающей достижение целей группы ключевых процессов эффективным способом, хотя, возможно, формально и отличающимся от рекомендованного CMM.

Взгляд на деятельность по управлению ИТ, при котором вместо процессов рассматриваются их составляющие - ключевые практики, а процессы присутствуют только виртуально, как что-то, что может быть построено из ключевых практик, выглядит на первый взгляд несколько экзотично. До сих пор задача совершенствования управления ИТ решалась внедрением готовых процессов из эталонной процессной модели. Теперь же возникает множество уровней, содержащих разрозненные (т. е. не объединенные в процессы) ключевые практики, и рекомендуемая последовательность продвижения по уровням. Управление ИТ, согласно CMM, совершенствуется по мере продвижения на более высокий уровень зрелости. Что же происходит при таком продвижении?

В определениях уровней (см. рис. 7.2) появилось такое понятие, как "производственный процесс". Оно же присутствует и в определении группы ключевых процессов, и это не случайное совпадение. Производственный процесс, или, как он точно называется в СММ, Стандартный Производственный Процесс Организации (СППО), - одно из центральных понятий всей модели.