Система как рабочая карта

Когда нужен этот материал

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

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

Материал полезен, когда:

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

Карта за 10 минут

Начать можно с шести вопросов:

1. Цель: какая работа должна стать проще, надежнее, быстрее или прозрачнее?
2. Граница: что входит в систему или задачу, а что остается снаружи?
3. Участники: кто или что действует внутри сценария?
4. Связи: какие интерфейсы, события, документы, API или ручные действия соединяют участников?
5. Данные: какие данные меняются, откуда они берутся и кто является источником истины?
6. Риски: где ошибка станет дорогой: для пользователя, команды, поддержки, безопасности или бизнеса?

Если на эти вопросы нет коротких ответов, команда пока не готова выбирать формат артефакта. Возможно, нужен не BPMN, не sequence diagram и не ТЗ, а сначала общий черновик карты.

Рабочий шаблон

Скопируйте этот блок в заметку, карточку задачи или документ discovery.

## Система или задача

Название:
Зачем это нужно:
Какая работа пользователя или команды меняется:

## Граница

Входит в текущий разбор:
- ...

Не входит:
- ...

Что пока неизвестно:
- ...

## Участники

Люди:
- ...

Системы:
- ...

Внешние стороны:
- ...

## Связи и интерфейсы

Кто с кем взаимодействует:
Через что: UI / API / файл / событие / ручной процесс / документ:
Что запускает сценарий:
Что считается завершением:

## Данные

Ключевые данные:
Источник истины:
Кто может менять:
Что нельзя логировать или публиковать:

## Состояния и исключения

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

## Следующий шаг

Что нужно уточнить:
Кто владелец:
Какой артефакт нужен дальше:

Цель шаблона не в том, чтобы заполнить все поля идеально. Его задача — быстро показать, где у команды уже есть общее понимание, а где есть пустоты.

Как выбрать следующий артефакт

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

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

1. Цель

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

Поэтому сначала полезно записать не “добавить экран”, а изменение в работе:

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

Слабая формулировка:

Добавить статус проверки.

Более полезная:

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

Во второй формулировке уже видны участник, работа, данные, внешний сервис и потенциальный риск.

2. Граница

Граница отвечает на вопрос: что мы сейчас рассматриваем, а что не берем в текущий контур.

Без границы обсуждение быстро расползается:

• задача про один сценарий превращается в redesign процесса;
• API-контракт начинает обсуждаться вместе с внутренней моделью данных;
• MVP незаметно включает поддержку всех исключений;
• внешний сервис воспринимается как часть нашей системы, хотя мы им не управляем.

Граница не обязана быть окончательной. Но она должна быть явной:

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

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

3. Участники

Участник — это не только пользователь. В рабочей системе участвуют:

• роли: клиент, оператор, менеджер, аналитик поддержки;
• внутренние системы;
• внешние сервисы;
• регламенты и ручные действия;
• очереди, файлы, уведомления, отчеты;
• команда поддержки или эксплуатации.

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

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

4. Связи и интерфейсы

Связи показывают, как участники взаимодействуют.

Не нужно сразу выбирать нотацию. Достаточно сначала назвать тип связи:

• UI-действие;
• API-запрос;
• webhook или событие;
• файл;
• ручной шаг;
• уведомление;
• документ;
• запись в журнале;
• изменение статуса.

После этого проще решить, какой артефакт нужен дальше. Если важен порядок сообщений — подойдет sequence diagram. Если важны статусы — схема состояний. Если важен процесс между ролями — процессная схема. Если важны границы ответственности — контекстная схема или короткая таблица.

5. Данные

Данные часто показывают реальные границы системы лучше, чем экраны.

Проверьте:

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

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

6. Состояния и исключения

Рабочая карта должна содержать не только happy path.

Минимально стоит спросить:

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

Если исключения не описаны, они все равно появятся. Только позже: в разработке, тестировании, приемке или production-инциденте.

Как использовать дальше

После такой карты легче выбрать следующий шаг:

• если непонятны цель и граница — уточнить задачу до разработки;
• если много неизвестных — провести risk-review;
• если риск в интеграции — разобрать карту интеграционных рисков;
• если нужен порядок взаимодействий — сделать sequence diagram;
• если важны статусы — описать состояния и переходы;
• если решение влияет на несколько задач — зафиксировать decision record;
• если задача идет в разработку — проверить готовность задачи и критерии приемки.

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