Convertir una fricción en una solución concreta.

#Hipótesis

Todo diseño empieza con una apuesta escrita que se puede perder. Si no se puede perder, no es una hipótesis, es un deseo.

Creemos que   [la solución]
para          [las personas del proceso]
logrará       [el cambio en su trabajo].
Sabremos que funciona cuando  [la métrica]
pase de       [línea base]  a  [meta]
medida        [fuente y periodo].

Creemos que   rutas de aprobación calculadas por reglas, con bandeja y vencimientos,
para          solicitantes y aprobadores de compras,
logrará       que nadie tenga que perseguir una aprobación.
Sabremos que funciona cuando  el tiempo de solicitud a orden emitida
pase de       2.9 días hábiles (mediana)  a  1 día hábil o menos
medida        con las fechas del sistema, sobre todas las solicitudes del mes.

Una hipótesis por pieza. Si hay dos resultados distintos, son dos piezas.

#Apetito

Antes de diseñar en detalle se decide cuánto vale resolver la fricción: cuánto esfuerzo estamos dispuestos a invertir. Es una restricción de diseño, no una estimación. Con el apetito fijo, lo que varía es el alcance: el diseño busca la versión que cabe.

• El apetito sale del costo de la fricción. No se invierte más de lo que la fricción cuesta en un plazo razonable.
• Si el diseño no cabe, se recorta alcance o se baja un peldaño en la escalera de solución. No se estira el apetito sin decidirlo en una compuerta.
• Se nombran los fuera de alcance (lo que no se hará, aunque alguien lo pida) y los hoyos: partes donde el esfuerzo puede crecer sin control, como una integración desconocida o datos sucios. Cada hoyo se resuelve en el diseño o se saca del alcance.

#Proceso futuro

Se dibuja el mismo mapa de carriles del descubrimiento, ahora como debería funcionar. Se compara paso por paso: qué desaparece, qué hace el sistema y qué sigue siendo una decisión de una persona.

El conteo del proceso futuro se pone junto al de hoy en la ficha de sistema. Es la promesa que la medición va a comprobar.

#Lenguaje y dominio

El sistema usa las palabras del cliente, en la interfaz y en el código. Se arma un glosario con el dueño del proceso: cada término con su definición y un ejemplo. Si en el código la entidad se llama distinto que en la operación, alguien va a traducir mal.

• Un término, un significado. Si “proveedor” significa algo distinto para Compras que para Cuentas por pagar, son dos contextos y se nombran por separado.
• Límites de contexto. Cada parte del sistema tiene un modelo coherente. Donde dos contextos se tocan (nuestra pieza y el ERP) se define qué se traduce y en qué dirección.
• Eventos del dominio, en pasado: “Solicitud creada”, “Ruta calculada”, “Aprobada por Finanzas”, “Orden emitida”. Son la base de la bitácora y de la medición.

#Estados

Toda entidad que avanza tiene una lista cerrada de estados y de transiciones permitidas. Escribirla evita casos imposibles y define qué se puede medir.

La transición “Pedir cambios” es la que mide el re-trabajo: cuántas veces regresa una solicitud es el % completo y correcto del paso anterior.

#Reglas: tablas de decisión

Las reglas escritas en el descubrimiento se convierten en tablas de decisión, el formato del estándar DMN. Cada fila es una regla: condiciones de entrada y una salida. El cliente puede leerla y aprobarla sin leer código, y el código la implementa casi sin traducción.

Las reglas del motor de la demo de Aprobaciones (lib/demos/approvals.ts). La política de aciertos dice qué pasa cuando varias filas aplican. Aquí aplican todas las que se cumplen y la ruta se ordena por área: en DMN se llama output order. Otras políticas comunes: unique (solo puede aplicar una), first (gana la primera que se cumpla) y collect (se juntan todas).

• Los umbrales son datos, no código. El dueño del proceso los cambia sin pedir un desarrollo.
• Cada regla tiene identificador. El sistema muestra cuál aplicó y por qué (“$25,000 vs $20,000”).
• De cada fila salen casos de prueba: uno justo en el umbral, uno arriba y uno abajo.
• Se revisa que no haya huecos (combinaciones sin regla) ni contradicciones.
• Una regla con “o” se parte en dos filas, como R6 en la demo: así cada fila se lee y se prueba sola.

#Pantallas

Las pantallas se diseñan desde la decisión que la persona toma en ellas, no desde los campos de la base de datos. Se baja el nivel de detalle en tres pasos:

1. Esquema de flujo: lugares (pantallas o vistas), lo que se puede hacer en cada uno (botones, campos) y a dónde lleva cada acción. Sin diseño visual. Sirve para discutir el flujo sin distraerse con colores.
2. Bocetos gruesos: dibujos con plumón grueso que no permiten detalle. Muestran qué es protagonista en cada vista.
3. Prototipo: ya con el lenguaje de Naoro y datos de ejemplo creíbles (ver Prototipo).

Reglas de la casa que aplican desde aquí: un protagonista por vista y como mucho dos piezas de apoyo, la lógica visible (“por qué está esta solicitud en tu bandeja”), controles propios y el Signal solo para lo que pide atención, como un vencimiento.

#Datos e integraciones

Por cada dato que la pieza usa o produce, se decide:

Antes de comprometer una integración se revisa la calidad de los datos de los que depende. Una integración perfecta con datos malos solo mueve el problema más rápido.

• Completitud: ¿están todos los registros y campos necesarios?
• Exactitud: ¿el dato corresponde a la realidad?
• Oportunidad: ¿está disponible cuando se necesita?
• Consistencia: ¿dice lo mismo en todos los sistemas?
• Validez y unicidad: ¿cumple el formato? ¿hay duplicados (el mismo proveedor dos veces)?

#Riesgos: pre-mortem

Antes de cerrar el diseño, el equipo imagina que ya pasó el tiempo y el proyecto fracasó. Cada persona escribe por su cuenta por qué fracasó. Se juntan las razones y se ajusta el diseño. Funciona porque imaginar un fracaso ya ocurrido hace más fácil encontrar sus causas que preguntar qué podría salir mal.

Las razones que más aparecen en nuestros proyectos, para revisar siempre:

• La gente sigue usando el canal viejo porque es más rápido para ellos.
• La integración con el ERP no permite escribir, o solo con un proveedor externo.
• Los datos maestros (proveedores, centros de costo) están sucios.
• Hay excepciones frecuentes que las reglas no cubren.
• El dueño del proceso cambia de puesto o pierde interés.
• Permisos: alguien ve lo que no debería, o no puede hacer lo que le toca.

#Mapa de historias

Convierte el proceso futuro en algo construible. A lo ancho, las actividades del proceso en orden (pedir, aprobar, emitir, consultar). Debajo de cada una, lo que la persona necesita hacer, de lo indispensable a lo deseable. Una línea horizontal marca la primera rebanada: la versión más delgada que funciona de punta a punta.

PEDIR                 APROBAR                    EMITIR                 CONSULTAR
───────────────────────────────────────────────────────────────────────────────────
Crear solicitud       Ver mi bandeja             Orden en el ERP        Estado de mi solicitud
Adjuntar cotización   Aprobar / rechazar         Aviso al solicitante   Por qué pasó por cada área
                      Pedir cambios
─────────────────────────── primera rebanada ──────────────────────────────────────
Plantillas frecuentes Delegar en ausencia        Varias órdenes         Tablero por área
Solicitud desde móvil Recordatorio automático    por solicitud          Exportar a Excel

#Ficha de sistema

Es el entregable del diseño. Una por pieza. La aprueba el dueño del proceso y se mantiene viva durante construcción y operación.

1. Fricciones que resuelve (con sus identificadores) e hipótesis.
2. Apetito, fuera de alcance y hoyos resueltos.
3. Proceso hoy contra proceso futuro, con el conteo de ambos.
4. Glosario y estados.
5. Tablas de decisión, con su política de aciertos.
6. Esquema de pantallas.
7. Mapa de datos e integraciones, con la revisión de calidad.
8. Roles y permisos.
9. Métrica principal, métricas de guarda, línea base y meta.
10. Riesgos del pre-mortem y qué se hizo con cada uno.
11. Mapa de historias con la primera rebanada marcada.

#Errores comunes

• Diseñar solo para el caso feliz. Las excepciones del descubrimiento tienen que tener un lugar.
• Pasar el Excel a la web. Se digitaliza el problema en vez de resolverlo.
• Agregar funciones “ya que estamos”. Todo lo que no se rastrea a una fricción sale.
• Dejar reglas implícitas en el código o en la cabeza del desarrollador.
• Olvidar quién se entera de cada cambio de estado.
• Comprometer una integración sin haber visto la API ni los datos reales.