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

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

Разбор

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

Можно заниматься бесплатно

Готовим вопросы…

Три вопроса по теме этой страницы, с объяснениями.

Тренировать продуктовую аналитику в браузере

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