Työmääräarviointien vaikea maailma

Pasi Taive | 17.02.2020
Lukuaika 3 min

Tietojärjestelmän työmääräarviointi on tärkeä osa projektia. Syy, miksi se on tärkeää, saattaa olla eri kuin mitä normaalisti ajatellaan. Yleisesti ottaen yhden sprintin arvioimisessa ei ole usein paljoa arvoa. Arvioinnin tarkoituksena ei ole myöskään sitoutua siihen, miten paljon sprintissä tehdään ominaisuuksia. Arvioimme asioita, jotta voisimme ennustaa paremmin tulevaisuutta erilaisista näkökulmista. Pari tärkeää näkökulmaa ovat:

  1. Tuottavuuden tilanne projektissa
    • Jos samankokoisten ominaisuuksien työmääräarviot kasvavat projektin edetessä, on tämä yleensä merkki ongelmista. Yleinen ongelma tällaisessa tilanteessa on, että tekninen velka on kasvanut projektissa ja sen takia ominaisuuksia on hankalampi rakentaa.
  2. Ennustettavuus lyhyelle ja pitkällä aikavälillä
    • Usein asiakkaan pitää pystyä arvioimaan milestonet, jotta voidaan tehdä budjetointia tai hakea vaikkapa lainaa tuotteen kehittämiseen.
  3. Tehtävälistan (Backlogin) priorisointi
    • Kun asiakas ymmärtää, miten paljon ominaisuudet maksavat, ne voidaan priorisoida liiketoiminnallisesta näkökulmasta projektin aikajanalla sopivaan kohtaan.

On myös projekteja, joissa työmääräarviointiin menevä aika ja siihen liittyvät vaarat voivat olla sen hyötyjä suuremmat. Tällaisesta esimerkkejä ovat mm. Startup-yritysten tuotteet/projektit, joiden vaatimukset tulevat pääsääntöisesti loppukäyttäjien palautteiden perusteella, ja siten ei ole mielekästä arvioida, mitä seuraavan vuoden aikana tehdään. Pääsääntöisesti kuitenkin suosittelen työmääräarviointia kaikissa projekteissa, kunhan se tehdään kevyesti, sekä muistetaan että kyseessä on arviointi, ei lupaus.

Työmääräarvioinnin vaarat sovelluskehityksessä

Tämä on yksi mieliaiheistani. Scrum-tiimi valitsee joukon ominaisuuksia, jotka se sitoutuu tekemään sprintissä. Tämä voi olla haitallista erityisesti ’ei niin kokeneiden’ ohjelmoijien kanssa. Jos tiimi pelkää sprintin epäonnistumista (kaikkia ominaisuuksia ei saada tehtyä), kehittäjiltä löytyy monta ”luovaa” tapaa saada ominaisuudet tehtyä. Yleensä nämä luovat tavat johtavat tahattomaan tekniseen velkaan, joka kostautuu pitkällä tai jopa lyhyellä aikavälillä. Huomioitavaa on, että välillä tarkoituksellinen tekninen velka ei ole paha asia. Tekninen velka on työväline ja sen pitää olla läpinäkyvää. Tekninen velka pitää ottaa tietoisesti ja se on usein päätös, joka tehdään yhdessä asiakkaan tuoteomistajan (product owner) kanssa.

Jos sinun projektissasi scrumin sprintit eivät koskaan ”epäonnistu” on syytä olla huolissaan siitä, miksi näin ei koskaan tapahdu. Joko kehittäjät tekevät ”luovia” ratkaisuja, ottavat liian vähän ominaisuuksia sprinttiin tai antavat liian pessimistisiä arvioita ominaisuuksista. On tärkeää, että sekä toimittaja ja asiakas ymmärtävät sen, että on ok epäonnistua sprinteissä. Epäonnistuminen on itseasiassa täysin väärä sana ja sitä ei pitäisi ikinä käyttää! Tämä onnistuu vain, jos asiakkaan ja toimittajan välillä on luottamus.

Lopuksi

Yhteenvetona voi sanoa, että työmääräarviointi on kriittinen osa projektia ja varsinkin projektin alkua. Liian usein arvio sekoitetaan lupaukseen, mikä voi johtaa vaarallisiin työtapoihin. Käytännön neuvona sanoisin, että tehkää arviota haarukkana (range). Kun annetaan haarukka työmääräarviolle, se kuvastaa myös samalla kuinka hyvin arvioija tuntee alueen. Haarukkana arviointi parantaa myös projektin läpinäkyvyyttä ja tuo esille sen epävarmuustekijöitä. Jos kerron, että projektin ensimmäinen milestonen saavuttaminen kestää 1-2 kuukautta on se aika eri asia kuin jos sanon, että se kestää 1-5 kuukautta. Jälkimmäisessä tapauksessa asiakas ehkä haluaa minun paneutuvan tarkemmin asioihin, jotka johtavat näin laajaan haarukkaan. Nämä asiat johtuvat usein epäselvistä toiminnallisuuksien vaatimuksista tai niiden puutteista. Mukavia arviointihetkiä itse kullekin😊