Come raccogli e chiarisci i requisiti?

Question

Accepted Answer

**La raccolta dei requisiti** è il processo di scoprire cosa effettivamente deve essere costruito — e *perché* — prima di costruirlo. L'errore più grande che commettono i junior è prendere una richiesta alla lettera senza capire il problema sottostante.

## Come affrontarlo

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

## Distingui la richiesta dal bisogno

Un stakeholder dice "aggiungi un pulsante di esportazione in PDF." Il vero bisogno potrebbe essere "Ho bisogno di condividere i report con il mio capo." L'email, un link condiviso o una dashboard potrebbero risolverlo meglio. Chiedere *perché* apre soluzioni migliori.

## Buone domande di chiarimento

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

## Un errore comune

Assumare di aver capito e iniziare a costruire. Rifletti sempre i requisiti — "quindi quello che ti serve è X, entro Y, e Z è fuori portata?" — per rilevare le lacune in anticipo.

## Perché è importante

Un errore di requisiti fisso nella fase di idea costa minuti; lo stesso errore trovato dopo il rilascio costa giorni o settimane di rework.

I requisiti chiari sono l'assicurazione più economica contro la costruzione della cosa sbagliata.

Chiedere *perché* ti trasforma da chi esegue ordini a chi risolve problemi.