Tuottavuuden mittaaminen kehittäjän näkökulmasta

Vuoden 2022 lopulla Elon Musk, ostettuaan Twitterin, irtisanoi runsaasti työntekijöitä. Useat journalistit, joista monilla on taustaa piilaakson suurissa yrityksissä, kertoivat kuulleensa lähteiltään, että tuotettujen koodirivien määrä on ollut olennaisena mittarina irtisanomisista päätettäessä.

https://twitter.com/zoeschiffer/status/1597582642601283584
https://twitter.com/GergelyOrosz/status/1588907407002185729
https://twitter.com/appyg99/status/1588917038881595392

Tässä kirjoituksessa käyn läpi muutamia yleisimpiä eri tapoja mitata kehittämisen tuottavuutta. Pääasiassa keskityn mittaukseen, jossa mittari on samalla tavoite, mutta sivuan myös eri mittareiden mahdollistamaa vertailua oman organisaation sisällä ja ulkopuolella, josta käytän ilmaisua tutkiva mittari ja siinäkin analysoin vain tuottavuuden mittaamista. Ja mittarit toimivat tutkivina lähinnä silloin, kun mittari ei ole ollut tavoitteena vääristämässä tulosta.

Aluksi on hyvä huomioida, millaisia kehittäjät ovat ihmisinä. Oman kokemukseni mukaan he ovat ensisijaisesti älykkäitä ongelmanratkaisijoita. Muita piirteitä ovat kasvun janoaminen, moraalitaju, vahva taipumus optimoida tehokkuutta, leikkisyys ja kokeilunhalu, tietämyksen arvostaminen ja tavoitteiden saavuttaminen. Tällaista ihmistä varten on hyvin hankala keksiä toimivaa objektiivista tavoitejärjestemää, sillä mainittujen ominaisuuksien lisäksi hänen työnkuvansa on suurelta osin rajoitteiden kiertämistä ja täysin uusien ratkaisujen keksimistä. Kehittäjien joukossa on myös huomattava määrä epäuskoa tuottavuuden mittaamista kohtaan.

Koodirivien lukumäärä

Tämä on hyvin yleinen mittari ja käytännössä aina käytettävissä, sillä ohjelmistokehitystä ei yleensä tapahdu ilman koodia. Järjestelmien karkea koko saadaan monesti laskettua näin, mutta koodirivimittauksen ongelmana on kannustaminen hyvin tehottomaan kehittämiseen. Yhden koodirivin saa muutettua 20:ksi riviksi muutamissa minuuteissa, vaikka koodiin ei edes laitettaisi mitään typerää. On olemassa hyvin paljon erilaisia suunnittelumalleja (ns. patterneja), joilla on jokin tarkoitus, mutta joiden sopivuuden tarkka analysointi vaatii paljon perehtymistä juuri siihen tiettyyn toimintoon ja kontekstiin joihin niitä ollaan laittamassa, jotta voisi sanoa, onko ratkaisu tarpeellinen. Ja silloinkin voi jäädä useita näkemyseroja tehdäänkö yksinkertaisesti vai haetaanko joustavuutta johonkin tiettyyn suuntaan.

Koodiin pätee myös sama kuin muuhunkin viestintään eli lyhyesti kirjoittaminen vaatii monesti paljon enemmän aikaa, koska asioita joutuu tiivistämään, toistoa pitää poistaa, ilmaisun selkeyttä täytyy miettiä jne. Koodi syntyy yleensäkin lähtökohtaisesti liian pitkänä ja sitä myötä aikaavievänä ylläpitää. Tilannetta ei helpota se, että tavoiteltaisiin tarkoituksella vielä enemmän koodia ylläpitoriesaksi. Turhan koodin poistaminen on myös tärkeää, jotta ylläpito ei vaikeudu, mutta tämä mittarihan joko pitää sellaista neutraalina tai jopa rankaisee siitä.

Yksilöiden välillä on jonkin verran vaihtelua koodirivien tuottamisessa, mutta tutkivana mittarina se on kohtalainen karkeiden arvioiden tekemisessä.

Versionhallinnan committien lukumäärä

Commit on kehittäjän yhden muutoksen tallennus koodipohjaan, eli se voi olla esim. yhden rivin lisäys tai tuhat muutettua riviä. Samat hyvät ja huonot puolet pätevät kuin koodirivien mittaamisessa eli committeja syntyy käytännössä aina, mutta mittaria on helppo pelata niin, että tehdään tarpeettomia committeja. Työajan välittömän käyttämisen lisäksi historian lukeminen vaikeutuu esim. selvityksiä tehtäessä ja tiettyyn version palaaminen hankaloituu.

Yksilöiden välillä on paljon vääristävää vaihtelua, eli jotkut tekevät paljon pieniä committeja ja toiset vähän mutta isompia. Tutkivana mittarina tämä on heikko.

Pull requestien lukumäärä, eli kuinka monta ehdotusta on tullut uuden muutoksen integroimisesta pääasialliseen haaraan, on yksi joskus käytetyistä mittareista. Käytännössä yksi tällainen on vain joukko committeja ja siinä pätevät samat asiat kuin yksittäisten committienkin kanssa.

Pull requestien läpimenoaika

Tämä on sinänsä houkutteleva tavoitteena, jos kaikki muutokset pitää viedä eteenpäin pull requestin kautta. mutta tätäkin voi helposti pelata. Eli tehdään suuri joukko pieniä pull requesteja, mikä vaikeuttaa kokonaiskuvan hahmottamista. Todennäköisesti työtä tehdään enemmän kuin ilman mittausta vain jotta saataisiin mittari vihreälle. Kiintoisa kuriositeetti oli Pull Panda-nimisessä yrityksessä havainto, että mittarin käyttöönoton jälkeen perjantaisin ei enää tehty pull requesteja (ajassa 12:05).

Luonnollista vaihtelua esiintyy paljon yksilöiden välillä, joten tämä on tutkivanakin mittarina heikko.

Tehtävien lukumäärä

Tällä tavalla toimitaan niin, että tietyt henkilöt luovat saman verran työtä vaativia tehtäviä tehtävänhallintaan tai arvioivat työmäärän erikokoisista tehtävistä. Näin tehtävien suorittamisen jälkeen voidaan tutkia miten paljon on saatu aikaiseksi. Tässä on selvänä haasteena saada tehtävät samankokoisiksi tai arvioiduiksi samalla tavalla ja etenkin skaalautuminen on vaikeaa, jos esim. eri tiimejä pitää kyetä vertailemaan. Lisää byrokratiaakin tulee siinä, kun muut ihmiset yrittävät kirjata ongelmia jolloin ne eivät voi mennä suoraan tiimin tehtävien joukkoon, vaan ne joudutaan arvioimaan ensin siitä vastaavan tahon kautta.

Tällä mittarillakin voi tulla ikäviä sivuvaikutuksia, mm. tiimiläiset voivat alkaa kärkkymään helpoksi katsomiaan tehtäviä tai he voivat antaa omia arvioitaan eri asioista harhaanjohtavasti saadakseen helpompia tehtäviä. Vioista raportointi voi olla vääristynyttä, sillä vaikeista asioista ei välttämättä haluta tehtäviä ollenkaan. Pientä havaittua vikaa ei välttämättä korjata heti, vaan se saatetaan antaa mennä tuotantoon ja odotetaan että siitä tulee tehtävä, jonka tietää helpoksi.

Tutkivana mittarina tämä voi toimia organisaation sisällä, jos riittävä määrä tehtäviä saadaan määrämuotoisiksi. Eri organisaatioiden välillä tutkiessa ei todennäköisesti löydä mitään hyödyllistä.

Automaattisten testien lukumäärä

Tämä on harvinaisempi ja syystäkin. Automaattisia testejä voi tehdä vaikka miten paljon eri variaatioilla, vaikkei niistä olisi mitäään hyötyä, vaan ennemminkin haittaa, koska niitä joudutaan ylläpitämään.

Tutkivana mittarina heikko.

Vikatiheys ja testien läpäisyaste

Tässä mainituista mittareista tämä on ensimmäinen, josta voisi olla hyötyä tavoitteenakin. Järkevästi toteutettuna erillinen laadunvarmistusosasto tarkkailee näitä metriikoita, mutta sen järjestäminen voi olla vaativaa. Tällaisen vastakkainasettelun takia tiimi ei myöskään todennäköisesti toimi hyvin yhteistyössä laadunvalvonnan kanssa, joten tiimissä on hyvä olla omaakin laadunvalvontaa.

Oman organisaation sisällä voi toimia tutkivana mittarina. Muita organisaatioita tarkastellessa hyöty on vähäinen.

Toimintopisteet

Toimintopisteet on kehittynein tapa tutkia tuottavuutta. Toiminnoille annetaan tiettyjä pistemääriä ja niitä laskemalla yhteen saadaan järjestelmän koko. Näiden lisäksi tarvitaan laatuvaatimukset, jotka ohjelmiston on täytettävä. Itse laskeminen onkin melko helppoa, tosin vaatii perehtymisen, mutta varsinainen haaste tässä on laatuvaatimusten tekeminen, levittäminen ja valvominen. Etenkin ylläpidettävyys on vaikea määrittää. Hyvillä laatuvaatimuksilla toimintopisteet ovat toimiva tuottavuuden mittari, ehkäpä ainoa sellainen. Jopa muiden organisaatioiden kanssa vertailu onnistuu laskemalla kertoimia esim. eri laatuvaatimuksille ja toimialoille. Tutkivana mittarina käyttäminen onnistuu myös silloin, kun se on ollut tavoitteena.

Yhteenveto

Jokainen mittari antaa toki tietoa itse asiasta, esim. committien määrän muutos on hyödyllinen tieto ja voi kertoa tiimin ongelmista. Samoin voi olla hyödyllistä verrata oman organisaation pull requestien läpimenoaikaa muiden organisaatioiden vastaavaan ja pohtia mikä voi aiheuttaa eroja. Mutta tuottavuuden tutkiminen on hankalampaa ja riskialtista. Vertauskuvana voisi ajatella sähköasentajan palkitsemista sen mukaan, miten paljon enemmän hän saa johtoa laitettua seinään. Toimintopisteet ovat selkeästi paras mainituista mittareista ja vain vikatiheys/testien läpäisyaste oikein järjestettynä on toinen mittari, joka ei ole lähinnä vahingollinen.

Tärkeää on kuitenkin pitää huoli, että joku huomioi haastavat laatuvaatimukset, dokumentaation toimivuuden, epämääräiset työt kuten pääsyjen hankkimisen eri järjestelmiin, yhteisöllisyyden ja hengenluonnin, organisaation oppimisen ja asiakkaista oppimisen.

Muita FiSMAn Blogeja