Šablona specifikace požadavků na produkt (PRD) (+ kompletní zpracovaný příklad ke zkopírování)

Šablona specifikace požadavků na produkt (PRD) (+ kompletní zpracovaný příklad ke zkopírování)

Naposledy aktualizováno: 28. července 2026.

Většina stránek se šablonou specifikace požadavků na produkt vám dá jen prázdný formulář. Atlassian nabízí čtyři sekce instrukcí kolem prázdné tabulky metrik úspěchu. Product School má v názvu „(with Example)“, ale žádný příklad neobsahuje. Markdown blok o 12 sekcích níže je celá šablona, bez nutnosti registrace, připravená ke zkopírování. Sekce 4 pak vyplní všech těch 12 sekcí na kompletním zpracovaném příkladu: portál pro faktury klienta, který čte PDF pomocí LLM a nejisté případy směruje na člověka. Zkopírujte prázdnou. Přečtěte si vyplněnou. Napište svou.

Klíčové poznatky

• PRD odpovídá na otázku, co stavět a proč; technický návrhový dokument odpovídá na otázku jak.
• 12 sekcí se hodí pro projekt jakékoli velikosti. Jednostránkový dokument (one-pager) je stejná šablona jen s menším počtem řádků.
• Non-goals (co se v této fázi nebude dělat) musí být zapsané. AI coding agent nedokáže odvodit rozsah z toho, co chybí.
• Akceptační kritéria musí být strojově ověřitelná: „p95 pod 400 ms“, nikdy „rychlé“.

Jakou podobu PRD zvolit?

Podobu volte podle toho, kdo dokument bude číst, ne podle toho, jak velký produkt vypadá. Jedna funkce určená vlastním vývojářům potřebuje jednostránkový dokument. Build předaný externímu týmu potřebuje plnou 12sekční PRD, protože akceptační kritéria zároveň slouží jako schvalovací brány. Specifikace pro AI coding agenta potřebuje stejných dvanáct sekcí, jen rozdělených do fází.

Jednostránková šablona specifikace požadavků na produkt, o kterou si všichni říkají, není samostatný artefakt. Široce kopírovaný one-pager Lennyho Rachitského, publikovaný s reálnými příklady v jeho newsletteru, je stejná kostra jen zbavená formalit. One-pager není jiný dokument. Je to stejných dvanáct sekcí, jen s vymazanými prázdnými řádky.

Agilní týmy si tuto otázku kladou taky často, obvykle ve znění, jestli PRD obstojí, jakmile existuje backlog. Obstojí, ve formě one-pageru: PRD drží proč a hranice, tickety drží samotnou práci.

Šablona PRD (markdown ke zkopírování)

Tady je celá věc jako markdown, volně dostupná, bez nutnosti zadávat e-mail. Vložte ji do Notion, Confluence, Google Docs, Linear, Wordu, nebo ji commitněte do GitHubu jako PRD.md a nechte ji verzovat spolu s kódem. Lidé si o tuto šablonu říkají v devíti různých formátech; markdown je ten, který přežije vložení do všech z nich, a je to jediný formát, který AI coding agent přečte čistě.

# PRD: [Název produktu nebo funkce]

## 1. Záhlaví
- Vlastník (produkt):
- Vedoucí vývoje:
- Vedoucí designu:
- Stav: Návrh | V revizi | Schváleno | Nasazeno
- Naposledy aktualizováno:
- Historie změn: datum / autor / co se změnilo

## 2. Popis problému
Jeden odstavec. Koho to bolí, jak často, kolik to dnes stojí. Bez jazyka řešení.

## 3. Cíle a metriky úspěchu
| Cíl | Metrika | Výchozí hodnota | Cíl | Měřeno pomocí | Datum |
|---|---|---|---|---|---|

## 4. Non-goals
Formulováno pozitivně: „Tato fáze nezahrnuje X.“

## 5. Uživatelé a persony
Kdo to používá, co už ví, na jakém zařízení, jak často.

## 6. Uživatelské příběhy a akceptační kritéria
Jako [persona] chci [akce], abych [výsledek].
- Given [kontext], when [událost], then [pozorovatelný výsledek].

## 7. Funkční požadavky
Číslované. Jeden požadavek na řádek. Testovatelné. Žádná věta neobsahuje slovo „a“.

## 8. Nefunkční požadavky
Výkon / zabezpečení a multi-tenancy / umístění a uchovávání dat / přístupnost / dostupnost.

## 9. Závislosti a integrace
Externí systémy, API, přístupové údaje, kdo vlastní přístup, doba realizace.

## 10. Milníky a fázování
| Fáze | Rozsah | Kritéria dokončení | Cílové datum |
|---|---|---|---|

## 11. Otevřené otázky a rizika
| Otázka nebo riziko | Vlastník | Potřeba do | Dopad, pokud zůstane nezodpovězeno |
|---|---|---|---|

## 12. Přílohy a odkazy
Návrhy, výzkum, poznámky ke konkurenci, předchozí tickety, smlouvy.

Dvanáct sekcí v pořadí: záhlaví, popis problému, cíle a metriky úspěchu, non-goals, uživatelé a persony, uživatelské příběhy s akceptačními kritérii, funkční požadavky, nefunkční požadavky, závislosti a integrace, milníky a fázování, otevřené otázky a rizika, přílohy.

Co má PRD obsahovat? 12 sekcí a jejich slabá verze

Specifikace požadavků na produkt by měla obsahovat popis problému, měřitelné cíle, explicitní non-goals, persony, uživatelské příběhy s akceptačními kritérii, funkční a nefunkční požadavky, závislosti, milníky, otevřené otázky s vlastníky a historii změn. Všechno ostatní je příloha. Test pro každý řádek je stejný, jaký ISO/IEC/IEEE 29148:2018 aplikuje na požadavky obecně: ověřitelný, jednoznačný, jednotný.

Většina PRD tímto testem neprojde na stejných třech místech.

Dvě sekce si zaslouží víc pozornosti, než obvykle dostávají.

Nefunkční požadavky jsou místo, kde se rozsah tiše zdvojnásobí. Výkon, multi-tenancy, umístění dat, uchovávání, přístupnost, dostupnost: každá z těchto věcí je inženýrské rozhodnutí s nákladem a žádná z nich se neobjeví v uživatelském příběhu. Bezpečnostní řádek patří sem, ne do vágního mávnutí rukou, a napište ho tak, jak byste chtěli, aby byl ověřen — jako zdrojový seznam použijte třeba náš kontrolní seznam zabezpečení před spuštěním. Pokud build obsahuje AI komponentu, patří sem i požadavky na produkční připravenost, ne do pozdější fáze „zpevňování“, která se nikdy nedostane do harmonogramu: verzi, kterou používáme my, najdete v našem kontrolním seznamu PoC do produkce.

Otevřené otázky potřebují tři sloupce, ne jeden. Otázka, vlastník, termín potřeby. Otázka bez vlastníka je rozhodnutí, které nikdo nedělá, a v šestém týdnu se objeví jako change request. Stojí za zmínku: PRD píšete až poté, co jste se rozhodli stavět místo kupovat. Pokud popis problému stále čte jako nákupní seznam funkcí, rozhodnutí build vs. buy ve skutečnosti ještě nepadlo.

Zpracovaný příklad: PRD portálu pro faktury, vyplněné

Tady je kompletní zpracovaný příklad, se všemi vyplněnými 12 sekcemi. Build: portál pro faktury klienta pro středně velkého logistického operátora. Zákazníci nahrávají PDF faktury, LLM extrahuje jednotlivé položky, systém označuje nesrovnalosti oproti záznamu objednávky a cokoli, čím si není jistý, jde do fronty na lidskou kontrolu. Stack: Next.js, Supabase/Postgres, jeden krok extrakce pomocí LLM. Zkopírujte si ho, vytiskněte, exportujte do PDF, cokoli potřebujete.

# PRD: Portál pro faktury klienta, fáze 1

## 1. Záhlaví
- Vlastník (produkt): Provozní ředitel, strana klienta
- Vedoucí vývoje: Delivery lead, Techsy
- Vedoucí designu: Produktový designér, Techsy
- Stav: Schváleno k realizaci
- Naposledy aktualizováno: 2026-07-28
- Historie změn:
  - 2026-07-14 / produkt / první návrh
  - 2026-07-21 / vývoj / přidáno pravidlo prahu jistoty do 6.2
  - 2026-07-28 / produkt / zápis zpět do ERP přesunut do non-goals

## 2. Popis problému
Provozní pracovníci dostávají zákaznické faktury jako PDF v e-mailu a ručně je
přepisují do systému objednávek. Objem přesahuje 300 faktur týdně, průměrná
doba zpracování je asi 6 minut na fakturu a přibližně 4 % obsahují chybu
přepisu, která se odhalí až při měsíční rekonciliaci. Každá oprava stojí druhé
kolo práce a telefonát.

## 3. Cíle a metriky úspěchu
| Cíl | Metrika | Výchozí hodnota | Cíl | Měřeno pomocí | Datum |
|---|---|---|---|---|---|
| Snížit ruční zpracování | Prům. doba zpracování | 6 min | pod 90 sek | Provozní dashboard, týdenní medián | 2026-11-01 |
| Snížit chyby přepisu | Faktury opravené při rekonciliaci | 4 % | pod 1 % | Měsíční finanční report | 2026-12-01 |
| Omezit zátěž kontroly | Podíl směrovaný na lidskou kontrolu | n/a | pod 25 % | Metriky fronty portálu | 2026-11-01 |

## 4. Non-goals
Tato fáze nepodporuje faktury ve více měnách, zápis zpět do ERP, samoobslužné
dobropisy pro zákazníky ani mobilní aplikaci. Extrakce pokrývá pouze PDF.
Fotografie papírových faktur a skeny pod 200 DPI jsou při nahrání odmítnuty
se zprávou vysvětlující proč.

## 5. Uživatelé a persony
- Provozní referent (primární, 6 lidí): celý den pracuje s frontou výjimek,
  hluboká znalost domény, pouze desktop.
- Kontaktní osoba za zákaznické účetnictví (externí, ~140 účtů): nahrává
  faktury, nízká tolerance ke komplikacím při zakládání účtu.
- Finanční manažer (sekundární): stahuje měsíční report, potřebuje auditní
  stopu pro každou fakturu.

## 6. Uživatelské příběhy a akceptační kritéria
6.1 Jako kontaktní osoba za zákaznické účetnictví chci nahrát PDF faktury,
abych ji nemusel/a posílat e-mailem a čekat.
- Given PDF do 20 MB při rozlišení 200 DPI nebo lepším, when ji nahraji,
  then portál vrátí referenční číslo do 5 sekund a zobrazí „Zpracovává se“.

6.2 Jako provozní referent chci, aby extrakce s nízkou jistotou byly
zadrženy, aby se nic špatného automaticky neschválilo.
- Given zpracovanou fakturu, when je jistota extrakce u kterékoli položky
  pod 0.85, then se faktura přesměruje do fronty na kontrolu a nikdy se
  automaticky neschválí.

6.3 Jako provozní referent chci vidět nesrovnalost na jednom místě, abych
ji mohl/a vyřešit bez otevírání systému objednávek.
- Given fakturu spárovanou s objednávkou, when se množství nebo jednotková
  cena kterékoli položky liší od záznamu objednávky, then portál zobrazí obě
  hodnoty vedle sebe a označí rozdíl.

6.4 Jako finanční manažer chci filtrovat faktury, abych mohl/a uzavřít
měsíc.
- Given seznam faktur, when filtruji podle dodavatele, časového rozsahu a
  stavu, then se výsledky vrátí do 400 ms při p95 a prázdný stav nabízí
  „Vymazat filtry“.

## 7. Funkční požadavky
1. Nahrávání přijímá pouze PDF, maximálně 20 MB, jeden soubor na odeslání.
2. Extrakce vrací dodavatele, číslo faktury, datum, měnu a položky s
   množstvím, jednotkovou cenou a celkovou částkou.
3. Každá položka nese skóre jistoty mezi 0 a 1.
4. Párování porovnává extrahovanou fakturu s otevřenou objednávkou podle
   čísla PO.
5. Výjimky vstupují do fronty seřazené od nejstarší, přiřaditelné jednomu
   referentovi.
6. Každá změna stavu zapíše auditní záznam s aktérem, časovým razítkem a
   předchozí hodnotou.
7. Schválené faktury se exportují jako dávka CSV pro finanční systém.

## 8. Nefunkční požadavky
- Výkon: seznam faktur p95 pod 400 ms. Extrakce se dokončí do 90 sekund od
  nahrání při p95.
- Zabezpečení a multi-tenancy: izolace jednotlivých tenantů vynucená na
  úrovni řádků databáze. Zákazník nikdy nemůže číst fakturu jiného zákazníka.
  Ověřováno automatizovaným testem při každém vydání.
- Umístění a uchovávání dat: dokumenty uloženy v EU. Originály uchovávány 7
  let, extrahovaná data 90 dní.
- Přístupnost: fronta plně ovladatelná klávesnicí, kontrast dle WCAG 2.2 AA.
- Dostupnost: 99.5 % měsíčně, podpora v pracovní době.

## 9. Závislosti a integrace
- Záznamy objednávek: read-only replika Postgres. Přístup vlastní IT
  klienta, přístupové údaje potřeba do 2026-08-15.
- Poskytovatel LLM extrakce: smlouva a smlouva o zpracování dat podepsané
  před zahájením buildu.
- E-mailová oznámení: existující transakční poskytovatel, doména odesílatele
  ověřená klientem.

## 10. Milníky a fázování
| Fáze | Rozsah | Kritéria dokončení | Cílové datum |
|---|---|---|---|
| P1 | Nahrávání, extrakce, směrování podle jistoty | 50 reálných faktur end to end, pod 25 % ve frontě | 2026-09-19 |
| P2 | Párování objednávek a zobrazení nesrovnalostí | Nesrovnalost správně označena u 20 testovacích případů | 2026-10-10 |
| P3 | Auditní stopa, export CSV, reporting | Finance uzavře jeden měsíc v portálu | 2026-11-01 |

## 11. Otevřené otázky a rizika
| Otázka nebo riziko | Vlastník | Potřeba do | Dopad, pokud zůstane nezodpovězeno |
|---|---|---|---|
| Které číslo PO je závazné, pokud faktura uvádí dvě? | Provozní ředitel klienta | 2026-08-08 | Zablokovaná logika párování |
| Posílá 12 největších zákazníků skenované nebo nativní PDF? | Delivery lead | 2026-08-08 | Práh jistoty může být špatně nastavený |
| Je 7leté uchovávání potvrzené s právním oddělením klienta? | Finanční manažer klienta | 2026-08-22 | Změní se návrh úložiště a náklady |
| Náklad na extrakci na fakturu při 300/týden | Delivery lead | 2026-09-05 | Neznámá jednotková ekonomika |

## 12. Přílohy a odkazy
Anonymizovaná ukázková sada faktur (40 souborů), schéma tabulky objednávek,
aktuální studie doby zpracování, Figma flows pro nahrávání a frontu, podepsaný
statement of work.

Čtyři rozhodnutí v tomto dokumentu stojí za zmínku, protože líná verze každého z nich stojí reálné peníze.

Sekce 3, výchozí hodnota. „6 minut“ není ozdoba. Bez výchozí hodnoty nepoznáte, jestli to fungovalo, a o šest měsíců později se o tom někdo hádá na poradě bez jakýchkoli dat. Líná verze, „zlepšit efektivitu“, dělá z projektu něco, co nelze vyvrátit.

Sekce 4, non-goal. Zápis zpět do ERP se přesunul do non-goals dne 2026-07-28, poté co byl při revizním hovoru automaticky předpokládán jako součást zadání. Zapsat ho jako non-goal stálo jeden řádek a ušetřilo hádku o rozsah.

Sekce 6.2, práh jistoty. Toto je pravidlo, které v našich vlastních prvních návrzích chybí nejčastěji. Vynechte ho a systém automaticky schválí faktury, které měl vidět člověk — přesně to smaže úsporu času, kterou jste slíbili v sekci 3.

Sekce 11, vlastníci. Každá otevřená otázka má jméno a datum. Tento sloupec je rozdíl mezi dokumentem a to-do listem, který nikdo nevlastní.

PRD vám řekne co. Neřekne vám, jak dlouho nebo za kolik — to je samostatné cvičení: viz stanovení rozsahu buildu pro tuto polovinu. A non-goal, který jste nezapsali, je funkce, kterou někdo postaví.

Jak napsat PRD, ze kterého AI coding agent skutečně dokáže stavět?

PRD napsané pro AI coding agenta vyměňuje stručnost za explicitnost. Agent nemá žádný neformální kontext z chodby, žádnou sdílenou historii a žádný instinkt pro to, co jste zjevně nemysleli vážně. Většinu rozdílu pokrývají čtyři pravidla, která vychází z pozorování, kdy specifikace uspěly a kdy selhaly napříč našimi vlastními builds s AI agenty.

1. Formulujte non-goals pozitivně. Lidé odvozují rozsah z toho, co chybí. Agenti ne. „V této fázi nepřidávejte autentizaci“ musí být věta v dokumentu, jinak se autentizace postaví, otestuje a předá vám zpátky.

2. Rozdělte práci na fáze. Jeden 40stránkový monolit vyprodukuje sebejistý, rozvětvený, napůl správný pull request. Rozdělte PRD na kroky, které agent dokončí v jednom ohraničeném běhu, každý s vlastními kritérii dokončení.

3. Udělejte akceptační kritéria strojově ověřitelná. „Rychlé“ není požadavek, je to nálada. „p95 pod 400 ms na endpointu se seznamem faktur“ je test, který agent umí napsat dřív, než napíše samotnou funkci.

4. Uveďte cesty k souborům a omezení stacku přímo v dokumentu, ne v chatu. Kontext chatu se mezi sezeními vytrácí. Specifikace ne. Proto je také důležitý plan mode v Claude Code: přečte vaše soubory a navrhne plán, aniž by cokoli upravoval, dokud ho neschválíte — a tento krok schválení je mnohem užitečnější, když se plán kontroluje proti napsané specifikaci místo vaší paměti toho, co jste vlastně chtěli.

Tady je portál pro faktury rozdělený do jedné fáze, kterou agent zvládne provést na jeden zátah.

# Úkol k realizaci: Nahrávání a extrakce faktur (fáze 1 ze 3)

## Omezení technologického stacku (nenahrazujte)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. Žádné nové závislosti bez předchozího dotazu.

## Soubory, které smíte vytvořit nebo upravit
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Nedotýkejte se
- lib/auth/*  (autentizace se dodá ve fázi 2; nyní nepřidávejte přihlašovací
  flow)
- Cokoli pod app/(marketing)/
- Existující schéma objednávek. Přečtěte si ho. Nikdy ho nemigrujte.

## Akceptační kritéria (napište je nejdřív jako testy)
1. POST /api/invoices odmítne soubory, které nejsou PDF, kódem 415 a
   soubory nad 20 MB kódem 413.
2. Položka s jistotou < 0.85 nastaví invoice.status = 'review', nikdy
   'approved'.
3. Každý insert zapíše auditní řádek s actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= vrátí odpověď do 400 ms na
   testovací sadě 10 000 řádků.

## Mimo rozsah tohoto kroku
Párování objednávek, UI pro nesrovnalosti, export CSV, e-mailová oznámení.

Oproti lidské verzi se změnily tři věci: objevily se cesty k souborům, objevil se seznam „nedotýkejte se“ a akceptační kritéria se z vět proměnila v tvrzení. Na tom, kterému agentovi to předáte, záleží méně, než si lidé myslí, i když srovnání coding agentů stojí za přečtení, než se rozhodnete. Požadavky a pravidla projektu držte v oddělených souborech: Cursor rules a CLAUDE.md drží konvence a nástroje, PRD drží to, co se má postavit. Pokud chcete pomoc AI přímo při tvorbě rozsahu, ne jen při jeho zpracování, to je jiný workflow. A pro samotný krok extrakce jsou volba modelu a evaluační smyčka samostatná práce na AI integraci.

Co se změní, když PRD jde k externímu týmu

Když PRD jde k agentuře nebo dodavateli, přestává být sladicím dokumentem a stává se smluvním jazykem. Nejasnost, kterou interní tým vyřeší dvouminutovou konverzací, se mění v change request s cenovkou. Studie PMI Pulse of the Profession zjistila, že 47 % neúspěšných projektů nesplní své cíle kvůli nepřesnému řízení požadavků. To je celý důvod, proč tento dokument existuje.

V tomto prostředí mají tři sekce neúměrnou váhu. Akceptační kritéria se stávají schvalovacími branami, takže musí být pozorovatelná i pro někoho, kdo není inženýr. Otevřené otázky potřebují jmenovaného vlastníka na straně klienta, protože dodavatel je nemůže zodpovědět a bude stavět kolem mezery. A historie změn přestává být byrokracií: je to záznam toho, co bylo kdy dohodnuto — a to je první věc, po které každý sáhne při sporu.

Řádek, u kterého jsme víc než jednou viděli, jak se to zvrtne, je nějaká verze věty „uživatelé mohou exportovat svá data“. Nikdo nenapíše, v jakém formátu. Nákladná verze tohoto se u nás projevila jako export CSV ve chvíli, kdy klient myslel formátovaný PDF balík faktur s vlastním brandingem, a přepracování spálilo zhruba týden vývoje, který nikdo nenaplánoval. Poctivé čtení je, že chyba seděla v dokumentu, ne v dodávce. Akceptační kritérium by to odhalilo za pět minut: given požadavek na export, when se soubor vygeneruje, then je to PDF odpovídající dodanému layoutu. Zachytil by to i řádek non-goals, z opačné strany. Takže teď máme v discovery pravidlo: jakýkoli požadavek visící na podstatném jménu jako „export“, „report“ nebo „notifikace“ dostane přiřazený formát, spouštěč a zpracovaný příklad ještě předtím, než se podepíše statement of work.

To je z velké části to, co naše řízení buildů webových aplikací skutečně znamená: proměnit vágní polovinu klientovy specifikace v testovatelné řádky ještě předtím, než se napíše jediný řádek kódu.

Co r/ProductManagement skutečně říká o šablonách PRD

Vyhledejte product requirements document template reddit a najdete stále stejnou stížnost opakující se na r/ProductManagement: přebujelost šablon. PRD, které nikdo nečte. Sekce vyplněné jen proto, že šablona měla nadpis, ne proto, že by obsah někdo potřeboval. Dokumenty, které zestárnou den po kickoffu a tiše je nahradí vlákno na Slacku. Je to oprávněná kritika většiny šablon, včetně několika z prvních deseti výsledků na tento dotaz.

Naše odpověď: sekce mažte, místo abyste je plnili ničím. Persony jdou pryč jako první, pokud jsou uživatelé zjevní. Přílohy jako druhé. Milníky mohou žít v trackeru místo v dokumentu. Jediná sekce, kterou nikdy nemažeme, jsou non-goals, protože je to jediná sekce, která se s odvedenou prací zkracuje, a jediná, která spolehlivě zabrání hádce, kterou byste jinak měli v šestém týdnu.

O autorovi

Mert Batur Gurbuz, spoluzakladatel, Techsy.io. Kvalifikace: spoluzakladatel, Techsy.io, University of Birmingham. LinkedIn

Mert Batur Gurbuz je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o nástrojovém stacku pro LLM, který tým Techsy skutečně používá v produkci.

Často kladené otázky

Co je specifikace požadavků na produkt?

Specifikace požadavků na produkt (PRD) říká, co tým staví a proč: problém, cíle a jejich metriky, non-goals, pro koho to je, a požadavky, které definují hotovo. Záměrně vynechává detaily implementace, které patří do technického návrhového dokumentu psaného později vývojem.

Jak napsat specifikaci požadavků na produkt?

Začněte popisem problému a v něm odmítněte používat jazyk řešení. Přidejte měřitelné cíle s výchozí hodnotou a cílovým datem, pak napište non-goals. Vyplňte persony, uživatelské příběhy s akceptačními kritérii ve stylu Given/When/Then, funkční a nefunkční požadavky, závislosti, milníky a otevřené otázky s vlastníky.

Co má PRD obsahovat?

Dvanáct sekcí: záhlaví s historií změn, popis problému, cíle a metriky úspěchu, non-goals, uživatelé a persony, uživatelské příběhy s akceptačními kritérii, funkční požadavky, nefunkční požadavky, závislosti a integrace, milníky a fázování, otevřené otázky a rizika a příloha. Cokoli, co se do některé z těchto kategorií nevejde, pravděpodobně není požadavek.

Jak dlouhé má PRD být?

Jedna až dvě strany pro jednu funkci, tři až pět pro fázi produktu, pět až osm, když ho staví externí tým a akceptační kritéria fungují jako schvalovací brány. Délka se řídí počtem zaznamenaných rozhodnutí, ne velikostí produktu. Prázdné sekce se mají mazat, ne vycpávat.

Je PRD totéž co BRD?

Ne. Business requirements document (BRD) popisuje komerční výsledek, který organizace chce, a omezení kolem něj, obvykle ještě předtím, než se vybere řešení. PRD popisuje produkt, který ho dodává: uživatele, chování, akceptační kritéria, non-goals. V menších firmách bývá BRD často jen sekcí popisu problému.

Píšou agilní týmy stále PRD?

Ano, obvykle jako one-pager. Backlog drží práci, ale tickety hrozně špatně drží proč, non-goals a metriku úspěchu. Týmy, které PRD úplně vynechají, ho mají tendenci znovuobjevit jako stránku na Confluence nazvanou „kontext“ tři sprinty do projektu.

Dá se PRD napsat v markdownu?

Markdown je pro to nejlepší formát. Čistě se vloží do Notion, Confluence, Google Docs a Linear, verzuje se v Gitu vedle kódu jako PRD.md, správně se diffuje v pull requestu a je to jediný formát, který AI coding agent přečte, aniž by ztratil strukturu. Šablona výše je v markdownu přesně z těchto důvodů.

Jak napsat PRD pro AI coding agenta?

Buďte explicitní tam, kde byste normálně byli struční. Formulujte non-goals pozitivně, protože agent nedokáže odvodit rozsah z toho, co chybí. Rozdělte dokument na fáze dokončitelné na jeden zátah. Pište akceptační kritéria jako tvrzení s čísly. Pojmenujte soubory, které agent smí upravit, a ty, kterých se nesmí dotknout.

Jaký je rozdíl mezi PRD a technickým návrhovým dokumentem?

PRD odpovídá na co a proč: problém, uživatelé, chování, akceptační kritéria, non-goals. Technický návrhový dokument odpovídá na jak: architektura, datový model, API kontrakty, zvažované kompromisy. První obvykle vlastní produkt, druhý vývoj, a návrhový dokument by měl jít číst jako odpověď na PRD.

Kdo vlastní PRD — produkt, vývoj, nebo klient?

Produkt vlastní dokument a rozhodnutí v něm. Vývoj vlastní zpětnou vazbu k proveditelnosti a nefunkční požadavky. U agenturních buildů vlastní klient popis problému, cíle a každou otevřenou otázku týkající se jeho vlastního byznysu. Sdílené vlastnictví celého dokumentu obvykle znamená, že ho nikdo neudržuje.

Na závěr

Tři věci k zapamatování. Šablona je užitečná až ve chvíli, kdy je vyplněná, takže si spíš okopírujte tvar zpracovaného příkladu než tu prázdnou. Non-goals je sekce s nejvyšší hodnotou na slovo v celém dokumentu a první, kterou lidé vynechávají. A akceptační kritéria napsaná jako testovatelná tvrzení slouží stejně dobře dvěma čtenářům: inženýrovi, který podepisuje dodávku, i agentovi, který píše test.

Pokud píšete PRD, které chcete předat externímu týmu, a chcete na něj druhý pár očí ještě předtím, než se stane součástí smlouvy, rádi si ho přečteme a označíme nejasné řádky. Je to stejný krok, jaký provádíme na našich vlastních buildech webových aplikací.