Бизнес-аналитик в IT — это человек, который превращает «хочу кнопку, чтобы было удобно» в проверяемые требования, границы системы и критерии приёмки; главные ошибки бизнес-аналитиков — не в UML и не в “красивых” документах, а в цене недосказанности: переделки, срыв сроков и конфликт ожиданий между бизнесом, разработкой и тестированием.

Самое обидное: многие промахи выглядят как «ну мелочь же». А потом эта «мелочь» приезжает в прод, и выясняется, что интеграция с 1С падает на закрывающих документах, в СБП не учитывается отмена платежа, а в МойСклад нельзя вернуть товар “как в офлайне”. И виноват формально никто — просто требования были “на глазок”.

Ниже — 7 типичных ошибок, которые встречаю и у начинающих, и у опытных (особенно у тех, кто пережил три проекта и решил, что теперь он бессмертен). Параллельно разберём, как писать требования так, чтобы разработка, QA и бизнес читали одно и то же, а не три разных романа.

7 типичных ошибок бизнес-аналитиков и как не наступать на них снова

1) Путать «цель бизнеса» с «хотелкой интерфейса»

Тезис: если нет бизнес-цели и метрики, требования превращаются в набор украшений.

Как выглядит: «Сделайте фильтры как на Ozon» вместо «сократить время поиска товара с 90 до 45 секунд».

Цена ошибки: команда делает “похоже”, но не решает задачу. Потом начинаются правки, A/B-тесты “вслепую”, и сроки едут.

• Правильно: цель → сценарии → требования → критерии приёмки.
• Подводный камень: бизнес часто сам не формулирует цель. BA должен вытянуть её вопросами, а не угадывать.

2) Требования без границ: «система должна…» — и дальше бесконечность

Тезис: границы системы важнее, чем её хотелки. Потому что границы — это деньги.

Как выглядит: «Интеграция с 1С» без уточнения: какой контур (УТ/ERP/БП), какие документы, онлайн/батч, кто источник истины.

Цена ошибки: всплывают “неучтённые” сущности: возвраты, корректировки, статусы, закрытие периода. И это уже не “маленькая интеграция”, а мини-проект.

1. Опишите контекст: акторы, внешние системы (1С, CRM, СБИС, ЮKassa/СБП).
2. Задайте границы: что точно входит, что точно нет (Out of scope).
3. Назначьте источник правды по данным (master data).

3) Ошибки use-case: сценарий есть, а исключений и альтернатив — нет

Тезис: 80% багов живёт в “а что если…”. Ошибки use-case обычно не в основном потоке, а в исключениях.

Как выглядит: use-case “Оплатить заказ” описан, но нет: отмены, частичной оплаты, просрочки сессии, повторной попытки, возврата, расхождения сумм.

Цена ошибки: QA тестирует “счастливый путь”, прод падает на реальной жизни. А реальная жизнь — токсичная.

4) «Как писать требования»: писать для себя, а не для команды

Тезис: требования — не литература и не дневник аналитика. Это рабочий контракт между бизнесом и командой.

Как выглядит: массив текста без структуры: “пользователь должен иметь возможность…”, “иногда нужно…”, “желательно…”.

Цена ошибки: разработка интерпретирует одно, тестирование — другое, бизнес — третье. Потом митинг “кто так понял”.

• Хороший минимум: User Story + Acceptance Criteria (Given/When/Then) + макет/ссылка + ограничения.
• Подводный камень: “всё описано в Figma” — нет, не описано. В Figma — картинка, а не правила.

5) Нет модели данных и словаря терминов: «клиент», «покупатель», «контрагент» — это кто?

Тезис: терминология — не бюрократия, это борьба с разночтениями.

Как выглядит: в одном месте “клиент”, в другом “контрагент”, в БД “customer”, в 1С “Партнёр”. Все правы, и все ошибаются.

Цена ошибки: дубли, неверные отчёты, поломанные интеграции, вечная миграция данных.

1. Сделайте глоссарий (10–30 терминов хватает на большинство модулей).
2. Нарисуйте минимальную ER-модель (сущности и связи, даже без атрибутов сначала).
3. Укажите владельца данных: кто создаёт/обновляет/удаляет.

6) «Согласовали требования» ≠ «готово к разработке»

Тезис: согласование — это не факт понимания, а факт подписи. Понимание проверяется вопросами и примерами.

Как выглядит: бизнес сказал “ок”, а потом на демо: “мы не это имели в виду”. Классика жанра.

Цена ошибки: переделка. А переделка в IT редко бывает “чуть-чуть”: меняется логика, тесты, документация, иногда архитектура.

• Практика: перед стартом разработки прогоните 3–5 примеров “живых” кейсов с реальными данными.
• Подводный камень: BA стесняется уточняющих вопросов, чтобы не выглядеть «неумным». Это дороже любого стыда.

7) Игнорировать нефункциональные требования (NFR): безопасность, нагрузка, аудит

Тезис: то, что “не видно в интерфейсе”, обычно и ломает релиз.

Как выглядит: сделали форму, но забыли: права доступа, журналирование, сроки хранения, 152-ФЗ (персональные данные), время ответа, пиковые нагрузки.

Цена ошибки: срочная “закладка” логирования и ролей в последний момент, блокировка релиза службой ИБ, или падение под нагрузкой после рассылки.

Экспертный вердикт и инструмент: чек‑лист “требование живое или мёртвое?”

Если вы меняете профессию на BA или уже работаете 1–3 года, вот быстрый фильтр. Он спасает от половины “почему всё поехало”.

• 1) Какая бизнес-цель и метрика? (время, деньги, конверсия, снижение ручного труда)
• 2) Где границы? Что в scope, что out of scope, какие внешние системы (1С, СБИС, банк, CRM).
• 3) Как выглядит use-case целиком? Основной поток + альтернативы + исключения (не только “успех”).
• 4) Какие данные и термины? Глоссарий + минимальная модель данных.
• 5) Как проверяем готовность? Acceptance criteria в формате Given/When/Then + примеры данных.
• 6) Какие NFR? роли, аудит, нагрузка, безопасность, хранение данных.
• 7) Кто подписывает и кто реально использует? Стейкхолдер “подписант” и стейкхолдер “страдалец в операционке” — не всегда один человек.

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