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

AЗафиксировать допущение, как и когда оно проверяется, и что команда делает при отказе: план B и влияние на охват
BНе писать допущение в документ, чтобы не пугать стейкхолдеров рисками и не замедлять обсуждение релиза заранее
CЗаписать допущение как факт: внешнее API будет доступно и стабильно к запуску, отдельный план B не требуется
DПеренести обсуждение допущений в раздел «вне области охвата» и больше не возвращаться, чтобы упростить документ
Правильный ответ. Допущения нужно явно фиксировать и привязывать к рискам: что проверяем и как меняется область охвата при отказе.

Разбор

Скрытые допущения часто превращаются в сюрпризы на интеграции и ломают сроки. В PRD полезно написать, на что вы рассчитываете, как быстро это можно подтвердить и какой запасной вариант предусмотрен. Тогда команда заранее понимает, что является блокером, и может управлять риском. Это также помогает честно согласовать область охвата и ожидания результата, а не догонять проблемы постфактум.

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

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