En un diagrama, una devolución parece sencilla: solicitar, autorizar, recibir y reembolsar. Sin embargo, si preguntas a una persona de soporte, a otra de almacén y a un desarrollador qué significa «aprobado», quizá obtengas tres respuestas distintas. Para una significa que el cliente puede devolver el artículo; para otra, que ha superado la inspección; para la tercera, que se ha aceptado una instrucción de pago.
Un taller de EventStorming permite descubrir esas diferencias al construir un relato compartido de los eventos importantes del negocio. Esta guía utiliza el proceso de devoluciones de un comercio ficticio para mostrar cómo pasar de descripciones contradictorias a un modelo que se pueda debatir con quienes realizan el trabajo.
Delimita el proceso que quieres modelar
El formato EventStorming Process Modelling de Alberto Brandolini sirve para explorar un proceso existente o diseñar uno nuevo. Es un buen punto de partida cuando la pregunta se refiere a un flujo concreto del negocio. Una sesión Big Picture explora un ámbito más amplio; una sesión Software Design profundiza en la implementación. No prometas completar los tres enfoques en una reunión breve.
Para el comercio del ejemplo, define el alcance así: «Un cliente devuelve un artículo comprado y recibe un reembolso o una explicación del rechazo». Deja fuera de la primera revisión los cambios de producto, las compensaciones de proveedores y las investigaciones de fraude. Puedes señalar dónde se relacionan con el proceso sin dejar que ocupen todo el tablero.
Invita a personas que conozcan distintas partes del recorrido: atención al cliente, operaciones de devoluciones, pagos e ingeniería. Resulta especialmente útil contar con alguien que tenga autoridad sobre la política de devoluciones. Un grupo formado solo por desarrolladores puede describir bien el software y pasar por alto lo que hacen los empleados fuera de él.
Empieza por eventos que las personas reconozcan
Deja que los participantes añadan eventos antes de intentar acordar una secuencia. Un evento de dominio describe algo relevante que ya ha ocurrido, como «Devolución solicitada» o «Artículo inspeccionado». Usa notas naranjas con etiquetas que expresen hechos pasados. «Inspeccionar artículo» es una acción prevista; «Artículo inspeccionado» registra el hecho resultante. El glosario de DDD Crew explica esta notación y otros conceptos del modelado de procesos.
Pide ejemplos de cada parte del trabajo. La persona de almacén puede añadir «Paquete recibido», mientras que soporte propone «Etiqueta de devolución enviada». Es posible que ninguno apareciera en la primera descripción del desarrollador. Conserva los duplicados hasta saber si realmente describen el mismo evento.
Ten cuidado con las etiquetas tomadas de pantallas o campos de una base de datos. «Estado actualizado» oculta qué ha cambiado en el negocio. Pregunta qué ha pasado a ser cierto para el cliente o para la persona que opera el proceso. Del mismo modo, «Reembolso completado» necesita una definición: ¿se envió la instrucción, la aceptó el proveedor de pagos o se confirmó su liquidación? Separa esos eventos si después de cada uno se toman decisiones diferentes.
Construye el relato de la devolución en grupo
Organiza los eventos en un relato plausible y pide a los participantes que lo recorran en voz alta. En este ejemplo, la primera versión podría ser: Devolución solicitada → Devolución autorizada → Paquete recibido → Artículo inspeccionado → Reembolso solicitado → Reembolso confirmado.
La secuencia es un modelo para debatir el caso, no una descripción de la política de todos los comercios. Si el equipo real reembolsa antes de recibir el artículo, su mapa debe reflejarlo. Si la inspección y otra actividad pueden suceder por separado, colócalas en recorridos distintos en lugar de insinuar que una siempre espera a la otra.
El patrón Conversational System de Brandolini advierte del problema de imponer una secuencia fija a comportamientos simultáneos o que pueden darse en órdenes diferentes. Lo importante es qué depende de qué, no lo bien alineadas que estén las notas.
Cuando surja un desacuerdo, añade un Hot Spot de color rosa intenso cerca del evento afectado. Formula el desacuerdo como pregunta: «¿La autorización garantiza el reembolso?» resulta más útil que «Problema de política». Avanza lo suficiente para ver el contexto y vuelve después a la pregunta con las personas adecuadas.
Relaciona los eventos con acciones e información
Cuando el relato se entienda, añade las acciones que hacen posibles los eventos. Usa notas azules para los comandos o acciones e identifica a la persona o al sistema que los inicia. Incorpora la información necesaria para una decisión solo cuando ayude a explicar el comportamiento. Presentar todos los símbolos posibles desde el principio puede convertir el taller en una clase de notación.
La primera parte detallada del proceso del comercio podría ser esta:
| Evento o situación | Acción que examinar | Información necesaria | Pregunta pendiente |
|---|---|---|---|
| Devolución solicitada | Autorizar devolución | Pedido, artículo y política de devoluciones aplicable | ¿Quién puede aprobar una excepción? |
| Paquete recibido | Inspeccionar artículo | Artículo esperado y motivo registrado de la devolución | ¿Qué ocurre si el paquete contiene otro artículo? |
| Artículo inspeccionado | Solicitar reembolso | Resultado de la inspección y referencia del pago original | ¿Todos los resultados de inspección permiten reembolsar? |
| Reembolso solicitado | Comprobar resultado del pago | Respuesta del proveedor y referencia de la transacción | ¿Cómo se distingue un resultado desconocido de un rechazo? |
Una política describe la reacción a un evento. En el ejemplo, el equipo podría proponer: «Cuando la inspección acepte la devolución, solicitar el reembolso». Recoge esa regla en una nota lila entre el evento y la acción correspondientes. Márcala como propuesta hasta que la confirme la persona responsable. Un conector no sustituye la autoridad necesaria para aprobar una regla del negocio.
Observa la diferencia entre solicitar y confirmar un reembolso. Tratarlos como un mismo evento podría ocultar respuestas tardías o solicitudes duplicadas. El taller no tiene que resolver inmediatamente el diseño del sistema de pagos, pero sí debe hacer visible la distinción.
Pon a prueba el modelo con una devolución atípica
Después del caso sencillo, elige una excepción que cambie la conversación. Supongamos que llega un paquete sin el identificador esperado del artículo. Soporte reconoce el pedido del cliente, pero almacén no puede identificar el contenido con suficiente seguridad.
Pide al grupo que continúe el relato. ¿Ya ha ocurrido «Artículo inspeccionado» o solo «Paquete recibido»? ¿Quién puede pedir más información? ¿Qué evento indica a soporte que la devolución requiere atención? Si la respuesta es «alguien envía un mensaje», concreta quién lo envía, quién lo recibe y qué hecho del negocio comunica.
No inventes un plazo ni un derecho al reembolso para rellenar el hueco. Coloca la pregunta pendiente sobre la política junto a las notas correspondientes. El patrón Rush to the Goal de Brandolini propone mantener visibles las objeciones y alternativas mientras se construye un recorrido básico. Aquí resulta más útil que detener todas las conversaciones hasta resolver cada excepción.
Una vez entendido el comportamiento del negocio, un diagrama de flujo de las excepciones (guía en inglés) puede concretar las distintas ramas operativas. EventStorming ayuda primero a acordar el significado de los eventos de los que dependen esas ramas.
Crea el modelo de devoluciones en Boardmix
Abre Boardmix y crea una pizarra en blanco para la conversación sobre devoluciones. Escribe el alcance encima de una zona de trabajo amplia. Coloca una pequeña leyenda a un lado para distinguir eventos, acciones, políticas y Hot Spots sin depender únicamente del color.
Antes de añadir notas, explica la notación al grupo. Una leyenda de pizarra con etiquetas además de colores ayuda a interpretar cada símbolo de la misma manera; conserva los significados de EventStorming utilizados aquí, en lugar de copiar el código de colores de otro taller.
- Añade notas adhesivas naranjas para los seis eventos del relato inicial. Utiliza etiquetas que se puedan leer durante la llamada.
- Deja espacio entre los eventos para las acciones azules. Pon «Solicitar reembolso» antes de «Reembolso solicitado», sin sustituir el evento.
- Añade la política propuesta en lila junto al resultado de la inspección. Conecta solo las relaciones que el grupo haya debatido.
- Coloca la pregunta rosa «¿Autorizar garantiza el reembolso?» junto a «Devolución autorizada». Mantén las dudas cerca del comportamiento al que afectan.
- Comparte el tablero con los permisos de edición adecuados. Pide a una persona de cada parte del proceso que recorra el relato mientras las demás corrigen las notas.
En una sesión en línea, mantén visible la misma sección mientras alguien la explica. Si varias personas reorganizan a la vez una zona en disputa, detén la edición y pídeles que describan sus alternativas. El tablero apoya la conversación; mover notas deprisa no demuestra que exista acuerdo.
Distingue el proceso observado de las propuestas
Que el tablero parezca completo no demuestra que el software implemente ese proceso, que una política esté aprobada o que se hayan encontrado todas las excepciones importantes. Separa el comportamiento observado de los cambios propuestos. Si el grupo diseña una nueva secuencia de reembolso, conserva la actual para que la diferencia sea visible.
En el caso del comercio, el resultado inmediato puede ser concreto: cambiar el nombre de un evento ambiguo, confirmar quién puede autorizar una excepción e investigar cómo se trata un resultado de pago desconocido. Esas preguntas dan a operaciones e ingeniería un punto de partida común. La siguiente conversación puede comenzar en la nota rosa pendiente, en lugar de repetir qué significa «aprobado».
