Jak zbierasz i wyjaśniasz wymagania?

Question

Accepted Answer

**Zbieranie wymagań** to proces dowiedzenia się, co faktycznie musi być zbudowane — i *dlaczego* — zanim się to buduje. Największym błędem juniorów jest dosłowne traktowanie prośby bez zrozumienia leżącego u jej podstaw problemu.

## Jak do tego podejść

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

## Rozróżnij prośbę od potrzeby

Stakeholder mówi "dodaj przycisk eksportu do PDF". Rzeczywista potrzeba może być "muszę udostępnić raporty swojemu szefowi". Email, udostępniony link lub pulpit nawigacyjny mogą to rozwiązać lepiej. Pytanie *dlaczego* otwiera lepsze rozwiązania.

## Dobre pytania wyjaśniające

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

## Częsta pułapka

Założenie, że zrozumiałeś i rozpoczęcie budowania. Zawsze powtórz wymagania — "więc to, czego potrzebujesz, to X, do Y, a Z jest poza zakresem?" — aby wcześnie wychwycić luki.

## Dlaczego to ważne

Błąd wymagań naprawiony na etapie pomysłu kosztuje minuty; ten sam błąd znaleziony po wydaniu kosztuje dni lub tygodnie pracy nad zmianami.

Jasne wymagania to najtańsze ubezpieczenie przed zbudowaniem złej rzeczy.

Pytanie *dlaczego* zmienia cię z osoby przyjmującej zlecenia na osobę rozwiązującą problemy.