Я сначала раскладываю новый процесс на карточках, а потом обсуждаю экран и архитектуру
Когда команда обсуждает новую функцию или автоматизацию, разговор быстро уходит в экраны, API и оценку. Я стараюсь сначала разложить будущий путь на простых карточках: кто начинает действие, какое решение принимает человек, что делает система, кому передаётся результат и что бывает в исключении.
Это не попытка заменить архитектуру бумажками. Наоборот, так проще понять, о чём архитектуре вообще нужно договориться. Пока граница ответственности не видна, технология лишь делает неясный процесс быстрее и дороже.
Карточки показывают то, что не видно на экране
Экран обычно принадлежит одному пользователю. Процесс почти никогда не заканчивается на одном экране. Менеджер создаёт заявку, руководитель подтверждает исключение, система проверяет правило, бухгалтер видит документ, клиент получает уведомление. Если начать с макета интерфейса, легко сделать удобный первый шаг и забыть обо всех остальных.
На столе это видно сразу. Одна карточка — событие, другая — решение, третья — данные, которые меняют ход, четвёртая — передача. Там, где между карточками возникает вопрос «а кто это делает?», уже появилась важная граница. Она важнее цвета кнопки и названия поля.
Я не приписываю этот приём какой-то одной методологии. Он полезен потому, что даёт людям общий предмет разговора. Собственник говорит о результате, сотрудник — о реальной работе, аналитик — о правилах, разработчик — о состояниях. Все смотрят на один путь, а не на четыре версии одной идеи.
Первый проход должен быть маленьким
В такой разбор не нужно тащить весь бизнес. Достаточно выбрать один частый и понятный случай. Например: клиент прислал запрос, менеджер проверил данные, система создала предложение, клиент подтвердил, задача ушла в исполнение. Сначала важно договориться, где этот путь начинается и какой результат считается завершённым.
Потом я добавляю вопросы, которые обычно появляются слишком поздно: что происходит, если данных не хватает; кто может отменить решение; как исправить ошибку; что увидит следующий сотрудник; какой след останется для клиента и команды. Именно в этих местах появляются реальные требования к ролям, статусам, журналу изменений и интеграциям.
Хороший первый путь не обязан быть красивым. Он обязан быть проверяемым. Если невозможно объяснить, как по нему пройдёт одна реальная операция, рано обсуждать масштабирование и архитектурные паттерны.
Граница ответственности — не должностная инструкция
«Ответственный менеджер» — слишком общий ответ. В процессе нужны более точные формулировки: менеджер подтверждает полноту заявки; руководитель утверждает отклонение от правила; система не пропускает заявку без обязательного условия; бухгалтер закрывает документ после факта отгрузки. Тогда ясно, какое решение остаётся у человека, а какое правило можно отдать системе.
Если этого не сделать, автоматизация начинает выдавать странные исключения. Система либо требует подтверждать каждую мелочь, либо молча пропускает то, что бизнес хотел контролировать. Люди обходят её в таблицах и мессенджерах, а команда разработки получает противоречивые просьбы «сделать гибче» и «ничего не давать менять».
Правило лучше сформулировать до выбора технологии. В статье о том, почему правила идут раньше технологии, я разбирал ту же логику: инструмент не решает за бизнес, что для него считается верным.
Три места, где спор обычно прячется
Первое — начало процесса. Одна команда думает, что заявка началась после нажатия кнопки, другая — только после проверки менеджером. Между этими версиями лежат потерянные обращения и разные цифры в отчётах. Поэтому стоит прямо назвать событие, после которого компания взяла на себя обязательство.
Второе — право на исключение. Если скидка, перенос срока или исправление документа возможны, нужно знать, кто их разрешает и что увидит следующий участник. Свобода «разберёмся в чате» удобна один раз, но плохо масштабируется на отпуск, смену команды и спор с клиентом.
Третье — финал. Отправка письма, проведённый документ и фактический результат для клиента — разные вещи. Если финальным считают технический шаг, система может рапортовать об успехе, пока работа всё ещё стоит. Хорошая карточка финала отвечает не на вопрос «какая функция сработала», а «что человек теперь может сделать иначе».
Не делать карточки новой бюрократией
У этого приёма есть плохая версия: команда рисует десятки цветных стикеров, фотографирует стену и больше к ней не возвращается. Тогда артефакт не помогает ни разработке, ни эксплуатации. Я бы оставил только то, что превращается в проверяемое правило: шаг, владелец, условие, результат, исключение.
После согласования карточки стоит перенести в короткую живую заметку рядом с задачей. Не нужно переписывать разговор дословно. Нужны решения и открытые вопросы: что считается началом, как выглядит успешный результат, кто принимает исключение, что пока не решили. Такая заметка помогает следующему участнику понять ход мысли и не повторять встречу с нуля.
Проверка до первой строки кода
Перед передачей в разработку полезно пройти путь как сотрудник. Пусть один участник читает действие, второй отвечает за систему, третий играет исключение. Если на каком-то шаге непонятно, откуда взялись данные или кто вправе продолжить, это хороший результат сессии: неясность обнаружена достаточно рано.
Затем можно сформулировать критерии приёмки в человеческих словах. Не «эндпоинт возвращает 200», а «заявка с неполным набором данных не переходит дальше, сотрудник видит причину, после исправления продолжает работу без новой заявки». Такие критерии одинаково понятны бизнесу, тестировщику и разработчику.
Исключение — часть основного пути
Самая частая ошибка в раннем проектировании — рисовать только удачный сценарий. Но продукт или система становятся полезны именно тогда, когда помогают с обычным отклонением: клиент прислал неполные данные, цена не укладывается в лимит, документ пришёл позже, сотрудник ушёл в отпуск, внешний сервис временно не отвечает.
Я бы не пытался описать все исключения сразу. Достаточно выбрать два-три самых дорогих или частых. Для каждого нужны владелец, допустимое действие и понятное возвращение в основной путь. Тогда исключение не превращается в тайный чат, где информация исчезает вместе с человеком.
Так же полезно заранее задать вопрос о возврате. Если правило сработало неправильно, кто это заметит и как исправит ситуацию без нового ручного квеста? Архитектура становится живой именно в этих переходах, а не в красивой схеме компонентов.
Что меняется в разговоре с разработкой
После такого разбора запрос к разработке звучит иначе. Вместо «нужна форма с пятью полями» появляется: «сотрудник должен передать заявку в следующий этап только после проверки двух условий; при отклонении руководитель видит причину; после решения клиент получает понятный статус; повторная попытка не создаёт дубль».
В этом уже есть материал для технического решения, тестов и приёмки. Можно обсудить роли, модель данных, события, интеграции, права и журнал. Но теперь каждая техническая деталь привязана к реальному действию, а не к вкусу участников встречи.
Если процесс затрагивает несколько систем, важно не размазывать ответственность между ними. У каждой передачи должен быть ожидаемый результат и способ понять, что произошло. Иначе при первой ошибке все будут смотреть на соседний сервис. Недавно я писал о том, почему на стыке систем нужен владелец ошибки, а не только описание API.
Как провести первую сессию за час
- Возьмите одну реальную операцию, которая повторяется хотя бы раз в неделю.
- Назовите начало и полезный результат для человека или клиента.
- Разложите действия и решения по порядку, без экранов и технологий.
- Отметьте передачи между ролями и системами.
- Выберите два важных исключения и путь обратно.
- Зафиксируйте открытые вопросы, а не маскируйте их догадками.
После встречи не нужен многотомный документ. Достаточно короткого описания пути, списка правил и решений, которые ещё предстоит принять. Это уже защищает команду от типичной ошибки: начать строить разное представление о задаче в разных головах.
Маленький макет экономит большой спор
Я люблю этот способ за его честность. Карточки не позволяют спрятать неясность за профессиональными словами. Если никто не может поставить следующую карточку, значит, решение не принято. Его лучше заметить до разработки, чем после запуска.
Технология нужна, чтобы надёжно поддержать договорённый путь. Но сама договорённость начинается раньше: с понятного действия, границы ответственности и безопасного исключения. Когда это есть, интерфейс и архитектура становятся продолжением процесса, а не попыткой угадать его по ходу работы.
Обсудим?