Ingeniería de software: cómo se sabe si la entrega va bien antes de que sea tarde

Una empresa recibe su sistema de pedidos en la fecha acordada. Funciona, el proveedor factura y el proyecto se cierra con un acta firmada. Cuatro meses después el negocio necesita un cambio pequeño: agregar un tipo de descuento. La cotización llega con seis semanas de trabajo y una advertencia de que puede afectar la facturación. La empresa entiende, por primera vez, que compró algo que funciona y que no se puede cambiar.

Nadie mintió. Se entregó lo que decía el contrato, en la fecha que decía el contrato. Lo que el contrato no decía era nada sobre la propiedad más importante de un sistema que va a vivir cinco años: cuánto va a costar el próximo cambio. Esa propiedad no se ve el día de la entrega, y por eso no se negocia.

Cinco indicadores que no exigen leer código

Preguntar si el proyecto va a tiempo es la peor pregunta disponible, porque se puede cumplir entregando algo que después no se puede cambiar. El programa de investigación DORA mide desde hace más de una década el desempeño de la entrega de software, y publica cinco indicadores que cualquier equipo puede dar con datos que ya genera (DORA):

• Cada cuánto llega algo nuevo a producción.
• Cuánto pasa desde que un cambio está listo hasta que está en producción.
• Qué proporción de las entregas obliga a intervenir de inmediato.
• Cuánto se tarda en recuperarse cuando una entrega falla.
• Qué proporción de las entregas no estaba planeada y salió por un incidente.

La idea útil es que la rapidez y la estabilidad no se negocian entre sí: los equipos que entregan seguido suelen fallar menos, porque cada entrega es más pequeña y más fácil de revertir. Y no hace falta comprar una herramienta para medirlo. Basta con anotar cada entrega, si hubo que intervenir y cuánto tardó.

El criterio de aceptación lo escribe quien va a usar el sistema

Una especificación puede estar completa y dejar el negocio sin resolver, porque describe el sistema y no el resultado. Lo que cierra esa distancia es un criterio de aceptación escrito por el área que va a usarlo, con los casos raros incluidos: la devolución parcial, el cliente con dos identificaciones, el pedido que se factura a otra empresa. Y la aceptación no se hace por demostración. Se hace con la gente del área, con datos reales y sin nadie del equipo que construyó tocando el teclado.

La deuda técnica que se acepta, y la que no

Deuda técnica es el nombre que dan los equipos a los atajos que habrá que pagar después. Martin Fowler propuso la distinción que vuelve útil la metáfora: lo importante no es si hay deuda, sino si es prudente o imprudente, y si se tomó a sabiendas (Martin Fowler, Technical Debt Quadrant). Salir antes con el código organizado de forma provisional es una decisión de negocio defendible. Lo que la vuelve imprudente es no escribir cuándo se paga.

Pedir que no haya deuda suena exigente y es contraproducente, porque obliga al equipo a esconderla. Lo que se exige es una lista visible con tres columnas: qué se hizo, por qué, y qué condición dispararía pagarlo.

La inteligencia artificial amplifica, no arregla

El informe de DORA de 2025 lo dice sin rodeos: la inteligencia artificial no arregla a un equipo, amplifica lo que ya está ahí. En el mismo informe, el 90% de quienes respondieron declara usarla en su trabajo (DORA, informe 2025). Un equipo con pruebas automáticas y un camino claro hacia producción entrega más. Uno sin eso produce más código sin filtro, y el problema aparece después, en las pruebas, en la seguridad y en la entrega.

Antes de comprar herramientas de inteligencia artificial para el equipo conviene saber cuáles de los cinco indicadores están medidos hoy. Si ninguno lo está, no habrá manera de saber después si la herramienta mejoró la entrega o solo produjo más código.

Seis cosas que se exigen al firmar

• La propiedad del código y el acceso al repositorio desde el primer día.
• Pruebas automáticas de los recorridos críticos del negocio, no un porcentaje de cobertura.
• Un procedimiento escrito y probado para montar el proyecto desde cero.
• La lista de componentes de terceros, y quién los actualiza.
• La deuda deliberada, declarada y con fecha.
• Qué recibe la empresa, y en qué formato, el día que la relación termine.

Las seis cuestan poco al firmar y son caras o imposibles después. La señal más útil de todo el proceso de selección es cómo reacciona el proveedor cuando las lee.