”Jatkuva release-show ei tunnu kovin upealta” – tietojärjestelmäprojektin julkaisuprosessin kehittäminen

Ketterän kehityksen ytimessä on jatkuva arvonluonti asiakkaalle ja loppukäyttäjille. Samalla on huolehdittava projektin sisäisten prosessien toimivuudesta (ja mielekkyydestä), jotta projektilla on valmiudet tuottaa arvoa versiojulkaisusta toiseen.

Projektien ongelmat eivät esiinny tyhjiössä

Vuosi sitten sain tilaisuuden tehdä pro gradu -tutkielmani projektista, jossa toimin tuoteomistajana. Tutkielmassani ”Julkaisuprosessin kehitys ketterässä ohjelmistoprojektissa – julkaisumallin kehitys ja arviointi” käsittelin ketterän kehityksen ohjelmistoprojektin versiojulkaisumallia ja arvioin julkaisumalliin tehtyjen muutosten vaikutusta projektin havaittuihin ongelmakohtiin.

Kartoittamani ja analysoimani projektin ongelmakohdat kattoivat lähes kaikki projektin avainprosessit. Ne haittasivat projektissa työskentelevien ammattilaisten arkea, sekä heikensivät sidosryhmien ja asiakkaan näkyvyyttä projektin etenemiseen. Analyysin perusteella erityisesti kolme kipukohtaa nousivat ylitse muiden:

1) Projektin huono ennustettavuus

2) Tuotantopäivitysten heikko hallinta

3) Julkaistujen tuotosten laatu

Projektin kipukohtia analysoidessani oli selvää, että haasteet vaikuttivat kaikki toisiinsa. Mikä näkyi asiakkaalle heikkona ennustettavuutena, näkyikin testaajalle hallitsemattomana työkuormana, tai kehittäjälle epäselvinä aikatauluina. Tämä onkin tyypillistä kompleksisille ja laajoille ohjelmistoprojekteille – usein ongelmia esiintyy juuri laadussa ja testauksessa, kehitettävien kokonaisuuksien priorisoinnissa, sekä versiojulkaisuiden teknisessä toteutuksessa ja hallinnoinnissa.

Koska ongelmat olivat laajoja ja koskettivat kaikkia projektin prosesseja ja henkilöitä, ei ongelmiin ollut yksiselitteisiä tai helppoja ratkaisuja. Oli tarkasteltava arvonluonnin prosessia kokonaisuutena.

Hallitusta julkaisuprosessista ennustettavaa arvonluontia

Projektissa otettiin käyttöön uudistettu julkaisumalli. Mallin ytimessä ovat säännölliset julkaisuaikataulut ja kehityssyklit, toisin sanoen ketterän kehityksen periaatteiden mukaisesti sprintit ja jokaista sprinttiä seuraavat releaset. Jokaisen releasen, eli julkaistavan version sisällöt suunniteltiin etukäteen tuoteomistajien, asiakkaan, ja kehitystiimien yhteistyönä. Julkaisupäivämäärät kiinnitettiin puolivuosittain etukäteen, ja laadittiin selkeä kriteeristö normaalin syklin ohittavalle versiojulkaisulle.

Uuden julkaisumallin tarkoituksena oli tehdä arjen projektityöstä hallitumpaa, eli antaa mahdollisuus kehittäjille ja testaajille keskittyä eniten arvoa luovaan työhön. Tämän toivottiin myös tasaavan testaajien työkuormaa. Toisena tavoitteena oli parantaa ennustettavuutta ja projektiviestintää, jotta asiakas ja muut sidosryhmät saisivat kattavan ja paikkaansa pitävän tiedon projektin etenemisestä. Mallin muutosten toivottiin myös selkeyttävän tavoitteiden viestintää projektin sisäisesti.

Mallin käyttöönotossa haasteeksi nousi viestintä mallin prosesseista ja sidosryhmien sitouttaminen mallin periaatteisiin. Käyttöönotto oli muutos projektin toimintoihin ja projektin parissa työskentelevien ammattilaisten työhön, mikä olisi vaatinut hallittua muutosjohtamista. Haasteista huolimatta mallin käyttöönoton myötä tarkastelujaksolla parannuksia havaittiin projektin ennustettavuudessa ja tuotosten laadussa. Vaikutukset tuotantopäivitysten hallintaan jäivät sen sijaan kohtalaisiksi. Julkaisumallin jatkokehitystarpeina tunnistettiin viestinnän ja läpinäkyvyyden kehitys, parempi muutostenhallinta, pidemmän aikajänteen suunnittelu, ja toteutuneiden julkaisusuunnitelmien laadun arviointi.

Muutos osaksi arkea

Tutkielmastani, ja sen kohteena olleen projektin muutosten tarkastelujaksosta on nyt kulunut vuosi. Vuosi sitten käyttöön otettu julkaisumalli on edelleen projektissa käytössä ja suunnitelluista julkaisupäivämääristä on pidetty kiinni. Viestintää on parannettu esimerkiksi säännöllisesti julkaistavalla projektin uutiskirjeellä, viikoittaisella kehitystiimien välisellä kolmen viikon syklin tavoitteiden välitarkastelulla ja kirjaamalla tarkasti ylös syyt mahdollisille tavoitteiden muutoksille.

Tarkastelujakson jälkeen tehdyt muutokset ja parannukset eivät välttämättä ole yksittäisinä suuria tai mullistavia, mutta säännöllinen toimintatapojen kriittinen tarkastelu on luonut projektiin jatkuvan kehittymisen kulttuurin. Kun jatkuva projektin toimintatapojen kehittäminen on osa arkea, pystytään isoakin projektia suuntaamaan askel kerrallaan pois kriisin tieltä ja kohti onnistumista. Pienet onnistumiset ovat tärkeä osa myös asiakaskokemuksen ja keskinäisen luottamussuhteen parantamista – isommatkin muutokset onnistuvat todennäköisemmin, kun projektilla on asiakkaan luottamus ja tuki taustalla.

Tutkielmani ”Julkaisuprosessin kehitys ketterässä ohjelmistoprojektissa: Julkaisumallin kehitys ja arviointi” löydät kokonaisuudessaan täältä

Jonna Paksunen
jonna.paksunen@netum.fi