Consejos para abordar la deuda técnica

Nada en el mundo es perfecto, incluido el código de software. De hecho, a la mayoría de los programadores no se les da tiempo para crear un código ni siquiera casi perfecto. Con la presión de implementar rápidamente, a menudo lanzan código problemático sabiendo que tendrá que ser corregido en el futuro. Eso crea deuda técnica.

“Vemos una gran cantidad de deuda técnica desde el punto de vista del código. [Los programadores] pecan de exceso de velocidad e innovación, e implementan código que no ha pasado el control de calidad como debería. Eso creará problemas en el futuro”, afirma Nate Buniva, socio de la empresa de servicios digitales West Monroe. “Y ocurre cada vez más”.

Aunque el término “deuda técnica” se aplica a veces a cualquier tecnología obsoleta y se considera a menudo sinónimo de “tecnología heredada”, en un principio se refería específicamente al código y, en muchos círculos tecnológicos, todavía se entiende así. Sin embargo, al igual que los directores de informática deben eliminar los componentes heredados de su infraestructura tecnológica que lastran sus estrategias empresariales, suponen un riesgo para su seguridad y añaden costes a sus presupuestos, también deben hacer frente a la deuda técnica.

El coste de no hacerlo puede ser elevado. El estudio más reciente disponible, de 2022, sitúa el coste de la mala calidad del software en 2,41 billones de dólares solo en Estados Unidos. Ante esta realidad, se está presionando a los CIO para que implementen prácticas que mantengan bajo control su deuda tecnológica. A continuación, varios líderes tecnológicos con amplia experiencia comparten seis estrategias que utilizan para reducir su deuda técnica.

1. Analizar la medición de la deuda técnica

Andrew Sharp, director de investigación de la práctica de infraestructura y operaciones de Info-Tech Research Group, es un firme defensor de la catalogación de la deuda técnica. El analista aconseja a los líderes de TI que establezcan una lista de su deuda técnica crítica, conozcan el impacto empresarial de esa deuda y dispongan de un proceso para abordarla.

Según él y otros, muchos CIO a menudo se quedan cortos en estas tres cuestiones fundamentales. “Uno de los mayores retos es simplemente comprender y organizar el alcance de la deuda técnica”, afirma Sharp, explicando cómo los equipos de TI luchan por conocer la cantidad y el impacto de la deuda técnica “porque se extiende a diferentes sistemas. Tiene efectos en cadena”.

Pero, como casi todo en los negocios hoy en día, la deuda no se puede gestionar con éxito si no se mide, afirma Sharp, añadiendo que los departamentos de TI deben mejorar en la identificación, el seguimiento y la medición de la deuda tecnológica. “El departamento de TI siempre sabe dónde están los problemas, qué armarios esconden esqueletos, pero a menudo no hay un análisis formal”, afirma. “Creo que un enfoque estructurado para abordar esta cuestión podría ser una oportunidad para pensar en cosas que antes no se tenían en cuenta. No se trata solo de saber que tenemos problemas, sino de saber cuáles son y comprender su impacto. La visibilidad es realmente clave”.

Sin embargo, Sharp advierte contra el seguimiento de cada parte de la deuda técnica y destaca la necesidad de hacer un seguimiento de la deuda que se pretende solucionar.

2. No pasar por alto el código generado por IA

Los trabajadores de TI y, de hecho, de toda la empresa están utilizando la IA generativa para escribir código. Algunas investigaciones han descubierto que la IA generativa puede mejorar ligeramente la calidad del código. Sin embargo, la mayoría de las organizaciones pueden esperar “ver un exceso de software muy mediocre durante el próximo año o los dos siguientes”, afirma Mike Mason, director de IA de Thoughtworks, que ofrece servicios de diseño y entrega de software, así como servicios de consultoría.

“La IA permite generar código rápidamente, pero [las personas] parecen más adaptadas a generar código nuevo que a corregirlo”, afirma, señalando que gran parte de ese código mediocre se traslada a la fase de producción sin ser revisado por desarrolladores expertos ni someterse a controles de calidad automatizados. “Prevemos que las organizaciones se verán en apuros, ya que conseguirán que más funciones se implementen más rápido, pero esto provocará un exceso de código y, por lo tanto, más deuda tecnológica y código heredado”, añade.

Eso no significa que los trabajadores no deban utilizar la IA para la codificación, afirma Mason. Más bien, las organizaciones deben asegurarse de que cuentan con los procesos y las herramientas, incluidas las basadas en la IA, para garantizar que no se cuela una cantidad inaceptable de código de mala calidad.

3. Aplicar la gobernanza a la deuda técnica

La mayoría de las organizaciones cuentan con algún tipo de gobernanza en torno a sus programas de desarrollo de software, afirma Buniva. Sin embargo, muchos de esos programas de gobernanza no son tan sólidos como deberían ni lo suficientemente detallados como para informar a los equipos sobre cómo deben equilibrar la velocidad y la calidad, un hecho que se hace más evidente con el aumento de la velocidad de producción de código habilitado para la IA. “La gobernanza no está al día con la IA generativa”, afirma Buniva. “Se necesita una gobernanza adecuada para la IA generativa, que no ralentice la innovación, pero que tampoco permita crear una gran cantidad de deuda técnica”.

Un buen programa de gobernanza debe establecer requisitos para las pruebas y el control de calidad, así como especificar cuándo deben intervenir los seres humanos en lugar de las decisiones automatizadas de control de calidad, afirma Buniva. También debe abordar los requisitos de formación, de modo que cualquier persona que desarrolle código esté familiarizada con las normas.

4. Priorizar lo que se paga

Al igual que la tecnología heredada en general, la deuda de código es una realidad y, como tal, nunca se pagará por completo. Por lo tanto, en lugar de intentar reducir el saldo a cero, el ejecutivo de TI Rishi Kaushal da prioridad a la reparación de las piezas más problemáticas, aquellas que podrían costarle más a su empresa.

“No conviene centrarse en solucionar la deuda técnica que requiere mucho tiempo y dinero, pero que no aporta ningún valor”, afirma Kaushal, director de informática de Entrust, empresa dedicada a soluciones de identidad y seguridad. Se centra en abordar la deuda técnica que supone un riesgo para la seguridad o que crea fricciones en la experiencia de los usuarios, el mismo enfoque que aplica a la tecnología heredada en su conjunto. “Está bien tener cierta deuda tecnológica; está bien mantenerla. Por lo tanto, hay que decidir con qué deuda tecnológica se puede vivir mientras se mejoran otras cosas”, añade.

Mark Gibson, director global de tecnología, medios y telecomunicaciones de la empresa de servicios profesionales KPMG, ofrece una estrategia similar y aconseja “inversiones muy específicas y proactivas, y correcciones rápidas” a la hora de abordar cualquier tecnología heredada, incluida la deuda de código. Afirma que la mayoría de los directores de informática saben dónde están esos puntos débiles. Señala los resultados del informe Global Tech Report 2024 de su empresa, que muestra que el 57% de los líderes de las organizaciones encuestadas afirman que los fallos en sus sistemas informáticos básicos perturban el funcionamiento habitual de la empresa cada semana.

Arreglar esos sistemas problemáticos es un buen punto de partida, afirma Gibson, quien añade que los CIO podrían utilizar los registros y las encuestas de su personal de TI para identificar otros problemas que deberían encabezar la lista de prioridades a resolver.

Y cuando se trata de obtener respaldo para hacer frente a la deuda tecnológica, los responsables de TI deben convencer a la alta dirección de que la deuda tecnológica es un riesgo para el negocio.

5. Ser específico al establecer los objetivos

Bobby Cain, vicepresidente y director de TI para Norteamérica de Schneider Electric, tiene que reducir la tecnología heredada en un 12% para finales de 2025. “Tenemos unos objetivos claramente definidos”, afirma.

Tener un objetivo específico proporciona a Cain y a su equipo un incentivo evidente para modernizar los sistemas y abordar cualquier código problemático en el proceso. Para alcanzar ese objetivo, Cain ha ideado una estrategia múltiple que incluye catalogar y medir su estado actual para saber dónde se encuentra la tecnología heredada y la deuda tecnológica, así como priorizar y planificar las medidas a tomar.

Aunque este trabajo es fundamental para cualquier función de TI bien gestionada, Cain reconoce que tener un objetivo asignado mantiene la motivación del equipo. Como señala, “no se puede impulsar el cambio sin una función impulsora”.

6. Reconocer que la gestión de la deuda es un proceso continuo

Wayne F. McGurk, director de informática y vicepresidente de TI de la Asociación Nacional de Cooperativas Eléctricas Rurales de Estados Unidos, no considera que la deuda técnica sea algo bueno o malo, sino “un resultado natural del proceso de desarrollo, que se produce porque se está construyendo algo nuevo”. “Existe la tendencia a ir lo más rápido posible para sacar el MVP [producto mínimo viable] al mercado, y no necesariamente se crea una aplicación excesivamente industrializada al principio”, afirma. Los equipos hacen concesiones y optan por tecnologías que funcionan para el MVP, pero que saben que serán insuficientes a medida que las soluciones se amplíen.

Por lo tanto, McGurk tiene en cuenta este factor no solo en su ciclo de desarrollo, sino también en las operaciones de TI, y recurre a diversas tácticas para crear un enfoque holístico que permita gestionar la deuda técnica de forma continua. Como parte de este enfoque, el equipo de McGurk documenta y detalla la introducción de cualquier nueva deuda técnica, que luego se rastrea a través del sistema de tickets de la organización para que los equipos de TI “puedan recuperarla, informar sobre ella y examinarla”.

McGurk también tiene en cuenta cómo cada elemento de la deuda técnica afecta a las operaciones en cinco áreas clave: simplicidad, flexibilidad, continuidad, seguridad y transparencia. “Cuando la deuda técnica empieza a obstaculizar cualquiera de esos principios operativos, entonces ha alcanzado el nivel en el que queremos abordarla”, explica.

McGurk y su equipo de TI tienen en cuenta el nivel de impacto, el riesgo para la organización y la estrategia general de esta para priorizar lo que requiere atención. A continuación, comunican esas decisiones, lo que permite visibilizar el tema en toda la organización. Todo esto se integra en el flujo de trabajo de su departamento de TI, afirma McGurk, lo que garantiza que la gestión de la deuda técnica no se trate como un proyecto puntual, sino que se gestione de forma continua. Por ejemplo, se espera que sus equipos Scrum identifiquen nuevas deudas técnicas y determinen cuándo y cómo abordarlas.

“Hay que crear una cultura de rendición de cuentas y responsabilidad para que los equipos sepan que el hecho de que un proyecto se haya entregado no significa que haya terminado. Es un viaje sin fin, por lo que se convierte en parte de la estrategia de gestión de la demanda, que consiste en gestionar tanto la demanda de nuevos trabajos como los trabajos heredados y la deuda técnica”, afirma.