Gjennomfør en pre-mortem i Jira: Finn utgivelsesrisikoene før de slår til

En utgivelse kan se klar ut i Jira selv om teamet fortsatt har bekymringer som ingen har skrevet ned. Implementeringen er nesten ferdig, testingen pågår og lanseringsdatoen nærmer seg. Noen mistenker at eldre kundekontoer oppfører seg annerledes. Andre frykter at kundestøtte vil forklare de nye kontrollene feil.

En pre-mortem gir bekymringene et nyttig utgangspunkt: Forestill dere at utgivelsen allerede har gått galt, og beskriv deretter årsakene. Øvelsen gjør det lettere å diskutere mulige feil før teamet blir opptatt med å håndtere dem.

I denne veiledningen gjennomfører vi en praktisk pre-mortem for en fiktiv kundeportalutgivelse og organiserer resultatene i Power Packs Risk & Pre-Mortem Grid. Resultatet er et kort sett med risikoer med tydelige eiere, varselsignaler og risikoreduserende arbeid.

Velg et konkret mål for utgivelsen

Teamet vårt legger til e-postinnstillinger i en kundeportal. Kundene skal kunne slå valgfrie konto-e-poster av eller på, samtidig som de fortsatt mottar nødvendige meldinger. Maya har ansvar for produktresultatet, Leo implementerer endringen, Priya leder testingen og Sam forbereder kundestøtte.

De velger Jira-saken som beskriver det felles målet for utgivelsen, som hjem for pre-mortemen. Relaterte implementerings- og testsaker forblir koblet gjennom den vanlige Jira-prosessen. Når diskusjonen ligger ved utgivelsessaken, vet folk hvor de skal finne den igjen.

Før møtet skriver Maya en enkel avgrensning: Vurder kundeopplevelsen, e-postatferden og hvor klar kundestøtte er til den første utgivelsen av innstillingskontrollene. Teamet skal se på lanseringen og den første uken med bruk. Denne avgrensningen hindrer at diskusjonen blir en gjennomgang av alle tenkelige portalproblemer.

Se for dere en feil før dere diskuterer løsninger

Start med et konkret spørsmål: «Det er én uke etter lansering. Kundene er forvirret, antallet støttehenvendelser har økt, og vi har måttet stanse utrullingen. Hva skjedde?» Det forestilte resultatet bør være ubehagelig nok til å sette i gang tanker, uten å antyde at en fiasko er uunngåelig.

Gi alle noen stille minutter til å skrive mulige årsaker hver for seg. Slik kan en testers bekymring eller en observasjon fra kundestøtte komme inn i diskusjonen før den første skråsikre forklaringen tar over. Be om årsaker folk kan beskrive, fremfor generelle utsagn som «kvaliteten var dårlig».

Del deretter scenarioene etter tur. I første runde samler dere bekymringene og avklarer hva de betyr. Vent med diskusjonen om den beste løsningen. En deltaker bør kunne ta opp en ubehagelig mulighet uten straks å måtte forsvare en fullstendig utbedringsplan.

• Eksisterende kunder ser innstillinger som ikke samsvarer med deres nåværende e-postinnstillinger.
• Grensesnittet gir inntrykk av at nødvendige e-poster kan slås av.
• Støtteinstruksjonene beskriver kontroller som ble endret før utgivelsen.
• Oppdateringen av innstillingene ser vellykket ut selv når den underliggende endringen mislykkes.

Dette er fiktive scenarioer i eksempelet vårt. Deres egen liste bør komme fra folk som forstår arbeidet, avhengighetene og kundeopplevelsen. Power Pack registrerer diskusjonen; teamet vurderer hva som kan skje.

Gjør bekymringer om til gjenkjennelige risikobeskrivelser

En nyttig risiko beskriver en mulig hendelse og konsekvensen av den. «Migrering» er et tema. «Eksisterende innstillingsverdier blir feil tilordnet, slik at noen kunder mottar valgfrie e-poster de forventet å stoppe» er et scenario folk kan undersøke.

Slå sammen dubletter uten å miste forskjellige konsekvenser. Flere bekymringer om eldre kontoer kan ha samme underliggende årsak. En misvisende etikett og en mislykket lagring kan begge forvirre kundene, men de trenger ulike kontroller og bør som regel forbli separate risikoer.

Spør hva teamet ville lagt merke til tidlig i hvert scenario. Et tidlig varselsignal er et observerbart tegn som fortjener oppmerksomhet. I eksempelet vårt er et avvik mellom eksisterende kontoinnstillinger og de planlagte migrerte verdiene mer nyttig enn «kundene kan klage». Det kan kontrolleres før lansering.

Bli enige om hva sannsynlighet og konsekvens betyr

Power Pack tilbyr en 3×3- eller 5×5-matrise og beregner en alvorlighetsgrad ved å multiplisere sannsynlighet med konsekvens. Bruk poengsummen til å støtte diskusjon og sortering. Det er en subjektiv vurdering, ikke en prognose for hvor ofte en feil vil oppstå eller en beregning av forventet tap.

I første møte velger teamet vårt 3×3 og blir enige om enkle definisjoner av nivåene. Sannsynlighet én betyr at de foreløpig ser lite som støtter scenarioet; to betyr at det er plausibelt og må undersøkes; tre betyr at det er sterke grunner til å forvente det uten tiltak. Dette er teamets arbeidsdefinisjoner.

De definerer konsekvens ut fra virkningene for kundene og utgivelsen. Én betyr begrenset ulempe, to betyr en vesentlig forstyrrelse som krever oppfølging, og tre betyr et alvorlig kundeproblem eller en grunn til å stanse utgivelsen. Et annet team kan trenge andre definisjoner i sitt miljø.

Priya vurderer feil migrering til sannsynlighet to og konsekvens tre, som gir seks poeng. Teamet diskuterer forutsetningene bak vurderingen: Den nye tilordningen er ennå ikke prøvd med representative eldre kontoer. De manglende bevisene er viktigere enn hvor presist tallet ser ut.

Behold samme skala når dere sammenligner de første risikoene. Bytte av matrisestørrelse skalerer om eksisterende vurderinger, så gjennomgå plasseringene dersom dere endrer oppløsningen. En ny plassering må ikke forveksles med ny kunnskap om utgivelsen.

Legg risikoene inn i Power Pack

Åpne Power Pack på den valgte Jira-saken og velg Risk & Pre-Mortem Grid. Bruk varmekartet til å se fordelingen av vurderingene og risikoregisteret til å gjennomgå oppføringene. Du kan legge til en risiko fra en matriserute når du allerede kjenner den første sannsynlighets- og konsekvensvurderingen.

Registrer tittel, feilscenario, tidlig varselsignal og kategori for hver oppføring. Legg til avtalte vurderinger, en plan for risikoreduserende tiltak og en eier. Power Pack støtter også kontrollpunkter for tiltakene, status og en valgfri referanse til en Jira-sak.

Eieren kan være en Jira-bruker eller en oppføring for en ekstern person. Velg noen som skal koordinere responsen og bringe manglende dokumentasjon tilbake til teamet. Å navngi personen i matrisen oppretter ikke en Jira-oppgave, tildeler ikke en eksisterende oppgave og gir ikke tilgang til saken.

Kontroller lagringsstatusen før du behandler den oppdaterte matrisen som delt. Endringene lagres på saken, og en lokal status eller status for nytt forsøk er ikke en bekreftelse på at en kollega allerede kan se siste oppføring.

Gi hver viktig risiko en praktisk respons

«Test grundig» er vanskelig å følge opp. For migreringsrisikoen foreslår Priya en prøvekjøring med representative tilstander fra eksisterende kontoer, etterfulgt av en sammenligning av innstillingene og forventet e-postatferd. Leo skal undersøke eventuelle avvik. Priya beholder eierskapet til risikoen og tar resultatet med til utgivelsesgjennomgangen.

Del responsen inn i kontrollpunkter som synliggjør fremdriften. Teamet kan velge representative tilfeller, kjøre prøven, gjennomgå avvik og registrere gjenværende usikkerhet. Kontrollpunktene organiserer responsen, mens selve dokumentasjonen ligger i det relevante test- eller leveransearbeidet.

Hvis tiltakene trenger en egen Jira-sak, oppretter og tildeler dere den gjennom den vanlige Jira-arbeidsflyten og legger deretter saksnøkkelen til som referanse på risikoen. En referanse gjør sammenhengen lettere å følge; den oppretter ikke arbeidet automatisk eller styrer gjennomføringen.

Vurder status på nytt når kunnskapsgrunnlaget endrer seg

Power Pack tilbyr statusene Identified, In Progress, Mitigated og Accepted. Bruk Identified når scenarioet er registrert, og In Progress når noen arbeider aktivt med responsen. Avtal hvilken dokumentasjon teamet forventer før en risiko beskrives som Mitigated.

Accepted kan beskrive en bevisst beslutning om å fortsette med en gjenværende risiko. Maya kan for eksempel akseptere en liten mangel i støttedokumentasjonen etter at Sam bekrefter at en midlertidig løsning finnes. Registrer begrunnelsen og vurder den på nytt hvis forutsetningene endres. Aksept skal være en forstått beslutning, ikke en måte å rydde matrisen på.

Spør eierne om varselsignaler, tiltaksresultater og gjenværende usikkerhet ved utgivelsesgjennomgangen. Vurder vesentlige omfangsendringer, nye avhengigheter og uventede testresultater særskilt. Oppdater vurderingene når dokumentasjonen tilsier det, og forklar hvorfor vurderingen har endret seg.

Du kan eksportere matrisen som Markdown eller CSV til en planleggingssamtale. Oppgi Jira-saken som stedet der den gjeldende registreringen skal kontrolleres. En delt eksport er et øyeblikksbilde og gjenspeiler kanskje ikke lenger teamets siste vurdering.

Bruk møtet til å endre det som skjer videre

En ferdig matrise er nyttig når den påvirker forberedelsene. For portalteamet vårt fører pre-mortemen til en prøvemigrering, tydeligere ordlyd og en kontroll av at støtteveiledningen samsvarer med utgivelseskandidaten. Hvert tiltak retter seg mot et konkret feilscenario tatt opp av dem som gjør arbeidet.

Start med én utgivelse, en kort fasilitert samtale og et lite sett med meningsfulle risikoer. Bruk Power Pack til å holde scenarioene, eierne og responsene synlige ved Jira-saken. Ta deretter registreringen med inn i neste utgivelsessamtale, der teamet kan vurdere hva som faktisk har endret seg.