Ketterä siellä, ketterä täällä – piileekö ketterässä ohjelmistokehityksessä riskejä?

Ohjelmistokehityksen hankintaan liittyvissä keskusteluissa ei voi olla törmäämättä termiin ketterä. Ketteryyttä painotetaan niin sekä ostajan että palveluntarjoajan puolelta ja sen hyötyjä jaksetaan hehkuttaa. Kyllä, ketteryys tuo mukanaan esimerkiksi joustavuutta reagoida äkillisiinkin muutostarpeisiin, nopeampaa arvontuottoa sekä riskien minimointia. Mutta piileekö ketterässä ohjelmistokehityksessä riskejä ja miten ne on mahdollista estää? Ajatuksen innoittamana koostimme tähän artikkeliin muutamia seikkoja, joihin ohjelmistohankinnan yhteydessä on hyvä kiinnittää huomiota.

Budjetti ylittyy ja lopputulos ei vieläkään valmis?

Ketterään ohjelmistokehityksen oleellisesti liittyvä asia on tuntihinnoittelu, jolla on vielä tänä päivänäkin hieman negatiivissävytteinen kaiku. Tuntihintaan yhdistettynä sprinttimalli, jossa ohjelmiston osa-alueita työstetään esimerkiksi kahden viikon mittaisissa pätkissä, voi aiheuttaa mielikuvia siitä, ettei hankkeen kokonaiskestoa tai –budjettia tiedetä etukäteen. Pahimmillaan näin voikin olla, mutta asiantuntevan toimittajan valinta tässäkin tapauksessa kannattaa – kun ohjelmistokehitystä suunnitellaan, määritellään hankkeelle tällöinkin kokonaisbudjetti.

Olennaisessa osassa on myös palautekäytäntö sekä tiivis seuranta projektin tuotoksista. Jatkuvalla testaamisella varmistetaan, että lopputulema miellyttää loppukäyttäjien tarpeita parhaalla mahdollisella tavalla.

Ketteryys on sujuvaa yhteistyötä toimittajan ja tilaajan välillä

Kuten esimerkiksi rekrytoinnissa, on myös ohjelmistohankkeissa henkilökemiat ja yhteistyön toimivuus ensiarvoisen tärkeitä asioita koko IT-projektin onnistumiseksi. Toimittajan on paitsi osattava kuunnella asiakasta, tämän toiveita ja tarpeita, mutta myös uskallettava ehdottaa uutta sekä jalostaa tilaajan ehkä jopa karkeitakin ideoita. Usein aivan ohjelmistoprojektin alkumetreillä ei vielä ole selkeää käsitystä, miten ohjelmisto kannattaisi toteuttaa tai ylipäätään sen järkevyydestä – tällöin toimittajalta vaaditaan rohkeutta jopa torpata asiakkaan ajatukset ja tuoda sellainen vaihtoehto tilalle, joka mieluusti ylittää asiakkaan odotukset ja ennen kaikkea vastaa loppukäyttäjien tarpeita.

Koko ohjelmistokehityksen innostus on usein suurimmillaan silloin, kun päätös hankinnasta on tehty ja kättä yhteistyöstä lyöty päälle. Tällöin on valtavasti odotuksia siitä, että projekti lähtee reippaasti ja sujuvasti liikkeelle ja että yhteydenpito toimittajan kanssa toimii. Tällöin olisikin toivottavaa, että esimerkiksi myyntitapaamisissa mukana olleet asiantuntijat ja koodarit olisivat myös itse projektissa mukana, eikä vastassa olisi täysin tuntemattomia kasvoja, joiden kanssa ollaan tekemisissä jopa päivittäin.

Ja vaikka kovasti painotetaankin sitä, että toimittajan on oltava joustava ja ketterä, on myös tilaajalla yhtä lailla vastuu toimia samoin ja olla esimerkiksi tavoitettavissa sekä aktiivisesti mukana projektissa. Lue aiemmasta blogiartikkelistamme, miten osallistumalla itse mukaan hankkeeseen myös ohjelmistokehitys onnistuu.