Kako napisati dobar dokument zahtjeva proizvoda (PRD)?

Question

Accepted Answer

**Product Requirements Document (PRD)** objašnjava *što* gradite, *zašto* i *kako ćete znati da je to radilo* — kako bi inženjerstvo i dizajn mogli graditi pravu stvar bez stalnih pojašnjenja. Dobar PRD je alat za razmišljanje i artefakt usklađivanja, a ne birokratski papir.

## Čvrsti PRD okvir

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

## Počnite s razlogom

Najvažniji odjeljak je **problem i ciljevi**. Ako tim razumije *zašto* i *kako izgleda uspjeh*, često će pronaći bolja rješenja od onoga što ste naveli. PRD koji je samo specifikacija značajke to propušta.

## Bez-ciljevi su podcijenjeni

Izričito navedene stvari koje su izvan opsega sprječavaju proširenje opsega i zamku "dok smo već na tome...". Jednako je vrijedno kao i sami zahtjevi.

## Česti nedostaci

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

## Zašto je to važno

Već rada dolazi iz neusklađenosti: tim je izgradio ono što je traženo, ne ono što je trebalo.

Jasna PRD dovodi te razmake u vidljivo *prije* nego što tko napiše kod.

Força vas da *promislite* na problem.

Ako ne možete jasno napisati cilj i metriku uspjeha, ne razumijete problem dovoljno dobro da ga izgradite sada.