Фича: удаление аккаунта. У продукта есть активные подписки и возвраты. Какие acceptance criteria лучше всего снижают риск некорректного поведения и закрывают ключевые edge cases?
A
acceptance criteria: пользователь нажимает «Удалить», данные немедленно удаляются из БД; активные подписки и незавершённые возвраты не проверяются; пользователь получает письмо об удаленииB
acceptance criteria: перед удалением показываем экран подтверждения и страницу прощания; аккаунт удаляется сразу после согласия; edge cases и подписки не рассматриваются как блокерC
acceptance criteria: удаление аккаунта снижает нагрузку на поддержку; кнопка доступна всем пользователям без ограничений; метрика успеха — рост числа удалений на 20% в месяцD
acceptance criteria: при активной подписке удаление требует сначала отмены; при незавершённых возвратах показываем блокирующее сообщение; после удаления пользователь разлогинен и не может войти; данные, которые обязаны храниться, остаются по правилам, остальное удаляется или анонимизируется; все статусы и ошибки описаны как edge casesПравильный ответ. Для рискованных операций
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` для первой версии?
- Фича: пользователь может изменить адрес доставки в заказе до передачи в сборку. Какой вариант лучше всего похож на проверяемые `acceptance criteria`?
- Вы добавляете промокоды в корзину. Какой вариант лучше всего подходит для раздела `edge cases` в PRD (Product Requirements Document)?
- В PRD (Product Requirements Document) вы полагаетесь на внешнее API, которое должно вернуть расчёт ETA доставки. Как лучше всего зафиксировать такое допущение, чтобы защитить `scope`?
- Все вопросы по «Постановка задачи и PRD» →