Портфолио системного аналитика без опыта: что положить и где взять кейсы

«Покажите, что вы умеете» — фраза, от которой холодеет спина у каждого новичка. Вы прошли курс, прочитали Вигерса, знаете разницу между POST и PUT. Но показывать нечего — коммерческого опыта нет, а список «ответственных поручений» с предыдущей работы не убеждает даже вас самих. Хорошая новость: портфолио системного аналитика — это не портфолио дизайнера. Никто не ждёт красивых картинок. Ждут артефакты. И их можно сделать за пару недель, не устраиваясь на работу.

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

Резюме говорит: «я знаю». Портфолио говорит: «вот, посмотрите сами». Это разница между строчкой «Владею SQL, UML, REST API» и репозиторием на GitHub, где лежит спецификация API для интернет-магазина с ERD-схемой, SQL-запросами и Mermaid-диаграммами. Первое — слова. Второе — доказательство.

Работодателю на младшую позицию всё равно, где вы взяли кейс. Ему важно увидеть структуру мышления: вы понимаете, что такое приёмочный критерий, не путаете функциональные требования с нефункциональными и умеете спроектировать API так, чтобы разработчик не пошёл к вам с вопросами через пять минут после прочтения спеки.

Если вы ещё на этапе «с чего вообще начинать» — есть смысл сначала заглянуть в дорожную карту для начинающего аналитика. Там пошагово расписано, что учить в первый месяц. А здесь — как превратить эти знания в артефакт, который можно приложить к отклику на вакансию.

Структура сильного портфолио

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

graph TD
  Core["Сильное портфолио"] --> Spec["Спецификации"]
  Core --> Diagrams["Диаграммы"]
  Core --> Data["Работа с данными"]
  Core --> Code["Технические артефакты"]

  Spec --> US["User Story с критериями<br/>приёмки"]
  Spec --> UC["Use Case с альтернативными<br/>потоками"]
  Spec --> TZ["Фрагмент ТЗ<br/>на одну фичу"]

  Diagrams --> Seq["Sequence-диаграмма<br/>сценария"]
  Diagrams --> ERD["ERD-схема данных"]
  Diagrams --> BPMN["BPMN бизнес-процесса"]

  Data --> SQL["SQL-запросы:<br/>SELECT, JOIN, агрегаты"]
  Data --> Schema["Схема БД<br/>под фичу"]

  Code --> OpenAPI["OpenAPI-спека<br/>REST API"]
  Code --> GitLink["Ссылка на GitHub<br/>с README"]

  Spec -.-> Link1["Системный аналитик<br/>с нуля"]
  TZ -.-> Link2["User Story<br/>и Use Case"]

  style Core fill:#7b68ee,stroke:#5a4db2,color:#fff
  style Spec fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Diagrams fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Data fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Code fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style US fill:#50c878,stroke:#3a9a5c,color:#fff
  style UC fill:#50c878,stroke:#3a9a5c,color:#fff
  style TZ fill:#50c878,stroke:#3a9a5c,color:#fff
  style Seq fill:#f0a500,stroke:#c88400,color:#fff
  style ERD fill:#f0a500,stroke:#c88400,color:#fff
  style BPMN fill:#f0a500,stroke:#c88400,color:#fff
  style SQL fill:#50c878,stroke:#3a9a5c,color:#fff
  style Schema fill:#50c878,stroke:#3a9a5c,color:#fff
  style OpenAPI fill:#f0a500,stroke:#c88400,color:#fff
  style GitLink fill:#f0a500,stroke:#c88400,color:#fff
  style Link1 fill:#e0e0e0,stroke:#999,color:#333
  style Link2 fill:#e0e0e0,stroke:#999,color:#333

Диаграмма показывает каркас: четыре блока второго уровня и тринадцать конкретных артефактов в них. Фиолетовый центр — сильное портфолио. Четыре синих направления: спецификации, диаграммы, работа с данными, технические артефакты. Зелёные — текстовые артефакты (требования и запросы), жёлтые — визуальные и технические (диаграммы, OpenAPI, GitHub). Серым — уже существующие статьи блога, которые помогут разобраться в теме глубже.

Спецификации: показать, что вы умеете писать требования

Это то, ради чего аналитика нанимают. Ваши спецификации должны демонстрировать три вещи: вы отличаете ФТ от НФТ, вы умеете формулировать критерии приёмки и вы способны разложить сложный сценарий на шаги.

Минимальный набор для портфолио:

• User Story с критериями приёмки по Given–When–Then. Одна история — это мало, сделайте три-четыре на разные сценарии одной фичи. Покажите позитивный кейс, негативный и граничный. Если вы пишете про оформление заказа в интернет-магазине — нужны истории: успешная оплата, отказ банка, повторная попытка, частичная оплата баллами. Шаблон и разбор с примерами — в статье про User Story и Use Case.
• Use Case на один сложный сценарий. Не на всю систему — на одну фичу, где есть альтернативные потоки. Например, «возврат товара» в e-commerce или «оформление кредита» в банке.
• Фрагмент ТЗ. Не пишите документ на сорок страниц. Достаточно трёх-четырёх страниц по одной фиче. Опишите контекст, функциональные требования в таблице (ID, описание, приоритет), нефункциональные отдельным блоком, маппинг на API-ручки. Это ровно тот формат, с которым работают в небольших командах.

Лайфхак. Не пишите спецификации в вакууме — привяжите их к конкретному сервису. «Спецификация API для доставки еды» звучит в десять раз убедительнее, чем «Пример REST API для абстрактной системы». Работодатель мгновенно узнаёт домен и понимает: вы не просто переписали учебник, вы продумали реальные сценарии.

Диаграммы: показать, что вы умеете визуализировать

Аналитик без диаграмм — как разработчик без клавиатуры. Теоретически может, практически бесполезен. В портфолио положите три:

• Sequence-диаграмму — для самого хитрого сценария из вашего Use Case. Покажите запросы между фронтом, бэком, базой и внешними сервисами. Именно sequence лучше всего отвечает на вопрос «кто кому что шлёт и в каком порядке».
• ERD-схему — пять-семь таблиц, связи, ключи. Без этого разработчик не поймёт модель данных, а наниматель не поймёт, умеете ли вы её проектировать.
• BPMN бизнес-процесса — одна диаграмма на сквозной процесс. Например, «обработка заказа от оформления до доставки». Пул с клиентом и пул с системой, шлюзы на проверках.

Делайте диаграммы в Mermaid или PlantUML — текстовые форматы, которые живут в Git рядом со спецификациями. Это уже само по себе плюс: кандидат, который хранит требования в репозитории, а не в Confluence, выбивается из общей массы.

Работа с данными: показать, что вы дружите с SQL

Новички часто пропускают этот блок — и зря. Аналитика, который не умеет написать SELECT с JOIN, не допускают к данным, а значит, он не может проверить ни одну свою гипотезу.

Что положить:

• SQL-запросы к придуманной схеме. Создайте минимальную БД (например, интернет-магазин: users, orders, order_items, products, categories) и напишите десять-пятнадцать запросов разной сложности: от простого SELECT с фильтрацией до запроса с JOIN, GROUP BY, подзапросом и оконной функцией. Покажите, что вы понимаете разницу между LEFT JOIN и INNER JOIN, умеете агрегировать и знаете, что такое HAVING.
• Схема БД под вашу фичу. ERD с описанием таблиц и связей. Поясните, почему выбрали именно такую нормализацию, где денормализовали и зачем.

Совет: используйте SQLite. Файл с демо-базой можно положить прямо в репозиторий, и проверяющий сможет запустить ваши запросы локально одной командой. Это производит впечатление.

Технические артефакты: показать, что вы владеете инструментами

Два пункта, которые закрывают вопрос «а он вообще в индустрии ориентируется?»:

• OpenAPI-спека REST API. Возьмите фичу, для которой писали требования, и опишите ручки в OpenAPI 3.0. Не в Markdown-таблице, а именно в YAML/JSON — так, как это делается в реальных проектах. Покажите, что вы понимаете структуру запросов, коды ответов, query-параметры и тело запроса. Swagger Editor с preview — бесплатно и наглядно.
• GitHub-репозиторий с README. Сам репозиторий — уже часть портфолио. В README напишите, что это за проект, какую фичу вы описываете, какие артефакты лежат внутри и как их смотреть. Это навигатор для нанимателя, который открыл вашу ссылку.

Важный момент: не надо делать «идеальный репозиторий» с первой попытки. Я видел портфолио, которые брали на junior-позиции, — там было всего четыре .md-файла, три диаграммы и пара SQL-запросов. Но они были сделаны по делу, а не «для галочки».

Где взять кейсы, если опыта нет

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

Пет-проекты на реальных сервисах

Не придумывайте «систему автоматизации для абстрактного предприятия». Возьмите сервис, которым пользуетесь сами: Ozon, Delivery Club, Тинькофф, Яндекс.Музыка. Найдите в нём фичу, которую вы понимаете как пользователь, и опишите её как аналитик.

Пример: «повторный заказ» в Delivery Club. Вы знаете, как это работает снаружи: пара кликов, и вчерашний обед едет к вам снова. Теперь разберите, что должно происходить внутри: какие ручки дёргает фронт, как система получает состав прошлого заказа, что происходит с актуальными ценами (вдруг борщ подорожал за сутки?), как обрабатывается ситуация «ресторан закрыт». Пользовательский опыт вы уже знаете — осталось перевести его в аналитику.

Хороший пет-проект решает конкретную задачу в конкретном домене. Плохой — описывает «систему для автоматизации бизнес-процессов» без единой живой детали.

Учебные задания, доведённые до артефактов

Курсы дают задачи, но редко объясняют, как превратить домашки в портфолио. А разница — в одном вечере доработки.

Вместо «написал User Story в Google Doc» сделайте: User Story с критериями приёмки в .md-файле → диаграмма последовательности в Mermaid → ERD-схема → OpenAPI-спека в отдельном .yaml. Всё в одном репозитории. Теперь это не домашка, а проект. И в резюме вы пишете не «прошёл курс», а «вот репозиторий с артефактами».

Тот же принцип работает с тестовыми заданиями. Даже если вас не взяли, задание остаётся у вас. Доведите его до ума — и это уже строчка в портфолио, а не пять часов потерянного времени.

Волонтёрство и open-source

Неочевидный, но рабочий путь. Есть open-source проекты, в которых не хватает документации. Есть некоммерческие инициативы, которым нужна спецификация API для волонтёрского приложения. Есть знакомые разработчики, которые пилят пет-проект и с радостью отдадут вам написание требований.

Плюс такого подхода: вы получаете реальный контекст и живой фидбек. Минус: найти такой проект сложнее, чем придумать свой. Но если найдёте — строчка «системный аналитик open-source проекта X» в резюме стоит дорого.

Как оформить: GitHub как витрина

GitHub — стандарт де-факто для технических портфолио. Даже если в компании, куда вы идёте, используют GitLab или Bitbucket, ваш публичный репозиторий на GitHub смотрят все. Потому что это быстро и не требует регистрации.

Структура репозитория, которую я рекомендую:

1
/requirements/        ← User Story, Use Case, ТЗ (.md)
2
/diagrams/            ← диаграммы Mermaid (.mmd или встроены в .md)
3
/database/            ← SQL-запросы, ERD, дамп демо-БД (.sql, .db)
4
/api/                 ← OpenAPI-спека (.yaml)
5
README.md             ← навигатор по проекту

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

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

Что НЕ класть в портфолио

• Рефераты и конспекты книг. «Конспект Вигерса на 30 страницах» — это не портфолио аналитика. Это доказывает, что вы умеете читать, но не доказывает, что вы умеете анализировать.
• Документацию несуществующих систем. «Система управления складом для марсианской колонии». Интересно, но не релевантно. Работодателю нужен человек, который справится с e-commerce, банком или логистикой, а не с фантастикой.
• Секретные артефакты с предыдущей работы. Даже если очень хочется. Даже если «там же обезличено». Один кандидат на моей памяти принёс на собеседование распечатку внутренней спецификации своего бывшего работодателя. Дальше первого раунда он не прошёл — и не потому, что не умел анализировать.

Чек-лист для аналитика

Перед тем как прикладывать ссылку на репозиторий к отклику, пройдите по пунктам:

• В репозитории есть User Story с Given–When–Then (хотя бы три сценария: позитивный, негативный, граничный)
• Есть Use Case с альтернативными потоками и исключениями
• Есть Sequence-диаграмма самого сложного сценария
• Есть ERD-схема минимум на пять таблиц
• Есть SQL-запросы с JOIN, GROUP BY и хотя бы одной оконной функцией
• Есть OpenAPI-спека в YAML (не Markdown-таблица)
• README объясняет, что это за проект и как его смотреть
• Проект основан на реальном сервисе, а не на «абстрактной системе»
• Всё на русском (спеки и описания), код и технические термины — на английском

Сделайте два-три таких проекта для разных доменов. Один — e-commerce. Второй — банк или финтех. Третий — что-то внутреннее, типа админки или CRM. Три домена показывают, что вы не заучили один шаблон, а понимаете принципы.

Собрать такое за месяц — реально. По вечерам и выходным. Не надо делать идеально с первого захода. Сделайте черновик, покажите знакомому разработчику, получите обратную связь, исправьте. Итерация, а не perfection. Как говорил один мой тимлид, лучше работающая спецификация на трёх страницах, чем «почти готовая» на тридцати.