Ohjelmistokehityskumppanin valinta on kaikkea muuta kuin yhdentekevä asia. Monesti ohjelmistoyritysten erot kuitenkin aukeavat asiakkaalle vasta yhteistyön myötä ja pidemmässä juoksussa.

Millä siis erottaa huipputason ohjelmistokehityskumppani keskiverrosta?

Keskustelimme aiheesta ohjelmistopalveluyritys Cinian Kimmo Alamartimon kanssa. Cinialla on tehty paljon itsetutkiskelua siitä, minkälainen partneri he haluavat olla asiakkailleen. Nostimme siis kissan pöydälle ja kysyimme, minkälainen on huipputason ohjelmistokehityskumppani.

– Huipputason ohjelmistopalvelu rakentuu loppujen lopuksi yksinkertaisista asioista. Meillä mitataan säännöllisesti asiakastyytyväisyyttä ja tulosten taustalta olemme sitten pyrkineet kaivamaan esiin asioita, joita ohjelmistopalveluiden ostajat eniten arvostavat.

Alamartimo nimeää neljä teemaa, jotka heidän kokemuksensa mukaan koskettavat yrityksiä ohjelmistokumppanuuksissa.

 

1. Teknologiahype vs. perusasioiden kuntoon laittaminen

– It-toimittajien kentässä on käynnissä jatkuva keskustelu siitä, mikä on juuri nyt “se kuumin juttu”. Alalle on leimaavaa palveluntarjoajien kilpalaulanta kulloinkin muodissa olevasta trendistä, oli kyse sitten ohjelmistorobotiikasta, analytiikasta tai tekoälystä .

Alamartimosta on kuitenkin falskia paasata ympäripyöreyksiä digitalisaatiosta ja sanoa sen 70:n kerran jotain, mikä on useasti jo todettu.

– “Machine learning tulee! No tuleehan se!”, hän heittää nauraen.

“Machine learning tulee! No tuleehan se!”

– Yritykset etenevät digitalisaatiossa ja uusien teknologioiden hyödyntämisessä kukin omaa tahtiaan ja erilaisista lähtökohdista. Meillä on asiakkaita, joilla on ohjelmistokehityksessä vuosien saatossa vakiintuneet perinteet ja jotka soveltavat jo tekoälyratkaisuja ja robotiikkaa. Toisaalta osa asiakkaista on vasta ottamassa ensiaskeleitaan digitalisaatiossa.

Alamartimon mukaan IT- ja ohjelmistokumppanin on syytä ensimmäiseksi pohtia sitä, voidaanko arjen ja liiketoiminnan ongelmia ratkoa ihan vaan laittamalla perusasioita kuntoon.

– Tarkoituksenmukainen ja harkittu eteneminen on käytännössä arvokkaampaa, kuin hypen harjalla kulkeminen ilman minkäänlaista kytkentää liiketoimintaan. Ei se sitä tarkoita, etteikö teknologiakokeilujakin voisi tehdä – tietysti pitää – mutta osaavan palveluntarjojajan tehtävänä on sparrata ja kyseenalaistaa investointipäätöksissä.

 

2. Elinkaariajattelu

Kun asiakas tilaa projektin, ohjelmiston oletettu elinkaari voi olla useita vuosia. Se on ohjelmistoteknisesti valtavan pitkä aika, sillä kehitystyö on niin kiivastahtista.

– Silloin täytyy suunnitella arkkitehtuuri ja tehdä teknologiavalinnat tavalla, joka ei kavenna mahdollisuuksia ohjelmiston jatkokehityksessä. Asiakas, joka satsaa paljon kehitykseen, ei halua päätyä umpikujaan. Hötkyilemällä tuhlaa helposti kehityspanoksia ja hukkaa rahaa, Alamartimo pohtii.  

Tänä päivänä suositaankin mikropalveluarkkitehtuureja, jotka mahdollistavat ohjelmiston osien toisistaan riippumattoman kehityksen ja päivittämisen. Lisäksi dataan pohjautuva liiketoiminta vaatii usein ”API-first” -tyyppistä lähestymistä kehitykseen, sillä eri toimijoiden järjestelmät muodostavat yhdessä toiminnallisia kokonaisuuksia ja ekosysteemejä.

“Hötkyilemällä tuhlaa helposti kehityspanoksia ja hukkaa rahaa”

– Teollisen internetin sovelluksissa ohjelmistoilla ja fyysisillä laitteilla on aivan erilainen elinkaari. Esimerkiksi juna- ja raidekaluston on board -järjestelmien elinkaari voi olla jopa 20-30 vuotta. Emme tiedä mitä kaikkea järjestelmiin tulee pystyä elinkaaren eri vaiheissa kytkemään tai millaisia käyttäjien päätelaitteet tulevat olemaan. Mutta meidän pitää varautua siihen, että kykenemme päivittämään ja muuttamaan ohjelmistoja aina kun tarpeita tulee, hän listaa.

 

Kimmo Alamartimon mukaan hyvä ohjelmistokumppani miettii ensiksi, voidaanko liiketoiminnan ongelmia ratkoa ihan vaan laittamalla perusasiat kuntoon.

 

Vaatimus muokattavuudelle ulottuu PaaS-palveluiden (Platform As a Service) aikana konesaliratkaisuihin saakka.

– Jos ajatellaan vaikkapa jotain reguloitua teollisuudenalaa, joka kohtaa vaihtuvia vaatimuksia lainsäätäjien taholta, niin heidän täytyy kyetä tarpeen vaatiessa siirtämään sovelluksia Azuresta AWS:ään tai omaan virtuaaliympäristöön, sekä mahdollisesti ajamaan sovelluksesta eri instansseja eri markkina-alueilla. Elastisuus näissä asioissa pidentää järjestelmän elinkaarta ja mahdollistaa kriittisyyden uusia teknologioita kohtaan, Alamartimo sanoo.

Siitä saammekin hyvä aasinsillan seuraavaan otsikkoon:

 

3. Asiakkaan edun ajaminen teknologiavalinnoissa ja Open Sourcen hyödyntäminen

– Asiakkaan kannalta on tärkeää pysyä kehityshankkeissa turvallisilla vesillä. Beta-vaiheen teknologioilla voidaan kyllä testata, jos asiakas hyväksyy riskit, Kimmo Alamartimo jäsentelee.

Yksi osa jatkuvuutta ja elinkaariajattelua on se, että ohjelmistoyritys on kumppani pitkäjänteisesti.

– Tällöin joustavuus on tärkeää ja henkilöitä täytyy kyetä vaihtamaan tarvittaessa projektista toiseen. Kun ohjelmistokumppani noudattaa sisäisesti yhteisiä käytänteitä, hyödyntää yleisesti käytettyjä teknologioita ja vakioituja työtapoja, se helpottaa uusien henkilöiden tuomista sisään projektiin.

“Lähtökohtaisesti IPR:ää tuotetaan asiakkaalle”

– Avoimen lähdekoodin käyttö on myös asiakkaan edun ajamista. Periaatteemme on, että lähtökohtaisesti tuotamme IPR:ää asiakkaalle ja mahdollistamme heidän ohjelmistopohjaista liiketoimintaa. Asiakkaan täytyy kyetä halutessaan vaihtamaan kumppanista toiseen tai siirtämään kehitystyö omille työntekijöilleen. Tarvetta kumppanin vaihtamiseen harvoin kuitenkaan tulee, jos vain ohjelmistokumppani huolehtii asiakkaan edusta ja työn jälki on priimaa.

 

4. Tehokas lisäarvon tuottaminen ja korkea laatu

Kimmo Alamartimon mukaan ohjelmistotalon ehkä keskeisin kompetenssi on se, että se kykenee nopeasti ymmärtämään, mitä asiakkaat omassa työssään ja liiketoiminnassaan tarvitsevat.

– Vaikka kaiken taustalla onkin geneerinen ohjelmistotekninen osaaminen, meiltä it-yrityksiltä odotetaan jatkuvasti enemmän toimiala- ja asiakaskohtaista osaamista.

Samaan aikaan ratkaisujen laatuvaatimukset nousevat. Cinia toteuttaa ratkaisuja esimerkiksi terveydenhuollon, liikenteen ja teollisuuden toimijoille, joille sovellusten korkea toimintavarmuus on kaikki kaikessa.

– Siksi laadunvarmistuksen täytyy olla läsnä korkealaatuisessa ohjelmistokehityksessä. Tiimissä täytyy olla aina se ihminen, joka pyrkii rikkomaan sitä, mitä muut ovat tehneet. Tietysti devaajatkin testaavat ja parikatselmoivat tuotoksiaan, mutta kun laadunvarmistusihminen työskentelee tutkivalla mentaliteetillä, saadaan kiinni ongelmia, jotka muutoin ilmenisivät vasta myöhemmin.

“Tiimissä täytyy olla aina se ihminen, joka pyrkii rikkomaan sitä, mitä muut ovat tehneet”

– Ja sanon sen suoraan, että  testaaminen ja laatu maksavat. Kokeilut ja proof of concept -tyyppiset projektit ovat tietysti tietoinen valinta ja asia erikseen. Laitetaan toteutus pystyyn virtuaalimasiinalle ja katsotaan lähtisikö se lentoon. Mutta kun halutaan pitkää elinkaarta, ehdoton edellytys on, että tukeudutaan riittävän jämeriin laadunvarmistuksen rakenteisiin sekä automatisoituun testaukseen ja julkaisuun. Näitä elementtejä voidaan toki tuoda kehitystyöhön vaiheistetusti jälkikäteenkin, mutta tehtiinpä kummalla tavalla tahansa, sen tulisi olla seurausta liiketoimintalähtöisestä harkinnasta.

Alamartimo määrittää, että laatua on myös se, millaisella otteella ihmiset töitä tekevät.

– Jos pitäisi yhteen sanaan tiivistää yhteistyön tärkein asia, niin se on keskinäinen luottamus sekä toimittajan että tilaajan henkilöiden välillä. Se ansaitaan näkemyksellisyydellä, suoraselkäisellä kommunikaatiolla sekä pitämällä kiinni siitä, mitä luvataan.

 

Cinia ite wikissä
Cinian kotisivut