Como você coleta e clarifica requisitos?

Question

Accepted Answer

**Coleta de requisitos** é o processo de descobrir o que realmente precisa ser construído — e *por quê* — antes de construir. O maior erro que juniores cometem é tomar uma solicitação literalmente sem entender o problema subjacente.

## Como abordar isso

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

## Diferencie a solicitação da necessidade

Um stakeholder diz "adicione um botão de exportação para PDF." A necessidade real pode ser "preciso compartilhar relatórios com meu chefe." E-mail, um link compartilhado ou um painel podem resolver melhor. Perguntar *por quê* abre soluções melhores.

## Boas perguntas de esclarecimento

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

## Uma armadilha comum

Supor que entendeu e começar a construir. Sempre reflita os requisitos — "então o que você precisa é X, por Y, e Z está fora do escopo?" — para capturar lacunas cedo.

## Por que isso importa

Um erro de requisitos corrigido na fase de ideia custa minutos; o mesmo erro encontrado após o lançamento custa dias ou semanas de retrabalho.

Requisitos claros são o seguro mais barato contra construir a coisa errada.

Perguntar *por quê* o transforma de um mero seguidor de ordens em um solucionador de problemas.