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

Что остаётся после работы аналитика
Результат его труда — не код и не презентация, а документы и модели, которыми пользуются другие: перечень требований с источником, формулировкой и признаком выполнения; схемы процессов и поведения системы; описание интеграций — кто с кем обменивается данными и что происходит при сбое; контракт программного интерфейса с методами, структурой запроса и ответа, кодами ошибок; постановки задач разработчикам; разделы технического задания.
Профессиональный стандарт описывает цель этой деятельности как обеспечение соответствия ИТ-решений требованиям на всём жизненном цикле системы (профстандарт 06.022 «Системный аналитик», приказ Минтруда России от 27 апреля 2023 года № 367н). Формулировка суховата, но предмет указан точно: аналитик отвечает за то, чтобы между потребностью и работающей системой не потерялся смысл.
Учебный пример: подключаем службу доставки
Ситуация вымышленная, она показывает ход работы. Интернет-магазин отправляет заказы транспортной компанией: менеджер вручную копирует адреса в кабинет перевозчика и раз в день сверяет статусы. Руководитель просит «автоматизировать доставку».
Аналитик начинает не со схемы, а с разговоров. У менеджера выясняется, что заказы бывают с предоплатой и с оплатой при получении; у бухгалтера — что для второго случая нужен акт о передаче денег; у поддержки — что клиенты спрашивают не «где посылка», а «когда придёт курьер». Затем аналитик читает документацию перевозчика и обнаруживает, что тот отдаёт статус только по запросу, а сам о событиях не сообщает. Значит, либо опрашивать перевозчика по расписанию, либо просить настроить уведомления; оба варианта он описывает и выносит на обсуждение.
После этого появляется описание: схема процесса от заказа до вручения, правило превращения статусов перевозчика в понятные покупателю, поведение системы при трёх неудачных запросах подряд, правило для заказов, созданных до внедрения. Выгода измерима: менеджер перестаёт вносить адреса руками, разработчик знает, что делать с таймаутом, а тестировщик — какие случаи проверять.
Требование, которое можно проверить
Главный навык в профессии — формулировать требования так, чтобы их нельзя было понять двумя способами, и здесь полезно заглянуть в действующий стандарт на техническое задание. ГОСТ 34.602-2020 действует с 1 января 2022 года взамен ГОСТ 34.602-89 и прямо перечисляет свойства, которыми требование обязано обладать: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность (текст стандарта, пункт 3.4). Единичность — в одном пункте одно требование, а не три склеенных союзом «и». Проверяемость — по формулировке строится сценарий приёмки: «система должна работать быстро» проверить нельзя, «ответ на запрос статуса заказа приходит не дольше трёх секунд» — можно. Однозначность отсекает «удобно», «при необходимости» и «корректно».
Там же есть правило, о котором обычно не пишут, а оно меняет практику. Стандарт задаёт десять разделов технического задания, и если по какому-то из них требований нет, раздел не выбрасывают: «соответствующий раздел сохраняется, и в нём приводится запись об отсутствии требований». Пустой раздел — зафиксированное решение: стороны обсудили защиту информации и договорились, что требований нет. Исчезнувший раздел — забытая тема, которая всплывёт на приёмке, когда менять что-либо уже дорого.
Зачем нужны BPMN и UML
Текстом удобно описывать правила, схемой — последовательность и взаимодействие, поэтому аналитик держит в руках минимум две нотации.
BPMN описывает бизнес-процесс: кто участвует, в каком порядке идут шаги, где развилка и что происходит при отказе. Это стандарт консорциума Object Management Group, причём версия BPMN 2.0.1 принята и как международный стандарт ISO/IEC 19510:2013, так что схема читается одинаково бизнесом и разработкой.
UML — язык для описания самой системы, тоже стандарт OMG (спецификация UML 2.5.1, декабрь 2017 года), причём в работе используют не весь язык. Диаграмма последовательности показывает, какими сообщениями обмениваются сервисы и в каком порядке, диаграмма классов фиксирует структуру данных, диаграмма состояний описывает жизненный цикл объекта — заказ создан, оплачен, собран, вручён, отменён — и, что важнее, какие переходы запрещены.
Нотации осваивают повторением и разбором чужих схем, поэтому смотрите при выборе обучения не на перечень тем, а на число работ с проверкой. Например, курс «Системный аналитик + ИИ» от Skillbox построен вокруг девяти проектов и заявляет работу в draw.io и Business Studio — в тех же средах, что и на работе.
Интеграции и описание API
Система редко живёт в одиночестве: она получает данные из складской программы, отдаёт документы в бухгалтерскую, спрашивает у банка статус платежа. Каждый стык описывает аналитик — кто инициирует обмен, какой протокол и формат (REST с телом в JSON, SOAP с конвертом XML, сообщение в очереди), какие поля обязательны, что делать, если ответа нет, если он пришёл с ошибкой, если один и тот же запрос ушёл дважды. Последнее встречается чаще, чем кажется, и именно из-за этого у клиента иногда списывают деньги повторно.
Контракт REST API принято описывать в формате OpenAPI — машиночитаемом описании HTTP-интерфейса, которое развивает OpenAPI Initiative при Linux Foundation; версия 3.2.1 опубликована 10 сентября 2026 года (спецификация OpenAPI). Файл содержит перечень путей, для каждого — операции, параметры, тело запроса и варианты ответа, а структуру данных задаёт схемами на основе JSON Schema. По одному документу и человек читает контракт, и инструменты строят документацию, заготовки кода и автотесты — отсюда рабочий набор из Swagger и Postman.
Без практики тут не разобраться, поэтому ищите в программе модуль, где вы сами составляете спецификацию и вызываете реальные методы. У курса «Системный аналитик» Яндекс Практикума среди инструментов указаны UML, BPMN, SQL, Postman, Swagger, JSON и XML — набор ближе к тому, что спрашивают на собеседовании, чем общий обзор видов интеграций.
Где проходит граница с соседними ролями
Вакансии называют аналитиков похоже, но предмет работы разный.
- Бизнес-аналитик работает с организацией: его цель профстандарт описывает как обеспечение изменений, приносящих пользу заинтересованным сторонам, через выявление потребностей (профстандарт 08.037). Он выясняет, какую проблему решать и стоит ли вообще что-то автоматизировать.
- Системный аналитик работает с системой: получает задачу, для которой решение уже выбрано, и описывает, как система должна себя вести и с чем обмениваться данными. Там, где бизнес-аналитик останавливается на «нужен автоматический обмен с перевозчиком», системный начинает.
- Аналитик данных работает с накопленными данными: считает метрики и проверяет гипотезы по фактам, а не проектирует поведение системы.
- Продакт-менеджер отвечает за продукт: что делать в первую очередь, для кого и какими показателями мерить успех. Он ставит задачу, а не описывает решение.
В небольших компаниях эти роли совмещает один человек, поэтому вакансию читайте не по заголовку, а по обязанностям.
Как выглядит обычная неделя
Работа делится пополам между разговорами и текстом. Аналитик ходит на встречи с заказчиком и архитектором, отвечает на вопросы разработчиков, разбирает с тестировщиками спорные случаи. Вторая половина — тишина и документ: сформулировать, перечитать, вычистить двусмысленности.
Есть и рутина, о которой редко предупреждают: требования меняются, и каждое изменение нужно провести по всем связанным документам — изменили правило расчёта скидки, проверьте схему процесса, метод API и сценарии приёмки. Ответственность своеобразная: аналитик почти ничего не делает руками, но его ошибка тиражируется в чужом коде и в тестах, которые проверяют не то.
Что может не подойти
Профессия тяжело даётся тем, кто не любит неудобные вопросы. Приходится переспрашивать собеседника, который считает, что всё уже объяснил: смириться с ответом «ну, там по логике понятно» нельзя, именно в этом месте потом и ломается. Дальше — объём письменной работы и медленная обратная связь: разработчик видит результат в тот же день, аналитик узнаёт, хорошо ли описал систему, через недели. И решение почти никогда не собирается из идеальной картинки: архитектор говорит, что так нельзя из-за нагрузки, безопасность запрещает передавать персональные данные, юрист требует акт.
Сколько платят
По данным исследования Хабр Карьеры за первое полугодие 2026 года, медианная зарплата системного аналитика в России — 222 тысячи рублей при медиане по всем ИТ-специалистам 191 тысяча; в банках и телекоме выше (обзор Хабр Карьеры). Это оценка фактических окладов: исследование строится на анкетах специалистов, в выпуске за первое полугодие разобрано 45 226 зарплат (методика и отчёт).
Предложения работодателей — другая величина, смешивать её с фактическими окладами не стоит. На hh.ru в середине сентября 2026 года по запросу «системный аналитик» в Москве открыто около 3,7 тысячи вакансий, в подборке для кандидатов без опыта — примерно 120, и типичные предложения для начинающих лежат в диапазоне 60–90 тысяч рублей (поиск вакансий на hh.ru). Читайте эту цифру с поправкой: поиск по ключевым словам подмешивает вакансии из других сфер, поэтому выдачу надёжнее просмотреть самому, с фильтрами по региону и опыту.
Разброс определяют отрасль, сложность предметной области и глубина технического понимания: SQL и умение разбираться в архитектуре поднимают планку заметнее, чем ещё одна нотация. Оценивая вилку, смотрите медиану, а не среднее, и проверяйте, указана сумма до вычета налога или на руки.
С чего начинать
Профильное образование помогает, но обязательным барьером не является. Вход по профстандарту скромнее, чем обещают рекламные тексты: младший системный аналитик отнесён к четвёртому уровню квалификации — достаточно среднего профессионального образования, опыт не требуется. Системный аналитик без приставки — пятый уровень, там ждут не менее года работы по техническому сопровождению проектирования, старший — шестой: высшее образование и не менее трёх лет в проектировании. Это не закон для каждого работодателя, но ориентир, по которому крупные компании строят грейды, и трезвая мера того, куда приводит курс «с нуля».
Базу проще набирать по порядку. Сначала SQL: не умея сам посмотреть, что лежит в базе, аналитик зависит от разработчика в простейших вопросах. Затем устройство веб-систем — клиент и сервер, HTTP-запрос, коды ответа, JSON и XML. Потом нотации: начните с BPMN на процессе, который знаете изнутри. Дальше API — возьмите открытый сервис с публичной документацией, отправьте запросы через Postman и опишите его контракт своими словами.
У самостоятельной тренировки есть слепая зона: свои двусмысленности человек не видит. Нужен кто-то, кто прочитает описание и укажет, где оно допускает второе толкование, — это главный довод в пользу обучения с проверкой работ. Сравнивать программы стоит не по количеству часов, а по числу работ, которые смотрит живой преподаватель: в курсе «Системный аналитик» от Skillfactory заявлены девять проектов и работа в Jira, Confluence и Miro — в тех средах, где требования живут в реальных командах.
Что показать вместо опыта
Портфолио системного аналитика — это документы. Соберите два-три комплекта по учебным задачам, и пусть каждый выглядит как рабочая папка: схема процесса в BPMN, диаграмма последовательности, перечень требований с признаками выполнения, описание метода API с полями и кодами ошибок, сценарии приёмки. Берите знакомую область: работали в логистике — опишите доработку учёта рейсов, в рознице — обмен между кассой и складом. И подготовьте объяснение решений: на собеседовании спросят не «что такое BPMN», а «почему опрос по расписанию».
Первые шаги в профессии
Приходят в профессию из тестирования, из поддержки и внедрения, из разработки, из отраслей: бухгалтер или логист ценен пониманием сути процессов. На старте разумнее искать позицию с приставкой «младший» или роль в команде, где есть опытный коллега, готовый вычитывать ваши документы: в одиночку некому заметить, что описание допускает двойное чтение. Окинуть взглядом рынок программ помогает рейтинг онлайн-школ по системной аналитике — он относится к направлению «Аналитика данных» в целом, поэтому в нём соседствуют программы разного уровня, и решение стоит принимать по содержанию конкретной: есть ли работа с базами данных, описание API, разбор нотаций и сквозной проект.
Проверить себя можно одним упражнением. Опишите письменно, как в вашей компании согласуют отпуск, — так, чтобы человек со стороны принял по вашему тексту решение в любой спорной ситуации: если руководитель в отпуске, если заявление подано за день, если дни кончились. Увлекла эта работа, а не измотала — беритесь за нотации и SQL.