Reducir la deuda técnica con la nube

Por Nurani Parasuraman y Siraj Gadne

Este blog aborda las mejores prácticas para reducir la deuda técnica por medio del aprovechamiento y operación responsable de servicios en la nube.La deuda técnica es una metáfora acuñada por Ward Cunningham para lidiar con el costo de tomar decisiones que implican concesos (trade-offs) en el desarrollo de software para cumplir con las necesidades de negocio a corto plazo. En el caso de la deuda financiera, usted toma un préstamo para adquirir algo que desea ahora con la promesa de pagar después y en caso de no pagar de vuelta, conlleva consecuencias. De la misma forma, si las deficiencias en el software no son atendidas de forma apropiada (“amortizadas”), mantenerlo, e incluso añadir nuevas funcionalidades, se convierte algo extremadamente complicado (“intereses”). Esto aplica universalmente para cualquier tipo de compañía, sin importar si están operando on-premises o en la nube. De esta forma, así como la deuda financiera debe ser manejada responsablemente, hay una necesidad de ser diligente en la forma de manejar la deuda técnica. De hecho, una ventaja clave que la nube ofrece, es la capacidad de manejar la deuda técnica efectivamente.

¿Cuáles son las causas de la deuda técnica?

Hay múltiples factores que contribuyen a la deuda técnica. Por mencionar lo obvio, las malas prácticas y decisiones en tecnología causan la generación de deuda. Algunos ejemplos son: la escritura deficiente de software, las revisiones de código y realización de pruebas de forma inadecuada, la ausencia de documentación, el diseño inflexible del software y las elecciones incorrectas de tecnología, entre otras. Sin embargo, la deuda técnica también se da como resultado de insuficiencia de capacidades y habilidades en TI, así como por la rotación de personal en la organización.

La forma en la que los equipos de negocio y tecnología interpretan los requerimientos de producto de forma diferente, resulta en la generación de deuda técnica. Los requerimientos de negocio se enfocan en la funcionalidad desde la perspectiva del usuario. Mientras que los requerimientos desde la perspectiva técnica se enfocan en atributos no funcionales como resiliencia, rendimiento, mantenibilidad y seguridad. Sin embargo, con frecuencia, estos no son priorizados para su ejecución respecto a los requerimientos de negocio. Por esta razón, los equipos de TI toman atajos para incorporar los requerimientos no funcionales, lo que resulta muchas veces en la generación de más deuda técnica. Por otro lado, los cambios en las preferencias del cliente, el entorno, la competencia, la geopolítica, la economía y la legislación se convierten en retos para predecir los modelos de negocio hacia el futuro. Todo esto hace que crear “software a prueba del futuro” sea todo un reto. La tecnología misma evoluciona de forma rápida, haciendo que las decisiones en este campo que son tomadas hoy, mañana sean ya obsoletas. Además, con la presencia constante de hackers buscando formas de explotar las vulnerabilidades en el software, las compañías se encuentran en un estado de deuda permanente ante la tecnología.

Mejores prácticas para manejar deuda técnica

La deuda técnica es inevitable. ¿Entonces, cómo se puede lidiar con ella? En caso de no ser tratada, esta hará que sea más difícil hacer cambios en el software de cara al futuro y por consiguiente se aumentará la velocidad de entrega de nuevos requerimientos, así como el costo de desarrollo de estos. Por otro lado, si las compañías dedican mucho tiempo a tratar de alcanzar la perfección, la velocidad entrega de nuevos requerimientos también será impactada. La deuda técnica no es mala necesariamente, mientras esta esté consensuada, prudente y exista un camino de bien definido para mejorar las deficiencias causadas por esta. Este tratamiento representa un gana y gana tanto para las áreas de negocio como de tecnología. Aquí se presentan un conjunto de buenas prácticas para manejar la deuda técnica por medio del apalancamiento de servicios en la nube.

Reconocer la deuda técnica “real” y hacerla visible

La deuda técnica puede ser utilizada incorrectamente para justificar nuevas inversiones. Esta es utilizada típicamente para justificar mejoras en los sistemas internos de TI en vez de la adición nuevas funcionalidad orientadas al usuario. Sin embargo, las inversiones en reparación de deuda técnica deben estar ligadas a los resultados de negocio. Esta debe ser cuantificada de acuerdo con su impacto en el negocio, por ejemplo, mala experiencia de usuario, disminución de las ganancias, ralentización en las entregas de producto, aumento en los tiempos para resolución de issues, y decrecimiento en la productividad de los equipos. Las actividades periódicas de mantenimiento como: copias de seguridad, mejoras de terceros, parches de seguridad, no son consideradas parte de la deuda técnica. Estas son simplemente buenas prácticas operacionales.

La deuda técnica no solo es un problema de tecnología

La decisión de “incurrir” y “pagar” deuda técnica debería considerar tanto a los equipos de negocio y tecnología. Se debe partir desde las necesidades del cliente para priorizar aquellas funcionalidades que más impacto tienen y que ayudan a mitigar la duda técnica. Se debe enunciar claramente cuando una pieza de software está “completa y lista” y no sobre prometer entregable a los diferentes stakeholders, con el fin de que los equipos de negocio puedan reducir la descalificación de funcionalidades. De igual forma, los equipos de IT deben ser abiertos y realistas en cuanto al tiempo y los recursos necesarios para la construcción de nuevas funcionalidades, así como para el “pago” de deuda.

Apalancamiento en servicios de la nube

A pesar de que la técnica de lift and shift es una gran opción para mover las cargas de trabajo rápidamente a la nube, esta no se hace cargo de la reducción de deuda técnica. En este caso la deuda ya establecida en on-premises será transportada directamente a la nube. Para maximizar los beneficios de la adopción de la nube y manejar la deuda, las empresas deben repensar y adaptar sus procesos originales de acuerdo con las características ofrecidas por la nube. Desplegar una aplicación de software requiere lo que AWS llama “undifferentiated heavy lifting” lo que implica el manejo de servidores, banda ancha, contratos, capacidad, operaciones y la coordinación de grandes equipos. Si alguna de estas áreas es manejada de forma indebida, se puede tener consecuencias negativas y por consiguiente generar deuda técnica. Las plataformas en la nube proveen bloques listos para utilizar y mantener software. Esto les permite a los equipos enfocarse en el negocio y la innovación, en vez de las operaciones de rutina de TI. Proveer infraestructura, desplegar código, realizar pruebas, detectar vulnerabilidades, monitorear y alertar el estado de los sistemas, así como, recuperación de desastres son operaciones que pueden ser completamente automatizadas en la nube. Las características de elasticidad de la nube, permiten liberar o provisionar recursos en respuesta al nivel de demanda. Muchos servicios, como serverless y las bases de datos adaptadas a necesidades específicas, están disponibles como servicios completamente manejados y con capacidades previamente incorporadas para mejorar disponibilidad y resiliencia. Esto significa que los equipos ya no tienen que disponer de recursos a estas tareas que antes hacían parte de la rutina.

Adoptación de prácticas ágiles y enfoque nativo de la nube

La computación en la nube se adapta bien a la práctica de desarrollo ágil, esta contribuye con los principios de experimentación, flexibilidad, entrega incremental de funcionalidades. Las tecnologías nativas de la nube soportan los cambios rápidos y frecuentes sobre las aplicaciones sin tener afectaciones sobre la entrega de servicios. La práctica de desarrollo ágil prioriza la velocidad sobre la perfección y mejora la colaboración entre negocio y tecnología. Ambas partes, nuevas funcionalidades y deuda técnica son visibles en un único tablero de “backlog” de producto. De esta forma los equipos pueden priorizar y entregar valor en cada uno de los cortos sprints de forma incremental.

Prácticas de desarrollo maduras

Las revisiones de código, los estándares de diseño y desarrollo, la documentación apropiada, la automatización de pruebas de código son técnicas para la reducción de deuda técnica. Más allá de las prácticas sobre el código, las aplicaciones modernas usan tecnologías con bajos niveles de acoplamiento y se enfocan en arquitecturas “sin servidor” e intercomunicadas por eventos. Estas usan herramientas automatizadas para el aprovisionamiento de infraestructura, el manejo operacional y control de seguridad, con el fin de mejorar la dependencia y consistencia a la hora de hacer despliegues. Los componentes reutilizables y probados con el tiempo son una gran forma de acelerar la entrega de funcionalidades y mitigar la deuda técnica.

Entrenamiento y desarrollo de habilidades

Adoptar nuevas tecnologías requiere dotar a los empleados con las habilidades correctas para que puedan tomar decisiones informadas y poner la tecnología en practica de forma efectiva. En el caso de la tecnología basada en la nube: El estudio reciente AWS Global Digital Skills study establece que el 87% de los empleadores reportan que las inversiones en entrenamiento de habilidades digitales para sus empleados han permitido que las organizaciones alcancen niveles de transformación digital más rápido. Desde la perspectiva de los empleados, más del 80% han reportado mejoras en la eficiencia a la hora de realizar su trabajo, así como un aumento en los niveles de satisfacción en este. Estos factores ayudan a las compañías alcanzar más rápido resultados en métricas como el time to value, así como a la reducción de deuda técnica

Medición de la deuda técnica

A lo largo del tiempo se han realizado múltiples propuestas acerca de como medir la deuda técnica, así como: la complejidad ciclomática, la cobertura de pruebas en el código, el rankeo por método SQALE, violación de reglas de código e incluso el simple conteo de los bugs en el software. A pesar de que estas metodologías proveen alunas medidas cuantitativas sobre la calidad del software, estas no miden otras dimensiones como la frecuencia de los cambios realizados sobre este. El código que obtiene puntajes bajos en calidad y que es cambiado con baja frecuencia, debería ser priorizado para su resolución. No siempre es obvio medir la deuda técnica, pues es necesario hacer un examen minucioso para su estimación. Y2K es un clásico ejemplo de cuando en los 60s, en la industria de software, se definió la convención para que los “años” fueran almacenados con dos dígitos (“75” en vez de “1975”). Con el cambio de siglo, esto se convirtió en un gran problema de deuda para todas las industrias. La deuda técnica es relevante cuando esta es expresada en términos de negocio como mala experiencia del cliente, decrecimiento de las ganancias, ciclos de desarrollo más largos y productividad de los empleados. Esto implica la toma de decisiones para priorizar la realización de inversiones.

Comentarios finales

La deuda técnica es un problema real al que se enfrentan las organizaciones y que no puede ser evitado. Esta surge tanto por factores controlables como no controlables. El riesgo de ignorarla es alto y puede resultar deterioro de métricas como el tiempo para mercado o las ganancias. Incluso puede causar impacto negativo en la moral dentro de la organización. La deuda técnica debe ser atendida en conjunto por los equipos de negocio y la tecnología. Debe ser visualizada, priorizada y por medio de la tecnología de la nube puede ser convertida en riqueza tecnológica efectivamente.

Lecturas adicionales

Agile Alliance, D. W. (n.d.). Project Management and Technical Debt. Retrieved from https://www.agilealliance.org/project-management-and-technical-debt/
Fowler, M. (2009, October 14). TechnicalDebtQuadrant. Retrieved from https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Fowler, M. (2019, May 21). TechnicalDebt. Retrieved from https://martinfowler.com/bliki/TechnicalDebt.html
Schwartz, M. (2020, December 16). The CIO-CFO Conversation: Technical Debt—An Apt Term? Retrieved from https://aws.amazon.com/blogs/enterprise-strategy/the-cio-cfo-conversation-technical-debt-an-apt-term/
Whelan, J.-L. L. (n.d.). Introduction to the Technical Debt Concept. Retrieved from https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf

Este artículo fue traducido del Blog de AWS en Inglés.

Blog de Amazon Web Services (AWS)