Kirjoittajat: Risto Nevalainen ja Markku Tukiainen, FiSMA ry
Mittaaminen on sana, joka saa monen ammattilaisen nyökkäämään – tai huokaamaan. Mutta mitä kaikkea oikeastaan voi, tai pitäisi mitata? Ja miksi mittaaminen on yhä tärkeämpää erityisesti ohjelmistokehityksen, IT-palveluiden ja digitaalisten järjestelmien maailmassa?
Tässä blogissa pohdimme mittaamisen merkitystä, sen haasteita ja mahdollisuuksia. Kyse ei ole vain numeroista – kyse on tiedosta, ymmärryksestä ja paremmista päätöksistä.
Syitä mittaamiseen on monia. Joskus halutaan vain ymmärtää paremmin, joskus etsitään keinoja parantaa toimintaa tai perustellaan olemassaolon oikeutusta. Entä jos parempi mittaaminen voisikin olla avain tehokkaampaan toimintaan, onnistuneempiin projekteihin tai parempaan asiakaskokemukseen?
Kaiken mittaamisen pitää perustua tarpeeseen. Tärkeintä on ammattilaisen saama kokemus ja palaute mittaamisen hyödyistä. Sitä myöten mittaamisen kulttuuri tarttuu ja leviää organisaatiossa. Myös johdon mittareista saama tuki ja varmuus päätöksille on tärkeää. Vaikka toiminnassa pitää olla luovuutta ja intuitiotakin, tärkeät asiat ja päätökset on hyvä perustella myös tosiasioiden perusteella. Suunnitteilla olevat isot muutokset on hyvä todentaa mittareiden avulla, esimerkiksi tekemällä hallittuja kokeiluja.
Mittaamisen tasot ja tarkkuus
Kaikki mitattava ja mittojen käyttö ei ole samalla loogisella tasolla. ISO/IEC 15939 -standardi auttaa hahmottamaan mittaamisen tasot: datasta suoriin mittareihin, edelleen johdettuihin mittareihin, indikaattoreihin ja lopulta päätöksenteon tueksi tuotettuun tietoon. Useimmat mittarit ovat kasaumia datasta. Esimerkiksi tuottavuus mitattuna tulos/käytetty resurssi on johdettu mittari, kun siinä yhdistetään kaksi suoraa mittaria: toimintopisteet ja käytetty tuntimäärä. Jos käytössä on paljon tuottavuusmittauksia, niistä vo muodostaa kehityksen suuntaa ja nopeutta kertovan indikaattorin. Sen perusteella taas voisi tehdä päätöksiä liiketoiminnan suunnasta ja kilpailukyvystä.
Mittauksen tarkkuuskin vaihtelee:
- Laadullinen arviointi: kuten prosessin kyvykkyystaso SPICE-standardin mukaan. Se voi perustua selkeisiin todisteisiin, mutta niiden kertoma todellisuus on lopulta enimmäkseen harkittu asiantuntija-arvio (engineering judgement).
- Numeerinen mutta tulkintaa vaativa: kuten toimintopistelaskenta. Lähtöaineisto voi olla epätäydellistä ja vaatii joitakin oletuksia. Jopa kirjatut työtunnit toimintopistettä kohden voivat olla epätarkkaa dataa, vaikka itse mittayksikkö eli tunti on yksikäsitteinen.
- Tarkka ja yksiselitteinen: kuten järjestelmän kehitysversiossa olevien virheiden määrä valitun tarkistuskohdan jälkeen. Useimmiten on myös niin, että järjestelmässä on piileviä virheitä ja teknistä velkaa, joita ei ole kirjattu mihinkään. Siksi tarkkakaan mittari ei kerro koko totuutta.
Mittaamista voi lähestyä kolmella tavalla kohteensa mukaan:
- Sisäinen mittaaminen: esim. ohjelmiston kompleksisuus (cyclomatic complexity) ja sen muutos kehitysversion aikana.
- Työtulosten mittaaminen: esim. julkaistun järjestelmän toimintopistemäärä. Järjestelmän luotettavuus (esim. käyttökatkokset per vuosi, MTBF) on usein haluttu ominaisuus, mutta sitä voi olla vaikea laskea lähtötietojen ja kokemuskannan puutteiden takia.
- Vaikuttavuuden mittaaminen: esim. käyttäjätyytyväisyyden muutos tai liiketoimintahyödyt. Usein johtoa kiinnostaa eniten vaikuttavuus: mitä hyötyä saatiin aikaan, ei vain mitä tehtiin.
Mittari voi olla sekoitus sisäistä laatua ja ohjelmistokehityksestä riippumatonta dataa. Järjestelmän käyttökokemukseen voi vaikuttaa esimerkiksi sen tuttuus. Siksi asiantuntijan mielestä huonompi järjestelmä voi saada paremmat kokemuspisteet.
Tunnettuja mittausmenetelmiä
Mittaus ei tarkoita sitä, että jokainen keksii pyörän uudestaan. Siksi on luotu jo vuosikymmeniä sitten mittaamisen kokonaismenetelmiä. Tunnettuja paketteja ovat mm.:
- GQM (Goal-Question-Metric). Tässä menetelmässä mittarit johdetaan tavoitteista, joita tarkennetaan strukturoitujen kysymysten avulla. Vastaus näihin kysymyksiin on haluttu tai sopiva mittari.
- DORA (DevOps Research and Assessment). (Deployment Frequency, Mean Lead Time for Changes, Mean Time to Recovery, Change Failure Rate, Reliability). Näistä luotettavuus on lisätty äskettäin, ja sen voi jättää poiskin, jos ei ole tarvetta.
- BSC (Balanced Scorecard). Tämä on ollut jo vuosikymmeniä suosittu menetelmä johtaa liiketoiminnassa tarvittavia laatumittareita. Usein mukana on enimmäkseen muita kuin järjestelmämittareita, esimerkiksi asiakkaan kokema laatu tai halutun muutoksen onnistuminen.
- ISO/IEC-standardit. Hyviä De Jure-standardeja on suuri määrä. Ne ovat useimmiten mittareiden määrityksiä, kuten järjestelmän laadun standardisarja ISO/IEC 250xx. Se pitää osata sovittaa organisaation tarpeisiin. Standardiperheen ISO/IEC 330xx avulla mitataan toiminnan kypsyyttä ja kyvykkyyttä. Useilla toimialoilla on omia standardejaan, esimerkiksi toiminnallisen luotettavuuden todentamiseksi.
Haasteita riittää edelleen
Mittaaminen on helppoa, kun tietää mitä mitata. Se tieto onkin usein hukassa, siksi mittaaminen on usein vielä kokeilu- ja harjoitteluvaiheessa. Muutamalla mittarilla kannattaa aloittaa, ja sitten vähitellen kasvaa kypsemmäksi. Kokeneilta kannattaa hakea oppia ja kokemuksia, ja hiukan kopioidakin.
Todellisuus on usein aika kivinen, ilman syytä ja painetta ei mitata. Kun asiakas vaatii, niin kyllä silloin mitataankin. Reguloiduilla toimialoilla mittaamista tarvitaan usein osana vaatimusten todentamista, joten mittaamista tehdään. Useimmissa muissa tilanteissa meiltä puuttuu:
- Hyvä syy ja motivaatio mitata, kun kukaan ei sitä osaa vaatia
- Pitkäaikainen, vertailukelpoinen data, josta saisi tehtyä analyysiä ja havaita trendejä
- Vaikuttavuuteen ja asiakaskokemukseen linkittyvä muu kuin mutu- tieto
- Emergenssin – yllättävien vaikutusten – mittarit. Systeemit monimutkaistuvat ja käyttäytyvät joskus yllättävällä tavalla.
- Perustietoja etenkin yhteiskunnan tasolla, kuten montako IT-ammattilaista Suomessa edes on? Se vaatii kysyjältään aika monen tilaston läpikäyntiä ja ymmärrystä niiden päällekkäisyyksistä.
Tuottavuus on perinteisesti output/input – kuten tuntia per toimintopiste. Tehokkuus taas kertoo, syntyykö arvoa järkevästi ja oikeaan suuntaan. Yksittäinen järjestelmä voi olla teknisesti tuottava, mutta jos se ei paranna esimerkiksi käyttäjäkokemusta tai asiakastyytyväisyyttä, sen tehokkuus on kyseenalainen. Sama pätee tekemisen onnistumiseen Ei riitä, että tulos ja toimitus saadaan aikaiseksi vaan mittaaminen pitäisi ulottua käyttäjän ja ostajan aikaansaamiin ja haluttuihin vaikutuksiin asti.
Liikkuva maali ja mittaamisen realiteetit
Kehitys kehittyy, ja niin tekee myös mittaaminen. Esimerkiksi organisaation kypsyystason arviointi ei toimi, jos liiketoiminnan rajat, organisaatio ja toimintaympäristö muuttuvat jatkuvasti. Ketteryys ja tekoäly asettavat uusia haasteita myös mittaamiselle. Joskus on liikaa tietäjiä, joista jokainen uskoo olevansa ainut oikeassa olija.
Mutta jotain pysyy: kehittäjän työaika on edelleen työtunti, ja sprinttien tuotokset voi laskea aivan hyvin toimintopisteiden avulla.
Mittaaminen vs. datan analysointi
Kumpi on tärkeämpää, hyvin vakioidut mittarit vai suuri määrä dataa? Molempia tarvitaan, kun muuttuvissa ja uusissa tilanteissa vanhasta toistosta ei ole riittävästi apua. Datan analysointi antaa täydentävän käsityksen todellisuudesta. Melkoista vaihteluakin voi olla, joten tilannekohtaista herkkyyttä tarvitaan. Jos työmäärä on yhdessä yksikössä keskimäärin neljä tuntia per toimintopiste, ja rinnakkaisessa yksikössä kuusi tuntia, niin mistä ero johtuu? Syy voi olla eritasoisissa vaatimuksissa, toiminnan toisteisuudessa, eri vaiheessa olevassa oppimiskäyrässä tai osaamisen tasossa. Silloin on kyettävä analysoimaan sekä taustatekijöitä että tilannekohtaisia asioita.