Bugin syy esiin tarkalla järjestelmällisyydellä

Tuotekehityksessä vastaan tulee useinkin ongelmia, jotka aluksi vaikuttavat täysin mystisiltä. Ei ole yksi tai kaksi kertaa, kun olen kuullut kehittäjän suusta sanat ”se ei ole mahdollista”, kun menen kertomaan ongelmasta. Toinen usein toistuva virhe on, että hypätään arvaten ilman tarkempaa faktojen selvitystä ”suosikkiselitykseen”.

Epäuskolla, purukumipaikkauksilla, pikafikseillä tai suosikkiselityksella on usein se seuraus, että ongelman todellinen syy jää selvittämättä, korjauksia ei saada aikaan, tai tehdään vaan ”näennäiskorjauksia”, ja ongelma kummittelee ja haittaa tiimin työtä tai asiakkaita jatkuvasti.

Tuotekehityksessä työskentelevien olisikin hyvä osata käyttää järjestelmällisen ongelmanratkaisun keinoja.

Yksinkertaista, rakas Watson

Tuotekehityksessä työskentelevien olisikin hyvä osata käyttää järjestelmällisen ongelmanratkaisun keinoja. Tämä muistuttaakin aika paljon salapoliisityötä, ja vertaus Sherlock Holmesiin onkin aika hyvä! Järjestelmällinen ongelmanratkaisu kirjattiin johdon oppaaksi ensimmäisen kerran 1960-luvulla Charles Kepnerin ja Ben Tregoen kirjassa The Rational Manager, mutta keinot itsessään ovat ikivanhoja, minkä todistaa se, että jo sata vuotta aiemmin Conan Doylen Sherlock-tarinat sisälsivät kaunokirjallisessa muodossa keinojen perusjutut.

Älä hyppää johtopäätöksiin

“It is a capital mistake to theorize before you have all the evidence. It biases the judgment.”

– Sherlock Holmes, A Study in Scarlet

Järjestelmällinen ongelmanratkaisu alkaa ongelman tarkalla kuvauksella ja tutkimisella. Tässä vaiheessa on ehdottoman välttämätöntä välttää teorioiden, suosikkiselitysten ynnä muiden johtopäätösten tekoa.

On fokusoitava energia siihen, että kerätään tietoa ongelmasta. Ongelman tutkimista helpottaa, jos sen otsikkotason kuvaus on mahdollisimman tarkka. Esimerkiksi: ”varaston lattia on liukas” tai ”varaston lattialla on öljyä” eivät ole tarpeeksi kuvaavia. Parempi otsikko olisi ”Suodattimen numero 1 puhdistusluukun alapuolella on öljyä”. Nykyään kun toimitaan sähköisten bugihallintatyökalujen kanssa, ongelman otsikkoa on helppo muuttaa. Virhehallinnassa olisikin hyvä ottaa tavaksi tarkistaa bugien otsikkotason kuvausta ongelman tutkimisen alkuvaiheessa, kunnes otsikkoon ollaan tyytyväisiä.

Kuvauksen tarkentaminen on olennaista

“Always approach a case with an absolutely blank mind. It is always an advantage. Form no theories, just simply observe and draw inferences from your observations.”    

– Sherlock Holmes, The Adventure of the Cardboard Box  

Seuraava tutkimuksen vaihe on tarkempi kuvaus. Tässä auttaa seuraavat kysymykset: MITÄ, MISSÄ, MILLOIN, KUINKA PALJON.

Näihin kysymyksiin vastausten etsiminen lisää tutkijan tietämystä ongelmasta. Milloin ongelma havaittiin ensimmäisen kerran? Miten usein se toistuu? Kuinka paha ongelma on? Missä ongelma toistuu?

Seuraava askel on hieman hankalampi muistaa, mutta se tarjoaa erittäin paljon lisätietoa ongelmasta. Pitäisi jatkojalostaa ylläolevien kysymysten osalta, missä ongelma VOISI TOISTUA, mutta EI TOISTU. Tarkoituksena on siis hakea tietoa siitä missä ja milloin ongelma esiintyy ja missä taas ei. Tapahtuuko ongelmaa vain suurissa järjestelmissä, ei koskaan pienemmissä? Tapahtuuko se vain tiettyyn aikaan vuorokaudesta, aina aamulla kello 4, ei koskaan muulloin? Tapahtuuko se vain, kun käyttäjä loggaa sisään? Tapahtuuko se vain, jos useita käyttäjiä loggaa sisään yhtä aikaa, ei muulloin?

Kaikilla näillä kysymyksillä ja vastauksilla tarkennetaan tutkijoiden tietämystä ongelmasta, ja tätä selvitysvaihetta kannatta jatkaa, kunnes tutkijaporukalle alkaa tulla olo, että nyt on selvitetty tarpeeksi ja nyt voidaan edetä seuraavaan vaiheeseen.

Round up the suspects!

“There should be no combination of events for which the wit of man cannot conceive an explanation.”

– Sherlock Holmes, The Valley of Fear

Seuraava vaihe on mahdollisten syykandidaattien löytäminen. Tämä vaihe muistuttaa brainstormingia, ja onnistuu ehkä parhaiten pareittain tai pienellä ryhmällä. Edelleen olisi tässäkin vaiheessa syytä muistaa kurinalaisuus eikä edetä ennenaikaisesti seuraavaan vaiheeseen, syykandidaattien testaamiseen.

Kun riittävästi syykandidaatteja on löydetty, kannattaa seuraavaksi miettiä, mitkä ovat niiden vaikutusmekanismit. Mikä sequence of events tarvitaan, että juuri tämä syykandidaatti selittää kuvatun ongelman? Kuinka todennäköinen tuo tapahtumasarja on? Jos ollaan pystytty rakentamaan vaikkapa kolme mahdollista syykandidaattia, ja kahden niistä tapahtumasarjan todennäköisyys on aika matala, ja yhden todennäköisyys on huomattavasti korkeampi, on aika selvä mitä seuraavaksi pitää tehdä.

Mieti todennäköisyyksiä – ja testaa todennäköisin syy ensin

“When you have eliminated the impossible, whatever remains, no matter how improbable, must be the truth.”

– Sherlock Holmes, The Sign of Four

Seuraavaksi pitää miettiä millaisella kokeella tai testillä varmistetaan kunkin syykandidaatin syyllisyys. Sitten vaan yksinkertaisesti lähdetään tässä todennäköisyysjärjestyksessä testaamaan, mikä syykandidaatti selittää käytöksen. Testaamista helpottaa valtavasti, jos ongelma on helposti ja tiedetyin stepein toistettavissa.

Kun syyllinen löytyy, on jäljellä enää ongelman korjaus ja muut tarvittavat toimenpiteet, mutta tämä on yleensä aika paljon helpompaa kuin tuon syyn löytäminen.

Järjestelmällinen ongelmanratkaisu on opittavissa

Järjestelmällisen ongelmanratkaisun keinoja käyttäen mysteeribugien selvitys helpottuu ja nopeutuu huomattavasti.

Järjestelmällisen ongelmanratkaisun keinoja käyttäen mysteeribugien selvitys helpottuu ja nopeutuu huomattavasti. Keinovalikoiman ymmärtäminen olisikin olennaista kaikille tuotekehityksessä työskenteleville, projektipäälliköille, product ownereille, kehittäjille, testaajille ja myös asiakastuessa toimiville. Yhteisellä näkemyksellä saadaan bugeihin jo alusta alkaen hyvä otsikko ja mahdollisimman hyvät kuvaukset. Syykandidaattien hakemisella ja todennäköisyyksien miettimisellä päästään nopeasti root causen jäljille.

Ongelmanratkaisun metodiikkaa on syytä opetella ja harjoitella. Contribyten kurssimoduli Järjestelmällinen ongelmanratkaisu voidaan pitää joko 2 tunnin moduulina normaalin Scrum- tai Agile-koulutuksen osana, tai sitten se voidaan laajentaa käytännön harjoituksin ja case-kuvauksin puolen päivän tai koko päivän mittaiseksi. Ota yhteyttä meihin ja parannetaan sinun tiimin tai organisaation ongelmanratkaisukykyä!

Tutustu myös Bugiblogi-sarjan muihin osiin! Ensimmäisessä osassa käsiteltiin bugien kuvausta, toisessa osassa bugien korjaamisen virtausnopeuden tärkeyttä. Kolmannessa osassa kuvasin hankalien bugien ratkaisua ”vyöryttämällä” ylivoimaisin voimavaroin ongelma ratkaisuun.

P.S. Haluatko pysyä perillä Contribyten uutisista sekä koulutuksista ja tapahtumista? Tilaa uutiskirjeemme!