Ohjelmoijan muistinmenetys

Tyypillinen työviikko 90-luvulla saattoi koostua neljästä päivästä armotonta koodausta ja perjantaina tajuamisesta, että sekä työaikakirjanpito että toteutuksen dokumentointi on viikon todellisuudesta jäljessä. Tässä vaiheessa korjasin asian.

Epätyypillinen työviikko 10-luvulla koostuu neljästä päivästä armotonta koodausta ja perjantaina tajuamisesta, että työaikakirjanpitoon tulee “koodausta, 30 tuntia” ja toteutusta ei saada ikinä dokumentoitua kunnolla. Tyypillisempi viikko menee niin, että kirjoitan sekä dokumentit että projektikirjanpidon etukäteen, koska muuten en muista edes mitä suunnittelin tekeväni.

Jälkiviisaana olen aika varma, että kukaan kaksikymppinen ei toimi tällasissa asioissa järjestyksessä, joka meille neljääkymmentä lähestyville on täysin pakollinen.

Parikymppiset lukijat jakautuvat nyt kahtia: toiset eivät pysty edes kuvittelemaan näin huonoa muistia, ja toiset ovat kauhuissaan eivätkä pysty kuvittelemaan miten ilman muistia voi tehdä töitä. Tähän liittyy toinen ero. Niin kauan, kun muistaa suunnilleen kaiken, mitä elämässä on tapahtunut, ei sisäistetyn tiedon ja sattumanvaraisen tiedon välinen ero ole käsitteellisesti välttämätön. Tieto kuin tieto. Tosiasiassa kuitenkin sisäistetty tieto käyttäytyy eri tavalla. Vaikka en muista mitään, muistan kuitenkin kuinka C:tä koodataan, koska osaan koodata C:tä. En muista mitä söin keskiviikkona lounaalla. Se ei kuulu osaamiseen.

// Kuva: Flickr CC, _annamo.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Tuloksia vai panoksia?

Asiakas kysyi minulta, leikillään totta kai, montako unetonta yötä olen viettänyt heidän projektinsa parissa. Ikään kuin uneton yö osoittaisi, että töitä tehdään tosissaan ja täysillä.

Vastasin, että en yhtäkään. Sen sijaan satsaan hyvin nukuttuihin öihin, joiden jälkeen ymmärrän heidän arkkitehtuuriaan paljon paremmin kuin katkonaisten unien jälkeen.

Pohjimmiltaan tässä on kyse siitä, halutaanko työntekijältä (alihankkijalta, jne) panoksia vai tuloksia. Mitataanko sitä, kuinka suurta vaivaa nähdään ja kuinka suuria uhrauksia tehdään, vai sittenkin sitä, kuinka hyvää jälkeä saadaan aikaiseksi.

Oikea vastaus on tietenkin päivänselvä. Siksi ketterissä menetelmissä keskitytään saamaan mahdollisimman nopeasti toimivaa softaa eli tuloksia, eikä piitata niinkään paljon tarkoista työmäärä-arvioista tai niiden pitävyydestä eli panoksista. Siksi myyntiä palkitaan kaupoista ja johtoa voitosta, eikä sankarillisista työsuorituksista.

Yleensä bisneskirjallisuudessa asia jääkin sitten tähän, teoreettisestihan asia on selvä. Todellisuus on kuitenkin monimutkaisempi. Erityisesti softa-alalla tuloksia on nimittäin yllättävän vaikea mitata.

Konsulttitoiminnassa myydään oleellisesti työtunteja asiakaalle. Luulisi siis, että olisi helppoa mitata myytyjen tuntien määrää ja palkita sen mukaan. Mutta ongelmaksi tulee, että on myös yrityksen sisäisiä töitä, ja nekin pitää tehdä. Jos ne lasketaan asiakastyön tapaan “palkittaviksi”, niin sitten palkitsematta jääneet tunnit ovatkin äkkiä palkattomia tunteja, eikä niiden tekeminen kiinnosta juuri ketään. Pian kaikki tunnit kirjataan asiakasprojektin puolelle, tehtiin todellisuudessa mitä hyvänsä. Seurauksena tuntikirjanpidosta ei voi enää päätellä mitä on oikeastaan tehty ja paljonko siihen meni aikaa. Sen arvo yrityksen ohjaamiseen tai kannattavuuden laskentaan lähenee siis nollaa. Tämän olen nähnyt myös toteutuvan käytännössä.

Vielä hankalampi on mitata keskeneräisen projektin edistystä. On helppo katsoa, montako suunnitelluista toimenpiteistä on tehty ja ollaanko niiden suhteen aikataulussa, mutta se on taas panosten mittaamista: listalta puuttuvat ne toimenpiteet, joita ei arvattu tarvittavan. Scrumin vauhtipisteetkään eivät ole juuri parempia. Ne kertovat lähinnä miten hyvin tiimi osaa ennakoida seuraavan kahden viikon töiden vaativuutta. Arvokasta tietoa tiimille, mutta ei kerro siitä, paljon tuloksia lopulta tuotetaan. Ja jos korkeasta vauhdista alettaisiin palkita, numerot kasvaisivat hyvin äkkiä, koska ei ole mitään estettä vaikka tuplata kaikkia pistemääriä. Tämä veisi mittaamisesta taas kaiken hyödyn.

Lähes kaikki mittarit luovat mittauksen kohteille tarpeen siistiä käytöstään näyttämään paremmalta mittarissa. Erityisen vahvana tämä efekti toimii, jos mittauksen tuloksista vielä palkitaan jotenkin. Sitä saa mitä mittaa, eli mittaustuloksia. Asiakastunteja, vauhtipisteitä tai vaikka commit-rivejä. Yksikään niistä ei ole projektin tavoite. Harkitsematon palkitsemisjärjestelmä tai edes mittaaminen aiheuttaa merkittävää oheishaittaa.

Eräänlaisena nollatasona tulosten mittaamiselle toimiikin arvioijan fiilis, perstuntuma. Projektin etenemistä ja sen jäsenten suoriutumista voi arvioida niin, että juttelee ihmisten kanssa, ja sitten vaan luottaa omaan intuitioonsa. Yleensä varsinkin epäonnistumiset ovat olleet tunnetasolla tiedossa jo kauan ennen kun ne näkyvät missään mittarissa.  Fiilismittarissa on ilmeiset riskinsä (suosikit, väärinymmärrykset, valehtelu…) mutta niin on kaikessa muussakin.

Ennen kun otat jonkin metriikan käyttöön, perustele itsellesi, miten tämä metriikka antaa parempia tuloksia ja tuottaa pienemmät haitat kuin perstuntumalla arviointi. Useimmat mittaus- ja palitsemisjärjestelmät kun häviävät tuolle nollatasolle.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.