Olen tähän asti ajatellut, että ongelmanratkaisukyky käsittää lähinnä riittävän kovan pään. Kaikki ongelmat ratkeavat yrittämällä niihin erilaisia ratkaisuita. Hakkaamalla päätä seinään riittävän pitkään, seinä hajoaa. Lopulta löytyy ratkaisu joka toimii!
Ajattelin tällaisen ”problem solving by perkeleen” olevan ihan hyvä tapa ratkaista asioita. Näin jopa kunnia-asiana, että useita erilaisia ratkaisuita rakentamalla löytyy lopulta hyvä vaihtoehto.
Onko tämä teidän kehitystyössä tavallista? Kuuletko tällaisia lauseita kehitystiimiltä?
- ”Kokeilen ensin tätä ja katsotaan sitten.”
- ”Mikähän tässä nyt on, toimisikohan tämä jos tekisin näin…”
- ”Tähän voisi kokeilla tällaista apukirjastoa.” (Javascript-maailmassa)
Näin tein itsekin kunnes luin kirjan. Lopussa paljastan vielä minkä kirjan!
Ratkaisu liian aikaisessa vaiheessa vaikeuttaa ymmärtämistä
Luen paljon kirjoja ja suurin osa luetusta tulee samaa vauhtia ulos kuin menee sisäänkin. Välillä vastaan tulee kirja, joka jysähtää. Tällä kertaa kirja osui ytimeen niin hyvin, että haluan jakaa keskeisen löydöksen myös teille.
Ja se on tässä:
Kun ymmärtää ongelman, ratkaisu on ilmeinen.
Tadaa! Noin yksinkertaista.
Lause tarkoittaa sitä, että kun ymmärtää ongelman läpikotaisin, niin ratkaisuvaihtoehtoja tai korjauksia on noin yksi. Tämä ratkaisu on niin ilmeinen, ettei useita ratkaisuvaihtoehtoja tarvita.
Erilaisten ratkaisuiden esittäminen liian aikaisessa vaiheessa hankaloittaa ongelman ymmärtämistä. Ratkaisuyritykset lisäävät vaihtelua, hämärtävät kokonaisuutta, luovat kohinaa ympärille ja vievät huomion pois itse ongelmasta.
Ratkaisukeskeisyydestä eroon pääseminen on kuitenkin vaikeaa. Siitä kertoo tarina seuraavasta aamusta.
Seuraavana aamuna…
Kirjan lukemisen viimeistelyn jälkeisenä aamuna olin taas ongelman edessä. Palvelimen automaattitesti ei mennyt läpi.
Palvelin tarkistaa saako dokumenttiin tehtyjä muutoksia tallentaa. Dokumentin lukittuja kenttiä saa muokata vain korkeimmillä käyttäjäoikeuksilla. Kaikki käyttäjät voivat muokata lukitsemattomia kenttiä. Automaattitesteissä tämän viimeisen asian testaava testi ei mennyt läpi.
Olin innoissani kokeilemassa uutta ongelmanratkaisutapaa tähän ongelmaan. Halusin ymmärtää ongelman perinpohjaisesti. Avasin koodit, lisäsin debuggausrivejä, perkasin koodia ja ajonaikaisia muuttujia läpi ymmärtääkseni toiminnallisuuden kulun.
Huomasin, että dokumenttien vertailussa verrattiin kahta kenttää, joiden ominaisuudet olivat eri järjestyksessä. Tutkin Javascriptin dokumentaatiota ja huomasin, että Javascriptissä ominaisuudet voivat olla eri järjestyksessä ja sen vuoksi vertailu voisi mennä pieleen.
Vaihdoin siis vertailun. Korjasin koodin kääntymään ja ajoin testit innokkaan optimismin vallassa. Olin oppinut uuden asian Javascriptistä, ongelmaan oli vain yksi järkevä ratkaisu ja se ratkaisu vaikutti hyvältä!
Mutta testi ei mennyt läpi.
Lyhyet chatit kokeneempien Javascript-vääntäjien kanssa (työkaverit, Goforen paras työsuhde-etu) ja kohta esillä oli lyhyet testikoodit. Testikoodit olivat hyvin lyhyet ja kokeilivat vain ongelman syyksi epäiltyä vertailua. Ne osoittivat, että alkuperäinen vertailu olikin toimiva. Olin ymmärtänyt ongelman väärin. Olin tehnyt väärän korjauksen ja vika oli toisaalla.
Lopulta ongelma oli itse testissä. Sovellus estää usean käyttäjän yhtäaikaisen muokkauksen aikaleimoja vertailemalla. Edellinen testi muokkasi dokumenttia tallentamatta aikaleimaa, jolloin tämä seuraava testi ei mennyt läpi.
Tarinan opetus: Ongelman syyn todistaminen oli tekemättä. Halusin mieluummin ratkaista ongelman kuin ymmärtää sen. En ollut tarpeeksi syvällä ongelmassa ja ratkaisu oli väärä.
Ongelma ei ole kenenkään vika
Kirja oli nimeltään Toyota Kata Managing Improvement Adaptiveness (löytyy Amazonin kirjakaupasta http://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238 ja Goforen kirjahyllystä https://gofore.com/en/join-the-team/) Toyotan henkilökunnan tapa ratkaista ongelmia on keskeistä yhtiön tavassa kehittää omaa toimintaa. Yhtiö myös kehittää mentoreiden avulla henkilökunnan ongelmanratkaisutaitoja systemaattisesti.
Toyotalta on peräisin paljon useita tuotantoon liittyviä keksintöjä, joita länsimaissa on otettu käyttöön 70-luvulta lähtien. Toyotan näkökulmasta nämä keksinnöt ovat tulosta tästä henkilökunnan taidosta ratkaista ongelmia. Toyota ei menesty keksintöjen vuoksi vaan taitavan henkilökunnan vuoksi.
Keskeinen elementti Toyotan ongelman ymmärtämisessä on asialähtöinen näkökulma. Kirjassa toistuvia käytäntöjä olivat ”mennään katsomaan” ja ”näytä minulle”. Ketään ei syyllistetä ja kaikki osallistuvat ongelman ymmärtämiseen kuin muurahaisia tutkivat lapset. Aivan mahtavia asiakeskeisiä käytäntöjä ihmisten kanssa työskentelyyn!
Toyotalla ongelmat eivät sisällä negatiivisia tai positiivisia mielikuvia. Ne ovat vain ongelmia.
