El CTO como traductor de la deuda tecnológica

Qué es la deuda tecnológica

El sector empresarial relacionado a la tecnología vive una aceleración nunca vista antes. La competitividad existente hace que el cumplimiento de plazos exija una toma de decisiones acertada, en el que la presión puede ocasionar errores de código por parte de los desarrolladores, que requerirán solución en el futuro y que constituye una especie de “deuda técnica”.

Este es un concepto actual utilizado para definir el coste de solventar esos errores y mantener funcionando en condiciones óptimas un software concebido o desarrollado en forma defectuosa desde su origen.

Este coste viene marcado por el re-trabajo que las empresas tienen que pagar con tiempo, dinero y recursos, generalmente por priorizar la velocidad de ejecución frente a la calidad del producto final, a fin de cumplir los plazos y generando una deuda (código mal estructurado, sin documentación, difícil de leer y entender, sin tests funcionales o de integración, etcétera) que en algún momento será necesario pagar.

En su estudio, la consultora IDG recoge que el 86% de los más de 400 responsables de IT encuestados se han visto impactados por la deuda tecnológica en los últimos doce meses, lo que hace que, detrás de la escasez de talento, sea su principal preocupación.

No obstante, en muchos casos los responsables de empresas minimizan este problema descartando la necesidad de determinar su origen e impactos no deseados.

Es un concepto acuñado por Ward Cunnigham - coautor del Manifiesto para el desarrollo ágil - que describe los aspectos técnicos mal gestionados, que generan carga adicional de trabajo, estrés e ineficiencia operativa continua.

Tipos de deuda tecnológica

Si bien existe abundante bibliografía sobre la deuda técnica a nivel de código, también existe la deuda técnica arquitectónica. Según R. Verdecchia, P. Kruchten, P. Lago, & I. Malavolta, es una metáfora utilizada para describir las decisiones de diseño (estratificación, descomposición en subsistemas, interfaces, marcos, tecnologías, lenguajes, plataforma etc.) que, aunque adecuadas o incluso óptimas cuando se tomaron, obstaculizan significativamente el progreso en el futuro.

Mientras la deuda técnica a nivel de código es fácilmente detectable mediante analizadores estáticos, o factible de refactorizar sin mayores esfuerzos, la deuda arquitectónica es difícil de identificar y a menudo se evita.

Steve McConnell, ingeniero de software en jefe en Construx Software, sugiere que hay dos tipos de deuda técnica según la intención.

Deuda técnica intencional, deliberada o activa

Se produce cuando el equipo, apostando al presente en detrimento del futuro, retrasa conscientemente la resolución de algunos problemas para lograr el objetivo establecido, por ejemplo, lanzar la actualización a tiempo.

También puede surgir de forma reactiva, por razones tácticas, como la utilización de los recursos existentes.

Además, la deuda a corto plazo puede ser focalizada, con “atajos” individuales perfectamente identificables, o no focalizada, con numerosos pequeños “atajos”.

Deuda técnica no intencional, obsoleta o pasiva

Ocurre cuando el equipo está haciendo un trabajo deficiente sin siquiera saberlo, mientras acumula muchos problemas en el camino.

Según un estudio de Portdar y Shihab de (2014) los desarrolladores más experimentados tienden a introducir la mayor parte de la deuda técnica autoadmitida y que las presiones de tiempo y la complejidad del código no se correlacionan con su cantidad.

Además, aunque se supone que la deuda técnica autoadmitida debe tratarse o eliminarse en un futuro, sólo entre el 26,3% y el 63,5% es eliminada realmente de los proyectos después de su introducción.

Por otro lado, la deuda técnica no intencionada ocurre debido a errores no deseados, falta de conocimiento o comprensión.

Causas de la deuda tecnológica

El concepto de deuda técnica se amplía a todas las empresas, no sólo a los productores de software, y se genera por múltiples factores.

Falta de inversión

La falta de inversión en mantenimiento y actualización de centros de datos puede generar deuda tecnológica.

La concepción del recurso humano como gasto (no como inversión) hace reticente la inversión en la optimización del equipo TI.

La rémora a la hora de invertir en nuevas tecnologías también es un factor importante y no solo tiene connotaciones financieras también suele evitarse invertir en este rubro por miedo a que las innovaciones en operaciones críticas generen más problemas. En ciertas ocasiones se contratan tecnologías teniendo en cuenta solo el precio, con una definición vaga y alcances limitados.

Enfoque en soluciones rápidas en lugar de soluciones a largo plazo

Al igual que en las finanzas, la deuda técnica puede ocasionar consecuencias positivas o negativas.

Existe una deuda que podría denominarse prudente y deliberada cuando nace de una decisión calculada, el coste es relativamente bajo y los beneficios superan el riesgo.

Son decisiones estratégicas que obedecen a las políticas de la compañía, el cumplimiento de su misión y sus valores.

Falta de mantenimiento y actualizaciones

El tema de las actualizaciones es complejo porque se debate entre factores de seguridad, economía y eficiencia. A veces es necesario un crecimiento rápido que encuentra dificultades por carencia de escalabilidad en sus sistemas o plataformas.

La implantación de nuevas funcionalidades puede también convertirse en un dilema a resolver (incluso imposible), especialmente cuando hay responsabilidades poco claras entre los componentes arquitectónicos de un sistema, dificultando el cumplimiento de requisitos de las partes interesadas y acarreando consecuencias más graves, como el aplazamiento de las versiones previstas.

Consecuencias de mantenerla

En general, se identifican tres tipos de consecuencias: relacionadas con el negocio (aumento de costes y baja de rentabilidad, pérdida de oportunidades, pérdida de clientes por insatisfacción), con la funcionalidad (hacer que un producto sea más vulnerable y menos eficaz) y con el desarrollo del producto (pérdida de velocidad de desarrollo, tiempo extra para reparar errores).

Esto implica más defectos e interrupciones en el funcionamiento del sistema, mayor tiempo de resolución de problemas y adicionalmente, frustración y baja la moral de quienes deben reparar errores ocasionados bajo presiones extenuantes.

Aumento de costos

Hacerlo rápido y mal puede generar mayores costos (muchas veces no identificables de inmediato) dada la cantidad creciente de recursos que hay que dedicar a lo largo del ciclo de desarrollo de producto al mantenimiento y la evolución de sistemas con un uso intensivo de software.

Para mitigar el impacto negativo de mayores costes en la percepción del cliente, es posible invertir recursos de modo que los esfuerzos de refactorización sean tangibles para sus usuarios finales (por ejemplo, mejorar el front-end).

Pérdida de productividad

Un gran número de miembros del equipo de ingeniería reconoce que la mayor parte de la deuda técnica vive en el backend, en los endpoints del servidor web.

Las aplicaciones y sitios web de las empresas y su infraestructura general también acumulan deuda. Los resultados sugieren que sería posible aumentar significativamente la productividad reduciendo la deuda técnica en estas áreas de su código base.

Según el estudio mencionado de Stepsize, las empresas con más de 100 equipos de ingenieros suelen dedicar más tiempo a realizar tareas de mantenimiento de forma continua (alrededor de 7 horas a la semana invierten los profesionales informáticos en corregir errores y deficiencias de “deuda técnica”).

Las pequeñas y medianas empresas prefieren realizarlas por proyectos. El 54% de los ingenieros de los grandes equipos de ingeniería afirma realizar tareas de mantenimiento de forma regular, mientras que sólo lo hace el 42% de los ingenieros de las nuevas empresas y de las empresas medianas.

Problemas de seguridad

Muchas empresas evitan actualizar periódicamente sus sistemas y emplean versiones obsoletas que pueden ser perjudiciales para la seguridad de la empresa.

Así como se producen islas organizativas a nivel de gestión también se da este caso a nivel de información. Estos silos o islas suelen quedar fuera del control de los procesos estándar repercutiendo también gravemente en la seguridad.

Riesgos de la deuda tecnológica

Los riesgos pueden evaluarse considerando las consecuencias que se han detallado, pero sin dudas la deuda arquitectónica puede generar mayores impactos no deseados a largo plazo que la de código.

Durante el ciclo de vida de un sistema de software pueden pasar años y su tamaño puede incrementarse en forma considerable, volverse impredecibles en cuanto al comportamiento esperado y las decisiones de diseño originales, convertirse en restricciones y limitar su evolución futura o hasta impedirla. Estos sistemas grandes y longevos sufren deuda arquitectónica, mientras que los pequeños y efímeros mueren antes de que se convierta en un verdadero problema.

La exposición al riesgo es una consecuencia potencial, que puede ocasionar otras consecuencias e impactos mayores, sobre todo cuando se mantienen grandes aplicaciones monolíticas que en general exigen la intervención de talento humano especializado y por ende, costoso.

Interrupción del negocio

El estudio de IDG evidencia que casi el 50% de los entrevistados reconoce haber sufrido, como consecuencia de la deuda tecnológica, interrupciones y tiempo de inactividad, capacidad limitada para innovar y dificultades para cumplir con los acuerdos de nivel de servicio.

También puede verse afectada la capacidad de llevar a cabo un desarrollo paralelo entre distintos equipos especialmente en componentes que encapsulan una gran parte de la lógica de negocio o los datos de un sistema de software intensivo.

Todo ello puede tener en jaque a los equipos y paralizar el inicio de nuevos proyectos.

Costos adicionales

Es lógico que la deuda de código y la arquitectónica generen costes adicionales a la gestión sobre todo por horas de desarrollo no previstas en los presupuestos iniciales. Otra dificultad es la de dimensionar estos costes y su asignación puesto que pueden aparecer en ejercicios contables posteriores a los que les dieron origen.

Falta de alineación con la estrategia de la empresa

La estrategia de negocios de una compañía es la que orienta el accionar de la dirección y las políticas son sus directrices que luego se llevarán a cabo mediante planes, objetivos, metas y acciones.

Las políticas de la empresa deben ser una guía permanente a la hora de tomar decisiones en las que se pondere la velocidad de ejecución frente a la calidad del producto final.

La deuda técnica intencional es una decisión que debe tomarse en un todo de acuerdo a la estrategia empresarial. Estas decisiones deben ser coherentes con la misión, valores y políticas de la compañía.

Hay muchos casos, en que estos valores y políticas son traicionados para satisfacer las necesidades de partes interesadas o cumplir los compromisos adquiridos con ellas por parte de los departamentos de negocios, bajo la suposición (a menudo incorrecta) de que estas deficiencias se resolverán en una fase posterior, por desconocimiento (comprender claramente el contexto de un sistema de software intensivo es fundamental fin de mitigar el establecimiento de elementos de deuda tecnológica), o sencillamente porque no les interesan las consecuencias y presionan a los técnicos para que cumplan sus promesas a riesgo de sembrar problemas graves en el mediano o largo plazo.

Beneficios de corregirla

• Mejora de la eficiencia operativa: Una gestión adecuada de la deuda técnica es vital para la optimización de la gestión operativa. Todos los problemas y consecuencias que se han descripto anteriormente en este artículo pueden verse minimizados en la medida que se tomen las decisiones oportunas en tiempo y forma.

• Incremento de la seguridad: Abordar la deuda tecnológica puede evitar que se incrementen los problemas de inseguridad en la empresa, esto redundará en la gestión de productos, pero puede impactar en forma positiva en la de clientes y negocios.

• Incremento de la satisfacción del cliente: Si a las empresas desarrolladoras les cuesta dimensionar la deuda técnica y la complejidad de reparar errores, es fácil imaginar los problemas que acarrea al cliente, ser víctima de vicios en sus sistemas que lo obligan en forma reiterada a solicitar reparaciones o suspensiones de funciones.

Abordar con seriedad y eficacia el tratamiento de la deuda sin dudas, incrementa la satisfacción de los clientes.

Papel del CTO ante la deuda tecnológica

El Chief Technology Officer (CTO) es el responsable de los sistemas informáticos de una organización, en algunos casos también analiza de forma integral el uso tecnológico de la compañía y es responsable del producto final y su mejora continua.

Su papel ha variado mucho en los últimos años y cada vez más se transforma en un conector, como ya vimos en el artículo sobre la evolución del perfil del CTO en los próximos años, entre la alta dirección, áreas funcionales y el resto de la organización.

La responsabilidad de la deuda como su pago son decisiones que debe tomar el CTO y debe poder traducir a la conducción de la organización las consecuencias y riesgos que se asumen como las formas de mitigarla o evitarla.

Identificación de la deuda tecnológica

Se ha hablado de deuda técnica involuntaria que suele ser difícil de detectar y cuantificar y de deuda intencionada cuyo seguimiento resulta problemático pero asumible.

Es posible dar transparencia a la carga de la deuda, al menos de dos modos:

• Elaborar un sistema de seguimiento: registrar cada deuda generada y las tareas necesarias para saldarla. Será útil utilizar el product backlog de la deuda para hacer un seguimiento del progreso y evitar acumular deuda de más de 90 días (o fijar un plazo límite).

• Integrar la lista de deudas dentro del esquema Scrum: de este modo será posible estimar el esfuerzo en saldar cada deuda y un cronograma tentativo de ejecución para su posterior seguimiento.

Establecimiento de prioridades

Una vez sea posible identificar la deuda, será oportuno establecer prioridades a fin de mitigarla.

Las prioridades siempre deben establecerse en función de variables que permitan decidir las urgencias y deberían estar en un todo alineadas con la estrategia del negocio, la misión y los valores de la organización.

Comunicación con otros líderes de la organización

Dado que las consecuencias de generar deuda tecnológica influyen en la gestión de distintas áreas funcionales de la organización, es importante poder tomar decisiones que hayan logrado consenso entre las partes involucradas.

Para ello es fundamental establecer adecuados canales de comunicación entre los responsables de área y los equipos de trabajo.

Implementación de soluciones

Como se ha mencionado, existe deuda con y sin intención, ambas deben ser saldadas en algún momento. Al pensar en una solución, es posible asegurarse de que las actualizaciones de software sean lanzados a tiempo y con poca deuda acumulada.

A modo de ejemplos:

• Una deuda técnica intencionada para cumplir plazos, originada en la elección de un marco, rápido de construir, pero con problemas reconocidos de rendimiento y limitada funcionalidad, que obliga al equipo a rehacer características con posterioridad al lanzamiento, puede ser solucionada a través del uso de aplicaciones adicionales que otorguen al software las funcionalidades requeridas.

• El lanzamiento de una nueva función del software con un plazo ajustado puede generar deuda técnica no intencionada, en virtud de no contar con desarrolladores senior para revisar cada parte del código y haber delegado la tarea a equipos de desarrolladores júnior inexpertos. La empresa contrata un apoyo temporal adicional de profesionales sénior para que revisen el código y comprueben su correcto funcionamiento. En muchos casos, aunque sean detectados la mayoría de los problemas, la falta de comunicación entre el personal full time y los free-lance propicia que algunos errores queden sin resolver, por cuanto será necesario, con posterioridad al lanzamiento, depurar estos problemas.

Los sistemas envejecen a pesar de nuestros esfuerzos en realizar mantenimiento continuo. Se vuelven obsoletos lentamente, especialmente su arquitectura requieren, por ejemplo, cambiar algún componente arquitectónico, o actualizar un framework a su última versión.

Herramientas para gestionarla

Automatización de procesos

Se ha expresado que una de las fuentes de generación de deuda tecnológica es el error de código por negligencia o intencionado para acortar tiempos de ejecución y entrega. La automatización de procesos puede ser un camino para saldar deuda.

Actualmente se está dando un fenómeno singular dado que los avances en el desarrollo de la inteligencia artificial generativa están colaborando en la escritura de código. Vemos como van apareciendo nuevas aplicaciones que permiten construir una interfaz de lenguaje capaz de interpretar comandos simples en lenguaje natural y ejecutarlos en nombre del usuario.

Estas aplicaciones se desarrollan a una velocidad inusitada, al principio tendrán errores, sin embargo en el corto y mediano plazo serán de gran ayuda para los desarrolladores y se constituirán en poderosas herramientas para evitar y mitigar la deuda tecnológica.

Desarrollo de políticas y procedimientos claros

Cada empresa define una Misión que desea cumplir, es decir los lineamientos generales que definen su propósito. Por otro lado, la estrategia del negocio es un análisis que se realiza para definir de qué modo mantener y elevar su participación en el mercado en un todo de acuerdo a su Misión.

Evalúa tanto aspectos de la corporación como de las empresas que conforman la competencia. Es la forma en que la empresa espera tener éxito y de ella depende el futuro de la misma. Esa estrategia luego se apoya en la definición de políticas cuyo cumplimiento brindará la guía del accionar de cada área de la empresa. Con todo ello, es posible identificar los procedimientos que se utilizarán y realizar planes de acción.

Muchas veces los principales procesos del negocio y/o sus procedimientos carecen de claridad y generan problemas a futuro, entre ellos, la generación de deuda tecnológica.

También es cierto que las organizaciones modernas cada vez se apoyan más en la gestión de los equipos de trabajo autosugestionados que en el cumplimiento de procedimientos rígidos. Los procesos y procedimientos deben permitir la ejecución de métodos ágiles de planificación y ejecución del trabajo.

Implementación de herramientas de monitoreo y análisis

Los equipos de ingenieros utilizan diversas herramientas para gestionar sus proyectos técnicos. No hay mucha diferencia entre las nuevas empresas, las medianas empresas y las empresas en cuanto a las herramientas que utilizan para gestionar la deuda técnica.

La mayoría de los equipos utilizan Jira u otras herramientas de gestión de proyectos, así como herramientas de calidad del código.

El 36% de todos los equipos utilizan más de una herramienta para gestionar sus proyectos técnicos, por ejemplo, herramientas de gestión de proyectos junto con herramientas de calidad del código, análisis Git o una hoja de cálculo.

Capacitación del personal

La falta de conocimientos, habilidades y aptitudes, que conducen a la deuda tecnológica, sea de código o de arquitectura suele ser un gran reto para las organizaciones.

No es solamente producto de desconocimiento de los responsables de la arquitectura de los sistemas, sino que también se da a nivel de equipo de colaboradores y se evidencia como falta de conocimiento del contexto, procesos, procedimientos, normas, disponibilidad de tecnologías adecuadas o de sensibilización sobre algunos temas importantes, como la satisfacción del cliente, los estándares de calidad o la gravedad de generar deuda sin registrarla, entre otros.

Todo ello obliga a la compañía a acometer acciones de formación que mitiguen y prevean problemas.

A un nivel más elevado también la falta de conocimientos puede ser un factor importante. Muchas empresas carecen de un responsable en gerencia (C-Level) dotado de conocimientos, experiencia y poder de decisión para establecer una hoja de ruta de actualización permanente en la tecnología de la empresa.

Conclusiones

El desarrollador, impelido por urgencias puede generar código incompleto, defectuoso o como solución temporal, en forma consciente o inconsciente provocando a mediano y largo plazo, serios inconvenientes, denominados “deuda técnica”.

También hay una deuda técnica arquitectónica proveniente de una arquitectura de sistemas fallida u obsoleta que es difícil de identificar y a menudo se evita.

Según algunos estudios, más de la mitad de esta deuda tecnológica no es eliminada realmente en el futuro y obliga a constantes esfuerzos en mantenimiento que ocasionan mayores costes, perdidas de rentabilidad y a veces, de clientes.

Las causas son variadas y pasan por la falta de inversión, la priorización del presente en desmedro del futuro y la carencia de aplicaciones actualizadas o de una estrategia en materia de tecnología adecuada.

Es cierto que el mundo de los negocios moderno es muy cambiante y exige una dinámica de gestión acelerada, sin embargo, muchas veces quienes interactúan con los clientes son personas que no conocen a fondo los tiempos de producción y con tal de complacer al cliente o de cerrar el negocio prometen plazos de entrega que son imposibles de cumplir sin generar deuda.

Los riesgos de contar con un tratamiento adecuado de la deuda son económicos, de seguridad y también estratégicos cuando ponen en juego la reputación de la empresa o se expone a pérdidas de clientes vitales.

Es muy importante identificar, cuantificar y registrar la deuda a fin de lograr un seguimiento eficiente, establecer prioridades y contar con talento suficiente como para abordarla con éxito.

La automatización de procesos como la claridad en los procedimientos será de vital importancia como la capacitación de desarrolladores, mandos medios y su sensibilización en referencia a este tema.

Recuerda que si quieres profundizar en este tema y muchos otros, estás invitado a comenzar el Plan Profesional y disfrutar de los primeros 15 días gratis.