Kehitysjohtajan pöydällä on ongelma: Kentällä on selvästi kysyntää uudenlaisille digitaalisille palveluille ja hyviä ideoitakin riittää listaksi asti, mutta tuotekehitykseen investointi aiheuttaa harmaita hiuksia.
Ajat ovat tiukat, ja jotenkin pitäisi varmistua siitä, että lopputulos todella palvelee käyttäjiä. Kannattaisiko pistää pystyyn tarkkaan määritelty projekti vai laittaa paukut pitkäjänteisempään kehittämiseen? Miten pakka pysyisi parhaiten koossa?
Lähtökohtaisesti kaikki ohjelmistokehitystyö on syytä aloittaa rajattuna projektina, jossa työskennellään selkeää tavoitetta kohti. Tavoite voi olla esimerkiksi MVP-versio kokonaan uudesta asiakassovelluksesta tai vanhan järjestelmän perustoiminnallisuuksien modernisointi.
Tuotekehitystä kannattaa harvoin jättää vain rajattuun projektitekemiseen. Työn edetessä huomataan ehkä, ettei teoria vastaakaan käytäntöä, ja tunnistetaan ne asiat, joita on hyvä viilata eteenpäin jatkuvan tuotekehityksen vaiheessa.
Rajatuksi projektin tekee se, että sille on ennalta määritelty tavoitteet haluttujen hyötyjen saavuttamiseksi. Kehitettävän ratkaisun vaatimukset ovat tiedossa ja riittävän selkeitä, eli niihin ei liity merkittäviä epävarmuuksia, olettamia tai tulkinnanvaraisuutta. Tämän vuoksi projektille voi olla helpompaa asettaa kokonaiskesto sekä -budjetti.
Koska rajat ovat selvät, on myös tuoteomistajan työ melko suoraviivaista. Hänen tulee pitää kaikki sidosryhmät tietoisena, missä projektissa mennään ja huolehtia, että kehitystyö keskittyy ennalta määriteltyjen tavoitteiden saavuttamiseen sekä pysyy budjetissa.
Usein rajatun projektin puitteissa rakennetaan melko pieni ratkaisu, josta saatu arvo on helppo määritellä. Tavoitteena voi esimerkiksi olla se, että rakennetaan ideasta riittävän toimiva sovellus, joka voidaan lanseerata tietyn joukon käyttöön. Tällöin on helppo tietää, milloin ratkaisu on valmis – tai ainakin riittävän valmis. Juuri tähän viittaa termi MVP eli minimum viable product.
Projektina voidaan toimittaa myös laajoja ja vaativia järjestelmiä, mutta niissäkin kannattaa jakaa kokonaisuus osatavoitteisiin ja hyödyntää MVP-ajattelua.
Rajattu kehitysprojekti toimii erityisen hyvin, kun rakennetaan teknisiä ratkaisuita. Tällöin kyseessä on esimerkiksi softa, joka keskustelee laitteen kanssa. Tekniset kyvykkyydet asettavat selkeät reunaehdot, joiden mukaan kehitystyö on helppo suunnata täsmällisesti tiettyihin asioihin.
+ Budjetti on hyvin tiedossa etukäteen.
+ Projektilla on selkeä alku ja loppu.
+ Lopputuloksesta on selkeä käsitys.
+ On helppo arvioida, milloin ratkaisu on valmis.
- Jos vaatimukset muuttuvat matkan varrella, ei lopputulos ehkä olekaan sitä, mitä lopulta tarvitaan.
- Jos budjetti ei jousta, ei uusia toiveita voida toteuttaa. (Liittyy olennaisesti edelliseen kohtaan.)
- Tuote on vasta minimitason tuote eli MVP, joka kaipaa useimmiten vielä kehitystyötä.
- Työn määrää voi olla vaikea arvioida etukäteen.
- Priorisointi on vaikeaa: mitä tehdään nyt ja mitä myöhemmin ylläpitovaiheessa?
Lähde: Tuoteomistajien rooli ja sen haasteet -tutkimus
Jatkuvassa tuotekehitysprojektissa tavoitteet eivät ole yhtä kiinteitä tai ennalta määriteltyjä, kuin rajatussa. Tavoitteita testataan, arvioidaan ja asetetaan myös työn edetessä, ja ne perustuvat saatuun palautteeseen. Kehitystyötä ei tästä johtuen yleensä aloiteta jatkuvana, vaan minimivaatimus on, että ratkaisu on joltain osin jo käytössä.
Käytännössä siis jatkuva kehitysprojekti aloitetaan rajatulla MVP-vaiheella. Kun on ensin rakennettu uusi softa vaikkapa asiakkaiden käyttöön, on jotain, minkä avulla kerätä lisää tietoa tarpeista ja relevanteista ominaisuuksista. Sovellusta käyttävät asiakkaat antavat palautetta ja sen perusteella lähdetään kehittämään siihen lisää toiminnallisuuksia.
Jatkuva kehitysprojekti on paikallaan silloin, kun lopullisia tavoitteita on mahdoton asettaa ennakkoon. Tämä voi johtua siitä, että kehitettävä kokonaisuus on monimutkainen tai järjestelmä tulee käyttöön suurelle käyttäjämäärälle, joiden toiveita on mahdoton ennakoida. Kehittämiseen voi liittyä myös teknisempää tuntematonta, joka paljastuu vasta kehitystyön aikana ja antaa syyn suunnanmuutoksiin. Tämän takia palautteen saaminen on jatkuvassa tuotekehitystyössä todella merkittävää.
+ Kehitetään vain ominaisuuksia, jotka luovat oikeasti arvoa liiketoiminnalle.
+ Sopii erityisesti ratkaisuihin, joissa käyttäjänä on ihminen eikä kone. Varsinkin erikoistuneissa ammattiympäristöissä työskentelevien mieleen voi tulla ensimmäisten versioiden julkaisun jälkeen yllättäviäkin toiveita, joita ei suunnitteluvaiheessa osattu ennakoida.
+ Suuntaa voidaan muuttaa sitä mukaa, kun opitaan lisää todellisista tarpeista.
- Vaatii kirkkaan vision.
- Jatkuva kehitystyöllä ei ole ennakkoon suunniteltua loppua.
- Kehitystyö voi lähteä väärille urille, jos tuoteomistaja ei ohjaa tekemistä vahvalla kädellä.
- Ilman huolellista backlogin hallintaa työjonosta voi tulla toteutumattomien toiveiden tynnyri.
- Kokonaisbudjettia tavoitteiden saavuttamiseksi on hankala ennustaa.
Lähde: Tuoteomistajien rooli ja sen haasteet -tutkimus
Projektimaisen ja jatkuvan tuotekehityksen selkein ero on tavoitteissa. Rajatulla projektilla on selkeä alku ja loppu, ja myös tavoite on helppo sanoittaa ääneen.
Jatkuvassa kehitystyössä ei ole ennakkoon suunniteltua loppua ja siksi sille on huomattavasti vaikeampaa asettaa selkeitä tavoitteita. Jatkuva kehitystyö voikin vaikuttaa epämääräiseltä rajattuun projektiin verrattuna. Siksi se voi tuntua riskisijoitukselta: mitä jos menetetään valtavasti rahaa eikä käteen jää mitään järkevää?
Jatkuvaa kehitystä ei kuitenkaan kannata nähdä aikasyöppönä, joka vie liikaa rahaa ja resursseja. Oikein johdettuna sillä saadaan aikaan ne kaikkein relevanteimmat asiat, jotka tuovat liiketoiminnallesi eniten arvoa.
Yksi jatkuvan tuotekehityksen hyödyistä on sen joustavuus. Se auttaa rakentamaan juuri sitä, mille oikeasti on tarvetta – ei liian pientä eikä varsinkaan liian suurta. Tätä voi olla vaikea hahmottaa, mutta ehkä seuraava ohjelmistokehityksen ulkopuolinen vertaus auttaa ymmärtämään asiaa.
“Agile skateboard” on yleinen vertauskuva ketterälle kehitystyölle. Jos lähdetään ratkomaan paikasta toiseen liikkumisen ongelmaa jatkuvan kehityksen työtavoilla, kehitetään ensin MVP:nä rullalauta.
Kun rullalauta on ollut tovin käytössä, saadaan käyttäjiltä palautetta, että se on kiikkerä ja vaatii hyvää tasapainoa. Päätetään siis kehittää rullalautaa helpommaksi käyttää ja lisätään siihen ohjaustanko. Tämä on selvä parannus MVP-malliin, mutta sekään ei vielä riitä: moni käyttäjä kaipaa lisäksi mahdollisuutta istua. Siksi seuraavaksi kehitetään käyttäjille taas astetta parempi kulkuväline, polkupyörä.
Joku toivoo pyörään telinettä, jossa voi kuljettaa tavaraa tai toista ihmistä. Joku taas haluaisi, että pyörät rullaisivat paremmin vaihtelevassa maastossa. Moni kaipaa valoja, jotta pyörällä näkisi ajaa myös pimeässä. Ja sitten on niitä, jotka toivovat vielä enemmän. Olisi helpompaa, jos ei tarvitsisi itse polkea, vaan kulkuväline toimisikin poljinta painamalla. Tai mitä jos laite kulkisi ilmassa eikä lainkaan maata pitkin?
Äskeisen tarinan kautta päästään jatkuvan tuotekehityksen ytimeen: toiveiden laari on ehtymätön ja on tuoteomistajan tehtävänä pitää mielessä alkuperäinen visio. Toisaalta tuotekehityksen tehtävä on etsiä ja toteuttaa innovaatioita, jotka puolestaan luovat kilpailukykyä.
Esimerkkitarinassa visiona oli kehittää kulkuväline, jolla ihmiset pystyvät kulkemaan nopeammin kuin jalan. Polkupyörä on tämän vision mukainen. Seuraavaksi pitää vain miettiä, miten siitä voidaan tehdä vielä parempi käyttää.
Jos alkuperäiseen ongelmaan (miten päästään nopeammin paikasta a paikkaan b), olisi lähdetty hakemaan ratkaisua rajatun projektin kautta, olisi helposti voitu rakentaa jotain liian isoa. Ehkä olisi saman tien kehitetty lentokone, jonka valmistaminen vie satoja, ellei tuhansia kertoja enemmän resursseja kuin polkupyörän. Lentokone ei ehkä olisi yhtä helposti käyttäjien saavutettavissa kuin polkupyörä, eikä se siten olisi ratkaissut alkuperäistä ongelmaa.
Pelkästään käyttäjiltä kerättyihin toiveisiin nojautumalla saadaan kyllä kehitettyä joukko ratkaisuja. Mutta palvelumuotoilun keinoin, yhdistämällä käyttäjä- ja liiketoimintaymmärrystä uusiin teknologioihin, voidaan löytää arvokkaita mahdollisuuksia, joita käyttäjät eivät osaa vielä edes kuvitella.
Jatkuvan ketterän kehittämisen tie onkin tällaisissa tapauksissa viisain valinta, vaikka voi tuntua riskaabelilta, jos ei ole etukäteen määritelty, mitä ollaan kehittämässä. Mutta toisaalta yksi sen eduista on nimenomaan joustavuus. Kun lopputulosta ei ole hakattu kiveen, voidaan järjestelmään rakentaa uusia ominaisuuksia sitä mukaa, kun ympäröivä maailma kehittyy ja tarpeet muuttuvat. Silloin voi saada sen mitä todella tarvitsee, vaikka se ei olisikaan sitä mitä alunperin suunnitteli haluavansa.
Lue myös: Ohjelmistojen tuotekehityksen ulkoistaminen: Uhka ja mahdollisuus
Kuten edellä olevasta plus- ja miinuslistasta näkee, on rajatulla kehitysprojektilla paljon hyviä puolia. Mikään ei estä siirtämästä ainakin osaa myös jatkuvaan kehitykseen.
Sekä rajatussa että jatkuvassa tuotekehityksessä on tarpeen priorisoida tekemistä ja määritellä hyötyjä jatkuvasti. Jatkuvassa kehityksessä yksi kompastuskivi on usein liiallinen säntäily tai kehitystyön vieminen väärään suuntaan. Tuoteomistajan tulee kaiken aikaa palata visioon ja arvioida, onko jo tehty riittävän hyvää, vaikka ideoita olisi lisää.
Lähde: Tuoteomistajien rooli ja sen haasteet -tutkimus
Teimme tuoteomistajille suunnatun survey-kyselyn ja vastaukset kertovat, että tehtävä on vaativa ja monipuolinen. Ei riitä, että tuoteomistaja vain priorisoi kehitysjonoon kirjattuja tehtäviä. Hänen rooliinsa kuuluu näiden lisäksi sidosryhmäviestintää ja odotusten hallintaa, budjetista huolehtimista, teknologia- ja arkkitehtuurilinjauksia ja tulevaisuuden visiointia ja ennakointia.
Tuoteomistajilla on lähes poikkeuksetta vankkaa substanssiosaamista omalta toimialaltaan, mutta joillekin tuotekehityksen ja tuotejohtamisen tehtävät ovat vieraampia. Tuoteomistajien omien arvioiden mukaan heidän liiketoimintaymmärryksensä on vahvaa, mutta teknisistä ratkaisuista ja teknologiavalinnoista koetaan epävarmuutta. Tämä ei ollut yllätys: onhan tuoteomistajan tärkeimpiä tehtäviä tuoda kehitystyöhön nimenomaan liiketoiminnan näkökulmaa ja tehdä päätöksiä organisaation strategian pohjalta.
Joskus toimiva vaihtoehto on jakaa tuoteomistajan vastuuta. Tässä on apua kumppanista, joka pystyy tuomaan ammattitaitoisten osaajien lisäksi korkean maturiteetin toimintamalleja tuotekehittämisen tueksi.
Pohditko, millaisia haasteita tuoteomistajat kokevat työssään ja millaista tukea he kaipaavat? Lataa tutkimusraportti, ja saat yhteenvedon yli 110 vastaajan näkemyksistä!