Подготовь полный PRD для интеграции функции {feature_description} на платформе {platform} в продукте {product_name} для пользователей {target_users}.
Входные параметры
- feature_description
- platform
- product_name
- target_users
- timeline
- business_goal
Если какой-либо параметр не заполнен, сделай не более необходимых разумных предположений и сразу зафиксируй их в разделе Assumptions перед основным документом.
Отвечай только на русском языке.
Верни только готовый PRD без пояснений о том, как он был создан.
Используй заголовки и подпункты. Сохраняй разделы строго в указанном порядке.
Структура PRD
1. Название и контекст интеграции — 2-3 предложения с использованием {feature_description}, {platform}, {product_name}, {target_users}.
2. Краткое резюме — цель интеграции, ключевые выгоды и связь с {business_goal}.
3. Объективы и критерии успеха — Primary и Secondary цели с измеримыми метриками: метод измерения, baseline, target, частота отчётности.
4. Scope — что входит и что исключено.
5. Пользовательские сценарии и UX — минимум 3 основных сценария, требования к интерфейсу, обработка ошибок, доступность, локализация и ограничения {platform}.
6. Технические требования — архитектура, производительность, хранение данных, SLA, отказоустойчивость, резервирование, кэширование, масштабирование.
7. Спецификации API — дай OpenAPI v3-compatible YAML или JSON для всех публичных и внутренних эндпоинтов, включая пути, методы, параметры, тела, схемы ответов, ошибки, auth, scope, rate limits, валидацию и примеры запросов/ответов.
8. Диаграммы потоков данных и последовательностей — включи один Mermaid-блок для DFD и один Mermaid-блок для основного sequence flow.
9. Взаимозависимости между командами — таблица с командами, артефактами, интерфейсами взаимодействия и owner.
10. План координации и коммуникации — RACI, регулярные синки, каналы, SLA ответов для внешних команд.
11. План запуска для {timeline} — этапы, owners, readiness criteria, rollout strategy, rollback plan и feature flags.
12. Тестирование и валидация — unit, integration, e2e, performance, security, UAT, тестовые данные, prod-readiness criteria.
13. Мониторинг и алертинг — технические и бизнес-метрики, дашборды, пороги и процедуры реакции.
14. Права доступа, безопасность и комплаенс — шифрование, персональные данные, аудит, key management, применимые требования GDPR или локального права.
15. Риски и mitigations — риск, вероятность, влияние, меры снижения.
16. Оценка ресурсов и зависимости внешних поставщиков — человеко-дни по ролям, критические зависимости и SLA поставщиков.
17. Assumptions and Out-of-Scope — допущения и границы.
18. Приложения/Артефакты — ERD, контракты API, mockups или их текстовые описания, release checklist.
Требования к содержанию
- Уровень детализации должен позволять инженерной, дизайн- и QA-командам начать планирование без дополнительных уточнений.
- Не добавляй новые бизнес-инициативы за пределами интеграции функции.
- Используй таблицы там, где они прямо требуются: dependencies, release timeline, RACI, метрики.
- Для метрик указывай формулу измерения, baseline и target.
Ограничения
- Ориентир по длине: около 1500-3500 слов, не считая встроенных спецификаций и диаграмм.
- Стиль: деловой, чёткий, пригодный для передачи в реализацию.
- Не добавляй пояснений о процессе подготовки документа.
