Системный аналитик до трудоустройства (уровень Middle): hard + soft навыки

Курс формирует ключевые компетенции системного аналитика для выхода на рынок труда с прицелом на middle-уровень: от требований и моделирования до технической базы и коммуникаций. В конце вы соберёте портфолио артефактов, отработаете интервью и подготовите карьерную стратегию.

1. Роль системного аналитика и целевая матрица компетенций Middle

Роль системного аналитика и целевая матрица компетенций Middle

Системный аналитик (СА) помогает команде создавать и изменять системы так, чтобы они решали задачи бизнеса и пользователей предсказуемо, качественно и в нужные сроки. В этой статье мы зафиксируем:

  • что именно делает системный аналитик и где проходит граница роли
  • чем Middle отличается от Junior
  • целевую матрицу компетенций Middle: что уметь, как это проявляется в работе и какими артефактами подтверждается

    • Ключевые понятия без «прыжков через термины»

  • Система — часть продукта (или весь продукт), которая принимает входные данные, обрабатывает их по правилам и выдаёт результат. Пример: личный кабинет банка, CRM, сервис расчёта доставки.
  • Стейкхолдер — человек или группа, чьи интересы затрагивает система. Пример: пользователь, служба поддержки, бухгалтерия, безопасность, разработка.
  • Требование — проверяемое описание того, что система должна делать или какими свойствами обладать.
  • Функциональное требование (ФТ) — что система делает. Пример: «пользователь может сбросить пароль по email».
  • Нефункциональное требование (НФТ) — каким должно быть качество/ограничения решения. Пример: «время ответа не более 2 секунд при 500 RPS», «шифрование данных в покое».
  • Артефакт — документ или модель, которую команда использует как источник правды. Пример: описание API, BPMN-схема процесса.

    • Где системный аналитик находится в жизненном цикле продукта

    Практически в любой компании работа выглядит как повторяющийся цикл:

  • понять проблему и цель
  • уточнить требования и ограничения
  • спроектировать решение на уровне аналитики (что именно должно быть реализовано)
  • реализовать и проверить
  • выпустить и наблюдать в эксплуатации

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

    !Карта того, с кем системный аналитик взаимодействует и какие типы информации через него проходят

    Зоны ответственности и границы роли

    В разных компаниях названия ролей отличаются, но полезно понимать типичное разделение.

    Системный аналитик отвечает за

  • выявление и уточнение требований, включая НФТ и ограничения
  • моделирование: процессы, сценарии, данные, интеграции
  • согласование требований со стейкхолдерами и командой
  • управление изменениями требований (что меняем, почему, какие последствия)
  • качество постановки: однозначность, проверяемость, трассируемость (связи «цель → требования → реализации/тесты»)

    • Где обычно границы роли

  • Product Owner/менеджер продукта чаще отвечает за что и зачем с точки зрения продукта: приоритеты, ценность, roadmap.
  • Проектный менеджер/скрам-мастер чаще отвечает за как организуем работу: сроки, риски, процесс, коммуникации по плану.
  • Архитектор чаще отвечает за как устроено решение технически: компоненты, технологии, масштабирование, ключевые архитектурные решения.
  • Разработчик отвечает за реализацию кода и техническое качество реализации.
  • Тестировщик отвечает за стратегию тестирования и проверку качества.

    • Важно: на практике зоны перекрываются. Middle СА умеет работать на стыке, но не «подменяет» владельца решения в его зоне ответственности.

    Что является результатом работы системного аналитика

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

    Ниже — типовые артефакты (выбор зависит от компании и задач).

  • Vision/цель изменения — коротко: какую проблему решаем и какой эффект ожидаем.
  • Глоссарий — словарь терминов домена, чтобы команда одинаково понимала слова.
  • User story и критерии приёмки — формулировка потребности + условия, по которым работа считается выполненной.
  • Use case/сценарии — пошаговое описание взаимодействия пользователя/систем с учётом альтернатив и ошибок.
  • BPMN-схема процесса — как работает бизнес-процесс «до» и «после».
  • UML-диаграммы — например, диаграмма последовательностей для сложных взаимодействий.
  • Модель данных — сущности, атрибуты, связи, правила целостности.
  • Интеграции и контракты API — методы, структуры запросов/ответов, ошибки, версии.
  • НФТ — производительность, доступность, безопасность, аудит, совместимость и т.д.
  • Трассируемость — связи между целями, требованиями, задачами разработки и тестами.

    • Полезные ориентиры по формату требований:

  • ISO/IEC/IEEE 29148 Systems and software engineering — Life cycle processes — Requirements engineering

    • Что отличает Middle системного аналитика

    Middle — это уровень, на котором от аналитика ожидают самостоятельности и управляемого качества работы. Обычно это проявляется так:

  • умеет превращать «хотелки» в проверяемые требования без постоянного контроля
  • видит зависимости и последствия изменений (данные, интеграции, миграции, отчёты, права доступа)
  • умеет декомпозировать задачу на релизуемые части и не терять целостность
  • ведёт встречи по сбору/согласованию требований и фиксирует решения
  • удерживает баланс между скоростью и качеством, понимает риски недоопределённости
  • пишет спецификации так, чтобы разработка и тестирование могли работать параллельно

    • Целевая матрица компетенций Middle

    Матрица — это список компетенций с критериями: как выглядит Middle-уровень на практике. Её удобно использовать как:

  • чек-лист самооценки
  • основу плана обучения
  • ориентир для портфолио и собеседований

    • Ниже — целевой профиль Middle системного аналитика. Это не «единственно верный стандарт», но практичный ориентир для трудоустройства.

    Hard skills: аналитика, модели, требования

    | Компетенция | Ожидание Middle | Индикаторы в работе | Что можно показать (артефакты) | |---|---|---|---| | Сбор требований (elicitation) | Самостоятельно выбирает техники сбора и получает недостающую информацию | Проводит интервью/воркшопы, задаёт уточняющие вопросы, выявляет скрытые ограничения | План и протокол встреч, список вопросов, итоговый конспект решений | | Анализ и формализация требований | Делает требования однозначными и проверяемыми | Формулировки без двусмысленности, есть критерии приёмки, обработаны ошибки/исключения | User story + acceptance criteria, use case, спецификация | | Управление изменениями | Контролирует изменения и их влияние | Фиксирует версии, ведёт список изменений, подсвечивает impact | Changelog, записи решений, обновлённые модели | | Моделирование бизнес-процессов | Описывает процессы «как есть» и «как будет» и находит разрывы | Выявляет роли, точки контроля, исключения, ручные операции | BPMN-диаграммы, описание шагов и правил | | Моделирование взаимодействий | Понимает сложные сценарии и интеграции | Определяет участников, последовательность, состояния, ошибки | UML sequence/communication diagram, сценарии | | Работа с данными | Понимает, какие данные нужны и как они связаны | Определяет сущности, атрибуты, ключи, справочники, валидации | ER-диаграмма, словарь данных, правила качества данных | | API и интеграции | Умеет описывать контракт и договориться о форматах | Прорабатывает методы, схемы, ошибки, идемпотентность, версии | OpenAPI/Swagger, таблица ошибок, примеры запросов/ответов | | НФТ | Выявляет и фиксирует ключевые НФТ под задачу | Есть требования по производительности, безопасности, доступности, логированию | Раздел НФТ в спецификации, чек-лист контроля | | Декомпозиция и границы решения | Разбивает задачу на части без потери смысла | Выделяет MVP/итерации, зависимости, общие компоненты | Backlog с декомпозицией, карта зависимостей | | Приёмка и тестируемость | Делает требования тестируемыми | Критерии приёмки проверяемы, есть негативные кейсы | Набор acceptance criteria, список тест-сценариев | | Инструменты и дисциплина документации | Поддерживает документы «живыми» | Единые шаблоны, ссылки между страницами, актуальность | Confluence-структура, шаблоны, договорённости |

    Soft skills: коммуникация и управляемость

    | Компетенция | Ожидание Middle | Индикаторы в работе | Что можно показать (сигналы) | |---|---|---|---| | Коммуникация «понятно разным» | Объясняет одно и то же разным аудиториям | Для бизнеса — ценность и правила, для разработки — точность и крайние случаи | Примеры формулировок, фрагменты спецификаций | | Фасилитация встреч | Ведёт обсуждения к решению | Есть повестка, таймбокс, фиксируются решения и действия | Agenda, meeting notes, список action items | | Управление ожиданиями | Договаривается о scope и компромиссах | Умеет говорить «нет» или «не сейчас» аргументированно | Записи решений, согласованные приоритеты | | Конфликты и переговоры | Разруливает противоречия требований | Находит общий критерий (цель, риск, стоимость), предлагает варианты | Матрица вариантов, протокол разногласий | | Критическое мышление | Проверяет гипотезы и не принимает «как принято» без анализа | Задаёт вопросы про цель, метрику, последствия, альтернативы | Документ с допущениями, рисками, вариантами | | Ответственность и надёжность | Доводит постановку до состояния «можно делать» | Предупреждает о рисках заранее, соблюдает договорённости | Обратная связь команды, стабильное качество | | Работа в неопределённости | Двигает задачу, даже когда нет всех ответов | Фиксирует допущения, планирует уточнения, делает инкременты | Список assumptions, план уточнений |

    Как пользоваться матрицей, чтобы выйти на Middle

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

  • Выберите 5–7 компетенций с наибольшим влиянием на трудоустройство: требования, модели, данные, API, НФТ, коммуникация.
  • Для каждой компетенции соберите «доказательства» — артефакты, которые вы можете показать в портфолио (даже учебные, но реалистичные).
  • Закройте пробелы через практику: одна компетенция = один мини-проект или один законченный пакет артефактов.
  • Запросите ревью: у коллег, ментора или сообщества. Middle растёт быстрее от обратной связи, чем от чтения.

    • Минимальный набор инструментов Middle системного аналитика

  • система задач и документации: Jira/YouTrack + Confluence/Notion
  • диаграммы: draw.io (diagrams.net) или аналог
  • описание API: OpenAPI (Swagger) и инструменты для теста запросов (например, Postman)
  • базовый SQL для проверки данных
  • базовое понимание Git (хотя бы чтение изменений)

    • Полезные источники и стандарты

  • A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3
  • ISO/IEC/IEEE 29148 Systems and software engineering — Requirements engineering
  • OMG Unified Modeling Language (UML)
  • OMG Business Process Model and Notation (BPMN)
  • OpenAPI Specification
  • The C4 model for visualising software architecture
  • Agile Manifesto

    • 2. Сбор требований: интервью, воркшопы, работа со стейкхолдерами

    Сбор требований: интервью, воркшопы, работа со стейкхолдерами

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

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

    Что значит “собрать требования”

    Сбор требований — это не “записать хотелки”. Это управляемый процесс получения информации, которая позволит команде:

  • понять цель изменения и ожидаемый эффект
  • выявить правила, исключения и ограничения
  • определить границы решения и зависимости
  • зафиксировать критерии приёмки и что считать “готово”

    • Важно различать:

  • потребности (зачем это нужно)
  • требования (что должно быть сделано и какие свойства соблюдены)
  • решения (как именно это будет реализовано технически)

    • Middle-уровень отличается тем, что вы умеете удерживать границу: не сваливаетесь в архитектуру раньше времени, но и не оставляете “дыр” в логике, данных и интеграциях.

    Стейкхолдеры: кого нужно вовлечь и зачем

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

    Типовые группы стейкхолдеров:

  • бизнес-заказчик (владелец цели и эффекта)
  • пользователи (те, кто реально делает работу)
  • поддержка/операции (те, кто “разгребает” инциденты и исключения)
  • разработка и тестирование (те, кто будет реализовывать и проверять)
  • безопасность/комплаенс/юристы (те, кто накладывает ограничения)
  • владельцы смежных систем (интеграции, данные, SLA)

    • !Карта стейкхолдеров помогает не забыть важные источники требований и ограничений

    Быстрый способ не пропустить важных стейкхолдеров

    Задайте заказчику и команде короткий набор вопросов:

  • Кто будет пользоваться результатом ежедневно?
  • Кто будет поддерживать и разбирать ошибки?
  • Какие команды владеют данными, которые мы читаем/пишем?
  • Какие регуляторные или безопасностные ограничения применимы?
  • Кто принимает решение о запуске в прод и по каким критериям?

    • Результат этого шага — список стейкхолдеров и план коммуникаций: кого интервьюируем, кого зовём на воркшоп, кого подключаем на ревью.

    Выбор формата: интервью или воркшоп

    Оба формата нужны, но решают разные задачи.

    Интервью подходит, когда:

  • нужно глубоко понять работу конкретной роли
  • много “тонкостей” и исключений
  • стейкхолдеров сложно собрать вместе

    • Воркшоп подходит, когда:

  • нужно согласовать общее понимание и снять противоречия
  • есть конфликт интересов или разные версии “как работает”
  • требуется быстро договориться о правилах, границах, приоритетах

    • Практичное правило: сначала 2–5 интервью, затем воркшоп на согласование, затем короткие точечные интервью по “дырам”.

    Подготовка к сбору требований

    Подготовка — ключ к тому, чтобы встреча дала результат, а не “поговорили”.

    Что подготовить до любой сессии

  • цель встречи в формате “после встречи у нас будет …”
  • предварительный контекст: что меняем, почему сейчас, какие ограничения уже известны
  • список участников и их роль (кто принимает решение, кто консультирует)
  • повестка с таймбоксом
  • заготовка артефакта для фиксации (шаблон заметок, таблица правил, черновик сценариев)

    • Шаблон повестки (agenda)

  • Контекст: цель изменения и границы обсуждения
  • Как работает сейчас: кратко, без деталей, которые не влияют на изменение
  • Как должно быть: сценарии, правила, исключения
  • Данные и интеграции: источники, что читаем/пишем, кто владелец
  • Нефункциональные требования: скорость, доступность, аудит, безопасность
  • Риски и открытые вопросы
  • Подведение итогов: решения, действия, ответственные, сроки

    • Интервью: как проводить на уровне Middle

    Структура интервью

  • Разогрев и контекст: зачем вы пришли и что хотите получить
  • Понимание роли: какие задачи у человека, какие боли, какие метрики успеха
  • Разбор сценариев: шаги, входы/выходы, ошибки, ручные обходы
  • Правила и исключения: “когда нельзя”, “что делаем, если …”, “кто решает”
  • Данные: какие поля важны, какие справочники, какие проверки
  • Завершение: резюме вами, подтверждение, следующий шаг

    • Типы вопросов, которые реально вытаскивают требования

  • открытые: “Как вы понимаете…?”, “Что происходит после…?”
  • уточняющие: “Что значит ‘быстро’?”, “Какие статусы возможны?”
  • на исключения: “А если клиент без …?”, “Что делаете, если система недоступна?”
  • на критерии: “По каким признакам вы считаете операцию успешной?”
  • на границы: “Что точно не входит?”, “Какие решения нельзя менять?”

    • Полезные техники во время интервью

  • Пять почему — последовательные вопросы “почему?”, чтобы выйти от симптома к причине
  • Конкретизация примерами — “приведите реальный кейс из вчера/прошлой недели”
  • Воспроизведение процесса — “покажите экран/форму”, “проговорим шаги как вживую”

    • Что фиксировать прямо в момент интервью

  • термины и определения для будущего глоссария
  • правила в формате “если … то …”
  • список исключений и ошибок
  • источники данных и владельцев
  • открытые вопросы и кому их адресовать

    • Если вы не фиксируете решения и допущения сразу, вы почти гарантированно получите “разные версии” через неделю.

    Воркшоп: как согласовывать требования и снимать противоречия

    Воркшоп — это управляемая групповая работа, где важны фасилитация (ведение к результату) и правила взаимодействия.

    Роли на воркшопе

  • фасилитатор (часто это вы): держит цель, процесс, таймбокс
  • владелец решения: подтверждает договорённости и приоритеты
  • эксперты: дают фактуру и ограничения
  • секретарь (можете быть вы): фиксирует решения и действия

    • Техники воркшопов, полезные системному аналитику

  • Story mapping (карта пользовательских действий) — раскладываем путь пользователя по шагам и выделяем MVP
  • Event storming (разбор домена через события) — выписываем ключевые события и команды системы, чтобы найти правила и пробелы
  • Совместный разбор сценариев — идём по use case и на каждом шаге уточняем альтернативы и ошибки
  • Матрица вариантов — сравниваем 2–3 подхода по критериям (риск, стоимость, сроки, влияние)

    • Если используете технику впервые, проговорите её простыми словами и покажите ожидаемый результат артефактом.

    Как проводить воркшоп так, чтобы он не превратился в спор

  • Начните с цели и определения “что сегодня считается результатом”.
  • Зафиксируйте правила: один говорит — остальные слушают, решения фиксируются.
  • Паркуйте темы, не входящие в цель встречи, в список parking lot (список отложенных вопросов).
  • Договорённости оформляйте сразу в виде проверяемых формулировок.
  • Завершайте резюме: решения, открытые вопросы, ответственные, сроки.

    • Работа со “сложными” стейкхолдерами

    Middle-аналитику важно не только “знать техники”, но и уметь управлять взаимодействием.

    Частые ситуации и рабочие ответы

  • Стейкхолдер говорит “сделайте как в прошлом проекте”.
    • - Уточняйте цель и ограничения: иногда “как раньше” не проходит по данным, безопасности или процессу.
  • Стейкхолдер просит “сделать всё сразу”.
    • - Переводите в декомпозицию: MVP, последующие итерации, риски, зависимости.
  • Конфликт между подразделениями.
    • - Находите общий критерий: риск, стоимость, SLA, регуляторика, влияние на клиента.
  • Нет времени на встречи.
    • - Предлагайте асинхронный формат: список вопросов в документе, короткий созвон на 20 минут, подтверждение итогов письменно.

    Ключевой приём: отделяйте позиции (“хочу так”) от интересов (“мне нужно, чтобы …”), и помогайте группе договориться на уровне интересов.

    Как превращать разговоры в требования и артефакты

    Сбор требований ценен только тогда, когда результаты становятся “источником правды” для команды.

    Минимальный комплект артефактов после сбора требований

  • краткая цель изменения и границы (что входит и что не входит)
  • список стейкхолдеров и владельцев областей (кто подтверждает что)
  • сценарии (use case) или user story с критериями приёмки
  • список бизнес-правил и исключений
  • данные: сущности/поля/валидации на уровне аналитики
  • интеграции: кто с кем и что передаёт, ошибки, идемпотентность при необходимости
  • НФТ: производительность, доступность, аудит, безопасность, ограничения
  • открытые вопросы, допущения и риски

    • Проверка качества результатов (валидизация)

    После интервью или воркшопа отправляйте короткое подтверждение:

  • что мы поняли (резюме)
  • что решили (decision log — журнал решений)
  • что осталось открытым (список вопросов)

    • Хороший признак Middle-уровня: вы не просите “проверить весь документ”, а просите подтвердить конкретные утверждения и правила.

    Типовые ошибки в сборе требований

  • задавать вопросы про интерфейс, не поняв цель и процесс
  • фиксировать “как привыкли”, не проверяя соответствие реальной работе
  • не обсуждать исключения и ошибки (потом они “вылазят” на тестировании или в проде)
  • не обозначать владельца решения, из-за чего требования “висят в воздухе”
  • не фиксировать термины, из-за чего команда спорит о значениях слов
  • уходить со встречи без списка решений и следующих шагов

    • Практический чек-лист перед сессией сбора требований

  • цель встречи сформулирована и понятна участникам
  • выбраны участники, которые могут дать фактуру и принять решения
  • подготовлен шаблон фиксации результатов
  • заготовлены вопросы про сценарии, исключения, данные, интеграции, НФТ
  • определён способ подтверждения итогов (комментарии в документе, письмо, короткий созвон)

    • Полезные источники

  • BABOK Guide v3 (IIBA)
  • ISO/IEC/IEEE 29148:2018 Requirements Engineering
  • Nielsen Norman Group: User Interviews
  • Atlassian: Stakeholder Management

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

    3. Моделирование: BPMN, UML, доменная модель и границы системы

    Моделирование: BPMN, UML, доменная модель и границы системы

    В прошлых статьях мы закрепили:

  • роль системного аналитика Middle и набор артефактов, по которым видна зрелость
  • как собирать требования через интервью, воркшопы и работу со стейкхолдерами

    • Следующий шаг — превратить разговоры и заметки в модели, которые помогают команде одинаково понимать:

  • где граница системы и с какими внешними участниками она взаимодействует
  • как устроены процессы и сценарии
  • какие данные существуют в предметной области и какие правила к ним применяются
  • что именно должно быть реализовано и проверено

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

    Что такое модель и зачем она нужна

    Модель — упрощённое описание реальности (процесса, взаимодействия, данных), которое оставляет только важное для решения задачи.

    Хорошая модель:

  • уменьшает двусмысленность в требованиях
  • ускоряет согласование со стейкхолдерами
  • подсвечивает пробелы: исключения, роли, статусы, источники данных, интеграции
  • помогает тестированию: по модели проще построить набор проверок

    • Плохая модель:

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

    • Практичный принцип Middle-уровня: каждая модель должна отвечать на конкретные вопросы и иметь владельца актуальности.

    Границы системы как отправная точка

    Прежде чем рисовать BPMN или UML, зафиксируйте границу системы.

    Граница системы — договорённость о том, что мы считаем «внутри» нашего решения, а что «снаружи».

    Это влияет на всё:

  • что именно вы описываете в требованиях (поведение нашей системы или внешней)
  • где заканчивается ваша ответственность и начинается ответственность внешнего сервиса/команды
  • какие интеграции и данные критичны

    • Контекстная диаграмма как быстрый способ договориться о границе

    Самый удобный стартовый артефакт — контекст: кто взаимодействует с системой и через какие каналы.

    В контексте обычно показывают:

  • нашу систему (или подсистему)
  • внешних акторов: пользователи, операторы, смежные системы
  • ключевые потоки: данные, события, запросы

    • !Контекст помогает договориться, кто с кем взаимодействует и что считается внешним

    Подход C4 полезен как язык для разговора о границах и интерфейсах системы.

    Ссылки:

  • C4 Model

    • Частая ошибка с границей

    Ошибка: смешивать в одном описании ответственность разных систем, например: «Система отменяет платёж и возвращает деньги».

    Правильнее:

  • «Наша система инициирует возврат в платёжном провайдере и фиксирует результат»
  • отдельно — договорённости по интеграции и обработке статусов

    • BPMN: моделирование бизнес-процессов

    BPMN (Business Process Model and Notation) — нотация для описания процесса как последовательности шагов с ролями, событиями, ветвлениями и исключениями.

    BPMN особенно полезен, когда:

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

    • Базовые элементы BPMN, которых достаточно для большинства задач

    Чтобы быть эффективным, не нужно знать весь стандарт. В типовой работе Middle СА чаще всего хватает:

  • Pool и Lane — участники процесса и роли (кто делает)
  • Task — шаг работы
  • Gateway — развилка условий (например, «оплата успешна?»)
  • Start/End event — начало и конец процесса
  • Intermediate event — ожидание события или таймера (например, таймаут оплаты)
  • Message flow — сообщения между участниками

    • Важно: BPMN — про процесс и ответственность, а не про UI-экраны.

    Как делать BPMN так, чтобы его читали

  • Начинайте с цели процесса и границ: где старт, где конец.
  • Делайте дорожки по ролям: пользователь, оператор, наша система, внешний сервис.
  • На каждый шаг задавайте вопросы:
    • - какие входные данные нужны - какой результат шага - что может пойти не так
  • Исключения моделируйте явно: ветка на ошибку, отмену, таймаут.
  • Не смешивайте разные уровни детализации в одной схеме.

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

    Связь BPMN с требованиями

    BPMN должен приводить к требованиям, а не заменять их.

    Практичная связка:

  • шаги процесса → сценарии (use case) и acceptance criteria
  • развилки → бизнес-правила в формате «если … то …»
  • таймауты и ожидания → НФТ и требования к асинхронности
  • ручные операции → требования к интерфейсу оператора и аудит-логам

    • Ссылка на спецификацию:

  • OMG BPMN Specification

    • UML: моделирование взаимодействий и поведения

    UML (Unified Modeling Language) — набор диаграмм для описания структуры и поведения системы.

    Важно: UML — это инструментарий, а не обязательная бюрократия. Middle-аналитик выбирает диаграммы по задаче.

    Какие UML-диаграммы чаще всего нужны системному аналитику

    Ниже — практичный минимум.

    #### Диаграмма вариантов использования

    Use case помогает зафиксировать:

  • акторов (кто инициирует)
  • цели взаимодействия
  • границу системы на уровне «что система делает для акторов»

    • Она хороша как вход в обсуждение, но редко бывает достаточной для разработки без дополнительных сценариев.

    #### Диаграмма последовательностей

    Диаграмма последовательностей (sequence diagram) показывает, кто с кем и в каком порядке обменивается сообщениями.

    Полезна, когда:

  • есть интеграции между сервисами
  • важны альтернативные ветки и ошибки
  • нужно договориться о синхронности и ответах

    • !Sequence диаграмма помогает увидеть порядок вызовов и обработку ошибок

    Как превращать sequence в требования:

  • каждый вызов → требования к API (метод, поля, коды ошибок)
  • каждая альтернативная ветка → негативные сценарии и критерии приёмки
  • точки сохранения в БД → требования к данным и аудиту

    • Ссылка на спецификацию:

  • OMG UML Specification

    • #### Диаграмма состояний

    Диаграмма состояний (state machine) полезна, если у сущности есть жизненный цикл со статусами, правилами переходов и ограничениями.

    Примеры сущностей:

  • заказ: создан → оплачен → собран → доставлен → закрыт
  • заявка: черновик → на проверке → отклонена или одобрена

    • State diagram помогает убрать двусмысленность:

  • какие статусы существуют
  • какие события переводят статус
  • какие переходы запрещены
  • что происходит при отмене и возврате

    • Эту же информацию можно оформить таблицей, если диаграмма не требуется.

    #### Диаграмма классов как доменная схема

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

    Обычно в ней важны:

  • сущности и их атрибуты
  • связи и кратность (один-ко-многим)
  • ключевые ограничения

    • Доменная модель: общий язык про данные и правила

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

    Доменная модель — согласованное описание ключевых понятий домена:

  • сущности: Заказ, Клиент, Платёж, Доставка
  • атрибуты: сумма, статус, адрес
  • отношения: у заказа может быть несколько позиций
  • правила: «нельзя отправить заказ без оплаты», «адрес должен быть валидирован»

    • Зачем она нужна:

  • даёт единый словарь для команды и стейкхолдеров
  • снижает риск «одинаковых терминов с разным смыслом»
  • служит опорой для API, БД, отчётности и тестов

    • Как строить доменную модель на практике

  • Соберите термины из интервью и воркшопов.
  • Сведите синонимы и зафиксируйте определения в глоссарии.
  • Выделите сущности и их атрибуты.
  • Проверьте, что сущности отражают реальные объекты и действия.
  • Пройдитесь по сценариям и убедитесь, что в модели есть все нужные данные.

    • !Доменная модель фиксирует сущности, связи и ключевые правила

    Типовая ошибка в доменной модели

    Ошибка: моделировать поля «как в UI» или «как в текущей таблице БД», не проверяя смысл.

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

    Как выбирать нотацию: BPMN или UML или доменная модель

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

    | Вопрос | Подходит лучше всего | Типичный результат | |---|---|---| | Кто участвует и где граница системы? | Контекст (C4) | список акторов, интеграции, потоки данных | | Как работает бизнес-процесс между ролями? | BPMN | схема процесса с исключениями и ответственностью | | Какой порядок вызовов между компонентами/сервисами? | UML sequence | контрактные точки, ошибки, синхронность | | Какие статусы и переходы у сущности? | UML state machine или таблица статусов | правила переходов и запреты | | Какие сущности, атрибуты и связи в домене? | Доменная модель (ER/UML class) | словарь данных и правила целостности |

    Практика: часто нужно комбинировать. Например:

  • контекст → чтобы согласовать границу
  • BPMN → чтобы согласовать процесс
  • доменная модель → чтобы договориться о данных
  • sequence → чтобы уточнить интеграции и API

    • Качество моделей: чек-лист Middle-уровня

    Используйте как критерии ревью со стороны команды.

  • Однозначность: нет мест, которые можно понять по-разному.
  • Трассируемость: понятно, какие требования поддерживает модель и где это описано.
  • Уровень детализации: схема отвечает на нужный вопрос и не уходит в «код».
  • Исключения: отражены ошибки, отмены, таймауты, ручные обходы.
  • Ответственность: видно, кто выполняет шаг и кто владелец данных/решения.
  • Согласованность терминов: названия сущностей и статусов совпадают между моделями, требованиями и API.

    • Как проводить моделирование со стейкхолдерами

    Модели — это ещё и инструмент коммуникации.

    Практика проведения сессии по моделированию

  • Начните с цели: какую неопределённость снимаем этой схемой.
  • Покажите границу системы и участников.
  • Пройдитесь по сценарию «счастливого пути».
  • Затем добавьте исключения и спорные места.
  • В конце зафиксируйте:
    • - что согласовали - что осталось открытым - кто подтверждает итог

    Хороший тон Middle-аналитика: не просить «посмотрите схемку», а просить подтвердить конкретные утверждения, например:

  • «Статусов заказа будет 6, переход из A в B возможен только при условии X»
  • «Провайдер должен возвращать уникальный идентификатор платежа, мы сохраняем его и используем для идемпотентности»

    • Как поддерживать модели живыми

    Чтобы модели не умерли после первой демонстрации:

  • храните их рядом с требованиями (в той же базе знаний)
  • добавляйте ссылку на модель из user story/спецификации
  • делайте минимально достаточный уровень детализации
  • ведите журнал изменений: что поменялось и почему

    • Реалистичная цель: модели должны быть достаточно актуальны, чтобы ими пользоваться, а не идеально отражать всё.

    Итог

    Моделирование на уровне Middle — это способность быстро и точно зафиксировать:

  • границы системы и внешние взаимодействия
  • процессы и ответственность ролей (BPMN)
  • сценарии и интеграции (UML sequence)
  • жизненные циклы сущностей (state)
  • доменные данные и правила (доменная модель)

    • В следующей логике курса эти модели станут опорой для формализации требований: сценариев, критериев приёмки, моделей данных и контрактов API.

    Ссылки для углубления:

  • OMG BPMN Specification
  • OMG UML Specification
  • C4 Model

    • 4. Артефакты аналитика: SRS, user stories, критерии приёмки, backlog

    Артефакты аналитика: SRS, user stories, критерии приёмки, backlog

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

    Артефакт системного аналитика — это управляемый источник правды, который:

  • снижает двусмысленность
  • делает объём работ прозрачным
  • позволяет согласовывать решения и фиксировать изменения
  • обеспечивает проверяемость (что значит сделано)

    • В этой статье разберём четыре ключевых элемента практики Middle-аналитика:

  • SRS (спецификация требований)
  • user stories (пользовательские истории)
  • критерии приёмки (acceptance criteria)
  • backlog (бэклог)

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

    !Как требования превращаются в набор артефактов и попадают в разработку

    Термины, которые нужны дальше

  • SRS (Software Requirements Specification) — документ (или набор страниц), где требования оформлены структурно и полно для реализации и тестирования.
  • User story — короткое описание потребности пользователя или стейкхолдера, обычно в формате “кто/что/зачем”.
  • Критерии приёмки — проверяемые условия, при которых задача считается выполненной.
  • Backlog — упорядоченный список работ (элементов), из которого команда берёт задачи в работу. В Agile-контексте чаще всего это product backlog.
  • Трассируемость — связи между целью, требованиями, моделями, задачами и проверками, чтобы понимать, зачем это делаем и как проверяем.

    • Как выбрать артефакт под задачу

    Одна из ошибок начинающих аналитиков — пытаться вести всё в одном формате всегда. У Middle-уровня ожидают осознанного выбора.

    Ниже — практичная карта.

    | Ситуация | Что использовать как основной формат | Почему | |---|---|---| | Много систем, интеграций, НФТ, критичная точность | SRS + модели | Удобно структурировать и согласовать целостно | | Работа итерациями, нужен управляемый объём на спринт/релиз | Backlog + user stories + criteria | Команда планирует и поставляет ценность частями | | Нужно быстро договориться “что именно делаем” | User story + criteria | Минимально достаточный формат для старта | | Нужно снять двусмысленность в “готово” | Критерии приёмки | Делают задачу тестируемой и управляемой |

    Важно: часто одновременно существуют и SRS, и backlog. Вопрос не в “или”, а в том, что является главным источником правды и как вы избегаете расхождений.

    SRS: спецификация требований как управляемый документ

    Когда SRS действительно нужен

    SRS полезен, когда цена ошибки высока и “карточки в трекере” недостаточно:

  • сложные интеграции и много внешних зависимостей
  • существенные нефункциональные требования (производительность, безопасность, аудит)
  • несколько команд и нужна единая договорённость
  • миграции данных и критичные бизнес-правила
  • регуляторные и комплаенс-ограничения

    • SRS не обязан быть одним файлом. На практике это часто набор разделов в базе знаний (Confluence/Notion), но со строгой структурой.

    Минимальная структура SRS для Middle-уровня

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

  • Контекст и цель
  • Границы системы (что внутри, что снаружи)
  • Термины и глоссарий
  • Стейкхолдеры и роли
  • Функциональные требования
  • Сценарии и исключения (включая ошибки)
  • Данные (сущности, атрибуты, валидации)
  • Интеграции (контракты, события, ошибки, идемпотентность при необходимости)
  • Нефункциональные требования
  • Ограничения и допущения
  • Критерии приёмки и подход к приёмке
  • Открытые вопросы, риски, решения (decision log)

    • Связь с предыдущей темой про моделирование: SRS становится местом, где вы даёте ссылки на контекстную диаграмму, BPMN, доменную модель, sequence. Модели не заменяют требования, но служат опорой.

    Как должен выглядеть пункт “требование”

    Требование должно быть:

  • однозначным
  • проверяемым
  • привязанным к источнику или решению

    • Удобный формат записи (не единственный):

  • ID: FR-01
  • Формулировка: “Система должна …”
  • Пояснение: зачем и для кого
  • Правила и исключения: условия, ошибки, запреты
  • Связанные модели: ссылка на BPMN/sequence/модель данных
  • Критерии приёмки: список проверяемых условий

    • Типовые ошибки в SRS

  • смешивать требования и реализацию без необходимости (например, “в Redis хранить …”), когда достаточно описать поведение и НФТ
  • не фиксировать исключения и ошибки
  • нет глоссария, из-за чего термины плавают
  • SRS не версионируется и непонятно, что актуально

    • Полезная опора на стандарты: требования к качеству требований и структуре спецификаций описаны в ISO/IEC/IEEE 29148.

    User stories: как упаковать потребность в работу

    Что такое user story на практике

    User story — это единица ценности, которую можно запланировать, реализовать и проверить.

    Классический шаблон:

  • “Как роль, я хочу действие, чтобы ценность/результат.”

    • Пример:

  • “Как оператор поддержки, я хочу видеть историю статусов заказа, чтобы быстрее разбирать обращения клиента.”

    • Важное ограничение: user story сама по себе почти никогда не достаточна для реализации. Её “доводят до готовности” через критерии приёмки, ссылки на модели, правила и данные.

    Справка: базовое описание подхода есть у Atlassian про user stories.

    Как делать user stories “уровня Middle”

    Middle-качество проявляется в том, что история:

  • не слишком большая (реалистично сделать за итерацию)
  • не теряет правила и исключения (они уходят в criteria)
  • имеет чёткие границы (что входит и что не входит)
  • трассируется к цели и моделям

    • Практичный приём: перед тем как писать историю, проговорите границу системы из предыдущей статьи.

    Плохой пример:

  • “Система возвращает деньги клиенту.”

    • Лучше:

  • “Как клиент, я хочу инициировать возврат, чтобы получить деньги обратно, если заказ отменён.”
  • “Система должна отправить запрос на возврат в платёжный провайдер и отобразить статус возврата.”

    • Так вы разделяете ответственность вашей системы и внешнего провайдера.

    Частая ошибка: превращать story в техническую задачу

    Технические работы бывают нужны, но user story должна описывать потребность. Если вам нужно завести техническую работу, делайте это явно (например, отдельный элемент backlog типа tech task), но не маскируйте под “как пользователь, я хочу обновить библиотеку”.

    Критерии приёмки: как сделать “готово” проверяемым

    Что такое критерии приёмки

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

    Они нужны, чтобы:

  • тестирование могло проверять без догадок
  • разработка понимала крайние случаи
  • заказчик понимал, что именно получит

    • Критерии приёмки часто пишут в формате списка “должно быть …”, но важно, чтобы это были проверяемые утверждения.

    Справка: краткое описание есть у Atlassian про acceptance criteria.

    Практичные правила хороших критериев

    Критерии приёмки должны:

  • быть конкретными и измеримыми там, где это нужно
  • включать “счастливый путь” и ошибки
  • проверять важные бизнес-правила
  • не зависеть от личного мнения (“удобно”, “красиво”), если это не формализовано

    • Если критерий звучит как “должно быть удобно”, это не критерий, пока вы не договорились, как проверяем удобство.

    Шаблон критериев приёмки для типовой user story

    Ниже — шаблон, который хорошо работает в продуктовой разработке.

  • Доступы и роли: кто может выполнить действие
  • Входные данные: обязательные поля, валидации
  • Основной сценарий: что происходит при успехе
  • Ошибки и исключения: что показываем/логируем/делаем при сбое
  • Данные и аудит: что сохраняем, какие статусы меняем
  • НФТ (если относится к задаче): время ответа, логирование, трассировка

    • Если вы используете сценарный формат, можно оформлять criteria как Given-When-Then, но не превращайте это в бюрократию. Цель — однозначность.

    Пример criteria (укороченный)

    User story: “Как клиент, я хочу отменить заказ до передачи в доставку, чтобы не получать ненужный товар.”

    Критерии приёмки:

  • Пользователь может отменить заказ только в статусе Создан или Оплачен
  • При отмене в статусе Оплачен система инициирует возврат через платёжного провайдера
  • Если платёжный провайдер недоступен, отмена фиксируется со статусом Возврат в обработке, а пользователю показывается сообщение о задержке
  • В историю заказа добавляется запись об отмене с временем и инициатором

    • Обратите внимание: тут есть статусы, внешняя интеграция и поведение при ошибке. Это как раз то, что чаще всего “забывают”, если ограничиться одной фразой.

    Backlog: как сделать объём работ управляемым

    Что такое backlog

    Backlog — это упорядоченный список элементов работы, который отражает договорённость “что будем делать” и “в каком порядке”.

    В контексте Scrum определение и базовые принципы зафиксированы в Scrum Guide 2020.

    Из чего состоит хороший backlog

    В реальности в backlog могут быть разные типы элементов:

  • user story
  • bug (дефект)
  • spike (исследование)
  • tech task (техническая задача)
  • enabler (подготовительная работа для возможности сделать фичу)

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

    Backlog как продолжение сбора требований и моделирования

    Связка выглядит так:

  • интервью и воркшопы дают факты и правила
  • модели (BPMN, доменная модель, sequence) подсвечивают пробелы
  • backlog превращает это в управляемые единицы работ

    • Middle-уровень — это когда вы умеете:

  • декомпозировать без потери смысла
  • выделить MVP и зависимости
  • провести команду к общему пониманию через backlog refinement (уточнение элементов)

    • !Как элементы проходят путь от запроса к готовности для разработки

    Definition of Ready и Definition of Done

    Чтобы backlog работал, команде полезны две договорённости.

  • Definition of Ready — критерии, по которым элемент можно брать в разработку.
  • Definition of Done — критерии, по которым элемент считается завершённым.

    • Пример Definition of Ready для user story:

  • сформулирована цель и ценность
  • понятны границы (in/out)
  • есть критерии приёмки
  • выявлены ключевые данные и интеграции
  • нет блокирующих открытых вопросов

    • Это напрямую связано с вашей ролью: аналитик помогает довести элементы до состояния ready.

    Как связать артефакты между собой

    Связность — одна из главных компетенций Middle-аналитика. Практичный минимум связей:

  • цель изменения → эпик или раздел SRS
  • эпик → набор user stories
  • user story → критерии приёмки
  • user story/SRS → ссылки на модели (контекст, BPMN, доменная модель, sequence)
  • требования → тесты (или хотя бы список проверок)

    • Если вы ведёте SRS и backlog параллельно, заранее договоритесь, что является “главнее”. Частая практика:

  • backlog — источник правды по составу работ и статусам
  • SRS — источник правды по сквозным правилам, данным, интеграциям, НФТ

    • Качество артефактов: чек-лист Middle

    Используйте это как критерии самопроверки и ревью с командой.

  • Однозначность: формулировки нельзя понять по-разному
  • Проверяемость: есть условия, которые можно проверить (вручную или тестами)
  • Полнота по рискам: учтены ошибки, таймауты, отсутствие данных, права доступа
  • Согласованность терминов: статусы, сущности, поля названы одинаково везде
  • Трассируемость: понятно, какая цель и какая модель стоят за задачей
  • Актуальность: понятно, где последняя версия и что изменилось

    • Коммуникация вокруг артефактов: часть soft skills

    Артефакты не “пишут в стол”. Их жизненный цикл — это коммуникация.

    Практики, которые ожидают от Middle:

  • фасилитировать refinement: вести обсуждение к решениям и фиксировать итоги
  • управлять ожиданиями через scope: что делаем в этой итерации, что позже
  • фиксировать решения: вести короткий decision log
  • работать с разногласиями: возвращать разговор к целям, рискам и ограничениям

    • Хороший индикатор зрелости: вы не просто “скинули ссылку на документ”, а задали конкретный запрос на подтверждение, например: “подтвердите, что отмена возможна только в статусах X и Y, а при статусе Z нужна заявка оператору”.

    Итог

    SRS, user stories, критерии приёмки и backlog — это взаимодополняющие способы сделать требования понятными, реализуемыми и проверяемыми.

  • SRS помогает держать целостность: правила, данные, интеграции, НФТ
  • user stories превращают потребности в управляемые единицы ценности
  • критерии приёмки делают “готово” конкретным
  • backlog обеспечивает планирование, приоритеты и прозрачный объём работ

    • В дальнейших темах курса эти артефакты станут основой для углубления в качество требований, работу с API/контрактами и управляемую приёмку.

    5. Технический фундамент: архитектура, API, интеграции, SQL и данные

    Технический фундамент: архитектура, API, интеграции, SQL и данные

    В предыдущих темах мы разобрали, как системный аналитик:

  • собирает требования у стейкхолдеров
  • переводит договорённости в модели (BPMN, UML, доменная модель, границы системы)
  • упаковывает результат в артефакты (SRS, user stories, критерии приёмки, backlog)

    • Теперь добавим технический фундамент, без которого Middle-аналитику сложно писать спецификации, которые реально можно реализовать и можно проверить: базовые принципы архитектуры, проектирование API и интеграций, понимание данных и практический SQL.

    Цель статьи: дать вам минимально достаточный “технический словарь” и рабочие чек-листы, чтобы:

  • задавать правильные вопросы разработке и архитекторам
  • фиксировать корректные требования к API и интеграциям
  • не забывать про данные, транзакции, ошибки, идемпотентность и качество данных

    • Какой технический уровень нужен Middle системному аналитику

    Middle-аналитик не обязан проектировать инфраструктуру и писать код, но должен:

  • понимать границы ответственности компонентов и внешних систем
  • уметь описать контракты (API, события, форматы данных) и поведение при сбоях
  • учитывать данные как основу требований: источники, владение, качество, миграции
  • говорить на одном языке с разработкой и тестированием, чтобы требования были однозначными

    • Архитектура для аналитика: что важно, а что лишнее

    Базовые термины

  • Компонент — часть системы, выполняющая выделенную ответственность (например, сервис заказов).
  • Интерфейс — договорённость о взаимодействии (API, событие, файл, очередь).
  • Контракт — точное описание запросов/ответов или сообщений: структура, коды ошибок, правила.
  • Зависимость — внешний компонент/система, без которой сценарий не завершится.
  • Нефункциональные требования (НФТ) — производительность, надёжность, безопасность, аудит и т.д.

    • Мышление через C4: контекст и контейнеры

    В теме про моделирование мы уже фиксировали границу системы. Для технического разговора удобно использовать идеи модели C4:

  • Контекст отвечает на вопрос: кто взаимодействует с системой и какие внешние зависимости есть.
  • Контейнеры отвечают на вопрос: из каких крупных частей состоит решение (приложение, сервисы, БД, брокер сообщений) и как они взаимодействуют.

    • !Упрощённая карта системы, чтобы договориться о границе, контейнерах и интеграциях

    Полезная ссылка для закрепления подхода:

  • The C4 model for visualising software architecture

    • Как аналитику проверять архитектурную адекватность требований

    Если вы описали фичу, но не проверили, как она “вяжется” с архитектурой, часто всплывают сюрпризы: нет нужных данных, внешний сервис не поддерживает операцию, невозможна транзакционность.

    Практичный набор вопросов:

  • Где будет храниться источник правды для ключевых сущностей (заказ, платёж, доставка)?
  • Какие внешние системы участвуют и кто владелец интеграции?
  • Взаимодействие синхронное или асинхронное?
  • Что происходит при недоступности внешней системы?
  • Нужны ли ретраи, дедупликация, идемпотентность?
  • Какие логи и аудит нужны для разборов инцидентов?

    • API как контракт: что обязан уметь системный аналитик

    Что такое API (в контексте аналитики)

    API — это контракт взаимодействия между клиентом и системой или между системами. На практике чаще всего вы будете описывать HTTP API (REST-подобные) и/или события.

    Ваша задача как аналитика: сделать контракт однозначным и тестируемым.

    HTTP основы, которые нужно знать

    В HTTP есть методы, статусы и семантика. Полезно опираться на стандарт:

  • RFC 9110: HTTP Semantics

    • Ключевые идеи:

  • GET — получение данных.
  • POST — создание ресурса или запуск операции.
  • PUT — полная замена ресурса по идентификатору.
  • PATCH — частичное обновление.
  • DELETE — удаление.

    • Важно для требований:

  • Некоторые методы по семантике идемпотентны (повтор запроса даёт тот же эффект). Это критично при ретраях.
  • Статусы ответа должны быть согласованы и описаны.

    • Идемпотентность: почему это важно и как фиксировать в требованиях

    Идемпотентность — свойство операции, при котором повторный вызов не приводит к “двойному” эффекту.

    Пример риска без идемпотентности:

  • клиент нажал “Оплатить”, сеть моргнула, запрос повторили
  • платёж создался дважды

    • Что фиксировать в спецификации:

  • какие операции должны быть идемпотентны
  • за счёт чего достигается идемпотентность (например, Idempotency-Key или уникальный ключ операции)
  • что считать повтором (временное окно, одинаковое тело запроса, одинаковый ключ)

    • Ошибки API: минимальный стандарт качества

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

    Практичный вариант для HTTP API:

  • единый формат тела ошибки
  • читаемые коды ошибок
  • различение ошибок валидации, прав доступа, конфликтов, ошибок внешних зависимостей

    • Существует распространённый формат описания ошибок:

  • RFC 7807: Problem Details for HTTP APIs

    • Что полезно зафиксировать:

  • список кодов ошибок и когда они возвращаются
  • структура ответа ошибки
  • правила локализации сообщений (если нужно)

    • Версионирование и совместимость

    API почти неизбежно меняется. В требованиях полезно явно описать:

  • что считается обратно совместимым изменением
  • как вводится новая версия (например, /v2/... или заголовок)
  • сколько времени поддерживаются старые версии

    • Как описывать API в артефактах

    На практике лучше всего работает комбинация:

  • краткое текстовое описание сценариев и правил в SRS или в story
  • формальный контракт в OpenAPI

    • Официальная спецификация:

  • OpenAPI Specification

    • Минимум, который аналитик должен уметь читать и обсуждать:

  • эндпоинты и методы
  • схемы запросов/ответов
  • статусы и ошибки
  • примеры

    • Интеграции: синхронные, асинхронные, надёжность и последствия

    Типы интеграций

    Синхронная интеграция (часто HTTP):

  • мы отправили запрос
  • ждём ответ
  • пользователь или процесс блокируется ожиданием

    • Асинхронная интеграция (очереди/события):

  • мы публикуем сообщение или событие
  • обработка происходит позже
  • система должна уметь жить с “не сразу”

    • Выбор типа интеграции почти всегда связан с НФТ:

  • требования к времени ответа
  • допустимость задержки
  • надёжность и обработка пиков

    • Что аналитику обязательно фиксировать про интеграцию

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

  • кто инициатор и кто получатель
  • что является “успехом” и какие статусы возможны
  • какие ошибки бывают и как их обрабатываем
  • есть ли ретраи и кто их делает
  • нужна ли дедупликация (защита от повторной доставки)
  • что логируем для расследований

    • Синхронный сценарий: полезная UML sequence как артефакт

    !Порядок вызовов и точки, где нужны статусы, ошибки и правила

    Что это даёт аналитику:

  • вы видите, где возможен таймаут
  • понимаете, какие статусы нужны сущности
  • можете явно сформулировать критерии приёмки на ошибки внешних сервисов

    • Асинхронный сценарий: очереди, ретраи, DLQ

    Асинхронность добавляет надёжность и масштабируемость, но приносит новые требования.

    Ключевые понятия:

  • At-least-once delivery — сообщение может прийти повторно, значит нужна дедупликация.
  • DLQ (dead-letter queue) — “кладбище” сообщений, которые не удалось обработать.
  • Outbox — паттерн, уменьшающий риск расхождения между записью в БД и публикацией события.

    • !Как обеспечить надёжную доставку и обработку событий

    Что важно для требований:

  • как система ведёт себя при временных сбоях
  • какие статусы отображаем пользователю, если операция “в обработке”
  • кто и как мониторит DLQ

    • Данные: доменная модель, источник правды и качество данных

    В теме про моделирование мы строили доменную модель. Здесь добавим техническую прагматику: как данные живут в системе.

    Сущности и их жизненный цикл

    Для ключевых сущностей почти всегда нужно явно определить:

  • идентификатор (что является уникальным ключом)
  • статусы и допустимые переходы
  • обязательные атрибуты и валидации
  • связи между сущностями

    • Это напрямую связывает:

  • доменную модель
  • сценарии и критерии приёмки
  • таблицы БД и контракты API

    • Источник правды (system of record)

    Источник правды — система, где данные считаются наиболее корректными и “официальными”.

    Пример:

  • статусы платежа “официально” приходят от платёжного провайдера
  • но в нашей системе хранится копия для отображения и процессов

    • Что важно зафиксировать:

  • какие поля мы считаем authoritative (истинными)
  • как часто и по каким событиям синхронизируемся
  • что делаем при расхождении

    • Качество данных и ограничения

    Качество данных — это не “техническая деталь”, а часто бизнес-риск.

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

  • уникальность (нет дублей)
  • полнота (обязательные поля)
  • согласованность (статус заказа согласован со статусом оплаты)
  • актуальность (как быстро данные обновляются)

    • Если требование связано с метриками качества, оно должно быть проверяемым. Например:

  • “адрес доставки должен проходить валидацию по справочнику” вместо “адрес должен быть корректным”

    • Персональные данные и доступы

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

  • роли и права доступа
  • аудит действий (кто и когда смотрел/менял)
  • маскирование данных в логах
  • сроки хранения

    • Здесь нет универсального стандарта для всех стран и компаний, поэтому ключевой навык аналитика — выявить ограничения у ответственных стейкхолдеров и зафиксировать их как НФТ.

    SQL для системного аналитика: минимум, который даёт преимущество

    SQL аналитику нужен не для “писать как разработчик”, а чтобы:

  • проверять гипотезы по данным (например, сколько заказов в статусе “зависло”)
  • понимать, какие данные реально есть и какого они качества
  • разговаривать с командой на языке таблиц, ключей, связей, транзакций

    • Термины

  • Таблица — набор строк (записей) и колонок (полей).
  • Первичный ключ (PK) — уникальный идентификатор строки.
  • Внешний ключ (FK) — ссылка на запись в другой таблице.
  • Индекс — структура для ускорения поиска (почти всегда компромисс между скоростью чтения и стоимостью записи).
  • Транзакция — группа операций, выполняемая как единое целое.

    • Базовые запросы, которые стоит уметь читать

  • SELECT ... WHERE ... для фильтрации
  • JOIN для связей между таблицами
  • GROUP BY для агрегирования

    • Пример запроса на проверку “зависших” заказов (условный пример):

    Что тут важно понимать:

  • мы группируем заказы по status
  • считаем количество в каждом статусе
  • ограничиваем периодом 7 дней

    • Транзакции и гонки: что важно аналитику

    Когда в требованиях есть “нельзя допустить двойное списание” или “нельзя создать два активных договора”, это часто означает:

  • нужны уникальные ограничения
  • нужна корректная транзакционная логика
  • нужно продумать конкурентные сценарии

    • Аналитику не нужно выбирать уровень изоляции транзакций, но нужно уметь задать вопросы:

  • что будет, если два запроса придут одновременно
  • какое действие считается “первым”
  • как система предотвращает дубли

    • Для справки по транзакциям (если вы работаете с PostgreSQL):

  • PostgreSQL Documentation: Transactions

    • Как связывать технический фундамент с артефактами аналитика

    Чтобы знания из этой статьи не остались “теорией”, привяжем их к тому, что вы уже делали: SRS, user stories, критерии приёмки, модели.

    Что добавляется в SRS

  • раздел Интеграции: кто с кем, протокол, форматы, ошибки, ретраи, идемпотентность
  • раздел Данные: сущности, атрибуты, ограничения, статусы
  • раздел НФТ: SLA/SLO (если применимо), логирование, аудит, безопасность
  • Decision log: почему выбран синхронный или асинхронный подход, какие допущения

    • Что добавляется к user story и критериям приёмки

  • роли и доступы (кто может)
  • поведение при ошибках внешних систем
  • требования к идемпотентности
  • изменения статусов и записи в аудит
  • ссылки на модели (контекст, BPMN, sequence, доменную модель)

    • Как это помогает soft skills

    Технический фундамент улучшает коммуникацию:

  • вы задаёте разработке вопросы про последствия, а не “как сделать”
  • вы быстрее находите риски и зависимые команды
  • вы аргументированно обсуждаете компромиссы: скорость, надёжность, стоимость

    • Чек-листы Middle-аналитика

    Чек-лист описания API

  • эндпоинт, метод, назначение
  • схема запроса и ответа (поля, типы, обязательность)
  • статусы HTTP и структура ошибок
  • правила валидации
  • авторизация и права доступа
  • примеры запросов и ответов
  • идемпотентность (если нужна)
  • версионирование и совместимость

    • Чек-лист описания интеграции

  • инициатор и получатель
  • синхронно или асинхронно и почему
  • таймауты и что считаем “недоступностью”
  • ретраи: кто делает, сколько попыток
  • дедупликация: как защищаемся от повторов
  • наблюдаемость: логи, корреляционные идентификаторы, метрики
  • сценарии деградации: что показываем пользователю, какие статусы ставим

    • Чек-лист по данным

  • сущности и идентификаторы
  • статусы и переходы
  • обязательные поля и валидации
  • уникальности и запреты
  • источники правды и синхронизация
  • аудит и безопасность данных

    • Итог

    Технический фундамент Middle системного аналитика — это способность связывать требования с реальностью исполнения:

  • архитектурно понимать границы системы и зависимости
  • описывать API как контракт с ошибками, версиями и идемпотентностью
  • проектно учитывать интеграции, ретраи, дедупликацию и наблюдаемость
  • мыслить данными: сущности, статусы, качество, источник правды
  • уверенно читать и использовать SQL для проверки гипотез и контроля качества данных

    • Этот набор навыков делает ваши артефакты (SRS, stories, criteria, backlog) не просто “текстами”, а инструкцией, по которой команда может предсказуемо реализовать и протестировать изменения.

    6. Soft skills: коммуникация, фасилитация, презентации, конфликт-менеджмент

    Soft skills: коммуникация, фасилитация, презентации, конфликт-менеджмент

    В предыдущих темах курса мы построили техническую опору работы системного аналитика: сбор требований, моделирование, артефакты (SRS, user stories, критерии приёмки, backlog), базовое понимание API, интеграций и данных. Но в реальной работе Middle-аналитика качество результата часто определяется не тем, знаете ли вы BPMN или OpenAPI, а тем, можете ли вы договориться.

    Soft skills для системного аналитика — это набор практик, которые превращают ваши знания в согласованное решение:

  • вы получаете информацию от людей с разными целями и словарём
  • удерживаете обсуждения в рамках цели и времени
  • фиксируете решения так, чтобы команда одинаково их понимала
  • снижаете напряжение и разрешаете противоречия требований

    • Эта статья даст рабочие подходы и шаблоны для четырёх ключевых областей:

  • коммуникация
  • фасилитация встреч
  • презентации решений
  • конфликт-менеджмент

    • !Карта коммуникаций системного аналитика и типов информации

    Коммуникация системного аналитика: ясность, контекст, управляемость

    Коммуникация в аналитике — это управляемый обмен смыслами. Ваша цель не «поговорить», а привести группу к состоянию:

  • мы одинаково понимаем проблему и цель
  • мы договорились о правилах и границах
  • мы знаем, что делать дальше и кто за что отвечает

    • Кому вы объясняете одно и то же по-разному

    Одна и та же тема должна звучать по-разному для разных аудиторий:

  • бизнесу важны ценность, риски, влияние на процесс, приоритеты
  • разработке важны контракты, крайние случаи, данные, интеграции, ограничения
  • тестированию важны проверяемость, сценарии, негативные кейсы, критерии приёмки
  • поддержке важны диагностика, логирование, статусы, сценарии деградации

    • Практичный маркер Middle-уровня: вы умеете переводить между аудиториями, не теряя точность.

    Структура сообщения: что сказать, чтобы вас поняли с первого раза

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

  • Цель: что мы хотим получить
  • Контекст: почему это важно и какие есть ограничения
  • Суть: правило, решение или вопрос
  • Запрос: что нужно от собеседника (подтвердить, выбрать вариант, дать данные)
  • Дедлайн: когда нужно, чтобы не блокировать команду

    • Пример формулировки для асинхронного согласования:

  • Цель: зафиксировать правила отмены заказа
  • Контекст: отмена влияет на интеграцию с оплатой и статусы
  • Суть: отмена доступна только в статусах Создан и Оплачен, при Оплачен инициируем возврат
  • Запрос: подтвердите правила или укажите исключения
  • Срок: до четверга 15:00, чтобы успеть в refinement

    • Активное слушание как инструмент извлечения требований

    Активное слушание — это набор приёмов, которые помогают:

  • не пропустить смысл за эмоциями и терминологией
  • проверить, что вы поняли правильно
  • мягко вернуть разговор к фактам и правилам

    • Практики:

  • перефразирование: «Правильно ли я понял, что…»
  • уточнение терминов: «Что вы называете “проведённым платежом” — какой статус считается истиной?»
  • запрос примеров: «Можете привести последний реальный кейс?»

    • Справка по активному слушанию: Active listening

    Письменная коммуникация: ваши артефакты читают как контракт

    В предыдущих статьях мы обсуждали, что артефакты аналитика — это источник правды. Значит, письменная коммуникация должна быть:

  • однозначной
  • проверяемой
  • управляемой по изменениям

    • Практика, которая резко повышает качество взаимодействия: писать не «простыни», а точечные запросы на подтверждение.

    Вместо:

  • «Посмотрите документ, всё ли ок?»

    • Лучше:

  • «Подтвердите, что статусов заказа будет 6 (см. таблицу статусов).»
  • «Подтвердите, что отмена в статусе Доставляется невозможна.»
  • «Ответьте, что показываем пользователю при таймауте платёжного провайдера.»

    • Фасилитация: как проводить встречи, которые дают решения

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

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

    Результат встречи: что именно должно появиться

    Перед любой встречей зафиксируйте результат в наблюдаемой форме. Примеры корректных результатов:

  • список бизнес-правил в формате «если … то …»
  • согласованный список статусов и переходов сущности
  • выбранный вариант решения и причины выбора (decision log)
  • список открытых вопросов с ответственными и сроками

    • Если результат нельзя показать как артефакт или запись решения, встреча почти наверняка расползётся.

    Минимальный набор ролей на встрече

  • Фасилитатор: держит цель, таймбокс и порядок обсуждения
  • Владелец решения: человек, который имеет право принять решение (или явно согласовать с тем, кто имеет)
  • Эксперты: дают факты и ограничения
  • Секретарь: фиксирует решения и действия (часто это аналитик)

    • Сценарий фасилитации: от цели к решениям

    Ниже — универсальный сценарий, который подходит и для воркшопа требований, и для обсуждения интеграции:

  • Открытие: цель, границы, ожидаемый результат
  • Общий контекст: что уже известно, какие ограничения
  • Проход по «счастливому пути» (основной сценарий)
  • Исключения и ошибки: что может пойти не так
  • Разногласия: фиксируем варианты и критерии выбора
  • Решения: что приняли, что отложили
  • Завершение: action items, сроки, ответственные

    • !Процесс фасилитации встречи от цели к решению

    Техники, которые особенно полезны аналитику

  • Таймбокс: ограничение времени на пункт повестки, чтобы обсуждение не захватило встречу
  • Parking lot: список тем, которые важны, но не входят в цель текущей встречи
  • Раунд вопросов: по очереди собрать мнения ключевых ролей, чтобы не доминировал один голос
  • Критерии выбора: договориться, по каким критериям выбираем вариант (риск, стоимость, сроки, влияние на клиента, регуляторика)

    • Дополнительные практики фасилитации командных обсуждений: Atlassian Team Playbook

    Как фиксировать итоги: решения и действия

    Вам нужны два простых артефакта:

  • Decision log: что решили и почему
  • Action items: что делаем дальше

    • Шаблон записи решения:

  • Контекст: о чём был выбор
  • Решение: что выбрали
  • Причина: почему
  • Последствия: что меняется (данные, интеграции, сроки, риски)
  • Дата и участники

    • Шаблон action item:

  • Действие
  • Ответственный
  • Срок
  • Зависимости

    • Презентации: как защищать решения и доносить сложное

    Презентация для системного аналитика — это не «слайды». Это способ быстро синхронизировать понимание и получить согласование.

    Типовые ситуации:

  • защита требований или SRS перед стейкхолдерами
  • демо сценариев и правил перед бизнесом
  • обсуждение интеграций и контрактов с разработкой/архитекторами
  • согласование scope релиза и компромиссов

    • Структура презентации решения

    Практичная структура, которая работает почти всегда:

  • Цель: какую проблему решаем и как измерим успех
  • Контекст: что есть сейчас и почему это не подходит
  • Варианты: 2–3 опции (если выбор действительно есть)
  • Рекомендация: что предлагаем
  • Последствия: риски, ограничения, зависимые команды, стоимость изменений
  • Следующие шаги: что нужно согласовать, кто делает, сроки

    • Если вы пропускаете пункт про последствия, вы часто получаете «согласование без понимания», которое потом ломается при реализации.

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

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

    Справка: Minto Pyramid Principle

    Пример:

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

    • Как отвечать на вопросы без ухода в спор

    Полезная техника: отделять вопрос на факт, интерпретацию и решение.

  • Факт: «Провайдер отвечает до 10 секунд в пике.»
  • Интерпретация: «Это риск для UX и таймаутов фронта.»
  • Решение: «Нужна асинхронная обработка и статус “в обработке”.»

    • Так вы удерживаете разговор в конструктиве и снижаете эмоциональную часть.

    Конфликт-менеджмент: как разруливать противоречия требований

    Конфликт в работе аналитика — нормален. Он возникает потому, что разные стейкхолдеры оптимизируют разные метрики:

  • бизнес хочет быстрее и больше фич
  • безопасность хочет снизить риски
  • поддержка хочет меньше инцидентов
  • разработка хочет управляемую сложность

    • Ваша задача — не «победить» в споре, а привести к решению, которое учитывает цели и ограничения.

    Виды конфликтов, которые вы будете встречать

  • конфликт целей: «быстро вывести» против «сделать надёжно»
  • конфликт правил: разные подразделения по-разному трактуют процесс
  • конфликт границ: что входит в релиз, а что нет
  • конфликт ответственности: кто владелец данных, кто чинит инцидент

    • Позиции и интересы: базовый навык переговоров

    Часто люди озвучивают позицию («хочу так»), но за ней стоит интерес («мне важно, чтобы…»).

    Пример:

  • Позиция: «Нельзя показывать эти данные в интерфейсе.»
  • Интерес: «Есть риск утечки персональных данных и штрафов.»

    • Когда вы выясняете интерес, появляются варианты:

  • маскирование
  • разграничение ролей
  • аудит доступа
  • отдельный защищённый контур

    • Классическая рамка переговоров: отделять людей от проблемы и обсуждать интересы, а не позиции. Справка: Getting to Yes

    Деэскалация: как снизить напряжение

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

  • «Давайте зафиксируем, в чём именно разногласие: правило, термин или приоритет.»
  • «Правильно ли я понял, что риск для вас в …? Давайте запишем риск и варианты контроля.»
  • «Предлагаю сравнить варианты по критериям: влияние на клиента, риск, стоимость, сроки.»

    • Важный приём: переводить эмоции в наблюдаемые утверждения (правила, риски, ограничения), которые можно записать.

    Конфликт как задача выбора: матрица вариантов

    Когда есть спор, полезно за 10–15 минут собрать таблицу вариантов. Это снижает «борьбу мнений» и делает обсуждение управляемым.

    | Вариант | Плюсы | Минусы | Риски | Как контролируем | |---|---|---|---|---| | A | | | | | | B | | | | | | C | | | | |

    Затем договоритесь, кто принимает решение и по каким критериям.

    Стили поведения в конфликте: осознанный выбор

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

    Справка: Thomas–Kilmann Conflict Mode Instrument

    Когда нужно эскалировать

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

    Эскалируйте, если:

  • нет владельца решения
  • конфликт блокирует команду и сроки
  • решение влияет на безопасность, деньги или регуляторику
  • стороны не принимают общие критерии выбора

    • Как эскалировать корректно (и профессионально):

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

    • Как soft skills связываются с hard skills из предыдущих тем

    Soft skills не существуют отдельно от артефактов и моделей, которые вы делаете.

    Практичные связки:

  • фасилитация → качественный сбор требований → меньше дыр в SRS и критериях приёмки
  • презентация → быстрое согласование моделей (BPMN, sequence, доменная модель) → меньше переработок
  • конфликт-менеджмент → управляемый scope и компромиссы → устойчивый backlog и реалистичный MVP
  • коммуникация → единые термины и правила → меньше дефектов из-за «поняли по-разному»

    • Если упростить: hard skills дают вам что писать, soft skills дают как сделать так, чтобы написанное стало реальностью.

    Итог

    Middle системный аналитик отличается тем, что он управляет не только требованиями, но и взаимодействием вокруг требований.

  • Коммуникация: ясные сообщения, общий контекст, проверка понимания
  • Фасилитация: встречи с результатом, таймбокс, решения и действия
  • Презентации: структура «вывод → обоснование», обсуждение последствий
  • Конфликт-менеджмент: интересы вместо позиций, матрица вариантов, корректная эскалация

    • Эти навыки делают ваши артефакты (SRS, user stories, criteria, backlog) живыми: ими пользуются, им доверяют, по ним реализуют.

    7. Трудоустройство на Middle: портфолио, кейсы, резюме, интервью, рост

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

    К этому моменту курса у вас уже есть «производственная база» системного аналитика:

  • как собирать требования (интервью, воркшопы, стейкхолдеры)
  • как моделировать (BPMN, UML, доменная модель, границы системы)
  • как оформлять артефакты (SRS, user stories, критерии приёмки, backlog)
  • какой нужен технический фундамент (API, интеграции, данные, SQL)
  • какие soft skills делают всё это применимым (коммуникация, фасилитация, презентации, конфликт-менеджмент)

    • Эта статья — про то, как «упаковать» всё перечисленное в трудоустройство на Middle: собрать портфолио, подготовить кейсы, написать резюме, пройти интервью и заложить траекторию роста.

    !Воронка трудоустройства и точки, где оценивают Middle-компетенции

    Что на самом деле проверяют на Middle

    На Middle позицию обычно берут не «за знание нотаций», а за способность:

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

    • Важно: рекрутер и руководитель смотрят на сигналы.

  • Резюме и портфолио дают сигнал «я уже делал похожее и умею оформлять».
  • Интервью дают сигнал «я могу повторить это вживую и объяснить ход мысли».

    • Портфолио Middle системного аналитика

    Почему портфолио решает

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

  • у вас мало релевантного опыта в названии должности
  • опыт есть, но проекты под NDA и нельзя показывать исходники
  • вы хотите перейти в другой домен или тип компании

    • Правило: портфолио должно показывать мышление и качество постановки, а не «красивый документ».

    Что включать в портфолио

    Оптимальный формат портфолио — 2–3 кейса, каждый из которых представляет законченный пакет артефактов.

    Требование к кейсу: в нём должны быть и hard, и soft составляющие.

    | Что показать | Какой артефакт из курса подходит | Что это доказывает на Middle | |---|---|---| | Граница системы и внешние зависимости | Контекст (C4-стиль), список интеграций | Вы не смешиваете ответственность систем и понимаете impact | | Процесс и роли | BPMN «as-is / to-be» | Умеете работать с бизнес-процессом и исключениями | | Сценарии и крайние случаи | Use case, acceptance criteria, негативные сценарии | Делаете требования тестируемыми | | Данные и правила | Доменная модель/ER, таблица статусов, словарь данных | Понимаете источник правды и целостность | | Интеграции и API | UML sequence, OpenAPI-черновик, таблица ошибок | Умеете описывать контракты и сбои | | Управляемость решений | Decision log, список assumptions/risks, changelog | Умеете фиксировать изменения и договариваться |

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

  • The C4 model for visualising software architecture
  • OpenAPI Specification
  • RFC 7807: Problem Details for HTTP APIs

    • Один «учебный» кейс, который выглядит как реальный

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

    Примеры тем:

  • отмена заказа и возврат денег (интеграция с платёжным провайдером)
  • регистрация и KYC-проверка (комплаенс, статусы, отказ)
  • запись к врачу (слоты, конкуренция за ресурс, уведомления)
  • выдача кредита (скоринг, решения, журналирование)

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

    Структура страницы кейса в портфолио

    Сделайте каждый кейс читаемым за 5–7 минут.

  • Контекст: домен, цель изменения, метрика успеха
  • Граница системы: что внутри, что снаружи, участники
  • Топ-правила и ограничения: 5–10 ключевых утверждений
  • Модели: контекст, BPMN, доменная модель, sequence (ссылки)
  • Требования: 5–15 требований или набор user stories с criteria
  • API и ошибки: 2–4 эндпоинта/события, коды ошибок, идемпотентность где нужно
  • НФТ: производительность, надёжность, аудит, безопасность (только релевантное)
  • Риски и решения: decision log, допущения
  • Что бы вы уточнили дальше: открытые вопросы и план уточнений

    • !Рекомендуемая структура одного кейса в портфолио

    Как обходить NDA корректно

    Если нельзя показывать реальные документы:

  • меняйте названия сущностей и полей, но сохраняйте структуру и логику
  • показывайте «обезличенные фрагменты» (например, часть таблицы статусов или шаблон API-ошибок)
  • делайте реконструкцию: «как бы я оформил спецификацию», без копирования внутренней информации

    • Важно: не уносите из компании конфиденциальные данные. Репутационно это хуже, чем отсутствие портфолио.

    Кейсы для интервью: как рассказывать про свою работу

    На интервью вас регулярно просят: «Расскажите про проект» или «Приведите пример сложной ситуации». Если отвечать хаотично, вы теряете сигнал Middle-уровня.

    Универсальная структура ответа: STAR

    STAR — удобная рамка для кейсов.

  • Situation: контекст и почему это было важно
  • Task: ваша задача и критерий успеха
  • Action: что именно сделали вы (а не команда абстрактно)
  • Result: результат, эффект, что изменилось

    • Справка: STAR (Interview)

    Какие кейсы подготовить заранее

    Подготовьте 6–8 историй и «переиспользуйте» их под разные вопросы.

  • про сбор требований с конфликтом интересов
  • про ситуацию, где не хватало данных и вы управляли неопределённостью
  • про сложную интеграцию и обработку ошибок
  • про инцидент/дефект в проде и улучшение требований после него
  • про декомпозицию и согласование MVP
  • про ситуацию, где вы сказали «нет» или ограничили scope

    • Обязательное правило: в каждом кейсе назовите артефакты, которые вы произвели.

    Пример формулировки уровня Middle:

  • «После воркшопа я зафиксировал таблицу статусов и переходов, обновил BPMN, добавил ошибки провайдера в SRS и согласовал decision log по варианту асинхронной отмены».

    • Резюме Middle системного аналитика

    Что должно быть в резюме, чтобы вас позвали

    Резюме должно быстро отвечать на три вопроса:

  • какой у вас уровень и тип задач
  • в какой среде вы работали (домен, команды, интеграции, нагрузки, регуляторика)
  • какой результат вы приносили и какими артефактами/подходами

    • Сильное резюме: структура

  • Заголовок: «Системный аналитик» (или «System Analyst») и уровень
  • Короткое summary на 4–6 строк: домены, типы систем, ключевые компетенции
  • Опыт: по каждому месту 4–8 буллетов «что делал + эффект + контекст»
  • Навыки: требования, модели, данные, API, инструменты
  • Образование и курсы: только релевантное
  • Ссылки: портфолио, GitHub (если есть), LinkedIn

    • Ссылки на профили (если вы их используете):

  • LinkedIn
  • hh.ru

    • Как писать буллеты опыта, чтобы читали как Middle

    Используйте формулу: действие → артефакт → эффект → масштаб/контекст.

    Слабый вариант:

  • «Собирал требования, писал ТЗ»

    • Сильнее:

  • «Провёл 12 интервью и 2 воркшопа, оформил SRS и acceptance criteria для процесса возврата; снизили количество уточнений от разработки на refinement и ускорили приёмку за счёт негативных сценариев»

    • Не обязательно указывать точные числа, если их нет, но контекст «какой сложности» должен быть.

    Триггеры, из-за которых резюме «режут»

  • перечисление инструментов без задач и результатов
  • «делал всё» без конкретики (границы ответственности не видны)
  • нет упоминаний про данные, интеграции и обработку ошибок
  • нет примеров коммуникации и согласований (как вы получали решения)

    • Собеседования: какие бывают и как к ним готовиться

    Типовой пайплайн для Middle-аналитика может отличаться, но чаще всего включает несколько типов оценки.

    | Этап | Что проверяют | Как готовиться | |---|---|---| | Скрининг с рекрутером | адекватность уровня, мотивация, коммуникация | коротко описать 1–2 проекта по STAR и ожидания | | Интервью с руководителем/аналитиком | требования, модели, артефакты, управление изменениями | принести портфолио и уметь объяснить решения | | Техническое интервью | API, интеграции, данные, ошибки, НФТ | тренироваться разбирать сценарии и edge cases | | Кейс/воркшоп | фасилитация, конфликт-менеджмент, структурирование | отрабатывать «вести обсуждение к решению» | | Финал | cultural fit, условия, рост | вопросы про процессы, ожидания, 30-60-90 |

    Типовые практические задания и как отвечать

    Частые форматы задания:

  • дописать acceptance criteria к user story
  • нарисовать BPMN процесса с исключениями
  • описать контекст системы и интеграции
  • предложить структуру API и ошибки
  • составить таблицу статусов и переходов

    • Алгоритм ответа, который показывает зрелость:

  • Уточнить цель и границы: что входит и что нет
  • Спросить про стейкхолдеров и источник правды по данным
  • Пройти «счастливый путь»
  • Добавить исключения: ошибки, таймауты, повторы, конкуренция
  • Зафиксировать НФТ только там, где они меняют решение
  • Оставить список открытых вопросов и допущений

    • Это напрямую использует навыки из предыдущих тем курса.

    Как проявлять soft skills прямо на интервью

    Интервью — это тоже рабочая коммуникация. Поведение, которое обычно считывается как Middle:

  • вы перефразируете задачу и подтверждаете понимание
  • вы задаёте вопросы про исключения и данные, а не только про «фичу»
  • вы фиксируете допущения: «если X, то сделаю так; если X не верно, будет другой вариант»
  • вы умеете предложить 2–3 варианта и критерии выбора

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

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

    Цель переговоров — согласовать ожидания и снизить риск «не совпали по роли».

    Что обсудить:

  • зона ответственности: вы ведёте фичи end-to-end или только требования
  • артефакты: есть ли SRS, как ведут backlog, кто владелец требований
  • взаимодействие с архитекторами и разработкой: кто решает по интеграциям
  • ожидания по самостоятельности: какие задачи считаются Middle в этой компании
  • рост: критерии следующего уровня и как его оценивают

    • Если вы хотите «Middle», полезно прямо спросить:

  • «Какие ожидания от Middle-аналитика в первые 2–3 месяца?»
  • «По каким сигналам вы понимаете, что человек соответствует уровню?»

    • Рост после выхода: план 30-60-90 дней

    Чтобы закрепиться на Middle, важно быстро стать предсказуемым.

    План на 30 дней

  • изучить домен: термины, процессы, стейкхолдеров
  • понять границы систем и ключевые интеграции
  • договориться о формате артефактов и «источнике правды» (backlog vs SRS)
  • сделать 1–2 небольших постановки с хорошими criteria и обработкой ошибок

    • План на 60 дней

  • вести 1 фичу или подпроцесс end-to-end
  • фасилитировать refinement или воркшоп, фиксировать решения и action items
  • стабильно закрывать «дыры»: данные, статусы, НФТ, доступы
  • собрать обратную связь от разработки и тестирования по качеству требований

    • План на 90 дней

  • взять инициативу по улучшению: шаблоны требований, чек-листы, единый формат ошибок API
  • уменьшить число возвратов задач из-за недоопределённости
  • стать «точкой связности» между бизнесом и командой

    • Эта траектория отражает компетенции из матрицы Middle из первой темы курса.

    Итог

    Трудоустройство на Middle для системного аналитика — это управляемая упаковка ваших компетенций в доказательства.

  • Портфолио показывает артефакты и качество мышления: границы системы, модели, данные, API, НФТ, решения.
  • Кейсы (по STAR) показывают, что вы умеете договариваться и доводить до результата.
  • Резюме должно транслировать масштаб, самостоятельность и эффект, а не только список инструментов.
  • Интервью проверяют способность работать с неопределённостью, исключениями и последствиями изменений.
  • Рост закрепляется планом 30-60-90 и привычкой фиксировать решения, риски и изменения.

    • Если вы сделаете 2–3 сильных кейса в портфолио, подготовите 6–8 историй по STAR и научитесь «вживую» раскладывать задачу на границы, сценарии, данные и ошибки, вы будете выглядеть как Middle ещё до первой работы на новом месте.