Роли аналитиков: Бизнес-аналитик и Системный аналитик
Введение: переводчик между бизнесом и разработкой 🧩
В проекте важно, чтобы бизнес говорил о целях, а техническая команда понимала, что делать.
Роли аналитиков — это «переводчики», которые превращают ожидания в понятные требования.
Роли аналитиков — это «переводчики», которые превращают ожидания в понятные требования.
Бизнес‑аналитик (BA) отвечает за ценность и процессы,
системный аналитик (SA) — за то, как система это реализует.
системный аналитик (SA) — за то, как система это реализует.
💡 Совет: путаница ролей приводит к хаосу: бизнес ждёт одно, а система делает другое.
✅ Вывод: BA и SA нужны, чтобы соединить «что нужно» и «как это сделать».
✅ Вывод: BA и SA нужны, чтобы соединить «что нужно» и «как это сделать».
Проблема: требования без владельца ❌
Если нет разделения ролей:
- бизнес говорит абстрактно;
- разработка не понимает деталей;
- QA не знает, как проверить.
Когда роли разделены:
- цели бизнеса понятны;
- требования структурированы;
- система проектируется осознанно.
✅ Вывод: роли аналитиков экономят время и снижают риски.
Чем помогает и как работает
- Помогает разделить ответственность за бизнес-ценность и техническую реализацию без потери связи между ними.
- Помогает снизить ошибки коммуникации между бизнесом, разработкой и QA.
- Помогает строить требования так, чтобы их можно было и реализовать, и проверить на достижение цели.
Как это работает:
- Шаг 1: BA формулирует бизнес-цель, метрики и процессный контекст.
- Шаг 2: SA переводит цель в системные требования, API и ограничения.
- Шаг 3: команда связывает BR -> SR и формирует единые критерии приёмки.
- Шаг 4: требования синхронно уточняются на протяжении реализации.
✅ Вывод: чёткие границы BA и SA ускоряют работу и повышают качество требований.
Ключевые термины (простыми словами)
- Business Analyst (BA) — аналитик, который формулирует бизнес‑цели и процессы.
- System Analyst (SA) — аналитик, который описывает поведение системы и интеграции.
- Stakeholders (стейкхолдеры) — участники, чьи цели и ожидания нужно учитывать.
- Business requirements — требования о ценности и результате для бизнеса.
- System requirements — требования к поведению системы и данным.
- As‑Is / To‑Be — текущее и целевое состояние процесса.
- Use case — сценарий взаимодействия пользователя и системы.
- Traceability (трассируемость) — связь бизнес‑целей с системными требованиями.
✅ Вывод: эти термины показывают границы ответственности BA и SA.
Самое важное (must-know)
- BA отвечает за бизнес-смысл, SA — за системную реализуемость; подмена ролей создаёт пробелы в требованиях.
- Любая системная детализация должна быть связана с бизнес-целью через трассируемость.
- User stories без системной конкретики и SR без бизнес-контекста одинаково опасны.
- Общие критерии приёмки BA+SA обязательны для корректной проверки результата.
- Совместная работа BA и SA — это процесс передачи контекста, а не разовый handoff.
✅ Вывод: в этой теме критично не «кто важнее», а как роли дополняют друг друга в одном потоке требований.
1. Бизнес‑аналитик (BA) — про цели и ценность
Назначение: понять, зачем бизнесу нужна фича и какую проблему она решает.
Простыми словами: BA выясняет, какую бизнес-проблему нужно решить и как измерить результат, прежде чем команда начнёт реализацию.
Аналогия: врач, который ставит диагноз, прежде чем назначить лечение.
Простыми словами: BA выясняет, какую бизнес-проблему нужно решить и как измерить результат, прежде чем команда начнёт реализацию.
Аналогия: врач, который ставит диагноз, прежде чем назначить лечение.
Пример:
Цель: повысить конверсию записи на курс на 15%.Проблема: пользователи теряются в каталоге.🔎 Как это происходит на практике:
- BA собирает контекст у стейкхолдеров и формулирует целевую бизнес-ценность.
- Фиксирует метрики успеха и границы задачи (что входит/не входит).
- Описывает процесс As-Is и целевой To-Be сценарий.
- Передаёт SA согласованный бизнес-контекст для детализации. Характеристики:
- ✅ фокус на бизнес‑ценности;
- ✅ работа со стейкхолдерами;
- ✅ описание процессов (As‑Is / To‑Be).
Когда использовать: всегда, когда нужно понять бизнес‑смысл и метрики.
✅ Вывод: BA отвечает за «что и зачем».
✅ Вывод: BA отвечает за «что и зачем».
2. Системный аналитик (SA) — про поведение системы
Назначение: описать, как система должна работать.
Простыми словами: SA превращает бизнес-цель в конкретное поведение системы, которое можно разработать и протестировать.
Аналогия: инженер, который превращает идею в техническую схему.
Простыми словами: SA превращает бизнес-цель в конкретное поведение системы, которое можно разработать и протестировать.
Аналогия: инженер, который превращает идею в техническую схему.
Пример:
Система должна показывать каталог за <=2 сек.API /courses поддерживает фильтры: topic, level, duration.🔎 Как это происходит на практике:
- SA декомпозирует цель в системные требования и ограничения.
- Описывает API-контракты, данные и интеграционные зависимости.
- Формулирует сценарии ошибок и пограничные случаи.
- Уточняет требования с разработкой и QA до уровня реализации. Характеристики:
- ✅ детализация требований;
- ✅ описание данных, интеграций, API;
- ✅ сценарии ошибок и исключений.
Когда использовать: при проектировании поведения системы.
✅ Вывод: SA отвечает за «как это будет работать».
✅ Вывод: SA отвечает за «как это будет работать».
3. Как BA и SA работают вместе
Назначение: показать передачу целей бизнеса в технические требования.
Простыми словами: эффективная связка BA и SA работает как непрерывная передача контекста, а не как «передал документ и ушёл».
Аналогия: эстафета — BA передаёт «палочку» SA, чтобы команда дошла до результата.
Простыми словами: эффективная связка BA и SA работает как непрерывная передача контекста, а не как «передал документ и ушёл».
Аналогия: эстафета — BA передаёт «палочку» SA, чтобы команда дошла до результата.
Логика передачи:
- BA формулирует бизнес‑цель и процессы.
- SA переводит цель в системные требования.
- Команда получает понятные задачи и критерии.
🔎 Как это происходит на практике:
- BA и SA синхронизируют терминологию и ожидания по результату.
- SA уточняет системные последствия бизнес-решений.
- BA валидирует, что техническая детализация сохраняет исходную ценность.
- Команда фиксирует согласованные критерии приёмки для реализации.
✅ Вывод: BA и SA — связка, а не конкуренты.
4. Артефакты BA и SA
Назначение: зафиксировать, какие документы создаёт каждая роль.
Простыми словами: артефакты BA и SA должны дополнять друг друга: одни объясняют зачем, другие показывают как.
Аналогия: разные наборы инструментов в одной мастерской.
Простыми словами: артефакты BA и SA должны дополнять друг друга: одни объясняют зачем, другие показывают как.
Аналогия: разные наборы инструментов в одной мастерской.
BA обычно делает:
- описание целей и KPI;
- As‑Is / To‑Be;
- user stories;
- приоритизацию.
SA обычно делает:
- системные требования;
- спецификации API;
- модели данных;
- сценарии ошибок.
🔎 Как это происходит на практике:
- BA фиксирует цели, KPI, процессы и приоритеты требований.
- SA фиксирует SR, API, модель данных и ограничения интеграций.
- Артефакты связываются через BR -> SR трассируемость.
- Актуальность документов поддерживается вместе с изменениями требований.
✅ Вывод: артефакты разные, но взаимосвязанные.
Сравнение: BA vs SA
| Критерий | Бизнес‑аналитик | Системный аналитик |
|---|---|---|
| Фокус | ценность и процессы | система и данные |
| Вопрос | «зачем?» | «как?» |
| Артефакты | цели, KPI, user stories | спецификации, API, интеграции |
| Кому ближе | бизнес | разработка |
Часто спрашивают на собеседованиях
- Чем отличается BA от SA? цели бизнеса vs поведение системы.
- Кто пишет user stories? чаще BA.
- Кто описывает API и интеграции? обычно SA.
- Нужна ли трассируемость? да, чтобы связать цели и требования.
- Можно ли одному человеку выполнять обе роли? да, но риски выше.
✅ Вывод: это ключевые интервью‑вопросы по ролям аналитиков.
Типичные ошибки
Ошибка 1: BA уходит в технику
❌ описывает API вместо целей
✅ фокус на ценности и процессах
✅ фокус на ценности и процессах
Ошибка 2: SA пишет «хотелки»
❌ нет системной конкретики
✅ описывать поведение и ограничения
✅ описывать поведение и ограничения
Ошибка 3: Нет трассируемости
❌ не видно связи целей и требований
✅ связывать BR → SR
✅ связывать BR → SR
Ошибка 4: Нет общих критериев
❌ QA не может проверить
✅ acceptance criteria обязательны
✅ acceptance criteria обязательны
Ошибка 5: Роли не согласованы
❌ дублирование и конфликт
✅ разделение ответственности
✅ разделение ответственности
Best Practices
- BA фиксирует цели и KPI.
- SA переводит цели в системные требования.
- Всегда поддерживайте трассируемость.
- Артефакты должны дополнять друг друга.
- Согласовывайте требования со стейкхолдерами и командой.
Заключение
Ключевые мысли
🎯 BA отвечает за «что и зачем».
🎯 SA отвечает за «как».
🎯 Вместе они превращают хаос ожиданий в ясные требования.
🎯 SA отвечает за «как».
🎯 Вместе они превращают хаос ожиданий в ясные требования.
Теперь вы понимаете, какую роль выбирать и как выстраивать совместную работу.