Инструменты и карьера аналитика: грейды, специализации, что учить дальше

Двенадцать статей трека были про работу: как достать знание из людей, как отличить бизнес-требование от «хотелки», как описать поведение однозначно и как довести это до приёмки, которая заканчивается решением, а не спором. Остались два вопроса, на которые обычно отвечают списками: чем работать и куда расти. Списки бесполезны: «Jira, Confluence, BPMN, SQL, UML» одинаково подходит человеку, который за полгода не выявил ни одного неявного требования, и человеку, который сэкономил компании квартал разработки. Поэтому здесь два критерия выбора:

• Инструмент выбирают по сроку жизни знания, которое в нём будет лежать, и по тому, кто и когда будет это знание искать. Остальное — вкусовщина и корпоративный стандарт.
• Грейд определяется классом неопределённости, который человек снимает сам, а не стажем, объёмом спецификаций и не знанием нотаций.

Сквозной пример трека продолжается: автовозврат в интернет-магазине — карточные оплаты, суммы до 3000 руб., две причины, окно отмены 60 минут, SLA 30 минут. На нём видно и инструменты, и разницу между грейдами: один и тот же вход даёт три очень разных ответа.

1. Инструмент — это место, где живёт решение

1.1. Единственный работающий критерий

Спор «Confluence или Notion», «Miro или draw.io» бесконечен, потому что ведётся не о том. Полезный вопрос один: через сколько времени и кто будет искать это знание, и что случится, если он его не найдёт? Отсюда три полосы. Знание, живущее часы, не заслуживает документа: договорились на доске, сфотографировали, пошли дальше. Знание, живущее до релиза, лежит в трекере рядом с задачей. Знание, от которого зависит чужой код через год, обязано лежать там, где есть версия, ревью и владелец, — то есть, как правило, в репозитории.

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

1.2. Маршрут артефакта

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

1.3. Пять слотов инструментария

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

Шестой, неформальный слот — прототипы: Figma, Balsamiq, Excalidraw, иногда просто HTML-страница (подробно в прототипировании). Он относится к средней полосе: макет живёт до релиза и спецификацией не является. Макет, объявленный источником истины, — классический способ потерять все состояния, которых на нём не нарисовано.

2. Docs-as-code: когда требования переезжают в репозиторий

Docs-as-code — это когда описание системы лежит в одном репозитории с кодом: текстовые файлы, pull request, ревью, CI. Для аналитика это не мода, а решение одной проблемы: расхождение описания и реальности перестаёт быть незаметным. Переносить стоит то, что живёт годами и проверяемо машиной: контракты API (интеграции), схемы сообщений, модель данных как миграции и словарь рядом с ними (моделирование данных), сценарии в Gherkin (если по ним действительно автоматизируют), диаграммы как текст — PlantUML, Mermaid, Structurizr DSL: их видно в диффе и можно ревьюить построчно, а не «сравните две картинки глазами». Плюс ADR — короткие записи «какое решение приняли и почему» (формат Нейгарда). Не стоит тащить туда протоколы встреч, черновики и презентации для бизнеса.

Главное здесь — контракт и код едут одним pull request. Пока они разъезжаются, документация обречена устаревать: код меняют потому, что иначе не работает, а документ — потому, что кто-то вспомнил.

# .github/workflows/contracts.yml — контракт ломается на CI, а не на демо.
name: contracts
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Полнота и стиль: у каждой операции есть описание, примеры и коды ошибок.
      - run: npx @stoplight/spectral-cli lint api/openapi.yaml --fail-severity=warn
      # Совместимость: убрали поле или сузили enum — сборка красная. Договорённость
      # «ломающее изменение только через версию» стала автоматической проверкой.
      - run: |
          git fetch origin main --depth=1
          git show origin/main:api/openapi.yaml > /tmp/base.yaml
          docker run --rm -v /tmp:/base -v "$PWD":/spec \
            tufin/oasdiff breaking /base/base.yaml /spec/api/openapi.yaml          

Инструменты настоящие: Spectral — линтер OpenAPI, oasdiff — детектор ломающих изменений, Prism — mock-сервер прямо из контракта, благодаря которому фронтенд стартует в день согласования, а не через две недели. Обратите внимание, что случилось с ролью аналитика: договорённость перестала быть строчкой регламента, которую все обещали соблюдать, и стала красной сборкой. Это и есть взросление в профессии — переводить договорённости в проверки.

3. Навыки, без которых любой инструмент бесполезен

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

3.1. SQL: уровень «сам достаю числа»

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

-- Сколько заявок на возврат за прошлый квартал попадает под согласованное правило
-- автовозврата и сколько из них люди всё-таки отклонили руками.
WITH requests AS (
    SELECT r.id, r.created_at, r.resolved_at, r.resolution,
           -- правило ровно в том виде, в каком его согласовали:
           (p.method = 'card'
            AND o.total_amount <= 3000
            AND r.reason_code IN ('not_fit', 'changed_mind')) AS auto_eligible
    FROM refund_request r
    JOIN orders  o ON o.id = r.order_id
    JOIN payment p ON p.order_id = o.id AND p.status = 'captured'
    WHERE r.created_at >= date_trunc('quarter', now()) - interval '1 quarter'
      AND r.created_at <  date_trunc('quarter', now())
)
SELECT count(*)                                              AS total,
       count(*) FILTER (WHERE auto_eligible)                 AS eligible,
       round(100.0 * count(*) FILTER (WHERE auto_eligible) / count(*), 1) AS share_pct,
       -- медиана времени решения: основа SLA, среднее здесь врёт из-за хвоста
       round(percentile_cont(0.5) WITHIN GROUP (
           ORDER BY extract(epoch FROM resolved_at - created_at) / 60)::numeric, 0) AS median_min,
       -- вот эта колонка и есть находка: подходят под правило, но отклонены человеком
       count(*) FILTER (WHERE auto_eligible AND resolution = 'rejected') AS rejected_though_ok
FROM requests
WHERE resolved_at IS NOT NULL;

Последняя колонка важнее остальных. Если из 4100 «подходящих» заявок операторы отклонили 260, значит, существует правило, которого нет ни в одном документе: люди на что-то реагируют — повторные возвраты от одного клиента, подозрительные адреса, спорные категории. Это классическое неявное требование, найденное не на интервью, а запросом (системно — в выявлении требований). Минимальный уровень: JOIN всех видов, GROUP BY с HAVING, FILTER, оконные функции для когорт, EXPLAIN — хотя бы чтобы понять, почему запрос идёт двадцать минут. Дальше — реляционная модель и индексы с планами запросов.

3.2. API руками: пять минут вместо двух дней переписки

# 1. Идемпотентность: тот же запрос с тем же ключом. По контракту ждём 200
#    и прежний refund_id, а не второй возврат тех же денег.
curl -sS -X POST https://api.shop.local/v1/refunds \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: 8f1c4a20-a3b1-4f0e-9c11-2f3d7a6b1e55' \
  -d '{"order_id":"A-100341","amount":{"value":"2490.00","currency":"RUB"},"reason":"not_fit"}' \
  -w '\nHTTP %{http_code}, %{time_total}s\n'

# 2. Граница правила: сумма ровно 3000.00 — внутри лимита или снаружи? Место, где
#    документ говорит «до 3000», а код думает иначе. Третий запрос — с заголовком
#    X-Force-Acquirer-Error: что приходит в теле, когда банк недоступен, —
#    машиночитаемый код ошибки или HTML, который фронт не разберёт?
curl -sS -X POST https://api.shop.local/v1/refunds \
  -H 'Idempotency-Key: 6b2e-boundary' -H 'Content-Type: application/json' \
  -d '{"order_id":"A-100999","amount":{"value":"3000.00","currency":"RUB"},"reason":"not_fit"}'

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

3.3. Чтение логов и трейсов

Разница между аналитиком и тестировщиком именно в выводе. Тестировщик заводит дефект. Аналитик видит дыру в требованиях: сценарий «банк принял, но не подтвердил» не описан ни в контракте, ни в критериях приёмки, ни в НФТ. Значит, надо не багу заводить, а дописать поведение — и тогда дефекта не будет ни здесь, ни в трёх похожих местах (НФТ, приёмка).

3.4. Немного кода: сверка, которую не сделает никто, кроме вас

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

from decimal import Decimal  # только Decimal: float даёт расхождение в копейки


def reconcile(ours: dict[str, Decimal], bank: dict[str, Decimal]):
    """Сверка реестра возвратов магазина с выпиской банка: три класса расхождений,
    за каждым стоит своё ненаписанное требование.

    Сложность: O(n + m) по времени и по памяти (n, m — размеры выгрузок).
    Наивный вложенный цикл дал бы O(n * m): на 200 тыс. строк это часы вместо секунды.
    """
    only_ours = {k: v for k, v in ours.items() if k not in bank}  # мы вернули, банк не знает
    only_bank = {k: v for k, v in bank.items() if k not in ours}  # банк вернул, следа нет
    mismatch = {k: (v, bank[k]) for k, v in ours.items()
                if k in bank and bank[k] != v}                    # суммы разошлись
    return only_ours, only_bank, mismatch

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

4. Грейды: чем junior отличается от senior не по годам

Грейд — это класс неопределённости, который человек снимает самостоятельно, и радиус, на котором он за это отвечает. Формулировка работает в любой компании независимо от её матрицы компетенций.

Правый нижний квадрант — самая частая ловушка. Человек знает систему лучше всех, помнит, почему в 2021 году сделали костыль в расчёте НДС, отвечает на сорок вопросов в день — и не принимает ни одного решения сам. По стажу это senior; по классу задач — middle, которого невозможно повысить, потому что повышение остановит поток ответов.

4.1. Один вход, три ответа

Стейкхолдер: «Сделайте автовозврат в один клик, у конкурентов есть».

Junior заводит эпик и пишет историю: «Как клиент, я хочу вернуть заказ в один клик». Критерии: «Кнопка “Вернуть” на странице заказа; при нажатии деньги возвращаются». Работа добросовестная, и в ней нет ответа ни на один вопрос: любой заказ или только оплаченный картой? Любая сумма? Что с отгруженным товаром? Что, если банк не подтвердил?

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

Senior сначала выясняет зачем: смотрит поток заявок тем самым SQL-запросом, считает, что 19% попадают под правило, ручная обработка занимает 26 минут и стоит столько-то за квартал, а 260 подходящих заявок операторы отклонили руками. Приносит владельцу продукта размер выигрыша, найденное неявное правило и альтернативу: «первые 60% эффекта даёт не кнопка, а автоодобрение уже поданной заявки; кнопка втрое дороже и требует переработки корзины». Отдельно фиксирует риск: без окна отмены и лимита частоты это дыра в мошенничество. Итог — дешёвый вариант, эффект тот же, разработка на месяц короче. Разница со вторым не в опыте написания историй: senior работает с задачей, а не с формулировкой, и приносит числа вместо мнений (как это делать, не превращаясь в человека, который всем возражает, — в работе со стейкхолдерами).

4.2. Почему застревают

1. Повторение одного года. Пять лет одинаковых историй в одной системе дают пять раз по одному году. Лекарство неприятное: раз в полгода брать задачу класса, которого вы не делали, — интеграцию, если делали только UI; нагрузку и НФТ, если писали только функциональные требования.
2. Ценность через незаменимость. Знание в голове ощущается как страховка, но именно оно держит на месте: некому передать. Перевод знания в модели, контракты и проверки — не альтруизм, а единственный способ освободить себе руки.
3. Комфорт исполнителя. Отвечать на поставленный вопрос спокойнее, чем ставить его самому. Помогает мелкая регулярная практика: к каждой задаче добавлять строку «зачем это бизнесу и как мы поймём, что помогло».

5. Специализации: куда расходятся дороги

Специализация раскладывается по трём независимым осям: тип системы (интеграции и обмен, данные и хранилища, ML и AI-продукты, миграции и замена систем), домен (финтех, e-commerce и логистика, госсектор и промышленность, медицина, телеком) и роль (ведущий аналитик, архитектор, product owner, руководитель аналитиков). Оси не связаны: можно быть интеграционным аналитиком в банке в консалтинге. Практический смысл разделения — понимать, что доучивать и где новичок в этой специализации ломается.

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

Два перехода стоит прокомментировать честно. В архитекторы уходят не за «умение рисовать квадратики»: там отвечают за решения с денежной ценой ошибки, знают эксплуатацию и спорят с инженерами на их языке — см. архитектурные решения. В product owner переходят не за «то же самое, только с властью»: меняется предмет ответственности — не «система ведёт себя правильно», а «мы делаем правильное» (треки Product management и Project management).

6. Что ломается в карьере чаще всего

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

Аналитик как узкое место. Команда не начинает задачу, пока вы не ответите; вопросы идут в личку; вы отвечаете быстрее, чем люди читают документ. Ощущается как незаменимость, работает как тормоз. Лечится переводом ответов в артефакты, доступные без вас, и явными решениями по умолчанию: «если до пятницы возражений нет — делаем так».

Документ ради документа. Спецификация на сорок страниц, открытая дважды. У документа должен быть читатель и решение, которое он принимает, прочитав; нет читателя — нет документа (подробно в документировании). Рядом стоит непереносимый навык: пять лет в одной корпоративной платформе, один домен, внутренняя терминология. На рынке это стоит дёшево не потому, что навык плохой, а потому, что его нельзя предъявить. Раз в год добивайтесь, чтобы хотя бы один результат описывался в общих терминах: контракт, модель данных, измеримое НФТ, сокращение времени процесса.

Отсутствие числа. «Занимался сбором и анализом требований» не несёт информации. «Автоматизировал возвраты: 19% заявок ушли из ручной обработки, среднее время решения с 26 минут до 4, релиз за 6 недель вместо 14» — это работа. NDA почти никогда не мешает назвать класс задачи, масштаб и эффект: секретны цифры выручки, а не факт ускорения процесса вчетверо. Показать можно и артефакты: анонимизированный кейс на две страницы, OpenAPI-контракт учебного сервиса с продуманными ошибками, BPMN-схему с корректными шлюзами, критерии приёмки к сложному правилу.

7. Собеседование: что на самом деле проверяют

Хорошее интервью аналитика — не викторина про нотации. Проверяют четыре вещи, почти всегда кейсом «опишите требования к сервису X»: задаёте ли вы вопросы до того, как начать описывать (кандидат, который сразу рисует, — красный флаг; три-четыре вопроса про цель, ограничения и границы системы стоят дороже схемы); умеете ли объявлять границы («расчёт налогов я считаю вне скоупа, и вот почему»); проверяемость — превращаете ли «система должна работать быстро» в «p95 отклика POST /refunds не более 800 мс при 50 rps, измеряем на API-шлюзе»; поведение в конфликте — на «финансовый директор хочет одного, поддержка другого» ответ «эскалирую» не ответ, а «вскрою интересы за позициями и покажу цену каждого варианта» — ответ.

Что спросить самому, кроме четырёх вопросов из обзора трека: где живут контракты и версионируются ли; есть ли доступ к продовым данным и логам; кто принимает результат и участвует ли в этом аналитик. Ответ «доступа к базе нет, выгрузки ждём неделю» — не стоп-фактор, но он определит, каким аналитиком вы там станете. Механику найма разбирает трек SDLC и карьера: грейды, рост, собеседование, переговоры, карьерные треки; зарплатные ориентиры — в открытых данных вроде Хабр Карьеры, а не в чужих рассказах.

Сертификации. IREB CPRE Foundation даёт строгую терминологию требований и полезен самоучкам; IIBA ECBA/CCBA/CBAP весит в международных и консалтинговых компаниях; BPMN Method and Style дисциплинирует, если процессы — ваш основной инструмент; TOGAF и ArchiMate имеют смысл там, где они условие входа. В продуктовых командах сертификат почти не влияет на найм — там смотрят разбор кейса, а ценность подготовки к CPRE выше ценности корочки: она заставляет системно прочитать про виды требований и трассировку.

8. Что учить в ближайший год

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

Базовая библиотека: Karl Wiegers, Joy Beatty, «Software Requirements» — энциклопедия ремесла; Suzanne и James Robertson, «Mastering the Requirements Process» с шаблоном Volere; Alistair Cockburn, «Writing Effective Use Cases». Для системной части — Gregor Hohpe, «Enterprise Integration Patterns» и Martin Kleppmann, «Designing Data-Intensive Applications»: после второй перестаёшь писать требования, которые невозможно выполнить. Для проверяемости — Gojko Adzic, «Specification by Example».

Мини-итог

• Инструмент выбирают по сроку жизни знания: часы — доска, до релиза — трекер, годы — репозиторий с версией, ревью и владельцем. Слотов всего пять: поток, стабильное знание, модели, контракты, данные; дыра в любом превращается в предсказуемую аварию.
• Docs-as-code имеет смысл ровно для проверяемого. Взрослая работа — переводить договорённости в проверки, а не в регламенты.
• Навыки важнее инструментов: SQL до уровня «сам достаю число», API руками, чтение логов и трейсов, немного кода для сверок. Профиль T-образный.
• Грейд — это класс неопределённости, который снимаешь сам: junior делает историю, middle отвечает за фичу, senior работает с задачей бизнеса и приносит числа, lead меняет правила игры. Застревают трояко: повторяют один год, держатся за незаменимость, привыкают отвечать вместо того, чтобы спрашивать.
• Предъявить стоит не список инструментов, а кейс с числом: что было неизвестно, что вы сделали, что изменилось.

Источники

• Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. — microsoftpressstore.com; Volere template — volere.org.
• IIBA BABOK — iiba.org; IREB CPRE — ireb.org.
• ISO/IEC/IEEE 29148:2018 — iso.org; ISO/IEC 25010 — iso25000.com.
• OMG BPMN 2.0 — omg.org; OpenAPI — spec.openapis.org; AsyncAPI — asyncapi.com.
• Spectral — docs.stoplight.io; oasdiff — github.com/oasdiff/oasdiff; Prism — github.com/stoplightio/prism.
• Michael Nygard. Documenting Architecture Decisions — cognitect.com; шаблоны ADR — adr.github.io; C4 model — c4model.com.
• Google SRE Book, глава про SLO — sre.google; PostgreSQL Documentation — postgresql.org.

Что дальше

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

• К продукту — Product management: зачем мы делаем то, что делаем, метрики и приоритизация.
• К управлению поставкой — Project management и Scrum master.
• К технической глубине — Архитектурные стили, Базы данных, DDD и материал «Требования» в треке архитектуры.
• К проверке результата — Тестирование; к пользователю — UX-дизайн; к карьере в целом — SDLC и карьера.

Общая карта портала с маршрутами под конкретные цели — в роадмапе.