Записаться

Представление руководства о процессе

В книге по CMM есть наглядная картинка, показывающая, как руководство может представлять процесс.

• Первый уровень — бесформенное облако со входом и выходом.
• Второй уровень — последовательность работ. Как они выполняются, непонятно: это чёрные ящики. Но последовательность задана политиками руководства.
• Третий уровень — работы обозначены маленькими прямоугольниками, детализированы, понятно, как они устроены.
• Четвёртый уровень — на работы «навешены» датчики, то есть метрики (metrics), связанные с процессом.
• Пятый уровень — часть стандартного процесса заменяется другим фрагментом, который лучше с точки зрения метрик.

Если загуглить CMM, можно получить примерно такое описание. Но это лишь неформальное введение. Сама методика и модель гораздо сложнее.

Формальная логика уровней

Любой уровень зрелости описывается по одним и тем же формальным правилам. Уровень содержит группы ключевых процессов (Key Process Areas, KPA). Группы состоят из ключевых практик (key practices).

Ключевые практики — это задачи процессов в терминологии стандарта 12207 (ISO/IEC 12207). Это отдельные понятные работы с понятными входами и выходами, которые решают конкретную задачу. Заранее определённого порядка их выполнения нет. Ключевые практики объединяются в группы, работающие на общую цель. Поэтому у группы ключевых процессов есть цель.

Группа ключевых процессов — это контейнер. На каждом уровне есть свои группы и свои ключевые практики. Если говорят, что группа ключевых процессов должна быть выполнена, это означает: все входящие в неё практики должны быть выполнены.

Почему «ключевые» и «группы»

Слово «ключевые» подчёркивает, что рассматриваются не все процессы организации, а только важные с точки зрения управления разработкой ПО. Например, процессов управления персоналом в CMM нет.

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

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

Разделы как атрибуты практик

Ключевые практики могут иметь разное назначение. Их можно условно «выкрасить» в разные цвета.

• Белые практики описывают, как управляем разработкой.
• Синие практики говорят о том, как измеряем и мониторим результаты работы.
• Жёлтые практики описывают, что организация должна сделать, чтобы основные практики действительно выполнялись: какие организационные решения принять, какие нормативные документы подготовить.

Таких цветов немного. Они одни и те же на всех уровнях. Раздел — это атрибут практики, показывающий, для чего она нужна. На разных уровнях задаются одни и те же вопросы: как выполнять, как измерять, что организация должна сделать.

Пример второго уровня

На первом уровне групп ключевых процессов и практик нет: процесс выполняется неформально, хаотически или сильно зависит от людей.

На втором уровне появляются контейнеры. Например, в CMM есть группа ключевых процессов «Управление требованиями». Авторы методики считают, что управление требованиями — важнейшая деятельность, которую нужно формализовать уже на втором уровне. Это одна из первых работ, с которых надо начинать.

Следующая группа — «Планирование проекта». Мало научиться управлять требованиями, надо ещё научиться планировать проект. Как это сделать, описано в ключевых практиках, входящих в эту группу.

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

Переход от наглядной схемы к формальным правилам показывает, что зрелость процесса — не оценочный ярлык, а способ упорядочить наблюдение за управленческой практикой. Практическая ценность такой логики в том, что она позволяет отделить существенное для управления разработкой от организационных деталей, которые не влияют на оценку. Если группа ключевых процессов рассматривается как контейнер, то оценка сводится к проверке наличия и взаимосвязи практик, а не к реконструкции всей иерархии компании. Это снижает субъективность и делает сравнение уровней воспроизводимым.

Разделение практик по разделам-атрибутам даёт диагностическую рамку: можно увидеть, где организация ограничивается декларацией деятельности, где отсутствует измерение, а где нет организационного обеспечения. На практике это помогает выбирать улучшения не по принципу «внедрить всё сразу», а по слабому звену. Например, если управленческие практики описаны, но не подкреплены мониторингом, улучшения будут неустойчивыми. Если нет организационных решений, даже хорошие практики останутся локальной инициативой.

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

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