Vieraskynä: Virheet opettavat vain niitä, jotka niitä opiskelevat

Virheistä oppii. Vai oppiiko? Ja onko oppiminen edes se tärkein asia, kun virheitä tapahtuu?

Vastaan tähän esittelemällä työkalun nimeltä blameless postmortem. Mikä se on, miten olen omassa työelämässäni sitä käyttänyt, ja miksi se on mielestäni yksi tärkeimmistä työkaluista, mitä tiimit ja organisaatiot voivat käyttää.

Mikä on blameless postmortem?

Postmortem, eli tyypillisesti projektin tai tapahtuman jälkeen pidettävä analyysi, ei toki ole uusi asia. Vastaavia on tehty varmasti jo iät ajat. Uutta henkeä ja vivahteita siihen on kuitenkin puhkunut ohjelmistokehityksessä etenkin DevOps- ja SRE-puolelta, pienellä mutta tärkeällä blameless lisäyksellä.

Idea on simppeli; jokainen asiakkaille negatiivisia vaikutuksia tuottanut tapahtuma käydään läpi välttäen syyttelyä, pyrkien jakamaan tietoa tapahtumien vaiheista ja luoden oppeja joiden avulla vastaavanlaisia ongelmia voitaisiin ehkäistä.

Miten pidetään blameless postmortem?

Tapoja blameless postmortemin järjestämiseen on erilaisia, mutta minulle tuttu malli on ollut jokseenkin seuraavanlainen:

1. Mahdollisimman pian ongelman havaitsemisen ja korjauksen jälkeen järjestetään avoin sessio, johon kutsutaan vähintään ongelman synnyssä ja selvityksessä mukana olleita henkilöitä. Mukana voi olla myös sidosryhmiä tai muita asiasta kiinnostuneita. Keskustelua ohjaa usein erillinen fasilitaattori.
2. Ennen kutsun lähettämistä session järjestäjä luo dokumenttipohjan, jossa on tyypillisesti kohdat mitä on tapahtunut, milloin ja mitkä ovat olleet ongelman vaikutukset sekä tapahtumien aikajana. Tämä lisätään kutsuun. Osallistujia kehotetaan lisäämään ja täydentämään tapahtuman aikajanaa jo ennen sessiota.
3. Session alkuun käydään läpi pohjaan jo kirjatut asiat, erityisesti aikajana, jota tyypillisesti läpikäynnin aikana yhdessä tarkennetaan. Tavoite on saada aikaan yhteinen ymmärrys siitä, mitä on tapahtunut, menemättä vielä syvemmälle mahdollisiin syihin niiden taustalla. Mahdolliset esiin nousevat faktojen ulkopuoliset kysymykset ja ajatukset pyritään tai pyydetään tässä vaiheessa kirjaamaan ylös myöhempää käsittelyä varten.
4. Läpikäynnin jälkeen osallistujia pyydetään pohtimaan ongelmaan liittyviä avoimia kysymyksiä ja lisäämään niitä listaan mahdollisesti jo esiin nousseiden kysymysten lisäksi.
5. Kysymykset käydään läpi yksi kerrallaan antaen osallistujille mahdollisuus vastata niihin haluamastaan kulmasta. Vastaukset poikivat usein lisäkysymyksiä. Joko niitä nousee luonnostaan osallistujilta tai fasilitaattorin toimesta esimerkiksi 5 whys -tyyppistä lähestymistapaa mukaillen. Tässä vaiheessa pyritään yhä pysymään avoimina ja uteliaina välttäen vielä ongelmanratkaisumoodia – mahdolliset jo esiin nousevat toimenpide-ehdotukset kirjataan ylös ja ohjataan keskustelu takaisin kysymysten pohtimiseen.
6. Kysymyksiä käydään läpi, kunnes osallistujat tai fasilitaattori eivät koe tarvetta porautua asiassa enää syvemmälle.
7. Kysymysten jälkeen käydään läpi jo ehdotettuja ratkaisuja sekä etsitään uusia, jotka voisivat auttaa ehkäisemään tulevia ongelmia ja niiden vaikutuksia.
8. Lopuksi valitaan ratkaisut, joita halutaan edistää, sekä kuka niitä edistää tai miten niitä lähdetään viemään eteenpäin.

Miksi blameless postmortem?

Aloitetaan helpoimmasta, eli oppimisesta

Olen työurani aikana pannut merkille, että tietyllä kadenssilla (esim. kahden viikon välein) toistuvat retrospektiivit eivät tuota kovinkaan paljon pysyviä vaikutuksia. Varsinkin jos tiimi on toiminut yhdessä jo pitkään, on riski, että retrot ovat aneemisen puoleisia ja aiheuttavat välillä jopa enemmän haittaa kuin hyötyjä.

Sen sijaan retrot, joissa on selkeämpi aihe tai konteksti, kuten vaikka heti jonkun kokemuksen perään pidetty lyhytkin pohdinta, aiheuttavat usein sekä vilkkaampaa keskustelua että konkreettisia ehdotuksia toimenpiteille. Tämä pätee myös blameless postmortemiin; sen taustalla on jokin tapahtuma, ja tyypillisesti osallistujilla on vahva motivaatio toimintaan.

Toki virheiden jälkeen syntyy usein toimenpiteitä ilman sen suurempaa retroiluakin. Mutta. Ilman virheen tarkempaa läpikäyntiä jäävät toimenpiteet usein pinnallisiksi – lisätään testi, parannetaan monitorointia, korjataan dokumentaatio. Hyviä toimia toki, mutta ne tuppaavat puremaan vain juurikin kyseisen virheen estämiseen.

Syvällisempi läpikäynti lähes poikkeuksetta paljastaa taustatekijöitä, joihin vaikuttamalla voidaan ehkäistä ja vaimentaa virheiden vaikutuksia huomattavasti laajemminkin. Kuvaava esimerkki on, kun osallistuin vähän aikaa sitten postmortemiin, jossa juuri tapahtuneen ongelman ympärillä pitkään pyörinyt keskustelu ottikin uuden suunnan. Sen jälkeen yksi osallistujista tokaisi, että “oikeastaanhan tämä alkoi jo vuonna 2020, kun…”

Oppimista tehostaa vielä sekin, että mukaan oppimiskokemukseen pääsee myös henkilöitä, jotka ovat ehkä olleet sivustaseuraajia tapahtuman aikana, mutta voivat tarjota keskusteluun oman tuoreen näkökulmansa. Tällä on muuten toinenkin positiivinen puoli; usein nämä samat sivulliset saattavat ihan hyvin aikomuksin liittyä mukaan keskusteluun tai ongelman ratkomiseen tilanteen ollessa vielä päällä, ja 1. vaatia taustoittamaan asiaa yhä uudelleen ja uudelleen sekä 2. ohjata aiheen akuutin ongelman ratkaisemisen sijaan juurisyiden ja “syyllisten” löytämiseen – pitkittäen näin ongelman pikaista korjaamista. Sen sijaan blameless postmortemin muodostuttua osaksi tiimin ja organisaation kulttuuria voidaan akuutin virheen ratkomisen aikana antaa tekijöille rauha keskittyä täysillä ongelman ratkaisuun syiden ja tulevaisuuden pohdinnan sijaan. Koska kaikki tietävät, että senkin aika tulee vielä.

Sitten se tärkein, eli tunteet

Sanon usein, että blameless postmortemissa voi ja saakin olla vähän syyttelyä, sillä sen seurauksena sitä ei postmortemin jälkeen enää ole. Tämä on tärkeää erityisesti, koska useimmiten ihmiset syyttävät virheistä itseään. Ja mikäli näitä tunteita ei pääse käsittelemään, voivat ne ajan kuluessa johtaa vakaviinkiin inhimillisiin ongelmiin. Negatiiviset asiat kun eivät yleensä katoa, kun ne hautaa sisälleen, vaan ne saattavat päinvastoin paisua. Toisaalta syytösten välttäminen on erityisen tärkeää silloin, kun session osallistujien välille ei vielä ole ehtinyt kehittyä luottamusta, koska tässä tapauksessa syytökset nostavat helposti defenssit päälle ja ratkaisujen hakeminen vaikeutuu.

Kun sessiota pidetään, huomataan lähes aina, ettei ongelman syntymisen taustalla olekaan vain se yksi asia, mitä kukin on itse päässään pohtinut, vaan tekijöitä on useita ja hyvin erilaisia. Esimerkkeinä väärän toimenpiteen syyksi paljastuukin puute työkalussa, virheellisen olettamuksen takana onkin kommunikaatiohaaste organisaation eri tahojen välillä, puuttuvien testien taustalla heikko design ja testattavuus, jne. Lisäksi mahdollisiin tunnontuskiin auttaa sekin, kun ongelmasta itseään jotenkin syyttävä taho pääseekin postmortemin kautta olemaan osa ratkaisua, eikä osa ongelmaa.

Virheistä keskustelu myös normalisoi sitä, että niitä tekevät kaikki ja että virheiden pelkäämisen ja peittelyn sijaan ne kannattaa tuoda rohkeasti esiin, koko tiimin hyväksi. Tämä johtaa tyypillisesti siihen, että virheiden tekemistä ei pelätä enää niin paljon, vaan ne koetaan luonnolliseksi osaksi tehokasta ohjelmistokehitystä – ja elämää.

Lopuksi

Ajattelin joskus, että hyvä tiimi ei tee virheistä numeroa. Nykyään ajattelen, että hyvä tiimi tekee virheistä numeron pitämällä niistä vaikkapa blameless postmortemin. Koska se johtaa oppimiseen, luottamukseen, ja turvallisuuteen.

Jotka ovat toimivassa yhteisössä kaikki aika tärkeitä juttuja.