Сбор требований - По шагам / BA

1

Понять проблему, а не фичу Зачем?

Стейкхолдер приходит с решением — докопайся до проблемы

⌄

Вопросы

Какую проблему мы решаем этой фичей?
Стейкхолдер часто приходит с готовым решением, минуя проблему. Этот вопрос возвращает разговор к корню.
Кто конкретно с этим сталкивается и как часто?
Помогает понять масштаб — решаем боль 1000 пользователей или одного руководителя.
Как люди обходятся без этого сейчас?
Если обходятся легко — проблема не критична. Если с трудом — высокий приоритет.
Почему это важно именно сейчас?
Выявляет скрытый дедлайн или внешний триггер — конкурент запустил фичу, регулятор требует, CEO увидел.
Есть ли жалобы, отзывы или данные, подтверждающие проблему?
Отличает реальную боль от предположения. Без данных — это гипотеза, не факт.

Свой вопрос

Заметки

AS-IS Как работает СЕЙЧАС

2

Ожидаемый результат и метрики Что измеряем?

Нужна конкретная цифра — не "стало лучше", а "выросло с X до Y"

⌄

Вопросы

Как мы поймём, что фича работает? Какая метрика?
Без метрики невозможно оценить успех. Часто стейкхолдер не думал об этом — помоги ему сформулировать.
Какая конкретная цифра будет считаться успехом?
"Стало лучше" — не метрика. "Конверсия выросла с 3% до 5%" — метрика.
Что изменится для пользователя после запуска?
Проверяет что фича реально меняет опыт, а не просто добавляет кнопку ради кнопки.
Что изменится для бизнеса?
Помогает связать фичу с бизнес-целью — без этого сложно обосновать приоритет.
Как эта метрика выглядит сейчас — есть ли базовая линия?
Без базовой линии ты не докажешь что фича сработала. Нужно зафиксировать точку отсчёта до запуска.

Свой вопрос

Заметки

3

Откуда данные и кто нам нужен? ⚠ Самый важный

Проверь: данные есть, дата-аналитик подключён, юридика чистая — иначе фича не взлетит

⌄

Вопросы ⚠ риск

Какие данные нужны для работы этой фичи?
Большинство фич требуют данных для работы или измерения результата. Выясни что именно нужно до начала разработки.
Эти данные у нас уже есть? В каком виде и где хранятся?
Если данных нет — фича не взлетит. Это самый частый невидимый риск который обнаруживают уже в середине разработки.
Кто владелец данных — нужно ли согласование с другой командой?
Данные могут принадлежать другой команде. Согласование занимает время — выясни это на старте.
Данные чистые? Есть ли пропуски или аномалии?
Грязные данные дадут неверные результаты. Аналитик должен это проверить до разработки.
Нужно ли подключать дата-аналитика?
Аналитик скажет чистые ли данные, как их получить, сколько займёт. Подключай на старте — не в конце.
Если данных нет — сколько времени займёт начать их собирать?
Сбор данных может занять недели или месяцы. Это критично для оценки реального дедлайна.
Есть ли технические ограничения?
Архитектура системы может не позволить реализовать фичу быстро. Уточни у разработчиков до написания требований.
Есть ли юридические ограничения (персональные данные, налоги, compliance)?
Персональные данные, финансы, медицина — всё регулируется. Лучше узнать сейчас чем переделывать после разработки.
Какие зависимости от других команд или систем?
Зависимость от другой команды — риск для дедлайна. Нужно согласовать заранее.

Свой вопрос

Заметки

4

Рамки задачи — скоуп и дедлайн Что входит?

Что делаем сейчас, что потом, когда — и есть ли жёсткий дедлайн

⌄

Вопросы

Кто пользователи этой фичи? (физлица / юрлица / все?)
Разные аудитории — разные сценарии и требования. Это влияет на скоуп и сложность.
Что точно входит в скоуп?
Без явного скоупа разработчики начнут делать "всё что логично" — и никогда не закончат.
Что точно не входит в скоуп?
Зафиксировать что НЕ делаем — так же важно как что делаем. Это защита от расползания скоупа.
На каких платформах? (мобайл / веб / оба?)
Разные платформы — разные команды и сроки. Уточни сразу чтобы не было сюрпризов.
Есть ли дедлайн? Жёсткий или мягкий?
Жёсткий дедлайн меняет приоритизацию и скоуп. Если привязан к маркетинговой кампании — это риск.
Привязан ли дедлайн к кампании или внешнему событию?
Если анонс уже запланирован — нужно подтвердить реалистичность сроков с разработчиками заранее.
Какой приоритет относительно других задач?
Команда не может делать всё одновременно. Нужно понять что подвинется ради этой фичи.

Свой вопрос

Заметки

TO-BE Как должно работать ПОСЛЕ

Допущения Что принимаем как данность?

Критерии приёмки При каких условиях готово?

5

Зафиксировать и определить следующие шаги Итог

Не уходи без чёткого списка — кто что делает до следующей встречи

⌄

Чеклист перед завершением

Зафиксировал все открытые вопросы и риски?
Открытые вопросы должны быть явно записаны — иначе они теряются и всплывают в середине разработки.
Договорились кто проверяет данные с дата-аналитиком?
Без конкретного ответственного это не будет сделано. Зафиксируй имя и срок.
Стейкхолдер знает что ему нужно уточнить?
Без чёткого "домашнего задания" стейкхолдер забудет. Проговори вслух и зафиксируй.
Назначен следующий созвон или дедлайн по уточнениям?
Договорённости без даты — не договорённости. Назначь сразу пока оба на звонке.
Если нашёл риск — предложил решение, а не просто констатировал?
BA который только называет проблему — это репортёр. BA который предлагает решение — это партнёр бизнеса.

Свой вопрос

Следующие шаги