¿Cómo recopila y aclara los requisitos?

Question

Accepted Answer

**Recopilación de requisitos** es el proceso de averiguar qué necesita construirse realmente — y *por qué* — antes de construirlo. El error más grande que cometen los novatos es tomar una solicitud literalmente sin entender el problema subyacente.

## Cómo abordarlo

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

## Distinga la solicitud de la necesidad

Un interesado dice "agregue un botón export-to-PDF." La necesidad real podría ser "necesito compartir reportes con mi jefe." El correo electrónico, un enlace compartido o un panel podrían resolverlo mejor. Preguntar *por qué* abre mejores soluciones.

## Buenas preguntas aclaratorias

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

## Una trampa común

Asumir que entendiste y comenzar a construir. Siempre refleja los requisitos — "así que lo que necesita es X, antes de Y, y Z está fuera del alcance?" — para detectar brechas temprano.

## Por qué es importante

Un error de requisitos fijo en la etapa de idea cuesta minutos; el mismo error encontrado después del lanzamiento cuesta días o semanas de reelaboración.

Los requisitos claros son el seguro más económico contra construir lo incorrecto.

Preguntar *por qué* te convierte de un simple tomador de órdenes en un solucionador de problemas.