Jak shromažďujete a objasňujete požadavky?

Question

Accepted Answer

**Shromažďování požadavků** je proces zjištění, co opravdu musí být postaveno — a *proč* — před jeho postavením. Největší chybou juniorů je doslova si vzít požadavek bez pochopení základního problému.

## Jak k tomu přistoupit

```text
1. ASK WHY → understand the problem behind the request, not just the request
2. TALK to the real users / stakeholders, not just the requester
3. CLARIFY scope → what's in, what's out, what "done" looks like
4. SURFACE assumptions and constraints (deadlines, budget, tech limits)
5. WRITE IT DOWN → confirm your understanding back to them
```

## Rozlišit žádost od potřeby

Stejkholdr říká "přidat tlačítko export-to-PDF." Skutečná potřeba může být "potřebuji sdílet zprávy se svým šéfem." E-mail, sdílený odkaz nebo přístrojová deska by to mohly vyřešit lépe. Ptaní se *proč* otevírá lepší řešení.

## Dobré objasňující otázky

```text
✓ "What problem does this solve for the user?"
✓ "What happens today without it?"
✓ "How will we know it worked?"
✓ "What's explicitly out of scope?"
✓ "What are the edge cases / what could go wrong?"
```

## Běžná chyba

Předpokládat, že jste porozuměli a začít stavět. Vždy si reflektujte požadavky zpět — "takže to, co potřebujete, je X, do Y a Z je mimo rozsah?" — abyste brzy zachytili mezery.

## Proč na tom záleží

Chyba fixních požadavků v etapě nápadu stojí minuty; stejná chyba nalezená po vydání stojí dny nebo týdny переделky.

Jasné požadavky jsou nejlevnějším pojištěním proti stavbě špatné věci.

Ptaní se *proč* vás změní ze člověka, který přijímá příkazy, na řešitele problémů.