Чем занимается системный аналитик и как он может помочь разработчику

Опубликовано 29.10.2026 04:11:00 в категории Просто о NET

Введ.ение: задача в одну строку

Представьте, что в трекере появляется задача:

Уведомлять клиента о смене статуса заказа.

Больше ничего. Ни описания, ни критериев приёмки, ни ссылки на макет. Разработчик берёт задачу в работу, и тут начинается самое интересное:

1. Какие статусы считать значимыми? Все или только «Оплачен», «Отправлен», «Доставлен»?
2. Через какой канал уведомлять: email, SMS, push, Telegram? А если у клиента не указан ни один?
3. Что делать, если статус сменился три раза за минуту? Отправить три письма или одно?
4. Что делать, если почтовый сервис недоступен? Повторять попытки? Сколько раз? Сообщать ли кому-то об ошибке?
5. Может ли клиент отказаться от уведомлений? Где это хранится?

Код без ответов не пишется

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

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

Статья адресована прежде всего системным аналитикам — тем, кто хочет понять, что на самом деле нужно разработчику. Но и разработчикам она будет полезна: понимая, как работает аналитик, проще задавать ему правильные вопросы.

Через всю статью пройдёт один сквозной пример — та самая задача про уведомления о смене статуса заказа.

Кто такой системный аналитик

Системный аналитик (systems analyst) — это специалист, который переводит язык бизнеса на язык системы. Бизнес говорит: «Клиент должен знать, где его заказ». Система понимает другое: события, состояния, интеграции, форматы данных, ошибки и время ответа. Между этими двумя языками и работает аналитик.

Аналитик отвечает за «что» и «зачем», разработчик — за «как»

Проще всего понять роль, сравнив её с соседними:

• Продакт-менеджер (product manager) решает, что и зачем делать с точки зрения продукта и рынка. Он отвечает за ценность: «Уведомления снизят количество звонков в поддержку».
• Архитектор (software architect) решает, из каких частей будет состоять система и как они взаимодействуют на высоком уровне: «Уведомления — отдельный сервис, подписанный на события заказов».
• Тестировщик (QA) проверяет, что система делает то, что от неё ожидали.
• Системный аналитик описывает, что именно должна делать система, чтобы бизнес получил свою ценность: какие события, какие данные, какие правила, какие ошибки, какие ограничения.

Главное правило, которое стоит запомнить: аналитик отвечает за «что» и «зачем», разработчик — за «как». Аналитик не выбирает, какую библиотеку для отправки писем использовать и как назвать класс. Но он обязан сказать, что при недоступности почтового сервиса уведомление не должно теряться, а повторная отправка не должна приводить к дублям.

Когда эта граница соблюдается, обе стороны выигрывают: аналитик не лезет в реализацию, разработчик не придумывает бизнес-правила.

Чем системный аналитик отличается от бизнес-аналитика?

Это, пожалуй, самый частый вопрос на собеседованиях и самая частая путаница в вакансиях. Обе роли занимаются требованиями, обе пишут документы, обе общаются с заказчиком. Но смотрят они в разные стороны.

Фокус работы

→ Бизнес-аналитик (business analyst) работает с бизнесом: процессами, целями, проблемами и способами их решения. Его вопросы звучат так: «Почему клиенты звонят в поддержку?», «Сколько это стоит компании?», «Как изменится процесс, если клиент будет получать уведомления?». Система для бизнес-аналитика — один из возможных инструментов решения проблемы, а иногда проблему можно решить и без доработки системы вовсе.

→ Системный аналитик работает с системой: её данными, интеграциями, состояниями и ограничениями. Его вопросы: «Какое событие сигнализирует о смене статуса?», «Где хранится согласие клиента на рассылку?», «Что вернёт сервис уведомлений, если канал недоступен?».

Что каждый выдаёт на выходе

Бизнес-аналитик	Системный аналитик
Бизнес-требования (BRD)	Спецификация требований к системе
Модель бизнес-процесса «как есть» и «как будет»	Модель данных, диаграммы взаимодействия
Цели, метрики успеха	Контракты API и форматы сообщений
Пользовательские потребности	Критерии приёмки, граничные случаи

Для нашего примера бизнес-аналитик напишет: «Клиент получает уведомление о ключевых изменениях статуса заказа. Цель — снизить количество обращений в поддержку на тему "где мой заказ"». Системный аналитик превратит это в перечень статусов, каналов, правил отправки, поведения при ошибках и описание контракта между сервисом заказов и сервисом уведомлений.

Путаница в терминах

Стоит оговориться: в зарубежной практике название «business analyst» часто покрывает обе роли сразу, а отдельная должность «systems analyst» встречается реже. В российских компаниях роли, как правило, разделяют, и в вакансиях «системный аналитик» почти всегда означает человека, который умеет работать с API, базами данных и интеграциями. Поэтому, читая вакансию или описание роли в команде, смотрите не на название, а на перечень обязанностей.

Как бизнес-аналитик общается с разработчиком

Если коротко — чаще всего никак, от слова "вообще". В классической схеме цепочка выглядит так: бизнес → бизнес-аналитик → системный аналитик → разработчик и тестировщик. Бизнес-аналитик передаёт требования системному, а тот превращает их в постановку для команды. Разработчик может ни разу не увидеть бизнес-аналитика за весь проект — и это нормально.

Схема 1. Путь требований от бизнеса до команды разработки. Пунктиром показан прямой канал «бизнес-аналитик → разработчик», который появляется в небольших командах.

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

✗ Плохо: разработчик получает документ с бизнес-требованиями и сразу садится писать код, додумывая всё, что в документе не сказано.

✓ Хорошо: в команде понятно, кто владеет бизнес-смыслом (бизнес-аналитик), а кто — системной постановкой (системный аналитик или тот, кто выполняет его функции). Вопрос «зачем нам уведомление о статусе "Собирается"?» уходит бизнес-аналитику, а вопрос «что делать, если событие пришло дважды?» — системному.

Если в вашей команде нет системного аналитика, это не значит, что его работа не нужна. Это значит, что её делает кто-то другой — обычно разработчик, и обычно неявно 😒.

Чем аналитик занимается на практике

Работу системного аналитика удобно разложить на несколько направлений. В реальной жизни они переплетаются, но по отдельности их проще понять.

Выявление требований

Выявление требований (requirements elicitation) — это сбор информации о том, что должна делать система. Основные способы:

• интервью с заказчиком, пользователями, поддержкой;
• разбор существующих процессов и документов;
• анализ текущей системы: что она уже умеет, какие данные хранит, какие ограничения есть;
• наблюдение за реальной работой пользователей.

Важный момент: заказчик почти никогда не формулирует требования полностью. Он говорит о том, что видит сам, а то, что для него очевидно, пропускает. Задача аналитика — вытащить именно это «очевидное». Для нашего примера заказчик скажет «уведомлять о статусе», но не скажет, что ночью SMS отправлять нельзя, — потому что для него это само собой разумеется.

Функциональные и нефункциональные требования

Функциональные требования описывают, что система делает: «при переходе заказа в статус "Отправлен" клиенту отправляется уведомление с трек-номером».

Нефункциональные требования (non-functional requirements) описывают, насколько хорошо она это делает:

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

Нефункциональные требования чаще всего забывают — и именно они чаще всего всплывают на продакшене.

Моделирование

Текстом сложно описать процесс с ветвлениями или взаимодействие пяти сервисов. Поэтому аналитик использует модели:

• BPMN — для бизнес-процессов: кто что делает и в каком порядке;
• диаграммы последовательности (UML sequence) — для взаимодействия систем во времени: кто кому что отправляет и что получает в ответ;
• диаграммы состояний (state diagram) — для жизненного цикла сущности: из какого статуса в какой может перейти заказ;
• ER-модели — для структуры данных: какие сущности есть и как они связаны.

Для нашего примера диаграмма состояний заказа сразу ответит на вопрос «какие переходы существуют», а диаграмма последовательности покажет, как событие из сервиса заказов доходит до клиента.

Проектирование интеграций и контрактов

Если система состоит из нескольких сервисов, им нужно договориться о формате обмена. Аналитик описывает контракты: какие поля передаются, какие обязательны, какие значения допустимы, какие ошибки возможны. Для синхронных API это обычно спецификация OpenAPI, для асинхронного обмена сообщениями — AsyncAPI или описание формата событий.

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

Артефакты на выходе

Результат работы аналитика — набор документов, по которым команда может делать задачу:

• пользовательская история (user story) — короткое описание потребности: «Как клиент, я хочу получать уведомление об отправке заказа, чтобы знать, когда его ждать»;
• критерии приёмки (acceptance criteria) — проверяемые условия, при которых задача считается выполненной;
• спецификация — подробное описание правил, данных, интеграций и ограничений.

О том, как эти артефакты выглядят в хорошей и плохой постановке, — в разделе «Постановка задачи: плохо, хорошо, правильно».

Какими навыками должен обладать аналитик?

Хороший системный аналитик стоит на трёх опорах: технические навыки, коммуникация и мышление. Если какой-то из них не хватает, это сразу видно по задачам, которые он ставит разработчикам.

Технические навыки (hard skills)

Аналитику не нужно писать продакшен-код, но он должен понимать, как устроена система, которую описывает:

• SQL — уметь прочитать структуру таблиц и написать запрос, чтобы проверить гипотезу на реальных данных: «а сколько у нас клиентов без email?»;
• HTTP и REST — понимать методы, коды ответов, заголовки, разницу между ошибкой клиента и ошибкой сервера;
• асинхронное взаимодействие — понимать, что такое брокер сообщений (message broker), очередь (queue), почему сообщение может прийти дважды или не в том порядке;
• основы архитектуры — монолит и микросервисы, транзакции, согласованность данных (consistency), кэширование;
• чтение логов и трассировок — чтобы самостоятельно разобраться, что произошло в инциденте, а не только пересказывать вопрос разработчику.

Не нужно знать всё это на уровне разработчика. Нужно знать достаточно, чтобы задать правильный вопрос и не пропустить очевидный для разработчика случай или сценарий.

Коммуникативные навыки (soft skills)

• Интервьюирование. Умение задавать открытые вопросы и слушать ответ, а не ждать своей очереди говорить.
• Неудобные вопросы. «А что, если клиент удалил аккаунт, а заказ ещё в пути?» — такой вопрос может показаться придиркой, но именно он спасает от инцидента.
• Переговоры. Бизнес хочет «всё и сразу», разработка говорит «это три месяца». Аналитик помогает найти вариант, который устроит обе стороны.
• Структурное письмо. Постановку читают разработчик, тестировщик, архитектор и заказчик. Она должна быть понятна каждому без устных пояснений.

Мышление

• Системный взгляд. Видеть не только свою задачу, но и то, как она повлияет на соседние части системы. Добавили уведомления — а выдержит ли почтовый сервис рассылку в пиковый день?
• Поиск граничных случаев (edge cases). Пустые значения, повторы, гонка данных, недоступность, отмена на середине процесса.
• Критичность к «очевидному». Если что-то кажется очевидным, стоит это записать. Очевидное для одного — неизвестное для другого.

Слабый и сильный аналитик

✗ Слабый аналитик: записал, что сказал заказчик, оформил в шаблон и передал в разработку.

✓ Сильный аналитик: выяснил, что заказчику на самом деле нужно, нашёл граничные случаи, проверил на реальных данных, что система это выдержит, и только потом передал в разработку.

Разница между ними не в количестве страниц документации, а в количестве вопросов, которые разработчик задаст после прочтения.

Какими инструментами должен уметь пользоваться аналитик?

Инструменты меняются, а задачи остаются. Поэтому удобнее говорить не о конкретных программах, а о том, какие задачи нужно уметь решать, и приводить инструменты как примеры.

Документация

• Вики-системы (например, Confluence или его аналоги) — классический вариант: удобно для команды, привычно для бизнеса.
• Документация как код (docs as code) — спецификации в Markdown, хранятся в Git рядом с кодом, проходят ревью так же, как код.

Документация как код (Docs as Code) — это подход к созданию технической документации, при котором тексты пишутся, хранятся и публикуются с использованием тех же инструментов и процессов, что и исходный код программного обеспечения.

Подход «документация как код» особенно удобен разработчикам: спецификация меняется в том же репозитории, видна история изменений, а расхождение между документом и реализацией заметно при ревью.

Диаграммы

• draw.io — универсальный редактор, подходит для чего угодно.
• PlantUML и Mermaid — диаграммы описываются текстом. Их удобно хранить в Git и сравнивать версии.
• BPMN-редакторы (например, Camunda Modeler) — для бизнес-процессов по нотации.

API и интеграции

• Swagger Editor и аналоги — для описания и проверки контрактов OpenAPI.
• Postman или аналогичные HTTP-клиенты — чтобы самому отправить запрос и посмотреть, что вернёт сервис.
• AsyncAPI — для описания асинхронного обмена сообщениями.

Данные

• SQL-клиенты (например, DBeaver или DataGrip) — для просмотра структуры базы и проверки гипотез на данных.

Прототипы

• Figma — чтобы показать, как это будет выглядеть для пользователя, или прочитать макет дизайнера и сверить его с требованиями.

Трекинг задач

• Jira, YouTrack и аналоги — постановка задач, связь требований с задачами, отслеживание статусов.

С чего начать

Если вы только приходите в профессию, не пытайтесь освоить всё сразу. Минимальный набор, с которым уже можно работать:

1. вики или Markdown для текста;
2. один инструмент для диаграмм (draw.io или PlantUML);
3. SQL-клиент;
4. HTTP-клиент для проверки API.

Остальное придёт с задачами.

Постановка задачи: плохо, хорошо, правильно

Вернёмся к нашему примеру и посмотрим, как одна и та же задача может выглядеть на трёх уровнях проработки.

✗ Плохо: одна строка

Уведомлять клиента о смене статуса заказа.

Все вопросы из раздела «Введение: задача в одну строку» разработчику придётся решать самому. Результат непредсказуем, а приёмка превратится в спор.

✓ Хорошо: история и критерии приёмки

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

Критерии приёмки:
1. Дано: заказ в статусе «Собирается», у клиента указан email.
   Когда: заказ переходит в статус «Отправлен».
   Тогда: клиенту отправляется письмо с номером заказа и трек-номером.

2. Дано: заказ в статусе «Отправлен».
   Когда: заказ переходит в статус «Доставлен».
   Тогда: клиенту отправляется письмо о доставке.

3. Дано: клиент отказался от уведомлений.
   Когда: статус заказа меняется.
   Тогда: уведомление не отправляется.

Критерии записаны в формате «Дано / Когда / Тогда» (Given / When / Then). Это уже хорошо: понятно, какие статусы важны, что отправлять и когда не отправлять. По таким критериям тестировщик сразу может написать тест-кейсы, а разработчик — проверить себя.

Но вопросы всё ещё остаются: что будет, если почта недоступна? Что, если событие пришло дважды? Как быстро должно уйти письмо?

✓✓ Правильно: история, критерии и всё, что вокруг

К тому, что было на уровне «хорошо», добавляется:

Граничные случаи:
- Событие о смене статуса может прийти повторно. Повторное событие
  не должно приводить к повторному уведомлению (дедупликация
  по идентификатору заказа и статусу).
- Если статус сменился несколько раз за 5 минут, отправляется
  уведомление только о последнем.
- Если у клиента не указан email, уведомление не отправляется,
  в журнал пишется запись с причиной.
- Если заказ отменён после отправки уведомления «Отправлен»,
  клиент получает отдельное уведомление об отмене.

Ошибки и отказы:
- Почтовый сервис недоступен: до 5 повторных попыток
  с увеличивающимся интервалом, затем статус «Не доставлено»
  и сигнал в мониторинг.
- Почтовый сервис отклонил адрес: повторов нет,
  статус «Неверный адрес».

Нефункциональные требования:
- Уведомление уходит не позже 1 минуты после смены статуса
  в 95% случаев.
- Ночью (с 22:00 до 8:00 по времени клиента) уведомления
  только по email, SMS не отправляются.
- Каждая отправка фиксируется в журнале и доступна поддержке.

Контракт:
- Событие OrderStatusChanged: orderId, customerId, oldStatus,
  newStatus, changedAt, eventId.
- Описание в AsyncAPI — ссылка на спецификацию.

Обратите внимание: здесь нет ни строчки о том, как это реализовать. Ни слова о классах, библиотеках или таблицах. Но разработчику больше не нужно ничего придумывать — все решения, которые влияют на поведение системы, уже приняты.

Схема 2. Три уровня постановки задачи и то, что разработчику приходится додумывать на каждом из них.

Трассировка требований

Последний штрих правильной постановки — трассировка требований (traceability). Каждое требование должно быть связано с тем, что из него получается: с контрактом, с задачей в трекере, с тест-кейсом. Тогда на любой вопрос «а зачем это сделано?» есть ответ, а при изменении требования сразу понятно, что ещё придётся поменять.

Для нашего примера: требование «повторное событие не приводит к повторному уведомлению» связано с полем eventId в контракте и с конкретным тест-кейсом «Повторное событие OrderStatusChanged». Если завтра бизнес решит отказаться от дедупликации, сразу видно, какой тест удалить и какое поле перестаёт быть обязательным.

Дедупликация — это метод оптимизации хранения данных, который устраняет повторяющиеся копии информации, заменяя их ссылками на один уникальный экземпляр.

Как аналитик помогает разработчику и что разработчик от него ждёт

Теперь посмотрим на работу аналитика с той стороны, где пишут код.

Что получает разработчик

• Граничные случаи выявлены до разработки. Исправить ошибку в документе стоит минуты. Исправить её в коде — часы. Исправить на продакшене — дни, а иногда и репутацию.
• Единый язык (ubiquitous language). Если в постановке «заказ отправлен», а не «заказ отгружен», «передан в доставку» и «уехал» в разных местах, то и в коде будет одно понятие, а не четыре. Бизнес, аналитик, разработчик и тестировщик говорят одними словами.
• Точные оценки. Когда все вопросы закрыты, разработчик оценивает работу, а не неопределённость. Разница между «два дня» и «от двух дней до двух недель» — это и есть работа аналитика.
• Меньше «а давайте ещё» посреди спринта. Если требования собраны заранее и согласованы с заказчиком, новые пожелания идут в следующую задачу, а не в текущую.
• Один источник правды для разработки и тестирования. Тестировщик проверяет то же, что разработчик реализовал, а не своё понимание задачи.

Вопросы, которые разработчик всё равно задаст

Опытный разработчик, получив задачу, почти всегда задаёт один и тот же набор вопросов. Если закрыть их в постановке заранее, задача пройдёт без возвратов:

1. Кто инициатор? Пользователь, другая система, расписание?
2. Какие данные на входе и какие обязательны?
3. Что должно произойти в случае успеха? Что видит пользователь, что меняется в данных?
4. Что должно произойти в случае ошибки? Каждой ошибки отдельно.
5. Что будет, если операцию повторить? Важно для сетевых вызовов и сообщений.
6. Какой объём данных и какая нагрузка? Десять уведомлений в день или десять тысяч в минуту?
7. Кто и где увидит результат? Клиент, поддержка, отчёт, мониторинг?
8. Что уже есть в системе? Можно ли переиспользовать существующие механизмы?

Если аналитик пробежался по этому списку перед тем, как отдать задачу, разработчику остаётся только реализация.

Как выглядит хорошее взаимодействие

Даже при отличной постановке вопросы появятся — это нормально. Важно, как они задаются и как на них отвечают.

✗ Плохо:

Разработчик: «Непонятно, переделайте постановку».

Аналитик: «Всё же написано».

Ни одна сторона не знает, что именно непонятно, и разговор идёт по кругу.

✓ Хорошо:

Разработчик: «В критерии 2 не сказано, что делать, если заказ перешёл в "Доставлен", минуя "Отправлен". Отправлять оба уведомления или только последнее?»

Аналитик: «Только последнее. Добавил в граничные случаи, критерий 2 обновил».

Конкретный вопрос порождает конкретный ответ. Ответ фиксируется в постановке, а не остаётся в переписке. Следующий человек, который прочитает задачу, увидит уже обновлённую версию.

Схема 3. Цикл уточнения требований: постановка, вопросы, уточнение и согласованный контракт. Каждый ответ возвращается в документ.

Где разработчик должен проявить инициативу

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

Заключение

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

Если вы системный аналитик, перед тем как отдать задачу в разработку, задайте себе три вопроса:

1. Что произойдёт, если что-то пойдёт не так? Если для каждой ошибки и каждого граничного случая есть ответ — задача готова.
2. Сможет ли разработчик сделать задачу, ни разу ко мне не обратившись? Если нет — чего не хватает?
3. Сможет ли тестировщик проверить задачу только по постановке? Если да — критерии приёмки сформулированы правильно.

А если вы разработчик — не стесняйтесь задавать аналитику конкретные вопросы. Каждый такой вопрос делает следующую постановку лучше.