Vältä tietojärjestelmien kehittämisen 6 sudenkuoppaa

Miten syntyy onnistunut digitaalinen palvelu käytännössä? Olemme pohtineet sudenkuoppia, joiden yli julkisten organisaatioiden on pystyttävä ponnistamaan, jotta ne voivat täysin hyödyntää digitalisaation ja teknologisen kehityksen tarjoamat mahdollisuudet palvelutuotannossaan. Arto kirjoitti aikaisemmin organisaatiolähtöisyyden ja toimintakeskeisyyden karistamisesta. Myös käytännön toimintatapojen on uudistuttava, jotta ne eivät rajoita organisaatioiden uudistumiskykyä ja aseta esteitä oivaltaville palveluinnovaatioille.

Pohdin tässä kuutta keskeistä seikkaa, joiden avulla palvelukehitykseen saadaan tuotua digitalisaation edistymiselle välttämättömiä ketteryyttä ja kokeiluja sekä joustavaa, vuorovaikutteista yhteistyötä.

Keskity suunnittelun sijasta tekemiseen

Ketterät menetelmät ovat olleet järjestelmä- ja ohjelmistokehittämisen arkipäivää jo kymmenen vuotta. Vesiputousmallisten projektien perintö on kuitenkin julkisella sektorilla vahva, ja yhä edelleen ajatus hyvin suunnitellusta puoliksi tehtynä saa monissa kehitysprojekteissa aikaa ja resursseja kulumaan ilman, että tulosta syntyy. Määrittelydokumentteja kirjoitetaan pidempään kuin koodia, ja kehitystyötä lähdetään lopulta tekemään melko tarkkaan ennalta lukkoon lyötyjen vaatimusten pohjalta.

Nykymaailmassa alkuperäiset suunnitelmat joutuvat todennäköisesti romukoppaan kehitystyön edetessä. Uudet digitaaliset palvelut syntyvät kokeilemalla ja jatkuvasti parantamalla. Muutoksiin mukautuminen ja niiden ennakoiminen on mahdollista vain ketterässä ympäristössä. Nopean ja jatkuvan kehittämisen vaatimukseen vastaamiseksi ketterästä kehittämisestä on jo otettu askel pidemmälle DevOps-kulttuuriin, joka tuo vauhtia ja ketteryyttä myös ohjelmistojen testaukseen, tuotantoonvientiin ja ylläpitoon.

Kuuntele jatkuvaa palautetta

Yleinen ongelma on, että digitaalisesta palvelusta yritetään tehdä kerralla valmista – ajatellaan, että on tilattu järjestelmä ja kunhan se on toimitettu, kehityshanke on valmis. Digitalisaatio etenee jatkuvasti ja muuttaa loppukäyttäjien tarpeita ja odotuksia palvelulle samalla kun myös toimintatavat muuttuvat. Organisaatioiden pitäisi jo hankintavaiheessa ymmärtää tilaavansa vain ensimmäisen vaiheen toteutusta, jota kehitetään jatkuvasti eteenpäin.

Ohjelmistokehittäjät ja järjestelmien ylläpitäjät yhteen tuoneen DevOps-toimintatavan valtti on se, että uusia toiminnallisuuksia voidaan viedä tuotantoon jatkuvasti, ei hitaissa päivityssykleissä. Tämä edellyttää myös, että toiminnan on oltava aidosti palauteohjautuvaa: palautesilmukoita on oltava monella tasolla operatiivisen, teknisen toiminnan ja käyttäytymisen mittaamisesta palvelun ominaisuuksiin liittyvään palautteeseen ja kokemuksiin palvelun käytöstä, ja näistä silmukoista saatavaa palautetta on myös sitouduttava kuuntelemaan.

Kiipeä kellarista pilveen

Julkinen sektori on selvästi takamatkalla modernien pilvipalvelujen hyödyntämisessä. Kallis ja kankea konesali-infrastruktuuri hidastaa järjestelmien ja palvelujen kehitysvaihetta ja tekee esimerkiksi nopeat kokeilukonseptit sekä ketterän prototyyppien tekemisen vaikeaksi. Pitämällä kiinni perinteisistä konesaleista organisaatiot ovat estäneet aidon lean startup -hengen syntymistä julkisten palvelujen kehittämiseen.

Kustannustehokkaiden ja skaalautuvien pilvipalvelujen avulla resurssit voitaisiin käyttää palvelimien ja verkkoyhteyksien sijasta varsinaiseen palvelukehitykseen ja uuden innovointiin. Tällaisessa ympäristössä ideoita voi testata ilman suuria riskejä – jolloin on myös helpompi luopua ideoista, jotka eivät toimikaan käytännössä. Tämän vuoden alussa valtion tieto- ja viestintätekniikkakeskus Valtori tuo palveluvalikoimaansa julkiset pilvipalvelut, mikä toivottavasti antaa vauhtia organisaatioiden siirtymiselle nykyaikaiseen pilviympäristöön.

Pilko järkälemäiset järjestelmät

Jatkuvan parantamisen kierteen syntymistä julkisiin digitaalisiin palveluihin estävät edelleen monoliittiset järjestelmät. Järkälemäiset, suuret järjestelmät ja sovellukset sitovat organisaatiot valittuihin teknologioihin ja hankaloittavat jatkokehittämistä, elleivät sitten tee siitä täysin mahdotonta. Julkisen sektorin monoliittisten järjestelmien joustamattomuuteen on kiinnitetty huomiota jo vuosia, mutta yhä vain niitä hankitaan.

Jatkuvasti muuttuvassa toimintaympäristössä järjestelmien ja sovellusten on pystyttävä liittymään ja kasvamaan osaksi digitaalisten palvelujen ekosysteemiä. Mikropalveluarkkitehtuuri auttaa säilyttämään reagointikyvyn ja jatkuvan kokeilemisen ja kehittämisen myös tulevaisuudessa. Mikropalveluina toteutettu järjestelmä koostuu erillisistä, keskenään kommunikoivista pienistä palveluista, joista jokainen on suunniteltu ratkaisemaan vain tietty toiminto. Mikropalvelut voidaan toteuttaa vastuullisissa, itseohjautuvissa kehittäjätiimeissä kuhunkin tarkoituksen parhaiten soveltuvalla teknologialla ja sopivimmilla menetelmillä.

Ota tuoteomistajuus haltuun

Onnistuneiden digitaalisten palvelujen taustalla on paitsi moniosaava järjestelmätoimittaja, myös sitoutunut asiakas. Aitoa tuoteomistajuutta ei voi ulkoistaa. Organisaatiosta on löydyttävä tuote- tai palveluomistaja, jolla on aikaa ja innostusta sitoutua kehitysprojektiin. Usein pöydän ääreen istuutuu organisaatiosta pakon edessä projektipäälliköksi päätynyt henkilö, jolla ei ole tarvittavaa omistautumista – eikä välttämättä edes valtaa tehdä päätöksiä.

Hyvä tuoteomistaja osallistuu palvelun kehittämiseen koko projektin ajan ja haluaa intohimoisesti rakentaa yhteistyössä parhaat mahdolliset ratkaisut. Tärkeä onnistumisen edellytys on vuorovaikutteinen yhdessä tekemisen kulttuuri, jossa kokeilut saavat myös epäonnistua, kunhan niistä opitaan. Jotta yhteistyö sujuu saumattomasti, kehitystiimissä on oltava vahva yhteisymmärrys ja keskinäinen luottamus. Moni oikaisee kumppanivalinnassa ja järjestää CV-kisat, joissa osaamisen sijasta ratkaisee mennyt kokemus. Valintaa tehtäessä olisi syytä nähdä vaivaa ja järjestää esimerkiksi haastatteluja ja ryhmätehtäviä. Siten voi saada etukäteen selville, miten aikaansaava kehitystiimi todella on ja miten yhteistyö käytännössä sujuu.

Vapaudu kankeista ja pitkistä sopimuksista

Yleinen kilpailutus- ja sopimusvaiheen virhe on se, että organisaatio lukittautuu yhteen toimittajaan pitkäksi aikaa eikä jätä itselleen mahdollisuutta irrottautua sopimuksesta, jos kemiat eivät kohtaakaan. Hyvä keinoa on suosia monitoimittajatiimejä, jolloin useampi kuin yksi toimittaja pääsee kiinni järjestelmän kehittämiseen ja tervehenkinen kilpailu haastaa myös toimittajia etsimään parhaita mahdollisia ratkaisuja.

Toinen kilpailutuksiin liittyvä haaste on, että organisaatiot asettavat hinnan laadun edelle. Puitesopimuksissa hinnat ovat jo valmiiksi kilpailukykyiset ja erittäin alhaisella tasolla. Painopistettä voisi siksi turvallisin mielin siirtää entistä enemmän laatuun ja osaamiseen, jotta valituksi tulisivat oikeasti parhaat, näkemykselliset tekijät, jotka hallitsevat uusimmat menetelmät ja teknologiat ja joiden kanssa yhteistyö sujuu niin, että kehittämisen muut sudenkuopat vältetään.

Tässä blogisarjassa pohdimme organisaatiolähtöisyyden, kulttuurin ja johtamisen sekä toimintatapojen sudenkuoppia, joiden yli julkisten organisaatioiden on ponnistettava voidakseen hyödyntää digitalisaation ja teknologisen kehityksen tarjoamat mahdollisuudet toimintansa kehittämiseen – siis aidosti vaikuttavaan digiloikkaan.

Blogisarjan seuraavassa osassa Mikael pohtii, miten ketteryys ja kokeilut tuodaan osaksi johtamista ja organisaatiokulttuuria.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Liity joukkoon

Backend-kehittäjä

Helsinki, Jyväskylä, Tampere

Frontend-kehittäjä

Helsinki, Jyväskylä, Tampere