En está página web encontrará articulos sobre los fundamentos del diseño UX, las metodologías, los procesos, recomendaciones de lecturas, y eventos de la comunidad UX en Madrid.
Este website está dirigido a todos los que quieren entender lo que es el UX, orientar su carrera al UX, o mantenerse al tanto de las novedades.
¿qué es la “Tech debt” o deuda técnica y cómo gestionarla?
La Tech debt, Technical Debt o Deuda Técnica, es la suma de todas las “pequeñas” cosas de back end que a pesar de no haber sido desarrolladas de la mejor manera, permiten al producto de funcionar correctamente lado cliente.
Con está analogía, “cuando el backstage de un concierto es un caos mientras que todo luce estupendo en el escenario”, quiero insistir sobre el hecho que la tech debt no es un bugg, sino un desface en el código, que ha permitido en su momento entregar una versión aceptable del producto (explico más adelante las principales causas de este desface).
En realidad la mayor parte de estos desfaces pueden ser mitigados durante la fase de estimación de los users stories y durante el montaje del sprint, ya que en ambos casos, los desarrolladores dabaten sobre la comprensión del trabajo y la mejor solución técnica posible para llevarlo a cabo.

¡Qué lo sepas!
El Technical debt es parte del desarrollo de un producto, aunque su gestión sea excelente. En efecto, la gestión de riesgo, su monitoreo y control se realiza durante toda la fase de desarrollo del producto.
¿Quién es responsable de la tech debt?

Las principales causas del tech debt:
- atajos tomados para entregar a tiempo un MVP
- trabajar en versiones obsoletas de biblioteca de código o pilas de código que ya no son compatibles con el resto del sistema.
- la construcción y el despliegue son lentos y mal hechos.
- dependencia a API de terceros que no son mantenidas o al contrario actualizadas y, de aquí en adelante, no soportada por el código del producto.
¿Cómo gestionar la tech debt?
Organizar
Para tener una mejor visibilidad de las debt stories, relaciona las que afectan una functionalidad con su epica. De tal manera podrás tener una doble lectura de la debt: la total y por feature.
Entender para solucionar: utilisa Spikes para crear stories
Para ayudar a la comprensión puedes crear spikes, que son stories, sin estimación pero con una duración de tiempo (ej. 5hrs). El spike permite al equipo de investigar sobre el tema del debt story para poder entenderla y proponer una solución adecuada. Como resultado surge la user story.
Es importante efectuar este ejercicio lo más pronto posible con el fin de evaluar las debt sories en la próxima planning session con el equipo.
Integrar la debt story dentro de los sprints y actualizar el roadmap
En pocas palabras, decidemos cada cuanto dedicaremos tiempo en resolver el tech debt, a un nivel de ejecución y a un nivel de negocio.
Reportar a los involucrados de alto nivel
Es momento de presentar el nuevo roadmap a los managers y clientes. Es importante explicar porque y cual será el impacto de la gestión del tech debt sobre el producto final (y por extensión sobre el usuario) y la productividad del equipo de desarrollo.
Las métricas
Observar la evolución de la tech debt permite mitigar su impacto en los costes, en la productividad, y de manera general en el valor de negocio.
En el diagrama siguiente, vemos que al rebasar el punto clave, el tech debt se convierte en amenaza real para la sobrevivencia del producto, que sea al nivel financiero como al nivel técnico. El producto ya no es viable:


La curva azul demuestra que invertir recursos de manera puntual a la resolución y a la prevención de tech debt permite el equipo de desarrollo de ser más eficiente y eficaz, cuando la roja indica que dejar la tech debt acumularse sin actuar impacta negativamente la productividad.