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

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

С чего начать, если я вообще из другой сферы?

С требований и процессов: научиться описывать, что должно происходить, и как это проверить. Потом данные (SQL) и интеграции (API). Эти три темы покрывают большую часть вопросов на первой работе.

Системный аналитик и бизнес-аналитик — это одно и то же?

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

Сколько времени занимает подготовка?

Ориентир — несколько месяцев по 10–15 часов в неделю до уверенного уровня для джуна; точный срок зависит от опыта и вакансии. Важнее контрольные точки: умеете ли вы описать процесс, требования и обмен данными.

Как проверить себя без платных курсов?

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

Системный аналитик с нуля: с чего начать

Чем системный аналитик отличается от других аналитиков

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

Отличие от бизнес-аналитика: тот отвечает на вопрос «что нужно и зачем», системный — «как это устроить и не сломать». Отличие от аналитика данных: данные для системного аналитика — предмет описания (структура, источники, правила) и инструмент проверки, а не основной результат.

Бизнес-аналитик: зачем и что нужно бизнесу.
Системный аналитик: как это устроить в системах и интеграциях.
Аналитик данных: что говорят цифры и как проверить гипотезу.
Продуктовый аналитик: как продукт движется к целям.

Базовый набор: требования, схемы, данные, интеграции

Требования: умение записать, что система должна делать, так, чтобы это можно было проверить. Простые правила — у требования есть число, условие и способ проверки; вместо «должно работать быстро» — «ответ не дольше 2 секунд при 100 запросах в минуту».

Схемы: BPMN для процессов, UML или контекстные схемы для устройств и взаимодействий, ER для данных. Не нужно рисовать всё на свете — нужно объяснить схему словами и назвать, что в ней важно. Данные: SQL на уровне select/join/group by, понимание, где дубли и пропуски. Интеграции: REST и JSON, коды ответов, ретраи, идемпотентность, очереди и топики в общем виде.

Требование: число, условие, способ проверки.
BPMN: процесс с ролями и развилками, без лишних символов.
SQL: читать данные, находить дубли и пропуски.
API: методы, коды ответов, повторы, что делать при сбое.
Документация: спецификация, которую нельзя понять двумя способами.

Порядок по неделям: ориентир, а не обещание

Срок зависит от вашего бэкграунда и часов в неделю, поэтому это ориентир. Задача каждой недели — не конспект, а артефакт: требование, схема, запрос или разбор кейса.

Недели 1–2: требования и постановка задач. Недели 3–4: процессы и схемы BPMN/UML. Недели 5–6: SQL и работа с данными. Недели 7–8: API, интеграции, базы и брокеры сообщений на уровне понимания. Недели 9–10: тестирование требований и документация. Дальше — кейсы и подготовка к собеседованию: разбор ситуаций вслух, вопросы с объяснением ответов.

1–2: требования, критерии проверки, постановка задач.
3–4: процессы, BPMN, схемы взаимодействия.
5–6: SQL, структура данных, источники и дубли.
7–8: API, интеграции, очереди, что при сбое.
9–10: проверка требований, спецификация, приёмка.
Дальше: кейсы, вопросы, тренировка ответов вслух.

Как учиться на практике, а не на конспектах

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

Затем разберите одну интеграцию: два сервиса, что передают, какие поля обязательны, что делать при повторе запроса, как понять, что данные приняты. Такие разборы и спрашивают на собеседовании — не учебные определения, а способность пройти по процессу.

Опишите знакомый процесс: роли, данные, шаги, ошибки.
Составьте спецификацию обмена между двумя сервисами.
Проверьте каждое требование вопросом «как это проверить».
Проговорите свой разбор вслух за 3–5 минут.

Контрольные точки: где вы сейчас

Проверяйте себя не по ощущению «всё прочитал», а на вопросах с объяснением ответа: после каждого ответа видно, где логика ошибки, а не только «верно/неверно». У нас вводные темы открыты без подписки — можно пройти тему «Роль аналитика и процессы», затем проверку уровня по всем курсам.

Если на ролевых вопросах идут ошибки — вернитесь к требованиям и процессам. Если на данных — к SQL. Если на интеграциях — к API и обработке ошибок. Так подготовка движется по слабому месту, а не по алфавиту.

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

Что спросят на собеседовании

Спрашивают не определения, а порядок разбора: как вы уточните условие, какие данные нужны, что произойдёт при сбое, как проверите результат. Кейсы — это те же вопросы, но в виде ситуации: «клиент не получил заказ», «данные пришли дважды», «требования противоречат друг другу».

Хорошая подготовка — разобрать 8–10 таких ситуаций вслух и держать в голове структуру: уточнить, разложить на шаги, назвать риски, предложить проверку. Подробный разбор вопросов и кейсов — в отдельных гайдах.

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

Что сделать: короткий чеклист

Выпишите 5–8 вакансий системного аналитика и общие требования.
Опишите один знакомый процесс по шагам, с ролями и ошибками.
Составьте схему обмена данными между двумя сервисами.
Сформулируйте 5 требований в формате «число, условие, проверка».
Пройдите демо-тему по роли аналитика и диагностику уровня.
Разберите один кейс вслух за 3–5 минут.

Где тренировать

Темы из гайда разобраны в тестах портала — каждый вопрос с объяснением ответа:

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

Системный аналитик с нуля: что учить и в каком порядке