Источник
CMMI (Capability Maturity Model Integration)
Пост о происхождении CMMI, сильных и слабых сторонах зрелостных моделей и границах их применимости.
Источник
CMMI (Capability Maturity Model Integration)
Пост о происхождении CMMI, сильных и слабых сторонах зрелостных моделей и границах их применимости.
CMMI и зрелость процессов
CMMI исторически помогала организациям перейти от хаотичной поставки к предсказуемому процессу. Но в современной продуктовой среде полезнее обсуждать не «какой уровень зрелости выбить», а какую конкретную проблему delivery, качества или надежности мы закрываем прямо сейчас.
TL;DR
- CMMI вырос из оборонного контекста США как модель дисциплины процессов и предсказуемости поставки.
- Сильная сторона модели - единый язык зрелости и управляемость сложных сервисных контуров.
- Слабая сторона - высокая стоимость внедрения, документационный перегруз и риск бюрократизации.
- Для продуктовых компаний ценность обычно в отдельных практиках, а не в гонке за уровнем 5.
История модели и контекст появления
Конец 1980-х
Появление CMM
SEI при Carnegie Mellon разработал Capability Maturity Model для Department of Defense, чтобы снизить вариативность и риски в поставке ПО.
2000
Переход к CMMI
Несколько maturity-моделей были объединены в Capability Maturity Model Integration, чтобы расширить область применения.
Дальше
Наследие подхода
Логика зрелости процессов повлияла на более современные модели в delivery и management, включая KMM и корпоративные архитектурные maturity-фреймворки.
Capability и Maturity
Capability (возможности)
Способность организации стабильно достигать бизнес-цели через воспроизводимые процессы, роли и артефакты.
Maturity (зрелость)
Степень эволюции процессов во времени: от ad-hoc и реактивного режима к управляемому улучшению на основе данных.
5 уровней зрелости CMMI
1. Initial
Процессы непредсказуемы и реактивны.
Риск: Результат зависит от героизма людей, а не от системы.
2. Managed
Процессы планируются и исполняются по политикам.
Риск: Появляется дисциплина, но возможен локальный оптимум без общего стандарта.
3. Defined
Подходы описаны, стандартизированы и согласованы между командами.
Риск: Стандартизация может начать тормозить экспериментирование.
4. Quantitatively Managed
Процессы измеряются и контролируются статистически.
Риск: Легко подменить реальность прокси-метриками и потерять контекст.
5. Optimizing
Системное улучшение через обратную связь и инновации.
Риск: Высокая стоимость поддержания модели и большой governance-след.
Что модель действительно дает
Рост предсказуемости и эффективности за счет стандартизации критичных процессов.
Стабилизация качества через согласованный quality bar и явные контрольные точки.
Репутационный плюс для сервисных компаний, особенно в заказной и регуляторной среде.
Более управляемое масштабирование на росте организационной сложности.
Ограничения и издержки
Complexity and cost: внедрение требует времени, ресурсов, обучения и большого объема документации.
Rigidity: жесткие рамки могут замедлять появление новых инженерных практик и технологий.
Bureaucracy: при плохом применении процесс начинает обслуживать бумагу, а не результат.
Lack of customizability: единая модель не всегда адекватно ложится на продуктовые и bigtech-контексты.
Границы применимости
Где CMMI обычно работает
- Крупная сервисная разработка с контрактами, аудитами и сильной ролью соответствия процессам.
- Регулируемые отрасли, где нужна доказуемость управляемости и повторяемости поставки.
- Организации, в которых главная проблема - вариативность процесса и срывы базовой дисциплины.
Где модель часто буксует
- Продуктовая среда с высокой неопределенностью и частой сменой гипотез.
- Контексты, где скорость learning loop критичнее, чем тяжелая стандартизация.
- Команды, которым важнее локальные инженерные практики, чем формальная сертификационная гонка.
Типичные антипаттерны
Ставить целью сертификат или уровень зрелости, не сформулировав проблему бизнеса.
Насаждать единый процесс без учета масштаба команды, домена и природы неопределенности.
Оценивать людей по «правильности бумажного следа», а не по влиянию на надежность и delivery.
Пытаться «дожать level 5» как универсальный KPI зрелости всей организации.
Практики вместо гонки за уровнем
RFC + ADR как минимальный управляемый контур для архитектурных решений и прозрачности trade-offs.
Техрадар как механизм управляемого внедрения/вывода технологий без централизованной бюрократии.
Практики надежности: observability, SLI/SLO/SLA и бюджет ошибок для балансировки скорости и стабильности.
Метрики потока (lead time, throughput, WIP) для поиска узких мест вместо формального подсчета process-compliance.
Когда уровень 5 может быть оправдан
Обычно только в среде с жесткими требованиями комплаенса и высокой ценой процессных сбоев. Для большинства продуктовых команд выгоднее выбирать узкие практики с быстрым обратным эффектом, чем строить тяжелую сертификационную надстройку.
Источники
Связанные главы
Итог для технического лидера
CMMI полезна как историческая рамка дисциплины процессов. Но в реальной продуктовой работе выигрыш чаще дает не maturity-level как цель, а короткий цикл: проблема -> практика -> измерение эффекта -> корректировка.