Как BA понять, что бизнес-требование сформулировано плохо?

«Если вы читаете требование и чувствуете лёгкое недоумение — это не ваша проблема с вниманием. Это признак плохой формулировки.»

На одном проекте заказчик прислал три страницы с пожеланиями «сделать удобнее». Команда утонула в догадках: что именно удобнее, для кого и насколько? Мы потеряли 2 спринта на уточнения. Это обычная история — и в ней есть повторяющиеся признаки, которые BA должен ловить сразу.

🤷‍♀️ Как понять, что требование плохое — 6 признаков
1️⃣ Нет цели / метрики.
«Сделать интерфейс удобнее» — не цель. Хорошо: «увеличить CR оформления заявки с 12% до 18% за 3 месяца».

2️⃣ Нет критерия приёмки
Если неясно, как принять работу — команда будет гадать. Требование должно иметь явный acceptance criteria.

3️⃣ Слишком широко или размыто.
Фразы типа «улучшить производительность» без контекста — это ловушка. Где, для кого, при каких условиях?

4️⃣ Скрытые допущения
Когда требование подразумевает наличие данных/интеграций/прав доступа, о которых никто не сказал. Это приводит к неожиданным зависимостям.

5️⃣ Фокус на решении, а не на проблеме
«Добавить кнопку X» — это решение. Спросите: какую проблему решит кнопка?

6️⃣ Отсутствие ответственных и ролей
Кто принимает решение, кто владеет результатом? Если это не прописано — будут бесконечные согласования.

🧠 Как быстро исправить — алгоритм из 4 шагов

1️⃣ Спроси «почему» трижды. Не для провокации, а чтобы добраться до реальной боли.
2️⃣ Привяжи к метрике. Какая метрика изменится и на сколько — гипотеза влияния.
3️⃣ Опиши критерии приёмки. Конкретно: «метрика ≥ X», «время ответа < Y», «количество ошибок < Z».
4️⃣ Проверь допущения и зависимости. Источники данных, интеграции, доступы, ограничения по безопасности.

Если хотите — пишите в комментариях одно ваше требование (строчку или пара абзацев). Я скажу, что в нём не так и как переписать в рабочую формулу. 😉

#ITHumanWork #BusinessAnalysis #Требования