Сбор требований в бизнес-анализе — как собрать и проверить данные без пробелов

Сбор требований в бизнес-анализе — это процесс, где вы добываете, проверяете и фиксируете ожидания бизнеса и пользователей так, чтобы разработка не строила «дом по слухам»: требования должны быть полными, согласованными, проверяемыми и привязанными к цели и метрикам.

Самая частая причина провалов — не «плохие разработчики» и не «тупые пользователи», а пробелы в данных: кто-то что-то имел в виду, но не сказал; сказали, но не так поняли; поняли, но не проверили. В итоге на выходе получается комбо: сроки растут, бюджет течёт, а виноватым назначают аналитика (или того, кто оказался рядом).

По рынку это видно и по вакансиям: от бизнес-аналитика в РФ почти всегда ждут умения вести сбор требований, анализ требований, описывать процессы (BPMN), писать постановки в Jira/Confluence, дружить с SQL на уровне «вытащить выборку», и — сюрприз — уметь договариваться. Зарплатные вилки плавают по регионам и компаниям, но типичная картина такая: Junior/стажёр — примерно 70–120 тыс. ₽, Middle — 150–250 тыс. ₽, Senior — 250–400+ тыс. ₽ (особенно в финтехе и крупных экосистемах). И да, быстрее растут те, кто умеет не просто «как собрать требования», а как их проверять и закрывать риски.

Где в требованиях появляются «дыры» (и почему это норм)

Тезис: пробелы возникают не из-за глупости, а из-за разного контекста

Бизнес говорит языком денег и рисков, пользователи — языком «чтобы было удобно», IT — языком ограничений и интеграций. Один и тот же запрос «сделайте отчёт» означает три разных вещи. Если не синхронизировать контекст, сбор требований превращается в игру «испорченный телефон», только на кону релиз.

Практический вывод: фиксируйте контекст: цель, кто заказчик, кто пользователь, какое решение принимают по результату.

Подводный камень: собирать требования «по форме», не задавая вопрос «зачем». Так рождаются красивые ТЗ, которые никому не помогают.

Тезис: «полнота» требований — это не 200 страниц текста

Полнота — когда нет критичных неизвестных для разработки и тестирования. На практике это означает: границы, сценарии, исключения, данные, интеграции, нефункциональные требования (скорость, безопасность, доступность), правила доступа.

Практический вывод: думайте как тестировщик: «а как я это проверю?» Если не проверяется — требование ещё сырое.

Подводный камень: путать «хотелки» со «must have». Приоритеты без цифр — это просто мнения.

Пошаговый процесс: как собрать требования без пробелов

Шаг 1. Декомпозируйте цель (не фичи)

Сбор требований начинается не с «какие кнопки», а с цели: что должно измениться в бизнесе. Типовые форматы — OKR (цели и ключевые результаты) или хотя бы «боль → изменение → метрика».

Цель: что улучшаем (например, сократить время обработки заявки).
Метрика: как измеряем (время, конверсия, % ошибок).
Ограничения: сроки, бюджет, легаси (1С, CRM, интеграции).
Стейкхолдеры: кто влияет/страдает/согласует.

Практический вывод: если метрики нет — вы не собрали требования, вы собрали пожелания.

Подводный камень: «метрика = число пользователей». Нет. Метрика — это изменение результата, а не факт существования людей.

Шаг 2. Выберите технику сбора требований под ситуацию

В бизнес-анализе нет «одного правильного интервью». Есть набор инструментов, и вы выбираете по рискам и сложности.

Техника	Когда подходит	Плюсы	Минусы/риски
Интервью 1:1	Нужен контекст, мотивация, боли	Быстро, глубоко	Субъективность, «каждый тянет одеяло»
Воркшоп (сессия)	Нужно согласование между отделами	Снимает конфликты, ускоряет решения	Требует модерации, иначе «рынок в пятницу»
Наблюдение (shadowing)	Реальные процессы отличаются от регламентов	Находит скрытые костыли	Дорого по времени
Анализ данных (SQL/выгрузки)	Нужны факты по ошибкам/времени/частоте	Снимает «мне кажется»	Данные могут быть грязными
Прототипирование (Figma, бумага)	Нужно быстро уточнить UX и логику	Рано выявляет недопонимание	Есть риск принять прототип за готовый дизайн

Практический вывод: комбинируйте минимум 2 техники: интервью + данные или воркшоп + прототип.

Подводный камень: надеяться, что один «созвон на час» закроет анализ требований. Не закроет.

Шаг 3. Опишите требования в форме, удобной команде

Формат важен не меньше содержания. В РФ чаще всего работает связка: Jira (задачи) + Confluence (описание) + BPMN-диаграммы (процессы) + прототипы. В тексте требование должно быть:

однозначным (без «быстро», «удобно», «как обычно»);
проверяемым (есть критерии приёмки);
атомарным (одно требование — одна мысль);
с привязкой к источнику (кто подтвердил).

Практический вывод: если вы не можете написать acceptance criteria (критерии приёмки) — требование ещё не готово к разработке.

Подводный камень: путать пользовательские истории (User Story) с ТЗ. User Story без критериев — это фанфик.

Шаг 4. Проверьте требования: валидация и верификация

Тут магия простая: валидация — «мы делаем правильную вещь?», верификация — «мы делаем вещь правильно?». Для «без пробелов» нужны обе.

Ревью со стейкхолдерами: подтверждаем смысл, приоритеты, границы.
Ревью с командой: проверяем реализуемость, интеграции, риски.
Трассировка: цель → требования → задачи → тесты.
Чек на противоречия: одно требование не должно ломать другое.

Практический вывод: встроите «Definition of Ready» (что должно быть, чтобы взять в разработку) и «Definition of Done» (что значит “готово”). Это дисциплина, а не бюрократия.

Подводный камень: согласовать требования только с бизнесом. Потом команда скажет: «мы так не можем», и вы откатитесь на две недели назад.

Реальные кейсы: как обычно ломается сбор требований

Кейс удачный: прототип спас 2 спринта

Компания внедряла личный кабинет для партнёров. В требованиях было «партнёр видит статус заявки». На воркшопе выяснилось, что у разных отделов 5 разных статусов с одинаковыми названиями, а часть вообще живёт в 1С и не выгружается. Слепили прототип в Figma, показали 6 партнёрам, добавили правило маппинга статусов и честную заглушку «данные обновляются раз в 2 часа». Итог: меньше споров, тесты стали возможны, релиз прошёл без сюрпризов.

Что сработало: сбор требований + проверка на данных/интеграциях + прототипирование.

Кейс провальный: «сделайте как в Excel»

Внутренний отчёт надо было перенести в веб. Пользователь сказал: «как в Excel, только в браузере». Аналитик записал, команда разработала таблицу, пользователи устроили восстание: им нужны были фильтры по 12 полям, экспорт с формулами, комментарии, и чтобы работало при 200k строк. Нефункциональные требования (производительность) не собрали, источники данных не проверили, критерии приёмки отсутствовали. В итоге — переделка, конфликт, минус квартал времени.

Где пробило: не сделали анализ требований через сценарии и объёмы данных.

Скрытая цена «неполных требований» (для тех, кто любит цифры)

В российских командах типичная математика простая: если фича уходит в переделку после разработки, вы платите минимум x1.5–x3 от изначальной стоимости (разработка + тестирование + перепроверки + заново согласование). Один пропущенный сценарий в интеграции с 1С/CRM — и вы внезапно обнаруживаете, что «быстро поправим» превращается в отдельный проект.

Практический вывод: лучший момент найти ошибку — на этапе сбора требований. Второй лучший — на прототипе. Худший — в проде в пятницу вечером.

Подводный камень: экономить на аналитике, а потом удивляться, почему «разработчики не угадали».

Экспертный вердикт и инструмент: чек-лист «без пробелов»

Если вы вкатились в BA или апгрейдите навык «сбор требований / анализ требований / как собрать требования» — вот короткий чек-лист, который реально спасает проекты. Хотите — распечатайте и приклейте рядом с Яндекс Трекером. Ещё похожие разборы лежат на https://itokno.ru.

Цель и метрика: что меняем и как измеряем?
Границы: что точно НЕ делаем в этом релизе?
Сценарии: основной поток + 5–10 исключений (ошибки, отмена, нет доступа).
Данные: источники, поля, объёмы, качество, частота обновления.
Интеграции: 1С/CRM/шины/почта — кто и как обменивается?
Права доступа: роли, ограничения, аудит действий.
НФТ: производительность, безопасность, SLA (время доступности), логирование.
Критерии приёмки: как тестируем, что значит «готово».
Трассировка: требование связано с целью и задачами.
Согласование: кто финально подтвердил, где это записано.

Частые вопросы

С чего начать сбор требований, если я новичок и боюсь «задолбать вопросами»?

Начните с цели и метрики, а затем попросите показать процесс «как сейчас» на реальном примере. Вопросы — это не занудство, а страховка от переделок. Если вам отвечают «просто сделай», значит, цель ещё не сформулирована.

Чем сбор требований отличается от анализа требований?

Сбор требований — добыча исходных ожиданий и фактов (интервью, воркшоп, наблюдение, данные). Анализ требований — приведение этого хаоса к структуре: приоритизация, устранение противоречий, уточнение сценариев, проверяемость и готовность к разработке.

Как понять, что требования «достаточно хорошие», а не идеальные?

Когда команда может оценить задачу, тестировщик — написать проверки, а заказчик — подтвердить критерии приёмки. И при этом известны ограничения, данные и интеграции. Идеал недостижим, но «проверяемо и согласовано» — вполне.

Нужно ли всегда писать ТЗ на 50 страниц?

Нет. Часто лучше работает набор: краткое описание в Confluence, user story с критериями приёмки в Jira, пара диаграмм BPMN и прототип. Объём текста не равен качеству требований.

Что делать, если стейкхолдеры конфликтуют и дают разные требования?

Вытащить конфликт в явный вид: общая цель, разные метрики успеха, разные риски. Провести воркшоп, зафиксировать решения и владельца решения. Если владельца нет — пробел в управлении, а не в аналитике.

Какие артефакты чаще всего ждут на собеседованиях бизнес-аналитика в РФ?

Примеры user story с acceptance criteria, схема процесса (BPMN/UML activity), описание интеграций и данных, умение работать с Яндекс Трекером/Confluence, базовый SQL. И почти всегда — кейс «как вы собирали и проверяли требования».

Можно ли выйти на Junior BA за 3–6 месяцев?

Реалистично, если параллельно делаете практику: учебный проект с интервью, описанием процессов, требованиями в Яндекс Трекер и простым прототипом. Без практики сроки обычно растягиваются: знания есть, а «как собрать требования» в реальности — нет.