Tips para hacer un buen User Story Mapping en el planteamiento de un nuevo producto

En estos días estamos manteniendo sesiones en nuestra colaboradora con el objetivo de desarrollar un nuevo producto porque, en el que tenemos actualmente, el modelo de datos es nefasto y no hay mucho que hacer al respecto.

Para tal fin, creamos un board de user story mapping con Miro. No obstante, a la hora de unir las partes de Negocio y Tecnología, nos dimos cuenta de que chocamos en algunas partes, bien por desconocimiento del dominio en su totalidad, bien porque personas que trabajan en negocio y que han programado en el pasado, piensan en las implementaciones de las cosas, pero con una contaminación dada por la herramienta actual.

Con este artículo/tips quiero indagar y a ser posible que me ayudéis a encontrar maneras de no perder el foco para sacar unos mínimos para el prototipo

Haz las preguntas adecuadas

¿Cuál es el problema que buscamos solucionar?
¿Qué user stories entregan valor realmente? Prioricémoslas
¿Qué implementaciones dependen de negocio?, como por ejemplo que tengamos que enviar un fichero .csv a las 6 am

Evita esto

Que se hable de cómo implementar las cosas

Que nos den lecciones del dominio y que no nos enfoquemos en diseñar la prueba de concepto
Que nos comenten, por medio de vivécdotas y experiencias, por lo que una factura no se puede decir que es eliminada o se anula, sino que hay que usar el término rectificar o abonar. Habría que evitar todo el "relleno" previo para decir al final. Evitemos las palabras anular o eliminar en las facturas y usemos rectificar y abonar

Recomendaciones

Involucra a alguien que pueda hacer de facilitador/a. IMPORTANTE: que no esté contaminado/a por el dominio, con esto evitarás que se pueda ir por las ramas.

Visual Thinking - Refleja en algún punto del board el target de clientes. Por ejemplo, para el prototipo inicial y para evitar pensar en implementaciones ya de 1.000.000 de clientes, ten siempre presente que buscamos los mínimos para hacer el monopatín no el coche.

Si ayuda más, cambiar el concepto de Release que es la parte del Product Versión por flujos horizontales.

Tal vez pueda ayudar plantearlo como una pila de test, donde analizamos los casos, happy path, en caso de que esto no ocurra cómo sería el flujo, etc...

Cuidado con el léxico que utilizamos porque puede variar mucho la puesta en común de una idea.

No es lo mismo decir el trigger de este evento es un día que da la impresión de que ÚNICAMENTE se puede disparar ese día, a A partir de este día el trigger de este evento estará permitido

Hay ocasiones en las que las conversaciones cruzadas pueden alargar el ejercicio de terminar una historia de usuario, si pasa muy a menudo se podría practicar hacer "Tres amigos" + Example Mapping. Recomiendo que, como mínimo, haya una persona de Negocio y una de Tecnología en esas salas que vamos a separar para hacer el "Tres amigos"

Herramientas

Miro

TODO en el post