Управление требованиями
Управление требованиями - это структурированный процесс сбора, документирования, проверки, расстановки приоритетов и отслеживания требований к продукту, системе или проекту на протяжении всего его жизненного цикла.
Управление требованиями начинается со сбора требований: с помощью интервью, воркшопов или прямого наблюдения выясняется, что на самом деле нужно клиентам, пользователям или внутренним заинтересованным сторонам. После сбора требования документируются, проверяются на противоречия и делятся на функциональные требования (что система должна делать) и нефункциональные требования (например, безопасность, производительность или удобство использования). Только после этого происходит расстановка приоритетов, часто с помощью метода MoSCoW, который распределяет требования по категориям: обязательные, желательные, возможные и отклонённые.
Документация обычно включает документ бизнес-требований, фиксирующий, чего хочет добиться клиент, и соответствующую спецификацию, описывающую, как исполнитель планирует это реализовать. Матрица трассируемости требований связывает каждое отдельное требование с его источником, статусом и тест-кейсами, которые впоследствии подтверждают его выполнение. В agile-проектах эту роль часто берёт на себя бэклог продукта, где требования фиксируются в виде пользовательских историй, которые уточняются и реализуются последовательно, Sprint за Sprint.
Когда требования меняются в середине проекта, вступает в действие правильный процесс управления изменениями: каждое изменение оценивается, взвешивается с точки зрения затрат и сроков и принимается только после формального согласования. Пропустите этот шаг - и вы получите разрастание объёма проекта, постепенное расширение того, что должно быть реализовано, без соответствующей корректировки бюджета или сроков. Именно надёжное управление требованиями делает возможными реалистичные предложения, чёткую ответственность и проверяемые результаты.
Практический пример
Производитель упаковочного оборудования среднего размера планирует новое программное обеспечение для обработки заказов. В рамках управления требованиями проектная команда опрашивает 12 сотрудников из отделов продаж, производства и отгрузки и собирает 84 отдельных требования. После расстановки приоритетов по методу MoSCoW для первого релиза остаётся 31 обязательное требование, зафиксированное в документе требований объёмом 18 страниц. В середине реализации проекта одно из требований, касающееся выставления счетов, меняется, и процесс управления изменениями фиксирует это в матрице трассируемости, чтобы все участники могли проследить связь с исходным требованием.
Как помогает Leanshift
Управление требованиями и Kaizen разделяют одну и ту же базовую позицию: прежде чем что-либо улучшать, нужно точно понять, что действительно нужно. Тщательный сбор требований и последовательное их отслеживание обеспечивают, чтобы работа по улучшению попадала в реальную цель, а не гонялась за симптомами. Эта ясность сама по себе является частью работы с процессом: она выявляет то, что действительно важно, и даёт другим прочную основу для дальнейшего улучшения.
Часто задаваемые вопросы
В чём разница между управлением требованиями и документом требований вроде технического задания?
Управление требованиями - это непрерывный процесс, а документ требований (например, техническое задание) - лишь один из его результатов. Он фиксирует, чего хочет добиться клиент, тогда как соответствующая спецификация описывает, как исполнитель будет это реализовывать.
Когда в проекте должно начинаться управление требованиями?
В идеале - на этапе концепции или коммерческого предложения, ещё до начала самого проекта. Прояснение требований только после начала реализации рискует привести к дорогостоящей переделке и разрастанию объёма проекта.
Как работает управление требованиями в agile-проектах вроде Scrum?
Оно работает итеративно через бэклог продукта вместо разового документа. Требования фиксируются в виде пользовательских историй, постоянно приоритизируются, уточняются и реализуются от Sprint к Sprint.