analysts-roles

Роли аналитиков: Бизнес-аналитик и Системный аналитик

📚 16 вопросовПройти тест →
Лекция

Роли аналитиков: Бизнес-аналитик и Системный аналитик

analysts-roles

Роли аналитиков: Бизнес-аналитик и Системный аналитик

Введение: переводчик между бизнесом и разработкой 🧩

В проекте важно, чтобы бизнес говорил о целях, а техническая команда понимала, что делать.
Роли аналитиков — это «переводчики», которые превращают ожидания в понятные требования.
Бизнес‑аналитик (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 выясняет, какую бизнес-проблему нужно решить и как измерить результат, прежде чем команда начнёт реализацию.
Аналогия: врач, который ставит диагноз, прежде чем назначить лечение.
Пример:
Цель: повысить конверсию записи на курс на 15%.Проблема: пользователи теряются в каталоге.
🔎 Как это происходит на практике:
  1. BA собирает контекст у стейкхолдеров и формулирует целевую бизнес-ценность.
  2. Фиксирует метрики успеха и границы задачи (что входит/не входит).
  3. Описывает процесс As-Is и целевой To-Be сценарий.
  4. Передаёт SA согласованный бизнес-контекст для детализации. Характеристики:
  • ✅ фокус на бизнес‑ценности;
  • ✅ работа со стейкхолдерами;
  • ✅ описание процессов (As‑Is / To‑Be).
Когда использовать: всегда, когда нужно понять бизнес‑смысл и метрики.
Вывод: BA отвечает за «что и зачем».

2. Системный аналитик (SA) — про поведение системы

Назначение: описать, как система должна работать.
Простыми словами: SA превращает бизнес-цель в конкретное поведение системы, которое можно разработать и протестировать.
Аналогия: инженер, который превращает идею в техническую схему.
Пример:
Система должна показывать каталог за <=2 сек.API /courses поддерживает фильтры: topic, level, duration.
🔎 Как это происходит на практике:
  1. SA декомпозирует цель в системные требования и ограничения.
  2. Описывает API-контракты, данные и интеграционные зависимости.
  3. Формулирует сценарии ошибок и пограничные случаи.
  4. Уточняет требования с разработкой и QA до уровня реализации. Характеристики:
  • ✅ детализация требований;
  • ✅ описание данных, интеграций, API;
  • ✅ сценарии ошибок и исключений.
Когда использовать: при проектировании поведения системы.
Вывод: SA отвечает за «как это будет работать».

3. Как BA и SA работают вместе

Назначение: показать передачу целей бизнеса в технические требования.
Простыми словами: эффективная связка BA и SA работает как непрерывная передача контекста, а не как «передал документ и ушёл».
Аналогия: эстафета — BA передаёт «палочку» SA, чтобы команда дошла до результата.
Логика передачи:
  1. BA формулирует бизнес‑цель и процессы.
  2. SA переводит цель в системные требования.
  3. Команда получает понятные задачи и критерии.
🔎 Как это происходит на практике:
  1. BA и SA синхронизируют терминологию и ожидания по результату.
  2. SA уточняет системные последствия бизнес-решений.
  3. BA валидирует, что техническая детализация сохраняет исходную ценность.
  4. Команда фиксирует согласованные критерии приёмки для реализации.
Вывод: BA и SA — связка, а не конкуренты.

4. Артефакты BA и SA

Назначение: зафиксировать, какие документы создаёт каждая роль.
Простыми словами: артефакты BA и SA должны дополнять друг друга: одни объясняют зачем, другие показывают как.
Аналогия: разные наборы инструментов в одной мастерской.
BA обычно делает:
  • описание целей и KPI;
  • As‑Is / To‑Be;
  • user stories;
  • приоритизацию.
SA обычно делает:
  • системные требования;
  • спецификации API;
  • модели данных;
  • сценарии ошибок.
🔎 Как это происходит на практике:
  1. BA фиксирует цели, KPI, процессы и приоритеты требований.
  2. SA фиксирует SR, API, модель данных и ограничения интеграций.
  3. Артефакты связываются через BR -> SR трассируемость.
  4. Актуальность документов поддерживается вместе с изменениями требований.
Вывод: артефакты разные, но взаимосвязанные.

Сравнение: BA vs SA

КритерийБизнес‑аналитикСистемный аналитик
Фокусценность и процессысистема и данные
Вопрос«зачем?»«как?»
Артефактыцели, KPI, user storiesспецификации, API, интеграции
Кому ближебизнесразработка

Часто спрашивают на собеседованиях

  • Чем отличается BA от SA? цели бизнеса vs поведение системы.
  • Кто пишет user stories? чаще BA.
  • Кто описывает API и интеграции? обычно SA.
  • Нужна ли трассируемость? да, чтобы связать цели и требования.
  • Можно ли одному человеку выполнять обе роли? да, но риски выше.
Вывод: это ключевые интервью‑вопросы по ролям аналитиков.

Типичные ошибки

Ошибка 1: BA уходит в технику

❌ описывает API вместо целей
✅ фокус на ценности и процессах

Ошибка 2: SA пишет «хотелки»

❌ нет системной конкретики
✅ описывать поведение и ограничения

Ошибка 3: Нет трассируемости

❌ не видно связи целей и требований
✅ связывать BR → SR

Ошибка 4: Нет общих критериев

❌ QA не может проверить
✅ acceptance criteria обязательны

Ошибка 5: Роли не согласованы

❌ дублирование и конфликт
✅ разделение ответственности

Best Practices

  • BA фиксирует цели и KPI.
  • SA переводит цели в системные требования.
  • Всегда поддерживайте трассируемость.
  • Артефакты должны дополнять друг друга.
  • Согласовывайте требования со стейкхолдерами и командой.

Заключение

Ключевые мысли

🎯 BA отвечает за «что и зачем».
🎯 SA отвечает за «как».
🎯 Вместе они превращают хаос ожиданий в ясные требования.
Теперь вы понимаете, какую роль выбирать и как выстраивать совместную работу.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Роли аналитиков: Бизнес-аналитик и Системный аналитик»

Пройти тест →