коротко

Все записи справочника — это отдельные навыки. Здесь они собираются в один проект. Мы ведём одну систему — MeetRoom, внутренний сервис бронирования переговорок — от первого разговора с заказчиком до эксплуатации в проде, и на каждом шаге показываем, какой артефакт аналитик производит и в какой записи разобран нужный навык. Путь: понять бизнес-смысл → выявить требования у стейкхолдеров → собрать SRS → спроектировать (HLD/LLD, зафиксировать выборы в ADR) → описать модель данных и жизненный цикл брони → задать API с ошибками и авторизацией → нарисовать интеграции (календарь по вебхуку) → продумать миграции, эксплуатацию и метрики. Это та самая сквозная нить, которой не хватает, когда теорию учат темами вразнобой: тут видно, как один документ перетекает в другой и почему порядок именно такой.

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

Возьмём MeetRoom — внутренний веб-сервис, где сотрудники бронируют переговорки офиса. Та же система, на которой построены примеры в записях про SRS, HLD/LLD и авторизацию. Здесь мы соберём все её куски в один маршрут.

Шаг 1. Зачем это вообще: бизнес-контекст

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

Шаг 2. Выявить требования, а не записать

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

До того как писать SRS, решаем, что вообще делаем в первую очередь: бронирование и просмотр — да, оплата платных комнат и интеграция со СКУД — потом. Это MVP и приоритизация, а отделить «что выяснить» от «что строить» помогает дискавери против деливери. И сразу честно оцениваем объём — диапазоном, а не точкой: про это оценка задач.

Шаг 3. Зафиксировать: SRS

Выявленное превращаем в документ, иначе оно не существует. Для MeetRoom это SRS — полная спецификация: цель, границы (что в скоупе, что нет), акторы (сотрудник, офис-менеджер, внешний календарь), функциональные требования с ID (создать бронь, защита от двойного бронирования) и нефункциональные с числами (сетка доступности < 800 мс, доступность 99.5%, «сотрудник видит только свои брони»). Как из выявленного собрать читаемый документ — в записи как написать ТЗ; разница между функциональными и нефункциональными требованиями — в FR против NFR, а отдельные сценарии описываем как user story и use case.

Шаг 4. Спроектировать: HLD, LLD, ADR

SRS говорит «что», теперь «как». Сначала крупными блоками — HLD: веб-приложение, бэкенд MeetRoom, база, внешний SSO, внешний календарь, и поток создания брони между ними. Потом детали — LLD: схема таблицы броней, контракт POST /bookings, защита от двойного бронирования через уникальное ограничение в БД. А каждый неочевидный выбор (почему PostgreSQL, а не Mongo — нам нужна атомарность брони) фиксируем в ADR, чтобы через полгода никто не «улучшил» решение обратно в баг. Какую диаграмму для чего рисовать — в записи про нотации BPMN, UML, C4.

Шаг 5. Данные и жизненный цикл брони

Проектируем данные на трёх уровнях — от сущностей бизнеса до таблиц PostgreSQL: модель данных: три уровня, а конкретику по ключам, связям и ACID — в базы данных для аналитика (если бы MeetRoom строили на документной базе, моделировали бы иначе — под паттерн доступа, см. моделирование в NoSQL). Отдельно описываем, как живёт сама бронь: «создана → подтверждена → отменена», какие переходы разрешены, а какие нет (нельзя отменить уже прошедшую встречу). Это диаграммы состояний — и именно запрещённые переходы ловят класс багов, который иначе всплывёт в проде.

Шаг 6. Контракт: API, ошибки, доступ

Чтобы веб-приложение и внешние системы общались с MeetRoom, задаём REST API: GET /rooms, POST /bookings, DELETE /bookings/{id}. Счастливый путь — это половина контракта; вторая половина — что вернётся при ошибке: 409 на занятый слот, 422 на превышение вместимости. Это ошибки как часть контракта. Кто вошёл — решает аутентификация через OAuth2 (корпоративный SSO), а что кому можно — авторизация на уровне данных: NFR «сотрудник видит только свои брони» — это не фильтр в интерфейсе, а проверка на сервере, что строка принадлежит запрашивающему. Что из данных брони считать чувствительным (с кем встреча) — в записи про безопасность данных и PII.

Шаг 7. Интеграции: календарь по событию

MeetRoom не живёт один: создал бронь — событие должно улететь в корпоративный календарь. Делать это синхронно или асинхронно — развилка из записи синхрон, асинхрон, очереди; для уведомления календаря берём асинхронный путь — исходящий вебхук booking.created. Сам сценарий «бэкенд создаёт бронь → шлёт событие календарю → тот подтверждает» удобнее всего нарисовать sequence-диаграммой — кто кого зовёт во времени. А поскольку событие может прийти дважды, обработчик на стороне календаря должен быть идемпотентным — про это идемпотентность (пример там на платеже, но для события booking.created механика ключа работает один в один).

flowchart TD
  A["Бизнес-боль:
хаос с переговорками"] --> B["Выявление
+ стейкхолдеры"]
  B --> C["SRS:
что строим"]
  C --> D["HLD/LLD + ADR:
как строим"]
  D --> E["Данные +
состояния брони"]
  E --> F["API + ошибки
+ авторизация"]
  F --> G["Интеграции:
календарь по вебхуку"]
  G --> H["Миграции +
эксплуатация"]
  H --> I["Метрики:
прижилось ли?"]

Схема показывает весь маршрут MeetRoom сверху вниз. Из бизнес-боли (хаос с переговорками) рождается выявление требований и карта стейкхолдеров; из них — SRS (что строим); из SRS — дизайн HLD/LLD с журналом решений ADR (как строим); дальше детализируются данные и жизненный цикл брони; затем — контракт API с ошибками и авторизацией; потом — интеграции с внешним календарём через вебхук; потом — миграции схемы и эксплуатация в проде; и в конце — метрики, которые отвечают, прижился ли сервис. Поток не строго водопадный: на практике он итеративный, и нижний шаг часто вскрывает дыру в верхнем (при проектировании API выясняется, что в SRS забыли requirement про отмену). Но порядок навыков именно такой — каждый следующий опирается на предыдущий. Тонкость: оглавление справочника учит темы в порядке «API → данные» (контракт проще для входа), а в проекте модель данных проектируют до контракта API — поэтому в маршруте шаг с данными идёт раньше. Это не противоречие: порядок обучения и порядок проектирования различаются намеренно.

Шаг 8. Эволюция и эксплуатация

MeetRoom выкатили — это не конец, а начало. Бизнес попросил хранить отдельно тему встречи и заметку вместо одного поля — меняем схему работающей базы без даунтайма: миграции данных и бэкфилл. Сервис доезжает до пользователей через несколько окружений — CI/CD, крутится в контейнерах (Docker и K8s), быстро отдаёт сетку доступности за счёт кэширования. Чтобы понимать, что он жив и где тормозит, закладываем логи, метрики, трейсы; обещание доступности из SRS превращается в SLA/SLO, а один интегратор не должен уронить сервис всем — ставим rate limiting.

Шаг 9. Прижилось ли: метрики

Последний и часто забытый шаг: фичу выкатили — а она работает? Без цифр это вопрос веры. Для MeetRoom главная метрика — доля встреч, забронированных через сервис, а не «по памяти»; смотрим воронку «открыл сетку → выбрал слот → подтвердил» и где отваливаются, проверяем гипотезы A/B-тестом. Всё это — в записи метрики, воронки, A/B. И когда копится словарь незнакомых терминов — держим открытым глоссарий.

Зачем смотреть на проект целиком

Каждый навык по отдельности — это инструмент в ящике. Но ценность аналитика не в том, что он знает, что такое SRS или sequence-диаграмма, а в том, что он умеет провести систему от размытой боли до работающего и измеримого продукта, не уронив ни один стык. Этот сквозной взгляд — то, что отличает человека, который «прошёл курс», от того, кто «сделал проект». Учите навыки по записям, но держите в голове весь маршрут MeetRoom: он показывает, как куски собираются в целое.

Как это спрашивают на собесе

Любимый формат сильного собеседования — не «что такое X», а «проведите меня по вашему проекту». Кандидата просят: «расскажите, как вы вели какую-нибудь систему от требований до прода» или «вот задача — спроектируйте сервис бронирования, рассуждайте вслух». Что проверяют: видите ли вы весь маршрут (а не только любимый кусок), не пропускаете ли выявление и метрики, помните ли про стыки — авторизацию, ошибки, идемпотентность, миграции. Слабый кандидат прыгает сразу в таблицы БД; сильный начинает с «а какую проблему решаем и кто стейкхолдеры» и доводит до «как поймём, что сервис прижился». Умение рассказать связный сквозной путь ценится выше, чем знание любого отдельного термина.

Частые вопросы

Это обязательный порядок шагов или можно иначе?

Порядок навыков — да, именно такой: каждый следующий шаг опирается на предыдущий (нельзя писать SRS, не выявив требования; нельзя проектировать API, не зная модель данных). Но сам процесс не строго водопадный, а итеративный: на практике вы постоянно возвращаетесь назад, потому что нижний уровень вскрывает дыру в верхнем — проектируя LLD, обнаруживаете, что в SRS забыли требование. Маршрут MeetRoom показывает логическую зависимость навыков, а не запрет ходить кругами.

Зачем нужен сквозной пример, если есть отдельные записи по каждой теме?

Отдельные записи учат навыкам — что такое SRS, как нарисовать sequence, чем RBAC отличается от ABAC. Но реальная работа аналитика — это не применение одного навыка, а проведение системы через все стыки так, чтобы ни один не рассыпался. Сквозной пример показывает, как один артефакт перетекает в другой (выявленное требование → строка SRS → блок HLD → таблица LLD → endpoint API) и почему порядок именно такой. Это превращает набор полочек в связный маршрут — то, что спрашивают на собесе и делают на проекте.

С чего начать, если я только учусь?

Идите по оглавлению справочника сверху вниз — он выстроен от фундамента к надстройке: контекст и роли → основы → требования → документы → процесс и продукт → API → интеграции → данные → эксплуатация → инструменты. А эту запись держите как карту: пройдя очередную тему, возвращайтесь сюда и смотрите, какое место навык занимает в маршруте MeetRoom. Так отдельные знания сразу укладываются в общую картину, а не повисают в воздухе.