Validación de los requerimientos del cliente desde la perspectiva ágil (Parte II)

En la entrada anterior quedó planteada la siguiente pregunta:

¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente (PO) antes de que el producto salga al mercado?

Para abordar la pregunta daré a conocer una serie de técnicas que son bastante útiles para descubrir y para comprender si se desarrolla el producto correcto con las características adecuadas.

Como cualquier técnica de investigación y validación, las demostraciones tienen sus puntos fuertes y débiles. Esta publicación proporciona una descripción general de los métodos de validación alternativos para que pueda elegir el que mejor se adapte a su producto.

Por Roman Pichler

Comentarios y datos en Scrum

La recopilación de comentarios y datos es un aspecto vital de Scrum. Le permite saber si se crea el producto adecuado con las características adecuadas. Scrum emplea un proceso de tres pasos para lograr esto: se crea un incremento de producto, que luego se expone a los usuarios, clientes y otras partes interesadas. Esto genera comentarios y datos, que desencadenan cambios en la cartera de productos, como muestra la siguiente imagen.

Para aprovechar este proceso, las técnicas utilizadas para recopilar los datos y validar el producto son cruciales. Si utiliza el método incorrecto, es probable que recopile datos incorrectos o insuficientes y saque conclusiones incorrectas. Si bien hay una variedad de técnicas disponibles, Scrum reconoce solo una: la demostración del producto, que se realiza en la reunión de revisión del sprint.

¡Pero esto no significa que deba o no pueda emplear otra técnica! Lo contrario es cierto: la demostración de sprint puede o no ser adecuada para el producto. Además, el uso de un único método de recopilación de datos durante un período de tiempo prolongado suele ser un error. Cada técnica tiene sus fortalezas y limitaciones, y ninguna es siempre apropiada. Por lo tanto, debe elegir la que sea más útil para su producto y combinar técnicas complementarias.

Una selección de técnicas útiles

Para ayudarlo a seleccionar el método correcto, he resumido cinco técnicas que se usan felizmente en Scrum en la tabla a continuación. Discuto cada técnica en las siguientes secciones.

Demostración del producto

Como sugiere su nombre, la demostración del producto presenta el último incremento del producto a los usuarios, clientes y partes interesadas internas correspondientes. El presentador explica cómo los usuarios emplearían el producto para realizar un trabajo específico. Las demostraciones de productos son particularmente valiosas en los primeros sprints, ya que le permiten obtener comentarios inmediatos sobre la funcionalidad limitada y los incrementos muy pequeños: al envolver el incremento en una historia, las personas pueden imaginar cómo sería usar el producto. Esta fortaleza también es una debilidad importante: la retroalimentación se basa en lo que la gente ve y oye, no en su experiencia real de uso del producto. Además, el presentador puede influir en los usuarios de manera inapropiada al hablar sobre el producto o hacer preguntas cerradas, y las personas poderosas como un gerente senior pueden influir en las opiniones del grupo.

Prueba de usabilidad

Una prueba de usabilidad le permite comprender cómo los usuarios interactúan con su producto. Las pruebas de usabilidad suelen realizarse en un entorno controlado, como una sala de reuniones o un laboratorio. Se pide a los usuarios de destino que realicen una tarea utilizando el último incremento de producto, que puede ser un prototipo en papel o un software ejecutable. Luego, observa y registra cómo las personas emplean el producto y puede finalizar la prueba preguntando a los participantes sobre sus experiencias e impresiones. A menudo es posible realizar la prueba en la reunión de revisión del sprint. Si bien una prueba de usabilidad genera rápidamente datos reales del usuario, el entorno artificial y la observación pueden hacer que los usuarios actúen de manera diferente en comparación con trabajar con el producto en “la naturaleza”, es decir, en el entorno en el que se utilizará el producto, por ejemplo, en casa, en el trabajo, en el auto, en el tren. Aquí es donde entra en juego la siguiente técnica.

Lanzamiento

Liberar software significa dar acceso a un grupo de usuarios objetivo a una versión temprana del producto y pedirles que lo utilicen en su entorno objetivo. Luego, los datos de uso se registran mediante una herramienta de análisis, por ejemplo, Google Analytics. El producto ahora se emplea en su entorno objetivo y se puede emplear un grupo de prueba más grande, lo que reduce el riesgo de recopilar datos que no son representativos del segmento de mercado objetivo. Con el software de análisis adecuado, también puede recopilar datos como quién interactúa con qué característica del producto, cuándo y con qué frecuencia, y qué variante de una característica prefiere la gente (prueba A/B). En el lado negativo, la técnica no puede explicar por qué las personas usan una determinada función o por qué no lo hacen. Además, hay un retraso: las personas necesitan tiempo para descargar, instalar y comenzar a usar el último incremento antes de que haya suficientes datos disponibles para sacar las conclusiones correctas. En un contexto de Scrum, esto significa que tienes que posponer el siguiente sprint o continuar con una función diferente para mitigar el riesgo de moverte en la dirección incorrecta. Si usa principalmente lanzamientos, su reunión de revisión de sprint cambia: ahora se usa para sincronizar las partes interesadas internas y revisar el progreso del proyecto en lugar de validar el producto.

Observación

La observación significa observar atentamente a los usuarios mientras emplean el producto en su entorno objetivo. Esto le ayuda a comprender cómo las personas interactúan con el producto y cómo utilizan sus funciones. También le permite hablar con el usuario y aprender sobre la experiencia del usuario mientras interactúa con el producto. El principal inconveniente de las observaciones es que pueden llevar mucho tiempo, especialmente si desea observar a más de unos pocos usuarios. Los usuarios también pueden actuar de manera diferente cuando alguien los observa (efecto de observador) y sus propios prejuicios pueden interferir con su capacidad para ver con claridad.

Spike

Son prototipos para probar una suposición arquitectónica o relacionada con la tecnología, por ejemplo, que Enterprise JavaBeans podrá ofrecer el rendimiento deseado. Por lo general, son baratos de crear, generan el conocimiento relevante rápidamente y le permiten ver si puede cumplir con requisitos críticos no funcionales . Los spike’s se vuelven problemáticos si los emplea demasiado, si se preocupa más por cómo construir el producto que por qué y qué construir. Si esto sucede, el resultado es un producto sobre-diseñado y una mentalidad centrada en la solución en lugar de una centrada en el usuario. Una vez conocí a un equipo que había estado creando spike’s durante casi dos años sin tener que mostrar ningún código enviable. Decirles que se detuvieran y pensaran en los usuarios fue bastante impactante para ellos.

Elegir la técnica correcta

Todas las técnicas discutidas tienen sus fortalezas y debilidades. Si bien siempre debe elegir la técnica que lo ayude a alcanzar su objetivo de sprint y validar el incremento de manera efectiva, me parece una regla práctica útil usar demostraciones de productos, pruebas de usabilidad y spike’s en los primeros sprints y lanzamientos; y observación en los sprints posteriores. , como ilustra la siguiente imagen.

El diagrama anterior intenta equilibrar las fortalezas y debilidades de las diferentes técnicas, y corresponde a un enfoque basado en el riesgo donde los riesgos clave y los supuestos críticos se abordan en los primeros sprints.

Independientemente de las técnicas que elija, no cometa el error de confiar en una sola técnica durante un período prolongado de tiempo. Cada técnica tiene sus ventajas e inconvenientes, y ninguna técnica es perfecta. Combine técnicas cualitativas y cuantitativas, por ejemplo, comunicados y observación, para aprovechar sus respectivas fortalezas y mitigar sus debilidades. No sea tímido para experimentar con diferentes técnicas para descubrir cuál funciona mejor para su producto, y use la retrospectiva del sprint para revisar su efectividad.

Fuente: https://www.romanpichler.com/blog/beyond-product-demo-validation-techniques-in-scrum/
Copyright © Pichler Consulting

Traducción al español: Juan José González Faúndez