Silloin tällöin tiimeille tulee vastaan harvinaisen hankala bugi. Se voi olla esimerkiksi ongelma, jota ei tiimin käytettävissä olevilla testiympäristöillä saada toistettua, tai joka toistuu vain harvoin, mutta suurta harmia aiheuttaen. Usein käy myös niin, että kun bugin tutkiminen on hankalaa, eikä siitä saada oikein kunnolla tietoa, tiimin motivaatio ja fiilis käyttää aikaa bugin ratkomiseen laskee. Tuntuu siltä, että kaikki, jotka bugia yrittävät tutkia, toistaa tai selvitellä, hukkaavat vain aikaansa.

Jos hankalan bugin antaa jäädä unohduksiin, se nousee aika ajoin kuitenkin uudestaan tapetille. Asiakkaat, joita bugi haittaa ja jotka tietävät siitä ja ovat raportoineet sen, turhautuvat kun ongelmaa ei saada ratkaistua. Tiimi saa toistuvia ”Ei kai taas!” -fiiliksiä: bugi, jonka oli toivottu vaipuneen unholaan, tuli taas esiin ja vaatii jälleen huomiota. Tällaisissa tilanteissa bugia ratkovan ihmisen mieli on jo valmiiksi lannistunut. ”Eihän tätä aikaisemminkaan selvitetty, miksi siis nyt?” Onnistumisen todennäköisyys on pieni, ja motivaatio matala.

Lannista bugi, älä tiimiä!

Ihmiset ratkovat ongelmia paljon paremmin ja tehokkaammin, kun heidän ajatuksensa ja aivonsa eivät ole negatiivisilla ajatuksilla alustettuja.

Tällaisessa tilanteessa olisikin ensiksi syytä tunnistaa tarve käyttää ylivoimaa bugin selvittämiseen: tilanne on sellainen, johon tarvitaan koko tiimin aivoja ja voimavaroja. Lisäksi porukalle olisi luotava mielentila, jossa ihmiset ajattelevat, että nyt tai ei koskaan tämä juttu ratkeaa, tavalla tai toisella. Ihmiset ratkovat ongelmia paljon paremmin ja tehokkaammin, kun heidän ajatuksensa ja aivonsa eivät ole negatiivisilla ajatuksilla alustettuja. Porukalle olisi siis saatava positiivinen fiilis – sellainen, että onnistuminen on todennäköistä, eikä kukaan ole ongelman kanssa yksin.

Kun bugi on vakava, eikä millään selviä tai ratkea, vaan alkaa vaikuttaa aikasyöpöltä, niin tiimin olisi syytä porukalla laittaa muut työt sivuun ja keskittyä ratkomaan ongelma ”once and for all”. Termiä ”Shock and Awe” ei ollut vielä edes keksitty, kun kenraali Schwarzkopfin johtamat liittoutuneet kukistivat Saddamin ensimmäisessä Irakin sodassa. Termi viittaa massiivisen ylivoiman käyttöön heikomman vihollisen kukistamiseen mahdollisimman nopeasti. Samaa strategiaa voidaan käyttää myös hankalien bugien kanssa.

Ole tilanteen herra

Product Owner on avainasemassa tilanteen huomaamisessa, koska hänellä on käsissä tuotekehitysporukan hommien priorisointi. Hän voi – ja hänen myös täytyy – tässä tilanteessa tehdä selväksi, että KAIKKI MUU TYÖ on kiellettyä, kunnes ongelma on selvitetty. Tämä on tehokas keino sille, että koko tiimin (tai tiimien) huomio kiinnittyy täysin ratkaistavaan ongelmaan. Toinen tehokas keino on fyysisesti matkustaa paikalle. Itsekin olen joutunut useampaan kertaan työurani aikana lähtemään pikaisesti maapallon toiselle puolelle, kun tilanne on katsottu niin pahaksi, että paikalle on pakko mennä, vaikka se ottaa aikaa ja vaivaa.

Tiimin ja Product Ownerin sekä myös asiakastuesta vastaavien ja jopa tuotepäällikönkin olisi syytä osata tunnistaa tilanne, jossa tarvitaan ”Shock and Awe” -strategiaa jonkun ongelman selvittämiseen. Tällä tavalla tiimi ei pääse lannistumaan negatiivisilla ajatuksilla ongelmasta, vaan asiat saadaan selviämään nopeasti ja asiakkaat säilyvät tyytyväisinä.

Bugiblogisarjan kahdessa ensimmäisessä osassa kerroin yleisistä ongelmista itse bugeissa ja bugien virtauksen tärkeydestä. Viimeisessä osassa kerron järjestelmällisten ongelmanratkaisukeinojen tärkeydestä bugien selvittämisessä.