Ohjelmistokehityksen ulkoistamiseen liittyy mitä mielenkiintoisempia uskomuksia. Itseltäni löytyy aiemmista tehtävistä paljon kokemusta ohjelmistokehityksen hankkijan roolista, joten olen muodostanut monia uskomuksia itsekin. Tänä päivänä toimin ohjelmistokehityksen tarjoajapuolella. Täten olen siinä mielessä onnellisessa asemassa, että olen jo muutaman vuoden ajan voinut ammentaa aiempaa ostajakokemustani asiakasprojektien kommunikoinnin suunnittelussa.
Samalla on ollut kiehtovaa huomata, kuinka aiemmin itseäni ostajana painaneet myytit ovat yksitellen murtuneet. Nyt tarkoitukseni on jakaa näkemykseni ja käsitellä näitä myyttejä julkisesti.
Ensimmäisenä mieleeni tuli seuraava lausahdus, jonka moni on varmasti kuullut eri asiayhteyksissä:
Eihän tätä kukaan ulkopuolinen taho voi tehdä, kun ei ne tiedä mitään meistä / toimialastamme / toiminnastamme.
Tähän törmää edelleen usein, etenkin kun on kyse organisaatiospesifistä tarpeesta, kuten tuotekehityksestä, tai olemassa olevan räätälöidyn järjestelmän jatkokehityksestä. Myönnetään, olen saattanut joskus sanoa tämän myös itse. Mutta mistä tämä uskomus kumpuaa, onko siinä perää, ja onko sille tehtävissä jotain?
Miksi tämä olisi este ohjelmistokehitykselle?
Tässä on kyse paljolti samasta asiasta kuin, jos harkitsee hankkivansa ulkoista siivousapua omaan kotiinsa.
Miten toinen voi täällä siivota, kun eihän se tiedä mitä missäkin on ja mikä mihinkin kuuluu?
Tämä asiahan ratkeaa kertomalla missä mitäkin on ja mihin mikäkin purnukka kuuluu. Lopputuloksena on siisti koti, vaikkei asioita olisi tehty ihan juuri kuten itse tekisit.
Mutta kun on kyse tietojärjestelmästä, ostaja (etenkin liiketoimintahenkilö) ei välttämättä tiedä mihin mikäkin kuuluu tai mitä missäkin on. Ei osata kertoa välttämättä tarkalleen esimerkiksi toiminnallisuuksista, olemassa olevasta ympäristöstä ja mahdollisista yhteystarpeista muihin järjestelmiin. Lisäksi taustalla on epäilys, että kun kerron mitä haluan, niin toimittaja ei ymmärrä tätä ja puhuu takaisin kieltä, jota en ymmärrä. Lopputuloksena on sitten jotain ihan muuta kuin tavoiteltiin.
Väittäisin, että ohjelmistokehityskumppanin substanssiosaamisen ja ymmärryksen kaipuun suurin syy on epäluottamus oman ja ulkopuolisen tahon välisen vuorovaikutuksen ja kommunikaation tasoa kohtaan. Tämä ei ole este ohjelmistokehitykselle, mutta koetaan niin suurena epävarmuutena tavoiteltuun lopputulokseen pääsemisen osalta, että haaste = este. Ja sitähän se on.
Miten haaste taklataan?
Hyvä ohjelmistokehityskumppani taitaa keinot, joilla inhouse-osaaminen ja substanssiosaamisen puutteiden negatiivinen vaikutus minimoidaan. Näissä keinoissa on kyse vuoropuhelun formalisoinnista ja mittaamisesta, eli muutetaan kommunikaatio selkeiden mallien ja työkalujen kautta sellaiseen muotoon, jonka kumpikin osapuoli ymmärtää ja ymmärtäminen on todennettavissa.
Pyrin seuraavilla esimerkeillä tuomaan näkemykseni konkretian tasolle.
Tavoite -> Arvo
Jokaisella ohjelmistokehitystarpeella on aina jokin tavoite ja sitä myöden arvo, minkä vuoksi sitä edes mietitään. Ohjelmistokehityskumppanille tämän ymmärtäminen on homman pihvi, jotta päästään haluttuun lopputulokseen ja oikeilla ratkaisuilla.
Tämän pystyy myös ei-tekninen ihminen kertomaan yleensä melko kivuttomasti. Mutta pelkkä ”se tuo meille säästöjä” tai ”kasvattaa myyntiä” ei riitä ulkoiselle taholle riittävän ymmärryksen syntymiseen. On ymmärrettävä säästöjen tai kasvun syntymislogiikka. Ymmärrykseen päästään ohjaavilla kysymyksillä, kuten miten toimitte nyt, mitä jos tätä ei tehdä jne. Ymmärryksen taso voidaan todentaa yksinkertaisilla mittareilla, kuten ROI-laskentalogiikalla. Jos tähän ei pystytä, asiaa ei joko ole ymmärretty tai sitten ratkaisu ei oikeastaan ole edes tuottamassa mitään arvoa, jolloin sitä ei alunperinkään kannata sellaisenaan viedä eteenpäin.
Vaatimukset – konkreettiset portaat tavoitteeseen
Ehkä haastavin osa-alue yhteisymmärrykselle on yksityiskohtaisemmat vaatimukset. Tarvitaan tietoa käyttäjistä, käyttökohteista, toiminnallisuuksista, reunaehdoista ja etenkin näiden tärkeydestä. Näiden kertominen ei välttämättä ole helppoa asiakkaalle, koska kaikkea ei välttämättä tiedetä, osata ottaa huomioon tai mahdollisuuksia edes tiedetä olevan olemassakaan.
Vaatimusten esille kaivaminen ja saattaminen ymmärrettävään muotoon on kriittinen osa-alue, josta ohjelmistokehityskumppanin on otettava ja kannettava vastuunsa. Näitä käydään yhdessä läpi, mallinnetaan kerrotun pohjalta, kysellään eri tahoilta ja tutustutaan esimerkiksi toimialan standardeihin. Ohjelmistokehityskumppani hyödyntää mallintamisessa esimerkiksi käyttötapauskuvauksia, vuokaavioita ja vaatimusmääritysmalleja.
Pointti näiden mallien käytössä on se, että ohjelmistokehityshankkeen vaatimukset ja arvonmuodostus pystytään esittämään asiakkaalle helposti ymmärrettävässä muodossa. Tällöin asiakkaan on helppo todeta, että juuri tätä me kehitysprojektilta haetaan. Asiakas voi vaihtoehtoisesti myös todeta, että tämä ei vaikuta vielä siltä ratkaisulta, jota tavoittelemme.
Summa summarum
Aina kaikki tosiaan 'ei mene kuin Strömsössä' ohjelmistokehityshankkeiden kanssa. Saamme aika ajoin lukea hämmentäviä uutisia julkisten järjestelmäkehitysprojektien ”tilinpäätösten” yhteydessä. Syyt voivat tietenkin olla moninaisia, kuten vaikkapa sopimukset, lähdekoodin suojaus, tiedon ja rajapintojen rajoitukset, mutta jos kuulen vielä yhdenkin sanovan, ettei asiakas vaan osannut ostaa, niin .... no lukekoon vaikka alkuun tämä blogi.
Tarkoitukseni oli käsitellä aihetta: onko ohjelmistokehityksen ulkoistus mahdotonta ilman ohjelmistokehitystahon inhouse-osaamista? Yhteenvetona näin lopuksi sanoisin, että suurin kipukohta on kommunikaatio, muttei niinkään, etteikö se olisi formalisoinnilla parannettavissa.
Sanoisin tämän myytin osalta, että BUSTED.
Mitä mieltä itse olet? Busted, plausible vai confirmed?
Jaa näkemyksesi asiasta kommentoimalla!
