Por Maximiliano Britez, Head of Engineering redbee.
El 42% del tiempo de los equipos de desarrollo se destina a gestionar deuda técnica, según The Developer Coefficient, el informe de la plataforma financiera Stripe que analiza la eficiencia de la ingeniería de software y su impacto global. Esto es, no se ocupa de construir nuevas funcionalidades, sino de resolver problemas acumulados en sistemas existentes. En términos de inversión, esto representa unos 85.000 millones de dólares anuales destinados a sostener lo que ya existe, de acuerdo con este mismo reporte.
El dilema es bien conocido por las organizaciones: el Global Technology Executive Survey, de la consultora global Protiviti, plantea que el 70% de las empresas declara que su deuda técnica le impide innovar y, sin embargo, el mismo informe desglosa que estas organizaciones destinan el 30% de su presupuesto a mantener dicha deuda. Podría interpretarse como una decisión equivocada; en redbee consideramos que no lo es: con las condiciones previas del mercado, invertir por encima de ese presupuesto no generaba retorno suficiente. El problema no tenía solución, estaba fuera de escala.
Por qué se abandonan los proyectos de modernización
Cuando una organización identifica un sistema que limita la evolución del negocio, la conversación suele derivar hacia uno de dos caminos. El primero: “es muy costoso, lo postergamos para el próximo año”. El resultado es predecible: el año siguiente el problema persiste, agravado, porque el sistema legado siguió creciendo y las vulnerabilidades y las funcionalidades pendientes son aún más difíciles de abordar. El segundo camino: “avancemos, pero con la mitad del tiempo y el presupuesto”. El resultado es igualmente predecible: el proyecto se vuelve inviable. Y, con frecuencia, ambos caminos se encadenan: se posponen hasta que la urgencia obliga a actuar y, entonces, se ejecuta bajo presión.
No existe una fórmula secreta: existe un método
Nuestra visión propone una secuencia de cinco fases que permite asegurar la calidad de extremo a extremo. Cabe destacar que estas fases están compuestas de prácticas de ingeniería adoptadas en la industria:
- Discovery. Comprender la composición del sistema legado. El resultado es un documento disponible para todo el equipo de ingeniería.
- Assessment. Elaborar un business case para determinar si la migración es viable. En esta instancia se toma una decisión: migrar lo existente o construir un sistema paralelo y descartar el legado.
- Strategy design. Definir el enfoque de migración en función del contexto específico del cliente.
- ADRs (Architecture Decision Records). Documentar la transición del estado actual hacia la arquitectura propuesta.
- Fitness functions. Un conjunto de tests y métricas que verifican de forma continua que la arquitectura se comporta conforme a lo esperado.
De dos meses a cuarenta minutos
Hasta hace pocos meses, recorrer esas cinco fases demandaba más de dos meses de trabajo con un equipo de ingenieros. Hoy, con un agente y un único ingeniero, el proceso insume aproximadamente 40 minutos. Esto incide directamente en la contradicción señalada al inicio. Cuando estos proyectos se extendían en el tiempo, se producían dos consecuencias recurrentes: se abandonaban o se comprimían. Y cuando ocurría esto último, lo primero que se resignaba era precisamente lo que garantiza la calidad: las fitness functions quedaban sin implementarse, la documentación de arquitectura y los ADRs permanecían incompletos, y las decisiones se tomaban sin un proceso de discovery riguroso como respaldo. Cuando ese proceso puede completarse en 40 minutos, la ecuación se transforma.
¿Qué cambió realmente?
Cuando hacemos estas afirmaciones no nos basamos en nada nuevo: son herramientas de ingeniería con años de trayectoria, y lo que un ingeniero realiza hoy mediante un agente es, en esencia, lo que antes ejecutaba en colaboración con otros ingenieros. Lo que cambió es el tiempo: proyectos que antes demandaban meses o años, y que en muchos casos eran inviables para el negocio por el esfuerzo que requerían, hoy los resolvemos con entre un 50% y un 60% de mayor rapidez y eficiencia.
El método es agnóstico a la tecnología. La única condición verdaderamente determinante es el testing; cuando el sistema legado carece de él, el primer paso, ahora que existe margen para hacerlo, es construir una capa de tests con el sistema original aún en funcionamiento, para garantizar que, al reemplazarlo, el comportamiento se preserve.
Para dimensionarlo en términos de negocio, un proyecto de esta naturaleza reduce el esfuerzo a la mitad, lo cual no representa únicamente un ahorro: significa demostrar valor antes, y redirigir la inversión hacia iniciativas que generan impacto real en los resultados del negocio, en lugar de destinarla a resolver deuda acumulada.
Leer más
- Cómo desactivar Gemini y las funciones de IA en Gmail y Google Docs paso a paso
- Meta revela qué hará con el tiempo que ahorra la IA: más trabajo y nuevos productos
- Cómo desactivar Gemini y las funciones de IA en Gmail y Google Docs paso a paso
