Второй уровень: мониторинг и управление подрядчиками
Нужно мониторить ход проекта. План есть, значит, надо смотреть, как он исполняется, контролировать проект и при существенных отклонениях предпринимать корректирующие воздействия. Это следующая группа ключевых процессов.
Управление производственным субподрядом означает, что на втором уровне нужно определить основные принципы и методы управления подрядчиками. Какие принципы? Понять, как заключаются договоры, как контролируется качество их работ. Как поступать, если субподрядчик не выполняет обязательства? Это должно быть формализовано.
Обеспечение качества — отдельная и приоритетная группа ключевых процессов. Требованиями управляли не зря: требования собирали и анализировали, потому что они пригодятся для управления качеством.
Последняя группа ключевых процессов — управление конфигурацией ПО (программного обеспечения). Это специфическая группа; о ней можно поговорить отдельно. Такие виды работ организация должна выполнять на втором уровне.
Почему выбраны такие группы процессов
Возникает вопрос: почему именно такие группы? Так решили авторы CMM. На третьем уровне будут совершенно другие группы ключевых процессов: например, экспертные оценки, межгрупповая координация, координация производственного процесса.
При переходе с одного уровня на другой не происходит накопление групп ключевых процессов. Они заменяются на другие, обновляются. То, что было на втором уровне, уходит и замещается тем, что должно быть на третьем. Это понятно: второй уровень предполагает большую самостоятельность проектных групп. Они ограничены политиками руководства, но остальное делают на свое усмотрение. На третьем уровне такой самостоятельности уже нет. Политики руководства заменяются стандартным производственным процессом, и организация начинает работать по-другому. Старые навыки и подходы ей не нужны, потому что деятельность перестраивается. Поэтому нет накопления — есть качественное изменение.
Логика переходов между уровнями
Организация не перескакивает с уровня на уровень. Теоретически это возможно, но практически связано с большими рисками. За переходами стоит накопление опыта. Нельзя придумать стандартный производственный процесс сразу, если на первом уровне ничего толком не понятно и работа идет неизвестно как. Можно, конечно, перейти сразу на третий уровень и даже сочинить стандартный процесс. Но он не будет держаться ни на каком опыте, кроме опыта хаотического выполнения работ.
Правильнее так: с хаотического начального уровня перейти на повторяемый, поработать в разных проектах по-разному, посмотреть, у кого что получалось лучше или хуже, проанализировать опыт и на его основе придумать производственный процесс. Это и будет началом перехода на третий уровень. Это естественный логический подход.
Цели и оценка зрелости
Проекты разные. Даже на втором уровне они по-разному будут достигать своих целей. CMM говорит, что важны именно цели групп ключевых процессов, которые впервые появляются на втором уровне. Конкретные ключевые практики, степень их регламентации политиками и возможность изменений участниками проектной команды на этом уровне не очень важны. Цель должна достигаться.
Если организация выполняет все ключевые практики, написанные в CMM для второго уровня, она с гарантией достигает цели. Если выполняет не все, значит, выполняет другие практики, не описанные в CMM, которые могут помочь достичь цели. Цель она достичь обязана.
Отсюда важное следствие: нет механического, простого формального способа оценки организации. Никогда не будет единообразия. Люди не выполняют буквально то, что написано в CMM, не называют это теми же словами и не получают одинаковые результаты. Отклонения всегда будут. Но с точки зрения оценивающего человека может быть очевидно, что, несмотря на различия, цель достигается.
Пример. Есть группа ключевых процессов «управление требованиями». В результате выполнения ключевых практик должен появиться документ «Техническое задание». Практики могут называться «подготовка технического задания», «анализ технического задания». В другой организации это называется не техническое задание, а «требования к продукту». Если оно содержит примерно то же самое с точки зрения CMM, считать это несоответствием бессмысленно. Соответствие CMM отдается на усмотрение человека, который оценивает компанию.
Жесткое требование к уровню зрелости
Компания достигла определенного уровня зрелости, если цели групп ключевых процессов достигнуты во всех проектах компании, выполнявшихся на настоящий момент. Для второго уровня: в каждом проекте есть управление требованиями, организованное как в CMM или близко к этому; в каждом проекте есть планирование проекта с работами из CMM или близкими; и так далее.
Если есть хотя бы один проект, в котором хотя бы одна группа ключевых процессов не достигает цели, организация не находится на этом уровне зрелости. Если хотя бы в одном проекте требованиями управляют не так, как написано в CMM, и какие-то работы отсутствуют, достижения всех остальных не имеют ценности. Организация находится на первом уровне.
Почему такая жесткость? На первые три уровня смотрит клиент. Если из двадцати проектов в одном что-то работает не так, как во всех остальных, это означает, что именно в его проекте может произойти так же. Факт, что девятнадцать проектов работают идеально, не важен, если его проект может выпасть из регламента. Подход последовательный и логичный.
CMM включает детальное описание фактически только двух уровней: второго и третьего. Первый не описан, потому что там нечего описывать. Четвертый и пятый уровни описаны только на уровне названий, групп ключевых процессов и целей. Ключевые практики там не определены; считается, что каждая организация должна сделать это самостоятельно.
Краткие итоги
Практическая ценность модели зрелости проявляется не в механическом внедрении предписанных практик, а в умении организации выстраивать управляемый переход от разрозненных действий к устойчивым результатам. Ключевая идея — цель важнее формы. Если процесс приводит к нужному результату, различия в терминах, документах и внутренних регламентах не должны автоматически считаться недостатком. Это снижает риск бюрократизации и позволяет сохранять пространство для инженерных решений. Однако такая свобода уравновешивается строгостью оценки: уровень зрелости подтверждается только тогда, когда цели достигаются во всех проектах, а не в среднем или в лучшем из них.
Для практики это означает, что улучшение нельзя сводить к написанию стандартов. Сначала необходимо накопить опыт, увидеть устойчивые и проблемные места, а затем формировать общий процесс. Преждевременная стандартизация опасна: она создает видимость порядка, но не опирается на реальные данные. Переход между уровнями — это не добавление новых практик к старым, а качественная перестройка способа работы. Поэтому организациям важно управлять не только внедрением, но и отказом от устаревших моделей поведения.
Оценка зрелости должна быть экспертной: она требует анализа целей, контекста и фактических результатов. Для заказчика такая логика важна потому, что он оценивает не абстрактный средний уровень, а риск того, что его собственный проект окажется исключением. Практическое применение модели состоит в диагностике всех проектов, выявлении разрывов по целям, развитии повторяемости и только затем — в переходе к стандартизации. Это делает управление процессами не формальным аудитом, а инструментом снижения неопределенности и повышения предсказуемости.
Уровни и описание. CMM включает пять уровней зрелости, но детально описывает второй и третий. Первый не описан, так как в нем нет устойчивых процессов. Четвертый и пятый даны только через названия, группы ключевых процессов и цели; ключевые практики организация определяет сама.
Второй уровень. Ключевые группы процессов: управление требованиями; планирование проекта; мониторинг хода проекта; управление производственным субподрядом; обеспечение качества; управление конфигурацией ПО. Мониторинг включает контроль исполнения плана и корректирующие воздействия при существенных отклонениях. Управление субподрядом требует принципов и методов: договоры, контроль качества, действия при невыполнении обязательств. Обеспечение качества — отдельная приоритетная группа. Управление конфигурацией ПО — специфическая группа.
Логика переходов. Группы ключевых процессов не накапливаются, а заменяются. На втором уровне проектные группы самостоятельны в рамках политик руководства. На третьем политики заменяет стандартный производственный процесс. Организация не перескакивает уровни: сначала повторяемый опыт, анализ разных проектов, затем стандарт. Преждевременный стандарт не опирается на реальную практику.
Цели и оценка. Важны цели групп ключевых процессов. Конкретные практики и термины менее важны. Если практики CMM выполняются, цель достигается. Если не все, но цель достигается другими практиками — это допустимо. Нет механической оценки: всегда есть отклонения. Оценивающий человек решает, достигнута ли цель. Пример: «Техническое задание» и «Требования к продукту» могут соответствовать CMM при близком содержании.
Уровень зрелости. Организация достигает уровня, если цели групп ключевых процессов достигнуты во всех проектах, выполнявшихся к настоящему моменту. Если хотя бы в одном проекте хотя бы одна группа не достигает цели, уровень не подтверждается. Достижения остальных проектов не компенсируют. Это жестко, потому что клиент смотрит на первые три уровня и рискует попасть именно в проблемный проект.
Вывод. CMM — не формальный чек-лист, а модель достижения целей через зрелость процессов. Практика: накапливать опыт, анализировать вариативность, стандартизировать после повторяемости, оценивать цели во всех проектах.
1. На втором уровне важны цели групп ключевых процессов, а не буквальное совпадение практик.
2. Группы ключевых процессов при переходе между уровнями заменяются, а не накапливаются.
3. Второй уровень дает проектным группам самостоятельность в рамках политик руководства.
4. На третьем уровне политики руководства заменяет стандартный производственный процесс.
5. Переход между уровнями должен опираться на накопленный и проанализированный опыт.
6. Преждевременный переход создает процесс, не подкрепленный реальной практикой.
7. Соответствие CMM оценивает человек, учитывая достижение цели, а не только термины.
8. Разные названия документов допустимы, если содержание близко к требованиям CMM.
9. Уровень зрелости достигается только при выполнении целей во всех текущих проектах.
10. Один проблемный проект обнуляет достижения остальных для подтверждения уровня.
11. Жесткость оценки связана с риском клиента оказаться в проблемном проекте.
12. Детально описаны второй и третий уровни; четвертый и пятый — только названиями и целями.
1. Какие группы ключевых процессов относятся ко второму уровню?
2. Что происходит с группами ключевых процессов при переходе на следующий уровень?
3. Почему организация не должна перескакивать уровни?
4. Чем второй уровень отличается от третьего по степени самостоятельности проектных групп?
5. Что важнее на втором уровне: цели или конкретные ключевые практики?
6. Почему нет механического формального способа оценки организации?
7. Как оценивающий человек определяет соответствие CMM при различиях в терминах?
8. Когда организация может считаться достигшей уровня зрелости?
9. Почему наличие одного проблемного проекта влияет на оценку всей организации?
10. Чем опасен преждевременный переход к стандартному производственному процессу?
11. Какие уровни CMM описаны детально, а какие только на уровне названий и целей?
12. Что означает замена политик руководства стандартным производственным процессом?
