Jokaisessa ohjelmistoprojektissa ostajaa kiinnostaa sen kustannus- ja aikatauluarvio resurssien rajallisuuden sekä investoinnin mielekkyyden arvioinnin vuoksi.

– Ohjelmistoyritysten asiakkaat kaipaavat selkeästi parempaa ennustettavuutta ja sitä kautta parempaa riskien hallintaa, jottei raha ja aika loppuisi kesken projektin, aloittaa verkkopalveluiden ketterään kehittämiseen erikoistuneen Sysartin Daniel Wellner.

Hänen mukaansa nykyaikaista digitaalista palvelua kehitettäessä on kiinnitettävä huomiota onnistumisen mittareihin. Onko onnistumista se, että palvelu tehtiin sovitulla budjetilla? Vai haetaanko mittarit esimerkiksi uuden liiketoimintamallin tuottavuudesta?  

Sysartilla on muotoiltu jo vuosien ajan mallia, joka tarjoaa työkalun parempaan ennustettavuuteen ohjelmistoprojekteissa. Perinteinen arviointi ei Wellnerin mukaan sitä todellakaan tarjoa.

Mitä tapahtuu, jos työmääräarviointia ei #NoEstimates-tyyliin tehdä lainkaan?

 

Perinteinen ohjelmistoprojektin työmäärän ja budjetin arviointi

Perinteinen tapa arvioida ohjelmistokehityshankkeen toteutusta ja budjettia on kärjistetysti seuraavanlainen: asiakas lähestyy alustavan toivelistan kanssa ja kysyy paljonko toteutus maksaa.

Daniel Wellner nostaa kuitenkin heti kissan pöydälle.

– Jos tässä kohtaa annetaan tarkka luku, se ei johda hyvään lopputulemaan. Ennen riittäviä tietoja annettu hinta-arvio perustuu liiaksi arvaukseen. Todellisuudessa jokaisessa ohjelmistohankkeessa tavoitteet tarkentuvat ja muuttuvat työn edetessä ja tiedon karttuessa. Samaan aikaan asiakkaan tarpeet elävät jatkuvasti, teknologiat kehittyvät, käyttäjien odotukset muuttuvat ja kilpailijat tekevät omia liikkeitään.

”Jokaisessa ohjelmistohankkeessa tavoitteet tarkentuvat ja muuttuvat työn edetessä ja tiedon karttuessa.”

– Asiakkaat saattavat esimerkiksi jo MVP:n tekovaiheessa pyytää tarjousta tuotteen lopullisesta, laajasta versiosta. Kuitenkin MVP:n tarkoitus on nimenomaan tuottaa dataa siitä, millainen ratkaisu voisi olla.

Palveluita kehittäessä törmätään jatkuvasti myös priorisointikysymyksiin. Ajatellaan vaikkapa tietyn käyttöliittymäelementin suunnittelua: riittääkö kolmannen osapuolen tekemä komponentti vai suunnitellaanko täysin kustomoitu toteutus? Juuri tällaisista lukuisista mikropäätöksistä ohjelmistoprojektit muodostuvat.

– Vaikka ennalta olisi tehty hyvinkin tarkka suunnitelma, kompleksisen järjestelmän toteutuksen etenemistä ei voida käytännössä ennustaa, Wellner pohtii.

Wellnerin mukaan työmääräarvion sijaan olisi parempi keskustella siitä, mikä on oikeasti tärkeää. Mitkä ovat tärkeimmät haasteet, joita ollaan ratkaisemassa ja miksi? Mitä rajoitteita, kuten budjetti ja aikataulu, täytyy ottaa huomioon kehitystyössä? Entä mikä on sopivin, nopein ja halvin tapa ratkaista ongelmia näiden rajoitteiden puitteissa?

– Reunaehtona on se, paljonko rahaa on käytössä, mitä halutaan saavuttaa ja miten mitataan onnistumista. Suunnitelmat muuttuvat kehityshankkeen aikana satavarmasti ja niiden kuuluukin elää. Siihen koko agile toimintatapa perustuu: tehdään iteratiivisesti, mitataan, kerätään palautteita, opitaan ja päivitetään suunnitelmat, Wellner kuvaa.

 

#NoEstimates – mitä jos työmääräarviota ei tehtäisi lainkaan?

Daniel Wellner törmäsi #NoEstimates -menetelmään jo vuoden 2012 tienoilla ja alkoi testata sen hyödyntämistä käytännössä.

– Suomessa Vasco Duarte on ollut koulukunnan pioneeri. #NoEstimates lähtee siitä ajatuksesta, että jos työmääräarviointi menee kuitenkin pieleen ja tekee siten hallaa työskentelylle, miksi tehdä sitä lainkaan, Wellner avaa.

”#NoEstimates lähtee siitä ajatuksesta, että työmääräarviointi menee kuitenkin pieleen.”

Sysartilla on hyödynnetty jo viiden vuoden ajan tähän ajattelutapaan pohjautuvaa ketterää ennustamismallia.

– Jos työkohteet pidetään pieninä ja niitä priorisoidaan jatkuvasti, ollaan aina tekemässä tärkeintä asiaa. Sen jälkeen voidaan miettiä uudelleen, mikä on seuraavaksi tärkein asia.

#NoEstimates eroaa scrumista, mutta on linjassa ketterän arvolupauksen kanssa: tehdään lyhyitä iteraatioita nopeissa sykleissä, jolloin opitaan mikä on toiminut ja mikä ei. Opitun perusteella kehitetään toimintaa ja priorisoidaan tekemistä.

Työmääräarvioita tähän ei tarvita.

 

Ei ilman lukuja voi tehdä kauppaa!

Vaikka Wellner on innokas #NoEstimates -ajattelun kannattaja, hän näkee, että koulukunnan “ei anneta hinta-arviota” -viesti on ollut välillä jopa liian provosoiva.  

– Tuollaisella sanomalla asiaa ei saada eteenpäin! Usein tarvitaan jonkinlainen kustannusarvio, koska muuten projekti ei mene läpi asiakkaan johtoryhmässä. Ilman lukuja ei voi tehdä kauppaa, se ei ole uskottavaa, Wellner sanoo.

Asiakkaalle pitäisi siis kyetä antamaan hintalappu, vaikka kaikki tietävät jo tässä kohtaa tarkkojen työmääräarvioiden mahdottomuuden.

– Meidän toimintatavassamme luodaan kevyt ennuste siitä, mitä työmäärä voisi olla tällä hetkellä, jotta päästään eteenpäin keskustelussa. Samalla tuodaan voimakkaasti esiin se tosiasia, että tämä ennuste tulee muuttumaan.

Wellnerin kuvaamassa mallissa olennaista on tarjota työkalut projektin johtamiseen ja lopputuloksen hallintaan. Samalla kun työtehtäviä priorisoidaan, päivitetään mittarit ja ennusteet, joilla asiakas pystyy läpinäkyvästi seuraamaan projektin edistymistä.

– Mallissa emme arvioi toteutettavien ominaisuuksien kokoa lainkaan. Sen sijaan pyrimme pilkkomaan ominaisuudet pieniksi ja vertailukelpoisiksi tehtäviksi ja seuraamme niiden kokonaismäärää. Näin historiatiedon kertyessä saamme yhä paremman kuvan siitä, paljonko työtehtävät vievät keskimäärin aikaa.

”Avoin ja luottamuksellinen toimintatapa tuo turvaa asiakkaalle.”

– Tässä toimintamallissa on tärkeää avata huolellisesti, mihin ennuste perustuu ja päivittää sitä jatkuvasti ja asiakkaalle läpinäkyvästi projektissa kertyneeseen historiatietoon perustuen. Koska tilanteet päivittyvät aina, myös ennusteita pitää päivittää jatkuvasti, Wellner kuvaa.

Wellnerin mukaan tärkeä elementti ketterässä projektissa on myös se, ettei koskaan tehdä asiakasta liikaa sitovia sopimuksia.

– Avoin ja luottamuksellinen toimintatapa tuo turvaa myös asiakkaalle. Hän voi milloin tahansa todeta: “Sain nämä tärkeät asiat, nyt pidetään kehitystyössä tauko”. Kun aina tehdään sitä tärkeintä asiaa, pystytään hallitsemaan budjettia, eikä tarvitse sitoutua keinotekoiseen lukuun, Wellner kertoo

– Silloin ohjelmistoprojekti on helpommin johdettavissa, hän lopettaa.  

 

Sysartin ite wiki -profiili
Sysartin kotisivut

 

Onko yrityksellänne mielenkiintoinen juttu kerrottavaksi, ohjelmisto esiteltäväksi tai osaava digitalisaation asiantuntija haastateltavaksi? Ole yhteydessä ite wikin toimitukseen johannes.puro@itewiki.fi tai elina.koskipahta@itewiki.fi, niin tehdään artikkeli!