Go/no-go-beslutningsproces: beslutningstræ før release

Hvad er go/no-go-beslutningsproces: beslutningstræ før release?

En go/no-go-beslutning er ikke et trin i et workflow. Det er en vurdering. Når en release når frem til parathedsgaten, er arbejdet gjort; tilbage står at holde dokumentationen op mod kriterier, der er aftalt på forhånd, og sige højt og til referat, hvilket af de navngivne udfald der gælder. De fleste teams har spørgsmålene liggende et sted (i en tjekliste, en runbook, en tilbagevendende mødeindkaldelse), men de er sjældent skrevet som et træ. Derfor kan ingen se, hvilket svar der fører hvorhen, hvilket spørgsmål der er et hårdt stop, og hvilket der blot hæfter en betingelse på, eller hvem der reelt har ret til at svare på det enkelte spørgsmål.

Denne side er bevidst et beslutningstræ og ikke et procesdiagram. Et procesdiagram svarer på 'hvad sker der nu, og hvem gør det': opgaver i rækkefølge, overleveringer mellem teams, én hovedvej med undtagelser hængende ud fra den. Et beslutningstræ svarer på 'hvilken mulighed vælger vi, og hvem beslutter': en rygrad af spørgsmål, der hver kan besvares ud fra dokumentation, med grene navngivet efter svaret frem for efter den næste opgave, og med tydeligt adskilte slutpunkter. Vil I have hele forløbet omkring gaten (scope freeze, udvikling og test, staging og UAT, deployment, smoketest og overvågning), så brug flowchartet for software release-processen på /da/templates/software-release-proces. Denne side er nærbilledet af den ene beslutning, der ligger inde i det.

Træet herunder kører tolv spørgsmål fordelt på fire vurderingsfaser, og banerne navngiver, hvem der svarer, frem for at kortlægge afdelinger: Release manager, Udvikling og QA, Drift og support samt Ledelsessponsor. Det ender i seks forskellige udfald: go, go med navngivne betingelser, et begrænset go til en pilotgruppe, no-go fordi acceptkriterierne ikke var opfyldt, no-go med en ny dato, og afbrydelse. Det skyldes, at en gennemgang, der kun kan sige ja eller nej, tvinger enhver delvis parathed ind i et af to forkerte svar. De to no-go-udgange er bevidst adskilte: at falde på den første gate på uopfyldte kriterier er et andet fund end at klare kvaliteten og miste sit ændringsvindue.

Hvad dette flowchart dækker

I denne skabelon

• Fire baner efter beslutningsret frem for et afdelingskort (Release manager, Udvikling og QA, Drift og support samt Ledelsessponsor) fordelt på fire faser: Beslutningsgrundlag, Kvalitetsgate, Driftsgate og Beslutning og udfald.
• Grenen om acceptkriterier: 'Er alle acceptkriterier opfyldt?' svarer Opfyldt eller Mangler, og Mangler ledes videre til 'Kan manglerne dispenseres?', hvor Kan dispenseres registrerer dispensationen og dens ejer, før forløbet samles igen i kvalitetsgaten, mens Blokerende afslutter gennemgangen i sin egen udgang, 'No-go: acceptkriterier ikke opfyldt'.
• Grenen om fejltærskler: 'Er fejl inden for tærsklerne for alvorlighed?' svarer Inden for eller Over, hvor Over ledes til 'Er rettelse eller dispensation aftalt?', så en release over tærsklen kun fortsætter på en registreret aftale, ikke på optimisme.
• To parathedsspørgsmål, der tåler et delvist svar: 'Er afhængigheder og leverandører klar?' falder videre til 'Kan vi frigive uden dem?', og 'Er rollback testet med succes?' falder videre til 'Kan ændringen overhovedet rulles tilbage?', hvor et Nej er den eneste vej til afbrydelse frem for til en ny dato.
• Support og timing som hver sin hårde gate: 'Er support oplært og bemandet?' og 'Er ændringsvindue og kalender fri?' svarer direkte til no-go ved Ikke klar eller Konflikt, så driftsparathed holdes ude af udviklingsdiskussionen.
• Et afsluttende par beslutninger, der navngiver udfaldet: 'Er ledelsens godkendelse givet?' (Godkendt eller Tilbageholdt) og derefter 'Hvilket omfang godkendes?', der forgrener sig i Fuldt, Betinget og Kun pilot til tre separate slutpunkter ved siden af no-go- og afbrydelsesudgangene.

Hvornår du skal bruge skabelonen

• I holder en parathedsgennemgang før release, og kriterierne findes kun i hovederne på folk, så udfaldet afhænger af, hvem der er i lokalet, og hvordan ugen er gået.
• Jeres gennemgange ender altid i enten 'go' eller 'udskudt', og delvis parathed (en forsinket leverandør, en tynd supportvagt) har ingen anden landingsplads end et fuldt stop eller et uregistreret hasardspil.
• I skal have beslutningsretten på plads, før den næste release fremtvinger diskussionen: hvem må dispensere fra et acceptkriterium, hvem må acceptere en fejl over tærsklen, og hvis godkendelse er påkrævet.
• I skal dokumentere, hvordan ændringer godkendes, testes og frigives (til en audit eller et sikkerhedsspørgeskema fra en kunde) og skal kunne vise kriterierne og ikke kun godkendelsen.
• I holder en post mortem på en release, der aldrig burde være frigivet, og vil have diskussionen til at handle om, hvilket spørgsmål der blev sprunget over, frem for om at rekonstruere forløbet fra hukommelsen.

Sådan fungerer det

1. Omdøb banerne, så de matcher jeres reelle beslutningsret

   Erstat Release manager, Udvikling og QA, Drift og support samt Ledelsessponsor med de roller, der reelt sidder på svaret hos jer. Hold banerne til, hvem der svarer, ikke hvem der er involveret: hvis tre teams leverer dokumentation til ét spørgsmål, men én person afgør det, hører spørgsmålet hjemme i den beslutningstagers bane. Slå enhver bane sammen, hvor I ikke kan sætte navn på en konkret person eller rolle.

2. Skriv tærsklerne ned, før I får brug for dem

   Træet er kun så godt som sine tests. Ved 'Er fejl inden for tærsklerne for alvorlighed?' skal I notere grænsen pr. alvorlighedsgrad for det, der frigives, hvem der må tilsidesætte en overskridelse, og om optællingen inkluderer kendte fejl fra tidligere releases. Gør det samme ved 'Er alle acceptkriterier opfyldt?' ved at markere hvert kriterium som obligatorisk eller ønskeligt allerede ved scope freeze, så gaten ikke bliver genforhandlet på selve dagen.

3. Definér, hvad en testet rollback betyder

   'Er rollback testet med succes?' bør betyde afprøvet i et produktionslignende miljø, tidtaget, med en navngiven person, der kan udføre den, og et nedskrevet kriterium for at trække i håndtaget. Beskriv dataspørgsmålet eksplicit, for det er ofte en skema- eller migreringsændring, der gør svaret på 'Kan ændringen overhovedet rulles tilbage?' til Nej, og den gren er den eneste vej til afbrydelse.

4. Gør det betingede go og pilotudfaldet til noget reelt

   Et betinget go adskiller sig kun fra et almindeligt go, hvis hver betingelse har en navngiven ejer, en frist og en konsekvens, hvis den ikke holdes. Et pilot-go kræver, at kohorten er defineret, at eksponeringsprocenten eller kundelisten er skrevet ned, og at kriteriet for at udvide er aftalt. Notér begge dele i kommentarfeltet på 'Hvilket omfang godkendes?', så gennemgangen ikke kan slutte med et ukvalificeret nik.

5. Hold no-go og afbrydelse adskilt

   No-go betyder, at den samme release frigives senere, og kræver derfor en ny dato og en navngiven blokering, før mødet slutter. Afbrydelse betyder, at releasen trækkes, og at indholdet går tilbage til omarbejdning eller fornyet vurdering. Ved at holde dem som forskellige slutpunkter undgår I, at en reel afbrydelse bliver registreret som en fjorten dages udskydelse, der stille og roligt gentager sig.

6. Publicér det, og evaluer efter hver gate

   Del træet der, hvor gennemgangen faktisk foregår, sammen med dokumentationspakken, og få godkendelse fra de personer, banerne navngiver. Tjek efter hver release, om et spørgsmål blev besvaret uden dokumentation, og om der manglede et udfald, I havde brug for. Gem de tidligere versioner, så I kan vise, hvornår kriterierne blev ændret, og hvorfor.

Ofte stillede spørgsmål

Hvad er forskellen på et go/no-go-beslutningstræ og et procesdiagram for release?

Et procesdiagram for release svarer på 'hvad sker der nu, og hvem gør det'. Det viser opgaver i rækkefølge på tværs af swimlanes (scope freeze, build, test, deploy, overvågning) og behandler go/no-go-beslutningen som én node. Et beslutningstræ svarer på 'hvilken mulighed vælger vi, og hvem beslutter'. Rygraden er en kæde af spørgsmål frem for opgaver, grenene er navngivet efter svar som Opfyldt, Over, Kan dispenseres eller Tilbageholdt frem for efter den næste aktivitet, og det ender i flere forskellige udfald i stedet for at samle alt på én lykkelig sti. Brug begge: procesdiagrammet til hele forløbet, på /da/templates/software-release-proces, og dette træ til gaten inde i det.

Hvilke spørgsmål hører hjemme i en go/no-go-beslutning?

Syv dækker de fleste releases. Er alle obligatoriske acceptkriterier opfyldt? Er åbne fejl inden for de aftalte tærskler for alvorlighed? Er afhængigheder og tredjeparter klar? Er rollback testet, ikke bare beskrevet? Er support og drift oplært og bemandet til den forventede mængde? Er ændringsvinduet frit både i forretningskalenderen og i den tekniske kalender? Foreligger ledelsens godkendelse? Hvert spørgsmål skal kunne besvares ud fra dokumentation indsamlet før mødet, og derfor starter træet med en dokumentationspakke og ikke med det første spørgsmål.

Hvem træffer go/no-go-beslutningen?

Én navngiven person bør lede den, typisk release manageren eller den, der ejer produktionsmiljøet, men den brugbare disciplin er at fordele de enkelte spørgsmål frem for hele beslutningen. Udvikling og QA svarer på accept- og fejlspørgsmålene, drift og support svarer på rollback og bemanding, release manageren svarer på afhængigheder og ændringsvindue, og ledelsessponsoren svarer på godkendelsen. Skrevet sådan bliver mødelederens opgave at køre træet igennem og registrere udfaldet, ikke at afgøre hvert spørgsmål personligt. Det tæller også som dokumentation: rammeværk som SOC 2 forventer, at ændringer bliver autoriseret, testet, godkendt og dokumenteret, og et beslutningstræ med navngivet beslutningsret er en enkel måde at vise det på.

Hvornår bør en go/no-go ende i et betinget go frem for et no-go?

Når det udestående punkt ikke bringer releasen i fare, og nogen tager ejerskab efter launch. Et betinget go er kun et reelt udfald, hvis hver betingelse har en navngiven ejer, en frist og en konsekvens ved overskridelse; ellers er det bare et almindeligt go med ekstra papirarbejde. Reservér no-go til alt, der ville efterlade brugerne udsatte eller uden support. I dette træ ledes blokerende mangler i acceptkriterierne, en ikke-aftalt fejl over tærsklen, en hård afhængighed I ikke kan frigive uden, en uforberedt supportfunktion og en konflikt i ændringsvinduet alle til no-go med en ny dato.

Hvad er forskellen på no-go og afbrydelse?

No-go betyder, at releasen udskydes: det samme indhold frigives på en ny dato, når blokeringen er ryddet. Afbrydelse betyder, at den trækkes, og at indholdet går tilbage til omarbejdning eller fornyet vurdering uden dato. Skellet er vigtigt, fordi en release, der slet ikke kan rulles tilbage, eller en, hvor ledelsessponsoren holder godkendelsen tilbage af forretningsmæssige grunde, ikke venter på en rettelse. Registrerer man den som en udskydelse, holdes det samme møde igen fjorten dage senere med det samme grundlag.

Hvordan begrænser jeg en launch til en pilot- eller canary-gruppe?

Behandl det som et udfald af beslutningen, ikke som et kompromis, der opstår i lokalet. I dette træ forgrener det sidste spørgsmål, 'Hvilket omfang godkendes?', sig i Fuldt, Betinget og Kun pilot, så en begrænset release vælges bevidst, efter at alle parathedsspørgsmål er besvaret, ikke som en måde at undgå et no-go på. Definér inden gennemgangen, hvad en pilot betyder i jeres produkt: hvilken kohorte eller eksponeringsgrad, hvor længe den kører, hvad der overvåges, og hvilket kriterium der giver lov til at udvide.