Miten kehität uutta laadukkaasti, jos budjetti on aiempaa tiukempi?

Ohjelmistokehitykseen laitetuista euroista pitäisi saada maksimaalinen hyöty sovellusten käyttäjille. Tämä on paine, jonka jokainen tuotekehitystiimi varmasti tunnistaa – erityisesti silloin, jos uuden luomiseen on varattu aiempaa vähemmän resursseja.

Ohjelmiston tuotekehityshankkeesta vastaava projektipäällikkö  joutuu tekemään tiiminsä kanssa budjettiin vaikuttavia päätöksiä jatkuvasti. Erityisesti teknologioihin liittyvät päätökset voivat vaikuttaa projektin aikatauluun nopeuttamalla tai hidastamalla sitä. Niillä on merkitystä myös ylläpitokustannusten ja käytettävyyden kannalta.

Liiketoiminnan tavoitteet sanelevat mitä tehdään, mutta päätöksiä tarvitaan myös siitä, miten tehdään. Esimerkiksi:

• Millaisia teknologioita tarvitaan? 
• Miten laajasti käytetty ohjelmointikieli on ja millainen on sen elinkaari?
• Millaisia osaajia kehitystiimiin tarvitaan? 
• Onko jotain erityistoiveita, joita tulee huomioida kehitystyössä?  
• Korvataanko vanhaa vai tehdäänkö kokonaan uutta? 
• Onko mahdollista miettiä kaupallisia ratkaisuja tai tehdäänkö avoimen lähdekoodin ratkaisua? 

Harva projektipäällikkö tai liiketoimintalähtöinen tuoteomistaja kuitenkaan on perehtynyt kovin syvällisesti teknologioihin tai tuotekehityksen tekniseen puoleen, kuten arkkitehtuuriin. Tästä kertoo myös Cinian tekemä tutkimus, jonka perusteella vain 24 % tuoteomistajista “ymmärtää teknisiä ratkaisuja riittävän syvällisesti pystyäkseen haastamaan tiimin valintoja”. 

Harha-askeliin ei oikein olisi varaa, etenkin jos järjestelmäkehityksen budjetit ovat tiukassa. Katsotaan seuraavaksi, mistä suunnasta haastavia valintoja voisi lähteä purkamaan.

Mitä valita, kun kaikkea ei voi saada? 

Projektinhallinnassa tunnetaan yleisesti projektikolmio eli rautakolmio. Kolmio koostuu kolmesta olennaisesta asiasta: ajasta, rahasta ja projektin sisällön laajuudesta. Viimeisestä käytetään usein myös termiä scope.

Aika, raha ja scope pyörivät tuoteomistajan ja projektipäällikön mielessä toistuvasti. Ja niin pitääkin, koska ne vaikuttavat aina toisiinsa. Jos yhtä näistä muutetaan matkan varrella, vaikuttaa se aina vähintään yhteen asiaan – joskus kaikkiin.

Jos projekti halutaan saada valmiiksi suunniteltua nopeammin, tai mukaan halutaan saada mukaan jokin uusi ominaisuus (eli muutetaan scopea), tarvitaan lisää työtunteja ja/tai -tekijöitä. Molemmat maksavat eli muutos vaikuttaa budjettiin. 

Lähes kaikissa projekteissa joudutaan tekemään kolmion sivuihin liittyviä valintoja. Jos budjettia ei voida venyttää, pitää keskustella koko tiimin ja projektiryhmän kesken, mitä nuo valinnat ovat. 

Raamit, struktuurit ja psykologinen turvallisuus mahdollistavat järkeviä valintoja

Äkkiseltään kuvittelisi, että esimerkiksi onnistuneisiin teknologiavalintoihin tarvitaan vain markkinoiden osaavimmat softakehittäjät, ja priimaa syntyy. Totuus on toinen.

Yksittäisen ihmisen kovinkaan osaaminen ei nimittäin auta koko tiimiä onnistumaan, pysymään budjetissa tai luomaan ohjelmistotuotteelle maksimaalista arvoa, jos ohjelmistokehityksen kulttuuri ei ole kunnossa. Osaamisen lisäksi tarvitaan raameja, struktuuria ja halua jatkuvaan parantamiseen.

Seuraavaksi listaan neljä muuttujaa, joiden kuntoon laittaminen auttaa ohjaamaan tuotekehityksen valintoja oikeaan suuntaan. Kun nämä pohjatyöt on tehty hyvin, ja tiimistäsi sen lisäksi löytyy riittävästi osaamista, ei yksittäisten valintojen tekeminen aiheuta suurta päänsärkyä.

1. Määrittele “riittävän hyvä” arvontuoton kautta

Riittävän hyvän määritteleminen, yhä uudelleen ja uudelleen, on yksi projektitiimin ja tärkeimpiä tehtäviä. Riittävän hyvä ohjaa tekemään valintoja silloin, kun kaikkea ei voi saada. Kun määrittelet riittävän hyvän, joudut ottamaan kantaa projektin scopeen, eli myös siihen, mihin rahaa ja aikaa käytetään.

Joskus voi olla vaikeaa määritellä, mitä on riittävän hyvä. Tässä auttaa, kun muistuttaa itseään, että tuotekehityksen tulee aina tuottaa jotakin arvoa. 

Ei siis kannata havitella kaikkia mahdollisia ominaisuuksia kerralla, vaan tähdätä ainakin aluksi MVP-tasoon (minimum viable product), joka täyttää kriittisimmät tarpeet ja tukee liiketoimintaa parhaiten. 

2. Rakenna viestintään mietityt toimintamallit

Yksi onnistuneiden projektien kulmakivistä on avoin keskustelu ja viestintä. Projektilla on hyvä olla sovitut tavat siihen, miten asioita nostetaan esiin kehitystiimin sisällä ja miten niitä viedään eteenpäin esimerkiksi projektin omistajataholle tai ohjausryhmälle.

Otetaan esimerkki: Tiimi tunnistaa uuden, kolmanteen osapuoleen liittyvän riskin, joka vaikuttaa joko aikatauluun, budjettiin tai scopeen. Ongelma käsitellään sovitun toimintamallin mukaisesti ohjausryhmätasolla. Tiimi miettii yhdessä vaihtoehtoisia tapoja ratkaista tai kiertää riskin toteutuminen. Tästä seuraa jatkotoimenpiteitä, ja ne käsitellään jälleen sovitusti, tarvittaessa ohjausryhmätasolla.

Riskienhallinta ei ole tuoteomistajan tehtävien joukossa helpoimmasta päästä. Lähde: Tuoteomistajien rooli ja sen haasteet -raportti

3. Muista laatuvipu eli hallitse riskejä ajoissa 

Budjetti pysyy varmimmin raiteillaan, kun riskienhallintaan kiinnitetään huomiota alusta asti. Kehitysitiimin, erityisesti tuoteomistajan, tuleekin miettiä riskejä lähes päivittäin. Riskienhallinnassa on kyse yhdenlaisesta lumipalloefektistä: kun pieneltä tuntuvaan ongelmaan tartutaan heti, niin se ei pääse kasvamaan isoksi. 

Esimerkiksi yksittäisen komponentin päivitys voi olla tänään pieni ongelma, mutta jos tekemistä lykätään, edessä onkin useamman teknisen ratkaisun päivityssavotta sen riippuvuuksien vuoksi. Tai tulevaisuudessa näkyy liiketoiminnallinen tarve, jonka huomioiminen ei vielä vaadi paljon muutoksia, mutta huomiotta jättäminen voi tehdä tulevaisuudessa järjestelmästä kankean ja tarpeisiin sopimattoman.

4. Vahvista psykologista turvallisuutta

Hyvä tiimi koostuu ammattitaitoisista osaajista, joilla kaikilla on usein eri vahvuudet. Jos voimme huomoida tekemisessä eri kyvykkyydet, toimintatavat ja ominaisuudet, voimme esimerkiksi suunnitella tiimin arkirytmin niin, että päivittäiset palaverit ja toimintavat tukevat sitä, että asiakkaille voidaan tuottaa mahdollisimman hyvin ja maksimaalisesti lisäarvoa. Myös suunnitelmien, prosessien ja työkalujen pitää tietysti olla kunnossa.

Psykologinen turvallisuus on yksi tärkeimmistä avaimista siihen, että ohjelmistokehityksessä pystytään tekemään valintoja, jotka ohjaavat resurssien käyttöä oikeaan suuntaan. Turvallisessa tiimissä:

• jokainen uskaltaa kyseenalaistaa, onko uusi ominaisuus “nice to have” vai tuottaako se aidosti arvoa
• viestintä sujuu ilman katkoja, vaikka tiimiin kuuluisi jäseniä eri organisaatioista ja
• jokainen voi kertoa ongelmista jo silloin, kun ne ovat pieniä.

Laadusta tinkiminen voi tulla kalliiksi 

Palataan äskeisten raamien jälkeen vielä projektikolmioon, joka koostuu kolmesta sivusta. Sivujen välissä, kolmion keskellä, on vielä jotain olennaista ja se on laatu. 

Totesin jo aikaisemmin, että muutos yhdessä asiassa vaikuttaa aina vähintään yhteen muuhun seikkaan. Mutta laatuun muutokset vaikuttavat aina. Kun projektissa tingitään laadusta, voidaan saada säästöjä lyhyellä aikavälillä. Mutta pitkässä juoksussa puutteet laadussa tuottavat yleensä suuria kustannuksia.

Laadulle ei ole olemassa yhtenäisiä kriteereitä, vaan ne riippuvat aina siitä tarpeesta, johon järjestelmää rakennetaan, sekä käytössä olevista resursseista. Tässä kuitenkin muutama asia, joita suosittelen priorisoimaan silloinkin, kun tuotekehityksen budjetti on tiukka:

• Testaus: Jos ohjelmistoa ei testata riittävän hyvin, virheet tulevat esiin vasta tuotantovaiheessa, ja niiden korjaaminen jälkikäteen on kallista.
• Tietoturva: Uhkaympäristö muuttuu nopeasti ja lainsäädäntö asettaa uusia vaatimuksia useille eri toimialoille. Vaakalaudalla on liiketoiminnalle tärkeä data ja yrityksen maine. Riittävä sovellustason tietoturva on vaatimus, josta ei voi tinkiä.
• Käyttäjäkokemus: On vaikea keksiä kalliimpaa sijoitusta kuin kymmenien tai satojen tuhansien eurojen järjestelmä, jota kukaan ei halua käyttää. Ja toisin päin: hyvä käyttäjäkokemus siivittää kohti menestystä. 

Tuotekehityksen priorisoinnissa on lukuisia eri muuttujia. Näin vastaukset jakautuivat, kun kysyimme, mikä ohjaa tuoteomistajan päätöksentekoa. Lähde: Tuoteomistajien rooli ja sen haasteet -raportti

Yksin on vaikeaa onnistua – tiimin monipuolisuus ja resilienssi ratkaisee

Kehityshanketta luotsaavan tuoteomistajan ei tarvitse olla ohjelmistokehittäjä tai teknologian tuntija. Hänen tehtävänsä on luoda visio ja priorisoida, mutta sekään harvoin onnistuu yksin. Ympärille tarvitaan osaamista monesta eri roolista. 

Maksimaalista hyötyä rajallisella budjetilla pystyy tarjoamaan ohjelmistokehityskumppani, jonka puolelta tiimiä voi laajentaa tai supistaa aina sen mukaan, mitä ohjelmistohankkeen vaihe kulloinkin vaatii. Kumppanilta pitää voida saada apua tarvittaessa myös raamien ja struktuurien luomiseen.

Mikä toteutustapa on oikea? Kuinka paljon se vaatii työtä, millaisia ominaisuuksia siihen liittyy, ja tuottaahan ratkaisu varmasti juuri sitä arvoa mitä haetaan? Jos otetaan tässä kohdassa priorisoinnin vuoksi tietoista teknistä velkaa, mitä se vaatii meiltä myöhemmin?

Kun projektitiimin eri jäsenet, kuten projektipäällikkö, IT-arkkitehdit, sovelluskehittäjät, scrum master, testaajat, designerit ja tuoteomistaja lyövät viisaat päänsä yhteen, he muodostavat yhdessä hyvin perustellun näkemyksen siitä, mikä suunta on oikea.  

Millaisia haasteita tuoteomistajat kokevat työssään ja millaista tukea he kaipaavat?