Дешёвая проверка решения — Примеры

Пример 1 — Выбор предположения, которое стоит проверять

У решения четыре предположения, и команда хочет начать с самого лёгкого — результат вышел бы приятным и ничего не говорящим; продуктовое исследование требует другого: взять то, которое вероятнее всего неверно и дороже всего, если это так, проверить только его и заранее определить рядом правило решения. Выберите же такое предположение из списка ниже и напишите дешёвую проверку, потому что именно оно задаёт направление работы.

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

Решение

Рискованнейшее предположение  повторные покупатели согласятся хранить карту
Почему                        если оно неверно, неверен весь подход.
Дешёвая проверка              предложить «запомнить мои данные на следующий
                              раз» без всякого хранения, на одну неделю.
Сигнал                        использование опции при оформлении плюс
                              доля повторных покупок.
Порог                         ниже 15% использования значит, что хранение
                              и не было сутью; решение: остановить разработку.
Решение записано вместе с проверкой, до её запуска.

Проверка стоит неделю и может убрать квартал работы, к тому же она измеряет поведение: клик при оформлении считается данными, а «я бы этим пользовался» — нет. Частая неудача — проверять формулировку или переключатель: они не могут изменить направление работы.

Пример 2 — Консьерж-тест с приложенным решением

Команда не уверена, нужен ли малым аккаунтам ежеквартальный разбор, а разработка планирования и отчётности заняла бы квартал. Однако консьерж-тест даёт результат вручную для первых нескольких клиентов, поэтому готовность проявится раньше, чем появится автоматизация, — напишите план проверки на одну страницу ниже и согласуйте правило решения заранее.

Идея: ежеквартальный звонок-разбор для малых аккаунтов.
Открытый вопрос: нужно ли это кому-нибудь и придут ли они на звонок?
Забота: сделать это сразу стоило бы квартала.

Решение

Предположение  малые аккаунты придут на назначенный разбор
Проверка       провести разборы вручную для следующих трёх
               продлевающихся аккаунтов, каждый раз
               записывая записку для подготовки.
Неделя 1       предложить дату четырём; двое согласившихся — минимум.
Неделя 2       провести звонки; записать каждый ручной шаг.
Порог          3 из 4 соглашаются и приходят -> автоматизировать
               планирование. 2 или меньше -> остановиться и записать
               это для следующей команды.
Результат записан в любом случае, ручные шаги перечислены.

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