Kävin puhumassa Finnish Test Assemblyssä laadun valmentamisesta. Kerroin kolme tarinaa laatukulttuurin kehittämisestä valmennuksen keinoin.
Ensimmäinen tarina kertoo kauniin joen varrella olevasta kylästä. Eräänä päivänä joessa havaitaan ruskeita kikkareita, jonka vuoksi kyläläiset palkkaavat jokivahteja tarkkailemaan ja keräämään kikkareita. Vuodet vierivät ja jokivahdit ovat kiireisiä. Lopulta eräs rohkea jokivahti päättää lähteä joen yläjuoksulle selvittämään, mistä roskaaminen johtuu. Hän onnistuu korjaamaan syyn, ja joen likaaminen loppuu. Jokivahti saa kylään palattuaan paljon kiitosta puhtaasta joesta, mutta myös muiden jokivahtien vihan niskoilleen, koska heille ei enää ole työtä. Kylässä keksitään kuitenkin tarjota jokivahtipalvelua muillekin kylille, joilla on samoja ongelmia. Näin jokivahdeista tulee maailmankuuluja, he saavat huippupalkkaa sekä lopulta kansainvälisen palkinnon puhtaiden jokien hyväksi tekemästään laatutyöstä.
Ensimmäisen tarinan opetuksia laadusta vastaaville:
Työskentele korkeammalla ravintoketjussa (tittelistäsi riippumatta)
Ratkaise heikon laadun syy, älä ainoastaan sen seurauksia (bugeja)
Tee itsestäsi korvaamaton tekemällä itsestäsi tarpeeton
Seuraava tarina kertoo ohjelmistokehityksestä. Mitä tapahtuu, kun ohjelmistokehittäjäsi toteuttaa uuden ominaisuuden, jossa havaitset virheen? Arvatenkin korjaatte yhdessä virheen ja toimitatte asiakkaalle toimivan ohjelmiston. Hienoa! Tosin ohjelmistokehittäjäsi on nopea oppimaan. Kun toistatte rutiinin muutaman kerran, hän todennäköisesti luottaa siihen, että havaitset hänen tekemänsä virheet jatkossakin. Opetit juuri hänelle, ettei laatu enää kuulu ohjelmistokehittäjän vastuulle.
Toisen tarinan opetuksia:
Älä hyväksy ohjelmointivirheitä organisaation “kulttuurina”
Valmenna ohjelmistokehittäjiäsi virheiden nollatoleranssiin
Kouluta ohjelmistokehittäjäsi löytämään itse tekemänsä virheet (älä vain ojenna virheitä hänelle, koska hän oppii luottamaan siihen)
Kolmas tarina kertoo virheettömän ohjelmistokehityksen yhtäläisyyksistä vuonna 1983 ja nykyään. Melvyn Estcourt julkaisi Sinclair ZX Spectrumille 1983 pelin nimeltään 3D Deathchase. Aikanaan tyylikäs “3D”-peli valittiin Your Sinclair -lehdessä yhdeksän vuotta myöhemmin 1992 kaikkien aikojen parhaaksi Spectrum-peliksi. Spectrumin ohjelmat myytiin C-kaseteilla eikä internetiä ollut vielä olemassa. Peleissä ei siis yksinkertaisesti voinut olla merkittäviä ohjelmointivirheitä.
Nykyään ohjelmistot ovat huomattavasti monimutkaisempia. Ohjelmistokerrokset ja komponentit helpottavat ohjelmistokehittäjän elämää, mutta niiden vuoksi joudumme luottamaan muiden kehittämiin ja ylläpitämiin laitteisiin, ohjelmistoihin sekä tietoliikenteeseen. Vaikka monimutkaisuus on lisääntynyt, on edelleen mahdollista kehittää virheettömiä ohjelmistoja. Parhaana esimerkkinä mieleeni on jäänyt Ekahau Oy:llä kehittämämme Ekahau Controller, jonka avulla hallitaan Ekahaun WLAN-paikannusjärjestelmän paikannustägejä. Tomi Mickelsson, Tomi Tirri, Pauli Misikangas sekä muut Ekahaun ohjelmistoinsinöörit kehittivät palvelinohjelmiston, tiedonsiirtoprotokollan ja verkkopohjaisen käyttöliittymän, jolla tägien asetuksia voidaan langattomasti tarkastella ja muokata. Tuotteesta ei saatu vuoden aikana yhtäkään virheraporttia, vaikka ohjelmisto oli päivittäin käytössä kymmenillä asiakkailla.
Tärkeimpinä syinä onnistumiseen oli ohjelmistokehittäjien asenne, johon yhdistyi ammattiylpeys, halu ottaa kokonaisvastuu käyttäjäkokemuksesta sekä kyky tunnistaa etukäteen tilanteita, jotka voisivat johtaa ohjelmistovirheeseen. Harrastuneisuus oli myös hyväksi, mutta se ei ole välttämätöntä.
Kolmannen tarinan opetuksia:
Palkkaa ohjelmistokehittäjiä, jotka ovat ylpeitä osaamisestaan ja haluavat ottaa kokonaisvastuun käyttäjäkokemuksesta
Tähtää virheiden nollatoleranssiin
Auta kehittäjiäsi ottamaan kokonaisvastuu käyttäjäkokemuksesta ja saavuttamaan virheiden nollatoleranssin
Lyhyt tarkistuslista laadun valmentamiseen ohjelmistokehityksessä:
Ohjelmistokehittäjäni ottavat täyden vastuun käyttäjäkokemuksesta
Ohjelmistokehittäjieni on mahdollista ottaa täysi vastuu käyttäjäkokemuksesta
Valmennan ohjelmistokehittäjiäni säännöllisesti kohti virheiden nollatoleranssia
Autan kehittäjiäni säännöllisesti poistamalla esteitä, jotka estävät heitä ottamasta täyden vastuun käyttäjäkokemuksesta
Toimin laadunparannuksen roolimallina edistämällä ketteriä testausmenetelmiä (esim. osallistumalla laadun kehittämiseen koko projektin alusta loppuun) ja automatisoimalla manuaalisia testaus- ja kehitysvaiheita.
Virheettömyyteen pyrkiessä kannattaa muistaa, että ketterässä kehityksessä pyritään oppimaan mahdollisimman nopeasti. Ihminen oppii nopeimmin onnistumalla ja epäonnistumalla puolet ajasta, jolloin syntyy väistämättä myös virheitä. Uuden oppiminen ja prototyyppaaminen kannattaa kuitenkin erottaa tuotantokoodin kirjoittamisesta. Viimeistään ennen kunkin ominaisuuden, sprintin tai tuoteversion julkaisua on syytä vakavoitua ja yhdessä varmistaa, ettei virheitä siirry omalta pöydältä yrityksen liiketoiminnan ja käyttäjien painolastiksi.