Kort svar: Et post mortem er én sides skriftlig opsamling efter en hændelse – skrevet inden en uge, mens detaljerne er friske, og efter én jærnregel: vi leder efter ÅRSAGER, ikke skyldige. Indholdet: tidslinjen med klokkeslæt, rodårsagen (spørg „hvorfor?“ fem gange – „pluginet fejlede“ er aldrig bunden), konsekvensen i tal (varighed, berørte kunder), hvad der gik godt og skidt i håndteringen – og præcis TO handlinger: én, der forebygger gentagelsen, og én, der forbedrer processen. Læg handlingerne i kalenderen med ansvar og dato, og tjek ved kvartalstjekket, at de BLEV gjort – ellers var dokumentet bare terapi.
Nedbrud koster to gange: først da det skete – og igen, når det gentager sig, fordi ingen samlede læringen op. Post mortem-rutinen er forsikringen mod anden regning, og den behøver hverken møder eller skabelon-bureaukrati: én side, én time, to handlinger. Sådan gør du.
Reglen „blame-free“ er ikke flødeskum – den er metodens motor: leder opsamlingen efter en skyldig, får du forsvar og tavshed, og den vigtigste information („jeg sprang testen over, fordi vi havde travlt“) kommer aldrig frem – og så gentager fejlen sig med et andet navn på. Leder den efter ÅRSAGER, får du systemsvar: testen var for besværlig, vinduet lå forkert, varslet gik til en død postkasse. Derfor skrives dokumentet i SYSTEM-sprog („opdateringen blev udrullet uden funktionstest“ – ikke „X glemte at teste“), og derfor må selv en enkeltmandsvirksomhed holde reglen over for sig selv: formålet er ikke at få ret eller få skyld, men at gøre NÆSTE nedbrud mindre sandsynligt eller mindre dyrt. Det er hele dokumentets succeskriterium.
Seks korte afsnit: TIDSLINJEN med klokkeslæt (opdaget hvornår og af hvem/hvad – forhåbentlig overvågningen, ikke en kunde – første handling, årsag fundet, løst; ændringsloggen og statussidens opdateringer leverer den næsten færdig), ÅRSAGEN (den tekniske OG rodårsagen – næste afsnit), KONSEKVENSEN i tal (varighed, berørte funktioner, skønnet tab – nøgternt, det styrer prioriteringen af handlingerne), HVAD GIK GODT (alarmen kom hurtigt, rollback virkede – det skal BEVARES og er lige så vigtigt som fejlene), HVAD GIK SKIDT (ledte 20 minutter efter kundenummeret; statussiden blev opdateret for sent) og HANDLINGERNE. Skriv det inden en UGE – efter to er detaljerne væk – og arkivér det samlet med de andre, så mønstre på tværs kan ses.
Den tekniske årsag er sjældent den rigtige at handle på, og „fem gange hvorfor“ er den enkleste vej ned: sitet var nede (hvorfor?) → et plugin fejlede efter opdatering (hvorfor gik det galt?) → det var to versioner bagud, så springet var stort (hvorfor bagud?) → licensen var udløbet, så opdateringer stoppede (hvorfor opdagede ingen det?) → varslet gik til en tidligere medarbejders mail. RODÅRSAGEN er altså varslingsadresser – og den rigtige handling er fælles-postkassen fra udløbs-guiden, ikke (kun) at opdatere det ene plugin. Stop, når svaret bliver et SYSTEM-forhold, I kan ændre (en rutine, et varsel, en aftale) – og acceptér gerne TO rodårsager: én for at fejlen OPSTOD, én for at den GJORDE ONDT så længe (manglende alarm, famlende eskalation – typisk stof til proces-handlingen).
Disciplinen er PRÆCIS to: én FOREBYGGENDE (adresserer rodårsagen: varsler til fællespostkassen; funktionstest efter opdateringer af betalingsplugins; tørke-alarm på ordrer, jf. funktions-overvågningen) og én PROCES-forbedring (gør næste hændelse billigere: kundenummeret ind i nødlisten; statusside-skabelonerne skrevet; nedbrudsplanen justeret med det lærte). Hvorfor kun to? Fordi ti handlinger er en ønskeliste, og to er en aftale: hver får ansvarlig og dato, ryger i kalenderen og i ændringsloggen – og bliver faktisk gjort. Er hændelsen stor nok til flere, så vælg de to vigtigste NU og læg resten i den almindelige opgavekø – post mortem’ets troværdighed hænger på, at dets handlinger altid gennemføres.
Dokumenter forhindrer ingenting – GENNEMFØRTE handlinger gør. Derfor har rutinen to opfølgninger: ved næste kvartalstjek tjekkes åbne post mortem-handlinger (gjort? – ellers op på formiddagens fem-punkts liste), og én gang årligt læses årets post mortems i sammenhæng: tre hændelser med samme rodårsagstype (udløb, ændringer uden test, én-persons-afhængighed) er ikke tre uheld, men ét strukturelt problem – og årets vigtigste prioritering. Del gerne konklusionen med kunderne, når hændelsen var synlig: en kort, ærlig „det skete, det gør vi“ på statussidens historik bygger mere tillid, end tavshed nogensinde har gjort. Og lad fundamentet tage sin del: på WordPress-hosting hos Hostious med performance-garanti er serverlagets hændelser hostingens post mortems – så dine egne kan handle om det, kun du kan ændre.
Når kunder mærkede den, eller den kostede mere end en halv times arbejde – og altid ved gentagelser. Små hændelser kan nøjes med to linjer i ændringsloggen.
Én time inden for en uge: tidslinjen ligger næsten færdig i ændringslog og statusside, og formatet er én side med seks afsnit og to handlinger.
Så spørg én gang til: hvorfor var fejlen MULIG og let at begå? Svaret er altid et system-forhold – en manglende test, et dårligt tidspunkt, en uklar rutine – og dét kan ændres.
