5.1 Сбор требований (pmBoK 4ed)
Сбор требований – процесс определения и документирования потребностей заинтересованных сторон проекта для достижения целей проекта. На успех проекта напрямую влияет тщательность сбора и управления требованиями к проекту и продукту. Требования включают в себя количественно определенные и задокументированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон проекта. Данные требования должны быть выявлены, проанализированы и зарегистрированы с достаточной степенью детализации так, чтобы их можно было измерить после начала исполнения проекта. Сбор требований представляет собой определение ожиданий заказчика и управление ими. Требования становятся базой для ИСР. Планирование стоимости, расписания и качества строится на основе этих требований. Разработка требований начинается с анализа информации, содержащейся в Уставе проекта (раздел 4.1.3.1) и в Реестре заинтересованных сторон проекта (раздел 10.1.3.1).
Многие организации разделяют требования на категории «требования к проекту» и «требования к продукту». Требования к проекту могут включать в себя бизнес-требования, требования к управлению проектом, требования к доставке и т. д. Требования к продукту могут содержать информацию о технических требованиях, требованиях к безопасности, производительности и т. д.
На рис. 5-2 показаны входы, инструменты и методы и выходы процесса сбора требований, а на рис. 5-3 представлена общая схема основных связей и взаимодействий в рамках данного процесса.
Рис. 5-2. Сбор требований: входы, инструменты и методы, выходы
Рис. 5-3. Блок-схема данных при сборе требований
5.1.1 Сбор требований: входы
.1 Устав проекта
Устав проекта используется для предоставления требований к проекту высокого уровня и описания продукта высокого уровня, позволяющих разработать подробные требования к продукту. Устав проекта описан в разделе 4.1.
.2 Реестр заинтересованных сторон проекта
Реестр заинтересованных сторон проекта используется для определения заинтересованных сторон проекта, которые могут предоставить подробную информацию о требованиях к проекту и продукту. Реестр заинтересованных сторон проекта описан в разделе 10.1.
5.1.2 Сбор требований: инструменты и методы
.1 Интервью
Интервью представляют собой формальный или неформальный способ получения информации от заинтересованных сторон проекта путем непосредственного общения с ними. Обычно в ходе интервью задают подготовленные и неподготовленные вопросы и записывают ответы. Интервью часто проводятся «один на один», но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, заинтересованными сторонами проекта или экспертами по отдельным вопросам может помочь в выявлении и определении характеристик и функций желаемых результатов проекта.
.2 Фокус-группы
Фокус-группы позволяют собрать вместе заранее выбранные заинтересованные стороны проекта и экспертов по отдельным вопросам, чтобы они изложили свои ожидания и отношения к предложенному продукту, услуге или результату. Подготовленный ведущий управляет группой во время многостороннего обсуждения, которое является более свободным по форме, чем интервью «один на один».
.3 Семинары с участием модератора
Семинары для определения требований представляют собой собрания по конкретным вопросам, в которых участвуют заинтересованные стороны проекта разного профиля для определения требований к продукту. Семинары используются в качестве основного метода, позволяющего быстро определить требования различного профиля и урегулировать различия между требованиями заинтересованных сторон проекта. В силу особенностей формата групповой работы, хорошо проведенные собрания с участием модератора помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести к повышению уровня согласия между заинтересованными сторонами проекта. Другое преимущество данного метода состоит в том, что проблемы могут быть обнаружены и разрешены гораздо быстрее, чем при встречах один на один.
Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка (или проектирование) приложений» (Joint Application Development (or Design), JAD). Такие собрания с участием модератора направлены на предоставление пользователям возможности встретиться с командой разработчиков для улучшения процесса разработки программного продукта. В производственных отраслях существует «Развертывание функции качества» (Quality Function Deployment, QFD) – это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для продвижения нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (Voice of the Customer, VOC). Затем эти потребности объективно сортируются, и между ними расставляются приоритеты, а также устанавливаются цели для их достижения.
.4 Групповые творческие методы
Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже представлено несколько групповых творческих методов:
• Мозговой штурм. Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к проекту и продукту.
• Метод номинальных групп. В данном методе к мозговому штурму добавляется процесс голосования, используемый для ранжирования наиболее полезных идей для будущего мозгового штурма или расстановки приоритетов.
• Метод Дельфи. Выбранная группа экспертов отвечает на вопросы анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора требований. Для обеспечения анонимности доступ к ответам имеет только координатор.
• Составление интеллект-карт. Идеи, возникшие во время отдельных сессий мозгового штурма, объединяются в единой интеллект-карте с целью отражения сходства и различия в понимании и формирования новых идей.
• Диаграмма сходства. Данный метод позволяет рассортировать по группам большое количество идей для их обзора и анализа.
.5 Методы группового принятия решения
Групповое принятие решений – это процесс оценки различных альтернатив с ожидаемыми результатами в форме разрешения будущих действий. Данные методы могут быть использованы для создания, классификации требований к продукту и расстановки приоритетов между ними.
Существует множество методов принятия группового решения, например:
• Единогласие. Все соглашаются с определенным направлением действий.
• Большинство голосов. Поддержка со стороны более 50 % членов группы.
• Относительное большинство голосов. Выбирается решение самого многочисленного блока в группе, даже если не достигнуто большинство голосов.
• Диктатура. Один человек принимает решение за всю группу.
Практически любой из описанных выше методов принятия решений может быть применен в групповых методах, используемых в процессе сбора требований.
.6 Анкеты и опросы
Анкеты и опросы представляют собой наборы вопросов в письменной форме, предназначенные для быстрого получения информации от большого числа респондентов. Опросы и/или анкеты лучше всего подходят для работы с широкими аудиториями, когда требуется быстрый сбор информации, и где допускается применение статистического анализа.
.7 Наблюдения
Наблюдения дают возможность непосредственного наблюдения за людьми в их окружении, за тем, как они выполняют свою работу или задания и осуществляют процессы. Наблюдения особенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают озвучивать свои требования. Наблюдение, также называемое «наблюдение за работой», обычно осуществляется внешним наблюдателем, следящим за тем, как пользователь выполняет свою работу. Также оно может осуществляться «наблюдателем-участником», который фактически осуществляет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования.
.8 Прототипы
Создание прототипов представляет собой метод раннего получения обратной связи по требованиям путем создания рабочей модели ожидаемого продукта до его фактического производства. Некоторые прототипы являются материальными, что позволяет заинтересованным сторонам проекта экспериментировать с моделью своего конечного продукта, а не только беседовать об абстрактных представлениях своих требований. Прототипы поддерживают концепцию последовательной разработки, потому что они используются в итеративных циклах создания экспериментальных моделей, проведения экспериментов пользователем, подготовки обратной связи и пересмотра прототипа. После проведения достаточного числа циклов обратной связи, требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе разработки или создания.