Феномен CMMI. На бумаге это тяжёлая «процессная» модель для аудита, но в реальности — вполне прикладной инструмент для IT-управления. В посте разберём, как читать уровни зрелости CMMI, что такое области процесса и как применять эту модель к планированию, требованиям, качеству и рискам уже сейчас 💪

Напомню, что все это я изучаю в рамках своего курса

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

Для IT-разработки сильная сторона CMMI в том, что он хорошо «закрывает» именно управленческие провалы вокруг engineering: оценка, планирование, требования, риски, контроль качества.

Уровни зрелости в модели очень простые: - ML1 Initial — работа идёт реактивно и непредсказуемо; - ML2 Managed — проект уже планируется, измеряется и контролируется; - ML3 Defined — появляется общий стандарт работы на уровне компании; - ML4 Quantitatively Managed — ключевые процессы начинают управляться на данных; - ML5 Optimizing — компания системно улучшает процесс, а не только чинит сбои.

Что мне в ней показалось полезным:

1. Модель дает готовый словарь областей процесса (process areas). Например:

- проблемы прогноза — это PP (Project Planning) и PMC (Project Monitoring and Control);

- бесконтрольные изменения — это REQM (Requirements Management) и CM (Configuration Management);

- позднее обнаружение дефектов — это VER (Verification), VAL (Validation) и PPQA (Process and Product Quality Assurance);

- повторяющиеся сбои — это CAR (Causal Analysis and Resolution);

- разные способы ведения проектов в разных командах — это OPD (Organizational Process Definition), OPF (Organizational Process Focus) и IPM (Integrated Project Management).

2. CMMI оценивает не только наличие документов, но и сильные и слабые стороны внедрения процесса, устойчивость применения и привычку работать по процессу. Иными словами, важно не «есть ли шаблон», а «работает ли он под нагрузкой»

3. CMMI-DEV прямо предупреждает: организации нередко слишком рано начинают собирать подробные количественные данные, а потом обнаруживают, что данные неинтерпретируемы из-за несогласованности процессов и определений измерений. Для проджекта это означает: сначала понять, насколько у вас вообще зрелый способ работы, потом определить, какой именно кусок процесса ломается, и только потом что-то улучшать.

Давайте прикинем, как можно это использовать прямо сейчас 🤔

Первое — переводить проблемы проекта в язык process areas.

Второе — собрать для проекта минимальную систему ML2. На практике это означает: единый способ планирования, прозрачное сравнение plan vs fact, управляемый change log по требованиям, базовые метрики, понятный статусный ритм, конфигурационную дисциплину и простую объективную проверку качества. Для большинства IT-команд именно это даёт наибольший эффект на коротком горизонте.

Третье — поверх этого добавить лёгкий слой регламентов из ML3. Это значит договориться о нескольких общих правилах: какие артефакты обязательны, какие метрики считаются одинаково, как проекты адаптируют общий процесс под свой масштаб, какие решения фиксируются обязательно, и стандартный онбординг для PM или тимлидов.

Четвёртое — не ставить CMMI рядом с agile как отдельную систему. Гораздо полезнее встроить его в уже существующие практики: - уточнение и декомпозиция бэклога и история изменений могут работать как REQM, - планирование спринта и релиза — как PP, - review прогноза и статуса — как PMC и MA, - code review и тестовые артефакты — как VER/VAL, - ретроспектива с корректирующими действиями — как CAR-litе.

Слышали когда-нибудь про CMMI? Подход выглядит супер понятным, но нормальных кейсов использования в РФ не нашел. Интересно понять причину. Может для нашего рынка используется какая-нибудь альтернатива?