Глава 32 описала решения без реализации. Глава 33 отсеяла слабые переходы. Теперь оставшееся становится ТЗ на коммерческую функцию первой версии: что делает проект, что оставляет человеку, как живёт после запуска и как принимается.
Карта отвечает, какое решение происходит. ТЗ: каким механизмом его поддержать в заданных условиях.
Коммерческие работы
Для каждого перехода:
Когда участник находится в ситуации X и принимает решение Y, система показывает доказательство Z, помогает сделать A и передаёт B, не принимая риск C.
Например, операционный директор готовит запуск и решает, вовлекать ли собственника. Система помогает проверить применимость, собрать обоснование и назначить диагностику с владельцем бюджета. Рост продаж до диагностики не обещает.
Первой версии хватает одной-трёх работ. Остальное: позже, ручной обход или вне проекта.
Приоритеты первой версии
Для возможности оцени подтверждённый переход, частоту и ущерб препятствия, силу доказательства, цену реализации и наличие ручного пути.
В первую версию входит необходимое для ключевой работы или измерения. Десятки статей не приоритетны, если узкое место: инициатор не приводит владельца бюджета.
Статусы:
- P0: нужно для перехода и приёмки;
- P1: снижает риск, но есть обход;
- P2: гипотеза следующего цикла;
- не делать: связи с решением нет.
Граница автоматизации
- Сейчас: правила устойчивы, данные определены, ошибка обратима.
- Человек: нужен контекст, ошибка дорога, правила меняются.
- Позже: ручной процесс надо накопить и измерить.
Система проверяет поля, собирает согласие, назначает слот. Консультант оценивает организационную готовность. Автоквалификация ждёт накопленных причин отказа.
У ручного участка есть владелец, срок и запасной канал. Иначе человек превращается в невидимую интеграцию, у которой бывает отпуск.
Функциональный контур
Для работы опиши:
- вход и источник;
- участника и данные;
- доказательство;
- действие и обязательные поля;
- квалификацию и отказ;
- результат покупателю;
- передачу человеку или системе;
- событие аналитики;
- ошибку и ручной обход.
Только потом назначай страницу, документ, форму, календарь, CRM и уведомление. Компонент рождается из сценария.
Эксплуатация
Назначь владельцев контента, расписания, цен и применимости; обработку и эскалацию; мониторинг интеграций; резервную связь; хранение, доступ и удаление данных; журнал логики; разбор отказов; предел мощности продаж и исполнения.
Для чувствительных данных укажи цель, согласие, хранение и доступ. Для срочного шага: обход при падении календаря или CRM.
Нефункциональные требования
Выводи их из риска: доступность сценария, загрузка на нужных устройствах, доступность интерфейса, безопасность, срок доставки обращения, наблюдаемость ошибок, пересылка без потери смысла, совместимость с рабочим контуром.
У каждого требования есть проверка. «Быстро, удобно, надёжно» отлично звучит и никак не принимается.
Критерии приёмки
Проверяй сценарий, не экраны. Назови начальные условия, участника, данные, доказательство, действие, результат в интерфейсе и системе, срок, аналитику, отказ и принимающего.
Пример: квалифицированный инициатор создаёт встречу с собственником; оба получают приглашение; карточка с источником и согласиями появляется в CRM не позднее чем через пять минут; консультант уведомлён; при сбое данные остаются в очереди, дежурный получает сигнал.
Выручка проверяется в эксплуатации. Приёмка подтверждает управляемую часть перехода.
Комплект в производство
- Коммерческие работы и доказательства.
- P0/P1 и исключённый объём.
- Сценарии и компоненты.
- Автоматизация и ручные обходы.
- Данные, интеграции, аналитика.
- Нефункциональные требования.
- Эксплуатация.
- Приёмка.
- Риски и пересмотр.
Владельцев обязательств назначит глава 35. Без них ТЗ пока умеет только очень подробно надеяться.