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

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.