Una visita al supermercado

Imaginen un sábado por la mañana y Uds. entrando al supermercado cercano a su casa.

Allí hay góndolas que exhiben los productos, encuentran las marcas habituales, los precios no parecen fuera de lugar.

Todo parece normal, pero hay algo que los incomoda, los pasillos estrechos, la limpieza en alguno de los exhibidores  no es la mejor, cierto desorden en la mercadería, etc.

Efectúan la compra, hacen fila en la caja, abonan y se retiran.

Al salir les queda una sensación que podría expresarse así: “Compré lo que necesitaba pero no volvería, o sólo lo haría en caso de necesidad; prefiero caminar más y pagar algo más caro pero sentirme mejor comprando”. Con esto termina este relato cotidiano.

Hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Los requerimientos o requisitos están cumplidos, las góndolas, la mercadería y los precios. Esa necesidad del consumidor la cubren. Sin embargo,  a pesar de ello:

Las expectativas, es decir aquello que el consumidor esperaba al entrar al supermercado (que puede o no ser realista) basado en experiencias previas, no fueron satisfechas. Encontró pasillos angostos, falta de limpieza, desorden, etc.

Su experiencia como consumidor, la suma de lo físico (góndolas, productos, precios) y lo emocional, no fue buena. Por lo tanto, a menos que tenga necesidad o le convenga por motivos por ejemplo económicos, probablemente no vuelva.

¿Adónde va todo esto?

Se trabajó y trabaja mucho en el área de requerimientos, su  definición, precisión, modelización, que sin duda son importantes. Pero el usuario/cliente/consumidor cada vez tiene más experiencia, utiliza más productos, y sus expectativas aumentan. Su experiencia de usuario incluirá lo que el producto hace, y cómo se esperaba que lo hiciera (lo funcional y parte de lo no funcional) y las expectativas cumplidas o no por el producto en su entorno real de ejecución.

¿Tenemos en cuenta esto también en nuestros desarrollos? ¿Qué ayudaría a considerar más estos temas?

Una propuesta  rápida y seguramente incompleta es:

Trabajar en equipos multidisciplinarios. Cada vez más importante para el éxito de los productos de software y servicios apoyados en ellos. Debemos entender no sólo cómo definir requisitos sino también cómo evaluar  comportamientos de los usuarios / consumidores ante el producto.

Evaluar la experiencia de usuario que trasciende por mucho a la usabilidad aunque la contiene. Suele medirse en algunos casos la usabilidad, pero no es todo lo que importa.

Obtener realimentación proveniente del producto en operación (calidad en uso).  Es fundamental ya que únicamente analizando esta información podremos llegar a entender cómo se siente el usuario interactuando con el producto o servicio.

Definir indicadores relacionados al negocio que muestren el comportamiento del producto / servicio desde su construcción hasta su comportamiento en Producción, además de los puntuales relacionados con la calidad de su construcción. 

Algunos podrán considerar que los puntos enunciados no son de su responsabilidad. Tal vez sea así. Pero… ¿Nuestra responsabilidad es lograr la calidad constructiva y conforme a requerimientos? ¿Sólo eso? ¿O es más amplia y comprende  que además el producto sea exitoso para el negocio?.  Para pensar al menos.


Continua en Equipos multidisciplinarios 
Y en ¡Hoy volvemos al Super!

Saludos,

Raúl

TW: @RaulMartinez582