Jak napíšete kvalitní dokument požadavků na produkt (PRD)?

Question

Accepted Answer

**Dokument požadavků na produkt (PRD)** vysvětluje *co* stavíte, *proč* a *jak poznáte, že to funguje* — aby inženýři a designéři mohli stavět správnou věc bez neustálého vyjasnění. Dobrý PRD je myšlenkovým nástrojem a artefaktem alignment, ne byrokrací.

## Solidní osnova PRD

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## Začněte s důvodem

Nejdůležitější sekce je **problém a cíle**. Pokud tým rozumí *proč* a *jak vypadá úspěch*, často najdou lepší řešení než to, které jste specifikovali. PRD, který je pouze specifikací funkcí, to postrádá.

## Non-goals jsou nedocenění

Explicitní vymezení toho, co je mimo rozsah, zabraňuje rozšiřování rozsahu a pasti "již, když jsme u toho...". Je to stejně cenné jako samotné požadavky.

## Časté chyby

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## Proč to má smysl

Většina přepracování pochází z nesouladu: tým vytvořil, co bylo požadováno, ne co bylo potřeba.

Jasný PRD odhalí tyto mezery *předtím*, než někdo napíše kód.

Zároveň vás to nutí *vy* si problém promyslet.

Pokud nemůžete jasně napsat cíl a metriku úspěchu, nerozumíte problému dostatečně dobře, abyste jej mohli stavět.