Kako napišeš dobro Product Requirements Document (PRD)?

Question

Accepted Answer

A **Product Requirements Document (PRD)** pojasni *kaj* gradíš, *zakaj*, in *kako veš, da je delovalo* — torej inženirjem in oblikovalcem omogoči, da zgradijo pravo stvar brez stalnega pojasnjevanja. Dober PRD je orodje za razmišljanje in artefakt za usklajitev, ne pa birokratski papir.

## Solidna struktura 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čni s »zakaj«

Najpomembnejši del je razdelek **problem in cilji**. Če ekipa razume *zakaj* in *kako izgleda uspeh*, pogosto najdejo boljše rešitve kot tista, ki si jo navedel. PRD, ki je samo specifikacija funkcionalnosti, to zamudi.

## Niso-cilji so podcenjeni

Natančno navedba, kaj je izven obsega, preprečuje razširjanje obsega in past »medtem ko smo že pri tem...«. To je enako dragocene kot zahteve same.

## Pogosti napadi

```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
```

## Zakaj je to pomembno

Večina ponovnega dela izhaja iz neskladja: ekipa je zgradila, kar je bilo zahtevano, ne pa, kaj je bilo potrebno.

Jasen PRD razkriva te vrzeli *preden* kdo napiše kodo.

Tudi te prisili, da *sam* premisliš problem.

Če ne moreš jasno napisati cilja in metrike uspeha, dovolj dobro ne razumeš problema, da bi ga zgradil.