Резюме системного аналитика: чем занять опыт вместо «участвовал в проекте»

У системного аналитика есть беда, которой нет у разработчика: результат его работы редко можно показать. Код лежит в репозитории, а спецификация — во внутренней вики, под NDA, и наружу из неё не выносится ничего.

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

Чинится это одним ходом: писать не про участие, а про артефакты и решения.

Общая механика резюме разобрана в статье про резюме программиста; здесь про то, что отличает аналитика.

Чем резюме аналитика отличается от резюме разработчика

Разработчика читают по стеку, аналитика — по типу задач и по домену.

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

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

Опыт через артефакты

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

Было: «Сбор и анализ требований, написание технических заданий».

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

Второй пример. Было: «Участие в проекте миграции». Стало: «Разложил миграцию справочников из старой ERP: сопоставление полей, правила преобразования, что делать со строками, которые не проходят валидацию. Расхождения после переноса свели к нулю на сверке».

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

Нотации и инструменты: что писать

Список нотаций в резюме аналитика раздут почти всегда. BPMN, UML, IDEF, ARIS, EPC — через запятую, и половина трогалась один раз в учебном курсе.

Лучше показать, что и когда применяли. «BPMN для описания процесса согласования заявки, UML sequence для интеграционных сценариев» — это ответ, за которым видно работу. Просто список — это фильтр по ключевым словам, и на собеседовании он же превращается в неудобный вопрос.

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

Отдельно стоит упомянуть инструменты, в которых жила работа: трекер, вики, схемы, API-клиент. Это мелочь, но она показывает, что процесс вам знаком.

Про домен

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

Если ваш домен совпал с вакансией, выносите его наверх. Аналитик, который уже понимает, как устроен процесс выплаты или что такое сверка остатков, начинает приносить пользу с первой недели, и за это платят.

Госзаказ стоит упомянуть отдельно: там принята работа по ГОСТ 34 и ГОСТ 19, и опыт написания документов в этом формате уже сам по себе преимущество. Если он есть, пишите прямо.

Если коммерческого опыта нет

Работает тот же приём, что у разработчиков с пет-проектами, только артефакты другие.

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

Ещё вариант — разобрать открытый API какого-нибудь сервиса и написать по нему спецификацию интеграции. Это близко к реальной задаче и хорошо показывает, умеете ли вы работать со структурой.

Курсы упоминают одной строкой. Учебный кейс с приложенным документом убеждает сильнее, чем название школы.

Формулировки, которые отсеивают

Несколько типовых.

«Участвовал в проекте» без указания, что именно делали. Участвовать можно и на созвонах.

«Взаимодействие со стейкхолдерами» — фраза, за которой не стоит ничего. Напишите, с кем и о чём договаривались.

Полное совпадение текста с описанием вакансии. Такое замечают сразу.

Пять страниц с перечислением всех систем компании. Читающий ищет вас, а не карту их ландшафта.

Проверка перед отправкой

Пройдите по каждому пункту опыта и найдите в нём существительное, которое можно потрогать: схема, ТЗ, регламент, интеграция, миграция. Если такого слова нет, пункт пустой.

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

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