Модуль 0.3. Системная аналитика: что это простыми словами, чем занимается системный аналитик
За 30–60 минут вы получите «карту местности»: простое, но технически корректное определение системной аналитики, чем именно вы занимаетесь ежедневно, где проходят границы с бизнес-аналитиком, архитектором, разработчиками и QA, и как роль меняется в разных доменах (финтех, банки, e-commerce, ERP/1C, DWH/BI). На выходе — артефакт «Карта роли SA vs смежные роли» для вашего проекта.
Простыми словами: что такое системная аналитика
Системная аналитика — это превращение бизнес-идеи в инженерно описанную систему, которую можно спроектировать, реализовать, протестировать и безопасно эксплуатировать.
Системный аналитик (SA) отвечает за спецификацию решения: процессы, правила, данные, интерфейсы, интеграции, нефункциональные требования (NFR) и трассируемость «цель → реализация → тест → мониторинг».
Коротко про ежедневные задачи SA
- Уточняете и нормализуете требования (без «быстро/удобно», только измеримые формулировки).
- Рисуете BPMN/DMN/UML/C4, пишете SRS (System Requirements Specification).
- Проектируете данные: ER-модель, глоссарий, справочники, правила качества данных (DQ).
- Проектируете интеграции: REST/GraphQL/gRPC, события/очереди, идемпотентность, схемы сообщений.
- Задаёте NFR: производительность, отказоустойчивость, безопасность, наблюдаемость (SLI/SLO).
- Обеспечиваете трассируемость (RTM): требование ↔ задача ↔ тест ↔ метрика/алерт.
- Сопровождаете приёмку (AC/BDD/UAT), участвуете в разборе инцидентов и эволюции решения.
Разница «бизнес-аналитик (BA) vs системный аналитик (SA)» — по сути
|
Вопрос |
BA |
SA |
|---|---|---|
|
Фокус |
Ценность и смысл: что и зачем |
Реализация и ограничения: как именно |
|
Артефакты |
Vision/BRD, бизнес-правила, KPI |
SRS, BPMN/DMN/UML/C4, ER, OpenAPI/AsyncAPI, NFR, RTM |
|
Единицы работы |
Эпики/фичи/бизнес-требования |
Системные требования, контракты, модели |
|
Решения |
Приоритеты, MVP, компромиссы ценности |
Техническая реализуемость, эффекты и риски |
|
Коммуникации |
Бизнес-стейкхолдеры, пользователи |
Архитектор, Dev/QA/DevOps, безопасность, данные |
На практике роли пересекаются. Хорошие BA говорят на языке бизнеса и понимают технику; хорошие SA объясняют технические решения по-человечески. Но ответственность за инженерную спецификацию — у SA.
Где работает SA: особенности доменов
Финтех/банки
- Контекст: платежи, переводы, кредитные продукты, AML/KYC, антифрод, регуляторика.
-
Что делает SA:
- BPMN/DMN для платежных сценариев, state-машины статусов (Authorized/Captured/Refunded).
- API: идемпотентность (Idempotency-Key), корреляция (Trace/Correlation-Id), пагинация, лимиты, таймауты, retry/circuit breaker.
- Безопасность: OAuth2/JWT/MTLS, маскирование PII, аудит-логи.
- NFR: latency p95, RTO/RPO, деградационные режимы.
- Риски: регуляторные ограничения; ошибки в идемпотентности → двойное списание.
e-commerce/логистика
- Контекст: каталог, корзина, заказ, оплата, доставка, возвраты, SLA.
- SA: Use Case «Оформление заказа», BPMN «Возврат», ER «Order/OrderItem/Payment/Shipment», веб-хуки «status changed», интеграции с PSP/3PL/CRM.
- Риски: гонки статусов, разрыв транзакций между платёжкой и складом, консистентность остатков.
ERP/1C
- Контекст: справочники, документы, бухучёт, обмен с внешними системами.
- SA: словарь и домены полей, согласование справочников, транспорт обмена (файлы/шина/API), правила трансформаций, валидаторы, сверки.
- Риски: «серые» бизнес-правила, дубли контуров (1C vs продукт), рассинхронизация справочников.
DWH/BI/данные
- Контекст: источники, CDC, витрины, метрики, отчёты, ML/AI.
- SA: контракт выгрузок/загрузок, ER/семантический слой, метрики (definition of metrics), SLA данных, lineage, контролы качества (DQ), API экспорта.
- Риски: неверные определения метрик, несогласованность витрин, «немолчащие» ошибки (данные есть, но неверны).
Роль на этапах SDLC/PDLC (как вы встроены в процессы)
- Discovery/Инициирование: фиксируете цели и ограничения; рисуете high-level C4 L1 + грубый BPMN.
- Анализ/Проектирование: делаете SRS, BPMN/DMN/UML sequence, ER; готовите OpenAPI/AsyncAPI, NFR.
- Реализация: отвечаете на вопросы, держите RTM, обновляете спецификации.
- Тестирование/Приёмка: формулируете AC и BDD, поддерживаете UAT.
- Релиз/Эксплуатация: задаёте SLI/SLO, требования к логам/трейсам/алертам; участвуете в RCA инцидентов.
- Эволюция: управляете change-request, версиями артефактов, ADR (решения и последствия).
Что именно производит SA (артефакты)
- SRS: системные требования + модели.
- BPMN/DMN/UML/C4: процессы, правила, последовательности, компоненты.
- ER + глоссарий: сущности, атрибуты, домены, справочники.
- API/Events: OpenAPI/AsyncAPI, схемы сообщений (JSON-Schema/Avro), коды ошибок, лимиты, безопасность.
- NFR: производительность/надёжность/безопасность/наблюдаемость.
- AC/BDD: критерии приемки, сценарии Given-When-Then.
- RTM: трассируемость от цели до теста и мониторинга.
- ADR: ключевые решения, альтернативы, последствия.
Как выглядит хороший день SA (мини-сценарий)
- Утро: grooming — вы уточняете сценарии, фиксируете вопросы, добавляете AC.
- Днём: дополняете SRS, рисуете BPMN «Возврат», обновляете OpenAPI и ER, публикуете ADR «Идемпотентность возврата».
- После обеда: с QA — синхронизация по BDD; с DevOps — SLI/алерты на события RefundFailed.
- Вечером: RTM обновлён, PR в репозиторий, страница Confluence получила «Approved».
Риски и анти-паттерны роли
- Секретарь требований. Только протоколируете. → Берите ответственность за инженерную спецификацию и NFR.
- Диаграммы ради диаграмм. Нет ценности для Dev/QA. → Делайте «ровно столько, сколько снижает риск».
- Нет идемпотентности/корреляции. Дубли операций/потерянные ответы. → Idempotency-Key, correlation-id, четкие контрактные правила.
- Размытые NFR. «Быстро и надёжно» без цифр. → p95 latency, error-rate, RTO/RPO, деградации.
- Без RTM. Непрозрачность: что реализовано и протестировано. → Ведите RTM и проверяйте на review.
- Версии/совместимость. Ломающие изменения без версий. → SemVer артефактов, ADR, матрица соответствия.
Метрики успеха SA
- Defects-of-requirements на релиз (низко — хорошо).
- Coverage RTM (требование имеет задачу/тест/метрику).
- SLO соответствуют факту (ошибок/латентность/доступность).
- Время ответа на вопрос Dev/QA (оперативность).
- Скорость апдейта артефактов (SRS/OpenAPI/диаграммы не отстают от кода).
Практические мини-кейсы
Кейс A (финтех): списание/возврат
- Требования: возврат в 24 часа, без двойных списаний.
- Решение SA: BPMN «Refund», API POST /refunds (идемпотентный), событие RefundCompleted, NFR p95<2 c, таймаут PSP 10 c, 3 retry с экспоненциальной паузой, audit-log.
- Проверка: BDD «Given оплата captured, When инициирован refund, Then статус refunded и событие отправлено».
- Риск: гонки при повторной подаче — закрыт Idempotency-Key.
Кейс B (e-commerce): «Статус заказа и доставка»
- Требования: push-обновления статуса, ETA доставки.
- Решение SA: события OrderPacked/HandedToCourier/Delivered, REST GET /orders/{id}, SSE/Webhook для пушей, SLA 1 мин до доставки статуса в клиент.
- Риск: рассинхронизация статусов → единая state-машина + «source of truth».
Кейс C (DWH/BI): «Выручка по дням»
- Требования: витрина Fct_Sales, корректная метрика «Gross/Net revenue».
- Решение SA: ER «Order/OrderItem/Refund/Payment», определение метрик, контракты экспорта, DQ-правила (уникальность, полнота), SLA 15 мин.
- Риск: «правда» метрик — закрыт согласованным глоссарием и тестами качества.
Вопрос–Ответ (частые)
Q1. SA должен уметь кодить?
A: Не обязательно писать прод-код, но читать API/схемы, писать простые SQL и править OpenAPI/AsyncAPI — обязательно. Скрипты/PoC — плюс.
Q2. Где граница между SA и архитектором?
A: Архитектор определяет принципы и целевую архитектуру; SA специфицирует решение в этих рамках и держит согласованность моделей/контрактов/NFR.
Q3. А SA рисует макеты интерфейсов?
A: Высокоуровневые user-flows и правила валидации — да; детальные UI-мокапы — зона UX, но SA обязан обеспечить непротиворечивость с процессами и правилами.
Q4. Кто владеет API-контрактами?
A: SA как владелец спецификации (совместно с Dev/QA/безопасностью). Версионирование/совместимость — ваша ответственность.
Q5. Что важнее — диаграммы или текст SRS?
A: Важна согласованность. Диаграммы помогают разработчикам и тестировщикам; текст описывает исключения и NFR. Храните вместе, версионируйте.
Q6. Как убедить бизнес в необходимости NFR?
A: Свяжите с деньгами: латентность → конверсия; доступность → SLA/штрафы; логирование → скорость RCA/меньше простоя.
Артефакт модуля — «Карта роли SA vs смежные роли»
Сделайте список ключевых активностей вашего проекта и заполните матрицу ответственности (кто ведёт, кто согласует, кто консультируется/уведомляется). Пример структуры:
# Карта роли: Системный аналитик vs смежные роли (Проект <X>) Версия: 1.0 | Владелец: <ФИО SA> | Последний обзор: <дата> ## Активности и ответственность - Обследование и бизнес-правила: BA (A/R), SA (R), PO (C) - Модели процессов (BPMN), правил (DMN): SA (A/R), BA (C), Архитектор (C), QA (C) - ER/Глоссарий/Справочники: SA (A/R), Data/BI (C), BA (C) - API/Events (OpenAPI/AsyncAPI/схемы): SA (A/R), Dev (R), Архитектор (C), Безопасность (C), QA (C) - NFR/Observability: SA (A/R), Архитектор (C), DevOps (C), QA (C) - AC/BDD/UAT: SA (A/R), QA (R), PO (C) - RTM и версии артефактов: SA (A/R), Dev/QA (C) - ADR (решения): SA (A/R), Архитектор (A), Dev/QA/Безопасность (C) ## Ссылки Confluence: /System Requirements Repo: /docs (SRS, ER, OpenAPI) Jira: EPIC-123, FEATURE-45
Критерии готовности артефакта: все «острые» зоны покрыты; на каждую активность — один владелец; есть ссылки на каноничные артефакты.
Домашнее задание (30–60 минут)
- Возьмите текущую инициативу и перечислите 15–20 активностей (анализ, модели, API, NFR, тесты, мониторинг).
- Заполните «Карту роли» для вашего проекта и согласуйте её на коротком созвоне с архитектором/лидами Dev/QA.
- Отметьте 3 риска роли SA именно в вашем контексте и опишите, как вы их закрываете (процедуры/артефакты/метрики).
