# Coste de cambiar software tarde: qué dicen los datos > ¿Corregir tarde cuesta 100 veces más? En 171 proyectos el efecto no apareció de forma consistente. Nuestra lectura: el coste depende de dónde vive la regla. - Autor: Marlon Trettin - Publicado: 2026-10-28 · Actualizado: 2026-10-28 - Idioma: es - Canonical: https://yowpi.com/es/blog/cuesta-mas-cambiar-el-software-tarde-que-dicen-los-datos --- ¿Corregir tarde cuesta decenas de veces más? No siempre. La regla viene de curvas de 1981 cuyos datos de base nunca se publicaron, y un estudio con 171 proyectos no encontró ese efecto de forma consistente. Una hipótesis más útil: el coste de cambiar depende de dónde vive la decisión en el sistema. ## TL;DR - La regla de que el coste de corregir crece decenas de veces hasta las fases finales viene de curvas de 1981 cuyos puntos de datos originales no se publicaron. - En 171 proyectos de 2006 a 2014, el esfuerzo para corregir un problema tardío se mantuvo cerca del esfuerzo de corregirlo pronto en la mayoría de los pares de fases. Las mayores medianas estuvieron entre 2,5 y 3 veces. - El estudio mide defectos en equipos con un proceso disciplinado, no cambios de alcance pedidos por el negocio. No prueba que cambiar tarde sea barato. - Nuestra lectura, que los datos no ponen a prueba: para quien contrata, la pregunta útil es en cuántos lugares vive una regla dentro del sistema. ## ¿De dónde viene la regla de que cambiar tarde cuesta 100 veces más? Uno de los orígenes es Barry Boehm, que en 1981 publicó curvas de coste por fase del proyecto. Según la [descripción de Tim Menzies y coautores](https://arxiv.org/abs/1609.04886), una de ellas muestra un aumento de 40 veces hasta la prueba de aceptación, y otra, de 100 veces para proyectos mayores antes de la entrega. La misma descripción registra que los puntos de datos detrás de esas curvas nunca se publicaron, y que Boehm informó, en 1980, de una curva más plana para proyectos pequeños. La idea se extendió. Según [Steve McConnell](https://stevemcconnell.com/articles/an-ounce-of-prevention/), Boehm y Philip Papaccio estimaron en 1988 que un defecto de requisitos que llega a producción puede costar de 50 a 200 veces más de corregir que uno detectado cerca de donde nació. Menzies y coautores citan además razones de 1 a 137 en Toshiba y de 1 a 117 en IBM, aportadas por participantes de talleres, también sin datos brutos. Nada de esto es invención, y la idea de que un problema se encarece cuanto más tarde se descubre resulta intuitiva. Lo importante es que circula como un número fijo, y el estudio que sigue la trata como una hipótesis que hay que contrastar. ## ¿Qué encontró un estudio con 171 proyectos? Encontró poca evidencia del efecto. Tim Menzies, William Nichols, Forrest Shull y Lucas Layman analizaron 171 proyectos de software realizados entre 2006 y 2014, de 45 organizaciones en 6 países, todos registrados en una base de datos del Team Software Process (TSP). Compararon el esfuerzo para corregir un problema en la fase en que nació con el esfuerzo para corregirlo en fases posteriores. El resultado, publicado en arXiv, es que las medianas de esas razones quedaron cerca de 1 en la mayoría de los pares. Las mayores fueron de 3,0, entre planificación y prueba unitaria, y de 2,54, entre requisitos y prueba de integración. En el percentil 90, el mayor valor también fue 3,0. Casi todas las comparaciones no difirieron de forma significativa. Los autores concluyen que no hay evidencia consistente ni sustancial del efecto y sugieren que puede ser un resto histórico, presente solo de forma intermitente en ciertos tipos de proyecto. ## ¿Qué no demuestra este estudio? No demuestra que cambiar un sistema tarde sea barato. Primero, todos los proyectos usaron TSP, un proceso disciplinado desarrollado por el empleador de dos de los autores. Un proyecto sin ese tipo de proceso no es el retrato de esta muestra. Segundo, el estudio mide el esfuerzo para corregir defectos. No mide lo que pierde la empresa mientras espera, ni un cambio de alcance pedido por el negocio cuando el sistema ya está en producción, que es el caso que más interesa a quien contrata. Y los propios autores admiten que no tenían un grupo de control para comparar el TSP con otros procesos. Lo que queda es más modesto: el multiplicador no es una constante. En algunos proyectos el coste crece con el tiempo y en otros no, y la pregunta pasa a ser qué explica la diferencia. ## ¿Qué hace variar el coste de cambiar? Los datos no lo responden, y lo que sigue es lectura nuestra. Un punto de partida es un [artículo de David Parnas](https://doi.org/10.1145/361598.361623), de 1972, en *Communications of the ACM*. Parnas propone que un sistema no se divida a partir de un diagrama de flujo, sino de una lista de decisiones difíciles o probables de cambiar, con cada módulo ocultando una de ellas al resto. En el ejemplo que analiza, la descomposición que defiende confina un cambio en la forma de almacenar los datos a un único módulo. En la convencional, el mismo cambio obliga a modificarlos todos. Traducido a la operación de una empresa: el coste de cambiar una regla depende de en cuántos lugares está escrita. Cuando la regla vive en un solo punto, cambiarla es una modificación. Cuando está dispersa, cada copia es una oportunidad de olvidar una, y el error aparece semanas después, lejos de donde nació. Eso es un problema de arquitectura, no de tecnología: la herramienta pesa menos que el lugar donde viven las decisiones de la empresa. ## Un ejemplo práctico: la regla de comisión de una correduría El escenario es hipotético, sin cifras medidas. Una correduría de seguros con 40 personas cambia la regla de comisión de un ramo. En el primer diseño del sistema, la regla aparece en la hoja de cálculo, en una pantalla de alta, en un informe y en la integración con finanzas. Cambiarla significa encontrar los cuatro lugares. Si se olvida uno, la discrepancia solo aparece en el cierre del mes, cuando la diferencia ya se ha convertido en conciliación manual. En el segundo diseño, la regla es una tabla con fecha de vigencia, leída por todas las pantallas e integraciones. El mismo cambio se convierte en una fila nueva con la fecha de inicio. La petición del negocio es idéntica, y el coste de cambiar depende mucho menos de la fase del proyecto en que llegó la petición. Lo que separa los dos diseños se decidió al principio, cuando alguien preguntó dónde debía vivir la regla. ## ¿Cómo usar esto al contratar un sistema? En tres pasos breves, antes de aprobar el alcance. El primero es listar las cinco decisiones que más probablemente cambiarán en los próximos 12 meses: regla de comisión, tabla de precios, campos del alta, límites de aprobación, qué puede ver cada perfil. El segundo es preguntar a quien vaya a construirlo, por escrito, en cuántos lugares existirá cada una de esas decisiones. La respuesta honesta para varias será "en uno", y para algunas será "en dos o tres, y este es el motivo". El tercero es probar antes de la entrega. Pida que se cambie una de esas reglas en el prototipo y observe cuántas pantallas o integraciones hay que tocar. Es una forma barata de ver el coste de cambiar antes de pagarlo. El texto sobre [por qué los presupuestos de software varían tanto](/es/blog/por-que-los-presupuestos-de-software-varian-tanto) ayuda a comparar propuestas que responden a esa pregunta de formas distintas. Los sistemas siguen cambiando después de entregados. En el [caso de Colo Saúde](/es/cases/colo-saude), Yowpi asumió una plataforma heredada y redujo en un 60% el consumo de capacidad de la plataforma original, dato del caso publicado, y la evolución siguió con el mismo equipo. Es un ejemplo de sistema que siguió evolucionando una vez terminado, no una prueba del efecto descrito en el estudio. ## Preguntas frecuentes **La integración con lo que ya uso va a ser complicada. ¿Encarece eso cambiar después?** Puede encarecerlo, porque cada integración es un lugar donde una regla puede estar copiada. La pregunta del segundo paso vale también aquí: qué datos salen del sistema nuevo hacia los que ya usa, y cuál de ellos es la fuente de cada regla. En nuestra lectura, una integración en la que solo un lado define la regla tiende a ser más barata de cambiar que dos que la repiten. **No tengo un equipo cualificado para implementarlo. ¿Cómo valoro la respuesta de un proveedor?** Pida la respuesta por escrito y compárela entre propuestas. Quien entiende su operación responde con nombres de reglas y lugares, como "la comisión vive en la tabla de vigencia y las pantallas solo la consultan". Una respuesta genérica sobre "arquitectura flexible" no dice en cuántos lugares incidirá un cambio. **No sé si el retorno compensa. ¿Congelo el alcance para no pagar por cambios?** Congelar el alcance es una lectura que el estudio no respalda. No dice que cambiar sea siempre barato. Dice que el coste depende del proyecto. En lugar de congelar, separe lo estable de lo probable de cambiar y dé a esto último un lugar único. Así el alcance puede crecer sin que cada petición nueva toque todo. ## El siguiente paso Si hoy cada cambio de regla en su sistema se convierte en una búsqueda de los lugares donde está escrita, el Diagnóstico de Arquitectura Operacional, una sesión de trabajo de 30 minutos, sirve para mapear dónde vive cada decisión antes de planificar el próximo cambio: [agende el diagnóstico](/es/contacto).