Фича: пользователь может изменить адрес доставки в заказе до передачи в сборку. Какой вариант лучше всего похож на проверяемые acceptance criteria?

AПроцесс изменения адреса должен быть удобным, понятным и визуально приятным на любом устройстве пользователя в production
BДобавить отдельный экран с полем address_input и кнопкой подтверждения, доступной на всех этапах оформления заказа
CЕсли статус заказа new или confirmed, адрес меняется; при packing адрес блокируется с понятным сообщением
DРеализовать изменение адреса по аналогии с конкурентами рынка, чтобы соответствовать паттернам в виджете checkout
Правильный ответ. Хорошие критерии приёмки бинарно проверяемы и описывают поведение по условиям, включая граничные случаи.

Разбор

Acceptance criteria должны позволять однозначно ответить, выполнено требование или нет. Формулировки про «удобно» и «как у конкурента» не дают проверяемого результата. Указание состояний заказа и ожидаемого поведения делает критерии тестируемыми и снижает риск разночтений между продуктом, дизайном и разработкой. Отдельно полезно предусмотреть негативный сценарий как часть edge cases, например попытку изменить адрес после начала сборки.

Проверь себя · 1/2разбор после ответа
Вы пишете PRD на экспорт заказов. В документе есть разделы «область охвата» и «вне области». Что лучше всего записать во «вне области» для первой версии?
Тренировать продукт в Telegram

Ещё вопросы по теме «Постановка задачи и PRD»