Lav en pre-mortem i Jira: find udgivelsesrisici, før de indtræffer

En udgivelse kan se klar ud i Jira, mens teamet stadig har bekymringer, som ingen har skrevet ned. Implementeringen er næsten færdig, test er i gang, og lanceringsdatoen nærmer sig. Nogen mistænker, at ældre kundekonti opfører sig anderledes. En anden frygter, at supporten forklarer den nye betjening forkert.

En pre-mortem giver bekymringerne et nyttigt udgangspunkt: forestil jer, at udgivelsen allerede er gået galt, og beskriv derefter årsagen. Øvelsen gør det lettere at diskutere plausible fejl, før teamet får travlt med at reagere på dem.

I denne vejledning gennemfører vi en praktisk pre-mortem for en fiktiv kundeportaludgivelse og organiserer resultaterne i Power Packs Risk & Pre-Mortem Grid. Resultatet er et kort sæt risici med tydelige ansvarlige, advarselstegn og afhjælpende arbejde.

Vælg et bestemt udgivelsesresultat

Vores team tilføjer mailindstillinger til en kundeportal. Kunderne skal kunne slå valgfrie kontomails til eller fra og fortsat modtage væsentlige beskeder. Maya har ansvaret for produktresultatet, Leo implementerer ændringen, Priya leder test, og Sam forbereder supporten.

De vælger Jira-sagen, der beskriver det fælles udgivelsesresultat, som hjem for deres pre-mortem. Relaterede implementerings- og testsager forbliver linket gennem den normale Jira-proces. Diskussionen ved siden af udgivelsessagen giver folk et oplagt sted at vende tilbage til.

Før mødet skriver Maya en enkel beskrivelse af omfanget: gennemgå kundeoplevelsen, mailadfærden og supportens parathed til første udgivelse af indstillingsbetjeningen. Teamet ser på lanceringen og den første uges brug. Grænsen forhindrer diskussionen i at blive en gennemgang af alle tænkelige portalproblemer.

Forestil jer en fiasko, før I diskuterer løsninger

Start med et konkret oplæg: ”Der er gået en uge siden lanceringen. Kunderne er forvirrede, supportanmodningerne er steget, og vi har måttet sætte udrulningen på pause. Hvad skete der?” Det tænkte resultat skal være ubehageligt nok til at sætte tanker i gang uden at antyde, at en fiasko er uundgåelig.

Giv alle et par stille minutter til selvstændigt at skrive mulige årsager. Det lader en testers bekymring eller en supportobservation komme ind, før den første selvsikre forklaring overtager. Bed om årsager, folk kan beskrive, frem for generelle udsagn som ”kvaliteten var dårlig”.

Del derefter scenarierne på skift. Indsaml bekymringen og afklar betydningen i første runde. Gem diskussionen om den bedste løsning til senere. En deltager skal kunne nævne en ubehagelig mulighed uden straks at skulle forsvare en fuld afhjælpningsplan.

• Eksisterende kunder ser indstillinger, der ikke matcher deres nuværende mailopsætning.
• Grænsefladen antyder, at væsentlige mails kan slås fra.
• Supportinstruktioner beskriver betjening, der ændrede sig før udgivelsen.
• Opdateringen af indstillingen ser vellykket ud, selv når den underliggende ændring fejler.

Det er fiktive scenarier til vores eksempel. Jeres egen liste bør komme fra dem, der forstår arbejdet, afhængighederne og kundeoplevelsen. Power Pack registrerer diskussionen; teamet leverer vurderingen af, hvad der kan ske.

Omsæt bekymringer til genkendelige risikobeskrivelser

En nyttig risiko beskriver en mulig hændelse og dens konsekvens. ”Migrering” er et emne. ”Eksisterende indstillingsværdier bliver forkert omsat, så nogle kunder modtager valgfrie mails, de forventede at stoppe” er et scenarie, folk kan undersøge.

Saml dubletter uden at miste forskellige konsekvenser. Flere bekymringer om ældre konti kan dele én grundårsag. En vildledende label og mislykket lagring kan begge forvirre kunder, men kræver forskellige kontroller og bør normalt forblive separate risici.

Spørg for hvert scenarie, hvad teamet ville bemærke tidligt. Et tidligt advarselstegn er noget observerbart, der fortjener opmærksomhed. I vores eksempel er en forskel mellem eksisterende kontoindstillinger og de foreslåede migrerede værdier mere nyttig end ”kunderne klager måske”. Den kan kontrolleres før lanceringen.

Aftal, hvad sandsynlighed og konsekvens betyder

Power Pack tilbyder en 3×3- eller 5×5-matrix og beregner alvorlighed ved at gange sandsynlighed med konsekvens. Brug scoren som støtte til diskussion og sortering. Det er en subjektiv vurdering, ikke en prognose for, hvor ofte en fejl indtræffer, eller en beregning af forventet tab.

Til første møde vælger teamet 3×3 og aftaler enkle betydninger af vurderingerne. Sandsynlighed ét betyder, at de aktuelt ser begrænset understøttende dokumentation; to betyder, at scenariet er plausibelt og kræver undersøgelse; tre betyder, at der er stærke grunde til at forvente det uden handling. Det er teamets arbejdsdefinitioner.

De definerer konsekvens ud fra påvirkning af kunder og udgivelse. Ét betyder en begrænset gene, to en væsentlig forstyrrelse, der kræver opfølgning, og tre et alvorligt kundeproblem eller en grund til at sætte udgivelsen på pause. Et andet team kan have brug for andre definitioner i sit miljø.

Priya vurderer forkert migrering til sandsynlighed to og konsekvens tre, hvilket giver seks. Teamet diskuterer antagelserne bag vurderingen: den nye omsætning er endnu ikke afprøvet med repræsentative ældre konti. Den manglende dokumentation betyder mere end tallets tilsyneladende præcision.

Behold samme skala, når I sammenligner de første risici. Skift mellem matrixstørrelser skalerer eksisterende vurderinger om, så gennemgå de nye placeringer, hvis opløsningen ændres. En ny placering må ikke forveksles med nyopdaget dokumentation om udgivelsen.

Tilføj risiciene til Power Pack

Åbn Power Pack på den valgte Jira-sag, og vælg Risk & Pre-Mortem Grid. Brug varmekortet til at se fordelingen af vurderinger og risikoregistret til at gennemgå posterne. Du kan tilføje en risiko fra en matrixcelle, når du allerede kender dens første sandsynlighed og konsekvens.

Registrer titel, fejlscenarie, tidligt advarselstegn og kategori for hver post. Tilføj de aftalte vurderinger, en afhjælpningsplan og en ansvarlig. Power Pack understøtter også afhjælpningskontrolpunkter, status og en valgfri Jira-sagsreference.

Den ansvarlige kan være en Jira-bruger eller en ekstern personpost. Vælg en, som koordinerer reaktionen og bringer manglende dokumentation tilbage til teamet. At navngive personen i matrixen opretter ikke en Jira-opgave, tildeler ikke en eksisterende opgave og giver ikke adgang til sagen.

Gennemgå gemmetilstanden, før den opdaterede matrix betragtes som delt. Ændringer gemmes på sagen, og en lokal tilstand eller et nyt forsøg må ikke læses som bekræftelse på, at en kollega allerede kan se den seneste post.

Giv hver vigtig risiko en praktisk reaktion

”Test grundigt” er svært at følge op på. For migreringsrisikoen foreslår Priya en prøve med repræsentative eksisterende kontotilstande, efterfulgt af en sammenligning af de resulterende indstillinger og forventet mailadfærd. Leo undersøger afvigelser. Priya forbliver risikoansvarlig og tager resultatet med til udgivelsesgennemgangen.

Del reaktionen op i kontrolpunkter, der gør fremdrift synlig. Teamet kan vælge repræsentative tilfælde, udføre prøven, gennemgå forskelle og registrere den resterende usikkerhed. Kontrolpunkter hjælper med at organisere reaktionen, mens den faktiske dokumentation forbliver i det relevante test- eller leverancearbejde.

Hvis afhjælpningen kræver sin egen Jira-sag, skal den oprettes og tildeles gennem det normale arbejdsforløb. Tilføj derefter nøglen som reference på risikoen. Referencen gør sammenhængen lettere at følge; den opretter ikke automatisk arbejdet og styrer ikke leveringen.

Gense status, når dokumentationen ændres

Power Pack har statusserne Identified, In Progress, Mitigated og Accepted. Brug Identified, når scenariet er registreret, og In Progress, når nogen aktivt arbejder på reaktionen. Aftal, hvilken dokumentation teamet forventer, før en risiko beskrives som Mitigated.

Accepted kan beskrive en bevidst beslutning om at fortsætte med en resterende eksponering. Maya kan for eksempel acceptere et lille hul i supportdokumentationen, efter at Sam har bekræftet, at et midlertidigt svar er tilgængeligt. Registrer begrundelsen, og gense den, hvis antagelserne ændres. Accept skal være en forstået beslutning, ikke en måde at rydde matrixen op på.

Spørg de ansvarlige om advarselstegn, afhjælpningsresultater og resterende usikkerhed ved udgivelsesgennemgangen. Gennemgå selvstændigt enhver væsentlig ændring i omfang, ny afhængighed eller uventet testresultat. Opdater vurderingerne, når dokumentationen giver grund til det, og forklar, hvorfor vurderingen ændrede sig.

Du kan eksportere matrixen som Markdown eller CSV til en planlægningsdiskussion. Angiv Jira-sagen som stedet, hvor det aktuelle register kontrolleres. En delt eksport er et øjebliksbillede og afspejler måske ikke længere teamets seneste vurdering.

Brug mødet til at ændre det næste, der sker

En udfyldt matrix er nyttig, når den påvirker forberedelsen. For vores portalteam fører pre-mortem til en prøvemigrering, tydeligere formuleringer og en kontrol af, at supportvejledningen matcher udgivelseskandidaten. Hver handling adresserer et bestemt fejlscenarie rejst af dem, der udfører arbejdet.

Start med én udgivelse, en kort faciliteret diskussion og et lille sæt væsentlige risici. Brug Power Pack til at holde scenarier, ansvarlige og reaktioner synlige ved siden af Jira-sagen. Tag derefter registret med til næste udgivelsessamtale, hvor teamet kan vurdere, hvad der faktisk har ændret sig.