Domain storytelling

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Un experto cuenta un caso real de principio a fin. El facilitador dibuja actores, objetos y actividades en una secuencia numerada; los participantes corrigen el dibujo mientras la historia se desarrolla. Las variantes se exploran después del recorrido principal.

Ejemplo: tramitar una solicitud

1. El solicitante entrega el formulario al analista.
2. El analista consulta los antecedentes en el sistema.
3. El analista envía una propuesta al responsable.
4. El responsable comunica la decisión al solicitante.

Este texto prepara la conversación; durante el taller se representa visualmente con la notación de la técnica. Pregunta qué significa cada término y dónde cambia una responsabilidad.

Notación

Elemento	Representación	Ejemplo
Actor	Icono de persona, grupo o sistema	Solicitante, analista, motor de reglas
Objeto de trabajo	Icono de documento, dato, dinero	Solicitud, informe del buró, pagaré
Actividad	Flecha con un verbo	envía, consulta, aprueba
Número de secuencia	En cada actividad	Orden de la historia
Anotación	Texto libre	Reglas, excepciones, dudas

Cada frase de la historia sigue el patrón actor – actividad – objeto – (con/a) otro actor: «(3) El analista solicita el informe al buró».

Factores de alcance

Antes del taller, decide qué tipo de historia vas a contar:

Factor	Opciones
Granularidad	Gruesa (todo el proceso de crédito) o fina (solo la verificación de identidad)
Momento	As-is (cómo se hace hoy) o to-be (cómo se hará)
Pureza	Pura (sin sistemas, solo negocio) o digitalizada (con los sistemas actuales)

Empezar por una historia gruesa, as-is y pura suele dar la mejor comprensión del dominio antes de hablar de software.

Taller de 90 minutos

1. Elegir un caso concreto y reciente («la solicitud de Juan del martes pasado»), no el proceso genérico.
2. Contar y dibujar: el experto narra; el facilitador modela en vivo con Egon.io o en una pizarra.
3. Releer la historia en voz alta para validar que es correcta.
4. Variantes: ¿qué pasa si el buró no responde?, ¿y si falta un documento? Cada variante, una historia aparte.
5. Glosario: anotar términos y sus significados tal como los usa el negocio.
6. Cerrar con dudas abiertas y responsables.

Del dibujo a los límites del sistema

Observa en las historias dónde cambian los actores, el vocabulario o el ritmo del proceso: suelen señalar límites de bounded contexts. Si la palabra «cliente» significa cosas distintas en dos partes de la historia, hay probablemente dos contextos.

Comparación con otras técnicas

Técnica	Fortaleza
Domain storytelling	Casos concretos contados por expertos; fácil de entender para negocio
Event Storming	Visión amplia de eventos de todo un dominio con muchas personas
User story mapping	Organizar el backlog alrededor del recorrido del usuario
Diagramas BPMN	Especificación formal de procesos para automatización

Se combinan bien: domain storytelling para entender casos, Event Storming para ver el conjunto, y C4 para documentar el sistema resultante.

Criterios de implementación

Reúne a quienes conocen y realizan el trabajo. Empieza con una historia concreta, no con todas las excepciones. Conserva preguntas abiertas y valida los límites descubiertos con más casos antes de decidir servicios, equipos o contratos.