Hay una pregunta que casi ninguna empresa de tecnología puede responder: cuánto costó la última estimación que salió mal.
No es una pregunta retórica. Es una cifra concreta, en horas, que existe en algún lugar de la operación. El problema es que está fundida con el resto del trabajo y no hay forma de aislarla.
El rework existe, pero no tiene nombre propio
Código que hay que rehacer. Entregas rechazadas en revisión. Tickets que se reabren una semana después de cerrarse. Funcionalidad que se construyó sobre un requerimiento que después cambió.
Todo eso es trabajo real, lo hace gente del equipo y consume horas que se cargan. Pero en la mayoría de las operaciones se carga en la misma categoría que el desarrollo nuevo. Y una vez que entró ahí, deja de ser distinguible.
En las 1.632 conversaciones que tuvimos con líderes de empresas de tecnología —fábricas de software, consultoras de IT, equipos de desarrollo a medida— 162 reportan desvíos entre las horas que estimaron y las que ejecutaron. El desvío se nota. Lo que no se puede hacer es explicarlo.
Como lo resumió uno de los entrevistados: "Horas facturables vs no facturables: no cuentan con esto. No lo tienen automatizado."
Lo que se pierde cuando se mezcla
Separar el rework no es una cuestión de prolijidad contable. Cambia tres cosas.
La primera: el costo de una mala estimación deja de ser invisible. Si el rework está adentro de las horas facturables, un proyecto que necesitó 80 horas de retrabajo se ve igual que uno que no necesitó ninguna. Los dos entregaron. Los dos facturaron. Pero uno dejó bastante menos margen, y nadie puede señalar dónde.
La segunda: el histórico queda contaminado. Cuando llega el momento de estimar un proyecto parecido, se busca el anterior y se mira cuántas horas llevó. Si en ese número hay 80 horas de retrabajo que nadie identificó, la nueva estimación arranca inflada —o peor, se descuenta "porque esta vez va a salir mejor" y arranca corta.
La tercera: la conversación con el cliente pierde evidencia. Cuando el retrabajo vino de un cambio de requerimiento del lado del cliente, poder mostrarlo separado convierte una discusión de percepciones en una conversación con datos.
Casi nunca está donde todos creen
Algo que aparece sistemáticamente cuando una empresa separa el rework por primera vez: la sorpresa no es cuánto hay, sino dónde está.
El proyecto que todos señalaban como problemático suele tener menos retrabajo del esperado. Y aparece concentrado en lugares que nadie miraba: una integración puntual, un cliente específico, una etapa del proceso que parecía resuelta.
Es información que no se puede intuir. Solo aparece cuando el dato existe.
Y ahora hay una fuente nueva
La adopción de herramientas de AI sumó una capa a este problema. Según la Developer Survey 2025 de Stack Overflow, con más de 49.000 desarrolladores en 177 países, el 84% ya usa o planea usar herramientas de AI, pero solo el 29% confía en la precisión de lo que producen —era 40% en la medición anterior—. Y el 66% dedica más tiempo del previsto corrigiendo código que queda "casi bien".
Esas horas de corrección son rework. Y se están cargando, en la mayoría de los casos, como desarrollo nuevo.
El análisis de GitClear sobre 623 millones de cambios de código entre 2023 y 2026 apunta en la misma dirección: la duplicación de bloques subió 81% mientras la refactorización cayó 70%. El volumen de output sube y la estructura que lo sostiene se degrada. Esa diferencia vuelve como retrabajo, en el mismo proyecto o en el siguiente.
Por dónde empezar
Separar el rework es el movimiento más barato de toda la operación: no requiere comprar nada.
Define la categoría. Una tercera opción de carga, junto a desarrollo nuevo y soporte. Con un criterio escrito de qué entra: retrabajo por error propio, por cambio de requerimiento, por entrega rechazada.
Acuérdalo con el equipo antes de implementarlo. Si el equipo lo interpreta como una métrica de control individual, los datos van a salir sesgados. El encuadre importa: esto mide decisiones de estimación y de alcance, no el desempeño de una persona.
Dale tres meses antes de sacar conclusiones. Un mes de datos no alcanza para distinguir un proyecto raro de un patrón.
Y el punto que ordena todo lo demás: el dato ya existe en tu operación. El equipo carga horas todos los días. Lo único que falta es que esas horas se puedan leer.
Volver al Blog