Screen Shot 2020-10-08 at 11.47.30 AM.pn

Abner Ballardo Blog

La vez que propuse detener nuevos desarrollos para pagar la deuda técnica



Hace varios años, cuando lideraba algunos equipos de tecnología, propuse detener los nuevos desarrollos para pagar la deuda técnica. Debido a la cultura organizacional y mi inexperiencia, no logré los resultados que buscaba. En este artículo compartiré esa historia y mis lecciones aprendidas para que una organización cuide la deuda técnica.


"Logramos los resultados esperados en la estrategia de negocio pero con algo deuda técnica."


Comencemos con el contexto, tuvimos que aprender nuevas tecnologías en el primer producto (MVP) que construimos. Por ejemplo, por primera vez implementamos DevOps, pruebas automatizadas para web y frameworks especializados para frontend y backend. Logramos los resultados esperados en la estrategia de negocio pero con algo deuda técnica.


Al poco tiempo, comenzamos con el segundo producto (MVP) mientras seguíamos mejorando el primero. Estratégicamente decidimos construirlo en la nube y ya no sería una aplicación web sino mobile . Como consecuencia tuvimos que aprender nuevas tecnologías para DevOps, pruebas automatizadas para mobile, nuevos frameworks para frontend y backend con el objetivo de aprovechar al máximo la nube. Nuevamente logramos los resultados que esperábamos pero con deuda técnica moderada en ambos productos.


"Decidí proponer un 'freeze', detener los nuevos desarrollos para pagar la deuda técnica"


Antes de comenzar con el tercer producto (MVP), decidí proponer un "freeze", detener los nuevos desarrollos para pagar la deuda técnica. Es decir, simplificar el stack tecnológico, corregir errores, evitar duplicidades y prepararnos para construir nuevos productos. Lo propuse porque debíamos prepararnos para escalar los productos, entregar mayor valor de negocio y motivar al equipo.


Sin embargo, las áreas de negocio no lo tomaron bien porque en lugar de detenerse querían acelerar. A pesar de muchas reuniones y explicaciones, no logré convencerlos y tuvimos que seguir adelante con el tercer y cuarto producto. Los resultados de negocio fueron buenos en los todos los MVPs, pero sacrificamos la deuda técnica para cumplir con tiempos; y como toda deuda, tuvo que pagarse en los siguientes años.


Lecciones aprendidas


Entonces, ¿qué lecciones aprendidas tengo? Con los años he llegado a identificar varias y aquí compartiré algunas de ellas con la esperanza que pueda ayudarlos a crear mejores productos digitales.

  • Desde el inicio deben capacitar a los roles de negocio sobre deuda técnica. Si no comprenden por qué incurrimos en deuda y por qué es inevitable tenerla, entonces será imposible la comunicación.

  • Deben comunicar claramente cada vez que incurren en deuda técnica, no esperen meses para evidenciarlo.

  • Agreguen tareas para reducir la deuda técnica en el backlog, de ser necesario mantenga una épica exclusiva para ello.

  • En todos los sprints deben asignar un porcentaje pequeño de tareas para reducir deuda técnica; o cada tres meses dediquen uno o medio sprint exclusivamente para reducirlo.

  • Acompañen las métricas de negocio con el estado de la deuda técnica en los productos digitales.


277 vistas2 comentarios

Entradas Recientes

Ver todo