Я прочитал сейчас интересный пост про Continuous Discovery от Марины Поляковой и поймал себя на одной мысли.

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

Да, если мы создаем продукт, то описываемая Мариной цепочка "цель -> проблема -> гипотеза -> требование -> проверка" действительно работает очень хорошо. Она помогает не перепрыгивать сразу к решению и постоянно сверяться с реальностью.

Но бизнес-анализ то намного шире продуктовой разработки.

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

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

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

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

Наверное, зрелость и эффективность бизнес-аналитика состоит не только в том, чтобы не путать проблему с ее решением (о чем Марина нам еще раз напоминает, за что ей отдельная благодарность), но и в том, чтобы понимать природу самого требования.

Потому что вопрос "какую проблему мы решаем?" очевидно очень важен, но вопрос "почему это требование вообще существует?" иногда оказывается еще важнее.