¿Se pueden usar historias de usuario para describir elementos de calidad para el producto?

Historia de usuario de búsqueda de libros

Recientemente tuvimos un interesantísimo debate sobre una pretendida historia de usuario, sobre si lo es o si no lo es:

Como lector de libros

Quiero que la búsqueda libros sea más rápida

Para poder evitar tener que esperar tanto

A priori tiene toda la pinta de una historia de usuario, ¿verdad? La primera pregunta que nos debemos de hacer es si esta historia es algo que realmente quiera un lector.

¿Un lector de verdad quiere que mejoremos los tiempos de respuesta de nuestra tienda on-line? o, ¿más bien quiere encontrar el libro que busca y poder comprarlo? No me imagino un lector pidiendo a Amazon que acelere su proceso de búsqueda. Si encuentra el libro en nuestra tienda on-line, aunque excesivamente lenta, pensará que somos unos chapuzas, pero como ha logrado el libro que quería volverá en el futuro... eso si mientras tanto no ha encontrado una tienda on-linea más rápida que tenga los libros de su interés. Si no ha encontrado el libro probablemente no vuelva a nuestra tienda on-linea nunca más.

Si consideramos la historia incial del post como una historia de usuario, lo que estamos haciendo es trasladar nuestra falta de calidad al lector... y eso desde luego no nos va a hacer competitivos ni a crear buenas experiencias de usuario.

Por tanto podemos concluir que nuestro ejemplo no es una historia de usuario. Si puede ser una historia técnica, algo que hemos de hacer para mejorar la experiencia del usuario. Somos nosotros, no los lectores, quienes debemos de descubrir nuestras debilidades. Podemos detectar el problema en tiempos de respuesta a través pruebas de rendimiento en entornos de test o de staging, lo importante es que sea antes de liberar la funcionalidad de búsqueda a producción.

Si la problemática ya está en producción podemos analizar el comportamiento del software y la experiencia del usuario mediante herramientas como google analytics; rendimiento del segmento de usuarios, grabar sesiones y monitorizar contenidos visitados. Podemos detectarlo también en una encuesta a final de cada compra; si me imagino a un lector dando feedback de un tiempo de espera excesivo en la encuesta post-compra que hace Amazon.

Lo que ha de quedar claro es que los que tenemos interés en tener un tiempo de respuesta adecuado somos nosotros, no el lector. Por tanto si hemos detectado esa carencia podemos corregirla mediante una historia técnica que luego se convierta en un requerimiento no funcional que probablemente aplique al resto de funcionalidades de nuestra tienda on-line.

La historia técnica necesaria para dotar al sistema de los tiempos de respuesta adecuados podría ser la siguiente:

Rediseñar la arquitectura del sistema que sustenta la web on-line

para que soporte tiempos de respuesta <200 milisegundos

en situaciones de alta concurrencia por encima de los 100 usuarios

Por tanto la forma correcta para la problemática descrita en el post sería de un requerimiento no funcional para una historia de usuario como la que sigue:

Como lector de libros
Quiero poder explorar libros

Para poder escoger el que voy comprar

con el siguiente requerimiento no funcional:

Paso 1

Nombre: usabilidad.rendimiento

Escala: milisegundos entre que el lector clica "buscar" y se le presenta la página con el resultado

Métrica: promedio de los tiempos de búsqueda de libros

Paso 2

Objetivo: <200 milisegundos (lo que Google considera como tiempo de respuesta máximo)

Restricción: >3000 milisegundos (cuando el lector empieza a sentir ansiedad)

Línea base: 1800 milisegundos

Quiero dar mis agradecimientos a Sara y a Miguel por el debate enriquecedor que tuvimos para que pueda escribir este post :-)