Шрифт:
процесс, который устанавливает, как будет производиться формальная приемка полученных поставляемых результатов проекта.
План управления содержанием может быть формальным и неформальным, детализированным или задавать лишь общие рамки в зависимости от потребностей проекта.
5.1.3.2. План управления требованиями
План управления требованиями – это компонент плана управления проектом, описывающий способы анализа, документирования требований по проекту и продукту и управления ими. Согласно документу Бизнес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: A Practice Guide) [7], в некоторых организациях данный план называют еще «план бизнес-анализа». Компоненты плана управления требованиями могут включать в себя, среди прочего:
порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;
действия по управлению конфигурацией, такие как порядок инициирования изменений, порядок анализа их воздействий, выявления, отслеживания и составления отчетов о них, а также уровни полномочий, необходимые для одобрения данных изменений;
процесс приоритизации требований;
используемые метрики и обоснование их использования;
структуру отслеживания, которая отражает, какие параметры требований будут представлены в матрице отслеживания.
5.2. Сбор требований
Сбор требований – это процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения поставленных целей. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения содержания продукта и проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса.
Рис. 5–4. Сбор требований: входы, инструменты и методы, выходы
Рис. 5–5. Сбор требований: диаграмма потоков данных
В Руководстве PMBOK® вопросы требований к продукту подробно не освещаются, поскольку эти требования разные в разных отраслях. Обратите внимание, что в документе Бизнес-анализ для специалистов-практиков: Практическое руководство (Analysis for Practitioners: Practice Guide) [7] можно найти более подробную информацию по требованиям к продукту. На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования к проекту и продукту, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или характеристики, которые должен, согласно требованиям, иметь продукт, услуга или результат, чтобы удовлетворить условиям соглашения или другим официально установленным спецификациям. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и записаны со степенью детализации, достаточной для их включения в базовый план по содержанию и измерения после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и закупок основывается на данных требованиях.
5.2.1. Сбор требований: входы
5.2.1.1. Устав проекта
Описан в разделе 4.1.3.1. В уставе проекта документируется высокоуровневое описание проекта и высокоуровневые требования, которые затем используются при детализации требований.
5.2.1.2. План управления проектом
Описан в разделе 4.2.3.1. Компоненты плана управления проектом включают в себя, среди прочего:
План управления содержанием. Описан в разделе 5.1.3.1. План управления содержанием содержит информацию о порядке определения и разработки содержания проекта.
План управления требованиями. Описан в разделе 5.1.3.2. План управления требованиями содержит информацию о порядке сбора, анализа и документального оформления требований по проекту.
План вовлечения заинтересованных сторон. Описан в разделе 13.2.3.1. План вовлечения заинтересованных сторон используется для понимания требований заинтересованных сторон к коммуникациям и уровня их вовлеченности с целью оценки и адаптации к уровню участия заинтересованных сторон в действиях в отношении требований.
5.2.1.3. Документы проекта
В качестве примеров документов проекта, которые можно считать входами в данный процесс, можно назвать, среди прочего:
Журнал допущений. Описан в разделе 4.1.3.2. В журнале допущений определены допущения в отношении продукта, проекта, среды, заинтересованных сторон и других факторов, которые влияют на требования.
Реестр извлеченных уроков. Описан в разделе 4.4.3.1. Реестр извлеченных уроков используется для предоставления информации об результативных методах сбора требований, особенно для проектов, в которых применяется итеративная или адаптивная методология разработки продукта.
Реестр заинтересованных сторон. Описан в разделе 13.1.3.1. Реестр заинтересованных сторон используется для определения заинтересованных сторон, которые могут предоставить информацию о требованиях. В нем также регистрируются требования и ожидания, которые есть у заинтересованных сторон по данному проекту.
5.2.1.4. Бизнес-документы
Описаны в разделе 1.2.6. Документом, который может оказать влияние на процесс сбора требований, является бизнес-кейс, который может содержать описание обязательных, желательных и необязательных критериев для удовлетворения бизнес-потребностей.