Второй уровень зрелости. Структура

Записаться

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

Управление требованиями (Requirements Management)

Первая цель — установить контроль над системными требованиями к ПО и сформировать базовую линию (baseline).

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

Процедура управления изменениями:

1. запрос на изменение регистрируется;
2. изменение анализируется всеми заинтересованными лицами;
3. если заинтересованные лица подтверждают готовность, изменение планируется: оцениваются последствия для сроков, ресурсов, стоимости;
4. изменение реализуется.

Если требование не входит в базовую линию, его можно менять проще. Например, формат документации, разбиение на разделы, шрифт не всегда являются принципиальными.

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

Планирование проекта (Project Planning)

Цели:

1. Задокументировать обоснования оценок: продолжительность, трудоёмкость, затраты, производительность.
2. Задокументировать план-график, привязку к календарю и обязательства.
3. Получить согласие задействованных групп и сотрудников с обязательствами по проекту.

Это важно, потому что нет централизованного управления ресурсами. Люди могут работать в нескольких проектах и сами планируют свою занятость. Согласие с обязательствами помогает избежать перегрузки или простоя.

Отслеживание хода проекта и контроль (Project Monitoring and Control)

Цели:

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

Управление производственным субподрядом (Supplier Agreement Management)

Цели:

• выбрать квалифицированных субподрядчиков;
• заключить контракты о взаимных обязательствах между генподрядчиком и субподрядчиками;
• обеспечить информационный обмен между сторонами;
• отслеживать фактические результаты работы и производительность субподрядчика.

Обеспечение качества (Quality Assurance)

Цели:

• планировать работы по обеспечению качества;
• объективно проверять соответствие программных продуктов и технологических операций стандартам и процедурам;
• распространять информацию о работе по качеству среди задействованных групп;
• эскалировать руководству вопросы качества, которые не решаются на уровне проекта.

Управление конфигурацией ПО (Software Configuration Management, SCM)

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

Для этого нужно:

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

Цели управления конфигурацией:

1. управлять конфигурацией на плановой основе: к какому сроку какие артефакты должны появиться, зафиксироваться и перестать меняться;
2. определить выбранные промежуточные программные продукты, сделать их управляемыми и доступными. Если продукт не выложен и недоступен, его фактически нет;
3. управлять изменениями в определённых промежуточных программных продуктах;
4. распространять информацию о состоянии и содержании базовых линий конфигурации.

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

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

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

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

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