Бизнес‑аналитик (BA): что делает, зачем нужен и как экономит бюджет на разработке
Запрос “бизнес аналитик кто это”, “BA в IT”, “зачем нужен аналитик” обычно приходит после боли: требования расплывчаты, разработчики делают “не так”, оценка плавает, а допработы растут.
Коротко: бизнес‑аналитик превращает “идею” и “хотелки” в проверяемые требования. Это снижает риск переработок и делает сроки предсказуемее.
1) Что делает BA (по шагам)
BA отвечает за:
- сбор требований (интервью, воркшопы)
- формализацию: user stories / use cases
- роли и права доступа
- сценарии и состояния
- интеграции и данные
- acceptance criteria (как понять, что “готово”)
- согласование терминов (единый словарь)
BA не “придумывает продукт”, а структурирует требования так, чтобы их можно было реализовать и проверить.
2) Почему без аналитики сроки часто “плывут”
Типовые проблемы без BA:
- требования на уровне “сделайте удобно”
- нет сценариев → оценки нет
- роли/права всплывают поздно → переделка админки
- интеграции “как‑нибудь” → недели на отладку вебхуков
- нет критериев готовности → “почти готово” бесконечно
3) Какие артефакты BA особенно важны заказчику
Минимальный набор:
- scope (in/out)
- список сценариев (user stories)
- роли и права (RBAC)
- интеграции + события/вебхуки
- acceptance criteria
Дополнительно (если нужно):
- BPMN/диаграммы процессов
- прототипы экранов
- ER‑модель данных
4) BA vs Product vs Project Manager: кто за что
- BA: требования, сценарии, критерии приёмки
- Product: ценность, приоритеты, метрики
- Project Manager: план, синхронизация, процесс, риски по срокам
В малых проектах роли могут совмещаться, но функции должны быть закрыты.
5) Когда BA особенно нужен
- много ролей/прав, сложная админка
- сложные интеграции (платежи/CRM/доставка)
- несколько стейкхолдеров
- есть регуляторика/безопасность/PII
- надо “оценить по‑взрослому”, а не “примерно”
6) Как заказчику проверить качество аналитики
Хорошая аналитика:
- читается быстро (структура)
- содержит сценарии и состояния
- содержит “что не делаем”
- даёт критерии приёмки
- помогает оценке (есть декомпозиция)
Плохая аналитика:
- много “воды” и мало проверяемых требований
- нет крайних случаев и интеграций
- нет критериев “готово”
FAQ
BA нужен, если есть ТЗ?
Если ТЗ на уровне “идея”, BA всё равно нужен: превратить это в сценарии и критерии.
BA — это лишний слой?
Нет. Это экономия на переработках и конфликтах “не так поняли”.
Можно без BA?
Можно, если проект очень маленький и требования стабильны. Но даже тогда нужны сценарии и критерии приёмки.
Если хотите — помогу настроить сбор требований: user stories, acceptance criteria и backlog, чтобы разработка не буксовала и не расползалась.