Trade-offs en arquitectura tecnológica: la decisión de delivery detrás de cada decisión técnica
Existe una brecha entre el momento en que un equipo técnico identifica la arquitectura ideal y el momento en que esa arquitectura puede ejecutarse de verdad. Esa brecha no aparece en los diagramas. No figura en la propuesta comercial. Y casi nunca se discute en las reuniones de kick-off.
Pero es exactamente ahí donde se decide si un proyecto tecnológico va a funcionar o no. La pregunta real en producción no es ¿cuál es la solución técnicamente correcta? La pregunta real es: ¿cuál es la solución que podemos ejecutar sin comprometer lo que ya está funcionando?
Lo que no estaba en el diseño
En proyectos tecnológicos complejos, los equipos técnicos competentes identifican la arquitectura ideal con relativa rapidez. El problema aparece después, en el momento de ejecutar, cuando la realidad operativa entra en contacto con el diseño. Este es el punto donde la mayoría de los proyectos tecnológicos en Colombia y LATAM encuentran su primera fricción real con la operación.
Hay integraciones activas que no pueden interrumpirse. Hay procesos de negocio que corren sobre los mismos sistemas que se están modificando. Hay partes de la arquitectura que no se pueden detener sin consecuencias que van mucho más allá del proyecto. Y hay equipos operativos que tienen que seguir funcionando mientras todo esto cambia a su alrededor.
En ese momento, el delivery deja de ser coordinación de tareas y se convierte en gestión de riesgo real. No el riesgo abstracto de los registros de riesgo que se actualizan cada dos semanas en una hoja de cálculo. El riesgo concreto de que una decisión técnica tomada hoy genere una falla operativa mañana en un sistema que la organización no puede permitirse que falle.
La decisión difícil no fue técnica
En este tipo de proyectos, la decisión más difícil rara vez es arquitectónica. Los equipos técnicos saben cuál es la solución correcta. La decisión difícil es otra: elegir entre avanzar más rápido asumiendo riesgo operativo, o diseñar una ruta más lenta que mantenga la estabilidad de lo que ya existe.
Esa decisión tiene un costo visible y un costo invisible. El costo visible es el tiempo: una ruta conservadora tarda más, consume más recursos en validación y genera la incomodidad de no poder mostrar avances tan rápido como todos quisieran. El costo invisible es el que aparece cuando se elige la ruta rápida sin medir bien el riesgo: una falla en producción, una integración rota, una operación paralizada en el momento menos oportuno.
Sacrificar velocidad no es una señal de que algo salió mal en un proyecto. En sistemas en producción, muchas veces es la única decisión responsable. El problema es que esa decisión tiene que tomarse con información real sobre el estado de la operación, no con el optimismo natural que caracteriza las fases tempranas de cualquier proyecto.
Lo que cambia cuando entiendes el delivery como gestión de riesgo
Un Delivery Manager que entiende su trabajo como coordinación de tareas lee un plan de proyecto de una forma. Uno que lo entiende como gestión de las consecuencias operativas de las decisiones técnicas lo lee de otra forma completamente distinta.
El primero ve un cronograma con hitos, dependencias y fechas. El segundo ve puntos de decisión donde el proyecto puede tomar rutas con perfiles de riesgo muy diferentes, y su trabajo es asegurarse de que las personas correctas tengan la información correcta para tomar esas decisiones antes de que la operación las tome por ellos.
Esta diferencia no es semántica. Se manifiesta en cómo se estructuran las reuniones de seguimiento, qué información se eleva a la dirección y cuándo, cómo se diseñan las ventanas de implementación para minimizar el impacto operativo, y qué criterios se usan para decidir si un cambio está listo para producción o no.
En proyectos donde los sistemas críticos no pueden detenerse, el delivery management no es un rol de soporte al equipo técnico. Es la función que preserva el control de la operación mientras el sistema evoluciona. Y eso requiere una lectura simultánea de dos realidades que frecuentemente se gestionan por separado: el estado del proyecto y el estado de la operación.
La métrica que realmente importa
Cuando el marco de referencia cambia de velocidad de entrega a continuidad operativa, la forma de medir el éxito de un proyecto también cambia.
Un proyecto que entregó todas sus funcionalidades en el tiempo comprometido pero que generó tres interrupciones operativas en el proceso no fue exitoso. Un proyecto que tardó más de lo planeado porque eligió rutas conservadoras que preservaron la estabilidad de la operación en todo momento sí lo fue, aunque en la presentación final los números de cronograma no sean perfectos.
Esta distinción parece obvia enunciada así. Pero en la práctica, los incentivos organizacionales frecuentemente apuntan en la dirección contraria: se premia la velocidad visible y se subregistran las interrupciones operativas como "incidentes del proceso", sin conectarlas con las decisiones de delivery que las generaron.
Cambiar esa lógica requiere que quienes lideran proyectos tecnológicos complejos tengan claridad sobre una sola cosa: su trabajo no termina cuando el sistema está desplegado. Termina cuando la operación demuestra que puede sostenerse de forma estable con el nuevo sistema en producción. Todo lo anterior es preparación.
El trade-off que nadie nombra en la propuesta
Cada proyecto tecnológico sobre sistemas en producción implica un trade-off entre velocidad y estabilidad que rara vez se nombra explícitamente en la fase de propuesta. Se habla de cronogramas, de entregables, de metodología. Pero la pregunta de fondo —¿qué tan rápido podemos movernos sin comprometer lo que ya está funcionando?— frecuentemente queda implícita, asumida por cada parte de una forma diferente.
Cuando esa conversación no sucede de forma explícita al inicio, sucede de todas maneras después, pero bajo presión y con menos opciones disponibles. El momento en que un equipo técnico descubre en producción que la ruta que eligieron no era compatible con la operación real no es el momento ideal para tener esa conversación.
En Iridian, este trade-off es parte de las conversaciones que sostenemos desde el inicio de cualquier proyecto sobre sistemas críticos. No porque sea una conversación cómoda, sino porque es la conversación que determina si el proyecto va a poder ejecutarse de verdad o solo va a poder diseñarse bien.
