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.

Työn sankari

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.

Artikkelin tagit:
 

3 vastausta artikkeliin Tuloksia vai panoksia?

  1. Janne Toivola kirjoitti:

    Hyvä kirjoitus! Teoriassa oikea tapa tulosten mittaamiselle olisi aloittaa projekti käymällä läpi projektin liiketoimintatavoitteet ja johtaa näistä mittaristo projektin lopputulosten arviointiin. Tämä on domainista riippuen varmasti haastavaa tai erittäin vaikeaa, mutta huonoimmillaankin hyvää asiakaskommunikointia ja hyödyllinen ajatusleikki!

  2. Lare Lekman kirjoitti:

    Kiitos Otso mainiosta artikkelista! Yhdyn täysillä osuviin näkemyksiisi ja ehdotan ainoastaan pientä tarkennusta Scrumin vauhtipisteisiin liittyen:

    Vauhtipisteet (aka. story points) eivät tue ainoastaan alkavan sprintin kapasiteetin arviointia, vaan suurin hyöyty pisteistä saadaan muutaman sprintin kuluttua, kun voidaan laskea tiimin keskivauhti ja käyttää sitä projektin jäljellä olevan kalenteriajan arvioimiseen.

    Esim. Jos tuotteen kehitysjonossa on kolmen sprintin jälkeen 70 pistettä tekemätöntä työtä ja kehitystiimi sai kussakin kolmessa sprintissä valmiiksi 8, 12 ja 10 pistettä (keskiarvo 10p), tarvitaan julkaisuun vielä arviolta 70p / 10p = 7 sprintiä. Jos tiimin sprintin pituus on 2 viikkoa, tarkoittaa tämä 14 kalenteriviikkoa.

    On hyvä muistaa, että vauhtipisteet ovat tiimikohtaisia ja ne tulee aina muuttaa kalenteriajaksi ennen vertailua muihin tiimeihin. Vauhtia ei myöskään voi liittää kannustimeen, koska tällöin se menettää arvonsa. Tähän perustuu Goodhartin laki: http://en.wikipedia.org/wiki/Goodhart's_law

  3. Aarne Ylä-Rotiala kirjoitti:

    Projektin, sprintin, etapin tms tuloksellisutta voi arvioida vaikka siten, että asiakas antaa laskutusluvan jos toimitettu tavara, palvelu tai toiminnallisuus vastaa odotuksia.
    Tilaajana olen käyttänyt ja minusta pelitti oikein hyvin.
    Toimittajan pitää sitten vain muistaa että tuotoksista joita ei ole pyydetty ei voi laskuttaa tunteja!
    Aarne

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Voit käyttää näitä HTML-tageja ja attribuutteja: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>