Предположим, инициатору не хватает материала для разговора с владельцем бюджета. Прежде чем делать раздел сайта, можно передать ему этот материал и посмотреть, состоится ли внутренний разговор. Если препятствие в другом, узнать это лучше до разработки.
Результат: реестр доказательств, протокол проверок и решение «строить / изменить / не строить». В главу 34 проходят только проверенные переходы.
Реестр допущений
Перенеси неизвестные из паспорта и карты. Формулируй проверяемо: проблема возникает в ситуации; последствия важны; инициатор привлекает владельца бюджета; участники понимают изменение; доказательство снижает риск; первый шаг приемлем; клиент способен исполнить обещание.
Оцени ущерб ошибки и недостаток знаний. Сначала проверяй то, что способно отменить проект. Формулировки интерфейса проверяют после оснований для покупки.
Доказательство к решению
Сила свидетельства растёт вместе с ценой действия:
- мнение;
- рассказ о прошлом;
- передача материала коллеге;
- данные или доступ;
- встреча с участниками;
- подпись или оплата;
- результат ручного исполнения.
Не всё доводят до оплаты. Но внутреннюю передачу лучше доказывает настоящее приглашение владельца бюджета, чем двадцать комплиментов макету.
Минимальная проверка
Минимум определяется вопросом, не числом функций. Подойдут интервью, прототип, ручная квалификация, документ, тестовая кампания или ручное оказание услуги.
До теста запиши гипотезу, риск, ситуацию, материал, ожидаемое действие, выборку, срок, критерии продолжения, изменения и остановки, владельца данных.
Ручная работа честна, если границы известны. Нельзя выдавать человека за алгоритм и продавать результат, который команда не умеет обеспечить.
По каким результатам разрешать разработку
Ворота проверки — заранее заданные условия, по которым ты решишь, что делать дальше. Например:
- строить: минимум три из пяти инициаторов передали материал владельцу бюджета, двое пришли на диагностику, один оплатил; ручное исполнение сходится по экономике;
- изменить: проблема есть, текущий объём риска не согласуется;
- не строить: ситуация не повторяется, обязательств нет или исполнение слишком дорого.
Пороги зависят от рынка. Не меняй критерии задним числом ради удачного итога. Если условия теста оказались неверными, запиши это и назначь новую проверку.
Цена и операционная готовность
Цена проверяется с объёмом, условиями и риском. Проси обязательство для конкретного шага. Отказ различай: бюджет, участник, ценность, риск, срок.
Параллельно прогони исполнение руками: кто принимает обращение, сколько ждёт покупатель, какие данные теряются, сколько длится диагностика. Спрос без способности обслужить его не оправдывает автоматизацию. Без этого рост спроса увеличит очередь и время ожидания.
Пакет доказательств
Для каждой работы запиши утверждение, риск и участника, материал, слова и действия отдельно, результат против порога, ограничения выборки, решение и изменение карты.
Например, пять операционных директоров получают обоснование и границы диагностики. Двое приводят собственников, один платит. Оснований объявить рынок доказанным нет. Более узкий вывод: в проверенных случаях механизм сработал при обязательном сроке. Условие входит в модель и квалификацию.
Что передать в техническое задание
Строить: ситуация и решения повторяются, обязательства соразмерны, ручное исполнение даёт ценность, экономика приемлема, цифровой механизм лучше обхода.
Изменить: вернуться в главу 31 или 32.
Не строить: закончить работу сэкономленным бюджетом и объяснённой причиной. Это самостоятельный результат проверки.
В главу 34 передай прошедшие переходы, работающие доказательства, условия отказа, ручной процесс, экономику и оставшиеся риски.
Непроверенные пожелания сохрани отдельно: они могут стать задачами следующего цикла, но не обязательной частью разработки.