top of page
Orange.png

Blog

Pagar la deuda técnica: Lecciones aprendidas de una propuesta fallida



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é obtener los resultados que buscaba. En este artículo, compartiré esa historia y las lecciones aprendidas para que una organización pueda cuidar su deuda técnica.


Logramos los resultados esperados en la estrategia de negocio, también acumulamos algo de deuda técnica


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


Poco después, comenzamos a trabajar en el segundo producto (MVP), al mismo tiempo que seguíamos mejorando el primero. Estratégicamente, decidimos construirlo en la nube y que no sería una aplicación web, sino móvil. Como consecuencia, tuvimos que aprender nuevas tecnologías para DevOps, pruebas automatizadas para móviles y 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 una deuda técnica moderada en ambos productos.


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

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


Sin embargo, las áreas de negocio no tomaron bien la propuesta, ya que 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 todos los MVPs, pero sacrificamos la deuda técnica para cumplir con los plazos; y como toda deuda, tuvo que pagarse en los años siguientes.


Lecciones aprendidas


Entonces, ¿qué lecciones he aprendido? Con los años, he identificado varias, y aquí compartiré algunas de ellas con la esperanza de que puedan ayudarte a crear mejores productos digitales.

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

  • Debes comunicar claramente cada vez que incurran en deuda técnica, sin esperar meses para evidenciarla.

  • Agrega tareas para reducir la deuda técnica en el backlog; si es necesario, manten una épica exclusiva para ello.

  • En todos los sprints, asigna un porcentaje pequeño de tareas para reducir la deuda técnica. Si es necesario, dedica un sprint completo o medio sprint cada tres meses para reducirla.

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


378 visualizaciones2 comentarios

Entradas relacionadas

Ver todo

2 Comments


Hola Abner, buen dia, interesante el articulo, tuvieras algunas propuestas cualitativas o las formulas de ¿como considerar la deuda tecnica al momento de la evaluacion de riesgo cuanto nos podria impactar en el ciclo de vida del producto?, gracias

Like
Abner Ballardo
Abner Ballardo
Oct 14, 2021
Replying to

Hola Jean, los números varían dependiendo de las personas y tecnología. Sin embargo, te invito a que revises el reporte del estado de la deuda técnica del 2021 porque tiene datos muy interesantes. Por ejemplo, los developers dedican un día aprox. a la semana lideando con la deuda técnica, con eso podrías estimar el impacto en productividad. https://www.stepsize.com/report

Like
bottom of page