Guía en profundidad
Simulador de pérdida de velocidad por deuda técnica: lo que cuesta el retrabajo a su equipo de ingeniería
Análisis ejecutivo del sector
La deuda técnica es el coste acumulado de los atajos: código que funciona pero es difícil de cambiar, pruebas que faltan, dependencias enredadas y sistemas antiguos que nadie entiende. Rara vez aparece en un presupuesto. Aparece, en cambio, como la sensación de que todo tarda más que antes. Las estimaciones se desvían, los cambios pequeños rompen cosas que nada tienen que ver y el equipo dedica sprints a un trabajo que no crea nada nuevo. La factura no llega como un cargo, sino como un menor número de funciones entregadas cada mes con la misma nómina.
La estructura del problema es un impuesto sobre la capacidad. Si una quinta parte de cada sprint se va en soluciones provisionales y retrabajo, el equipo se comporta como si fuera una quinta parte más pequeño, mientras los salarios no cambian. La deuda además se acumula. Cada función nueva construida sobre una base frágil añade más complejidad, de modo que la parte perdida crece salvo que se dedique algún esfuerzo a amortizar. Saldar la deuda cuesta producción ahora, y por eso siempre resulta tentador aplazarlo y por eso la decisión merece números.
El modelo del efecto dominó sigue la pérdida. La parte del sprint perdida por la deuda reduce la capacidad disponible para trabajo nuevo, lo que reduce las funciones entregadas. Menos funciones reducen el valor entregado por cada dólar de nómina, y la carga del retrabajo, los apagafuegos y la rotación crece con la deuda. La última casilla compara el valor entregado con el coste real del equipo. Un aumento modesto de la deuda puede convertir un retorno sano en una pérdida, porque la nómina es fija mientras que el valor no lo es.
El iceberg muestra lo que oculta la línea de nómina. Es visible la propia nómina. Bajo la línea de flotación están la parte de la nómina gastada en retrabajo, los apagafuegos que la deuda causa en producción, la rotación de los ingenieros que abandonan bases de código agotadas y el valor de las funciones que nunca se construyeron. La última partida es un coste de oportunidad que nunca aparece en la contabilidad, pero que suele ser la mayor. Use el simulador para encontrar el nivel de deuda en el que el equipo deja de pagarse a sí mismo y para comprobar si un plan de amortización merece la pena.
Esquema de fórmulas y metodología
El modelo es una vista mensual de un equipo de producto. La nómina son los ingenieros por el coste total. Una parte del sprint se va en deuda y otra en amortización deliberada, y el resto construye funciones nuevas. Las funciones entregadas son los ingenieros por las funciones por ingeniero por esa parte restante, valoradas al valor por función. La deuda también causa incidentes, como proporción del coste del retrabajo, y eleva la rotación, valorada en cuatro meses de salario total por reemplazo. En la proyección, la deuda sube cada mes salvo que se financie la amortización.
- Parte de construcción
- c = 1 − deuda − amortización
- La parte del sprint que se dedica a funciones nuevas.
- Funciones entregadas
- F = ingenieros × funciones por ingeniero × c
- Funciones nuevas entregadas en un mes.
- Coste del retrabajo
- R = nómina × deuda
- La nómina que no compró ningún valor nuevo.
- Coste de la rotación
- A = ingenieros × (1 % + 0,06 % × puntos de deuda) × 4 meses × coste
- Coste mensual esperado de reemplazar ingenieros, que aumenta con la deuda.
- Resultado neto
- Neto = F × valor − nómina − 0,15 × R − A
- Valor entregado menos el coste real del equipo. El punto de ruptura es donde llega a cero.
Elasticidad en cascada
La parte de deuda es el dato más elástico, porque reduce la producción y aumenta a la vez los costes de incidentes y de rotación. El valor por función y las funciones por ingeniero escalan todo el retorno. El coste de la nómina importa porque es la base fija que el valor debe superar.
Tres casos prácticos reales
Inicio con recursos propios
Un equipo pequeño con un código limpio
Un equipo de tres mantiene baja la deuda, entrega rápido y valora mucho cada función respecto a la nómina. El retrabajo es pequeño. Cárguelo para ver la ventaja inicial de una base limpia y lo poca deuda que hace falta para empezar a erosionarla.
Mediana empresa en crecimiento
Un equipo grande que invierte en amortizar
Un equipo de cuarenta y cinco personas arrastra una deuda moderada, pero reserva una décima parte de cada sprint para la limpieza. Las funciones se entregan a buen ritmo y los incidentes se mantienen bajos. Cárguelo para ver por qué una amortización disciplinada escala.
Crisis de cisne negro
Un código de rápido crecimiento que nadie puede cambiar
Un equipo de veinticinco personas heredó años de atajos. Más de la mitad de cada sprint se va en retrabajo e incidentes, la rotación es alta y el tiempo de amortización es cero. Cárguelo para ver una gran nómina que produce poco y qué palanca recupera el mes.
Matriz de referencias del sector
| Métrica | Zona de peligro | Promedio del sector | Élite (10 % superior) |
|---|---|---|---|
| Parte del sprint perdida en retrabajo | Más del 40 % | 15–25 % | Menos del 10 % |
| Tiempo reservado para amortizar la deuda | Cero | 5–10 % | 15–20 % cuando hace falta |
| Valor entregado por cada dólar de nómina | Menos de 1,0 | 1,2–1,6 | Más de 2,0 |
| Rotación mensual de ingenieros | Más del 2,5 % | 1–1,5 % | Menos del 1 % |
| Trabajo de incidentes como porcentaje del coste del retrabajo | Más del 25 % | 10–15 % | Menos del 8 % |
Variables y palancas
Ingenieros del equipo
Desarrolladores que trabajan en el producto, contados como equivalentes a tiempo completo.
Palanca: No añada primero ingenieros a un equipo con mucha deuda, ya que cada persona nueva hereda el mismo lastre y ralentiza la incorporación.
Coste total por ingeniero al mes
Salario más impuestos, beneficios, equipamiento y gastos generales de un ingeniero en un mes.
Palanca: Mantenga los salarios en línea con el mercado, pero recorte los gastos generales ocultos, porque cada hora perdida por la deuda se paga al coste total.
Sprint perdido por deuda y retrabajo
Parte del tiempo de ingeniería dedicada a soluciones provisionales, corrección de errores, compilaciones lentas y lucha contra código antiguo en lugar de nuevas funciones.
Palanca: Haga visible la deuda: enumere los peores módulos, estime las horas de retrabajo y corrija primero los que afectan a más funciones.
Funciones por ingeniero al mes (sin deuda)
Cuántas funciones relevantes entregaría un ingeniero en un mes si no se perdiera tiempo por la deuda.
Palanca: Elimine la fricción en la compilación, las pruebas y las revisiones, porque la experiencia del desarrollador decide cuántas funciones puede entregar una persona.
Valor mensual de una función entregada
Ingresos, ahorros o retención que aporta al mes una función típica una vez entregada, según su propia estimación.
Palanca: Entregue funciones que muevan los ingresos o la retención; si el valor entregado es bajo, ninguna velocidad hará rentable al equipo.
Sprint invertido en amortizar la deuda
Parte del sprint dedicada deliberadamente a reducir la deuda. Cuesta producción ahora y reduce la deuda después.
Palanca: Reserve una porción constante de cada sprint, a menudo entre el diez y el veinte por ciento, para la deuda que bloquea el trabajo próximo.
Cómo usar este simulador
- 1Parta del escenario realista o introduzca el tamaño de su equipo, el coste total y la parte estimada de retrabajo.
- 2Lea las cinco casillas del efecto dominó para ver si la velocidad o la carga de la deuda se ponen en rojo primero.
- 3Pulse «Encontrar mi punto de ruptura» para ver la parte de deuda que vuelve deficitario al equipo.
- 4Compare el plan actual con el plan de amortización en el gráfico de 24 meses.
- 5Mida el retrabajo durante unos sprints y revise el modelo cada trimestre.
Errores que conviene evitar
- Tratar el tiempo perdido por la deuda como gratuito porque los salarios son fijos, cuando cada hora lleva el coste total.
- Añadir ingenieros a un código lento y esperar que la velocidad suba en proporción.
- Planificar una gran reescritura en lugar de saldar la deuda de forma constante donde bloquea el trabajo próximo.
- Ignorar la rotación, que es un coste real y recurrente de un código desagradable.
Preguntas frecuentes
¿Cómo estimo la parte del sprint perdida por la deuda?
Etiquete durante unos sprints las tareas y las solicitudes de cambio que sean retrabajo, corrección de errores o soluciones provisionales, y divida ese tiempo entre el tiempo total de ingeniería. Pida al equipo una cifra aproximada como contraste.
¿Es mala toda la deuda técnica?
No. Tomar un atajo para aprender más rápido o cumplir un plazo puede ser un buen intercambio, si se registra y se salda. La deuda se convierte en un problema cuando no se gestiona y se acumula.
¿Cuánto tiempo debemos dedicar a amortizar?
Depende del nivel de deuda y del trabajo próximo. Es habitual dedicar de forma constante entre el diez y el veinte por ciento, pero hágalo en la deuda que bloquea funciones planificadas y no en limpiezas por sí mismas.
¿Cómo valoro una función?
Estime los ingresos mensuales, la retención o el ahorro de costes que aporta, aunque sea de forma aproximada. Si no puede, use como punto de partida el crecimiento medio de ingresos dividido entre las funciones entregadas.
¿Cómo encuentro el nivel de deuda con el que el equipo pierde dinero?
Pulse «Encontrar mi punto de ruptura». La herramienta desplaza cada dato hacia su extremo desfavorable e indica el valor en el que el beneficio mensual llega a cero.
¿Qué grado de precisión tiene esto?
Es un modelo educativo con supuestos declarados, no asesoramiento de gestión. Los resultados reales de ingeniería dependen de muchos factores. Sustituya los datos por los suyos.
Este es un modelo educativo de planificación con supuestos declarados. No constituye asesoramiento financiero, fiscal ni jurídico. Sustituya los datos por sus propias cifras y consulte las decisiones importantes con un profesional cualificado.