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

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

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

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

После сбора и финализации требований их документируют. Документация - выход из процесса Сбора требований, она помогает понять, что все требования явные и непротиворечивые. Документация на требования будет входом в процессы Определения содержания и Разработки ИСР.
Требования могут включать разную информацию, но то, что обязательно нужно - это критерии приемки. Главный вопрос, который мы задаем заинтересованным сторонам - "Как мы поймем, что требование исполнено?". Это также и хороший способ понять, выполнима ли задача в принципе.
Уровень документации требований прорабатывается до тех пор, пока каждое требование не будет соответствовать критериям ясности, полноты, и измеримости. Требования нужно излагать так, чтобы связанные поставки продукта можно было протестировать или измерить, для подтверждения приемки. Сама документация на требования может называться различно, например Бизнес-требования, или Функциональные требования, или 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. управлению проектом: "Мы требуем использования таких-то процедур управления рисками на проекте"

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