Aina kun tulee kysymys huonoista mittareista, tulee mieleeni netflixistä löytyvä loistava dokumentti Vietnamin sodasta. Miten Vietnamin sota ja tuotekehityksen mittarit liittyvät toisiinsa? Vietnamissa USA:n armeija soti ensimmäisen kerran sissitaktiikkaa käyttävää vastustajaa vastaan. Kuten kaikki historiaa tuntevat muistavat, sota oli sekava, verinen ja hankala suunnitella. Muistuttaako yhtään ohjelmistotuotekehitysprojektia?

Miten mitata sekavaa ja uudenlaista tilannetta?

Yhdysvaltain sotilasjohto koetti keksiä mittaria, jolla voisi osoittaa sodan etenevän toivotulla tavalla. Lähes jokainen taistelu päättyi USA:n armeijan voittoon, mutta silti vihollinen ei antanut periksi, ja vallatut kohteet jouduttiin valtaamaan yhä uudelleen ja uudelleen.

Kuolleet viholliset menestyksen mittarina

Koska sodan perinteistä mittaria, rintaman sijaintia ei voinut enää vaihtelevassa sissisodassa käyttää, armeijan johto keksi alkaa mitata sodan edistymistä kuolleiden vihollisten määrällä. Jos omia sotilaita kuoli jossain operaatiossa vain muutama, mutta vihollisia kuoli vaikkapa sata, niin olemmehan selkeästi niskan päällä. Pian koko sotaa mitattiin sillä, kuinka monta vihollistaistelijaa sinä päivänä oli löytynyt kuolleena.

Maksimoidaan mittarin näyttämä keinolla millä hyvänsä

Tässä mittarissa oli vain muutama iso ongelma. Ensinnäkin, kommunistijohtoisessa Pohjois-Vietnamissa viis veisattiin kuinka paljon omia kuoli. Toiseksi, Vietnamin kansa koki taistelevansa olemassaolonsa puolesta invaasiota vastaan. Ja kolmanneksi; sissitaistelijalla kun ei ole univormua, hän oli yllättävän paljon siviilin näköinen, ja kuolleelta ei voi enää kysyä mitään. Pian joka ikinen taistelun jälkeen löytynyt ruumis oli vihollistaistelija. Mittari johtikin siihen, että sissisotaan väsyneet joukot alkoivat nähdä kaikki siviilitkin vihollisena. Sota, jonka piti pelastaa Vietnamin kansa kommunismilta, muuttuikin turhaksi taisteluksi, jota ei halunnut kukaan.

En väitä, että lopputulos johtui mittarista, mutta itselleni on aina tuon dokumentin katsomisen jälkeen tullut mieleen ”kuolleet viholliset” -mittari, kun keskustellaan huonoista mittareista.

Millainen on huono mittari

Hyvä tuotekehityksen mittari mittaa jotain mikä on arvokasta, tai jotain mikä kiistatta johtaa johonkin arvokkaaseen. Huono mittari taas mittaa toissijaisia asioita, tai on altis ”pelaamiselle”, jossa tiimi alkaa tehdä asioita, jota mitataan. Huonolle mittarille voi keksiä monta eri ominaisuutta, mutta ainakin nämä kolme tulevat mieleen

• käänteinen kannustin
• altis väärinkäytölle
• madaltaa tiimin mielialaa

Käänteinen kannustin

Huono tuotekehityksen mittari saattaa kannustaa tiimiä tekemään ihan vääriä asioita, tai viemään projektia väärään suuntaan. Esimerkkinä tulee nyt mieleen vaikkapa bonustavoite, mikä on lukittu vuosi aikaisemmin, ja vaatii jotain ominaisuutta, mikä tuntui hyvältä vuosi sitten, mutta mitä ei enää oikeastaan tarvittaisi. Tiimi saattaa kokea helpommaksi vaan tehdä ominaisuuden, joka bonuksissa lukee, vaikka siinä ei mitään järkeä enää olekaan, kuin alkaa taistella bonustavoitteiden säätämisen puolesta.

Altis väärinkäytölle

Jos mitataan väärää asiaa, kuten vaikkapa jäljempänä esitettävää commit countia, on itsestään selvää, mitä tapahtuu. Committeja aletaan tekemään urakalla. Yksi tunnissa? Kaksi tunnissa? Mitä tämä enää kertoo meille? Mittari muuttuu arvottomaksi tosi nopeasti.

Madaltaa tiimin mielialaa

Jos tiimi vaistonvaraisesti kokee, että mitattava asia ei oikeasti ole arvokas, johdon seuranta ja fokusointi tähän turhaan mittariin vain madaltaa tiimin fiilistä. Oikein toimiva mittari kannustaa, ei lannista.

Huono mittari mittaa toissijaisia asioita tai on altis ”pelaamiselle”.

Huonoja tuotekehityksen mittareita

Speksimuutosten määrä (Changes to specification)

Jos aletaan mitata sitä, kuinka monta kertaa tai kuinka paljon speksi (tai vaikkapa EPIC) on muuttunut toteutuksen aikana, mistä se kertoo? Kertooko muutosten vähäinen määrä siitä, että speksi saatiin alussa tehtyä tarpeeksi hyvin? Vai kertooko se siitä, että ei olla yhtään haettu tai saatu palautetta? Jos taas muutoksia on paljon, kertooko se siitä, että on saatu palautetta, vai siitä, että ei oltu ennen liikkeellelähtöä tehty ollenkaan tarpeellisia määrittelytöitä tai konseptin tutkimista? Speksimuutosten määrä on huono tuotekehityksen mittari. Mikä voisi toimia paremmin?

Kun mietitään sitä, mikä johtaa hyvään määrittelyyn:

• riittävä konseptointi
• idean epävarmuuksien kartoitus
• epävarmuuksien testaus ja palautteen hakeminen
• refinement ennen toteutusta
• tarpeellinen toteutusvaiheen pilkkominen
• toteutuksen julkistus pienissä osissa ja palautteen seuranta

Näitä katsoessa on varmaan selvää, että muutosten määrä on huono tuotekehityksen mittari. On mahdotonta korvata sitä yhdellä ja ainoalla toisella mittarilla, joka olisi tarpeeksi helppo mitattava. Ehkäpä paras vaihtoehto on tiimin oma arvio siitä, miten hyvin he ovat onnistuneet tällaisessa Lean Startup henkisessä ketterässä vaatimusmäärittelyssä.

Yksikkötestikattavuus (Unit test coverage)

Yksikkötestejä tarvitaan, mutta onko niiden testikattavuuden oltava 100%? Vai 80%? Vai onko niin, että mikä tahansa prosenttiluku on ”testing smell”? Yksikkötestien määrän tai osuuden mittaaminen tuntuu vievän huomiota väärään suuntaan. Oikeampia kysymyksiä ovat, mitä testejä oikeasti tarvitaan ja onko kaikilla kehittäjillä osaamista ja rutiineja rakentaa ne osana Definition of Donea? Lue tästä vielä hauska tarina mitä kehittäjäguru vastasi tähän kysymykseen.

Velocity

Mitä ihmettä? Miten velocity, ketteryyden ydinkonsepti, voi olla huono tuotekehityksen mittari? Mutta juuri näin on. Velocity on paras ohjenuora tiimille siihen, kuinka paljon asioita ladata seuraavaan sprinttiin. Velocity ja siitä johdettava burn-up kaavio on ainoa toimiva keino ennustaa monimutkaisien projektien valmistumista. Mutta velocity soveltuu todella huonosti vertailuun tiimien välillä tai edes tiimin oman historian vertailuun.

Velocity perustuu tiimin omaan arvioon työmäärästä, joka yleensä tehdään joko storypointeilla tai ideaaliaikayksiköllä. Tämä arvio ei ole verrannollinen tiimien välillä, eikä sitä missään tapauksessa saa siihen käyttää. Toisen tiimin sprinttivelocity saattaa olla 40, toisen 90, ja silti lopputulos ja tuottavuus tiimeissä saattaa olla yhtä hyvä tai jopa ”väärinpäin”.

Omasta mielestäni velocity toimii huonosti myös tiimin oman kehityksen mittarina. Siinä on mielestäni sisäänrakennettu palautemekanismi; kun tiimi oppii tekemään jotain tehokkaammin tai kehittää vaikkapa työtä avustavia työkaluja, nouseeko velocity? Ehkä vähäksi aikaa, mutta kohta uusien tarinoiden arvioitu effort pienenee, koska tiimi sisäistää uusien työkalujen tai toimintatapojen hyödyt. Tarina, mikä oli ennen 10 tarinapistettä, onkin nyt enää 5. Oma kokemukseni on, että tiimin velocity muuttuu olennaisesti vain kun, jäseniä tulee tai lähtee tiimistä. Kaikki muut muutokset ovat itseään korjaavia.

Koodirivien määrä (Lines of Code, LOC)

Jos aletaan mitata koodirivien määrää, niin sitten kehittäjät tekevät enemmän koodia. Halusitko enemmän vai parempaa koodia? Suurin osa koodiriveistä on kuitenkin muuta, kuin toiminnallista koodia (kommentteja, siirrettyä koodia, tyhjiä rivejä, avainsanoja, yms.). Jos mitataan koodirivien määrää, alkavat kehittäjät pelata peliä, jossa kaikki toteutetaan ”pidemmän kaavan mukaan”. Haluatko oikeasti kannustaa heitä siihen? Mihin se johtaa vuosien päästä? Valtavaan määrään koodia, jonka designiin ei ole kiinnitetty huomiota, ja joka on lukittu sen luoneiden ihmisten mielenmaisemaan.

Käytetty aika (hours spent)

Olen aina ollut sitä mieltä, että ketterästi toimivan tiimin pitää arvioida jonkin asian työmäärää, effortia, ennen aloittamista. Tämä pitää tehdä, kun asiasta on keskusteltu ja se on määritelty tarpeeksi hyvin kirjallisesti. Tällä arviolla on suuri merkitys, koska se toimii velocityn rakennuspalikkana, ja päätöksentekokriteerinä tiimille, onko joku asia liian iso toteutettavaksi kerralla. Mutta sen seuranta, miten kauan jotain asiaa on tehty, on täysin turhaa.

Tuntiseuranta tuotekehityksen mittarina on hyödytöntä, koska se saattaa vaan antaa turhaa ”tavoitteellisuutta”. Jos jonkin asian piti kestää arvion mukaan 10 tuntia, ja siihen on mennyt 9 tuntia, kuinka paljon on jäljellä? 1 tunti? Väärin. Asia valmistuu, kun se läpäisee kaikki sen hyväksyntäkriteerit, ja on testattu niin, ettei siitä löydy bugeja. Kymmenen tunnin täyttyminen saattaa antaa kehittäjälle tunteen, että ”kai se on valmis, kun aika on käytetty”, eikä hän mieti onko se oikeasti valmis. Toisaalta, jos kehittäjä saakin asian tunnissa tehtyä, niin mitä hän tekee loput 9 tuntia?

Hours spent -mittari on kuin mittaisit miten kauan teiniltä kestää leikata ruoho. Pyydäpä teiniä leikkaamaan ruoho, ja laita kello käyntiin. Jos ruohonleikkuuseen pitäisi mennä vaikkapa 2 tuntia, ja kello näyttää 3 tuntia, onko ruoho leikattu? Mittari on huono, koska se on tarpeeton, harhaanjohtava eikä anna mitään hyödyllistä tietoa.

Storypoints per hour

Tarinapistetehokkuuden vertailu eri kehittäjien välillä on myös mittari, joka johtaa siihen, että kehittäjät alkavat pelaamaan mittarin kanssa. Tiimin kun pitäisi olla itseohjautuva, eli tiimi valitsee sprint backlogilta oikeaksi katsomassaan järjestyksessä tehtäväksi backlog itemeja. Miten systeemi toimii, jos kehittäjät tietävät, että heitä arvostellaan sen suhteen, kuinka paljon tarinapisteitä he saavat valmiiksi per aikayksikkö? Johtaako se kenties työmääräarvioiden pullisteluun? Entä johtaako se siihen, että ”hankalan oloiset” tarinat, joilla on ”liian pieni” työmääräarvio, liikahtavat sprinttibacklogilta kovin vastahakoisesti eteenpäin? Varmasti.

Entä miten tällainen kehittäjien välinen kilpailutilanne vaikuttaa tiimihenkeen tai tekemisen fiilikseen? Hankala nähdä, että se parantaisi sitä.

Commit count

Commit count on vastaavanlainen mittari kuin edellinenkin. Vaikka tavoitteena on ehkä se, että kehittäjät pitäisivät omia muutoksiaan enemmänkin pieninä kuin suurina, niin commit-määrän seuranta johtaa helposti siihen, että tulee tavoitteeksi keinotekoisesti tsekata sisään mahdollisimman pieniä muutoksia, jatkuvasti. Miten tämä vaikuttaa vaikkapa koodikatselmuksiin, tiedostojen versiohistorian seurattavuuteen? Tämäkin mittari on huono, koska se nopeasti tekee itsensä tarpeettomaksi.

Ratkaistut ongelmat (Issues resolved)

Periaatteessa joskus tämä mittari voisi toimiakin, mutta tämänkin osalta riski on se, että aletaan nähdä siviilitkin vihollistaistelijoina. Eli, kirjataan pienimmätkin asiat ongelmiksi, joita sitten päästään ratkomaan. Eikö tämä mittari myös kannusta tekemään sellaista kehitystä, että korjattavia ongelmia on mahdollisimman paljon? Koska jos seurataan ongelmia, pitää niitä olla. Mikä onkaan sitten kannustin tehdä parempaa designia tai kehityksenaikaista ongelmien proaktiivista ratkaisua?

Koodimuutosten määrä (code churn)

Koodimuutosten määrän mittaaminen on ongelmallista, koska on hyvin hankala tietää, mistä muutosten määrä johtuu. Johtuuko se siitä, että on saatu palautetta prototyyppiin tai ”MVP” tyyliseen toteutukseen, ja säädetty toteutusta vastaamaan palautetta? (hyvä asia). Vai johtuuko se siitä, että vaatimuksien määrittely alkuvaiheessa on puutteellista (huono asia). Vai johtuuko se siitä, että toteutusta on refaktoroitu useaan otteeseen, ja tehty siitä mahdollisimman helposti luettava ja ”future proof”? (hyvä asia). Vai johtuuko se siitä, että organisaatiossa ei tehdä minkäänlaista ideoiden esikehitystä ja testausta, ja toteutus muuttuu sen takia massiivisesti lähes aina (huono asia)?

Kuten näemme, mittari ei anna tietoa siitä, onko tilanne hyvä vai huono, ja sen takia se on vaarallinen.

Mitä pitäisi tehdä, jos epäilet, että teillä käytetään huonoja tuotekehityksen mittareita

Miettikää yhdessä, miksi kyseistä mittaria käytetään. Mitä on oikeasti tarkoitus selvittää? Millainen mittari voisi toimia paremmin?

Hyvän tuotekehityksen mittarin ominaisuuksia ovat seuraavat

• se tarjoaa arvokasta ja olennaista tietoa
• se mittaa, tehdäänkö asioita, joiden tiedetään johtavan hyvään lopputulokseen
• saatko haluamiasi lopputuloksia
• se auttaa tiimiä selvittämään, onko tiimin tilanne menemässä parempaan vai heikompaan suuntaan
• se kertoo, onko sinulla ongelma, ja osoittaa siihen suuntaan, missä ongelma mahdollisesti on

Tuotekehityksen mittarit ovat parhaimmillaan, kun ne eivät säily samanlaisina ja muuttumattomina vuosikausia, vaan organisaatio ja tiimi miettii, mikä on kulloinkin tärkeää, ja vaihtaa mittareita tilanteen mukaan.

Lue täältä lisää tuotekehityksen mittaamisesta tai kysy meiltä, kuinka mittareita voisi parantaa!