Рекомендации по сбору и приоритизации требований для бизнес-аналитика

Конспект статьи. Автор оригинала: Дмитрий Сушков (WMT Group)

Обзор процесса сбора и приоритизации требований. Автор приводит распространённую оценку: дефект требований, найденный на этапе разработки, обходится примерно в 10 раз дороже, чем на этапе анализа, а в эксплуатации — примерно в 100 раз.

Шаги

• Определить стейкхолдеров: владелец продукта, заказчики, пользователи, разработка, тестирование, DevOps, маркетинг, поддержка. Помогает матрица стейкхолдеров.
• Подготовиться: цели, ограничения (бюджет, сроки, безопасность), текущие процессы, контекстная диаграмма.
• Выбрать методы: интервью для индивидуальных потребностей, воркшопы для консенсуса, наблюдение для скрытых обходных путей, анализ документов.
• Формализовать: проверить на однозначность, реализуемость и проверяемость; оформить в use case, user story, BPMN или UML; согласовать.

MoSCoW

Must have — без этого проект провалится; Should have — нужно, но не критично; Could have — если хватит ресурсов; Won't have — не в этом цикле.

Ловушки

• Стейкхолдеры меняют решения — фиксировать договорённости рано, записывать встречи.
• Scope creep — нужен регламент запросов на изменение (Change Request).
• Игнорирование технических ограничений: простое на вид требование может быть очень сложным.
• Не опрошены конечные пользователи.