Retrabajo, cola de revisión y la tentación de contratar más gente
En una fintech, el equipo de pagos (6 desarrolladores, 1 arquitecto, 1 QA) trabaja en sprints de dos semanas con velocidad estable de 42 puntos. En los últimos seis sprints se cerraron 92 historias, pero 31 fueron reabiertas por defectos hallados en producción en los 30 días siguientes. La cobertura de pruebas unitarias del módulo de cálculo de comisiones es 38% y no se valida en el pipeline. La revisión de pull requests tarda en promedio 52 horas porque solo el arquitecto puede aprobar cambios en ese módulo, y hay 14 PRs abiertos en cola. Los despliegues son cada tres semanas, con ventana nocturna de cuatro horas y dos rollbacks en el último trimestre. El gerente de área propone contratar a dos desarrolladores más y añadir una etapa de QA manual de tres días antes de cada liberación, argumentando que así se atrapan los errores antes del usuario. El presupuesto alcanza para una de las dos medidas, no para ambas, y el patrocinador quiere una recomendación en una semana.
1. Con los datos del caso, ¿cuál es la restricción principal del sistema de entrega y por qué? Justifica con cálculos y descarta al menos una hipótesis alternativa.
Read the worked answer
El retrabajo y la cola de revisión limitan más que la plantilla.
- Retrabajo: 31/92 = 33.7% de las historias entregadas regresaron como defecto. Sobre una capacidad de 42 puntos por sprint, eso equivale a ~14 puntos por sprint dedicados a corregir en lugar de construir; la capacidad efectiva ronda 28 puntos.
- Recurso serializado: el arquitecto es el único aprobador. Con 14 PRs en cola y 52 h de espera media, la ley de Little implica una llegada de ~0.27 PR/h (~6.5 por día). Si se contratan dos desarrolladores (+33% de capacidad de producción), la llegada de PRs sube a ~8.7 por día y la utilización del aprobador pasa de ~0.75 a >1: la cola y la espera crecen sin límite. Contratar aguas arriba de un cuello de botella agrava el cuello.
- Tamaño de lote: cuatro despliegues por trimestre con dos rollbacks implican una tasa de fallo de cambio cercana a 50%; lotes grandes hacen que cada defecto escape más lejos y que el rollback sea más caro.
Hipótesis descartada: «faltan manos». La velocidad es estable en 42 puntos, señal de que la restricción no es la capacidad de codificación sino el flujo de retroalimentación. Otra hipótesis descartable es «el QA no prueba lo suficiente»: el 38% de cobertura en el módulo de comisiones explica el escape, pero añadir pruebas manuales al final no reduce la inyección de defectos, solo los detecta más tarde.
2. Propón tres intervenciones medibles con un criterio de éxito evaluable a seis semanas, y explica por qué atacan la causa y no el síntoma.
Read the worked answer
Intervención 1 – Distribuir la propiedad del código. Habilitar dos revisores adicionales con checklist común, limitar PRs a ≤400 líneas cambiadas y fijar un SLA de primera respuesta <8 h. Métrica: percentil 85 de tiempo de PR (hoy ~52 h), objetivo <16 h; PRs en cola <5. Ataca el recurso serializado, que es la verdadera restricción.
Intervención 2 – Puerta automática en el módulo crítico. Umbral de cobertura ≥80% en cálculo de comisiones con pruebas de contrato y casos límite (redondeo, moneda, reversos), bloqueante en CI. Métrica: tasa de reabdos por defecto en producción, hoy 33.7%, objetivo <15% en el trimestre. Es prevención, no detección tardía: el defecto se atrapa en minutos, no en un gate de tres días.
Intervención 3 – Reducir el tamaño de lote. Feature flags y ramas cortas, liberación semanal en lugar de cada tres semanas. Métricas DORA: frecuencia de despliegue y tasa de fallo de cambio (hoy ~50%), objetivo <15%; MTTR <1 h.
Por qué seis semanas es suficiente: permite dos ciclos de sprint para estabilizar la métrica y comparar contra la línea base. Se usan indicadores adelantados (tiempo de PR, cobertura) y rezagados (reabiertos, rollbacks) para no confundir esfuerzo con resultado. Sin línea base comparable, cualquier mejora sería anécdota.
3. ¿Cómo respondes a la propuesta del gerente y qué evidencia presentas para inclinar la decisión?
Read the worked answer
Respuesta: ninguna de las dos medidas propuestas ataca la restricción; la recomendación es invertir en la puerta automática y en la revisión distribuida, y posponer la contratación.
- Sobre el gate manual de tres días: con cadencia de tres semanas son ~17 liberaciones al año; tres días por liberación añaden ~51 días de tiempo de ciclo, aumentan el lote en tránsito y retrasan la retroalimentación justo cuando el defecto ya está caro de corregir. El coste de retraso se multiplica y la detección sigue siendo tardía.
- Sobre contratar: dos personas más elevan la llegada de PRs ~33% mientras el aprobador mantiene su capacidad, así que el tiempo de espera crece; además, la curva de rampa de un nuevo integrante en un módulo con 38% de cobertura es de 4–8 semanas antes de ser netamente productivo.
- Presupuesto: automatizar el módulo crítico es un gasto único y recurrente menor que dos salarios anuales; se puede financiar con el ahorro de retrabajo (≈14 puntos/sprint).
Cómo lo presento: una tabla con dos escenarios y sus supuestos (tiempo de ciclo, tasa de fallo de cambio, coste), declarando que son estimaciones y proponiendo un experimento de seis semanas con métricas ya definidas. Si al final del piloto la tasa de reabiertos no baja de 20%, se reabre la discusión de contratación con datos, no con opiniones. Esto convierte la discusión política en una decisión falsable.