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

1. У проекта будет несколько промежуточных продуктов, которые сложны, и будут впоследствии соединяться меж собой. Как РМ, вы понимаете, что ИСР поможет стейкхолдерам лучше понять, как промежуточные поставки собираются в итоговый результат. Чтобы управлять отдельными ее элементами, вы использовали систему нумерации работ. Эта система нумерации позволяет проектной команде:

• А. Систематически оценивать затраты элементов ИСР
• В. Дать обоснование проекту
• С. Понять уровень, на котором находятся элементы
• D. Их можно использовать в софте по управлению проектами

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

2. ИСР лучше всего подходит для коммуникации с:

• А. Командой
• В. РМ
• С. Клиентом
• D. Стейкхолдерами

Ответ D. Термин "стейкхолдеры" включает в себя все остальные варианты. ИСР - это инструмент коммуникации со всеми вовлеченными в проект людьми.

Процесс Контроля содержания проекта

Многие РМ не контролируют содержание своих проектов, а зря. Контроль содержания предполагает измерение исполнения работ против Базовых значений содержания, и управление изменениями содержания. В любой момент времени РМ должен быть уверен, что проект исполняется в соответствии с Планом управления проектом. На экзамене, всегда имеем ввиду, что так и происходит - если в вопросе не сказано обратное.
Чтобы контролировать содержание, для начала нужно четкое его определение - то есть базовое значение содержания из плана управления проектом. А также нужно и что-то сделанное по проекту. Также, надо и исходные требования (Документация на требования, и Матрица трассировки требований). Далее, вы измеряете выполненную работу против базовых значений содержания, выявляете отклонения, и решаете, достаточно ли они существенны, чтобы начинать волноваться об изменениях. Если надо, отправляете запрос на изменение, через процесс Интегрированного контроля изменений, чтобы оценить импакт изменения на все аспекты проекта. Изменения в свою очередь могут потребовать апдейтов проектной документации.
Помним, что контроль содержания - проактивен. Процесс включает размышления, откуда взялись изменения, и что нужно сделать, чтобы предотвратить или отменить изменения из этого источника. Правильно используя инструменты, техники и практики проектного менеджмента, вы избавитесь от второстепенных проблем по проекту.
Как РМ, вы не должны просто претворять в жизнь изменения от других людей; вы должны контролировать проект так, чтобы он исполнялся в соответствии с планом управления проекта для достижения базовых значений. Так что, не нужно колебаться и поддаваться влиянию, не надо позволять другим добавлять новое в содержание без прохождения процесса Интегрированного контроля изменений, и без проверки того, что запрошенные изменения в запланированном содержании проекта. Люди всегда пытаются впихнуть что-то в проект, не задумываясь, является ли добавка его логической частью, или нет. РМ должен это контролировать.

Выходы процесса Валидации содержания проекта

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

1. информация о состоянии исполнения работ
2. принятые продукты
3. запросы на изменение
4. апдейты в реестр вынесенных уроков, матрицу требований, и документацию на требования

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

1. Валидацию можно делать как в конце фазы проекта, для получения формальной приемки продуктов, так и в промежутках, как часть процесса Контроля и мониторинга, для приемки промежуточных продуктов. Так что, содержание валидируется клиентом многократно в течение проекта. В change-driven проектах, это случается в конце каждой итерации, как часть приемки итерации клиентом
2. Есть тонкая разница между Валидацией содержания, и Закрытием проекта или фазы. Валидация это приемка промежуточных продуктов, а Закрытие это финальное закрытие проекта или фазы в целом и списание их из актива
3. Надо понимать, как процесс Валидации содержания связан с процессом Контроля качества:

Хотя Контроль качества обычно проводится первым, чтобы проверить продукты перед сдачей клиенту, оба процесса очень похожи, и подразумевают проверку качества работы. Разница - это фокус усилия, и кто делает проверку. В Контроле качества, отдел качества проверяет соответствие продукта спецификациям, и вообще их правильность. В Валидации содержания, клиент проверяет, и в хорошем случае принимает продукты.

Процесс Валидации содержания проекта

Многие путаются с понятием Валидации содержания. А на этот счет может быть до пяти вопросов в экзамене!
Валидация - это НЕ утверждение и подписание содержания проекта в ходе планирования. Процесс валидации содержания предполагает регулярные плановые митинги со спонсором или заказчиком для осуществления формальной приемки продуктов во время фазы Контроля и мониторинга проекта. То есть, это подтверждение соответствия сделанного запланированному.
Входы для процесса Валидации содержания:

• работа должна быть исполнена и проверена перед каждым митингом с клиентом, так что у вас должны быть проверенные продукты, после Процесса контроля качества
• на встрече с клиентом будет полезно утвержденное содержание, то есть нужен базовый план по содержанию из базового плана проекта
• нужна будет информация по требованиям проекта, и тому как они исполняются и валидируются. Эта информация может быть найдена в Плане управления требованиями и Матрице трассировки требований
• также нужна информация и на сами требования, чтобы сравнить их с фактом
• иная документация типа Отчетов по качеству или Вынесенных уроков тоже должна быть просмотрена. Отчет по качеству могут включать информацию об открытых или закрытых проблемах, и об управлении ими, а вынесенные уроки могут быть использованы для улучшения процесса Валидации содержания
• также нужен План управления содержанием, который показывает согласованные к поставке продукты, и формальные процедуры их приемки
• также, вы будете ссылаться на данные по исполнению работ из процесса Управления и ведения проектной работы, чтобы понять, насколько хорошо выпущенные продукты соответствуют требованиям

Документация: Базовый план по содержанию

Базовые значения помогают РМ контролировать их проекты. Базовые планы - это просто последние и утвержденные версии некоторых частей плана управления проектом. Для содержания, базовые значения это финальные версии ИСР, Словаря ИСР, и Описания содержания проекта, которые утверждены в конце планирования, до момента начала работ. По мере прогресса работ, РМ их проверяет против базовых значений, задавая вопросы:

1. как идет мой проект, в сравнении с базовыми значениями?
2. какое содержание уже сдано?
3. соответствует ли оно тому, что описано в ИСР, словаре ИСР, содержании?

Если требуется сделать что-то за пределами базовых значений, это должно быть формально одобрено через процесс интегрированного контроля изменений, и новые пункты добавляются в ИСР, словарь ИСР, и Описание содержания, чтобы обозначить добавки. Эта обновленная документация становится новым базовым значением по содержанию для проекта. Любые другие компоненты плана управления проектом, на которые влияют изменения, должны также быть проапдейчены, включая Документацию на требования и Реестр предположений.

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

Документация: Словарь ИСР

В ИСР, пакеты работ могут быть описаны парой слов. Столько краткое определение поставляемых продуктов дает простор вариациям. Иными словами, допускает шатание содержания. Словарь ИСР - это решение проблемы. Документ дает описание всех работ, которые делаются в рамках пакета, список критериев приемки для каждого продукта, чтобы мы понимали, что результат работы соответствует требованиям. То есть, РМ использует словарь ИСР для предотвращения шатания содержания до старта работ, вместо того чтобы разбираться с шатанием в процессе.
Словарь ИСР - это выход процесса Создания ИСР. Он может использоваться как часть системы авторизации работ, информирующей участников команды, что их работы начинаются. Словарь ИСР может включать описание ключевых вех графика проекта, критерии приемки, продолжительность, взаимосвязи, и иную информацию по пакетам работ. Также используется для контроля законченности работ, предотвращения шатания содержания, и повышения понимания заинтересованных сторон в части усилий, требуемых для каждого пакета работ. Словарь ИСР устанавливает границы, что включено в пакет работ, по аналогии с тем, как Устав определяет, что включено в проект. Важно понимать, что определенные пункты словаря ИСР могут заполняться итеративно, а не сразу после его создания.
Пример словаря ИСР:

Что делать после создания ИСР?

Над этим вопросом следует думать с позиции "Чем это поможет проекту?"
После своего создания, ИСР может быть использована в любой момент, когда содержание проекта будет переоцениваться. Например:

1. когда поступил запрос на изменение, связанный с содержанием, ИСР (вместе с содержанием) используется для оценки, в проекте ли изменение, или нет
2. ИСР используется как часть интегрированного контроля изменений, чтобы понять их влияние на содержание
3. РМ может контролировать "шатание" содержания, используя ИСР, чтобы понимать, какую работу надо делать, а какую нет
4. ИСР может быть использована как коммуникационный инструмент, во время обсуждения проекта с командой или клиентом
5. ИСР помогает участникам проекта видеть свои роли в проекте

На экзамене может быть много отсылок к ИСР. Чтобы отвечать на эти вопросы корректно, помним, что ИСР:

1. это графическое представление иерархии проекта
2. показывает все продукты, которые должны быть поставлены (чего нет в ИСР, того нет в проекте)
3. это основа, на которой строится проект
4. очень важна, и на каждом проекте должна быть
5. дает уверенность, что РМ подумал обо всех аспектах проекта
6. может быть использована повторно на иных проектах
7. не показывает зависимости

Терминология: не путаем ИСР и декомпозицию. ИСР это результат декомпозиции проекта. На экзамене могут быть использованы термины decomposition или deconstruction.

Выгоды от использования ИСР

В чем преимущества ИСР:

1. предотвращает то, что мы забудем какие-то пакеты работ
2. дает команде управления проектом понимание, как поставки продуктов соответствуют общему плану управления проектом, и помогает проектной команде понять ее вклад в проект в целом
3. способствует коммуникации и кооперации между проектной командой и заинтересованными сторонами
4. помогает управлять ожиданиями заинтересованных сторон в части поставок продукта
5. помогает выявлять риски
6. помогает предотвращать изменения
7. фокусирует проектную команду на том, что нужно сделать, что выливается в повышение качества и улучшение управляемости проекта
8. дает базис для оценки ресурсов, расходов, и расписания
9. дает обоснование потребности в ресурсах, фондировании, и сроках
10. помогает планировать усилия по контролю, и устанавливает критерии приемки для поставок
11. способствует вкладу каждого из команды, сплачивает всех
12. помогает заставить людей думать о проекте

ИСР - это основа проекта. То есть, все, что в проекте происходит после создания ИСР, будет с ней связано. Также, ИСР помогает РМ лучше оценить риски, через рассмотрение проекта на уровне пакетов работ.

Пример ИСР в терминах ИСР:

Документация: Иерархическая структура работ

ИСР - это обязательный элемент управления проектом. Этот организационный инструмент показывает все содержание проекта, разбитое на маленькие поставки. Без ИСР, проект займет больше времени, какие-то продукты и работы для их исполнения могут быть пропущены, и это негативно повлияет на проект. Так что, без вариантов - все проекты, даже мелкие, нуждаются в ИСР.
Часто РМ просто готовят список продуктов, которые будут выпущены по проекту, и считают это ИСР. На самом деле ИСР это диаграмма. Сравним:

Преимущества графического представления:

1. так проще воспринять результаты; графика дает структурированный взгляд на проект, и облегчает проверку, что ничего не потеряно и не забыто
2. список может быть запутан, и затруднять разбиение проекта на маленькие самостоятельные кусочки. На ИСР проще разбить проект на пакеты работ (маленькие поставки, не задачи). А также лучше видна иерархия
3. список обычно составляется кем-то одним, в то время как ИСР это результат вкладов спонсора и других заинтересованных сторон. Вовлечение команды и иных интересантов повышает драйв проекта, а это улучает прогресс исполнения. Список сложнее в восприятии, и если он составлялся кем-то одним, то это снижает доверие к нему
4. процесс создания ИСР помогает команде пройти в уме сквозь проект, а это повышает качество планирования; в итоге исполнение проекта менее рисково и более результативно
5. вовлечение людей в создание ИСР помогает им лучше понять проект; так он будет казаться им более достижимым
6. ИСР показывает структуру проекта, на ней ясно, как один продукт связан с другим

Например:

В общем случае, на вершине ИСР указывается наименование проекта; второй уровень соответствует жизненному циклу разработки. Следующие уровни разбивают проект на продукты, которые далее разбиваются на более мелкие компоненты, вплоть до конкретных пакетов работ. Декомпозиция должна быть такая, чтобы удобно управлять проектом.

ИСР может и похожа на организационную диаграмму, но ей не является! У ИСР другая задача. Она позволяет разбить сложный проект на участки, которые можно планировать, организовывать, управлять, и контролировать.

Итого, ИСР - это декомпозиция поставок в пакеты работ. Можно ее делать сверху-вниз, или снизу-вверх, или по иным любым адекватным стандартам.

Обращаем внимание, что на ИСР отражаются не задачи, а продукты работ, которые получаются из задачи или группы задач. Так что на экзамене считаем, что каждый пакет должен обозначаться существительным. Это вещь, продукт, поставка. А не глагол (задача, активность). ИСР ориентирована на поставки. Это не означает, что там только те продукты, которые мы передаем клиенту. Туда можно включить и полное содержание проекта, в т.ч содержание продукта, и усилия по управлению проектом.

Уточнимся по слову "задача". На экзамене, имеем ввиду, что задача это под-сущность Активности. Проектом мы управляем именно на уровне активностей, а задачи это уже операции. То есть иерархия, это Продукт -> Пакет работ -> Активность по его созданию  -> Задача.

Каждая ИСР уникальна, и у каждого РМ свой подход к ее разработке. Но есть гайдлайны, которым надо следовать всегда:

1. ИСР создает РМ, на основе вводных от команды и стейкхолдеров
2. Каждый уровень ИСР - это развертка другого уровня
3. На верхнем уровне сам проект
4. ИСР включает только запрошенные продукты; напротив, то, чего нет в ИСР, не входит в проект

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

1. могут быть осмечены (= декомпозированы до задач со сроком и стоимостью)
2. могут быть быстро исполнены
3. могут быть исполнены без вмешательств, и без новых уточнений
4. могут быть отданы на аутсорс

На этом этапе пакеты работ - самый нижний уровень ИСР - могут быть заведены в какой-то софт по управлению проектами. Не стоит делать наоборот, то есть финализировать пакеты работ уже в софте. Они определяются строго на этапе ИСР.

Уровни ИСР можно нумеровать, для удобной ориентации. Система нумерации может быть любой. Например:

Control account тут - это промежуточные точки, которые позволят собрать и проанализировать факт по каким-то пакетам работ (содержание, расписание, бюджет). Контрольные счета, включающие один или несколько пакетов работ, помогают управлять и контролировать содержание, расписание и бюджет на уровне более высоком, чем пакет работ. Каждый пакет работ может ассоциироваться только с одним контрольным счетом.

По мере планирования, команда декомпозирует пакеты работ до активностей. Эта декомпозиция делается как часть процесса Управления расписанием, и так и называется, Определение активностей. Команда использует для этого Описание содержания проекта, ИСР и Словарь ИСР.

На мелких проектах, ИСР разбивается на пакеты работ длительностью от 4 до 40 часов. На средних, от 8 до 80. На больших, пакеты работ могут включать до 300 часов. Так что, процесс определения активностей особенно важен на больших проектах.

Если вы работаете над схожими проектами, то ИСР одного можно брать за базис для другого. Поэтому проектный офис должен стремиться сохранять ИСР, делиться ими, и создавать темплейты. Это часть процессных активов компании.

Хорошие РМ видят в ИСР не просто информацию, они понимают ценность усилий по созданию ИСР. 

Документация: Описание содержания проекта

Первый выход процесса Определения содержания - это Содержание проекта. Он говорит, "Вот то, что мы будем делать на этом проекте". На plan-driven проекте, проработка содержания проекта может занять много времени, и потребовать экспертных оценок многих пользователей, и даже экспертов из-за пределов компании. Содержание change-driven проекта будет менее детальным, но тем не менее достаточным, чтобы понять, что входит, а что не входит в проект. Далее содержание будет прорабатываться по мере прогресса проекта.
Во время работы с требованиями, и далее, конвертации их в содержание, нужно находить участки, где люди запросили что-то, но они не были включены в проект. Также нужно определять участки, где содержание может быть легко недопонято. Разработка содержания проекта, которое не нужно, или которое не будет утверждено, - это пустая трата времени. На практике такое случается очень часто. Один из способов избежания этой проблемы - явно указать в Уставе проекта, что не включено в проект, чтобы такие добавки уж точно не случались.
Описание содержания проекта, вместе с ИСР и словарем ИСР, образуют базовые значения содержания, которые являются частью плана управления проектом.
Содержание проекта может включать следующее:

1. Содержание продукта
2. Содержание проекта, включая описание
3. Описание поставок проекта
4. Критерии приемки
5. Что не включается в проект
6. Предположения и ограничения проекта

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

Часть определения содержания - это понимание, что нужно заделиверить в результате проекта. Продуктовый анализ проводится для того, чтобы выявить цели создания и описание продукта так, как это видят спонсор или клиент. Анализ продукта - это критически важный инструмент, позволяющий РМ проверить, что содержание проекта и продукта понятны и точны. На экзамене, всегда считаем, что будем сами выявлять требования к продукту, как часть проекта, а не получим исчерпывающий список от клиента.

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

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

1. Устава
2. Плана управления содержанием
3. Документацию на требования, собранную в процессе Сбора требований
4. Реестр предположений
5. Реестр рисков

Помним, что планирование итеративно. Когда требования определены и содержание понятно, РМ определяет расписание и бюджет. Если результирующее расписание и бюджет не соответствуют ожиданиям спонсора и стейкхолдеров, РМ балансирует требования (содержание) против ограничений по бюджету и расписанию. Итеративно, прорабатываются все взаимодействия требований, чтобы достичь содержания, расписания и бюджета. Менеджменту можно предложить варианты для принятия решений. Результат может включать сжатие расписания, поиск альтернативных путей исполнения работ, или корректировку бюджета или содержания проекта. Итог - реалистичное расписание и бюджет, в рамках которых получим требуемое содержание. Процесс определения содержания продолжается в течение всего проекта.
Два ключевых нюанса на понимание  этого процесса на экзамене:

1. РМ часто жалуются на нереальные сроки; на экзамене считается что это всегда вина РМ, скорее всего они не проводили итеративного планирования как сказано выше. РМ должен соотнести содержание с расписанием и бюджетом, чтобы разрешить все проблемы до начала работ
2. РМ проводит много времени в течение исполнения, контроля и мониторинга проекта за поиском вариантов корректировки проекта так, чтобы по-прежнему остаться в рамках расписания и бюджета. Так что, все те инструменты, которые использовались при итеративном планировании, будут применяться и при исполнении проекта

Безотносительно того, используется ли plan-driven или change-driven подход, итеративный процесс Определения содержания будет присутствовать в течение всего проекта. Его цель - в постоянной проверке, что входит в проект, а что нет.

Документация: Матрица трассировки требований

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

Информация типа номера требования, его источника, ответственного за управление, статуса по каждому требованию, документируется в матрице. Но, с ней сложно управляться на больших проектах; в таком случае репозитарий организуется как-то иначе. На экзамене в любом случае имеем ввиду, что Матрица трассировки требований это инструмент связки требований с целями проекта и друг с другом, и что атрибуты требований типа идентификационного номера, ответственного и т.д. также документируется.
Назначение ответственного за каждое требование схоже с концепцией ответственных за риски. Ответственный помогает заказчику понять, что требование исполнено. Также, ответственные за требования высвобождают время РМ. Роль ответственного за требования - это пример работы, которую участники команды могут делать на проекте, кроме собственно выпуска продукта.

Документация: Документация на требования

После сбора и финализации требований их документируют. Документация - выход из процесса Сбора требований, она помогает понять, что все требования явные и непротиворечивые. Документация на требования будет входом в процессы Определения содержания и Разработки ИСР.
Требования могут включать разную информацию, но то, что обязательно нужно - это критерии приемки. Главный вопрос, который мы задаем заинтересованным сторонам - "Как мы поймем, что требование исполнено?". Это также и хороший способ понять, выполнима ли задача в принципе.
Уровень документации требований прорабатывается до тех пор, пока каждое требование не будет соответствовать критериям ясности, полноты, и измеримости. Требования нужно излагать так, чтобы связанные поставки продукта можно было протестировать или измерить, для подтверждения приемки. Сама документация на требования может называться различно, например Бизнес-требования, или Функциональные требования, или User Stories, или как-то еще, и самих документов на выходе может быть несколько - PMBoK это не регламентирует и считает все единой Документацией на требования.

Разрешение конкурирующих требований

Многие РМ не понимают, как ранжировать конкурирующие требования. Что делать, если инженерный департамент видит фокус проекта в уменьшении доли дефектов, а бухгалтерия - в снижении расходов? Можно ли достичь и того и другого? А если инженерный департамент - главный стейкхолдер или даже спонсор, можно ли закрыть глаза на требования бухгалтерии? Что делать, если нужды инженеров затрагивают бухгалтерию невыгодным ей образом?
Некоторые случаи так сложны, что РМ в одиночку не сможет их разрешить, и ему потребуется помощь менеджмента. Тем не менее, все требования проверяем по чек-листу:

1. Требование поддерживает предпосылки проекта
2. Требование соответствует Уставу проекта
3. Требование попадает в содержание проекта (если оно готово на момент конфликта)
4. Требование в рамках ограничений проекта

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

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

Балансировка требований

Балансировка - это очень важный аспект сбора требований. Одна из составляющих балансировки - это проверка того, что требование вообще может быть исполнено в контексте целей проекта. Если нет, то надо искать варианты корректировки конкурирующих требований к содержанию, расписанию, бюджету, качеству, ресурсам, риску и удовлетворению клиента. Балансировка также предполагает ранжирование требований и разрешение конфликтов.
Балансировка требований следует за их сбором, поскольку ее необходимость может проясниться только после, когда мы увидим картину в целом. В том числе, и уже в ходе исполнения проекта. Но когда бы такая необходимость не возникла, помним, что требования балансируются в интересах проекта.
Балансировка требований никогда не бывает простой и быстрой. А если вы не понимаете целей проекта, или не все требования собрали, то отбалансироваться невозможно вообще. Так что, стремимся собирать требования по-максимуму; ранжируем их по важности; на гибких проектах организуем в бэклог.
Ключевые действия по балансировке требований:

1. Выявляем все заинтересованные стороны, разбираемся в их нуждах, требованиях, предположениях, ожиданиях по проекту
2. Проясняем и прорабатываем требования настолько четко, насколько предполагает выбранный подход к управлению проектом, до старта работ
3. Используем информацию о заинтересованных сторонах и их требованиях для разрешения конкурирующих требований, возникающих в ходе исполнения работ по проекту
4. Обращаем внимание на конкурирующие интересы во время планирования проекта; не надо просто ждать, пока они всплывут в ходе исполнения проекта
5. Ищем варианты разрешения конфликтующих требований, и альтернативные пути их исполнения. Это может подразумевать использование техник брейнсторминга, сжатия расписания, переоценки, и прочих практик
6. Принимаем решение по конкурирующим требованиям с оглядкой на то, как они повлияют на проект
7. Всегда в приоритете требования клиента
8. Управляем качеством, чтобы повышать соответствие проекта нуждам, ради которых он был предпринят
9. Разбираемся с проблемами и конфликтами как только они возникнут
10. Говорим "Нет" некоторым конфликтующим интересам (на экзамене имеем ввиду, что у РМ есть такое право)
11. Разбираемся с проектом, когда его метрики начинают отклоняться от требований (а не меняем требования ради достижения результата проекта)
12. Работаем над прямым разрешением споров, затрагивающих интересы интересантов или проекта
13. Организуем собрания и интервью для скорейшего разрешения конкурирующих требований
14. Эскалируем проблему на менеджмент, если в составе "РМ + команда" не можем прийти к консенсусу
15. Используем техники ведения переговоров для разрешения споров между заинтересованными сторонами
16. Планируем и используем эффективные коммуникации
17. Собираем и интегрируем всю связанную информацию по проекту

Методы сбора требований

На больших проектах с сотнями интересантов, ни один из методов не будет работать сразу на всех них. Поскольку упущение требования может вылиться в очень серьезные проблемы сроков, денег и успешности проекта, важно приложить все усилия для их сбора. Собираем требований столько, сколько сможем вообще до старта работ по проекту.
Сбор требований также предполагает выявление и декомпозицию ожиданий заинтересованных сторон - их убеждения или ментальные картинки проекта - и трансляцию этого в требования. Сбор требований может производиться в любой из следующих техник; какие конкретно, выбирает РМ. Также, эти техники могут использоваться и для других целей, например для определения рисков.

1. Брейнсторминг. Важно, что это не просто собрание для обсуждения идей; на нем идеи именно что рождаются в непринужденной обстановке. Кто-то высказывает одну идею, у другого на ее основании родится своя, и т.д. Очень полезно включать в брейнсторм людей с разными точками зрения или профессиями. Участники могут быть и внешними для проекта или компании. Когда все идеи собраны, они ранжируются и оцениваются с помощью техник ниже.
2. Интервью. РМ или команда разговаривает с интересантами, выявляет их понимание по каким-то аспектам продукта или проекта, или по проекту в целом. Проводить можно 1:1 или в группах, лично или с использованием средств коммуникации.
3. Фокус-группы. Техника применяется для заинтересованных сторон или экспертов предметной области. Участников группы обычно выбирают из какой-либо демографической группы; они общаются друг с другом под надзором модератора.
4. Анкетирование. Обычно используется для больших групп.
5. Бенчмаркинг. Это сравнение чего-то в нашей компании с чем-то с другой (например расходов на единицу продукта). Это может быть очень дорогое исследование.
6. Голосование. Требования могут конфликтовать друг с другом. Также, их надо как-то ранжировать, принимать или отказывать. Эти задачи можно решать с помощью голосования - техники принятия решения в группе.
7. Принятие решения по набору критериев. Количественные требования пересчитываются по целевой функции, за коэффициенты берем матрицу с зафиксированными оценками времени, риска, бюджета.
8. Диаграммы родства. Идеи, собранные по любой из техник выше, группируются по своей схожести; каждой группе даем имя. Такая сортировка помогает увидеть дополнительные участки содержания и риска, которые не выявлены прямыми способами. Иное воплощение диаграмм родства - категоризация требований, например:
1. требования бизнеса
2. требования заинтересованных сторон
3. требования к решению
4. требования к transition period
5. требования к проекту
6. требования к качеству
7. технические требования
9. Ментальные карты
10. Техники номинальных групп. Может применяться на собраниях типа брейнсторминга. Модератор позиционирует вопрос, все высказываются, идеи каждого фиксируются, и потом ранжируются уже сообща.
11. Наблюдение. Иногда очень полезно просто понаблюдать как работает пациент!
12. Помощь в общении. Предполагает сведение вместе разных групп интересантов - например, дизайнеров и конечных пользователей, чтобы они поговорили и выработали требования. Важно достижение общего консенсуса. Во время сессий, могут прорабатываться user stories.
13. Прототипы. Это модель продукта, которую показываем заказчику в качестве обратной связи.
14. Диаграммы контекста. Показывают границы содержания проекта, выделяя сам продукт и его интерфейсы с людьми, системами, и процессами. Например:

Входы в процесс Сбора требований

Входами являются:

1. Устав проекта. Определяет проект и продукт на высоком уровне еще в фазе инициации. С этого и начинается Сбор требований, требования далее прорабатываются до деталей.
2. Реестр предположений. Документирует, как предположения стейкхолдеров связаны с проектом и продуктом. Сбор требований предполагает проработку имеющихся предположений и выявление новых.
3. Реестр заинтересованных сторон. Создается на этапе инициации. Включает как список интересантов, так и их требования и ожидания.
4. Соглашения. Если проект предполагает закупки, то требования покупателей документируются в контрактах. Но и иные любые соглашения или даже переписка тоже могут быть источником требований.
5. Процессные активы компании. Например, исторические записи или вынесенные уроки. Включают прошлые требования с похожих проектов, и могут помочь выявить релевантные процессы и ожидания. Например, требования к отчетности, к управлению проектом, к совместимости систем. Вынесенные уроки помогут проверить, что мы ничего не забыли в этом проекте.

Процесс Сбора требований

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

1. качеству: "Компонент должен выдерживать нагрузку в 200 кг"
2. бизнес-процессу: "Расходы на проект должны отслеживаться и рапортоваться так-то"
3. комплаенсу: "По закону мы должны реализовать это так-то"
4. управлению проектом: "Мы требуем использования таких-то процедур управления рисками на проекте"

То есть, область знаний Управления требованиями касается всех требований, не только тех, что относятся к самому продукту. Это критично для успеха проекта, поскольку потеря требований будет вести к конфликтам, вплоть до провала проекта.

Документация: План управления требованиями

План управления требованиями - второй выход процесса Планирования управления содержанием, также отражает аксиому PMP "планируй прежде чем делать". План управления требованиями также может быть назван Планом бизнес-анализа. Он должен дать ответ на вопрос: "как только я соберу все требования, что я буду делать для их анализа, ранжирования, и трекинга? Что я включу в Матрицу трассировки требований?"
План управления содержанием и План управления требованиями - это части плана управления проектом. Они дают начало Процессу сбора требований.