Ohjelmistoyrityksillä – erityisesti tuotetaloilla – on elinkaarensa alkupuolella usein haasteena löytää se kultainen keskitie, johon tuotetta pitäisi viedä. Tämä aiheuttaa epävarmuutta ja omistajuuden puutetta niin tuotetiimillle kuin muillekin sidosryhmille. Vahva visionääri tai pääomistaja voi pitkälti sanella tuotteen kehitystä, ilman että sille on löydettävissä järkevää perustetta – tai ainakin järkevä perustelu ei ole koko tiimin nähtävissä.
Kehityksen ohjaaminen saattaa olla myös myyntijohtoista, myyjien painottaessa myyntityössä kohtaamiensa ongelmien ratkaisua ja toisaalta, uusien ominaisuuksien kehittämistä kauppojen toivossa.
Tässä kaikessa on se ongelma, että ohjelmistokehityksessä sidosryhmiä on aika monta – omistajat, myynti, tuki, infra, ux/ix, varsinaiset kehittäjät – ja tietenkin asiakkaat. Kaikkien kuuntelemiseksi ja kaikkien toiveiden täyttämiseksi tuskin kellään on aikaa, jonka takia kehitystyössä joudutaan tekemään päätöksiä eli priorisointia.
Tässä kohtaa kuvaan astuu PO eli Product Owner eli tuoteomistaja. Tuoteomistajan olisi hyvä ymmärtää liiketoiminnan päälle, mutta pystyä keskustelemaan sujuvasti eri sidosryhmien kanssa. Tuoteomistajan rooli on yksi kehitystyön tärkeimpiä, koska hänen tehtävänsä on ottaa muiden tarpeet ja huolet huomioon niin, että saadaan luotua tuotteelle ymmärrettävä, taloudellisesti kannattava ja toteuttamiskelpoinen kehityssuunnitelma.
Tuoteomistajalla täytyy olla valtuutus päättää
Priorisointipäätökset tulisi tehdä niin, että niistä keskustellaan oleellisten sidosryhmien kanssa. Ryhmä ihmisiä ei kuitenkaan tee päätöksiä, vaan antaa omat mielipiteensä joiden perusteella tuoteomistajan on tehtävät päätökset. Tämä edellyttää siis riittävän vastuun ja vastuutuksen antamista tuoteomistajalle, kaikkien työrauhan takaamiseksi.
Lisäksi tulee muistaa kommunikointi ja läpinäkyvyys erityisesti tuotekehitystiimin osalta. Suunnitelmien jatkuva muuttuminen tai perustelemattomat priorisoinnit luovat epävarmuutta. Kannattaakin luoda helposti avautuva, yksinkertaistettu näkymä tulevaisuuteen joka käydään säännöllisesti läpi yhdessä ja kerrotaan muutoksista koko tiimille.
Kehityskohteita täytyy voida arvottaa ja vertailla keskenään
Tapa arvottaa ja priorisoida kehityskohteita on kunkin yrityksen itse keksittävä, mutta rahassa mitattava arvo on yleensä helppo ja konkreettinen tapa arvioida. Kehityskohteen tuoman lisäarvon lisäksi vaa’assa pitäisi painaan myös sen kehittämiseen menevät kulut (suorat kehityskulut) sekä sen ylläpitämisestä aiheutuvat kulut (kehittäjien aika, tukitoiminnot, palvelinresurssien tarve, jne).
Esimerkiksi ominaisuuksien arvotustapa voisi olla: “paljonko lisämyyntiä (euroissa) ominaisuus X tuo seuraavan 3kk?” tai “kuinka tärkeä (asteikoilla 1-5) ominaisuus X on uuden markkina-alueen valtaamisessa?”.
Ongelman yhtälöön tuovat kehityskohteet, jotka eivät tuo suoraa lisäarvoa – kuten refaktorointi, infrahankkeet tai muu teknisen velan poisto. Niiden priorisointi voidaan tehdä joko euromääräisen arvion perusteella tai yksinkertaisesti tekemällä niille tilaa muun kehitystyön joukossa riittävän usein.
Tiivistettynä teesit toimivan priorisoinnin varmistamiseksi:
- Nimeä tehtävään nimetty tuoteomistaja
- Takaa roadmapin läpinäkyvyys viestimällä ja visualisoimalla
- Luo selkeä arvotusmekanismi kehityskohteille
- Turvaa työrauha, mutta älä pelkää muutosta
- Muista myös arvoa suoraan tuottamattomat kehityskohteet
Kannattaa muistaa, että kertaalleen tehty priorisointi ei ole kiveen kirjattu ja suunnitelmia pitää muuttaa tilanteen eläessä. Tärkeintä on huomioida kaikki sidosryhmät ja taata työrauha kaikille osapuolille.
Kirjoittanut
Timo Kallela – CXO
Timolla on vankka kokemus startup-yrityksistä, ohjelmistotuotteiden kehittämisestä ja kehitystiimien luotsaamisesta. Varaanilla Timo on koodaavan asiakastyön lisäksi kehittämässä toimintaa mm. rekrytointien ja kumppanuuksien osalta.