Документ требований к продукту (PRD)

Обзор

Проектируйте исчерпывающие PRD продакшен-уровня, соединяющие бизнес-видение и техническую реализацию. Этот скилл работает для современных программных систем, гарантируя чёткое определение требований.

Когда использовать

Используйте, когда: начинаете новый цикл разработки продукта или функции; превращаете расплывчатую идею в конкретную техническую спецификацию; определяете требования к функциям на базе ИИ; стейкхолдерам нужен единый «источник истины» по объёму проекта; пользователь просит «написать PRD», «задокументировать требования» или «спланировать функцию».

Операционный рабочий процесс

Фаза 1: Discovery (интервью)

Прежде чем написать хоть строку PRD, вы ОБЯЗАНЫ расспросить пользователя, чтобы заполнить пробелы в знаниях. Не предполагайте контекст.

Спросите о: основной проблеме — почему мы строим это сейчас?; метриках успеха — как мы поймём, что сработало?; ограничениях — бюджет, техстек или дедлайн?

Фаза 2: Анализ и определение объёма

Синтезируйте ввод пользователя. Выявите зависимости и скрытые сложности. Нарисуйте пользовательский поток. Определите не-цели, чтобы защитить сроки.

Фаза 3: Техническое черновое написание

Сгенерируйте документ по строгой схеме PRD ниже.

Стандарты качества PRD

Качество требований

Используйте конкретные измеримые критерии. Избегайте «быстро», «легко» или «интуитивно».

# Vague (BAD)
- The search should be fast and return relevant results.
- The UI must look modern and be easy to use.

# Concrete (GOOD)
+ The search must return results within 200ms for a 10k record dataset.
+ The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
+ The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.

Строгая схема PRD

Вы ОБЯЗАНЫ следовать этой точной структуре вывода:

1. Резюме для руководства

• Формулировка проблемы: 1–2 предложения о «боли».
• Предлагаемое решение: 1–2 предложения об исправлении.
• Критерии успеха: 3–5 измеримых KPI.

2. Пользовательский опыт и функциональность

• Персоны пользователей: для кого это?
• User stories: Как [пользователь], я хочу [действие], чтобы [польза].
• Критерии приёмки: маркированный список определений «Готово» для каждой истории.
• Не-цели: что мы НЕ строим?

3. Требования к ИИ-системе (если применимо)

• Требования к инструментам: какие инструменты и API нужны?
• Стратегия оценки: как измерять качество и точность вывода.

4. Технические спецификации

• Обзор архитектуры: поток данных и взаимодействие компонентов.
• Точки интеграции: API, БД и аутентификация.
• Безопасность и приватность: обработка данных и соответствие требованиям.

5. Риски и дорожная карта

• Поэтапная выкатка: MVP → v1.1 → v2.0.
• Технические риски: задержка, стоимость или сбои зависимостей.

Рекомендации по реализации

ДЕЛАЙТЕ (всегда): определяйте тестирование — для ИИ-систем укажите, как тестировать и валидировать качество вывода; итерируйте — представьте черновик и попросите отзыв по конкретным секциям.

НЕ ДЕЛАЙТЕ: пропускать Discovery — никогда не пишите PRD, не задав хотя бы 2 уточняющих вопроса; выдумывать ограничения — если пользователь не указал техстек, спросите или пометьте как TBD.

Пример: интеллектуальная система поиска

1. Резюме

Проблема: пользователям трудно находить конкретные фрагменты документации в огромных репозиториях.
Решение: интеллектуальная система поиска, дающая прямые ответы со ссылками на источники.
Успех: сократить время поиска на 50%; точность цитирования >= 95%.

2. User stories

История: как разработчик, я хочу задавать вопросы на естественном языке, чтобы не угадывать ключевые слова.
Критерии приёмки: поддержка многоходового уточнения; возврат код-блоков с кнопкой «Copy».

3. Архитектура ИИ-системы

Нужные инструменты: codesearch, grep, webfetch.

4. Оценка

Бенчмарк: тест на 50 частых вопросах разработчиков.
Порог прохождения: 90% должны совпадать с ожидаемыми цитатами.