Šablona PRD v Markdownu:zkopírujte ji a vyplňte.

Dokument s požadavky na produkt se nejsnáz udržuje v souboru .md vedle kódu. Tahle šablona je krátká, má číslované požadavky a ověřitelná kritéria přijetí a je napsaná tak, aby podle ní mohl stavět AI agent.

macOS 14 nebo novější. Čtení je zdarma; úpravy a revize se platí jednou.

Rychlá odpověď

Dobré PRD uvádí problém, cíle a co je mimo rozsah, pak vypíše číslované požadavky s kritérii přijetí, která lze ověřit. Uložte ho jako prd.md nebo docs/prd/feature-name.md, zkopírujte šablonu níže a každou sekci vyplňte prostými větami.

# PRD: <Feature name>

## 1. Problem
## 2. Goals
## 3. Non-goals
## 5. Requirements
## 6. Acceptance criteria

·

Šablona

Zkopírujte ji do nového souboru a nahraďte vše ve špičatých závorkách. Sekci smažte, jen když jste si jistí, že se netýká věci, a místo prázdného místa napište „žádné“, aby čtenář poznal, že se o ní uvažovalo.

# 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>.

Proč je napsaná takhle

PRD pro AI agenta má stejný úkol jako PRD pro člověka, jen s menším prostorem pro dohady. Člověk se vás na chodbě zeptá, co jste měli na mysli. Agent mezeru vyplní nejlepším odhadem a jede dál.

  • Necíle jsou nejlevnější ochrana proti rozrůstání rozsahu. Agenti přidávají „užitečné“ extra, pokud jim neřeknete, ať to nedělají.
  • Číslované požadavky (R1, R2) umožní plánu, testu i komentáři z revize odkazovat na totéž.
  • Kritéria přijetí jako políčka úkolového seznamu se změní v seznam úkolů, které lze odškrtávat. Syntaxi viz úkolové seznamy v Markdownu.
  • Okrajové případy jsou místo, kde vygenerovaný kód selhává jako první: prázdná data, špatný vstup, ztracené připojení.
  • Návrat zpět vás donutí promyslet, jak změnu vrátit, ještě než ji nasadíte.

Jak ho vyplnit

  1. Napište problém bez řešení

    Pokud nedokážete problém popsat, aniž byste pojmenovali funkci, funkce je jen odhad. Řekněte, koho se týká a co se děje dnes.

  2. Každý cíl udělejte měřitelný

    „Rychlejší pokladna“ je přání. „Medián pokladny pod 30 sekund“ je cíl.

  3. Požadavky pište jako chování

    „Systém musí zobrazit chybu, když je soubor větší než 10 MB“ se dá otestovat. „Dobré zpracování chyb“ ne.

  4. Ke každému požadavku přidejte kritérium

    Použijte schéma Given, when, then (Je dáno, když, pak). Pokud kontrolu nedokážete napsat, požadavek je vágní.

  5. Skončete otevřenými otázkami

    U každé uveďte vlastníka. Agent se na ně má ptát, ne je rozhodovat.

Diagramy pomáhají u toků a stavů; blok Mermaid v souboru se snadno mění. Viz syntaxe vývojových diagramů Mermaid.

Předání PRD AI agentovi

Agenta nasměrujte na soubor, ne ho vkládejte: „Přečti docs/prd/export.md a navrhni plán; zatím nepiš kód.“ Nejdřív požádejte o plán, porovnejte ho s číslovanými požadavky a pak nechte agenta stavět. PRD, plán a seznam úkolů jsou obvykle tři oddělené soubory. PRD říká co a proč, plán říká jak a úkoly jsou kroky.

Pravidla pro celý projekt (příkazy, styl, složky) držte mimo PRD v CLAUDE.md nebo AGENTS.md, aby PRD obsahovalo jen to, co je specifické pro tuto funkci.

Časté chyby

  • Řešení převlečené za problém. „Potřebujeme rozbalovací seznam“ není problém.
  • Žádné necíle. Všechno okolo se stane součástí rozsahu.
  • Požadavky, které nemohou selhat. Pokud by je žádný test nikdy nemohl neprojít, nic neříkají.
  • PRD, které už nikdo nečte. Aktualizujte stav a otevřené otázky průběžně.
  • Deset stran na malou změnu. Funkci na jeden den stačí půl stránky.

Produktoví manažeři mohou PRD číst a revidovat v DotMD jako vykreslené dokumenty, s komentáři přímo k danému místu. Čtení je zdarma; úpravy a revize viz ceník.

Otázky k šablonám PRD v Markdownu

Co patří do šablony PRD?

Problém, cíle, necíle, uživatelské scénáře, číslované požadavky, kritéria přijetí, okrajové případy, data a rozhraní, metriky úspěchu, nasazení a návrat zpět a otevřené otázky.

Proč psát PRD v Markdownu?

Soubor Markdown leží vedle kódu, má čitelnou historii v Gitu, AI agent ho snadno přečte a lze ho revidovat a měnit jako jakýkoli jiný soubor.

Jak soubor pojmenovat?

prd.md pro jediný produkt, nebo docs/prd/feature-name.md, když jich je víc. Jedna funkce v jednom souboru.

Čím se PRD liší od specifikace?

PRD říká, co postavit a proč, z pohledu uživatele. Specifikace nebo plán říká, jak se to postaví. Držte je odděleně, aby šlo každé revidovat samostatně.

Další otázky