Työnimike Chief Results Officer työskentelee ohjelmistoprojektissa kehittäjien ja myynnin välimaastossa huolehtien projektitoimitusten onnistumisesta.

Jouni Jaakkola toimii tässä roolissa ehkä yhden ohjelmistoalan näyttävimmän brändin, Solinorin, palveluksessa.

– Tärkeimpiä töitäni on koordinaatio ohjelmistokehityshankkeen tekijäporukan, myynnin ja asiakkaan välillä. Vastaan siitä, että myymme sitä mitä voimme toimittaa ja toisaalta siitä, että toimitamme mitä myymme, Jaakkola tiivistää toimenkuvansa.

“Vastaan siitä, että myymme sitä mitä voimme toimittaa ja toisaalta siitä, että toimitamme mitä myymme”

Hän on toiminut projektipäällikkönä lukuisissa globaalissa kaavassa merkittävissä medioissa. Jaakkolan CV:stä löytyy työrupeama muun muasssa New York Timesin, Discoveryn, Independent UK:n ja Boston Globen verkkomedioista, sekä Suomesta MTV:ltä, Talentumilta ja A-lehdiltä.

Työnkuvaan lukeutui “mobiiliwebbiä, web appeja, natiivisovelluksia ja kaikennäköistä kivaa”, kuten mies itse kuvaa aiempaa työuraansa.

Tällä hetkellä Jouni Jaakkola kehittää projektimalleja ja työstää projektitoimituksia löytääkseen parhaan mahdollisen tavan asiointiin asiakkaan ja ohjelmistokehitystalon välillä.

Tavoitteena on tietysti onnistua projekteissa.

 

Epäonnistuneen ohjelmistokehityshankkeen rakennusaineet

Ohjelmistokehityshankkeessa epäonnistuminen liittyy yleensä aina näkemyseroihin projektin kulusta tilaajan ja toimittajan välillä.

Ostajan näkökulmasta toimittaja ei pysy budjettiraamissa, toimittaa myöhään ja pahimmassa tapauksessa myös jotain vääränlaista.

Huonosti viestityissä hankkeissa asiakkaalle jää pahimmillaan sellainen kuva, että toimittaja on tahallaan luvannut jotain naurettavan halvalla voidakseen lopulta laskuttaa moninkertaisen summan.

“Jos toivomuksia noudatetaan sanasta sanaan ketterän projektin aikana, käytetty aika voi valjeta tilaajalle vasta tuntiraportista”

– Useimmiten ketterä toimintamalli tarkoittaa myös kevyesti määriteltyä lähtötilaa, jolloin sopimuksentekovaiheessa puolet tarvittavista ominaisuuksista jää mainitsematta, Jaakkola kuvaa.

Toisin sanoen ennakointi on mahdotonta, koska kukaan ei voi alkuvaiheessa tietää tarkalleen, mitä ollaan kehittämässä.  

Tyypillisesti toimittajan mielestä asiakas on taas itse pyytänyt joukon alunperin sovitusta poikkeavia asioita ja olettanut, ettei niiden tekeminen maksa mitään.

Ei ihme että ohjelmistoprojekteilla on huono maine.

– Tilaajilla on joskus epärealistiset odotukset siitä, mitä eri asioiden kehittäminen maksaa, eivätkä he välttämättä hahmota syy-seuraussuhteita. Ohjelmistoalan ulkopuolelta tuleva hankkija voi tilata hyvinkin ison komponentin, joka on lopputuloksen kannalta merkityksetön, mutta aiheuttaa suhteettoman suuren määrän työtä.  

Jos toivomuksia noudatetaan sanasta sanaan ketterän projektin aikana, käytetty aika voi valjeta tilaajalle vasta tuntiraportista. Tällöin asiakas on todennäköisesti  tehnyt päätöksiä vaillinaisella tiedolla ymmärtämättä kolikon toista puolta eli kuluja.

– Jos keskitytään puhtaasti siihen, että kehitetään maailman hienoin palvelu, se on ihan ok ja kaunis tavoite, kunhan molemmat ovat samalla sivulla siitä, mitä se tarkoittaa. Mutta jos niitä ominaisuuksia tehdään intohimon palosta ymmärtämättä hintalappua ja työmäärää, asiakas ei ole oikeasti mukana hommassa. Silloin tulee isompia laskuja ja yllätyksiä jälkikäteen, ja asiakassuhde on vaarassa tulehtua, Jaakkola varoittaa.

Fakta on, että jos yrityksessä olisi riittävästi ohjelmisto-osaamista omasta takaa, sitä tuskin täytyisi hankkia ulkopuolelta. Toisaalta ohjelmistoyritys ei tunne asiakkaan toimialan nyansseja.

“Projekti on onnistunut silloin, kun se saavuttaa tai ylittää asiakkaan sille asettamat odotukset”

Tästä päästään itse koodin ja kehitettävän ratkaisun ulkopuolisiin asioihin.

– Kun mietitään mikä tekee menestyneen projektin, niin se ei ole se tosi timanttinen softakehityksen jälki. Projekti on onnistunut silloin, kun se saavuttaa tai ylittää asiakkaan sille asettamat odotukset, Jaakkola sanoo.

Siksi odotusten hallinta on ohjelmistoprojektien onnistumisen keskiössä.

 

Ohjelmistokehityksen ohella Solinor mittelee vuosittain voimiaan jalkapallokentällä Fraktion kanssa.

 

Ohjelmistokehityshankkeen onnistumisen keskiössä on odotusten hallinta

Projektin menestys on siis harvoin kiinni vain suorittavan työn, kuten designin tai koodaamisen laadusta.

Jos softakehityksessä onnistuminen on riippuvainen ennen kaikkea odotusten hallinnasta, niin millä muuttujilla odotuksia sitten hallitaan?

– Odotukset voidaan karkeasti jakaa kolmeen osa-alueeseen, jotka ovat toimituksen laajuus, aikataulu ja käytettävät resurssit. Uusia asioita luodessa kaikkia kohtia on vaikea lukita. Aikataulua voidaan nopeuttaa joko kasvattamalla tiimin kokoa tai karsimalla laajuudesta, rahaa taasen voidaan säästää paitsi ominaisuuksia karsimalla, myös tekemällä tehokkaammin pienemmällä tiimillä.

On toimittajan vastuulla huolehtia siitä, että asiakasorganisaatiolla on edellytykset ja halu tehdä projektin kannalta parhaat päätökset.

Nykyään lähes kaikki ohjelmistotalot liputtavat ketterän kehityksen puolesta.

Silloin kuljetaan best-effort -mallilla kohti tuntematonta. Sopimuksellisesti ketterät asiakkuudet toteutetaan tyypillisesti siten, että myydään ohjelmistokehittäjien työaikaa ja kieltäydytään antamasta tarkkoja työmääräarvioita.

– Agile kehitys on erinomainen toimintamalli silloin, kun tehdään R&D-tyyppisesti jotain ihan uutta. Toimintatapana se vaatii kuitenkin asiakkaalta paljon osaamista ja ymmärrystä digituotekehityksestä sekä tietenkin luottamuksellisen ilmapiirin asiakkaan ja toimittajan välillä, Jaakkola kuvaa.

“Vesiputousmalli on erinomainen silloin, kun asiakas ja toimittaja ymmärtävät tarkalleen mitä halutaan tehdä”

Toisessa ääripäässä on perinteinen kiinteähintainen vesiputousprojekti.

– Vesiputousmalli on erinomainen silloin, kun asiakas ja toimittaja ymmärtävät tarkalleen mitä halutaan tehdä ja tekeminen on luonteeltaan tunnettua ja ennakoitavissa.

Vesiputousmalli vaatii kuitenkin tiukkoja sopimusneuvotteluja.

Ostajaa kiinnostaa lähtökohtaisesti hintalappu, mutta toimittajan on vaikeaa sitoutua kiinteään hintaan asiakkaan ohjatessa vaatimuksia.

Siksi usein paras ratkaisu löytyy jostain välimaastosta.

– On toimittajan ammattitaitoa löytää projektille oikea toimintamalli ja myydä se asiakkaalle. Eri toimintamalleissa vastuut ja vapaudet jakautuvat eri tavoin asiakkaan ja toimittajan välillä, joten on tärkeää, että pöydän molemmin puolin ymmärretään täysin mihin ollaan ryhtymässä, Jaakkola jäsentää.

 

Kaikki samalle viivalle

Jotta ohjelmointihankkeessa vältyttäisiin yllätyksiltä, on toiminnan ja tavoitteiden syytä olla läpinäkyviä molempiin suuntiin. Tämä tarkoittaa paljon muutakin kuin tuntiraporttien lähettämistä asiakkaalle kerran kuussa.  

– Projektin alussa on tärkeää ymmärtää projektin reunaehdot ja onnistumisen todelliset kriteerit – voidaanko esimerkiksi laajuudessa joustaa, kunhan hinta ei ylitä tiettyä kipurajaa? Onko toimituksen aikataulua mahdollista pidentää jos siitä saadaan kustannussäästöä? Selkeät reunaehdot antavat toimittajalle mahdollisuuden harjoittaa omaa ammattitaitoaan, Jouni Jaakkola sanoo.

“Selkeät reunaehdot antavat toimittajalle mahdollisuuden harjoittaa omaa ammattitaitoaan”

On toimittajan edun mukaista, että asiakas suoriutuu omista velvoitteistaan projektissa hyvin. Asiakkaan velvoitteet riippuvat suuresti projektin toimintamallista, mutta jokainen kehityshanke sisältää niitä jossain määrin.

– Ammattitaitoinen toimittaja osaa kertoa asiakkaalle mihin ollaan ryhtymässä ja mitä asiakkaalta oikeasti odotetaan. Näin luodaan todelliset edellytykset onnistuneelle odotusten hallinnalle, Jaakkola sanoo.

Projektin aikana aktiivinen ohjausryhmätyöskentely varmistaa sen, että kaikki sidosryhmät ovat tietoisia siitä, mitä ollaan tehty, missä mennään ja mitä tehdään seuraavaksi. Näin vältytään kulkemasta laput silmillä ainoastaan projektin operatiivisen tahon ohjaamana.

– Yllätyksiä ja mutkia tulee matkaan aina. Mitä aikaisemmin asian kuin asian nostaa pöydälle, sitä paremmin siihen voidaan reagoida. Kun asiakkaalla on oikea käsitys odotuksista ja ne täytetään, niin todennäköisesti hän on tyytyväinen.

 

Lue myös: Mikä on Bluetooth-Beacon ja miten sitä voi hyödyntää sovelluskehityksessä?

 

Solinorin ite wiki -profiili
Solinorin 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!