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

Системный аналитик (SA) переводит бизнес-требования в технические спецификации, которые разработчики могут реализовать. Если бизнес говорит «хотим, чтобы пользователь получал уведомление при изменении статуса заказа», системный аналитик превращает это в: какие события тригерят уведомление, через какой канал (push/email/sms), что именно написано в тексте, как обрабатывается ошибка доставки.

Без SA разработчик либо делает неправильно, либо тратит половину времени на уточнение требований.

Чем занимается системный аналитик

Системный аналитик — специалист, который переводит бизнес-задачи в техническое задание. Между тем, что хочет заказчик («хочу, чтобы клиенты могли оплачивать онлайн»), и тем, что должен написать разработчик (технические требования к API платёжной системы, схема БД, сценарии ошибок), лежит пропасть. SA эту пропасть закрывает. Он собирает требования, задаёт нужные вопросы, рисует схемы процессов, пишет спецификации — и делает это так, чтобы разработчик понял задачу с первого раза без бесконечных уточнений.

От BA (бизнес-аналитика) SA отличается техническим заземлением: он понимает архитектуру систем, умеет читать SQL и описывать API. От разработчика — тем, что его продукт не код, а документация и коммуникация. В крупных банках и телекоме SA — один из самых многочисленных технических специалистов: системы интегрированы между собой, требования сложны, и без SA команды просто не могут работать эффективно.

• Сбор требований: интервьюирует заказчиков и пользователей, выявляет реальные потребности (а не то, что они говорят что хотят)
• Написание технической документации: технические задания (ТЗ), user stories, use cases, SRS (Software Requirements Specification)
• Моделирование процессов и систем: BPMN-диаграммы бизнес-процессов, UML-диаграммы для описания системы
• Проектирование API: описывает контракты между системами – что отправляет, что принимает, какие ошибки возможны
• Согласование с командами: проводит ревью ТЗ с разработчиками и тестировщиками, разруливает противоречия
• Поддержка разработки: отвечает на вопросы разработчиков в процессе реализации, уточняет требования

Системный аналитик vs Бизнес-аналитик vs Data Scientist

В небольших компаниях бизнес-аналитик и системный аналитик часто одна должность под названием «аналитик» или «BA/SA». Подробнее о смежной роли: кто такой бизнес-аналитик.

Зарплаты системных аналитиков

Данные ориентировочные по hh.ru, октябрь 2026. Банки и крупные корпоративные IT-структуры платят ближе к верхней границе. Зарплаты Data Scientist – смежной роли с упором в данные – в статье как стать Data Analyst с нуля.

Откуда приходят системные аналитики

Нет одного «правильного» пути. Чаще всего системными аналитиками становятся:

• Разработчики – знают технологии, постепенно берут на себя больше проектирования и коммуникации
• Тестировщики (QA) – хорошо понимают требования и то, как система должна работать
• Бизнес-аналитики – расширяют компетенции в сторону технической стороны
• Выпускники технических специальностей – начинают напрямую в роли SA после курсов или стажировки

Что производит системный аналитик

Главный продукт SA – документация. Конкретные артефакты:

Центральный документ — Техническое задание (ТЗ) или SRS (Software Requirements Specification). Хорошее ТЗ отвечает на вопросы: что должна делать система, при каких условиях, какие ошибки должна обрабатывать, какова производительность. Плохое ТЗ — это список «хотелок» заказчика без схем, без сценариев ошибок, без критериев приёмки. Именно из-за плохого ТЗ большинство IT-проектов выходит за рамки бюджета или сроков: разработчики делают «как поняли», а не «как нужно».

• ТЗ (Техническое задание): полное описание системы или её компонента: функциональные требования, ограничения, нефункциональные требования (производительность, безопасность)
• User Story / Use Case: описание взаимодействия пользователя с системой с точки зрения пользователя
• API-спецификация (OpenAPI/Swagger): контракт между сервисами – что принимает, что отдаёт, коды ошибок
• ER-диаграмма: схема базы данных – таблицы, связи, типы данных
• BPMN-диаграмма: визуальная схема бизнес-процесса – кто что делает в какой последовательности
• Протокол согласования: запись договорённостей между командами после встречи

Кейс: как работает системный аналитик на реальной задаче

Чтобы объяснить, что делает SA, – разберём задачу из практики. Допустим, бизнес хочет добавить онлайн-оплату в мобильное приложение.

1. Встреча с бизнесом: SA узнаёт требования – какие платёжные системы нужны, нужны ли рассрочки, как обрабатывать отказы банка
2. Анализ текущей системы: SA смотрит, как устроена текущая архитектура, где хранятся данные пользователей, какие системы нужно будет интегрировать (ERP, CRM, банковский процессинг)
3. Написание user stories: «Как пользователь, я хочу оплатить заказ картой, чтобы не вводить данные каждый раз» – SA описывает сценарии со всеми альтернативными путями (что если карта не прошла, что если лимит превышен)
4. Разработка API-спецификации: SA пишет OpenAPI (Swagger) документ: какие endpoints нужны, какие данные принимает платёжный сервис, какие коды ответов возвращает
5. Согласование с разработкой: SA проводит grooming с командой – разработчики задают вопросы, SA уточняет неоднозначности, финализирует ТЗ
6. Приёмка: SA проверяет, что реализованное соответствует описанному – участвует в тестировании граничных кейсов

Весь этот цикл занимает 2–4 недели для одной фичи. SA – связующее звено: без него разработчики строят не то, что хотел бизнес.

Карьерные грейды: что умеет каждый уровень

Junior SA в банк или крупный телеком берут охотно – там много аналитической работы и есть кому учить. В небольших IT-компаниях джуну без опыта сложнее: там нужен готовый к самостоятельной работе Middle.

Где работают системные аналитики

Банки и финтех

Крупнейший работодатель SA в России – Сбер, Тинькофф (Т-Банк), ВТБ, Альфа. Финансовые системы сложны: много интеграций, высокие требования к безопасности и документации. Платят выше рынка, процессы выстроены, есть обучение.

Телеком и e-commerce

МТС, Билайн, Яндекс Маркет, Ozon – системы с тысячами компонентов, которые нужно постоянно интегрировать. Масштаб задач большой, темп высокий. Хороший опыт для тех, кто хочет работать со сложными распределёнными системами.

IT-продуктовые компании

SaaS-стартапы и зрелые продуктовые компании: 1С, HeadHunter, Битрикс. SA здесь совмещает аналитику с участием в продуктовых решениях. Часто – переходная зона между SA и PM.

Консалтинг и системные интеграторы

Компании вроде EPAM, Luxoft, IBS берут SA для работы на проектах у крупных клиентов. Разнообразие задач, возможность быстро набрать опыт в разных доменах. Минус – постоянная смена проектов.

Soft skills системного аналитика

Технические навыки SA хорошо описаны в вакансиях. Soft skills – реже, но именно они определяют, станет ли Junior Middle:

• Умение задавать правильные вопросы: бизнес не знает, чего хочет в деталях – SA должен это вытащить через правильно поставленные вопросы, а не принимать расплывчатые требования
• Умение говорить «нет» требованиям: когда бизнес хочет невозможного в срок – SA объясняет ограничения и предлагает альтернативу
• Структурированное мышление: держать в голове сложную систему из сотен компонентов и видеть, как изменение одного затронет другое
• Письменная коммуникация: 80% работы – документация; плохо написанное ТЗ порождает ошибки в коде
• Фасилитация встреч: SA собирает стейкхолдеров с разными интересами и приходит к согласованным решениям

Инструменты системного аналитика

SA работает с широким набором инструментов. Для каждой категории – свой стандарт индустрии:

Моделирование и диаграммы

Главный язык SA – визуальные схемы. Рисовать их можно в любом инструменте, но читать должна вся команда. Самые распространённые: draw.io (diagrams.net) – бесплатный, экспортируется в любой формат; Miro – коллаборативная доска, удобна для удалённых команд; Confluence + Lucidchart – стандарт в корпоративном секторе.

Типы схем, которые SA рисует регулярно: BPMN (бизнес-процессы), UML Use Case (сценарии использования), Sequence Diagram (последовательность вызовов между системами), ERD (структура базы данных), C4 Model (архитектура системы на разных уровнях абстракции).

Написание требований и спецификаций

Confluence – стандарт де-факто для корпоративных проектов. Встроенные шаблоны для ТЗ, интеграция с Jira. Notion – чаще в стартапах, гибче, удобнее для не-технических стейкхолдеров. Google Docs – для небольших команд и первых черновиков.

API и техническая документация

Swagger / OpenAPI – стандарт для описания REST API. SA пишет спецификацию, разработчики генерируют код и документацию из неё. Инструменты: Swagger Editor (онлайн, бесплатно), Postman (тестирование API + встроенная документация). Stoplight Studio – для крупных API с версионированием.

Работа с задачами и требованиями

Jira – в большинстве компаний. SA создаёт user stories, эпики, линкует требования к задачам разработки. YouTrack – российская альтернатива, используется в части отечественных компаний после 2022 года.

Как стать системным аналитиком: практический путь

Путь в профессию зависит от того, откуда вы стартуете:

Из бизнес-анализа или проектного менеджмента

Это самый органичный переход. Вы уже умеете собирать требования и работать со стейкхолдерами. Добавить нужно: понимание архитектуры систем, работу с API-спецификациями (OpenAPI), моделирование в UML и BPMN. Займёт 6–12 месяцев целенаправленного изучения + практика на реальных задачах.

Из QA-тестирования

Тестировщик уже умеет думать граничными кейсами, читать ТЗ и находить в нём дыры. Переход в SA – шаг от «нахожу проблемы в требованиях» к «пишу требования так, чтобы проблем не было». Основная доработка: научиться самостоятельно собирать требования и проектировать интеграции.

Без IT-опыта

Реально, но дольше. Лучший вход – банковский или страховой сектор: там много аналитической работы, процессы выстроены, есть обучение. Требования к технической глубине ниже, чем в IT-продуктовых компаниях. Стажировки в Сбере, ВТБ, Росбанке берут людей с экономическим или техническим образованием.

Что изучить в любом случае

• SQL: Selectel SQL Academy, курс на Stepik – базовые SELECT, JOIN, GROUP BY
• OpenAPI / Swagger: официальная документация + 1–2 практических проекта
• UML и BPMN: книга Гради Буча «UML. Объектно-ориентированный анализ» или онлайн-курсы на Udemy
• Гибкие методологии: BABOK Guide (стандарт бизнес-анализа), Scrum Guide – базовые сертификации типа IIBA ECBA

Почему компании готовы платить SA 200 000+ рублей

На первый взгляд странно: SA не пишет код, не руководит командой, не генерирует прямую выручку. Почему он получает столько же, сколько middle-разработчик или больше?

Ответ – в цене ошибки. Разработчик, который три месяца делал не то, что хотел бизнес, стоит компании 500 000–1 500 000 рублей прямых затрат плюс opportunity cost. SA – это страховка от такой ошибки. Он проводит неделю на сбор и согласование требований и экономит три месяца разработки неправильного решения.

Второй фактор – дефицит. Хороших системных аналитиков мало. Писать код можно научить за год. Научить человека одновременно понимать бизнес-процессы, проектировать архитектуру интеграций, писать понятную документацию и договариваться со стейкхолдерами – занимает 3–5 лет практики. Рынок это отражает в зарплатах.

Типичная неделя системного аналитика

Понедельник начинается с чтения почты и Jira: что изменилось за выходные, есть ли новые запросы от бизнеса. Потом – встреча по новой фиче: продукт объясняет, что хочет, SA задаёт вопросы. Много вопросов. «А что происходит, если пользователь нажал кнопку дважды?», «А какие данные нужны из системы X?», «А что если система X недоступна?». Бизнес редко думает о граничных кейсах – это работа SA.

Вторник-среда – основная работа с документацией. SA сидит и пишет. User stories, flow-диаграммы, API-спецификация. Это медитативная, требующая концентрации работа. Один хорошо описанный endpoint занимает час: нужно прописать все входные параметры, все коды ответов, все граничные ситуации, примеры запроса и ответа.

Четверг – grooming с командой разработки. SA представляет готовую спецификацию, разработчики задают вопросы и дают оценки. SA уточняет непонятное, иногда переписывает часть требований прямо на встрече. После grooming разработчики должны понимать задачу настолько хорошо, чтобы начать делать без дополнительных уточнений.

Пятница – административное: обновить статусы задач, написать summary для стейкхолдера, посмотреть, что из ТЗ уже реализовано и соответствует ли написанному. Иногда – приёмочное тестирование нового функционала.

Где ошибаются новички: три ловушки в работе SA

Ловушка первая: писать требования вместо того, чтобы понимать задачу. Типичный сценарий: бизнес приходит с запросом «хочу кнопку, которая экспортирует отчёт в Excel». Слабый аналитик садится и описывает кнопку. Сильный задаёт вопрос: «А зачем вам Excel? Что вы с ним делаете дальше?» – и выясняет, что Excel нужен, чтобы раз в неделю отправлять отчёт директору. После уточнения задача превращается из «кнопка экспорта» в «автоматическая отправка еженедельного отчёта на email». Это другая архитектура, другая сложность и, скорее всего, лучшее решение.

Ловушка вторая: слишком технические ТЗ для нетехнических стейкхолдеров. SA часто пишут документы, которые разработчики понимают, а бизнес-заказчики подписывают не читая. Потом оказывается, что бизнес имел в виду другое. Хорошее ТЗ читается на двух уровнях: бизнес читает описание процессов и user stories, разработчики смотрят на технические детали и API-контракты. Писать в расчёте только на одну аудиторию – профессиональная ошибка.

Ловушка третья: считать, что задача SA заканчивается на сдаче документа. Реальность: SA нужен на протяжении всей разработки. Разработчики будут задавать вопросы, находить противоречия в требованиях, предлагать альтернативные решения. Если SA исчез после сдачи ТЗ – проект уйдёт не туда, потому что команда начинает принимать решения самостоятельно. Хороший SA присутствует на grooming-сессиях, доступен для quick-вопросов и участвует в приёмочном тестировании.

Системный аналитик в разных типах компаний: чего ожидать

В банке или финтехе SA работает по ГОСТ-документации, BPMN 2.0 и строгим процессам согласования. Задачи стабильные, процессы описаны, зато изменения проходят через 5 согласований. Подходит тем, кто ценит структуру и хочет глубоко изучить финансовые бизнес-процессы. Зарплаты в Сбере, ВТБ, Тинькофф – одни из самых высоких на рынке SA.

В продуктовой IT-компании (Яндекс, Авито, Wildberries) темп выше, требования менее формализованы, зато больше влияния на продукт. Здесь SA называют то аналитиком, то BA, то иногда PM – граница размытая. Ценится скорость и умение работать с неопределённостью. Часто нет классического ТЗ – есть набор user stories и устные договорённости.

В системном интеграторе или аутсорсе SA работает на нескольких проектах одновременно, нарабатывает широкий опыт с разными стеками и отраслями. Минус – меньше влияния на продукт и частая смена контекста. Плюс – через 2–3 года вы будете понимать, как устроены системы в ритейле, логистике, производстве и госсекторе. Это ценный опыт для перехода в консалтинг или выхода на более сложные роли.

Системный аналитик vs смежные профессии: точная таблица

Разграничение ролей на практике зависит от компании. Вот как это выглядит в большинстве российских IT-команд:

Источник зарплат: Хабр Карьеры, данные по России за 2026 год. Медианы по вакансиям с указанной зарплатой.

Вопросы на собеседовании системного аналитика

По разборам интервью в IT-компаниях Москвы (банки, маркетплейсы, телеком):

Что такое диаграмма последовательности (sequence diagram) и когда вы её используете?

Sequence diagram — тип UML-диаграммы, показывающий взаимодействие компонентов системы во времени. SA использует её для описания сложных сценариев (авторизация, платёж, интеграция с внешней системой). Инструменты: PlantUML (текстовый), draw.io, StarUML. На собеседовании часто просят нарисовать диаграмму прямо на встрече.

Как бы вы описали требования для простого API?

Ожидаемый ответ включает: 1) Endpoint (метод + URL). 2) Request body/params (со схемой данных). 3) Response (структура + коды ответа: 200, 400, 404, 500). 4) Ограничения (auth, rate limit). 5) Пример запроса/ответа. Хорошие SA оформляют это в OpenAPI/Swagger — спросите, знакома ли вам эта нотация.

Как вы валидируете требования с заказчиком?

Ответ должен включать: прототипирование (показать, а не рассказать), Use Case / пользовательские истории, accept criteria, согласование примеров — «definition of done». Красный флаг на интервью: SA который просто записывает что говорит заказчик, а не задаёт уточняющие вопросы.

Что делать, если разработчик говорит «это невозможно», а заказчик требует?

Классическая ситуация. Правильный ответ: 1) Уточнить у разработчика — что именно невозможно и почему (технические ограничения). 2) Уточнить у заказчика — в чём суть потребности (часто просят решение, а не проблему). 3) Найти альтернативное решение, удовлетворяющее потребность в рамках технических возможностей. SA — переводчик между бизнесом и разработкой.

Объясните разницу между функциональными и нефункциональными требованиями.

Функциональные — что система делает: «пользователь может войти через Google OAuth». Нефункциональные — как она это делает: «авторизация выполняется за <2 секунды, система выдерживает 10 000 одновременных пользователей». К NFR относятся: производительность, доступность, безопасность, масштабируемость, UX-требования. Распространённая ошибка: SA фокусируется только на функциональных.

Плюсы и минусы работы системным аналитиком

По теме: Кто такой продакт-менеджер, Кто такой Python-разработчик, QA-тестировщик: профессия с нуля, Как найти первую работу в IT, Как составить резюме без опыта работы.

FAQ

Нужно ли системному аналитику уметь программировать?

Писать production-код – нет. Но понимать принципы разработки, читать SQL-запросы и разбираться в структуре API – обязательно. Аналитик, не понимающий техническую сторону, пишет документацию, которую разработчики не могут реализовать.

Системный аналитик или продакт-менеджер – что лучше?

Разные профессии с разным фокусом. SA – глубже в технической документации и проектировании систем. PM – в стратегии продукта, метриках и бизнесе. Переход из SA в продакт-менеджера – один из популярных карьерных путей: SA хорошо понимает продукт изнутри.

Есть ли сертификации для системных аналитиков?

Есть: CBAP (Certified Business Analysis Professional) от IIBA, CCBA, BABOK-сертификации. В России популярен также курс от «Системные аналитики» и программы в Яндекс Практикуме. Сертификация не обязательна для трудоустройства, но плюс при прочих равных.

Нужно ли системному аналитику писать код?

Нет – программировать не нужно. Но SA должен понимать как работает код: что такое переменная, функция, цикл, база данных, API. Этого достаточно, чтобы читать технические решения и разговаривать с разработчиками на одном языке. Sql-запросы на уровне SELECT – полезный навык.

Как войти в системный анализ без IT-опыта?

Стартуют обычно из трёх точек: QA-инженер (уже понимает, как тестируются требования), бизнес-аналитик (переходит в техническую сторону) или разработчик (уходит от кода в аналитику). Без IT-опыта – сложно, но реально через банковский или корпоративный сектор: там берут SA со смежным бизнес-образованием и обучают.