The Professor
Índice Índice del curso

Módulo 11 · Habilidades no técnicas

Lección 49 — Estimar y dividir problemas

Partir tareas grandes y comunicar trade-offs con honestidad.

Publicada
En esta lección
  1. Objetivos
  2. 1. El error del número único
  3. 2. El histórico: la memoria que la estimación pide
  4. 3. Dividir: entregables verticales, no horizontales
  5. 4. La comunicación del trade-off: el "sí, pero" estructurado
  6. 5. La estimación en el mundo del curso
  7. Autoevaluación

Stack: Habilidades · Proyecto: TicketFlow Estado: Publicada — estimar con honestidad y partir problemas grandes Prerrequisito: Lección 48 — Documentación y ADRs

Objetivos

  1. Estimar con rangos e incertidumbre declarada (no con números-facha): el método de la ancla, la descomposición y el histórico.
  2. Dividir un problema grande en entregables verticales que el negocio puede ver y el equipo puede terminar.
  3. Comunicar el trade-off cuando la estimación muerde: el "sí, pero" estructurado que vence al sí mudo y al no seco.

1. El error del número único

La pregunta "¿cuánto tarda esto?" merece la respuesta "entre X e Y, con esta incertidumbre" — el número único ("3 días") falsea la realidad: los problemas conocidos tienen variación, los desconocidos (la pasarela nueva, la migración del legado) tienen incertidumbre REAL. El método del curso:

markdown
Tarea: webhooks salientes con firma y reintentos (17)
- Conocido bien:  firma HMAC + outbox + poller        → 3-5 d   (confianza alta)
- Conocido medio: cola con backoff + DLQ               → 2-3 d   (confianza media)
- Desconocido:    el sandbox del proveedor (¿responde?, ¿docs?) → 0-3 d (incertidumbre real)
Total: 5-11 días, confianza media. El gatillo: si el sandbox demora >1 d, re-estimo y aviso.

Las tres piezas: la descomposición (cada parte estimable), el rango (la incertidumbre explícita), y el gatillo de re-estimación (la condición que convierte el rango en un número y dispara la comunicación: la estimación es un contrato con revisión, no una promesa fija). Y el multiplicador del imparcial: la tarea estimada "2 h" por alguien que la conoce bien suele ser "medio día" en la realidad — el buffer del conocimiento, no del miedo: se declara en el rango.

2. El histórico: la memoria que la estimación pide

La mejor herramienta de estimación es TU histórico (lo que la suite del curso registra): la tabla de tareas pasadas con estimado vs real. El patrón que el histórico revela (la ley de Hofstadter operativa): las tareas de 2 días toman 3; las de 2 semanas toman 4 (la incertidumbre escala más que el trabajo). El correctivo del proyecto: rango multiplicado por 1.5 en tareas > 1 semana, y la pregunta de la tarea grande: "¿esto es UNA tarea o tres mal separadas?" — la respuesta casi siempre es la segunda (§3). El histórico NO se comparte como arma (el "tardaste 2× lo estimado" del jefe tóxico): se usa para calibrar los rangos propios.

markdown
# docs/estimates/2027-Q4.md — el histórico
| Tarea | Estimado | Real | Desvío | Por qué |
|---|---|---|---|---|
| Webhooks salientes | 5-11 d | 9 d | ok | sandbox del proveedor: 2 d |
| Expiración con Celery | 3 d | 2 d | -1 | la lógica ya extraída (28) |
| Export RGPD | 4 d | 8 d | ×2 | la anonimización era el 70% del trabajo |

3. Dividir: entregables verticales, no horizontales

La división del problema grande: vertical (cada trozo entrega valor al usuario de punta a punta: "registrar pago y mostrarlo" con la pasarela fake) vs horizontal ("primero todo el modelo, luego todo el servicio, luego la vista" — nada funciona hasta el final, el feedback llega tarde, y la integración final es el infierno clásico). El troceado del curso (la feature "compra con tarjeta regalo", la 08):

1. (0.5 d) El modelo GiftCard + migración + admin: el negocio VE el inventario
2. (1 d)   Pagar CON tarjeta regalo (el happy path completo, pasarela fake): el flujo E2E existe
3. (1 d)   El ledger de la tarjeta (08): la trazabilidad del dinero
4. (1 d)   Los bordes: saldo insuficiente (26), expiración (31), concurrencia (10)
5. (0.5 d) La pasarela real + smoke: el borde final

Cada trozo: terminable, testeable, demostrable (el negocio ve la feature crecer); el total: 4 días con feedback en cada corte. La regla del troceado: si un trozo supera 3 días, se divide más (¿cuál es el happy path de ESTE trozo?); y el trozo 1 no es "solo el modelo" — es el modelo + admin + el primer test: vertical también.

4. La comunicación del trade-off: el "sí, pero" estructurado

El trade-off que la estimación revela se comunica estructurado — el sí mudo (aceptar la fecha imposible: el cliff del deadline) y el no seco ("no se puede": la obstrucción sin alternativas) son los dos fracasos de comunicación del junior. El formato del "sí, pero":

markdown
"Podemos tener el checkout con tarjeta regalo el día X SI:
 (a) el sandbox del proveedor responde esta semana (riesgo: su lado, no el nuestro), Y
 (b) el alcance es el happy path + bordes — el reembolso de tarjetas regalo (el
     monto inverso) es la semana siguiente.
 Opciones si la fecha no se mueve: (1) el scope (a) es lo que entra;
 (2) el reembolso entra si desplazamos el export RGPD; (3) nadie más toca
 el checkout esta semana (el riesgo de merge del 40 lo pide)."

Las tres piezas: la condición (qué debe ser verdad), el alcance (qué entra y qué NO — el no explícito del scope), y las opciones (el dueño del trade-off es el negocio: tú presentas, ellos eligen). La regla de oro del oficio: el problema comunicado a tiempo es un plan; comunicado a mitad del sprint es un incendio; comunicado al deadline es una dimisión.

5. La estimación en el mundo del curso

TicketFlow aplica el método: la feature de preventa (el turnstile del 36) estimada con el método: conocido (rate limiter del 23: 2 d), medio (la cola de espera con SSE del 16: 3-4 d), desconocido (el UX de la sala de espera: 2-4 d con el front) → 7-10 días en 4 trozos verticales (rate limit solo → cola en memoria → cola con Redis → UX pulido), con el gatillo "si la sala de espera supera 2 d, el MVP sale sin ella". Y el histórico del trimestre alimentado por los commits: la estimación es una habilidad que mejora con medición — la misma tesis del 37 (medir antes de optimizar) aplicada al tiempo.

Autoevaluación

  1. ¿Por qué el número único falsea y qué tres piezas lleva la estimación honesta (descomposición, rango, gatillo)?
  2. ¿Qué revela el histórico personal y cómo se usa sin convertirse en arma?
  3. Vertical vs horizontal: ¿por qué "todo el modelo primero" fracasa y qué propiedad tiene cada trozo vertical?
  4. ¿Qué tres piezas lleva el "sí, pero" y quién es el dueño del trade-off?
  5. La regla de oro de la comunicación: ¿qué convierte el problema en plan vs incendio vs dimisión?

Continúa con los ejercicios. Las solutions.md solo tras intentarlo.

^ arriba