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.