Hard и soft skills системного аналитика: что реально спрашивают

Расскажу историю. Приходит ко мне джун после месяца самостоятельного обучения. Глаза горят, в резюме — UML, BPMN, SQL, Kafka, DDD. Спрашиваю: «Ок, пользователь нажал кнопку «Оплатить», деньги списались, а склад ответил «нет товара». Что делаем?» Пауза. Потом: «Ну… надо посмотреть, что в API возвращается?»

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

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

Hard skills: технический фундамент

Hard skills — то, что можно измерить. Знаешь SQL или нет. Понимаешь разницу между PUT и PATCH или нет. Нарисовал sequence-диаграмму — и по ней видно, насколько глубоко ты продумал взаимодействие.

Глубина владения жёстко привязана к грейду. То, что простительно джуну, на собеседовании middle — красный флаг. И наоборот: от senior’а ждут не «напишите запрос», а «как вы спроектируете интеграцию, которая не ляжет под нагрузкой».

flowchart LR
  subgraph Hard["Hard Skills (технические)"]
      direction TB
      H1["SQL: SELECT, JOIN, агрегаты"]
      H2["REST API: методы, коды ответов"]
      H3["UML и BPMN: диаграммы"]
      H4["Интеграции: REST, Kafka, gRPC"]
      H5["Проектирование БД: ER-модели"]
      H6["Архитектура: монолит, микро, DDD"]
  end
  subgraph Soft["Soft Skills (коммуникация)"]
      direction TB
      S1["Интервью стейкхолдеров"]
      S2["Управление требованиями"]
      S3["Фасилитация встреч"]
      S4["Презентация и защита решений"]
      S5["Переговоры: приоритеты и компромиссы"]
      S6["Менторство и наставничество"]
  end
  Hard --> SA["Системный
аналитик"]
  Soft --> SA
  
  style SA fill:#7b68ee,stroke:#5a4db2,color:#fff
  style Hard fill:#e0e0e0,stroke:#999,color:#333
  style Soft fill:#e0e0e0,stroke:#999,color:#333
  style H1 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style H2 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style H3 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style H4 fill:#f0a500,stroke:#c88400,color:#fff
  style H5 fill:#f0a500,stroke:#c88400,color:#fff
  style H6 fill:#50c878,stroke:#3a9a5c,color:#fff
  style S1 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style S2 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style S3 fill:#f0a500,stroke:#c88400,color:#fff
  style S4 fill:#f0a500,stroke:#c88400,color:#fff
  style S5 fill:#50c878,stroke:#3a9a5c,color:#fff
  style S6 fill:#7b68ee,stroke:#5a4db2,color:#fff

Диаграмма — карта компетенций системного аналитика. Синим — базовые навыки, с которых стартуют все. Жёлтым — навыки middle-уровня, появляются с опытом. Зелёным и фиолетовым — то, что приходит на уровне senior. Разберу каждый блок.

SQL и работа с данными

Без SQL вы не аналитик. Точка. Даже если работаете в компании, где выборки пишут разработчики. На собеседовании спросят — и не «чем LEFT JOIN отличается от INNER JOIN» (хотя и это спросят), а задачу: «Есть таблицы orders, order_items, products. Выведи топ-5 товаров по выручке за последний квартал».

Junior. SELECT, JOIN (INNER, LEFT), WHERE, GROUP BY, HAVING, ORDER BY. Простые агрегаты: COUNT, SUM, AVG. Подзапросы — понимать, что это, и уметь прочитать чужой. Оконные функции — знать о существовании ROW_NUMBER() и не падать в обморок при виде OVER (PARTITION BY ...).

Middle. Оконные функции — свободно: ROW_NUMBER(), RANK(), LAG(), LEAD(). CTE (WITH). Понимание плана запроса (EXPLAIN), индексов — когда запрос тормозит, вы видите, почему. Оптимизация JOIN и фильтрации.

Senior. Проектирование структуры данных: нормализация, денормализация под отчёты. Понимание, как выбор архитектуры БД влияет на интеграции и производительность системы. Вы не просто пишете запрос — видите картину целиком.

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

Аналитик без понимания API обречён писать требования уровня «система А передаёт данные системе Б» — и разработчик будет переспрашивать каждую строчку. Начните с REST API: основные принципы — это база.

Junior. Методы (GET, POST, PUT, PATCH, DELETE), коды ответов (200, 201, 400, 404, 500), структура запроса/ответа. Форматы: JSON, XML (хотя бы узнавать в лицо). Умение прочитать OpenAPI/Swagger-спецификацию.

Middle. Проектирование контрактов: какой метод для какой операции, какие поля в теле ответа. Пагинация, фильтрация. Идемпотентность — что это и зачем. Статус-коды глубже стандартных: 201, 202, 204, 409, 422. Асинхронные взаимодействия: очереди, колбэки.

Senior. Выбор стиля интеграции: REST vs gRPC vs GraphQL vs асинхронные очереди. Проектирование API с учётом обратной совместимости и версионирования. Понимание, как выбор протокола влияет на архитектуру системы.

Моделирование: UML, BPMN, ERD

Диаграмма в Confluence — это не «украшение страницы». Это инструмент, который либо снимает вопросы, либо их создаёт.

Junior. Use Case-диаграмма: акторы и их цели. Sequence-диаграмма для простого сценария (один запрос — один ответ). Activity-диаграмма для линейного процесса.

Middle. Sequence-диаграмма для сложного сценария с ветвлениями, альтернативными потоками, таймаутами. BPMN: пулы, дорожки, шлюзы (XOR, AND, event-based). ERD: сущности, связи, кардинальность.

Senior. Нотацию выбираете под задачу, а не наоборот. UML для взаимодействия компонентов. BPMN для сквозных бизнес-процессов. ERD для модели данных. C4 для архитектуры системы в целом. И можете объяснить команде, почему здесь нужен BPMN, а там хватит трёх стикеров на доске.

Архитектура

Для junior’а слово «архитектура» звучит страшно. Но даже на старте полезно различать базовые понятия — хотя бы чтобы понимать, о чём спорят разработчики.

Junior. Разница «монолит — микросервисы» на уровне аналогий. Что такое «сервис», «база данных», «брокер сообщений» — общее представление.

Middle. Монолит, модульный монолит, микросервисы — плюсы и минусы каждого. Зачем нужен API Gateway и как он вписывается в картину. Брокеры сообщений на уровне: топик, партиция, consumer group.

Senior. Проектирование архитектурных решений. DDD: bounded context, агрегаты, доменные события. Паттерны: CQRS, Event Sourcing, Saga, Outbox. И что важнее всего — умение объяснить, почему здесь микросервисы не нужны, даже если «все модные ребята так делают».

Проектирование БД

Junior. Что такое таблица, первичный ключ, внешний ключ. Связи «один-к-одному», «один-ко-многим», «многие-ко-многим» на уровне концептуального понимания.

Middle. Нормализация до 3NF. Понимание, когда денормализовать (отчёты, витрины). Индексы: какие типы бывают, как влияют на выборки и вставки.

Senior. Выбор между реляционной БД и NoSQL под задачу. Проектирование схемы, которая не превратится в тыкву через полгода. ACID vs BASE, eventual consistency — понимание компромиссов.

Soft skills: о чём молчат в вакансиях

Формально пишут «коммуникабельность», «умение работать в команде». На деле soft skills — это конкретные поведенческие паттерны, которые видны за первые 10 минут собеседования.

Интервью стейкхолдеров

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

Что спрашивают на собеседовании: «Расскажите, как проводили интервью с заказчиком. Самый сложный стейкхолдер и как вы с ним работали?»

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

Управление требованиями

Вы собрали 200 требований от семи стейкхолдеров. Часть противоречат друг другу. Часть — «хотелки» без бизнес-ценности.

Junior. Фиксирует в Confluence, делает табличку. Middle. Приоритизирует: что в MVP, что потом, что — «нет, обсуждаем ещё раз». Связывает требования с бизнес-целями. Каждое требование отвечает на вопрос «какую проблему пользователя это решает?». Senior. Видит систему требований целиком: какие тянут архитектурные изменения, где конфликты, как изменение одного атрибута влияет на пять других.

Фасилитация встреч

Собрать 8 разработчиков, продакта, тимлида и стейкхолдера в одной комнате или зуме и провести встречу, откуда все вышли с решениями — навык, которому не учат на курсах.

Типичный кейс с собеседования: «Команда спорит о подходе к интеграции. Разработчики хотят REST, архитектор — gRPC, продакту всё равно, лишь бы вчера. Ваши действия?»

Плохой ответ: «Я задокументирую оба варианта и отдам на решение тимлиду». Хороший: «Сначала пойму критерии выбора — latency, объём данных, кто потребители, есть ли стриминг. Потом свожу всех на встречу с конкретными аргументами по каждому критерию. Решение фиксирую в ADR».

Презентация и защита решений

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

Junior. Показывает диаграмму и ждёт вопросов. Middle. Рассказывает, какие альтернативы рассмотрел и почему выбрал этот вариант. Senior. Предвидит вопросы и возражения до презентации и встраивает ответы прямо в рассказ. Структура: проблема → варианты → выбор → риски → план миграции. Без слайда «Спасибо за внимание» в конце (серьёзно, уберите его).

Переговоры: приоритеты и компромиссы

Заказчик хочет фичу X, разработчики говорят «три месяца», продакт настаивает «через две недели». Вы посредине.

На собеседовании проверяют гибкость мышления. Можете ли предложить альтернативу, которая решает 80% проблемы за 20% времени? Понимаете разницу между «нужно сейчас» и «нужно правильно»?

Менторство и наставничество

Senior-аналитик — это не только «делает сложные задачи». Это «делает команду сильнее». Код-ревью требований, онбординг новичков, развитие внутренних стандартов.

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

Что реально спрашивают: статистика по грейдам

По моему опыту проведения собеседований и разговорам с коллегами-нанимателями, распределение фокуса выглядит так:

Юниору прощают пробелы в коммуникации — нанимают за способность быстро учиться и делать руками. Senior’у простят незнание конкретной технологии (выучит за неделю), но не простят неумения договариваться.

Откуда брать скилы, если нет коммерческого опыта

Картинка ясна. Что делать новичку без живых стейкхолдеров и рабочих проектов?

База. Пройдите путь системного аналитика с нуля — закроете фундамент. SQL — любой тренажёр (SQL Academy, SQL-Ex, LeetCode, раздел Database). REST API — читайте документацию публичных API (GitHub, Stripe) и дёргайте через Postman. Диаграммы — качайте draw.io или PlantUML и перерисовывайте бизнес-процессы сервисов, которыми пользуетесь.

Практика. Берите опенсорс-проекты и пишите к ним спецификации. Свой пет-проект: придумайте сервис, опишите требования, нарисуйте диаграммы, спроектируйте API. Без строчки кода — уже готовый кейс для портфолио.

Soft skills. Тренировать переговоры на котиках не выйдет. Но можно: ходить на митапы и задавать вопросы, участвовать в опенсорс-дискуссиях, вести технический блог (письменное формулирование мыслей — та же тренировка). Записывайте себя на видео при объяснении технической темы — смотреть больно, зато видны все «э-э-э» и слова-паразиты. Через пять попыток прогресс будет заметен невооружённым глазом.

Чек-лист для самопроверки

Это не экзамен. Ориентир: если честно отвечаете «да» на большинство пунктов своего грейда — порядок. Если половина вызывает вопрос «а что это?» — знаете, куда копать.

Junior

• Пишу SELECT с JOIN и GROUP BY без гугления синтаксиса
• Отличу PUT от PATCH без подсказки
• Могу объяснить, что такое REST и почему это не просто «JSON через HTTP»
• Нарисую Use Case-диаграмму и sequence для простого сценария
• Понимаю разницу между функциональными и нефункциональными требованиями
• Напишу User Story по шаблону и не перепутаю «я как…» с «система должна…»

Middle

• Оконные функции в SQL — без гугления
• Спроектирую REST API с пагинацией и фильтрацией
• BPMN-процесс с тремя участниками и ветвлениями — рабочая задача
• Проведу интервью со стейкхолдером и вытащу скрытые требования
• Приоритизирую бэклог и объясню заказчику, почему его хотелка не в MVP
• Понимаю разницу между синхронным и асинхронным взаимодействием сервисов

Senior

• Выбираю архитектурный стиль под задачу и защищаю выбор перед архитектором
• Проектирую интеграции, которые не развалятся при росте нагрузки в 10 раз
• Фасилитирую встречи со столкновением интересов трёх разных отделов
• Менторю middle-аналитиков и вижу типичные ошибки за первый обзор спецификации
• Понимаю, когда микросервисы — зло, а модульный монолит — спасение
• Могу объяснить CTO, почему DDD в нашем случае окупится через год, а не через месяц

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