Al Inicio de un proyecto, frecuentemente nos encontramos con conversaciones como esta:

• Developer: Necesitamos tiempo para establecer la arquitectura… ¡Tenemos muchos temas por definir!
• Project Manager: No tenemos tiempo para eso. Nuestro objetivo es entregar funcionalidades.

¿Les parece conocido? ¿Les ha sucedido en sus proyectos?

A menudo, este tipo de conversaciones refleja una falta de alineación en los equipos, pues a pesar de que las partes quieren lo mismo -concluir de la mejor manera el proyecto- no lo piensan hacer de la misma manera. Y esta desalineación conlleva a un inicio descontrolado, con un muy seguro aumento de la deuda técnica.   Dichos comportamientos generarán frustración, tanto en los equipos de desarrollo y de los PM, como problemas técnicos frecuentes y desarrollo lento.

Pero ¿qué es deuda técnica?

Es el costo del trabajo adicional que hemos inyectado al proyecto causado por haber escogido soluciones fáciles y apresuradas -en arquitectura, diseño, código e incluso pruebas- en lugar de usar un mejor enfoque que tomaría algo más de tiempo.

La visibilidad de ésta no es muy buena normalmente; pues tradicionalmente en los proyectos son más evidentes sus características y defectos o bugs reportados. Pero siempre quedan ocultas las bases, es decir, la arquitectura y la deuda técnica que se tiene en dicho proyecto.

La buena administración de la deuda técnica implica revisar su costo, establecer un proceso para administrarla y hacerla ver al equipo.

Las siguientes son algunas guías y reglas de cómo documentar la deuda técnica

• Use un sistema de tickets.
• Describa el problema, no la tarea.
• Describa la implicación del problema separadamente.
• Justifique en los casos en que la deuda técnica sea adicionada a propósito.
• Proponga una solución.
• De al ticket las métricas apropiadas (severidad, complejidad, contagio)

Cuando se tenga una correcta administración de la deuda técnica, el proyecto empezará a mejorar, el desarrollo se hará más rápido y se tendrá equipos más cohesionados y felices. Recuerde que nunca va a ser cero, y que no será necesario solucionarla toda. Pero no revisarla y dejarla a un lado será lo peor que puede hacer como miembro de un equipo de desarrollo.

Lecturas recomendadas:

https://www.amazon.com/Managing-Technical-Debt-Reducing-Development/dp/013564593X

https://resources.sei.cmu.edu/asset_files/Presentation/2019_017_001_546211.pdf