Cuando un equipo entrega lento, la causa casi nunca son los ingenieros. Suelen ser cuatro o cinco fricciones concretas que nadie ha medido.
«El equipo es lento» es un síntoma, y los fundadores suelen diagnosticarlo mal como un problema de personas. Según nuestra experiencia, casi siempre es un problema de sistema: el trabajo espera en colas, los cambios son grandes y arriesgados, desplegar da miedo y nadie tiene números con los que discutir.
Empieza por cuatro mediciones
Estas cuatro están bien establecidas y, más importante, son diagnósticas: cada resultado malo apunta a una clase concreta de problema.
| Métrica | Qué expone cuando es mala |
|---|---|
| Frecuencia de despliegue | Tamaño de lote demasiado grande, despliegues tratados como eventos |
| Tiempo de entrega de cambios | Tiempo en cola — normalmente revisión de código o QA esperando, no programar |
| Tasa de fallo de cambios | Testing débil o falta de paridad con producción |
| Tiempo de restauración | Sin rollback ensayado, observabilidad pobre |
Los hallazgos habituales
La revisión de código es un cuello de botella, no una puerta de calidad
- Los pull requests son demasiado grandes para revisarse en serio, así que la revisión se vuelve teatro de aprobación
- No hay expectativa sobre el tiempo de respuesta de la revisión, así que los cambios se quedan días parados
- Un único ingeniero sénior es el único aprobador — una cola con un solo servidor
Desplegar es un evento
- Pasos manuales que solo una persona conoce
- Ningún rollback en el que se confíe, así que las releases se agrupan, lo que las hace más arriesgadas, lo que las hace más raras
- Despliegues programados en horas tranquilas — señal potente de que el equipo no confía en el proceso
El trabajo no está realmente definido
- Tickets que exigen una conversación antes de que nadie pueda empezar
- Sin definición compartida de «terminado», así que el trabajo rebota entre desarrollo y QA
- Demasiado trabajo en curso — todos ocupados, nada se termina
Qué cambiar primero
- Haz que desplegar sea aburrido — automatiza, añade rollback, practícalo. Todo lo demás mejora en cuanto publicar es seguro.
- Reduce el tamaño de lote — los cambios pequeños son más fáciles de revisar, más seguros de publicar, más rápidos de diagnosticar.
- Fija un SLA de revisión — horas, no días, con un segundo aprobador para que nunca haya una persona cuello de botella.
- Limita el trabajo en curso — terminar gana a empezar.
- Instrumenta lo que sienten los clientes, para encontrar los incidentes internamente en vez de recibirlos reportados.
Velocidad y seguridad no son un compromiso en la entrega de software. Los equipos que despliegan con más frecuencia también tienen las tasas de fallo más bajas — porque los cambios pequeños, frecuentes y reversibles son a la vez más rápidos y más seguros.
Estudiar trabajo sin convertir métricas en clasificaciones
Las tareas comparables revelan restricciones del sistema. Explica esperas y retrabajo sin confundir actividad con productividad.
- Seleccionar cambios completados, incluida una corrección urgente.
- Medir colas, revisiones, traspasos y problemas de despliegue.
- Probar una mejora con referencia inicial y fecha de revisión.
Preguntas frecuentes
¿Cuánto dura una auditoría de procesos de ingeniería?
Normalmente de una a dos semanas: recoger datos de entrega, entrevistar al equipo, observar una release real y revisar el tooling. El resultado debe ser un número pequeño de cambios priorizados con impacto esperado, no una puntuación de modelo de madurez.
¿Nos va a decir que adoptemos Scrum?
No. La metodología rara vez es la restricción — lo son el tiempo en cola, el tamaño de lote y el riesgo de despliegue. Ha habido equipos que entregan bien bajo todos los frameworks y mal bajo todos; cambiar la ceremonia sin cambiar esas tres cosas no hace nada.
Nuestro equipo dice que necesita más ingenieros. ¿Es cierto?
A veces, pero contratar hacia un cuello de botella de proceso empeora las cosas antes de mejorarlas — más personas produciendo más trabajo en curso contra las mismas colas de revisión y despliegue. Mide primero adónde va realmente el tiempo; si la mayor parte es tiempo en cola, contratar no es el arreglo.
¿Se pueden comparar equipos con métricas brutas?
Solo considerando producto, tipo de trabajo y restricciones operativas. Las tendencias ayudan a investigar; los recuentos no demuestran eficacia por sí solos.
¿Tu equipo entrega más lento de lo que debería?
Medimos adónde va realmente el tiempo y arreglamos las principales restricciones — normalmente en semanas, no en trimestres.
Para seguir leyendo
Buenas prácticas de postmortem: escribir uno que la gente lea
La mayoría de postmortems son arqueología: un registro exacto de algo que nadie va a cambiar. Uno útil produce un número pequeño de cosas que efectivamente se hacen.
Auditoría técnica de MVP: qué revisamos en las primeras 48 horas
La mayoría de las auditorías de MVP producen un documento. Una útil produce decisiones: qué está ardiendo, qué puede esperar y cuánto cuesta arreglarlo.