¿qué es la “Tech debt” o deuda técnica y cómo gestionarla?

tech debt, un problema integralmente técnico que únicamente los equipos de desarrollo dominan

La Tech debtTechnical 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.

La tech debt es mejorable del código que no tiene impacta la experiencia directa del usuario en su momento
Representación de la tech debt en la estructura de un código.

¡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?

El tech debt no existe porque los programadores son incompetentes, ni porque la gestión del producto es pésima. La explicación es mucho más orgánica: el desarrollo de producto nuevo o inovador obliga el equipo a aprender sobre la marcha mientras que tiene el compromiso de entregar MVPs en fechas precisas.
Esta curva de aprendizaje combinada con la exigencia de entregas a corto plazo genera un circulo vicioso que obliga el equipo a realizar un trabajo apróximativo. Con el tiempo, estás apróximaciones se acumulan lo que complica aún más la posibilidad de corregirlas, aún si ahora, sabe como debería haberlo hecho.
Este esquema resume el fenómeno:
El product manager puede decidir de actuar o no frente al tech debt
Los 4 comportamientos frente al 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?

Como product manager es importante saber dedicar tiempo y priorizar los causantes de la deuda, para ir integrandolas en los sprints, o dedicar sprints enteros a su resolución. Hay que resolver el problema antes de que ponga en peligro el ciclo de vida del producto.
Aunque no aporta valor al usuario final de manera directa, aporta valor al producto, haciendolo más robusto, estable y con el tiempo quizá más competitivo y apto a ser inovador.

Organizar

Si trabajas con SCRUM, crea una epica dedicada al tech debt.
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

Es necesario que el equipo entienda con claridad cada debt story para poder convertirla en user story, en caso contrario, no podrás añadirla a un sprint.

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:

uno de los gráficos para gestionar la deuda técnica
Muestra de la relación entre la tech debt y el valor de negocio del producto.
curvas de gestión buena y mala de la deuda tecnica
El impacto de una gestión buena y mala de la tech debt sobre la productividad.

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.

Saber más sobre el tema

Spread the love

Spotify da más control al usuario con una nueva funcionalidad mejorable

Vista del UI de un artista bloqueado

La funcionalidad de blacklisting es disponible desde hace 2 meses, con esa, Spotify deja al usuario el superpoder de realmente escuchar la música que quiere al dejarle la posibilidad de bloquear la reproducción de cierta música, es buena idea pero el UX y UI son mejorables

En un mundo sacudido por el hashtag #metoo, sospecho los equipos de Spotify de haber sido inspirado por el movimiento. Al nivel de negocio, este caso de estudio destaca claramente:

  1. la detección de un problema,
  2. la acción tomada como respuesta a este problema,
  3. la formulación de una user story entendible para todos los involucrados,
  4. la implementación del user story por el equipo de desarrolladores.

Al escribir este artículo detecte oportunidades de mejoras del UI, así como otras acciones posibles para completar la respuesta desarrollada por Spotify. Encontrarás mi propuesta UI en la descripción de la feature, aquí mismo, y mis propuestas de acciones, con sus users stories, user flow, user testing y prototipo interactivo, en mi portafolio.

¿Cómo funciona la feature?

La funcionalidad para bloquear un artista es disponible desde de la vista del artista, dentro del menú, seleccionando la opción “No escuchar a este artista”.

Aquí les enseño el flujo

  1. El acceso a la opción “no escuchar a este artista” se hace desde la landing del artista.
  2. Spotify me confirma la acción al disparar un popup que me indica lo que acaba de suceder, y observamos que el botón seguir ya no está disponible al lado del menú.

He estado feliz de aplicar la restricción a R Kelly, artista que soy susceptible de escuchar contra mi voluntad ya que hace parte de playlist auto generadas por Spotify (el Autoplay), las playlists de RnB, y otros…

¿Cómo se aplica la restricción?

A pesar de la restricción, el artista y todo su catálogo musical sigue visible tanto en vistas de contenido dedicado como en resultados de busqueda. ¡Una lastima!, me hubiera gustado no ser obligada de ver su nombre o su retrato en el artwork de sus discos… Pero no represento todos los usuarios y seguramente eso tiene sentido (¿quizás porque aún no existe la posibilidad de gestionar desde una misma vista todo el contenido bloqueado?).

La música del artista bloqueado es accesible en toda la app (salvo en las playlists “Radio” a donde desaparecen del listado aunque la radio lleva el nombre del artista) pero su selección con click o tap no dispara la lectura. Claro, con la configuración activada, buscamos no escuchar esa música.

El problema de eso es que no existe un elemento gráfico de diferenciación para identificar el contenido bloqueado del resto. Es seguro que este olvido se vuelve una fuente de frustración para unos usuarios quienes no se acordaran haber aplicado la restricción, fustración formulada a través de la pregunta ¿Por qué no se reproduce esa música si es presente en la playlist?

Este comportamiento es aplicado a todas las canciones de la discografía del artista, significa que no aplica a los featurings que hace en los discos de otros artistas.
Eso lo descubre el usuario con la experiencia ya que nunca le es explicado (es una de las propuestas que trabaje en el caso de estudio próximamente públicado en mi portafolio).

Propongo aquí una solución UI para distinguir el contenido bloqueado

Me acuerdo haber visto a varias ocasiones un disable surgerido por la aplicación de una opacidad de 40% a la música no disponible por cuestion de derechos de autor. Aplicando este subterfugio, seguiríamos un pattern ya utilizado por Spotify para indicar música no reproducible.
Necesitaríamos ahora diferenciar los dos tipos de disable. En efecto, no olvidemos nuestro objetivo: como usuario quiero ser capaz de controlar mi catálogo. Así, para el contenido bloqueado, podríamos añadir a la solución disable el icono elegido por spotify para significar la restricción. Colocamos el icono a la derecha de cada título bloqueado :

Vista UI de una playlist conteniendo una música de un artista bloqueado
Mejora UI con diferenciación visual del contenido bloqueado en una playlist.

Y en las vistas del artista y de un disco, podemos utilizar un banner arriba de las vistas. Ese daría más información sobre el estatus del contenido, gracias al texto informativo: “has bloqueado la música de este artista” y un botón para reabilitar la lectura de la música del artista.

¿Cómo reestablecer la configuración inicial?

Si por inadevertencia mi dedo dio un tap en “no escuchar a este artista” en vez de “compartir”, cuando mi intención era de publicar una música de Sampha en mi Insta.
Ningún problema, tengo la posibilidad de reestablecer el estado anterior al seleccionar “Retirar”. Al hacerlo, el contenido es de nuevo accesible así como la opción “No escuchar a este artista”.

Aquí veo una oportunidad de mejorar la experiencia de usuario, al elegir una sintaxis más precisa.

En efecto Retirar da a entender que vamos a eliminar el artista de la biblioteca, sin embargo es exactamente lo opuesto que buscamos hacer. Sugiero “Quitar la restricción y escuchar”.

Caso de uso alternativo:
¿Qué pasa si el usuario aplica la restricción mientras escucha un título del artista que está bloqueando?

Mientras estaba realizando el análisis de la funcionalidad de restricción, llegue a escuchar un título de XXXtentation sin querer. Este título era parte del autoplay de Spotify, que se activa después de haber escuchado la lista completa de música la más popular de un artista, en este caso, estaba escuchando a Joey Bada$$:

Ocurre que Joey hizo un featuring sobre el disco de XXX que aparece primero en el autoplay.

Aquí puedes ver el flujo de usuario para eliminar XXX:

Mientras escuchaba infinify (888) bloquee XXX, es cuando, automáticamente, el lector de música paso al título siguiente, omitiendo él que estaba tocando milisecundo antes.
En efecto observamos ahora que el player toca 1Train de A$AP Rocky (5). En (6) vemos que infinify (888) sigue visible aunque no escuchable.

Conclusión

Con la user story siguiente “Como usuario quiero ser capaz de bloquear un artista para no escuchar la música de sus discos“, Spotify solucionar el valor añadido siguiente: un usuario (premium y básico), puede refinar su catálogo de música con más control.

Con mi propuesta UI resolví la nueva user story: “Como usuario quiero ser capaz de distinguir el contenido bloqueado para diferenciarlo del contenido normal“.

Al realizar este analísis se me ocurrieron otras respuestas para llegar a optimizar el objetivo de refinamiento, las formulo en las user stories siguientes:

  • Como usuario quiero acceder a la lista de contenido bloqueado para gestionarlo.
  • Como usuario quiero ser capaz de bloquear todo el contenido en el cual canta el artista para no tener que escuchar su voz (sus featurings).
  • Como usuario quiero ser capaz de bloquear una canción para no tener que escucharla nunca.

Enseño el trabajo realizado a partir de esas user stories en mi portafolio.

Spread the love

Un buen service design beneficia a todos: con un envío optimizado y responsable de tus newsletters

Cuando un buen service design, representa un beneficio para la empresa, sus clientes y el medio ambiante. La buena gestión de su base de datos permite eso.

El caso de la newsletter

Al mantener actualizada tu lista de clientes inscritos a tu newsletter y al vigilar los que no la habren nunca o con un índice menos de 30%, tiene un impacto real en factores internos y externos a tu empresa.

Hoy por ejemplo recibí una de la empresa Mademoiselle Bio, que a mi gran sorpresa, no teme eliminar usuarios de su base de datos, y lo hace con mucha magía. ¿Por qué digo eso? Pues soy cliente fiel, aunque poco frecuente, y su correo me parecío a la vez útil para refinar mi flujo de emails y para tener una mejor imágen de la empresa.

¡Vaya, ellos se preoccupan por mi y al hacerlo me acuerdan que existen! Además, como soy del medio digital, me cae el veinte que ellos enviarán menos newsletter, lo que tendrá en impacto en su huella digital.
¡Me encanta todo!

Un ejemplo de email para gestionar eficazmente el envío de newsletter.

Muestra de un email para mantener una lista de receptor actualizada
Email de Mademoiselle Bio para gestionar un envío optimizado y responsable de sus newsletters.

Primero lo primero: da la oportunidad al receptor de cancelar su subscripción desde el principio. Una practica ahora común y extremadamente importante para la imagen de la empresa: no obliga el internauta en nada.

  1. Qué: desde hace 6 meses no ha comprado ni ha abierto ninguna newsletter.
  2. En consecuencia: no le enviaremos más emails, a no ser que decida de lo contrario al seleccionar el botón siguiente (3).
  3. El botón opt in
  4. Contacto cliente: por email, teléfono (con horarios) o redes sociales
  5. Invitación a la compra:  Busca tiendas fisicas cerca de ti, y conoce nuestro catálogo. Disfruta de unas facilidades (descuento, entrega gratuita, regalos) por si te apetece comprar en línea.
Spread the love

La claridad del diseño

Mantener la claridad del diseño es pintar la información necesaria de manera optina. Tu objetivo es asegurar que el usuario sepa que hacer con la información disponible para lograr sus fines.

shazam un buen exemplo de claridad de diseño

Para optimizar la claridad del diseño necesitas:

  • pintar las opciones que son estrictamente necesarias. Así limitarás las indecisiones, confusiones y frustraciones frente a las cuales el usuario podría enfrentarse.
  • implementar los patrones existantes que son aplicables a la funcionalidad o vista. Harás todo lo posible para maximizar la aprendibilidad.
  • implementar un UI que apoya las decisiones previas: al ordenar el contenido lógicamente y al aplicar una jerarquia enfatizando el elemento el más esencial.
  • Siempre guardar en mente el perfil tipico de usuario que utiliza la app (es familiarizado al uso de las tecnologías, en que contexto utiliza la app,…?)
Spread the love