Beslutningslog: skabelon til dit team

En beslutningslog for teamet gør det muligt at svare på, hvorfor en mulighed blev valgt, og hvad der skulle ændre sig for at revidere den. Den er nødvendig, når nogen arbejder med en gammel beslutning, en anden husker en undtagelse, og ingen kan finde den oprindelige årsag. Den sidste sætning i chatten indeholder sjældent al den information.

I et bureau (på engelsk) kan loggen være et delt dokument med et kort for hver beslutning og et indeks. Nytten opstår ved at bevare konteksten, skelne mellem det verificerede og det antagne, og ved at linke en ny beslutning til den, den erstatter. Her er en skabelon og et komplet eksempel på, hvordan man gør det.

Registrer beslutninger, der ændrer arbejde

Opret et kort, når valget påvirker flere personers arbejde, afhænger af en betydelig usikkerhed, eller ville være dyrt at rekonstruere. At vælge en fælles leveringsmetode fortjener registrering; at rette en slåfejl kan forblive i opgaven. Dokumentet skal gemme en beslutning, som nogen vil skulle forstå senere.

Formuler et spørgsmål, der kan lukkes: «Hvilket format skal vi bruge til at præsentere workshoppen i kundens lokale?». «Forbedre præsentationer» identificerer ikke en beslutning. Tilføj, hvad der er udelukket: indhold, antal sessioner eller materialer til deltagere, i henhold til hvad der allerede er aftalt i arbejdets omfang i tilbuddet (på engelsk).

Adskil evidens og antagelser. «Den person, der koordinerer workshoppen, bad om at kunne rette slides indtil dagen før» beskriver en besked. «Computeren i lokalet vil kunne åbne den redigerbare fil» er stadig uafklaret, indtil det er verificeret. At være enig i en antagelse gør den ikke til et faktum.

Gør det klart, hvem der forbereder, og hvem der beslutter

Den person, der indsamler informationen, kan være forskellig fra den, der har det endelige ansvar for at beslutte. Atlassians DACI-tilgang adskiller disse roller, udover dem der bidrager med viden, og dem der skal modtage resultatet. Du kan bevare den skelnen på et lille kort.

Noter, hvem der har ansvaret for beslutningen, hvem der skal fremskaffe evidens, og hvem resultatet påvirker. Bekræft denne tildeling; at sætte et navn i en celle giver ikke beslutningsret eller beviser accept. Hvis der er behov for et eksternt svar, lad det være en afventende afhængighed.

Valgmuligheder kræver konkrete konsekvenser. «Brug den redigerbare fil», «præsenter en PDF» og «udskyd valget, indtil lokalet er testet» gør det muligt at sammenligne, hvad der vindes, hvad der mangler, og hvad der kan blokere arbejdet. Tilføj ikke muligheder, som ingen overvejede, blot for at retfærdiggøre den foretrukne efterfølgende.

En skabelon med to separate tilstande

Kopiér kortet og erstat teksten i klammerne. Brug korte referencer som DEC-01 og DEC-02, både i indekset og i opgaverne. Identifikatorerne er interne eksempler; de kræver ikke et specifikt værktøj. Link til evidens, der er tilgængelig for teamet, uden at kopiere legitimationsoplysninger eller unødvendig information.

Reference og spørgsmål: [identifikator / konkret beslutning]
Omfang: [påvirket arbejde / hvad der er udelukket]
Forberedelse: [person der indsamler information]
Beslutningsansvarlig: [person / bekræftet tildeling]
Bidragydere og modtagere: [hvem bidrager / hvem skal vide det]
Evidens: [faktum / reference / verificeringsdato]
Antagelser: [hvad der mangler at verificere / ansvarlig / konsekvens]
Muligheder: [reelle alternativer og konsekvenser af hver]
Resultat: [valgt mulighed og årsag; eller afventende]
Beslutning: [foreslået / vedtaget / forkastet / erstattet]
Bekræftelse: [person / dato / reference; eller afventende]
Anvendelse: [siden hvornår / nødvendig betingelse]
Revision: [betingelse der udløser den / dato / ansvarlig]
Historik: [erstatter / erstattet af / dateret note]
Udførelse: [afventende / i gang / blokeret / verificeret]
Næste handling: [opgave / ansvarlig / dato eller betingelse]
Verifikation: [forventet resultat / evidens / ansvarlig]

Vedtaget betyder, at der eksisterer en bekræftet beslutning. Verificeret betyder, at udførelsen er kontrolleret med den forventede evidens. En forkastet beslutning skal ikke bevæge sig mod udførelse. Hvis beslutningen udskydes, bevar «foreslået», skriv hvad der mangler, og hvem der vil løse det; tavshed fuldfører ikke bekræftelsen.

Eksempel: evidens ændrer sig, beslutning ændrer sig

Fiktivt eksempel. Et bureau forbereder en workshop. Referencenavne, dage og følgende resultater er didaktiske; de beskriver ikke en reel kunde. Indholdet af workshoppen er aftalt. Det mangler at beslutte, hvilken fil der skal bruges under præsentationen.

DEC-02 er allerede vedtaget, men tillader stadig ikke at skrive «præsentation verificeret». Den næste handling består i at åbne den endelige PDF på lokalets udstyr og gennemgå de forventede slides. Hvis workshoppen afhænger af en animation, der forsvinder ved eksport, skal testen opdage det, før formatet erklæres gyldigt.

Ideen om at bevare ræsonnementet stammer fra de arkitekturbeslutningsregistre, eller ADR’er, beskrevet af AWS: en ny beslutning kan erstatte en tidligere. Her tilpasser vi den til serviceoperationer; vi anvender ikke en arkitekturnorm på workshoppen.

Bevar de fakta og årsager, der er skrevet i DEC-01, intakte. Tilføj erstatningsnoten med dato og link til DEC-02. Den, der læser historikken, vil kunne skelne en rimelig beslutning under en eksplicit antagelse fra en fejl, der er skjult gennem en retrospektiv redigering.

Revider ud fra en konkret betingelse

«Vi gennemgår det senere» forklarer ikke, hvad nogen skal observere. En mislykket test, en afhængighed, der ændrer sig, eller et nyt krav tillader derimod at åbne for revisionen. Tildel, hvem der følger den betingelse, og en dato for at verificere den, hvis arbejdet har en deadline.

Datoen tilbagekalder ikke automatisk beslutningen. Hvis der ikke dukker ny information op, registrer da, om den stadig er gældende, og hvilken verifikation der mangler. Når fortsættelse afhænger af en uopfyldt betingelse, bevar da blokeringen. I eksemplet autoriserede accept af DEC-01 ikke at undlade at teste udstyret.

At rette en slåfejl kræver ikke DEC-03. At ændre det valgte format eller dets brugsbetingelse fortjener derimod en anden reference. Hvis du opdager, at evidens var forkert noteret, tilføj da en dateret korrektion og gennemgå dens konsekvenser; lad ikke loggen fortsat understøtte en fejlagtig oplysning.

Kontroller, at en anden person kan fortsætte

Oprethold et indeks med reference, spørgsmål, gældende beslutning og link til historikken. I udførelsesopgaven, angiv hvilken beslutning der gælder. Hvis den ændrer sig, giv besked til de berørte personer og kontroller, at den, der har arbejde ventende, har modtaget den nye reference. At redigere dokumentet garanterer ikke, at alle har læst det.

Bed en person, der ikke deltog i samtalen, om at finde tre ting: hvad der skal gøres nu, hvorfor det ændrede sig, og hvad der stadig er afventende. Hvis vedkommende skal spørge dig, ret kortet. Hvis der er en overflødig vedligeholdelsesopgave, anvend da princippet om at eliminere, automatisere og delegere (på engelsk), før du opretter en ny rutine.

Start med en gældende beslutning, hvis årsag er svær at genfinde. Skriv det kendte, markér hvad der stadig er en antagelse, og efterlad en næste handling med ansvarlig. Den næste person skal kunne fortsætte derfra.