Для предзаказа обеда легко придумать длинный список функций: каталог, оплата, бонусы, история покупок, уведомления, учёт остатков. Чтобы выбрать первую версию, полезнее сначала пройти один заказ целиком: человек выбрал доступное блюдо, оставил заявку, сотрудник её увидел и подтвердил возможность выдачи.
Дальше нужно решить, что необходимо для этого пути, какие действия пока выполняет человек и по каким признакам система готова к использованию. Рассмотрим условный сервис предзаказов, который не является клиентским кейсом студии.
Сначала проверьте самое рискованное предположение
Вопрос может быть техническим: получится ли получать актуальное меню из существующей системы? Или организационным: кто подтвердит заказ, если нужное блюдо закончилось? Или связанным с потребностью: будут ли люди заранее оставлять предзаказ?
Не каждый такой вопрос требует полноценной разработки. Для проверки интереса может хватить разговора, макета или ручного приёма ограниченного числа заявок. Способ проверки выбирают по тому, что именно остаётся неизвестным.
В руководстве GOV.UK о прототипировании рекомендуют сосредоточиться на рискованных предположениях. Там отдельно подчёркнуто, что такой прототип ещё не является публичным рабочим сервисом. Это полезное различие и для небольшого проекта: макет показывает идею, а запуск требует надёжного выполнения выбранного пути.
Зафиксируйте один результат первой версии
Для условного предзаказа можно записать:
Посетитель выбирает блюдо из актуального списка и оставляет заявку на выбранное время. Оператор видит её, подтверждает или отклоняет, а посетитель получает понятный итог.
Теперь у функций появляется роль. Нужен способ обновлять доступный список, принять заявку, показать её оператору и сообщить решение. Роли, права доступа и существенные ошибки этого пути входят в обсуждение первой версии сразу.
Для каждой новой идеи задайте вопрос: без неё согласованный результат не состоится или она делает следующий этап удобнее? Ответ помогает определить очерёдность. Сам список пожеланий сохраняйте, чтобы вернуться к нему после первых наблюдений.
Что можно оставить человеку
Оператор может вручную подтвердить наличие блюда и время выдачи. Меню можно обновлять через простую админку. Это допустимые решения, если заранее понятно, кто выполняет действия и справляется ли с ожидаемой нагрузкой.
Ручная часть тоже должна быть описана: где сотрудник видит новые заявки, как часто проверяет их, что делает при отказе и кто его заменяет. Иначе за внешне простым интерфейсом останется неорганизованная работа.
Оплату, внешнюю учётную систему или автоматический расчёт доступности включают в первый этап, если без них выбранный сценарий не работает. Состав определяется условиями конкретного проекта. Универсального набора «достаточно этих пяти экранов» нет.
Критерии готовности к первому использованию
Проверяйте результат на действиях посетителя и сотрудника, включая неудобные случаи:
- Список доступного обновляется, пользователь понимает, что именно выбирает.
- Принятая заявка сохраняется и находится по номеру.
- Повтор отправки не создаёт дополнительный заказ той же операции.
- Оператор видит новые заявки и может зафиксировать решение.
- Подтверждение и отказ понятны посетителю; ожидание решения не выглядит как уже подтверждённый заказ.
- Понятно, что делать при недоступности сервиса и как восстановить работу с принятыми заявками.
- Ответственный получил доступы, материалы и объяснение повседневной работы.
Проверку данных, права, восстановление и существенные ошибки нельзя откладывать только потому, что аудитория запуска небольшая. Глубина решений зависит от риска, но сам риск нужно разобрать до передачи системы людям.
Запускайте в управляемом объёме
Сначала можно договориться с ограниченной группой пользователей и одним оператором. Участникам должно быть понятно, какой результат сервис уже даёт и куда сообщать о проблеме.
В описании beta-фазы GOV.UK работу с реальными пользователями начинают с ограниченного круга, затем улучшают сервис по обратной связи. Это пример подхода, а не обязательная процедура или срок для российского бизнеса.
После старта полезно смотреть, где люди бросают заказ, какие заявки требуют уточнения и с чем не справляется оператор. Отделяйте необходимость доработки от единичного пожелания. Для ближайшего изменения снова определяйте результат и способ проверки.
Что согласовать с исполнителем
До начала разработки зафиксируйте рабочий путь, роли, ручную часть, внешние зависимости и критерии приёмки. Отдельно договоритесь, где лежат исходники, как передаются доступы, кто отвечает за эксплуатацию и как оцениваются следующие этапы.
Первая версия может быть законченной поставкой. Дальнейшее развитие зависит от новых задач и наблюдений после использования. Месячная работа подходит и для создания первой версии, если объём периода и ближайший результат согласованы заранее.
В студии можно запустить нужное решение или продолжать развитие проекта. Для первого разговора достаточно описать один путь пользователя и то, что сейчас мешает выполнить его до конца.
