Ihmiset tekevät virheitä – se vain on fact of life. Myös ohjelmistotuotekehityksessä näin tapahtuu. Tuotekehitystiimeillä ja projekteilla kannattaakin olla jonkinlainen virheiden johtamiskäytäntö sen varmistamiseen, että asiat on priorisoitu oikein ja oikeat asiat etenevät.

Virheidenhallinta on tärkeää!

Virheet on pakko saada avoimesti näkyviin ja työkaluun, jotta niitä voidaan aktiivisesti hallita ja korjata.

On tietenkin myös huomattava, että tuotekehitysorganisaation pitää pyrkiä parempaan laatuun. Tähän voi olla monia keinoja, esimerkiksi parempi asiakasymmärrys tai paremmat suunnittelu ja katselmuskäytännöt. Virheiden suhteen, tavoitteena pitäisi olla tehdä pienempiä virheitä ja kehittää mekanismeja, että tehdyt virheet havaitaan aikaisemmin. Virheistä pitää myös pystyä puhumaan avoimesti ja niiden tilan pitäisi olla läpinäkyvästi kaikkien tiedossa tai näkyvissä. Virheitä ei saa piilotella! Jos organisaatiossa on kulttuuri, että kaikkia virheitä ei raportoida tai niistä ei kerrota, on syytä kaivautua tämän käytöksen juurille – miksi näin toimitaan? Onko kyseessä hankala työkalu virhehallintaan? Vai onko joku muu syy, kuten hankala virheiden raportointiprosessi tai joku muu. Tämä tilanne pitää ymmärtää ja korjata: virheet on pakko saada avoimesti näkyviin ja työkaluun, jotta niitä voidaan aktiivisesti hallita ja korjata.

Tämän blogin aiheena on kuitenkin virheiden johtamis- tai hallintakäytäntö. Olen kokemuksesta oppinut, että on hyvä, jos isommissa kehityshankkeissa on säännöllinen kokous, joka on fokusoitunut virheiden hallintaan. Tässä on muistilista mitä kannattaa pitää mielessä, kun järjestätte tällaista kokousta!

Miksi virhehallintakokous?

Miksi virheidenhallinta vaatii erillisen kokouksen virhetilanteen seurantaan? Tähän on seuraavia syitä.

Kokouksella tavoitellaan:

1. virheiden laatukontrolli
2. prioriteetin varmistaminen
3. kriittisten asioiden seuranta
4. päätösten tekeminen
5. tiedon ja ymmärryksen jakaminen virheistä ja kokonaisvirhetilanteesta

Virheiden laatu

Hyvä virhe sisältää paljon tietoa. Kovin usein tilanne on se, että organisaatio laiskistuu, ja virheet alkavat sisältää vähemmän ja vähemmän tietoa, kunnes ne typistyvät vain kryptiseksi otsikoksi ilman kuvausta. Kuulostaako tutulta? Tähän pitää tehdä stoppi. Hyvälaatuinen virhe sisältää

• hyvän ja selkeän otsikon
• prioriteetti tai vakavuus
• tietoa millä buildilla vika on ensin löydetty
• tietoa mitkä muut buildit on tarkistettu, että onko vika siellä
• millaisessa ympäristössä vika löytyy
• mitkä esistepit (preconditions) pitää ajaa, että virhe toistuu
• millä stepeillä virhe toistuu
• mikä on actual ja expected käytös (eli virheen tulos)
• mitä muita käyttäjän toimia on kokeiltu – ja toistuuko virhe niissäkin, vai eikö toistu
• missä buildeissä, ympäristöissä tai käyttöskenaarioissa virhe ei toistu
• toistuuko virhe, kuinka usein?
• kuka on alkuperäinen virheen löytäjä

Tietoa voi olla paljon muutakin, ja tietenkin asiaankuuluvat logit, tracet ja muut pitää myös liittää mukaan. Tarkoitus on siis, että tässä vaiheessa virheen raportointia annetaan tarkka kuva siitä, millainen ja miten vakava ongelma on kyseessä, ja miten sen voi toistaa. Tällä tiedolla on paljon helpompi ensinnäkin tehdä oikea prioriteettipäätös ja päättää korjauksen kiireellisyydestä ja target releasesta, ja toisaalta virhettä korjaavan henkilön on helpompi alkaa yrittää itse toistaa ongelmaa ja alkaa selvittää ongelman juurisyytä. Erityisesti tieto siitä missä virhe toistuu ja missä se ei toistu on todella tärkeä.

Jos näitä tietoja ei ole, ne pitää hankkia. Suurta hukkaa syntyy siitä, jos puutteellisin tiedoin varustettu virhe päästetään korjattavaksi. Kehittäjä toimii silloin sokkona, yrittää etsiä ”neulaa heinäsuovasta” ja turhautuu helposti. Tällainen tilanne johtaa helposti ping pong virheisiin, jotka kimpoilevat organisaation eri tahojen välillä, tai vääriin päätöksiin ”ei se toistu meillä, sen täytyy olla harvinainen vika tai pelkästään yksittäistapaus”.

Tarpeeksi tietoa virheessä onkin perusjuttuja, ja virhehallintakokous (muitakin keinoja on) on yksi keino varmistaa se, että organisaatio oppii täyttämään nämä tiedot virheisiin. Jos tietoja ei ole, on testaajan yleensä helpompi etsiä ja hankkia ne kuin devaajan.

Oikea prioriteetti

Kun virheessä on tarpeeksi tietoa, on helpompi varmistaa onko prioriteetti tai vakavuus oikea.

Kun virheessä on tarpeeksi tietoa, on helpompi varmistaa onko prioriteetti tai vakavuus oikea. Tähän kannattaa ottaa mukaan tuoteomistaja. Kun virheessä on tarpeeksi tietoa loppukäyttäjän ongelmasta ja tuskasta, tuoteomistaja voi tehdä päätöksen onko tämä virhe tarpeeksi paha, jotta se saa ”critical” -tason leiman, vai riittääkö ”major”. Yleensä kannattaa pyrkiä siihen, että kaikki virheet korjataan, mutta joskus se ei ole mahdollista. Silloin tietenkin pitää taas pyrkiä siihen, että vakavat virheet korjataan ensin. Organisaatioilla on myös yleensä sääntöjä siitä, millaisia tiedossa olevia virheitä myyntireleasessa saa olla. Esimerkiksi ei sallita yhtään critical-tason virhettä, mutta majoreita saa olla tietty määrä.

Seuranta

Virhekokous voi myös auttaa virhestatistiikan seurannassa, vaikka se ei olekaan kokouksen päätavoite. Kokouksen päätavoite on varmistaa virheiden laatu ja oikea vakavuuspäätös. Mutta kun nyt ollaan sopivalla porukalla koossa, voidaan hyvin myös katsoa mikä on virhe-inflow ja kokonaisstatistiikka. Näin varmistetaan, että kaikilla on sama käsitys nykytilasta. Tämä voi auttaa esimerkiksi sen huomaamiseen, pitääkö enemmän voimia suunnata virheiden etsimiseen ja korjaamiseen, ja vähemmän uuden tekemiseen.

Lisäksi kokous voi myös olla avuksi kiireellisten korjausten seurannassa, jos tälle ei ole muuta seurantamekanismia sovittu. Virheet, jotka pitää korjata nopeasti, voidaan vaikkapa leimata jollain tietyllä leimalla, ja kokous voi varmistaa, että nämä virheet ovat etenemässä mahdollisimman suurella nopeudella.

Päätösten tekeminen

Virheiden osaltakin pitää joskus tehdä päätöksiä. Korjataan / ei korjata. Critical / Major. Major / Minor. Korjataan nyt / seuraavassa releasessa. Tämä on mahdollista, kun on tarpeeksi tietoa virheestä ja oikeat päätöksentekijät paikalla. Kokous on hyvä paikka tällaiseen. Lisähyöty on se, että kokouksessa on myös yleisöä, joten päätökset ovat kaikkien tiedossa ja myös niiden perustelut on mahdollista kertoa.

Tiedon ja ymmärryksen jakaminen

Virhekokous on myös tilaisuus keskustella ja ymmärtää.

Virhekokous on myös tilaisuus keskustella ja ymmärtää. Usein virheet saattavat olla niin spesifisiä, että vaikka ne koetettaisiin kuvata kuinka hyvin, niin ne ovat hankala ymmärtää. Keskustellessa niiden impakti on kuitenkin helppo kertoa muille. Tällöin koko organisaatio voi vakuuttua siitä, että joku asia on pakko korjata nyt. Usein myös tietoisuus jostain virheestä voi johtaa siihen, että testausta tai muita laadunvarmistuskeinoja kuten katselmointeja päätetään lisätä, tai kohdentaa johonkin uuteen alueeseen. Keskustelu parantaa organisaation oppimista. Olisihan tavoitteena se, että ei toisteta samoja virheitä monta kertaa. Miten voitaisiin siis välttää samanlaisia virheitä tulevaisuudessa?

Muiden edessä annetut lupaukset toimenpiteistä jäävät myös ihmisten mieleen ja ne toteutetaan varmemmin.

Virhehallintakokouksen pitää olla säännöllinen

Hyvä frekvenssi kokoukselle on mielestäni kaksi kertaa viikossa, mutta kerrankin viikossa saattaa riittää. Frekvenssi riippuu paljon projektin tavoiteaikataulusta ja error inflowsta. Jos päivässä tulee useampia uusia bugeja, saattaa olla parempi pitää kokous pari kertaa viikossa, niin siinä ehditään kaikki tärkeät bugit käsitellä ilman että kokous venyy liian pitkäksi.

Olisi myös hyvä, jos joku, jolla on riittävästi aikaa, järjestää kokousta. Tuoteomistaja voi tehdä sen pienemmissä projekteissa, vähän isommissa paras ihminen on ehkä testaus lead- tai testipäällikkö. Vieläkin isommissa kannattaa ehkä jo harkita oikein virhehallintaroolia (Error manager).

Paljasta patternit

Virhehallintakokous voi myös auttaa organisaatiota paljastamaan tiettyjä patterneja. Onko tietyntyyppisiä virheitä liikaa? Miksi? Pitääkö jotain tiettyä testausta lisätä? Pitääkö kehittäjien muuttaa toimintatapojaan, jotta jotain tietyntyyppistä virhettä ei tulisi jatkossa enää niin paljon? Näihin asioihin kokouksen keskustelu ja tiedon jakaminen voi tuoda apua.

Kokous voi toimia myös muutosagenttina

Virhehallintakokous toimii myös tiimille ja organisaatiolle tietynkaltaisena seremoniana, missä virhetilanne hyväksytään.

Virhehallintakokous toimii myös tiimille ja organisaatiolle tietynkaltaisena seremoniana, missä virhetilanne hyväksytään. Tämä on tilanne missä olemme nyt – me voimme yhdessä päättää, mihin haluamme mennä. Virhekokous voi auttaa organisaatiota muuttamaan kulttuuria virheiden osalta. Jos on piilotteleva kulttuuri, kokouksen keskusteluilla voidaan ehkä alkaa muuttamaan kulttuuria suuntaan missä virheistä voidaan puhua avoimemmin. Kun huomataan, että virheiden tuominen päivänvaloon ei olekaan niin tuskallista, ja itse asiassa muillakin on virheitä, piilottelusta voidaan ehkä päästä hitaasti eroon.

Tietyllä tavalla tehdyt ja perustellut prioriteetti- ja korjataan/ei korjata päätökset myös opettavat organisaation eri tahoja siihen, mitkä virheet pitää korjata, ja mitkä ei. Ehkä osa virheistä voidaan korjata jo aikaisemmin, kun kaikille on selvää, että tätä ei ainakaan voi päästää tuotantoon.

Ajantasainen virhetieto mahdollistaa oikeat päätökset, ja hyvälaatuiset virheet on mahdollista korjata tehokkaasti ja nopeasti. Tämän takia tehokas virhehallintakokous on tavoittelemisen arvoinen.

PS: Aikaisemmin olen kirjoittanut bugihallinnasta täällä, täällä ja täällä.