El “Como usuario quiero” un camino al reverso tenebroso es

El objetivo de nuestro Mr. NoBody hoy, y de su equipo de Product Owners, durante años, había sido cumplir el Roadmap que se fijaba a principios de año. Para ellos el éxito se medía así… en porcentaje de cumplimiento del Roadmap.

Llegó el Corona, las 10  plagas, la teoría conspiranoica de que Spectra se había confabulado con Hydra para destruir el universo y, fuera lo que fuese… su línea de negocio comenzó a ir mal. 

 —¿Cómo puede ser? Si cumplimos más del 90% del Roadmap cada año y, además, trabajamos en Ágil, con Historias de usuario y todo lo demás —repetían en las numerosas reuniones de crisis.

 Hasta que un Rebelde Ágil, de cuyo nombre puedes acordarte, que se acababa de incorporar a una de aquellas reuniones de llanto, exclamó:

 —Aparte de fijar un Roadmap y convertirlo en Historias de Usuario…  —hizo una pausa para pasarse una mano por la barba—. ¿Alguién ha mirado si lo que entregamos es lo que necesita el usuario? ¿Se lo ha preguntado?

 Tras un silencio desconcertado, Mr. NoBody respondió «no”.

Primero fueron los antiguos requisitos, tremendas especificaciones pormenorizadas y detalladas, se usaban normas viejunas como las IEEE 830 (uuuff dolor). Siguieron los casos de uso. Y llegaron las Historias de Usuario, desde el mundo eXtreme Programming, como una brisa fresca frente a la burocracia. Pero de eso hace ya muchos años. Muchos. 

Después de aquello vinieron BDD, Gherkin y, en definitiva, especificar con ejemplos y orientándose a la prueba de aceptación. Y hubo otros más, como las Job Stories.

Pero, más allá de los formatos mejorados, todas las evoluciones seguían llevando, en mucha menor medida, en su alma un toque de LADO OSCURO heredado del originario Requisito del cascada… creer que NOSOTROS sabemos lo que necesita el usuario.

Y por eso, desde hace unos años, en los sitios ya maduros (repito lo de maduro, porque empezar por Historias de Usuario cuando se viene del Cascada es una opción, lo sospechoso es no evolucionar una vez que el uso de Historias está ya maduro) empezamos a incorporar la cultura de escribir las historias como hipótesis (que ya lo había contado hace unos 7 años). 

 Hipótesis (en vez de Historias): Algo que nosotros creemos, asumiendo que puede no ser así, y con el compromiso de medir en el UNIVERSO USUARIO si hemos acertado. Ejemplo real…

 CREEMOS: que incorporar la funcionalidad de **** en la página de ****

PRODUCIRÁ EL RESULTADO de una mejor participación del usuario

Y LO SABREMOS EN REALIDAD cuando veamos un aumento del 5% en las descargas de  ****.

Volviendo al caso de Mr. NoBody, no sólo las Hipótesis cambiaron la situación, fue necesario trabajar el Dual Track, los MVP y otros tantos. 

Espero que el tema de hoy te sea de ayuda y, como resumen, recuerda… piensa en el problema que tiene el usuario, que no siempre es el que él cree que tiene, antes de pensar en la solución.

Antes de terminar, muy brevemente… recuerda el programa de FORMACIÓN ONLINE LOWCOST DE VERANO sobre Técnicas Ágiles, con 4 masterclass en Video Asíncronas sobre:

  • Técnicas de Estimación,
  • Creación de Historias de Usuario,
  • Priorización del Product Backlog y/o
  • Retrospectivas….

Con un 50% de DESCUENTO hasta el 30 de julio para los primeros 30 inscritos. Tienes toda la información aquí: Verano Ágil.

Que la Agilidad te acompañe.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba