“Teknologiapäätöksiä ei missään nimessä tule ulkoistaa kumppanille, vaan asiakasorganisaation täytyy itse olla kuskin paikalla", sanoi eräs vastaajista, kun kysyimme yli sadalta Product Ownerilta vinkkejä tuoteomistajan roolissa onnistumiseen.
Mitä ovat ne teknologiapäätökset, jotka ainakin täytyy pitää omissa käsissä? Voiko liiketoimintakriittistä hanketta ylipäätään antaa ulkopuolisen tiimin kehitettäväksi?
Kysymykset mietityttävät esimerkiksi teollisuuden, logistiikka-alan, energia- tai sote-sektorin kehitysjohtajia.
Kannattaako tuotekehityksen ulkoistaminen? Yhteenveto artikkelista:
- Tutkimusdatan perusteella tuoteomistajat kaipaavat tukea tekniseen osaamiseen ja teknologiapäätösten tekoon. Kaikki eivät saa sitä oman organisaationsa sisältä.
- Liiketoimintariskiä ei voi ulkoistaa. Kehitystyön teknistä tuoteomistajuutta kuitenkin voi ja kannattaa jakaa ulkoistetun tiimin kanssa, vaikka se vaatiikin avoimuutta ja luottamusta.
- Kehityskumppanin on tunnettava toimialan erityispiirteitä, saatava avoimesti tietoa strategisista tavoitteista ja tarjottava läpinäkyvyys työmääräarvioihin ja kustannuksiin.
- Ketterät menetelmät eivät yksin takaa kustannustehokkuutta. Teknologiavalintojen kriittinen arviointi ja asiantunteva vaatimusten hallinta pitävät budjetin paremmin aisoissa.
Tuotekehityksen ulkoistamisen riskit
“Vastuun antaminen ulkopuolelle on se suurin asia, joka ulkoistusta harkitsevia kehitysjohtajia huolettaa. Se liittyy tunteeseen siitä, että omassa talossa työskentelevä kehittäjä tai arkkitehti on lähempänä ja siksi sitoutuneempi hyvään lopputulokseen”, kuvailee liiketoimintajohtaja Ville Vainio Cinialta.
Toisaalta Vainion kuulema palaute nykyisiltä asiakkailta antaa toisenlaisen perspektiivin: ulkopuoliselta kumppanilta saatu tekninen näkemys onkin juuri sitä virkistystä, jota oman tuotetiimin porukka on kaivannut.
“Mitä sitoutumiseen tulee, meille tuotekehityskumppanuuden tarjoaminen on liiketoimintaa”, Vainio muistuttaa. “Tyytyväisen asiakkaan kanssa yhteistyö jatkuu pitkäjänteisesti, ja sehän on molempien kannalta hyvä tilanne.”
Millaisia peikkoja vastuun jakamisen tiellä oikeastaan on? Ohjelmistokehityksen ulkoistamisen riskejä ovat ostajan näkökulmasta:
- Kustannusten hallinta, eli kuinka vältetään ennakoimattomat jättilaskut ja saadaan tuotekehityspanostuksille odotusten mukaista lisäarvoa
- Päätösvallan ja vastuun jako, eli millaiset teknologiapäätökset kannattaa pitää tiukasti omissa käsissä, millaisia päätöksiä tiimi voi tehdä itsenäisesti
- Toimialaosaaminen, eli ymmärtääkö kumppani liiketoimintaa ja alan maisemaa riittävän hyvin.
Tutustu yli sadan vastaajan näkemyksiin tuoteomistajan roolista ja sen haasteista:
Kustannusten hallinta: Ketteryys ei ole oikotie
“Ketterien menetelmien soveltaminen on vienyt budjeteista päättäviltä otetta siihen, kuinka paljon uuden rakentaminen lopulta maksaa”, sanoo Kimmo Alamartimo, liiketoimintajohtaja ja Vainion kollega Cinialta.
Eikö ketteryyden nimenomaan pitänyt lisätä hallintaa?
“Agile on ilman muuta kustannustehokkain ja tuottavin tapa johtaa modernia sovelluskehitystä ja päästä lyhintä reittiä konkreettisiin tuloksiin. Mutta joskus teknisten peruskivien muuraaminen voikin viedä odotettua paljon enemmän aikaa. Tietoturvavaatimukset, riippuvuudet tai monet muut tekniset haasteet voivat yllättää tai kehitystyön laajuuden hallinta pettää. Kun tuotoksia ei synny odotettuun tahtiin ja rahatkin saattavat olla tiukilla, aletaan olla ongelmissa.”, Alamartimo selittää.
Valmistumisajankohtien ennustaminen on haastavaa ilman riittävää tukea. (Tuoteomistajien rooli ja sen haasteet -tutkimus)
Ketteryyden arvo on läpinäkyvyydessä ja notkeudessa, mutta kaikkia ongelmia se ei yksin ratkaise. Kustannusten ennakoitavuus paranee, kun kumppania etsiessä kiinnittää huomiota näihin asioihin:
1) Saatko alkumetreillä riittävän syvällisiä, jopa kriittisiä neuvoja ja kysymyksiä ideoidesi toteutuskelpoisuudesta? Kumppani, jolla on korkea osaaminen ja maturiteetti kehitystyön johtamisessa, osaa heti kiinnittää huomiota onnistumisen ja jatkuvuuden kulmakiviin: ovatko teknologiat ajantasaisia ja siirrettäviä, miten ohjelmisto ja kehitystyö on dokumentoitu ja kuinka laadunvarmistus on hoidettu. Sitoutunut kumppani sparrailee myös liiketoimintaan liittyen: Miten ohjelmiston tuotekehitys skaalautuu, jos bisnes lähtee satumaisesti lentoon? Entä jos tulovirta ehtyy ja täytyy selvitä vähemmällä – miten kehityksen jatkuminen silloin turvataan?
2) Saatko tuotekehityskumppanilta tukea jatkuvaan vaatimusten hallintaan? Tuki on sprinttien varrella jaettua realistista näkemystä siitä, kuinka paljon kunkin uuden ominaisuuden kehittämistyö vaatii työtä konepellin alla. Se on myös jatkuvaa haastamista ja teknisen velan kanssa tasapainoilua. Minkälaisia ylläpitotoimenpiteitä ja päivityksiä jatkuvasti kehitettävään järjestelmään on tehtävä lyhyellä aikajänteellä? Mitä voidaan lykätä myöhemmäksi? Minkälaisia riskejä vaihtoehtoihin liittyy ja kuinka ne pidetään aisoissa?
Vastuunjako: Osan teknologiapäätöksistä voi ulkoistaa
Ohjelmistokehityksen ulkoistaminen tarkoittaa perinteisesti toimintamallia, jossa tilaajan tuoteomistaja vastaa kehitystyön laajuudesta, priorisoinnista sekä ohjelmiston arkkitehtuurityön johtamisesta. Ulkopuoliselta kumppanilta hän ostaa toteutustyön eli suunnitelmien implementoinnin.
Jos tuoteomistajalla ei ole teknistä osaamista – kuten usein ei ole – yhteistyön voi järjestää myös toisin:
- Ohjelmistokumppanin riveistä nimetään tiimiin tekninen tuoteomistaja, joka jalostaa priorisoidut tehtävät tarkemmalle tasolle siten, että ne ovat tiimin toteutettavissa ja vastaavat tuotekehityksen strategisia linjoja.
- Suuret teknologiavalinnat jäävät kuskin paikalla istuvalle liiketoiminnan tuoteomistajalle, mutta niihinkin saa asiantuntevaa tukea. Tekninen tuoteomistaja ja kehitystiimi voivat auttaa arvioimaan mahdollisuuksia, riskejä ja vaikutuksia esimerkiksi sen suhteen, toteutetaanko jokin järjestelmän toiminnallisuus tiimin omin voimin alusta asti vai integroidaanko kokonaisuuteen kolmannen osapuolen tuote.
Liiketoimintariskiä ei voi ulkoistaa, joten siitä varsinainen tuoteomistaja huolehtii kuten ennenkin. Erilaisten skenaarioiden hahmottelussa ja niihin varautumisessa on silti apua tuotekehityskumppanista, joka ymmärtää liiketoiminnan näkökulman.
Vaatimusten hallinta ja priorisointi on tuoteomistajan työn ydintä. Vain pieni osa (11%) joutuu huolehtimaan siitä silti täysin itsenäisesti. (Tuoteomistajien rooli ja sen haasteet -tutkimus)
Vastuun jakaminen edellyttää vahvaa luottamusta ja tasavertaisuuden kokemusta osapuolten kesken. Kommunikointi on kaiken lähtökohta, jotta jokainen tietää mitä tekee ja miksi.
“Kumppanin liiketoimintamallilla on paljon väliä. Jos toteutustyötä ulkoistetaan resursointimallilla ostamalla yksi konsultti kerrallaan, vastuu tiimin yhtenäisistä käytänteistä, dokumentaatiosta, laadun varmistamisesta sekä jatkuvuuden turvaamisesta henkilövaihdostilanteissa on tilaajan puolella. Ammattitaitoinen tuotekehityskumppani voi sen sijaan ottaa kantaakseen suurimman osan näistä murheista ja tuoda tekemiseen ryhtiä, varmuutta ja ennakointia”, Alamartimo korostaa.
Toimialaosaaminen: Tuotekehityksen ulkoistaminen onnistuu, jos tieto liikkuu molempiin suuntiin
Tutkimusdatan perusteella Product Ownerit kaipaavat paljon tukea juuri teknologiapäätöksissä. He tuntevat hyvin oman organisaationsa liiketoiminnan näkökulman, mutta tekninen osaaminen ei ole välttämättä heidän vahvinta kompetenssialuettaan”, Alamartimo valottaa.
Alustat, teknologiat ja tietoturva korostuvat tuoteomistajien vastauksissa. (Tuoteomistajien rooli ja sen haasteet -tutkimus)
Toisaalta kumppanin on oltava kartalla asiakkaansa toimialasta. Sote-alan ohjelmistokehityksessä on erittäin tärkeää tuntea potilasdatan tietosuojavaatimukset. Yhteiskunnan kannalta kriittisillä toimialoilla NIS2-direktiivi on huomioitava koodin perustuksista alkaen.
“Me emme kuitenkaan voi olla asiakkaan markkinatilanteen parhaita asiantuntijoita. Paras lopputulos syntyy, jos asiakas kertoo meille avoimesti strategisista tavoitteista ja suunnitelmista, kyvykkyyksistä, markkinoista ja kilpailjoista sekä riskeistä”, Ville Vainio täydentää. “Kumppani ei voi ottaa liiketoimintariskiä kantaakseen, mutta tuotekehityksen tiekartan realistiseen suunnitteluun voimme tuoda paljon näkemystä.”
Miten luottamus rakentuu?
Mitä kunnianhimoisempia tavoitteita asetetaan ja mitä monimutkaisemmasta ohjelmistosta on kyse, sitä laajempaa asiantuntemusta kilpailukykyisen tuotteen rakentaminen vaatii. Kun koodareiden lisäksi tuotekehitystiimiin voi kutsua joustavasti erityisasiantuntijoita, kuten ratkaisuarkkitehteja, data scientisteja, tietoturva-asiantuntijoita ja palvelumuotoilijoita, voi tiimi yhdessä löytää liiketoiminnallisesti kannattavia ratkaisuja hyvinkin moniulotteisiin ongelmiin ja tulevaisuusskenaarioihin.
Toisaalta tuotekehityksen ulkoistaminen on aina riski, johon liittyy pelkoja kustannusten karkaamisesta, vallan ja vastuun jakamisesta sekä kumppanin toimialaosaamisesta.
Riskit voidaan taklata vain molemminpuolisella luottamuksella, ja se ei muodostu itsestään.
“Luottamus syntyy siitä, että kommunikaatio on toimivaa ja läpinäkyvää. Kumpikin tietää, mitä sprintin aikana on työn alla, rahaa ei pala selittämättömästi ja hankkeen ohjausvalta säilyy tuotteen omistajalla”, Kimmo Alamartimo summaa ja jatkaa:
“Luottamuksen perustaksi tarvitaan tunne siitä, että tuotekehityskumppani kuuntelee tilaajaa. Kumppani ymmärtää sekä osaa jäsentää ja ratkoa tuotteen kehittämiseen liittyviä ongelmia. Silloin voidaan tuottaa näkemyksellisiä ja toimintavarmoja ohjelmistotuotteita, joiden voimin tilaaja menestyy markkinoilla ja liiketoiminta kukoistaa."
Hyödynnä yli 80 organisaation näkemykset tuotekehityksen haasteen paikoista:
