Управление содержанием проекта

Введение в управление содержанием
Область знаний «Управление содержанием проекта» включает в себя включение в проект только тех работ, которые необходимы для его успешного завершения. Главная задача — не упустить обязательные работы и не делать лишних. Любая дополнительная, не включенная в содержание работа при фиксированном бюджете и сроках выполняется за ваш счет и с перерасходом ресурсов.

Содержание делится на две части:
• Содержание проекта — работы, которые вы выполняете.
• Содержание продукта — характеристики и функции создаваемой системы.

В управление содержанием входит пять процессов. Первый из них, инициация, в современной редакции стандартов (например, PMBOK 2004) относится к области управления интеграцией и представляет собой разработку устава проекта.

Процесс 1: Инициация и Устав проекта

Инициация призвана ответить на вопросы: стоит ли вообще начинать проект и какую выгоду он принесет? На выходе процесса появляется Устав проекта (Project Charter) и назначается менеджер проекта. Устав — это документ самого верхнего уровня, дающий общую характеристику проекта без лишних деталей. Он фиксирует базовую концепцию и, как правило, не меняется в дальнейшем.

Устав проекта состоит из следующих разделов:
1. Описание бизнес-потребностей, вызвавших проект. Примеры таких потребностей:
o Прямой заказ от клиента.
o Внутренние потребности вашего бизнеса.
o Технический прогресс и обновление оборудования.
o Общественные нужды.
2. Предварительное описание продукта проекта. Общий подход к решению проблемы, описание системы без учета текущих ограничений.
3. Описание границ проекта. Четко определяется, что входит в проект (какие подразделения, функции), и, что не менее важно, что не входит в содержание. Это предотвращает риски неоднозначного понимания документации заказчиком и исполнителем.
4. Назначение ключевых лиц: руководитель проекта, спонсор, заказчик.
5. Сроки разработки более детальной проектной документации.

Последовательность инициации зависит от типа проекта:
• Внутренний проект. Сотрудник формулирует идею и обосновывает ее (фактически создает Устав). Если идея соответствует стратегии компании, руководство назначает менеджера для дальнейшей проработки.
• Внешний проект. Получив предложение от заказчика, вы проводите анализ осуществимости на основе предварительного плана. Только после этого формируется Устав и принимается решение о принятии проекта.

Процесс 2: Планирование содержания

На этом этапе общая концепция из Устава превращается в более детальный документ — Описание содержания проекта (Project Scope Statement). В отличие от Устава, этот документ может и будет изменяться в ходе проекта, но только по утвержденным правилам.

Документ «Описание содержания проекта» включает:
• Обоснование проекта — детальное описание причин его возникновения.
• Описание продукта проекта — подробные характеристики создаваемой системы.
• Результаты проекта — что должно быть достигнуто.
• Цели и критерии их достижения для различных фаз и этапов.
• Границы проекта.
• Стратегический подход к исполнению — какие процессы управления проектами будут использоваться и с какой степенью детализации.

Результатом процесса также является План управления содержанием, который отвечает на вопросы:
• Как будет отслеживаться исполнение содержания (через контроль работ, бюджета или загрузки ресурсов)?
• Как инициируются и кем утверждаются изменения?
• Каким образом документируются все изменения?

Процесс 3: Уточнение содержания и создание ИСР

Этот процесс заключается в создании Иерархической структуры работ (ИСР) (Work Breakdown Structure, WBS). Это детальный, структурированный перечень всех работ проекта. На этом этапе нас не интересуют связи между работами, их длительность или ресурсы — только их полный список.

Методы создания ИСР:
• Декомпозиция — разбиение крупных работ на более мелкие.
• Использование шаблонов для типовых проектов.

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

Когда прекращать декомпозицию?

• Вы можете реально оценить стоимость и трудозатраты элемента.
• Элемент дальше не делится с точки зрения логики.
• Элемент выполняется достаточно быстро (например, до 80 часов для ИТ-проектов).

Помимо работ, в ИСР включаются события (вехи) (Milestones) — работы с нулевой длительностью, фиксирующие важные результаты. Для каждого события задаются проверяемые условия (например, «написано 150 строк кода»). События бывают двух типов:
• Контрольные — отмечают достижение значимого результата проекта.
• Интерфейсные — фиксируют изменение ситуации в проекте, например, смену сфер ответственности между ролевыми кластерами, как в модели МСФ.

В процессе детализации ИСР могут выявиться упущения, что приводит к изменениям в Описании содержания проекта.

Процессы 4 и 5: Подтверждение и контроль содержания

• Подтверждение содержания — это формальная приемка результатов проекта. Все сделанное должно быть проверено на соответствие и зафиксировано.
• Контроль изменений содержания — это отслеживание и управление корректировками. Любое изменение содержания (например, исключение подсистемы) влечет за собой каскад изменений в планах тестирования, управления рисками, развертывания и т. д. Все они должны быть проведены и задокументированы согласованно.

Основные причины для изменений:
1. Изменения во внешней среде (законодательство, правила учета).
2. Ошибки или упущения при описании содержания.
3. Появление новых технологий.
4. Изменение бизнес-потребностей заказчика.
5. Наступление рисковых событий.

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

Исходная точка любого проекта — это неопределенность, которая снимается путем последовательной детализации знаний о будущем результате. Главная ценность представленного подхода заключается в переходе от разрозненных идей к формализованной системе обязательств, что минимизирует предпринимательские и управленческие риски. На этапе инициации происходит принципиальное отделение стратегического «зачем» от тактического «как». Заказчик и исполнитель договариваются не о функциональности кнопок, а о бизнес-потребности, которую необходимо удовлетворить. Фиксация этого в Уставе создает незыблемую точку отсчета, защищающую от самого опасного риска — когда готовый продукт оказывается никому не нужным, потому что изначальная потребность не была осознана.

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

Центральный этап — создание Иерархической структуры работ — представляет собой процесс принудительной детализации, который не оставляет места для неявных допущений. Принципиально важным является одновременная декомпозиция и действий, и продукта. На практике менеджеры часто сосредотачиваются только на одном, что ведет к провалам: если детализировать только работы, можно упустить создание важного компонента системы, если только продукт — забыть о таких действиях, как закупка или обучение персонала. Критерий остановки декомпозиции (оценка в 80 часов) служит не формальным правилом, а границей управленческого горизонта — работа должна быть достаточно мала, чтобы ее можно было однозначно поставить сотруднику и проконтролировать.

Завершающие процессы приемки и контроля формируют дисциплину обратной связи. Внедрение формальной верификации каждого результата и сквозного документирования всех изменений защищает бюджет и сроки от незаметного расползания границ проекта. Практическая польза от понимания перечисленных причин изменений (от смены законов до падения рынка) в том, что они перестают быть «неожиданностями» и становятся частью матрицы рисков. Таким образом, от первого документа до финальной приемки выстраивается сквозная прослеживаемость: любое действие обосновано бизнес-потребностью, зафиксированной в самом начале.