Cómo hacer un diagrama de flujo de decisiones
Cómo hacer un diagrama de flujo de decisiones: escribe cada decisión como una pregunta, haz que las salidas sean exhaustivas y excluyentes, deja los criterios por escrito y cierra cada resultado.
Un diagrama de flujo de decisiones traza una secuencia de elecciones: cada decisión es una pregunta, cada salida lleva la etiqueta de una respuesta y entre todas cubren cada caso exactamente una vez.
En resumen
- Cada rombo contiene una pregunta, formulada para que el lector pueda responderla.
- Las salidas son exhaustivas y excluyentes: cada caso encaja en una sola.
- Los criterios van en el diagrama, no en la cabeza de quien lo escribió.
- Mejor dos decisiones claras seguidas que una con cinco salidas.
- Ordena las preguntas para que la más barata y la que más descarta vaya primero.
Qué hace que un diagrama de decisiones sirva bajo presión
Un diagrama de flujo de decisiones lo lee alguien que tiene que elegir, normalmente deprisa y muchas veces sin el contexto que tenía quien lo escribió. Es un público más exigente que el de un mapa de procesos. Eso significa que las preguntas deben poder responderse con la información que el lector tiene delante, que las salidas tienen que cubrir todos los casos y que los criterios no pueden vivir en la cabeza del autor: «¿esto es crítico?» solo es una decisión si el diagrama dice qué significa crítico.
El requisito técnico es que las salidas de cada decisión sean exhaustivas y mutuamente excluyentes: cada caso encaja en una sola ruta. La exhaustividad falla cuando la situación del lector no aparece y este se inventa un camino. La exclusividad falla cuando dos rutas son válidas a la vez y dos lectores deciden distinto con el mismo diagrama, lo que parece una falta de criterio del equipo y en realidad es un defecto del diagrama.
El ejemplo de abajo es un flujo de triaje de bugs, que es prácticamente decisiones de principio a fin: si se puede reproducir, si ya se había reportado, qué gravedad tiene, si la corrección pasó la revisión, si superó la verificación. Seis decisiones, y cuatro de ellas pueden devolver el caso hacia atrás.
Seis decisiones, un defecto
Triaje de bugs desde el reporte hasta el cierre. Casi cada paso es una elección y la mayoría pueden devolver el caso hacia atrás.
Primero la pregunta más barata
¿Se reproduce el defecto? Nada de lo que viene después merece la pena hasta responder a eso, así que va primero. Ordenar las decisiones por la cantidad de trabajo que eliminan es la mejora aislada que más rinde en un diagrama de triaje.
Da finales de verdad a los callejones sin salida
Si quien reporta no responde, el caso se cierra como no reproducible; si es un duplicado, se enlaza y se cierra. Ambos son resultados legítimos con su propio terminador: un diagrama de triaje que solo termina en «corregido» no describe un triaje.
Enruta por severidad, y di qué significa severidad
Crítico abre una incidencia de producción y se salta el backlog; estándar va al equipo propietario. Escribe la definición de crítico junto a la decisión o dos personas triarán el mismo defecto de forma distinta, y ambas podrán decir que siguieron el diagrama.
Decisiones que vuelven hacia atrás
La revisión de código y la verificación devuelven los fallos a desarrollo, y una verificación no superada reabre el caso en lugar de cerrarlo. Los bucles son lo que hace que un diagrama de decisiones sea honesto sobre el retrabajo.
Cómo funciona
Enumera las preguntas antes que las respuestas
Apunta como preguntas todas las elecciones que contiene el proceso. Después ordénalas por la cantidad de trabajo que elimina cada una: la que cierra más casos con menos esfuerzo va primero. Los diagramas de triaje que hacen antes la pregunta cara desperdician justo el esfuerzo que venían a ahorrar.
Haz que cada pregunta se pueda responder
Comprueba que el lector puede contestarla con lo que tiene delante. «¿Es un duplicado?» funciona si hay un tracker con buscador; «¿es un problema conocido?» no funciona, salvo que el diagrama diga dónde se listan los problemas conocidos.
Escribe los criterios sobre la propia decisión
Pon el umbral en el comentario del paso: qué hace que un defecto sea crítico, qué cuenta como evidencia suficiente, qué importe dispara la aprobación adicional. Una decisión sin criterios escritos produce diagramas de aspecto uniforme y decisiones dispares.
Comprueba que las salidas cubren cada caso una sola vez
Para cada decisión, pregúntate si existe una situación que no encaje en ninguna salida y si existe alguna que encaje en dos. Ambas cosas son defectos. Las bifurcaciones a tres bandas están bien (estándar, normal, emergencia) siempre que cada caso caiga en una sola.
Dibuja los bucles con honestidad
Revisión no superada, verificación fallida, caso reabierto después de cerrarse: cada uno vuelve al flujo por un paso concreto. Fingir que el trabajo es lineal es la forma de que las estimaciones acaben describiendo un proceso que nadie ha vivido nunca.
Pruébalo con casos reales
Coge diez casos que pasaron por el proceso el mes pasado y recorre el diagrama con cada uno. Los que no encajen te están señalando una salida que falta o un criterio que solo existe en el buen juicio de alguien.
Errores que debes evitar
Criterios vagos
«Grave», «urgente», «significativo»: cada lector pone su propio umbral, y el diagrama entrega la apariencia de estandarización sin nada de estandarización.
Salidas que se solapan
Si un caso puede tomar legítimamente dos rutas, dos personas lo enrutarán de forma distinta y ambas tendrán razón. Haz que la bifurcación sea excluyente.
Una decisión con una sola salida
Si solo hay una ruta dibujada, no es una decisión. O dibujas el otro resultado o lo conviertes en un paso de proceso.
Anidar cinco decisiones
Las cadenas largas de decisiones son difíciles de seguir y más difíciles todavía de cambiar. Cuando el árbol es realmente ancho, una tabla de decisión junto al diagrama suele ser más clara que añadir más rombos.
Crea tu propio diagrama de flujo de decisiones
Abre el ejemplo de triaje de bugs como diagrama propio y sustituye las preguntas por las decisiones que tu equipo toma de verdad.
Guías relacionadas
Preguntas frecuentes
¿Qué es un diagrama de flujo de decisiones?
Un diagrama de flujo cuya estructura está dominada por puntos de decisión más que por actividad secuencial: cada rombo plantea una pregunta y cada salida etiquetada lleva a un curso de acción distinto. El triaje, las comprobaciones de elegibilidad, las reglas de escalado y el enrutado de aprobaciones son todos diagramas de decisiones. La restricción de diseño que los distingue es que las salidas de cada decisión deben cubrir cada caso exactamente una vez, para que cualquier lector que siga el diagrama llegue al mismo resultado.
¿Una decisión puede tener más de dos resultados?
Sí, siempre que los resultados sean exhaustivos y mutuamente excluyentes. Una solicitud de cambio que se divide en estándar, normal y de emergencia es una decisión a tres bandas impecable. Lo que da problemas es una decisión con cinco o seis salidas, que casi siempre resulta ser dos decisiones metidas en un mismo rombo: separarlas hace ambas más fáciles de responder y mucho más fáciles de cambiar después.
¿Dónde deben escribirse los criterios de decisión?
Sobre la propia decisión, no en un anexo. En QueryChart cada paso lleva un campo de comentario, y ahí es donde van el umbral, la definición o la referencia a la política. Los criterios guardados en un documento aparte se consultan una vez, se recuerdan de forma aproximada y se aplican de manera desigual, lo que anula el sentido mismo de documentar la decisión.
¿Cómo represento una decisión que vuelve hacia atrás?
Apunta la salida al número de fila del paso al que regresa. Una revisión de código no superada que vuelve a desarrollo, o una verificación fallida que reabre el defecto, son en ambos casos una única conexión de vuelta al centro del diagrama. Los bucles son normales, y dibujarlos es lo que hace que un diagrama de decisiones sea honesto sobre cuánto retrabajo contiene realmente el proceso.