Системный аналитик vs бизнес-аналитик vs продакт: кто чем занимается

«Системный аналитик», «бизнес-аналитик», «продакт-менеджер». Три вакансии, три названия, и на каждом втором собеседовании новичок сидит с мыслью «а в чём вообще разница?». В одной компании аналитик пишет API-контракты и ковыряет схему БД, в другой — собирает требования у стейкхолдеров и рисует BPMN. А третья вакансия с заголовком «аналитик» на деле оказывается позицией продакта.

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

Системный аналитик: что и как

Системный аналитик — это роль, выросшая из технарей. Если кратко: он берёт функциональные требования от бизнес-аналитика (или заказчика напрямую) и превращает их в документ, который разработчик читает и пишет код. Никаких «сделайте интеграцию с CRM, как-нибудь там» — только конкретика.

Что он делает на практике:

• Проектирует API. Не «придумывает названия ручек», а определяет контракты: какие эндпоинты, какие поля в теле запроса, какие коды ответов, как выглядит ошибка. REST или gRPC — решает тоже он.
• Работает со схемами данных. Понимает, какие таблицы нужны в БД, как они связаны, что хранить в JSON-поле, а что выносить в отдельную сущность.
• Описывает интеграции. Между микросервисами, с внешними системами, с брокерами сообщений. Какие события передавать, в каком формате, кто продюсер, кто консьюмер.
• Пишет ТЗ. Не в духе «система должна быть быстрой», а с чёткими критериями приёмки: «метод POST /orders создаёт заказ в статусе pending, возвращает 201 и id».
• Ходит на груминг с разработчиками и объясняет, зачем нужен именно этот формат даты в ответе, а не другой.

Системный аналитик ближе к коду, чем к бизнесу. Он не решает, надо ли вообще делать фичу — это решили до него. Он решает, как именно её реализовать так, чтобы она не развалилась на проде.

Если вы ещё не знаете, с чего начинать в этой профессии, рекомендую пост Системный аналитик с нуля: с чего начать — там дорожная карта для входа.

Бизнес-аналитик: зачем и какие процессы

Бизнес-аналитик живёт на другом конце цепочки. Он работает с бизнесом, а не с кодом. Его задача — понять, какую проблему решаем, какой процесс меняется, и кто от этого выигрывает.

Ключевые занятия:

• Сбор требований. Интервью со стейкхолдерами, воркшопы, анализ документов. Вытаскивает из заказчика не «хочу кнопку», а «у нас отдел теряет 40 часов в неделю на ручную сверку отчётов — давайте автоматизируем».
• Моделирование бизнес-процессов. AS-IS (как сейчас) и TO-BE (как должно стать). Рисует диаграммы в BPMN — с дорожками, шлюзами и событиями.
• Формулирование бизнес-требований. Не «система должна выгружать CSV», а «финансовый отдел должен получать сводку по транзакциям за день до 9:00 утра».
• Выявление противоречий. Когда один стейкхолдер говорит «утверждение заявки за 1 шаг», а второй — «сначала руководитель, потом комплаенс», бизнес-аналитик ловит конфликт на этапе требований, а не на проде.
• User Stories и Use Cases. Переводит бизнес-требования в формат, понятный команде: «Я, как оператор колл-центра, хочу видеть историю обращений клиента, чтобы не переспрашивать его по каждому звонку».

Бизнес-аналитик не лезет в SQL, API и схемы БД. Его оружие — вопросы, диаграммы процессов и умение слушать так, чтобы услышанное не противоречило само себе. В небольших компаниях эту роль часто совмещает системный аналитик — и тогда получается «аналитик полного цикла», который и с бизнесом говорит, и спеки пишет.

Продакт-менеджер: стратегия, приоритеты и «а надо ли?»

Продакт-менеджер — это не аналитик, хотя его часто путают с бизнес-аналитиком. У них разный нерв работы. Продакт отвечает на вопрос «что и зачем мы делаем?», а аналитик — «как и в каком виде?».

За что отвечает продакт:

• Видение продукта. Куда идём, какую проблему рынка решаем, в чём наше преимущество. Это не красивая презентация для инвесторов, а руководство по принятию решений: если фича не приближает к видению — режем.
• Roadmap и приоритеты. Какие фичи пойдут в следующий релиз, а какие в бэклог на полгода. Приоритеты определяются бизнес-ценностью, срочностью и технической возможностью — а не «директору понравилась идея».
• Метрики и ROI. Сколько денег принесёт фича? Сколько сэкономит? Как измерим успех — через конверсию, NPS, время выполнения операции?
• Исследование рынка. Конкуренты, тренды, сегменты пользователей. Продакт знает, кто платит за продукт и почему они его покупают (или не покупают).
• Коммуникация с командой. Продакт формулирует, ЧТО надо сделать. Аналитик — КАК. Разработчик — пишет код. Тестировщик проверяет. Продакт акцептует результат.

Продакт не пишет ТЗ. Он пишет описание фичи: проблему, контекст, критерии успеха. Дальше — аналитик.

Как выглядит взаимодействие в реальном проекте

Вот живой кейс. E-commerce платформа. Заказчик жалуется, что клиенты бросают корзину. Продакт анализирует метрики и решает: «Внедряем систему брошенных корзин — через 1 час после ухода клиента отправляем email с напоминанием и промокодом на 5%». Это решение: ЧТО делаем и ЗАЧЕМ.

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

Системный аналитик получает это описание и проектирует: какие микросервисы участвуют, какой формат события «basket_abandoned» в Kafka, схема таблицы для хранения сгенерированных промокодов, API для проверки его валидности при оформлении заказа, контракт с SendGrid для отправки. Всё это ложится в ТЗ для разработчика — с конкретными endpoint, полями и кодами ошибок.

flowchart TB
  subgraph ROLE_PM["Продакт-менеджер"]
      PM1["Что делать и зачем?"]
      PM2["Roadmap, приоритеты"]
      PM3["Метрики, рынок, бюджет"]
  end

  subgraph ROLE_BA["Бизнес-аналитик"]
      BA1["Какие бизнес-процессы?"]
      BA2["Сбор требований бизнеса"]
      BA3["AS-IS и TO-BE"]
  end

  subgraph ROLE_SA["Системный аналитик"]
      SA1["Как реализовать?"]
      SA2["API, БД, интеграции"]
      SA3["ТЗ и спецификации"]
  end

  ROLE_PM -->|"фичи и приоритеты"| ROLE_BA
  ROLE_BA -->|"функциональные требования"| ROLE_SA
  ROLE_SA -->|"технические спецификации"| DEV["Команда разработки"]
  DEV -->|"реализованная фича"| ROLE_PM

  OVERLAP["Пересечение ролей:
User Stories, ТЗ, приёмка"]
  ROLE_BA -.-> OVERLAP
  ROLE_SA -.-> OVERLAP
  ROLE_PM -.-> OVERLAP

  style ROLE_PM fill:#7b68ee,stroke:#5a4db2,color:#fff
  style ROLE_BA fill:#50c878,stroke:#3a9a5c,color:#fff
  style ROLE_SA fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style PM1 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style PM2 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style PM3 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style BA1 fill:#50c878,stroke:#3a9a5c,color:#fff
  style BA2 fill:#50c878,stroke:#3a9a5c,color:#fff
  style BA3 fill:#50c878,stroke:#3a9a5c,color:#fff
  style SA1 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style SA2 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style SA3 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style DEV fill:#f0a500,stroke:#c88400,color:#fff
  style OVERLAP fill:#e0e0e0,stroke:#999,color:#333

На диаграмме три роли со своими зонами ответственности (цветные блоки) и пересечение — серая область, где все трое встречаются. Продакт определяет «что» и инициирует цепочку через бизнес-аналитика, который формализует бизнес-процессы. Системный аналитик берёт функциональные требования и превращает их в спецификации для разработки. Реализованная фича возвращается к продакту на приёмку — цикл замкнулся.

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

Таблица сравнения

Если вам лень читать, вот выжимка. Но лучше прочитайте — в таблице нет контекста.

Таблица сравнения ролей: системный аналитик, бизнес-аналитик и продакт-менеджер.

Техническая глубина движется вниз по цепочке «PM → BA → SA», а бизнес-глубина — в обратную сторону. Это не значит, что продакт глупее аналитика в технике. Это значит, что ему не нужно писать SQL-запросы, чтобы принимать решение о приоритете фич.

Как понять, кем ты хочешь быть

Если вы новичок, задайте себе три вопроса. Честно.

Вам нравится копаться в том, как устроена система внутри? Если схема БД вызывает интерес, вам хочется понять, как микросервисы общаются по Kafka, и JSON-схема для вас — красивая структура, а не набор скобок — системный аналитик.

Вам интереснее разбираться, почему бизнес работает так, а не иначе? Если вы получаете кайф от того, что нашли корень проблемы в процессе на стыке двух отделов, если умеете слушать заказчика и переводить «нам бы автоматизацию» в конкретные сценарии — бизнес-аналитик.

Вы видите картину целиком — рынок, продукт, деньги? Если вы думаете не «как сделать фичу», а «стоит ли её вообще делать», если метрики и A/B-тесты для вас родная стихия, и вы готовы отвечать за результат перед бизнесом — продакт-менеджер.

В реальности границы размыты. На старте карьеры я бы советовал начинать с системного анализа — это даст техническую базу, которая пригодится в любой из трёх ролей. Потом вы поймёте, куда вас тянет: глубже в бизнес (BA), шире в стратегию (PM), или глубже в архитектуру (SA/архитектор).

Чек-лист для начинающего

• Вы понимаете разницу между вопросом «что делать» и «как делать»
• Вы можете на примере одной фичи объяснить, что делает продакт, что — бизнес-аналитик, а что — системный аналитик
• Вы знаете, какие артефакты на выходе у каждой роли
• Вы ответили себе, какая из трёх зон ответственности вам ближе
• Вы прочитали дорожную карту для системного аналитика с нуля (если выбрали путь SA)
• Вы не боитесь, что в реальной компании роли будут перемешаны — теперь вы понимаете модель и адаптируетесь быстрее

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