Фича: пользователь может изменить адрес доставки в заказе до передачи в сборку. Какой вариант лучше всего похож на проверяемые acceptance criteria?
AПроцесс изменения адреса должен быть максимально удобным, понятным и визуально приятным для пользователя на любом устройстве
BДобавить отдельный экран с полем ввода адреса и кнопкой подтверждения, доступной на всех этапах заказа
CЕсли
status='new' или status='confirmed', адрес можно изменить; если status='packing' и дальше, адрес менять нельзя и показываем объяснение; после изменения адрес отображается в деталях заказа и в письме подтвержденияDРеализовать изменение адреса по аналогии с ведущими конкурентами, чтобы пользователи не испытывали затруднений и не обращались в поддержку
Правильный ответ. Хорошие
acceptance criteria бинарно проверяемы и описывают поведение по условиям, включая edge cases.Разбор
Acceptance criteria должны позволять однозначно ответить, выполнено требование или нет. Формулировки про «удобно» и «как у конкурента» не дают проверяемого результата. Указание состояний заказа и ожидаемого поведения делает критерии тестируемыми и снижает риск разночтений между продуктом, дизайном и разработкой. Отдельно полезно предусмотреть негативный сценарий как часть edge cases, например попытку изменить адрес после начала сборки.
Проверь себя · 1/3разбор после ответа
Вы пишете PRD (Product Requirements Document) на напоминания об оплате счёта. Что лучше всего сформулировать как
non-goals для первой версии?Ещё вопросы по теме «Постановка задачи и PRD»
- Стейкхолдер пишет: «Добавьте страницу FAQ про восстановление пароля». Какой вариант лучше всего формулирует `problem statement` для PRD (Product Requirements Document)?
- Вы пишете PRD (Product Requirements Document) на экспорт заказов. В документе есть разделы `scope` и `non-goals`. Что лучше всего записать в `non-goals` для первой версии?
- Вы добавляете промокоды в корзину. Какой вариант лучше всего подходит для раздела `edge cases` в PRD (Product Requirements Document)?
- В PRD (Product Requirements Document) вы полагаетесь на внешнее API, которое должно вернуть расчёт ETA доставки. Как лучше всего зафиксировать такое допущение, чтобы защитить `scope`?
- Команда делает кнопку повторного заказа в приложении. Что лучше всего записать как `acceptance criteria` для первой версии?
- Все вопросы по «Постановка задачи и PRD» →