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