Сбор требований
Шпаргалка BA — отмечай шаги и фиксируй по ходу разговора
00:00
0 из 5 шагов выполнено
Название фичи / проекта
Стейкхолдер — имя и роль
Команда / отдел
Кто принимает финальное решение?
1
Понять проблему, а не фичу Зачем?
Стейкхолдер приходит с решением — докопайся до проблемы
⌄
Вопросы
  • Какую проблему мы решаем этой фичей?
    Стейкхолдер часто приходит с готовым решением, минуя проблему. Этот вопрос возвращает разговор к корню.
  • Кто конкретно с этим сталкивается и как часто?
    Помогает понять масштаб — решаем боль 1000 пользователей или одного руководителя.
  • Как люди обходятся без этого сейчас?
    Если обходятся легко — проблема не критична. Если с трудом — высокий приоритет.
  • Почему это важно именно сейчас?
    Выявляет скрытый дедлайн или внешний триггер — конкурент запустил фичу, регулятор требует, CEO увидел.
  • Есть ли жалобы, отзывы или данные, подтверждающие проблему?
    Отличает реальную боль от предположения. Без данных — это гипотеза, не факт.
Свой вопрос
    Заметки
    AS-IS Как работает СЕЙЧАС
    2
    Ожидаемый результат и метрики Что измеряем?
    Нужна конкретная цифра — не "стало лучше", а "выросло с X до Y"
    ⌄
    Вопросы
    • Как мы поймём, что фича работает? Какая метрика?
      Без метрики невозможно оценить успех. Часто стейкхолдер не думал об этом — помоги ему сформулировать.
    • Какая конкретная цифра будет считаться успехом?
      "Стало лучше" — не метрика. "Конверсия выросла с 3% до 5%" — метрика.
    • Что изменится для пользователя после запуска?
      Проверяет что фича реально меняет опыт, а не просто добавляет кнопку ради кнопки.
    • Что изменится для бизнеса?
      Помогает связать фичу с бизнес-целью — без этого сложно обосновать приоритет.
    • Как эта метрика выглядит сейчас — есть ли базовая линия?
      Без базовой линии ты не докажешь что фича сработала. Нужно зафиксировать точку отсчёта до запуска.
    Свой вопрос
      Заметки
      3
      Откуда данные и кто нам нужен? Самый важный
      Проверь: данные есть, дата-аналитик подключён, юридика чистая — иначе фича не взлетит
      ⌄
      Вопросы риск
      • Какие данные нужны для работы этой фичи?
        Большинство фич требуют данных для работы или измерения результата. Выясни что именно нужно до начала разработки.
      • Эти данные у нас уже есть? В каком виде и где хранятся?
        Если данных нет — фича не взлетит. Это самый частый невидимый риск который обнаруживают уже в середине разработки.
      • Кто владелец данных — нужно ли согласование с другой командой?
        Данные могут принадлежать другой команде. Согласование занимает время — выясни это на старте.
      • Данные чистые? Есть ли пропуски или аномалии?
        Грязные данные дадут неверные результаты. Аналитик должен это проверить до разработки.
      • Нужно ли подключать дата-аналитика?
        Аналитик скажет чистые ли данные, как их получить, сколько займёт. Подключай на старте — не в конце.
      • Если данных нет — сколько времени займёт начать их собирать?
        Сбор данных может занять недели или месяцы. Это критично для оценки реального дедлайна.
      • Есть ли технические ограничения?
        Архитектура системы может не позволить реализовать фичу быстро. Уточни у разработчиков до написания требований.
      • Есть ли юридические ограничения (персональные данные, налоги, compliance)?
        Персональные данные, финансы, медицина — всё регулируется. Лучше узнать сейчас чем переделывать после разработки.
      • Какие зависимости от других команд или систем?
        Зависимость от другой команды — риск для дедлайна. Нужно согласовать заранее.
      Свой вопрос
        Заметки
        4
        Рамки задачи — скоуп и дедлайн Что входит?
        Что делаем сейчас, что потом, когда — и есть ли жёсткий дедлайн
        ⌄
        Вопросы
        • Кто пользователи этой фичи? (физлица / юрлица / все?)
          Разные аудитории — разные сценарии и требования. Это влияет на скоуп и сложность.
        • Что точно входит в скоуп?
          Без явного скоупа разработчики начнут делать "всё что логично" — и никогда не закончат.
        • Что точно не входит в скоуп?
          Зафиксировать что НЕ делаем — так же важно как что делаем. Это защита от расползания скоупа.
        • На каких платформах? (мобайл / веб / оба?)
          Разные платформы — разные команды и сроки. Уточни сразу чтобы не было сюрпризов.
        • Есть ли дедлайн? Жёсткий или мягкий?
          Жёсткий дедлайн меняет приоритизацию и скоуп. Если привязан к маркетинговой кампании — это риск.
        • Привязан ли дедлайн к кампании или внешнему событию?
          Если анонс уже запланирован — нужно подтвердить реалистичность сроков с разработчиками заранее.
        • Какой приоритет относительно других задач?
          Команда не может делать всё одновременно. Нужно понять что подвинется ради этой фичи.
        Свой вопрос
          Заметки
          TO-BE Как должно работать ПОСЛЕ
          Допущения Что принимаем как данность?
          Критерии приёмки При каких условиях готово?
          5
          Зафиксировать и определить следующие шаги Итог
          Не уходи без чёткого списка — кто что делает до следующей встречи
          ⌄
          Чеклист перед завершением
          • Зафиксировал все открытые вопросы и риски?
            Открытые вопросы должны быть явно записаны — иначе они теряются и всплывают в середине разработки.
          • Договорились кто проверяет данные с дата-аналитиком?
            Без конкретного ответственного это не будет сделано. Зафиксируй имя и срок.
          • Стейкхолдер знает что ему нужно уточнить?
            Без чёткого "домашнего задания" стейкхолдер забудет. Проговори вслух и зафиксируй.
          • Назначен следующий созвон или дедлайн по уточнениям?
            Договорённости без даты — не договорённости. Назначь сразу пока оба на звонке.
          • Если нашёл риск — предложил решение, а не просто констатировал?
            BA который только называет проблему — это репортёр. BA который предлагает решение — это партнёр бизнеса.
          Свой вопрос
            Следующие шаги
            Открытые риски
            Риски встречи
            Рисков пока нет — добавь если нашёл в ходе разговора
            Итог встречи
            Заметки по всем шагам
            Заполни заметки в шагах — они появятся здесь
            Скопировано в буфер ✓
            J Подключение к Jira

            Токен хранится только локально в этом браузере. Настройки общие для всех инструментов BA Toolkit. Jira Cloud блокирует прямые запросы из браузера (CORS) — укажи адрес прокси, иначе запрос не пройдёт. Свой бесплатный прокси можно развернуть за 2 минуты: инструкция на GitHub.

            C Подключение к Confluence

            Email и API-токен — от вашего Atlassian-аккаунта (создать токен: id.atlassian.com). Space ID (числовой) можно найти через GET /wiki/api/v2/spaces?keys=КЛЮЧ или в URL пространства. Токен хранится только локально в этом браузере (localStorage) и никуда не отправляется, кроме самого Confluence.

            Confluence Cloud блокирует прямые запросы из браузера (CORS), поэтому нужен адрес прокси — без него запрос не пройдёт. Развернуть бесплатный прокси за 2 минуты: инструкция для Confluence.