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