Шаблон PRD в Markdown:скопируйте и заполните.

Шаблон

Скопируйте его в новый файл и замените всё, что в угловых скобках. Удаляйте раздел, только если уверены, что он не относится к делу, и пишите «нет» вместо пустого места, чтобы читатель видел, что об этом думали.

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

Почему он написан именно так

У PRD для ИИ-агента та же задача, что и для человека, но с меньшим простором для догадок. Человек спросит вас в коридоре, что вы имели в виду. Агент заполнит пробел лучшей догадкой и пойдёт дальше.

• Не-цели — самая дешёвая защита от разрастания объёма. Агенты добавляют «полезные» мелочи, если не сказать им не делать этого.
• Пронумерованные требования (R1, R2) позволяют плану, тесту и комментарию ревью ссылаться на одно и то же.
• Критерии приёмки как флажки списка задач превращаются в список дел, который можно отмечать. Синтаксис см. в статье списки задач в Markdown.
• Пограничные случаи — то, на чём сгенерированный код ломается первым: пустые данные, неверный ввод, потеря соединения.
• Откат заставляет подумать, как отменить изменение, ещё до выпуска.

Как его заполнять

1. Опишите проблему без решения

   Если вы не можете описать проблему, не назвав функцию, значит, функция — догадка. Скажите, кого это касается и что происходит сегодня.

2. Сделайте каждую цель измеримой

   «Быстрее оформление заказа» — пожелание. «Медианное время оформления меньше 30 секунд» — цель.

3. Пишите требования как поведение

   «Система должна показать ошибку, если файл больше 10 МБ» можно проверить. «Хорошая обработка ошибок» нельзя.

4. К каждому требованию — свой критерий

   Используйте схему «Дано, когда, тогда» (Given, when, then). Если проверку написать не получается, требование расплывчатое.

5. Закончите открытыми вопросами

   Назовите ответственного за каждый. Агент должен спрашивать о них, а не решать их.

Диаграммы помогают для потоков и состояний; блок Mermaid в файле легко менять. См. синтаксис блок-схем Mermaid.

Передача PRD ИИ-агенту

Указывайте агенту файл, а не вставляйте текст: «Прочитай docs/prd/export.md и предложи план; пока не пиши код». Сначала попросите план, сверьте его с пронумерованными требованиями, потом позволяйте писать. PRD, план и список задач обычно три отдельных файла. PRD говорит, что и зачем, план — как, а задачи — это шаги.

Правила для всего проекта (команды, стиль, папки) держите вне PRD, в CLAUDE.md или AGENTS.md, чтобы в PRD было только то, что относится к этой функции.

Частые ошибки

• Решение под видом проблемы. «Нам нужен выпадающий список» — не проблема.
• Нет не-целей. Всё рядом оказывается в объёме работы.
• Требования, которые не могут не выполниться. Если никакой тест не может их провалить, они ничего не говорят.
• PRD, который никто не перечитывает. Обновляйте статус и открытые вопросы по ходу работы.
• Десять страниц на мелкое изменение. Функции на один день хватит полстраницы.

Менеджеры продукта могут читать PRD и проверять их в DotMD как отрисованные документы, с комментариями к конкретному месту. Чтение бесплатно; о редактировании и ревью см. цены.

Вопросы о шаблонах PRD в Markdown

Другие вопросы