Sådan laver du et beslutningsdiagram

Sådan laver du et beslutningsdiagram: skriv hver beslutning som et spørgsmål, gør udgangene udtømmende og gensidigt udelukkende, skriv kriterierne på, og giv hvert udfald en afslutning.

Et beslutningsdiagram kortlægger en række valg: hver beslutning er et spørgsmål, hver udgang er mærket med et svar, og svarene dækker tilsammen hvert eneste tilfælde præcis én gang.

Kort fortalt

  • Hver rude indeholder et spørgsmål, formuleret så læseren kan svare på det.
  • Udgangene er udtømmende og gensidigt udelukkende: hvert tilfælde matcher præcis én.
  • Kriterierne hører til på diagrammet, ikke i forfatterens hoved.
  • Foretræk to klare beslutninger efter hinanden frem for én med fem udgange.
  • Sortér spørgsmålene, så det billigste og mest udelukkende kommer først.

Hvad der gør et beslutningsdiagram brugbart under pres

Et beslutningsdiagram bliver læst af en, der skal vælge, som regel hurtigt og ofte uden den kontekst, forfatteren havde. Det er en sværere målgruppe, end et procesdiagram får. Det betyder, at spørgsmålene skal kunne besvares ud fra oplysninger, læseren rent faktisk har, at udgangene skal dække alle tilfælde, og at kriterierne ikke må bo i forfatterens hoved: »er den her kritisk?« er kun en beslutning, hvis diagrammet fortæller, hvad kritisk betyder.

Det tekniske krav er, at hver beslutnings udgange er udtømmende og gensidigt udelukkende: hvert tilfælde matcher præcis én vej. Udtømmende fejler, når læserens situation ikke står på listen, og læseren opfinder en vej. Udelukkende fejler, når to veje begge passer, og to læsere træffer forskellige valg ud fra det samme diagram, hvilket ligner uenighed i teamet, men i virkeligheden er en fejl i tegningen.

Eksemplet herunder er et forløb for bug triage, som består af beslutninger næsten hele vejen: kan fejlen reproduceres, er den anmeldt før, hvor alvorlig er den, blev rettelsen godkendt ved review, bestod den verifikationen. Seks beslutninger, hvoraf de fire kan sende sagen baglæns.

Seks beslutninger, én fejl

Bug triage fra rapport til lukning. Næsten hvert trin er et valg, og de fleste af dem kan sende sagen tilbage.

  1. Det billigste spørgsmål først

    Kan fejlen reproduceres? Intet længere nede i forløbet er værd at gøre, før det er besvaret, så det kommer først. At sortere beslutninger efter, hvor meget arbejde de fjerner, er den enkeltforbedring, der betyder mest i et triage-diagram.

  2. Giv blindgyderne rigtige afslutninger

    Intet svar fra anmelderen lukker sagen som »kan ikke reproduceres«; en dublet knyttes til originalen og lukkes. Begge dele er legitime udfald med hver deres slutpunkt: et triage-diagram, der kun ender i »rettet«, beskriver ikke triage.

  3. Rutér efter alvorlighed, og skriv hvad alvorlighed betyder

    Kritisk udløser en produktionshændelse og springer backloggen over; standard går til det ansvarlige team. Skriv definitionen af kritisk ved siden af beslutningen, ellers vil to personer triagere den samme fejl forskelligt, og begge vil kunne sige, at de fulgte diagrammet.

  4. Beslutninger, der løber baglæns

    Code review og verifikation sender begge fejl tilbage til udvikling, og en mislykket verifikation genåbner sagen i stedet for at lukke den. Sløjferne er det, der gør et beslutningsdiagram ærligt om, hvor meget omarbejde der er.

Sådan fungerer det

  1. Skriv spørgsmålene ned, før du skriver svarene

    Notér hvert valg, processen indeholder, som spørgsmål. Sortér dem derefter efter, hvor meget arbejde hvert enkelt fjerner: det spørgsmål, der lukker flest sager med mindst indsats, kommer først. Triage-diagrammer, der stiller det dyre spørgsmål først, spilder netop den indsats, de blev bygget for at spare.

  2. Gør hvert spørgsmål besvarligt

    Tjek, at læseren kan svare ud fra det, vedkommende har foran sig. »Er det en dublet?« virker, hvis der findes et søgbart fejlsystem; »er det et kendt problem?« gør ikke, medmindre diagrammet fortæller, hvor kendte problemer er skrevet ned.

  3. Skriv kriterierne på selve beslutningen

    Læg grænsen i trinnets kommentarfelt: hvad der gør en fejl kritisk, hvad der tæller som tilstrækkelig dokumentation, hvilket beløb der udløser den ekstra godkendelse. En beslutning uden nedskrevne kriterier giver ensartede diagrammer og uensartede beslutninger.

  4. Tjek at udgangene dækker alle tilfælde (én gang)

    Spørg for hver beslutning, om der findes en situation, der ikke passer på nogen af udgangene, og om der findes en, der passer på to. Begge dele er fejl. Tredelte beslutninger er helt fine (standard, normal, akut), så længe hvert tilfælde lander præcis ét sted.

  5. Tegn sløjferne ærligt

    Fejlet review, fejlet verifikation, genåbnet efter lukning: hver af dem går tilbage i forløbet ved et bestemt trin. At lade som om arbejdet er lineært, er måden, hvorpå estimater ender med at beskrive en proces, ingen nogensinde har oplevet.

  6. Test det på virkelige sager

    Tag ti sager, der løb gennem processen i sidste måned, og før hver af dem gennem diagrammet. De sager, der ikke passer, fortæller dig om en manglende udgang eller om et kriterium, der kun findes i nogens personlige vurdering.

Faldgruber du skal undgå

  • Uklare kriterier

    »Alvorlig«, »hastende«, »væsentlig«: hver læser leverer sin egen grænse, og diagrammet giver udseendet af standardisering uden noget af indholdet.

  • Overlappende udgange

    Hvis en sag med rimelighed kan tage to veje, vil to personer rutere den forskelligt, og begge vil have ret. Gør opdelingen gensidigt udelukkende.

  • En beslutning med kun én udgang

    Er der kun tegnet én vej, er det ikke en beslutning. Tegn enten det andet udfald, eller gør trinnet til et almindeligt procestrin.

  • Fem beslutninger i dybden

    Lange beslutningskæder er svære at følge og endnu sværere at ændre. Hvor træet reelt er bredt, er en beslutningstabel ved siden af diagrammet som regel klarere end flere ruder.

Lav dit eget beslutningsdiagram

Åbn eksemplet med bug triage som dit eget diagram, og udskift derefter spørgsmålene med de beslutninger, jeres team faktisk træffer.

Lav dit eget beslutningsdiagram

Relaterede guides

Ofte stillede spørgsmål

Hvad er et beslutningsdiagram?

Et flowchart, hvis struktur er domineret af beslutningspunkter frem for sekventielt arbejde: hver rude stiller et spørgsmål, og hver mærket udgang fører til en anden handling. Triage, egnethedstjek, eskaleringsregler og godkendelsesruter er alle beslutningsdiagrammer. Det designkrav, der adskiller dem, er, at udgangene fra hver beslutning skal dække hvert tilfælde præcis én gang, så enhver læser, der følger diagrammet, når frem til det samme udfald.

Kan en beslutning have mere end to udfald?

Ja, så længe udfaldene er udtømmende og gensidigt udelukkende. En ændringsanmodning, der deler sig i standard, normal og akut, er en ren tredelt beslutning. Det, der giver problemer, er en beslutning med fem eller seks udgange, som næsten altid viser sig at være to beslutninger i én rude: deler man den i to, bliver begge lettere at besvare og langt lettere at ændre senere.

Hvor skal beslutningskriterierne stå?

På selve beslutningen, ikke i et bilag. I QueryChart har hvert trin et kommentarfelt, og det er dér, grænsen, definitionen eller henvisningen til politikken hører hjemme. Kriterier, der ligger i et separat dokument, bliver slået op én gang, husket omtrentligt og anvendt uensartet, hvilket underminerer hele formålet med at dokumentere beslutningen.

Hvordan viser jeg en beslutning, der løber tilbage?

Peg udgangen på rækkenummeret for det trin, den vender tilbage til. Et fejlet code review, der går tilbage til udvikling, eller en fejlet verifikation, der genåbner fejlen, er begge én enkelt forbindelse tilbage til midten af diagrammet. Sløjfer er normale, og at tegne dem er det, der gør et beslutningsdiagram ærligt om, hvor meget omarbejde processen reelt indeholder.

Skabelonen bag denne guide

Flowchart for bug triage-processen — Flowchart for bug triage: modtagelse af fejlrapporter, reproduktion, dublettjek, alvorlighed og prioritet, eskalering, rettelse, code review, QA-verifikation og release til produktion.

Browse all Vejledninger til rutediagram og proceskortlægning