Imagen de Alice Pascual

Deuda técnica: El sector informático presenta la particularidad de que permite la implantación de productos no acabados o con errores conocidos. En ocasiones, la política de ahorro de costes en la implantación de hardware o el desarrollo de software se centra en recortar los procesos de pruebas, control de calidad o documentación, o incluso algunos parámetros básicos de optimalidad de procesos, lo que compromete la viabilidad a largo plazo del proyecto a cambio de poder entregarlo en el plazo previsto y con el presupuesto acordado. Wikipedia

La deuda técnica no es un concepto abstracto y absurdo. Es real. Sirve para ilustrar el problema que ocurre cuando el desarrollo de un sistema se hace rápidamente y a costa de comprometer el mantenimiento a mediano y largo plazo.

La metáfora de la deuda técnica es sumamente poderosa como herramienta de comunicación entre las áreas de negocio y el equipo de desarrollo. Permite explicar las decisiones técnicas a un gerente usando un lenguaje que conoce y entiende: es mejor no tener deudas, ni siquiera técnicas.

Las empresas contraen deuda técnica cuando desarrollan software rápidamente dejando de lado la calidad del código, la facilidad de mantenimiento, la escalabilidad, la documentación. Pero como ocurre con el crédito para comprar una casa, desarrollar un software en esas condiciones tiene una coste que tocará asumir más adelante. Más pronto que tarde será mucho más complicado y costoso introducir mejoras y hacer correcciones en el sistema. Y si la deuda se hace demasiado grande puede comprometer la viabilidad misma del proyecto en el futuro.

Uno de los problemas de la deuda técnica es que es invisible para los gerentes y todos los que no están directamente en contacto con el desarrollo del software. El alto coste a pagar no es evidente. Pero sí es real y aparece cuando los equipos tardan demasiado tiempo en implementar cambios que deberían ser triviales, una lista interminable de errores, necesidad de consultores externos para mejorar el rendimiento, los nuevos miembros del equipo no logran hacerse con el proyecto, etc.

¿Por qué ocurre esto? Simplemente porque así funciona el desarrollo de software. Aunque hay herramientas para evitar la deuda técnica en los proyectos, el beneficio que traen a mediano plazo no parece compensar las necesidades y urgencias de corto plazo del proyecto (o la gerencia). Sin embargo, en algunos casos, la deuda técnica es más bien una cuestión táctica: la mayoría de las startups tecnológicas incurre en deuda técnica para crecer y sacar adelante los productos. Esto es legítimo para desarrollar pruebas de concepto y prototipos desechables.

Pero si el ciclo de vida es más largo, conviene mantener la deuda en mínimos, aunque requiera esfuerzo y disciplina. Una buena estrategia es que los proyectos lleguen a un acuerdo con la dirección para reservar una parte del tiempo a pagar la deuda (corregir errores, refactorizar el código, documentar). Aplicando esta regla sistemáticamete se logra tener algo que sea coherente, con una base firme y una arquitectura sólida.

Aunque por un lado es importante ir reduciendo la deuda en los téminos que sean relevantes al negocio (costes, riesgos, impacto en el cliente, etc.), también es sumamente necesario tener cierta trazabilidad de la deuda actual para hacerla visible y poder comunicar y argumentar sobre su impacto.

Gestionar la deuda técnica proactivamente debería ser una actividad del proceso de mejora continua del equipo. La alternativa es casi como salir de compras con la tarjeta de crédito sin controlar los gastos hasta que llega el resumen a fin de mes y hay que pagar. La sorpresa puede ser muy desagradable.