Deuda UX: su origen en la Deuda Técnica

La deuda UX existe y aunque es un registro operativo que puede ser difícil sobrellevar, nos sirve para no perder la pista a todo aquello que no se desarrolló y así fue lanzado en productivo.

Quizás para ti te sonará raro escuchar este concepto, yo lo hice en febrero y tuve bastante curiosidad respecto al tema. Ya que de alguna manera durante mi profesión faltaba un repositorio donde pudiéramos tener seguimiento a todo lo que se diseñó en la arquitectura de información, accesibilidad, usabilidad, diseño UID e Interacción, que no se ha plasmado en el producto final.

Comenzaremos por entender que es la Deuda Técnica, para posteriormente entender la Deuda UX.

Sin más comencemos con esta explicación de este tema y conocer cómo debemos resolver estos problemas. Con esta serie de publicaciones, en la cual culminará con una herramienta para dar seguimiento y resolver la deuda técnica y UX.

La Deuda Técnica

Antes de poder hablar sobre la Deuda UX, entendamos que este concepto es heredado por el ecosistema de desarrollo de software, por Ward Cunningham; siendo conocido por ser el coautor del Manifesto for Agile Software Development donde explica que en el desarrollo de productos por modelo incremental, tiene un problema al momento de consolidar poco a poco dentro de un producto, que funciona bien y para el cliente está perfecto.

Sin embargo, al enviar a producción, en varias iteraciones y poco control, puede llegar a ser un producto inflexible. Por lo tanto, al momento de enviarlo, puede quedar pendiente código y esto se llama deuda.

La deuda permite que el desarrollo se mueva rápido, siempre y cuando se pague la deuda, en caso de no ser así, El peligro ocurre cuando la deuda no se paga.

Cada minuto gastado en un código no del todo correcto cuenta como interés en esa deuda. Organizaciones de ingeniería completas pueden quedar paradas bajo la carga de la deuda de una implementación no consolidada.

Pero entendiéndolo un poco mejor en nuestro contexto actual, “un concepto en el desarrollo software que indica la cantidad de trabajo de desarrollo adicional que se va acumulando cuando se implementa código que es fácil de desarrollar a corto plazo en lugar de aplicar la mejor solución global”.

Sobre todo en aquellas soluciones temporales y con poca mantenibilidad que comúnmente en la jerga se conoce como “parches”.

El cuadrante de la Deuda Técnica

Philippe Krunchten nos habla de esta deuda técnica en un cuadrante donde podemos ubicar en que áreas se pueden identificar, Martin Fowler son pronuncian ante este concepto:

Descripción del valor visible:

• La zona verde: los elementos más obvios son las nuevas características (servicios, funcionalidades, capacidades) que se agregarán al sistema; a veces mejoras visibles en algún atributo de calidad (capacidad, tiempo de respuesta, interoperabilidad, funciones de interacción).
• La zona roja: si el producto de software ya se lanzó, entonces es probable que tenga defectos, perjudicando a algunos clientes directa o indirectamente de manera negativa.

Descripción del valor invisible:

• Zona azul: elementos arquitectónicos, infraestructura, frameworks, herramientas de implementación, etc. Su costo a menudo es muy desigual: son difíciles de dividir en pequeños incrementos. Sabemos que agregan valor, a largo plazo, al aumentar la productividad futura y a menudo, siendo clave de calidad. Pero este valor es difícil de definir.
• Zona amarilla: hay elementos que tienen tanto un valor negativo, y son invisibles: grandes bultos de deuda técnica. Son el resultado de decisiones arquitectónicas anteriores que fueron sabias y óptimas en ese momento, pero que en el contexto actual son claramente funcionales, obsoletas y perjudican el proyecto de varias maneras: generalmente por una reducción de la productividad o un impacto en la evolución del sistema. El equipo de desarrollo conoce las cosas negras, pero rara vez se expresa visiblemente a nivel de los tomadores de decisiones clave que deciden la hoja de ruta del lanzamiento futuro. Los atajos u omisiones para desarrollar la zona amarilla aumentan la cantidad de la zona negra, evitando aún más el progreso.

Para conocer las causas de la deuda técnica y si eres un desarrollador con enfoque UX, te comparto el artículo de Adrián Alonso Vega. En la tercera entrega veremos las causas y como resolverlo.

En conclusión, al entender este concepto, recordemos que un equipo de producto que tiene presente el enfoque de UX sobre todo el equipo de desarrollo y diseño, tienen cosas en común.

Existe una responsabilidad en estos equipos principalmente en evitarlo, ya que son los makers que materializan un producto digital.

Continuaremos con este tema aclarado, podremos verlo en la Deuda UX: cúmulo de deudas de experiencias, interacción y diseño.

Recuerda que cada día aprendamos y compartamos conocimiento, con el fin de:

Ser la mejor versión de uno mismo