5 consejos para hacer frente a la deuda técnica

Los CIO se han enfrentado a la deuda técnica durante décadas, pero muchos todavía luchan por administrarla adecuadamente. Y les está costando.

La firma de consultoría de gestión Protiviti encuestó a más de 1.000 ejecutivos de tecnología para su encuesta de ejecutivos de tecnología global de 2023 y descubrió que la deuda técnica es un obstáculo importante para la innovación para casi el 70% de las organizaciones. Los ejecutivos también informaron que la deuda tecnológica consume el 31% de los presupuestos de TI y requiere administrar el 21% de los recursos de TI.

La encuesta de Optimización de Costes de TI 2023 de LeanIX tuvo un hallazgo similar, ya que el 56% de los encuestados dijo que la tecnología obsoleta y la deuda técnica contribuyen particularmente a los presupuestos de TI derrochados.

Mientras tanto, los líderes de TI que administran con éxito la deuda técnica están mucho mejor posicionados para permitir que sus organizaciones se desempeñen mejor. Según la firma de investigación y asesoría Gartner, los líderes de infraestructura y operaciones que administran y reducen activamente la deuda técnica pueden lograr tiempos de entrega de servicios al negocio al menos un 50% más rápidos.

Dados estos hallazgos, muchos CIO se han centrado en encontrar formas de recortar su deuda técnica. Los líderes tecnológicos experimentados comparten cinco estrategias que utilizan para mantener la deuda tecnológica bajo control.

 

1. Obtener un análisis sobre la medición de la deuda técnica

Andrew Sharp, director de investigación para la práctica de infraestructura y operaciones en Info-Tech Research Group, es un firme defensor de catalogar 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 comercial de esa deuda y tengan un proceso para abordarla.

Muchos CIO, dicen él y otros, con demasiada frecuencia se quedan cortos en estos tres temas fundamentales.

“Uno de los mayores desafíos es simplemente comprender y organizar el alcance de la deuda técnica”, dice 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 colaterales”.

Pero como casi todo lo demás en los negocios hoy en día, la deuda no se puede administrar con éxito si no se mide, dice Sharp, y agrega que TI debe mejorar en la identificación, el seguimiento y la medición de la deuda tecnológica.

 

“TI siempre tiene una idea de dónde están los problemas, qué armarios tienen esqueletos, pero a menudo no hay un análisis formal”, dice. “Creo que un enfoque estructurado para analizar esto podría ser una oportunidad para pensar en cosas que no se consideraron anteriormente. Entonces, no se trata solo de saber que tenemos problemas, sino de saber cuáles son los problemas y comprender el impacto. La visibilidad es realmente clave”.

Sin embargo, Sharp advierte contra el seguimiento de cada parte de la deuda tecnológica y enfatiza en cambio la necesidad de rastrear la deuda que se pretende arreglar.

Ken Knapton, vicepresidente senior y CIO de Progrexion, también habla de la importancia de conocer los detalles sobre la deuda que ha acumulado su departamento de TI.

Con ese fin, él y su equipo de TI desarrollaron un método para medir su deuda. Califican la deuda según los atributos tecnológicos clave (soporte, vida útil restante esperada, estabilidad y duración) y luego según dos atributos adicionales (criticidad del negocio y alineación estratégica). Multiplican la suma de los cuatro atributos clave por la suma de los dos últimos y luego normalizan los valores a una proporción entre 0 y 1.

Knapton dice que cualquier deuda tecnológica con una calificación de 0 a 0,4 es aceptable, cualquier valor entre 0,5 y 0,7 es preocupante y cualquier valor superior a 0,7 es crítico.

“Ahora que tengo un marco para medir la deuda técnica, podemos rastrearla. Podemos centrarnos en qué parte de nuestra deuda técnica vamos a abordar y en qué vamos a trabajar ahora”, añade.

 

2. Pagar la deuda priorizándola en las hojas de ruta

Knapton dice que ha visto de primera mano el coste de no pagar la deuda técnica de manera oportuna.

Señala un incidente pasado en el que un equipo de desarrollo usó una biblioteca de Java pero no volvió a buscar el código actualizado en aras del tiempo y la velocidad de comercialización, ya que suele ser la razón principal para endeudarse. Esa decisión, si bien estaba justificada en el momento del desarrollo y la implementación iniciales del producto, obstaculizó la capacidad del equipo para agregar actualizaciones o realizar los cambios necesarios más adelante.

Knapton dice que ha aprendido que “no hay nada tan permanente como una decisión temporal” si esas decisiones temporales no se revisan.

“Debido a que permites todas estas pequeñas decisiones, esta deuda técnica puede permanecer en su lugar y luego tienes soluciones demasiado difíciles, soluciones demasiado complejas, que no te permiten ser tan ágil como un negocio. Ahí es cuando la deuda técnica comienza a ser un pasivo, cuando no la saldamos”, dice.

“Ahora lo medimos, lo gestionamos y reconocemos que si vamos a asumir alguna deuda técnica para ser los primeros en el mercado, tenemos que cumplir y pagar esa deuda técnica después de que lancemos”.

Para asegurarse de que se realicen esos pagos, Knapton dice que él y su equipo saben que "tenemos que agregar a nuestra línea de tiempo la capacidad de administrarlo y resolverlo".

Para respaldar eso, los equipos de Knapton, que trabajan de manera ágil en toda la TI, cambiaron la meta para definir cuándo "terminaron" para incluir la mitigación de la deuda técnica.

“Un proyecto no está terminado hasta que regresas y ajustas lo que sea que asumiste como deuda técnica; y todos están de acuerdo en que así es como definimos 'hecho'”, dice Knapton, señalando que la deuda técnica es parte de la cartera de pedidos de un equipo hasta que se completa el trabajo de mitigación.

Agrega: "No quiero que una solución temporal se convierta en permanente, así que la ponemos oficialmente en nuestra hoja de ruta".

Otros abogan de manera similar por la asignación de recursos (tiempo y dinero), así como por la creación de responsabilidades para hacer frente a la deuda.

Sharp, por ejemplo, habla de "mejorar la verificación del valor que proporciona un proyecto, conocer y vigilar los errores, presupuestar el mantenimiento y cualquier equipo nuevo necesario".

Y agrega: "Un número sorprendente de organizaciones no hacen eso".

 

3. Tratar la deuda tecnológica como el riesgo comercial que es

Ennoche Andrade, quien como especialista en innovación de aplicaciones digitales en Microsoft ha asesorado a ejecutivos sobre deuda técnica, dice que la deuda técnica no es solo un problema para TI; también es un riesgo comercial, lo que indica que la deuda técnica tiene implicaciones comerciales, financieras y de seguridad.

Como tal, Andrade dice que la deuda técnica es un tema para todos los ejecutivos y líderes de funciones comerciales, no solo de TI, y las decisiones sobre cuándo y cuánta deuda técnica incurrir y cuándo y cómo se paga deben alinearse con la estrategia empresarial y las necesidades comerciales.

“Los CIO tienen la responsabilidad crítica de crear conciencia sobre la deuda técnica entre la junta directiva y los equipos de liderazgo”, dice. “Para fomentar una cultura de concienciación y responsabilidad en torno a la deuda técnica, las empresas deben fomentar equipos multifuncionales y establecer objetivos y métricas compartidas que alienten a todos los grupos a trabajar juntos para abordar la deuda técnica y fomentar la innovación. Esto puede incluir la creación de un entorno seguro para que los desarrolladores experimenten con nuevos enfoques y tecnologías, lo que lleva a la innovación y la mejora continua”.

Knapton está de acuerdo con la necesidad de hacer un bucle en el negocio al decidir cuándo asumir deuda técnica, medir su impacto y priorizar qué pagar.

Él dice que las métricas de su equipo de TI realmente ayudan a informar a sus colegas de C-suite sobre el tema. "Ahora tengo una forma de comunicarme con mi junta y mi equipo ejecutivo para decir: 'Esta es nuestra deuda, y estamos apalancados debido a decisiones que tomamos en el pasado”, comenta.

 

4. Ser intencional al asumir nuevas deudas

Mike Huthwaite, un CIO de Hartman Executive Advisors, que brinda liderazgo ejecutivo fraccional a los clientes, compara la deuda técnica con la deuda financiera. “La deuda conmigo es algo en lo que incurres, que luego resuelves”, agrega.

Así como a veces es inteligente asumir una deuda financiera, Huthwaite dice que a menudo es más inteligente optar por una deuda técnica que no hacerlo. Al igual que otros, dice que los equipos pueden decidir incurrir en deuda técnica por velocidad y agilidad, ventajas de mercado que superan los costos de la deuda técnica.

“Siempre es una compensación y si continúa con la analogía de la deuda personal, hay puntos o decisiones en las que asumir deuda tiene valor. Pero sigue siendo deuda igual. Así que espero que lo estés haciendo de manera prudente”, dice.

Huthwaite dice que instruye a los equipos de TI para que sean deliberados a la hora de asumir deudas técnicas, sopesando los beneficios que obtienen al usar, por ejemplo, un código subóptimo frente a las desventajas de esa decisión. Él llama a eso deuda técnica intencional, en contraste con la deuda técnica no intencional que se incurre sin tal deliberación.

“La deuda técnica intencional tiene su lugar y su valor; la deuda técnica no intencional es un problema mayor”, dice. “Cuando no hacemos un seguimiento de toda la deuda, puede encontrarse al borde de la bancarrota”.

Andrade tiene palabras de consejo similares, diciendo que aunque las organizaciones no pueden eliminar de manera realista toda la deuda técnica, pueden tomar medidas para limitar su creación (y particularmente la creación de deuda no intencional).

Aconseja a los equipos que adopten la metodología de desarrollo ágil, refactoricen, automaticen las pruebas y simplifiquen los procesos. Los equipos también deben usar herramientas de análisis de código para identificar la deuda técnica y realizar revisiones periódicas del código por parte de colegas y partes interesadas para garantizar la calidad del código e identificar problemas potenciales. También deben adoptar la simplificación arquitectónica, la creación de componentes y la estandarización.

 

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

Wayne F. McGurk, CIO y vicepresidente sénior de TI de la Asociación Nacional de Cooperativas Eléctricas Rurales, no ve la deuda técnica como algo bueno o malo, sino como "un resultado natural del proceso de desarrollo, que ocurre porque se está construyendo algo nuevo".

“Hay una tendencia a ir lo más rápido posible para sacar el MVP y no necesariamente se crea una aplicación demasiado industrializada al principio”, dice. Los equipos hacen concesiones y optan por tecnologías que funcionan para el MVP que saben que serán insuficientes a medida que escalan las soluciones.

Por lo tanto, McGurk tiene en cuenta eso no solo en su ciclo de desarrollo, sino también en las operaciones de TI, incorporando varias tácticas para crear un enfoque holístico para administrar la deuda técnica de manera 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 emisión de boletos de la organización para que los equipos de TI "puedan sacar todo eso, informarlo y analizarlo".

 

McGurk también considera cómo cada parte de la deuda técnica afecta las operaciones en cinco áreas clave: simplicidad, flexibilidad, continuidad, seguridad y transparencia.

“Cuando la deuda técnica comienza a obstaculizar cualquiera de esos principios operativos, entonces se eleva al nivel en el que queremos abordarlo”, explica.

McGurk y su equipo de TI consideran el nivel de impacto, el riesgo para la organización y la estrategia general de la organización para luego priorizar lo que necesita atención. Luego dan a conocer esas determinaciones, creando así visibilidad sobre el tema en toda la organización.

Todo esto se incluye en el flujo de trabajo de su departamento de TI, dice McGurk, lo que garantiza que la gestión de la deuda técnica no se trate como un proyecto único, sino que se gestione de manera continua. Por ejemplo, se espera que sus equipos de Scrum identifiquen nuevas deudas técnicas y determinen cuándo y cómo abordarlas.

“Tienes que construir la cultura de rendición de cuentas y responsabilidad. Es un viaje, y no tiene fin, por lo que se convierte en parte de su estrategia de gestión de la demanda: manejar tanto la demanda de trabajo nuevo como el trabajo heredado y la deuda técnica”, dice.