¡Hoy volvemos al Super!

Continuemos con nuestra aventura en el supermercado  iniciada en un post anterior (Una visita al supermercado).

Como sus propietarios notaron una caída en las ventas se propusieron averiguar de cuánto era y a qué se debía dicha caída.

Más allá del indicador del monto de la caída, que era un indicador tardío, les interesaba saber si había alguna otra observación que les permitiera adelantarse a los problemas.  

Descartaron primero las obvias, precio, variedad, ubicación del local, etc., ya que en todas ellas estaban en iguales condiciones que la competencia.

Quedaba por entender entonces algo que estaba ocurriendo dentro del local, entre el cliente y la oferta de nuestro supermercado.  Pensaron varias alternativas, entre ellas:

•       Contar cuánta gente entraba y cuánta salía sin comprar nada.
•      Ver los tickets y entender en qué góndolas la gente compraba menos,  a igual precio e igual mercadería que la competencia, habría otros factores que no les convencían.
•      Detectar cuántos clientes vuelven a comprar luego de la primera compra (licencia poética).
•      Entender el tipo de cliente que normalmente atraemos y entender sus expectativas (qué le encanta y qué le disgusta).
•       .……

Podríamos seguir enumerando indicadores que le pongan valor al comportamiento del cliente y tratar de deducir de allí la experiencia  de compra que tiene.

--

Dejemos aquí al supermercadista preocupado y nuevamente hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Comencemos por la definición de requerimientos o exploración de las necesidades.

Si el comportamiento del usuario es más conocido y manejable nos permitirá la definición de requerimientos algo más precisa, si es menos conocido y manejable nos obligará a explorar.

Para ordenar el trabajo puede ser útil aquí el modelo Kano ⁽¹⁾, que nos dice habrá funcionalidad que el producto deberá tener, ya que si ellas nuestro usuario/consumidor ni siquiera lo considerará, habrá otras características que entre más tenga de ellas, más apreciará el producto y finalmente habrá otras que al descubrirlas le encantarán y eso hará que lo considere de calidad superior, y tal vez esté dispuesto a pagar más por él. Es una ayuda, al menos nos acercará a descubrir necesidades y algunas expectativas.

Pero qué ocurre cuando el producto está en operación durante algún tiempo. ¿Cómo podremos descubrirlas? Es una situación parecida a la de nuestro personaje del supermercado que quería verificar la experiencia del consumidor en su local. Buscaba medidas e indicadores que lo orientaran a qué cambiar y mejorar y a qué mantener. Nosotros también.

Dependiendo del tipo de producto/servicio que estemos tratando, algunos indicadores pueden ser parecidos, por ejemplo cantidad de visitantes convertidos en ventas.

Algunas alternativas de qué medir cuando el producto/servicio está operando las plantea la idea de calidad en uso propuesta por la ISO 25010, hoy con poco detalle todavía, pero ayuda. 

Nos hace preguntar por ejemplo:

• ¿Confía el usuario en el sistema?
• ¿Hace más cosas en menos tiempo?
• ¿Está satisfecho con el sistema?
•  ¿Se logró/mejoró el objetivo económico con la adopción del sistema?
• ¿Logró lo anterior, confiabilidad, efectividad, satisfacción, en los diferentes contextos de utilización?

En estas entradas: La calidad en uso e Indicadores accionables hay algo más sobre esta idea.

Posiblemente nuestro caso necesite algunos indicadores distintos, o más detallados, o de mayor precisión. Pero esta es una buena aproximación.

Dejamos entonces a nuestro supermercadista de la historia viendo cómo mejorar la experiencia de usuario de sus visitantes y, como él, entendamos que las expectativas al entrar al local, superadas o no, son lo que va a definir finalmente el futuro del negocio.

Viene de Equipos Multidisciplinarios
y de Una visita al supermercado

Saludos,

Raúl

TW: @RaulMartinez582

Referencias:

Kano, Noriaki; Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji (April 1984). «Attractive quality and must-be quality»

Ser o parecer

Entre los elementos básicos a tener en cuenta, planificar y diseñar al gestionar un área de QC o pensar una estrategia de pruebas para un proyecto o servicio específicos, no podemos dejar de lado los ambientes y datos de prueba necesarios.

Ambientes y datos de prueba ocasionan en algunos casos preguntas como “¿Realmente se necesitan? ¿No puede ser la máquina del desarrollador / ambiente de desarrollo? ¿Por qué no Producción antes de liberar?  ¿Un equipo potente les es suficiente? ¿No pueden crear sus propios datos, o traer una base / archivos productivos? …”,
o directamente objeciones como “Nunca los hemos tenido; en nuestro caso no es necesario; saldrá muy caro…”

Afortunadamente estas preguntas y objeciones son cada vez menos frecuentes. Sin embargo, aún pueden aparecer, y es parte de nuestra misión al gestionar un área de pruebas o un proyecto / servicio dados, ocuparnos seriamente de ambientes y datos de prueba. Desde contestar adecuadamente las preguntas y objeciones, pasando por saber diseñarlos, solicitarlos y gestionarlos.
Ellos contribuirán a la fiabilidad de nuestras pruebas. En definitiva, lograremos que lleguen a Producción productos donde las pruebas realizadas serán más representativas de lo que ocurre en la realidad, deseablemente con menos fallas evidentes u ocultas.

Hemos aprendido y enseñado habitualmente que al menos tres ambientes bien diferenciados son los mínimos recomendables:

• Desarrollo. Donde trabajan los desarrolladores  con todas sus herramientas.
• Pruebas. Donde trabajan los testers con sus propias herramientas y datos.
• Producción. Donde trabajan los usuarios con sus datos y donde las aplicaciones conviven con otras.

Y que deseablemente se agrega un cuarto ambiente entre Pruebas y Producción:

• Pre-producción. Donde pueden trabajar los usuarios con copias de sus datos durante las pruebas de aceptación, existirán algunos de los sistemas con los que convivirá la aplicación, se pueden dar capacitaciones y demostraciones sobre los productos a liberar o modificados, y se pueden realizar pruebas de requerimientos no funcionales.

Y la disyuntiva que suele plantearse es la del título de este artículo:
Ser o parecer.

• ¿Puede nuestro ambiente de Pruebas ser Desarrollo / Producción / Pre-producción, tal vez utilizando distintas instancias de los datos?
• ¿Pueden nuestros datos de prueba ser directamente los datos de Producción?
• ¿Cuánto se tienen que parecer los ambientes que nos suelen ocupar, Pruebas y Pre-producción, al ambiente de Producción?
• ¿Cuánto se tienen que parecer los datos de prueba que generemos a los datos productivos?

Lamentablemente no tenemos una respuesta terminante y taxativa a estas preguntas, sólo que deberían “parecerse tanto como sea posible”.

Y esa recomendación parte del sentido común, y de la necesidad y conveniencia de llevar a cabo pruebas que realmente diagnostiquen la calidad de los productos entregados. Al margen de considerar que muchos tipos de pruebas directamente no tienen sentido en ambientes o con volúmenes o variedad y tipo de datos no similares a Producción.

Como ya he mencionado, ambientes y/o datos mal configurados o estructurados, generan riesgos respecto a la calidad de nuestras pruebas. Entonces, ¿por qué no gestionar esos riesgos como gestionamos los del producto de software que estamos probando? ¿por qué no justificar la inversión necesaria en adquirir / configurar los ambientes y generar los datos de prueba, en función al riesgo de pérdidas potenciales para el negocio que ocasionan  pruebas no fiables?

Poder pensar, planificar y luego gestionar, ambientes y datos con los que controlamos la calidad de los productos de software, ayuda a mitigar adecuadamente los riesgos identificados en relación al producto, a su contexto y a su evolución. Entonces:

• Ajustemos los diseños y estrategias a lo importante para mitigar los riesgos y potenciales pérdidas, dentro de las restricciones existentes.
• Justifiquemos y negociemos alternativas para los ambientes y datos de prueba, mostrando los riesgos de cada una.

Hasta la próxima
Pilar

Nota: imagen tomada de faro - http://www.e-faro.info/

Equipos multidisciplinarios

En el post anterior  Una visita al supermercado mencioné el tema de los equipos que están compuestos por personas que dominan diferentes disciplinas.  Para no que no quede en un enunciado, detallo un poco el tema. 

Como lo que buscamos es la mejor experiencia de usuario posible que lleve al éxito del negocio, el equipo que se conforme debe estar compuesto por todas aquellas personas que puedan colaborar a lograrlo y verificar que realmente se logró. Esto significa que tiene que estar el que hace y el que ve en el campo el resultado de lo hecho. 


Entonces, el equipo multidisciplinario deberá, al menos idealmente:

• Encargarse de un flujo de valor. Esto es entenderlo, diseñarlo, implementarlo y medir su resultado en operación.  Para poder responder ¿qué le aporta/aportó al negocio esta operatoria?
• Ser responsable por ese flujo de valor, es decir tomarlo como propio, no descargando responsabilidades en uno u otro sector. Lo que se construye es de todos y todos en el equipo son responsables por su éxito o su fracaso.

Estos dos puntos nos llevan a que al equipo multidisciplinario lo deben componer entonces: 

• personas del negocio que entiendan qué se requiere y qué se espera del producto/servicio y del flujo de valor en particular, 

• personas técnicas que tenga capacidad para llevar adelante la ejecución 

• y personas de la primera línea de contacto con el usuario que informen el resultado del producto en operación de modo de adecuarlo donde se requiera.

No todos deben saber hacer de todo en el equipo. Si bien sería ideal, también sería poco óptimo y utópico. Pero sí todos deben saber qué se hace y por qué y para qué.  

Ventajas, muchas: sentido de pertenencia, objetivos definidos, indicadores de negocio relacionados a indicadores técnicos, etc.

Obstáculos, bastantes: organizaciones funcionales que no aceptan, por cultura o desconocimiento, otras alternativas de organización; pequeños “caciques” que no ceden su territorio; negocio e implementación separados por fronteras funcionales, etc.; “secretos” del negocio no accesibles a personas técnicas; vivir en urgencias continuas y no encontrar  proyecto ni tiempo para implementar la idea (que entonces nunca aparecerá). 

Resumiendo, como todo primer paso es complejo, no exento de caídas y vueltas a empezar.

Pero en muchas organizaciones que ofrecen productos exitosos, se trabaja en equipos multidisciplinarios.

Viene de Una visita al Supermercado

Sigue en  ¡Hoy volvemos al Super!

Saludos,

Raúl

TW: @RaulMartinez582

Nota: la imagen muestra un momento del rescate de los 33 mineros chilenos de la mina de cobre San José durante agosto 2010.

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