Файл: Американ. стандарт 4-е издание.pdf

Добавлен: 29.10.2018

Просмотров: 18366

Скачиваний: 63

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

109

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание

.6   анкеты и опросы

Анкеты  и  опросы  представляют  собой  наборы  вопросов  в  письменной  форме,  предназначенные 

для  быстрого  получения  информации  от  большого  числа  респондентов.  Опросы  и/или  анкеты  лучше 

всего  подходят  для  работы  с  широкими  аудиториями,  когда  требуется  быстрый  сбор  информации,  и  где 

допускается применение статистического анализа.

.7   наблюдения

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

тем,  как  они  выполняют  свою  работу  или  задания  и  осуществляют  процессы.  Наблюдения  особенно 

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

желают  озвучивать  свои  требования.  Наблюдение,  также  называемое  «наблюдение  за  работой»,  обычно 

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

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

.8   прототипы

Создание  прототипов  представляет  собой  метод  раннего  получения  обратной  связи  по  требованиям 

путем  создания  рабочей  модели  ожидаемого  продукта  до  его  фактического  производства. 

Некоторые  прототипы  являются  материальными,  что  позволяет  заинтересованным  сторонам  проекта 

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

представлениях  своих  требований.  Прототипы  поддерживают  концепцию  последовательной  разработки, 

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

экспериментов  пользователем,  подготовки  обратной  связи  и  пересмотра  прототипа.  После  проведения 

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

5.1.3  сбор требований: выходы

.1   документы по требованиям

Документы по требованиям описывают, каким образом отдельные требования удовлетворяют бизнес-

потребностям  проекта.  Требования  могут  быть  сначала  описаны  на  высоком  уровне,  а  затем  постепенно 

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

должны  стать  однозначными  (такими,  чтобы  их  можно  было  измерить  и  проверить),  отслеживаемыми, 

полными,  последовательными  и  приемлемыми  для  ключевых  заинтересованных  сторон  проекта. 

Формат  документов  по  требованиям  может  варьироваться  от  простого  документа,  перечисляющего  все 

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

Глава  5  −  упРавление  содеРжанием  пРоекта

5

5


background image

110

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание

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

• 

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

• 

цели бизнеса и проекта для возможности контроля

;

• 

функциональные  требования,  соответствующим  образом  описывающие  бизнес-процессы, 

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

;

• 

нефункциональные  требования,  такие  как  уровень  обслуживания,  производительность, 

безопасность, надежность, соответствие нормам, наличие технической поддержки, длительное 
использование / чистка и т. д.;

• 

требования к качеству;

• 

критерии приемки;

• 

бизнес-правила, описывающие руководящие принципы организации;

• 

влияние  на  другие  отделы  организации,  такие  как  центр  обработки  вызовов,  отдел 

продаж,  технологические группы;

• 

влияние на другие органы внутри и за пределами исполняющей организации;

• 

требования к технической поддержке и обучению;

• 

допущения и ограничения в отношении 

требований. .2   план управления требованиями

План  управления  требованиями  документирует  порядок  анализа,  документирования  и  управления 

требованиями  на  всем  протяжении  проекта.  Связи  между  фазами,  описанные  в  разделе  2.1.3.2, 

существенно  влияют  на  порядок  управления  требованиями.  Менеджер  проекта  должен  выбрать 

наиболее эффективные связи для фаз проекта и задокументировать данный подход в плане управления 
требованиями. Многие элементы плана управления требованиями основаны на их связях.

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

• 

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

действия  по  управлению  конфигурацией,  такие  как  порядок  инициирования  изменений 

требований  к  продукту,  услуге  или  результату,  порядок  анализа  влияния,  его  выявления, 

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

одобрения данных изменений;

Глава  5  −  упРавление  содеРжанием  пРоекта

5

5


background image

111

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание

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

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

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

.3   матрица отслеживания требований

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

с  их  происхождением  и  отслеживает  их  на  протяжении  жизненного  цикла  проекта.  Применение 

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

ценность  бизнеса,  связывая  его  с  целями  бизнеса  и  проекта.  Это  позволяет  отслеживать  требования  на 

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

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

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

требования к бизнес-потребностям, возможностям, задачам и целям;

требования к целям проекта;

требования к содержанию проекта / результатам ИСР;

требования к проектированию продукта;

требования к разработке продукта;

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

детализацию требований от высокого уровня до более детальных требований.

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

требований.  Данные  параметры  помогают  определить  ключевую  информацию  относительно  требований. 

Типичные  параметры,  используемые  в  матрице  отслеживания  требований,  могут  включать  в  себя: 

уникальный  идентификатор,  текстовое  описание  требования,  обоснование  включения  в  список  требований, 

владельца, источник, приоритет, версию, текущий статус (например, активный, отменен, отложен, добавлен, 

одобрен)  и  дату  выполнения.  Дополнительные  параметры,  позволяющие  удостовериться,  что  требование 

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

Глава  5  −  упРавление  содеРжанием  пРоекта

5

5


background image

112

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание

5.2  определение содержания

Определение  содержания  –  процесс  разработки  подробного  описания  проекта  и  продукта.  Подготовка 

подробного  описания  содержания  проекта  чрезвычайно  важна  для  успеха  проекта  и  основывается  на  основных 

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

проекта  определяется  во  время  планирования  и  описывается  более  подробно  по  мере  поступления  информации 

о  проекте.  Существующие  риски,  допущения  и  ограничения  анализируются  на  предмет  полноты;  дополнительные 

риски, допущения и ограничения добавляются по мере необходимости. На рис. 5-4 показаны входы, инструменты 

и  методы,  выходы  процесса  определения  содержания,  а  на  рис.  5-5  представлена  общая  блок-схема  основных 
связей и взаимодействий в рамках данного процесса.

Входы

Инструменты и методы

Выходы

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

.2 Документация по    

требованиям 

.3 Активы процессов   

организации

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

.2 Анализ продукта 

.3 Поиск альтернатив 

.4 Семинары с участием  

модератора

.1 Описание содержания проекта

.2 Обновления документов  

проекта

Рис. 5-4. определение содержания: входы, инструменты и методы, выходы

Глава  5  −  упРавление  содеРжанием  пРоекта

5

5


background image

113

©2008 Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) — Четвертое издание

5.2.1  определение содержания: входы

.1   устав проекта

Устав  проекта  предоставляет  описание  проекта  высокого  уровня  и  характеристики  продукта. 

Кроме  того,  он  содержит  требования  к  одобрению  проекта.  Устав  проекта  описан  в  разделе  4.1.3.1. 

Если  исполняющая  организация  не  использует  Устав  проекта,  необходимо  получить  или  подготовить 

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

.2   документы по требованиям
Описаны в разделе 5.1.3.1.

Рис. 5-5. блок-схема данных при определении содержания

Глава  5  −  упРавление  содеРжанием  пРоекта

• 

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

• 

Активы процессов

     организации

• 

Документация

     по требованиям

• 

Описание содержания

     проекта

• 

Обновления

     документов

     проекта

5.2

Определение

содержания

5.1

Сбор

требований

4.2 

Разработка

плана

управления

проектом

6.2

Определение

последовательности

операций

6.4

Оценка

длительности

операций

6.5

Разработка

расписания

11.1 

Планирование

управления

рисками

11.3 

Качественный 

анализ рисков

4.1

Разработка

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

5.3

Создание ИСР

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

Документы

проекта

Предприятие/

организация

5

5