Beslutningslogg: mal for teamet ditt

En beslutningslogg for teamet gjør det mulig å svare på hvorfor et alternativ ble valgt og hva som måtte endres for å revidere det. Det er nødvendig når noen jobber med en gammel beslutning, en annen person husker et unntak, og ingen finner den opprinnelige årsaken. Den siste setningen i chatten inneholder sjelden all denne informasjonen.

I et byrå (på engelsk) kan loggen være et delt dokument med et kort per beslutning og en indeks. Nytten viser seg ved å bevare konteksten, skille det verifiserte fra det antatte, og lenke en ny beslutning til den den erstatter. Her er en mal og et komplett eksempel for å gjøre dette.

Registrer beslutningene som endrer arbeid

Åpne et kort når valget påvirker arbeidet til flere personer, avhenger av en viktig usikkerhet eller ville være kostbart å rekonstruere. Å velge en delt leveringsmetode fortjener registrering; en skrivefeil kan korrigeres i den tilsvarende oppgaven. Dokumentet skal lagre en beslutning som noen vil trenge å forstå senere.

Formuler et spørsmål som kan lukkes: «Hvilket format skal vi bruke for å presentere workshopen i kundens rom?». «Forbedre presentasjonene» identifiserer ikke en beslutning. Legg til hva som er utenfor: innhold, antall økter eller materiale for deltakerne, i henhold til hva som allerede er avtalt i beskrivelsen av arbeidet i tilbudet (på engelsk).

Skill bevis og antakelser. «Personen som koordinerer workshopen ba om å kunne korrigere lysbildene frem til dagen før» beskriver en melding. «Rommets datamaskin vil kunne åpne den redigerbare filen» er fortsatt ventende til det er sjekket. Å være enig i en antakelse gjør den ikke til et faktum.

Gjør det klart hvem som forbereder og hvem som bestemmer

Personen som samler inn informasjonen kan være en annen enn den som har det endelige ansvaret for å bestemme. Atlassians DACI-rammeverk skiller disse rollene, i tillegg til de som bidrar med kunnskap og de som skal motta resultatet. Du kan opprettholde dette skillet på et lite kort.

Skriv ned en person som er ansvarlig for å bestemme, hvem som skal bidra med bevis, og hvem resultatet påvirker. Bekreft denne tildelingen; å sette et navn i en celle gir ikke autoritet eller beviser at det er akseptert. Hvis et eksternt svar er nødvendig, la det stå som en ventende avhengighet.

Alternativene trenger konkrete konsekvenser. «Bruke den redigerbare», «presentere en PDF» og «utsette valget til rommet er testet» gjør det mulig å sammenligne hva som vinnes, hva som er ventende og hva som kan blokkere arbeidet. Ikke legg til alternativer som ingen vurderte bare for å rettferdiggjøre det foretrukne senere.

En mal med to separate tilstander

Kopier skjemaet og erstatt teksten i hakeparentesene. Bruk korte referanser som DEC-01 og DEC-02, både i indeksen og i oppgavene. Identifikatorene er interne eksempler; de krever ikke et spesifikt verktøy. Lenk til bevis som er tilgjengelig for teamet uten å kopiere innloggingsopplysninger eller unødvendig informasjon.

Referanse og spørsmål: [identifikator / konkret beslutning]
Omfang: [påvirket arbeid / hva som er utenfor]
Forberedelse: [person som samler informasjon]
Ansvarlig for å bestemme: [person / bekreftet tildeling]
Bidrag og mottakere: [hvem bidrar / hvem må vite det]
Bevis: [faktum / referanse / sjekkdato]
Antakelser: [hva som mangler å sjekke / ansvarlig / konsekvens]
Alternativer: [reelle alternativer og konsekvenser av hvert]
Resultat: [valgt alternativ og årsak; eller ventende]
Beslutning: [foreslått / vedtatt / forkastet / erstattet]
Bekreftelse: [person / dato / referanse; eller ventende]
Anvendelse: [fra når / nødvendig betingelse]
Revisjon: [betingelse som utløser den / dato / ansvarlig]
Historikk: [erstatter / erstattet av / datert merknad]
Utførelse: [ventende / pågående / blokkert / verifisert]
Neste handling: [oppgave / ansvarlig / dato eller betingelse]
Verifisering: [forventet resultat / bevis / ansvarlig]

Vedtatt betyr at det finnes en bekreftet beslutning. Verifisert betyr at utførelsen er kontrollert med forventet bevis. En forkastet beslutning skal ikke gå videre mot utførelse. Hvis beslutningen utsettes, behold «foreslått», skriv ned hva som mangler og hvem som skal løse det; stillhet er ikke en bekreftelse.

Eksempel: bevis endres, beslutning endres

Fiktiv sak. Et byrå forbereder en workshop. Referansenavnene, dagene og de etterfølgende resultatene er didaktiske; de beskriver ikke en ekte kunde. Innholdet i workshopen er avtalt. Det gjenstår å bestemme hvilken fil som skal brukes under presentasjonen.

DEC-02 er allerede vedtatt, men tillater ennå ikke å skrive «presentasjon verifisert». Neste handling består i å åpne den endelige PDF-en på rommets utstyr og kontrollere de forventede lysbildene. Hvis workshopen avhenger av en animasjon som forsvinner ved eksport, må testen oppdage dette før formatet erklæres gyldig.

Ideen om å bevare begrunnelsen kommer fra arkitektur-beslutningslogger, eller ADR, beskrevet av AWS: en ny beslutning kan erstatte en tidligere. Her tilpasser vi den til tjenesteoperasjoner; vi bruker ikke en arkitektonisk norm på workshopen.

Hold fakta og årsaker skrevet i DEC-01 intakte. Legg til den daterte erstatningsmerknaden med lenke til DEC-02. Den som leser historikken vil kunne skille en rimelig beslutning under en eksplisitt antakelse fra en feil skjult via en retrospektiv redigering.

Revider basert på en konkret betingelse

«Vi vil revidere det senere» forklarer ikke hva noen skal observere. En mislykket test, en avhengighet som endres eller et nytt krav gjør det mulig å åpne revisjonen. Tildel hvem som følger denne betingelsen og en dato for å sjekke den hvis arbeidet har en tidsfrist.

Datoen trekker ikke automatisk tilbake beslutningen. Hvis ingen ny informasjon dukker opp, registrer om den fortsatt er anvendelig og hvilke bevis som mangler. Når fortsettelse krever en betingelse som ikke er oppfylt, bevar blokkeringen. I eksemplet autoriserte ikke godkjenning av DEC-01 å utelate testing av utstyret.

Å rette en skrivefeil krever ikke DEC-03. Å endre det valgte formatet eller betingelsen for å bruke det fortjener en annen referanse. Hvis du oppdager at et bevis var feil notert, legg til en datert korrigering og vurder konsekvensene; ikke la loggen fortsette å opprettholde en falsk sikkerhet.

Sjekk at en annen person kan fortsette

Oppretthold en indeks med referanse, spørsmål, gjeldende beslutning og lenke til historikken. I utførelsesoppgaven, angi hvilken beslutning som gjelder. Hvis den endres, varsle de berørte personene og sjekk at den som har ventende arbeid mottok den nye referansen. Å redigere dokumentet garanterer ikke at alle har lest det.

Be noen utenfor samtalen om å finne tre ting: hva som skal gjøres nå, hvorfor det endret seg, og hva som fortsatt er ventende. Hvis vedkommende må spørre deg, korriger skjemaet. Hvis det er en overflødig vedlikeholdsoppgave, anvend kriteriene for eliminere, automatisere og delegere (på engelsk) før du oppretter en ny rutine.

Start med en gjeldende beslutning hvis begrunnelse er vanskelig å finne igjen. Skriv ned det kjente, marker det som fortsatt er en antakelse og legg igjen en neste handling med ansvarlig. Neste person skal kunne fortsette derfra.