Demo vs Review

Dos miradas sobre cómo presentarle a los clientes en qué se estuvo trabajando.

Random Google Image

Antes de comenzar quiero aclarar que en este artículo no estoy hablando puntualmente de una “Review meeting” tal cual plantean frameworks como SCRUM. Simplemente son dos formas de llevar a cabo una demostración del trabajo realizado a un tercero.

Es razonable que cada tanto nuestros clientes quieran ver el progreso, así como también lo es, que nosotros, orgullosos desarrolladores, queramos mostrar en lo que hemos estado trabajando.

No importa la metodología utilizada: si es ágil o no; si es por iteraciones cortas o largas; en algún momento debemos interactuar con el cliente para que éste pueda ver “lo nuevo”.

El ejemplo que voy a usar, si mal no recuerdo, lo usó Freddy Alegre en el AgileOpenCamp de este año en uno de sus charlas de openspace, así que el crédito es para él :).

Para ilustrar el ejemplo, supongamos que el cliente pidió que se le construya una silla. Vamos a mostrarle al cliente cómo avanza su producto con una demostración, utilizando dos miradas diferentes : la “demo” y la “review”.

Demo

Empecemos con una demo. Esta reunión suele ser un ambiente controlado, en donde una persona del equipo le muestra a los demás qué se hizo. Empieza contando como pusieron un cosa por acá, otra por allá y cómo es el flujo de trabajo.

El problema de las demo es que en general uno evita hacer cosas que potencialmente puedan generar un fallo durante la demostración (como ingresar letras en un campo solo numérico), por miedo a quedar en evidencia.

Random Google Image

Haciendo el paralelismo con la silla, uno al mostrarle la silla se la muestra de lejos, se sienta despacito y quizás solo en una parte procurando no cargar la pata que sabemos que está mal encolada para que no se rompa. Le contamos lo suave que es la madera y lo bien que siente al sentarse.

Si alguna vez fueron a comprar un sillón sabrán que se siente cuando te dicen “son de muestra, no te podes sentar”. E imaginen que siente el cliente cuando ve su producto andando en una pantalla.

Este tipo de reunión nos suele dejar poco feedback útil al equipo de desarrollo. Yo personalmente las veo más para cubrirse y decir “¿ves que avanzamos un montón?” que para generar un valor real al producto y por ende a los usuarios.

El mayor feedback que podemos obtener de una demo es visual : “¿podemos cambiar el color de ese botón?”, “¿podemos alinear eso a la derecha?”, etc.

Review

La review va un paso más. Los que se reúnen son los mismos que estaban para la demo, pero en lugar de mostrar una pantalla, lo que se hace es darle al cliente la opción de interactuar con el software, y a medida que le vamos contando los avances, que él vaya teniendo la posibilidad de descubrir cómo se hacen las cosas.

La ventaja de permitir al cliente utilizar el software es que puede darnos
un feedback mucho mas rico respecto a cómo se organizaron, las posiciones
de los elementos, los textos, etc. Como usuario uno puede detectar si es cómodo trabajar con el sistema o no.

Podemos ir un paso más y no explicarle siquiera las cosas, solamente decirle cosas como “ahora podes crear un usuario nuevo, y luego darle permisos de administrador” que que él deba hacerlo con la menor asistencia posible. Esto nos permite probar nuestras si la experiencia de usuario es como la pensamos o si le dificulta encontrar donde se realiza cada tarea.

En el caso de la silla podría descubrir que su peso es demasiado y pedir que se refuercen las patas; o que la madera elegida se ve linda y suave pero haría falta un almohadón ya que después de 10 minutos sus posaderas se sienten incómodas usando el producto :).

Random Google Image

Existen muchas posibles ramificaciones para un review y generalmente las empresas de servicios les escapan porque el control está más del lado del cliente. Pero los beneficios para el cliente son infinitamente mejores.

También hay que tener en cuenta que aunque es el cliente quién usa el software, está todo el equipo de desarrollo durante la reunión para guiar al usuario que hace la prueba del sistema. La reunión debe ser igualmente planificada y estar alineada con los objetivos de la iteración. No es una reunión aleatoria que va para donde quiere.

Cerrando

Como se dijo antes, una review permite al usuario final o cliente tener un contacto real con el software, pudiendo detectar mejoras con mayor rapidez que el caso en donde es observador pasivo.

Si bien hay mayor riesgo de que algo salga mal, ese riesgo puede ser mitigado de muchas otras formas durante el desarrollo y las ganancias son aún mayores que el riesgo de aceptar que algo no salió bien.

Sea cual sea el método que elijan, algunos pequeños consejos:

  • Todos para uno: Que participe todo el equipo tanto en la preparación como en la reunión. Escuchar el feedback de primera mano es mucho más eficiente que jugar al teléfono descompuesto.
  • Planificar: Elegir en que orden van a presentar las cosas y armar un guión para seguir un orden.
  • Preparar: Crear de antemano todo lo que sepamos que necesitamos en el ambiente donde vamos a probar. Usuarios, imágenes, reportes, datos de prueba, etc.
  • Practicar: Al menos una vez para ver que van a decir en cada caso de no quedar balbuceando mientras piensan “¿Cómo era esto?”.
  • Documentar: Todo lo que se dice en la reunión que de valor al producto.

Los invito en su próxima entrega a hacer una review en lugar de una demo y contarme cómo les fue :).