Mitä enemmän jaat, sitä enemmän saat - ohjelmistohankkeessa avoimuus ja luottamus ratkaisevat

Ohjelmistokehityshankkeen menestys on monesti verrannollinen hankkeen osapuolten välisen avoimuuden ja luottamuksen määrään. Mitä enemmän asiakas on valmis kertomaan liiketoiminnastaan ja hankkeestaan, sen taustoista sekä ympäristöstä, missä hanketta tehdään, sitä varmemmin kumppani pystyy vastaamaan todellisiin tarpeisiin. Ja sama pätee toisinpäin – luotettava ja pitkäjänteinen kumppani kertoo myös avoimesti toiminnastaan ja osaa kysyä oikeat kysymykset.

Vaikka erilaisten ohjelmistohankkeiden kokoluokka, budjetti ja toimitusmallit olisivat päällisin puolin samankaltaiset, niin jostain syystä toiset asiakkaat saavat kehitystyöstä enemmän irti kuin toiset. Miksi näin on?

Yksi selittävä tekijä on asiakkaan ja toimittajan välillä vallitseva avoimuuden ja luottamuksen taso. Vaikka osapuolet lähtökohtaisesti luottavat toisiinsa, niin arjen kommunikoinnissa ilmenee isoja eroja: Kun yksi asiakas antaa toimittajalle tietoa vain välttämättömässä laajuudessa kehitystyön suorittamiseksi, niin toinen asiakas on valmis avaamaan ohjelmistokumppanilleen koko liiketoimintastrategiansa ja pitkän aikajänteen roadmapin.

En kuitenkaan väitä tämän olevan tietoista toimintaa, vaan esimerkiksi asiakkaan toimiala ja sen oma kulttuuri voivat nostaa kynnystä tiedon jakamiseen korkeaksi. On kuitenkin kiistatonta, että mitä avoimemmin toimittajalle kommunikoidaan sovelluksen vaatimusten ohella liiketoiminnan tavoitteita ja kehitykseen vaikuttavia ulkoisia olosuhteita piirtäen niin sanottua “isoa kuvaa”, sitä parempia tuloksia asiakkaalla on lupa odottaa itse kehitystyöltä.

Ohjelmistoprojektin peruskysymykset hahmottavat kokonaisuutta

Ohjelmistoprojektissa avoimuus on siis tärkeää. Kun kumppanin kanssa on jaettu riittävästi tietoa niin tämän hetken tilanteesta kuin tulevaisuudenkin suunnitelmista, myös toimittajalla on edellytykset ohjata hanketta oikeaan suuntaan.

Vastaa ainakin seuraaviin kysymyksiin:

• Mikä on ohjelmistohankkeen tarkoitus (purpose ja scope)?
• Mitä hankkeessa on tarkoitus tuottaa?
• Miten se auttaa liiketoimintaasi, mihin kaavailtu ohjelmistoratkaisu vaikuttaa?
• Mitä odotuksia ohjelmistohankkeeseen liittyy? Minkälainen vaikutus sillä odotetaan olevan esimerkiksi yrityksen tulokseen, prosesseihin?
• Mikä on hankkeen tuotekehitykselle suunniteltu budjetti?

Kun tällaiset kysymykset käydään läpi, saadaan laajempi kuva, ja kumppani pystyy toimittamaan laudanpätkien sijaan kokonaisia elementtejä. Kysymysten pohjalta voidaan arvioida hankkeesta muodostuvan tuotteen ja sen komponenttien elinkaarta sekä kriittisyyttä, ja sitä kautta ennakoimaan tulevia kehitystarpeita.

Erityisesti tuotekehityksessä joudutaan usein pohtimaan, toteutetaanko pienemmällä työmäärällä ominaisuus tiedossa olevaan tarpeeseen, vai käytetäänkö kehitykseen hieman enemmän aikaa ja luodaan näin pohjaa ohjelmiston laajennettavuudelle ja/tai komponentin uudelleen käytettävyydelle myöhemmin.

Kun kumppanin tiimi tuntee riittävällä tasolla koko kokonaisuutta, olosuhteita ja asioiden vaikutus- ja riippuvuussuhteita, se pystyy etsimään ja ehdottamaan parempia ratkaisuja ja auttamaan asiakasta punnitsemaan hankkeen aikana tehtyjä päätöksiä.

Rahastakin pitää puhua

Hanketta käynnistettäessä ohjelmiston tulevat käyttäjät ja muut määrittelyyn osallistuvat ovat usein innoissaan: vihdoinkin pääsen kertomaan tarpeistani ja toiveistani! Kun kaikki toiveet ominaisuuksista on kerätty, usein huomataan, että niiden kaikkien kehitystyö voikin maksaa enemmän kuin kehitykseen on mahdollista satsata.

Ketterissä ohjelmistohankkeissa tarkkaa budjettia ei hankkeen käynnistyessä useinkaan tiedetä, sillä kaikkia vaatimuksia ja tarpeita ei ehkä tunneta, tai tekniseen toteutukseen liittyy epävarmuuksia. Ketterille hankkeille on lisäksi luontevaa, että hankkeisiin halutaan jättää pelivaraa matkan varrella tehtäville muutoksille.

Kumppanin kanssa on syytä käydä keskustelu kaavaillusta budjettihaarukasta, jotta sitä voidaan peilata yhtäältä vaatimusmäärittelyn toivelistaan ja toisaalta suunniteltuun tiimikokoonpanoon. Kun toimittaja ymmärtää taloudelliset realiteetit, se voi pitää huolta siitä, että annetussa budjetissa saadaan tuotettua keskeisiltä osin valmis, toimiva järjestelmä eikä kaikilta osin vielä keskeneräinen “toiveiden tynnyri”.

Työstä liiat ominaisuudet pois

Yllämainittu, myös feature-ähkyksi kutsuttu asia, voidaan välttää helposti jo hankkeen suunnitteluvaiheessa käymällä kumppanin kanssa huolellisesti läpi, mitä ohjelmistolta odotetaan, minkälaisiin tarpeisiin sen tulisi vastata ja keitä käyttäjät ovat.

Työpajamuotoisesti käytävä ensivaiheen selvitystyö on nopea ja halpa tapa saada selkeä käsitys siitä, mitkä ovat kriittisiä ja ehdottoman tärkeitä ominaisuuksia, ja mitkä nice-to-have -tyyppisiä lisätoiveita. Samalla voidaan käydä läpi aikataulusovitus, stakeholderit sekä tarpeen mukaan vaikkapa markkinatilanne.

Ensivaiheen selvitystyön tuloksena syntyy näkemys siitä, millaisen investoinnin halutun mukaisen ohjelmistoratkaisun kehittäminen vaatii sekä miten kauan se vie aikaa. Työn myötä syntyy myös ohjelmistokehittäjien kieltä puhuva materiaali, jonka pohjalta ohjelmistohanke on mahdollista kilpailuttaa ja kehitystyö on nopea ja helppo käynnistää kenen kanssa tahansa.

Tässä vaiheessa myös tunnistetaan, jos ohjelmistoratkaisun tai integraation sijaan tavoitteet voidaan saavuttaa kustannustehokkaammilla ratkaisuilla, kuten ohjelmistorobotiikalla (RPA, robotic process automation) tai manuaalisten työnkulkujen selkeyttämisellä ja tehostamisella. Tällainen saattaa tulla kyseeseen silloin, kun esimerkiksi integraation rakentaminen useiden eri toimijoiden kanssa on liian kallista tai aikaavievää tai kaavaillulla featurella ei ole lopulta paljoakaan käyttöä suhteessa siihen aikaan, joka kuluu ominaisuuden rakentamiseen.

Nykyisin jo patenttiratkaisuna tarjottua workshop-lähestymistä ei todellakaan kannata ohittaa kevyin perustein. Poikkeuksetta asiakkaamme sanovat ammattilaisten läpiviemän ja mahdollisesti teknisellä selvityksellä täydennetyn workshopin jälkeen asioiden olevan myös oman liiketoiminnan kannalta huomattavasti selkeämmin jaoteltuna ja ymmärrettävissä paremmin.

Myös toimittaja rakentaa avoimuutta

Ensimmäinen uskon askel luottamuksessa ja avoimuudessa otetaan jo myyntitilanteessa – avaako asiakas myyntiprosessin aikana riittävästi ongelmakenttää, jotta toimittajan työkalupakista voidaan tuoda oikeat ratkaisut?

Avoimuus on kuitenkin kahden kauppa ja luottamus syntyy ohjelmistohankkeessakin kaksisuuntaisessa vuorovaikutuksessa. Kysyykö toimittajakandidaatti oikeat kysymykset, kuuleeko vastaukset, ja tarjoaako hän standardiratkaisun sijaan yrityksen yksilölliseen tilanteeseen parhaiten sopivaa ratkaisua?

Avoimuus ja luottamus korostuu entisestään, kun kehityshanketta lähdetään toteuttamaan. Tarjoamalla myös asiakkaalle pääsyn projektinhallinnan välineisiin ja kehityksen aikaiseen dokumentaatioon toimittaja tekee yhteistyöstä läpinäkyvää. Se luo yhteisymmärrystä backlogin sisällöstä, priorisaatiosta, työmääristä, resursseista ja riskeistä.

Kun tehtävät backlogilla on yhdistetty työmääräarvioihin sekä laskutukseen, asiakas pystyy tarkemmin ennakoimaan ketterästä kehitystyöstä tulevia kuluja.

Dokumentaatio asiakkaalle

Tärkein avoimuuden elementti liittyy projektin dokumentaatioon. Varsinkin räätälöidyn ohjelmiston kohdalla on välttämätöntä sopia siitä, kenelle lopullisen tuotteen immateriaalioikeudet jäävät ja millainen dokumentointi kehitystyöhön tulee sisältyä.

Vaikka tällä hetkellä ohjelmistokehityskumppani tuntuisi mitä täydellisimmältä matchilta, siihen pätee sama kuin moderniin avioliittoon; you never know. Luotettavan toimittajan erottaakin siitä, että eräänlaisena avioehtona ohjelmiston dokumentaatio sekä ratkaisun immateriaalioikeudet jäävät aina asiakkaalle.

Näin suhteesta on helpompaa ja kivuttomampaa päästä myös eroon ja osapuolet voivat jatkaa uusiin suuntiin, mikäli tilanne sitä vaatii.

Toimittaja pitää hankkeen fokuksessa

Avoimuus ja luottamus mahdollistaa myös laadukkaan muutosten hallinnan ja tuottavuuden ketterässä kehitystyössä. Mikäli toimittaja ottaa vaillinaisen tiedon varassa ja enempiä kyselemättä tehtäväkseen kaiken mitä asiakas hoksaa sprinttien vaihdoissa ehdottaa, rahaa varmasti palaa ja aikataulut alkavat venyä.

Jos sen sijaan toimittajalle on jaettu riittävän avoimesti tietoa ohjelmistohankkeen kontekstista ja liiketoiminnan tavoitteista, tämä osaltaan torjua kehitystyön tuottavuutta vaarantavaa scopen paisumista (eng. scope creep) kertomalla kuinka paljon uudet toiveet vaikuttavat kehitystyön budjettiin tai aikatauluun.

Vaikka ohjelmistohankkeissa vaaditaan toki aina joustoa innovointiin ja epävarmuuden selättämiseen, sovelluskehityksen kumppanilla tulee olla myös kyky pitää kehitystyön laajuus suitsittuna ja fokus asioissa, jotka tuottavat arvoa ja kuljettavat tiimiä määrätietoisesti kohti ohjelmiston julkaisua tavoitellussa aikataulussa.

Koska asiakkaan liiketoiminnan näkökulmasta on aina kyse myös siitä, milloin tehdyn työn hedelmistä päästään käytännössä nauttimaan.

Näin tunnistat avoimen ja luotettavan ohjelmistokehityskumppanin:

• Oikeat ja fiksut liiketoiminnan kokonaiskuvaa ja arjen ongelmia haravoivat kysymykset myyntivaiheessa
• Molemminpuoliset toiveet ja odotukset hankkeelle selvitetään huolellisesti ennen kehitystyön starttaamista ja kommunikoidaan kaikille. Toimittaja on valmis ja halukas sitoutumaan tavoitteisiin
• Näkemyksellinen ja perusteltu ehdotus tarpeisiin soveltuvaksi ratkaisuksi
• Toimittaja pystyy selkeästi kuvaamaan omat vaatimusten tuottamisen, ketterän kehityksen, laadunvarmistuksen ja ohjelmistojen julkaisun prosessinsa
• Asiakkaalle tarjotaan pääsy projektinhallinnan työkaluihin ja kehitysympäristöön
• Toimitettavaan ratkaisuun sisältyy riittävä tekninen dokumentaatio
• Immateriaalioikeudet jäävät asiakkaalle
• Toimittaja on valmis tarjoamaan kehittämälleen ohjelmistolle ylläpito- ja tukipalvelua, asiakkaan tarpeiden mukaisesti
• Ensimmäisestä kohtaamisesta saakka muodostuu hyvä ja välitön tunne yhteistyön sujuvuudesta myös henkilötasolla.