CMMI. Структура - 1

Записаться

1. Успех CMM и первые CMM-подобные методики

CMM (Capability Maturity Model, модель зрелости процессов) в таком виде просуществовала долго и имела большой успех. При первом знакомстве её тяжело воспринимать: кажется, что это нагромождение похожих слов. Но если внимательно разобраться, видно простую, ясную и логичную конструкцию. Поэтому люди стали применять CMM на практике.

Возникло целое направление CMM-подобных методик — не только для организаций, занимающихся разработкой ПО, и не только для проектных организаций, но и для самых разных областей. SEI (Software Engineering Institute, Институт программной инженерии) усилил этот процесс. Через три года после появления CMM он разработал People CMM (People Capability Maturity Model, модель зрелости управления персоналом) — методику оценки деятельности HR-департамента (Human Resources, управление персоналом). Уровни зрелости HR-департамента там прописаны, и они нетривиальны.

Эту методику не рекомендуют для массового чтения: она очень большая, толстая и написана специально для не-IT-специалистов, то есть для HR-менеджеров. Текст использует типичные HR-понятия и другой уровень формализма, чем CMM. Документ занимает чуть ли не 500 страниц. Но несколько первых страниц стоит прочитать, чтобы увидеть подход: он сохранился таким же, как в CMM, хотя ключевые практики совершенно другие.

2. Размножение моделей и потеря сопоставимости

Постепенно разные организации стали придумывать CMM для своих целей. Сложилась неприятная картина. Часть организаций разрабатывала CMM-подобные модели для внутренних видов деятельности и структурных единиц, которые рассматривались как организации. В некоторых организациях одновременно присутствовали две-три разные модели CMM.

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

3. Появление CMMI

SEI понял, что нужен следующий шаг, и разработал комплексную методику CMMI (Capability Maturity Model Integration, интегрированная модель зрелости). Она предполагала, что все разные виды деятельности должны оцениваться на основе одного и того же подхода.

В 2001 году появилась первая версия CMMI 1.0. Это был очень сложно читаемый и огромный документ — «концептуальная модель». Он описывал общую систему понятий, чтобы на её основании строить модели оценки разных структурных единиц или организаций, сравнимые между собой. Предполагалось, что все заинтересованные изучат концептуальную модель и будут строить конкретные модели оценки. Этого не случилось: концептуальная модель была слишком сложной и достаточно сырой.

После нескольких итераций появились версии 1.0, 1.1, 1.2, 1.3, затем 2.0, и уже идёт работа над версией 2.1. SEI отказался от универсальных проектов с большим замахом и к моменту появления версии 1.3 разработал три CMMI-подобные модели. Они описывают три вида деятельности организации, или три вида организаций, или три вида деятельности — смотреть можно по-разному.

Это:

• инженеринговая деятельность;
• закупочная деятельность;
• деятельность по предоставлению услуг.

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

Три модели называются:

• CMMI for Development (CMMI-DEV) — для разработки;
• CMMI for Acquisition (CMMI-ACQ) — для закупок;
• CMMI for Services (CMMI-SVC) — для услуг.

4. Смена объекта оценки

Идея ядра CMMI сильно отличается от идей, положенных в основу CMM. Первое и главное отличие: организация или структурная единица больше не рассматривается как основной объект, о зрелости которого можно говорить. Точнее, организацию можно рассматривать как объект, у которого есть зрелость, но это скорее использование методологии CMMI для совместимости с тем, что было сделано раньше. Придумана она была не для этого.

Вместо организации, которая выполняет группы ключевых процессов, рассматриваются сами эти группы. Речь идёт о зрелости каждой отдельной группы ключевых процессов. Поэтому с точки зрения результата оценки получается то, что называется профиль организации. Одна группа процессов имеет такой-то уровень зрелости, другая — другой, третья — третий. Получается «гребёнка», по которой видно, насколько эффективны и институализированы (институционализированы) те или иные группы ключевых процессов.

Терминология тоже была заменена. Вместо группы ключевых процессов теперь говорится процессная область (process area). Смысл тот же: это такой же набор практик без связей между ними, такой же контейнер, как в CMM. У процессной области есть цель — специфическая цель (specific goal). Целей может быть несколько. Для достижения этих целей служат специфические практики (specific practices). Это то же самое, что ключевые практики в CMM.

5. Практики, субпрактики и общие элементы

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

Практики описываются очень подробно, даже подробнее, чем в CMM. Описывается, как практика выглядит, какие примерно входы и выходы она имеет. Рассматриваются примеры выходов с подробными комментариями. В некоторых случаях практика распадается на субпрактики (subpractices) — более мелкие единицы работ, у которых тоже есть свои определённые выходы.

Здесь пока нет принципиальных отличий от CMM. Отличия начинаются в правой части общей картины, где указаны общие цели (generic goals), общие практики (generic practices) и далее.

Краткие итоги

Развитие моделей зрелости показывает, как популярная методика неизбежно порождает волну адаптаций. Сначала единая модель даёт ясный язык и критерии, но затем разные подразделения и области создают собственные версии. В результате оценки теряют сопоставимость: цифры выглядят объективными, но за ними стоят разные шкалы, практики и допущения. Практический вывод — нельзя сравнивать подразделения по уровню зрелости, если модели не сведены к общему ядру. Это важно для управленческих решений, рейтингов, распределения ресурсов и оценки эффективности. Интеграция нужна не ради унификации ради унификации, а чтобы создать общую систему понятий и правила сопоставления. Однако чрезмерно сложная концептуальная модель не работает: если документ требует огромных усилий для освоения, организации не начнут строить на его основе сравнимые модели. Поэтому зрелая методология развивается итерационно: от универсального проекта к набору согласованных моделей для разных видов деятельности. Практический смысл трёх моделей в том, что разработка, закупки и услуги оцениваются по единой логике, но с сохранением специфики. Это снижает риск методологического разрыва между подразделениями и позволяет видеть организацию как набор процессов, а не как монолит. Переход от оценки организации к оценке процессных областей меняет управленческую оптику. Вместо одного усреднённого уровня появляется профиль: сильные и слабые зоны видны отдельно. Это даёт более точную основу для улучшений, приоритизации и контроля. Специфические цели и практики описывают, что именно должно достигаться в данной области. Общие цели и практики показывают, насколько устойчиво и институционально эти практики внедрены. Такое разделение помогает отличать содержание работы от качества её закрепления. Субпрактики детализируют действия до уровня, пригодного для внедрения, обучения и аудита. В прикладном смысле материал полезен для построения систем оценки, совместимых между подразделениями, и для выбора между единой жёсткой моделью и семейством согласованных моделей. Главный урок: стандартизация эффективна, когда сохраняет общее ядро, допускает специфику и остаётся практически осваиваемой.