[14/04/2023] Los CIO llevan décadas lidiando con la deuda técnica, pero muchos siguen luchando por gestionarla adecuadamente. Y les está costando caro.
La empresa de consultoría de gestión Protiviti encuestó a más de mil ejecutivos de tecnología para su encuesta 2023 Global Technology Executive Survey, y descubrió que la deuda técnica es un obstáculo importante para la innovación en casi el 70% de las organizaciones. Los ejecutivos también informaron de que la deuda técnica consume el 31% de los presupuestos de TI, y requiere el 21% de los recursos de TI para su gestión.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
La encuesta IT Cost Optimization Survey 2023 de LeanIX arrojó un resultado similar, ya que el 56% de los encuestados afirmaron que la tecnología obsoleta, y la deuda técnica contribuyen en gran medida al despilfarro de los presupuestos de TI.
Mientras tanto, los líderes de TI que gestionan con éxito la deuda técnica están mucho mejor posicionados para permitir que sus organizaciones tengan un mejor rendimiento. Según la empresa de investigación y asesoramiento Gartner, los responsables de infraestructuras y operaciones que gestionan y reducen activamente la deuda técnica pueden conseguir tiempos de prestación de servicios a la empresa al menos un 50% más rápidos.
A la vista de estos resultados, muchos CIO se han centrado en encontrar formas de recortar su deuda técnica. Líderes tecnológicos experimentados comparten cinco estrategias que utilizan para mantener la deuda técnica bajo control.
1. Ser analítico a la hora de medir 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 responsables de TI que elaboren 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 se quedan cortos en estas tres cuestiones fundamentales.
"Uno de los mayores retos es comprender y organizar el alcance de la deuda técnica", afirma Sharp, que explica cómo los equipos de TI tienen dificultades para 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 lo demás en los negocios de hoy, la deuda no puede gestionarse con éxito si no se mide, anota Sharp, añadiendo que TI necesita mejorar en la identificación, seguimiento y medición de la deuda técnica.
"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", añade. "Creo que un enfoque estructurado para analizar esto podría ser una oportunidad para pensar en cosas que antes no se tenían en cuenta. No se trata sólo de saber que tenemos problemas, sino de conocerlos y entender su impacto. La visibilidad es realmente clave".
Sin embargo, Sharp advierte de que no se debe hacer un seguimiento de todas las deudas tecnológicas, sino de las que se pretende solucionar.
Ken Knapton, vicepresidente senior y CIO de Progrexion, también habla de la importancia de conocer los detalles de la deuda que ha acumulado su departamento de TI.
Para ello, él y su equipo de TI desarrollaron un método para medir su deuda. Califican la deuda en función de atributos tecnológicos clave (capacidad de soporte, vida útil restante prevista, estabilidad y duración) y, a continuación, en función de dos atributos adicionales (criticidad empresarial 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 un ratio entre 0 y 1.
Knapton dice que cualquier deuda tecnológica que tenga una puntuación de 0 a 0,4 es aceptable, cualquier cosa entre 0,5 y 0,7 es preocupante, y cualquier cosa por encima de 0,7 es crítica.
"Ahora que tengo un marco para medir la deuda técnica, podemos hacer un seguimiento. Podemos centrarnos en qué parte de nuestra deuda técnica vamos a abordar y en qué vamos a trabajar ahora", añade.
2. Pague su deuda priorizándola en las hojas de ruta
Knapton sostiene que ha visto de primera mano el costo de no pagar la deuda técnica a tiempo.
Señala un incidente pasado en el que un equipo de desarrollo utilizó una biblioteca Java, pero no volvió por el código actualizado en aras del tiempo y la velocidad de comercialización, como suele ser la razón principal para asumir la deuda. Esa decisión, aunque justificada en el momento del desarrollo y despliegue inicial del producto, obstaculizó la capacidad del equipo para añadir actualizaciones o hacer cambios necesarios más adelante.
Knapton anota que ha aprendido que "no hay nada tan permanente como una decisión temporal" si esas decisiones temporales no se revisan.
"Al permitir todas estas pequeñas decisiones, esta deuda técnica puede permanecer en su lugar y entonces tiene soluciones demasiado difíciles, soluciones demasiado complejas, que no le permiten ser tan ágil como puede ser como empresa. Es entonces cuando la deuda técnica empieza a ser un lastre, cuando no la pagamos", afirma.
"Ahora la medimos, la gestionamos y reconocemos que, si vamos a asumir cierta deuda técnica para ser los primeros en llegar al mercado, tenemos que seguir adelante y pagar esa deuda técnica después de lanzarla".
Para asegurarse de que esos pagos se realizan, Knapton afirma que él y su equipo saben que "tenemos que añadir a nuestro calendario la capacidad de gestionarlo y resolverlo".
Para ello, los equipos de Knapton, que trabajan de forma ágil en todo el departamento de TI, han trasladado el objetivo de definir cuándo han "terminado" para incluir la mitigación de la deuda técnica.
"Un proyecto no está terminado hasta que se vuelve atrás y se ajusta lo que sea que se haya asumido como deuda técnica; y todo el mundo está de acuerdo en que así es como definimos 'terminado'", comenta Knapton, señalando que la deuda técnica forma parte de la cartera de tareas pendientes de un equipo hasta que se complete el trabajo de mitigación.
Y añade: "No quiero que una solución temporal se convierta en permanente, así que la ponemos oficialmente en nuestra hoja de ruta".
Otros abogan igualmente por asignar recursos (tiempo y dinero), así como por crear una responsabilidad para hacer frente a la deuda.
Sharp, por ejemplo, habla de "mejorar la verificación sobre el valor que aporta un proyecto, conocer y vigilar las fallas, presupuestar el mantenimiento y cualquier nuevo equipo necesario".
Y añade: "Un número sorprendente de organizaciones no lo hace".
3. Tratar la deuda tecnológica como el riesgo empresarial que es
Enoche Andrade, que como especialista en innovación de aplicaciones digitales en Microsoft ha asesorado a ejecutivos sobre la deuda técnica, señala que la deuda técnica no es sólo un problema para TI; también es un riesgo empresarial, indicando que la deuda técnica tiene implicaciones empresariales, financieras y de seguridad.
Como tal, Andrade anota que la deuda técnica es un tema para todos los ejecutivos y líderes de funciones de negocio, no sólo 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 de la empresa y las necesidades del negocio.
"Los CIO tienen la responsabilidad fundamental de concientizar sobre la deuda técnica al consejo de administración y a los equipos directivos", afirma. "Para fomentar una cultura de concientización y responsabilidad en torno a la deuda técnica, las empresas deben animar a los equipos multifuncionales, y establecer objetivos y métricas compartidos que animen 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 conduce a la innovación y la mejora continua".
Knapton está de acuerdo en la necesidad de tener en cuenta la empresa a la hora de decidir cuándo asumir la deuda técnica, medir su impacto y priorizar lo que hay que amortizar.
Sostiene que las métricas de su equipo de TI realmente ayudan a informar a sus colegas de la C-suite sobre el tema, diciendo: "Ahora tengo una manera de comunicarme con mi junta y mi equipo ejecutivo para decir: 'Esta es nuestra deuda, y estamos apalancados debido a las decisiones que tomamos en el pasado'".
4. Sea intencionado a la hora de contraer nuevas deudas
Mike Huthwaite, CIO de Hartman Executive Advisors, que ofrece liderazgo ejecutivo fraccionado a sus clientes, compara la deuda técnica con la deuda financiera. "Para mí, la deuda es algo en lo que se incurre y que luego se resuelve", añade.
Al igual que a veces es inteligente asumir una deuda financiera, Huthwaite afirma que a menudo es más inteligente optar por la deuda técnica que no hacerlo. Al igual que otros, afirma que los equipos pueden decidir incurrir en deuda técnica por rapidez y agilidad, ventajas de mercado que compensan los costos de la deuda técnica.
"Siempre es un compromiso, y si seguimos con la analogía de la deuda personal, hay puntos o decisiones en los que contraer deuda tiene valor. Pero no deja de ser una deuda. Así que esperemos que lo hagamos de forma prudente", afirma.
Huthwaite señala que instruye a los equipos de TI para que sean deliberados a la hora de asumir la deuda técnica, sopesando los beneficios que obtienen al utilizar, por ejemplo, código subóptimo frente a los inconvenientes de esa decisión. A esto lo llama deuda técnica intencionada, en contraste con la deuda técnica no intencionada, en la que se incurre sin esa deliberación.
"La deuda técnica intencionada tiene su lugar y su valor; la deuda técnica no intencionada es un problema mayor", afirma. "Cuando no hacemos un seguimiento de toda la deuda, entonces puedes encontrarte al borde de la quiebra".
Andrade tiene un consejo similar: aunque las organizaciones no pueden eliminar de forma realista toda la deuda técnica, pueden tomar medidas para limitar su creación (y, en particular, la creación de deuda involuntaria).
Aconseja a los equipos que adopten la metodología de desarrollo ágil, refactoricen, automaticen las pruebas y racionalicen los procesos. Los equipos también deben utilizar herramientas de análisis de código para identificar la deuda técnica, y realizar revisiones periódicas del código por parte de compañeros y partes interesadas para garantizar la calidad del código e identificar posibles problemas. También deben adoptar la simplificación arquitectónica, la componentización y la estandarización.
5. Reconocer que la gestión de la deuda es un proceso continuo
Wayne F. McGurk, CIO y SVP de TI de la National Rural Electric Cooperative Association, no ve la deuda técnica como algo bueno o malo, sino más bien como "un resultado natural del proceso de desarrollo, que se produce porque se está construyendo algo nuevo".
"Hay una tendencia a ir tan rápido como se pueda para sacar el MVP, y no se construye necesariamente una aplicación demasiado industrializada al principio", señala. Los equipos hacen concesiones y optan por tecnologías que funcionan para el MVP, pero que saben que serán insuficientes a medida que se amplíen las soluciones.
Por ello, McGurk tiene en cuenta este factor no sólo en su ciclo de desarrollo, sino también en las operaciones de TI, aplicando 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 extraer todo eso y notificarlo y examinarlo".
McGurk también tiene en cuenta cómo afecta cada deuda técnica a las operaciones en cinco áreas clave: simplicidad, flexibilidad, continuidad, seguridad y transparencia.
"Cuando la deuda técnica empieza a obstaculizar alguno de esos principios operativos, entonces ha llegado al 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 global de ésta para priorizar lo que necesita atención. A continuación, dan a conocer esas determinaciones, creando así visibilidad sobre 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 trata como un proyecto puntual, sino que se gestiona 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 un proyecto no se acaba porque se entregue. Es un viaje que no tiene fin, por lo que se convierte en parte de la estrategia de gestión de la demanda: gestionar tanto la demanda de trabajo nuevo como el trabajo heredado y la deuda técnica", afirma.
Basado en el artículo de Mary K. Pratt (CIO) y editado por CIO Perú