Руководство к Своду знаний по управлению проектами (Руководство PMBOK) - Коллектив авторов

Рис. 5–3. Диаграмма потоков данных планирования управления содержанием

План управления содержанием – компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться. Разработка плана управления содержанием и детализация содержания проекта начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), последних одобренных вспомогательных планов плана управления проектом (раздел 4.2.3.1), исторической информации, которая содержится в активах процессов организации (раздел 2.1.4) и других соответствующих факторов среды предприятия (раздел 2.1.5). Данный план помогает снизить риск расползания содержания проекта.

5.1.1. Планирование управления содержанием: входы

5.1.1.1. План управления проектом

Описан в разделе 4.2.3.1. Одобренные вспомогательные планы плана управления проектом используются для создания плана управления содержанием и оказывают влияние на подход, применяемый для планирования содержания и управления содержанием проекта.

5.1.1.2. Устав проекта

Описан в разделе 4.1.3.1. Устав проекта используется для предоставления контекста проекта, необходимого для планирования процессов управления содержанием. Он предоставляет высокоуровневое описание проекта и характеристики продукта из описания работ проекта.

5.1.1.3. Факторы среды предприятия

Описаны в разделе 2.1.5. Факторы среды предприятия, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего:

• организационную культуру,

• инфраструктуру,

• управление персоналом,

• ситуацию на рынке.

5.1.1.4. Активы процессов организации

Описаны в разделе 2.1.4. Активы процессов организации, которые могут оказывать влияние на процесс планирования управления содержанием, включают в себя, среди прочего:

• политики и процедуры,

• историческую информацию и базу накопленных знаний.

5.1.2. Планирование управления содержанием: инструменты и методы

5.1.2.1. Экспертная оценка

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

5.1.2.2. Совещания

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

5.1.3. Планирование управления содержанием: выходы

5.1.3.1. План управления содержанием

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

• процесс подготовки подробного описания содержания проекта;

• процесс, который позволяет создавать ИСР из подробного описания содержания проекта;

• процесс, который определяет, как ИСР будет поддерживаться и одобряться;

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

• процесс контроля обработки запросов на изменения в отношении подробного описания содержания проекта. Этот процесс напрямую связан с процессом интегрированного контроля изменений (раздел 4.5).

План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта.

5.1.3.2. План управления требованиями

План управления требованиями – это компонент плана управления проектом, описывающий способы анализа, документирования требований и управления ими. Взаимосвязи между фазами, описанные в разделе 2.4.2.1, существенно влияют на порядок управления требованиями. Руководитель проекта выбирает наиболее эффективный тип взаимосвязей для проекта и документирует данный подход в плане управления требованиями. Многие компоненты плана управления требованиями основаны на этом типе взаимосвязей.

Компоненты плана управления требованиями могут включать в себя, среди прочего:

• порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;

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

• процесс приоритезации требований;

• используемые метрики продукта и обоснование их использования;

• структуру отслеживания, т. е. какие параметры требований будут отражены в матрице отслеживания.

5.2. Сбор требований

Сбор требований – процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса.

Рис. 5–4. Сбор требований: входы, инструменты и методы, а также выходы

Рис. 5–5. Диаграмма потоков данных сбора требований

На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или возможности, которым должен соответствовать проект или которые должен иметь продукт, услуга или результат, чтобы удовлетворить соглашению или другой формальной предписанной спецификации. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и зарегистрированы со степенью детализации, достаточной для того, чтобы их включить в базовый план по содержанию и измерять после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и иногда закупок основывается на данных требованиях. Разработка требований начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), в реестре заинтересованных сторон (раздел 13.1.3.1) и в плане управления заинтересованными сторонами (раздел 13.2.3.1).

Многие организации подразделяют требования на различные типы, например бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние – к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя:

• Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят.

• Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон.

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

– Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом.

– Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д.

• Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем.