No todo lo nuevo es mejor

Durante años, el software en las empresas se entendía como un proyecto. Tenía un inicio claro, un alcance definido, un presupuesto cerrado y —en teoría— un final. Se entregaba, ¡se ponía en producción y se daba por concluido. A partir de ahí, mantenimiento.

Ese modelo ya no describe la realidad.

Hoy, el software no termina. Evoluciona, se ajusta, se reconfigura. Lo que antes era un hito, ahora es solo una versión más dentro de un flujo continuo de cambios. Y esto, aunque suene evidente, sigue generando tensiones dentro de muchas organizaciones.

Porque el cambio no es solo técnico. Es mental.

El espejismo del “proyecto terminado”

Todavía es habitual encontrar organizaciones que intentan encajar el desarrollo de software en esquemas clásicos de proyecto. Se define un alcance amplio, se negocia con uno o varios proveedores, se establece un calendario… y se espera una entrega “final”.

El problema es que, cuando ese momento llega, el contexto ya ha cambiado.

Un CIO lanza una iniciativa para renovar su plataforma de atención al cliente. Se involucran varios proveedores: uno para el frontend, otro para la capa de integración, otro para el CRM. Todo parece bien coordinado al inicio.

Doce meses después, el negocio ha cambiado prioridades, el proveedor SaaS ha actualizado su producto tres veces, y las integraciones que se diseñaron al principio ya no encajan del todo. Sin embargo, el proyecto sigue avanzando como si nada de eso hubiera ocurrido.

Se entrega. Funciona. Pero nace desalineado.

Y ahí empieza el verdadero trabajo.

La realidad: convivir con el cambio constante

Cuando el software pasa a ser un proceso continuo, lo que cambia no es solo la frecuencia de las versiones. Cambia la naturaleza de la relación con él.

Ya no se trata de “tener un sistema”, sino de gestionarlo en el tiempo.

Esto implica aceptar algo incómodo: siempre habrá cosas a medio hacer. Siempre habrá decisiones revisables. Siempre habrá dependencias vivas.

Muchos responsables IT lo viven de forma bastante tangible cuando trabajan con múltiples proveedores.

Uno despliega nuevas funcionalidades cada pocas semanas. Otro trabaja con ciclos trimestrales. Un tercero depende de ventanas de mantenimiento rígidas. Coordinar todo eso no es trivial.

Un ejemplo típico: una empresa adopta una plataforma cloud que evoluciona continuamente. Al mismo tiempo, mantiene sistemas internos más estables y proveedores externos con ritmos distintos. El resultado es una especie de coreografía imperfecta donde cada cambio tiene impacto en varios frentes.

El CIO ya no gestiona proyectos aislados. Gestiona un ecosistema en movimiento.

De controlar entregas a orquestar evolución

Aquí es donde muchas organizaciones se atascan.

Siguen midiendo el éxito en términos de entregas cerradas, cuando lo que realmente importa es la capacidad de adaptación. Siguen negociando contratos como si todo fuera predecible, cuando en realidad lo único seguro es el cambio.

He visto responsables de IT frustrados porque “el proyecto nunca se acaba”. Pero la cuestión no es terminarlo, sino mantenerlo alineado.

Esto cambia también la relación con los proveedores.

Antes, el proveedor entregaba y se iba. Hoy, el proveedor forma parte del ciclo continuo. Y no todos están preparados para eso.

Algunos siguen trabajando con mentalidad de proyecto: definen, construyen, entregan. Otros operan como servicios vivos, con mejoras constantes pero a veces sin suficiente coordinación con el resto del ecosistema.

El CIO queda en medio, intentando alinear ritmos, prioridades y expectativas. No siempre con herramientas adecuadas.

El coste invisible de no adaptarse

Intentar forzar el modelo antiguo sobre una realidad continua tiene un coste. No siempre evidente, pero real.

Se acumulan desarrollos que nadie quiere tocar porque “ya están cerrados”. Se generan capas de integración cada vez más complejas para evitar rehacer lo existente. Se posponen decisiones porque implican reabrir algo que se consideraba finalizado.

Y, poco a poco, el sistema pierde agilidad.

Paradójicamente, muchas iniciativas de transformación digital fracasan no por falta de tecnología, sino por exceso de mentalidad de proyecto.

Otra forma de enfocar el software

Cuando aceptas que el software es un proceso continuo, cambian las preguntas.

Dejas de preguntar “¿cuándo estará terminado?” y empiezas a preguntar “¿cómo evoluciona?”. Dejas de centrarte en cerrar fases y te centras en reducir fricción.

Esto no significa trabajar sin rumbo. Al contrario. Requiere más disciplina, no menos.

Requiere priorizar constantemente. Decidir qué merece evolucionar y qué no. Entender el impacto de cada cambio en un entorno donde todo está conectado.

Y, sobre todo, requiere una relación distinta con el negocio.

Porque si el software no se termina, tampoco lo hacen las expectativas.

Una reflexión final

En el fondo, este cambio no es solo una cuestión de metodología o herramientas. Es una cuestión de perspectiva.

El software ya no es algo que se construye y se entrega. Es algo que se gestiona, se cuida y, en cierto modo, se negocia continuamente.

Algunas organizaciones ya operan así, aunque no siempre lo expresen de esa manera. Otras siguen intentando cerrar proyectos que, en la práctica, nunca terminan.

Y ahí es donde aparecen las fricciones.

No porque el software sea más complejo que antes —que también— sino porque seguimos intentando tratarlo como si no hubiera cambiado.