В PRD (Product Requirements Document) вы полагаетесь на внешнее API, которое должно вернуть расчёт ETA доставки. Как лучше всего зафиксировать такое допущение, чтобы защитить scope?

AЯвно записать допущение, как оно будет проверяться, и что делаем, если оно не подтвердится (план B и влияние на scope)
BНе писать допущение, чтобы не пугать стейкхолдеров
CЗаписать допущение как факт: API точно будет доступно и стабильно
DПеренести обсуждение допущений в non-goals и не возвращаться к ним
Правильный ответ. Допущения нужно явно фиксировать и привязывать к рискам: что проверяем и как меняется scope, если допущение не выполняется.

Разбор

Скрытые допущения часто превращаются в сюрпризы на интеграции и ломают сроки. В PRD (Product Requirements Document) полезно написать, на что вы рассчитываете, как быстро это можно подтвердить и какой fallback предусмотрен. Тогда команда заранее понимает, что является блокером, и может управлять риском. Это также помогает честно согласовать scope и ожидания результата.

Проверь себя · 1/3разбор после ответа
Вы пишете PRD (Product Requirements Document) на экспорт заказов. В документе есть разделы scope и non-goals. Что лучше всего записать в non-goals для первой версии?
Тренировать продукт в Telegram

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