Olemme jo useamman vuoden ajan saaneet huomata, että asiakkaiden vaatimukset ratkaisujen laajuudesta ja ominaisuuksista ovat kasvaneet hurjasti. Olen saanut olla seuraamassa tätä muutosta konkreettisesti Finn-ID:llä. Voin myös helposti ennustaa, että digitalisaation kasvu ei tule näitä vaatimuksia ainakaan vähentämään tulevaisuudessa. Tämä asettaa meille myös jatkuvan tarpeen kehittää toimintaamme, jotta voimme hallita paremmin haastavia ja monimutkaisia IT -projekteja. Kukapa ei haluaisi olla tekemässä projektia, jossa asiakas ja toimittaja ovat molemmat tyytyväisiä projektin lopussa.
Myyntivaiheen alku onkin erittäin keskeisessä asemassa projektin onnistumisen kannalta. Ennen projektin alkua asiakas pyrkii sopimukseen, jossa kustannus on kiinteä ja aikataulu sekä laajuus on lyöty lukkoon. Kaiken lisäksi laadustakaan ei tulisi tinkiä.
Tämä kuulostaa asiakkaan kannalta hyvältä diililtä, mutta usein totuus ei ole kuitenkaan aivan tämä.
Onko vesiputousmalli toimiva?
Perinteisessä vesiputousmallissa sovellus ja integraatiot pyritään määrittelemään alussa hyvin tarkasti. Tämän jälkeen sovellusta lähdetään toteuttamaan tiukasti määrittelyä noudattaen. Kaikki sujuu yleensä hyvin niin kauan, kun tilanne pysyy jäädytettynä määrittelyn osalta.
Haasteet tulevat esille heti, kun tarvitaan toteutukseen muutoksia tai eteen tulee seikkoja, joihin ei ole osattu varautua määrittelyssä. Jos molemmat osapuolet pitävät tiukasti kiinni sopimuksista, ollaan toistuvasti tilanteessa, jossa neuvotellaan kustannus- ja aikataulumuutoksista. Tämä tilanne ei ole asiakkaalle arvoa tuottava. Lisäksi tiukka sopimuksen tuijottaminen voi aiheuttaa tilanteen, jossa toimittajan on joustettava laadusta, jotta aikataulu ja kustannukset pysyvät hallinnassa.
Tällainen vesiputousmalli on helppo ymmärtää ja ostaa. On se myös ihan toimiva malli, kunhan muistetaan seuraavat asiat:
- Vaatimuksiin ei tule muutoksia.
- Tunnemme kaikki tekniikat.
- Aikataulu ei ole projektille tärkein.
- Toteutuksen aikainen katselmointi ei ole tarpeellista.
Ratkaisuksi ketteryys
Ketterät menetelmät on kehitetty meille avuksi hallita ja onnistua monimutkaisemmissa IT-projekteissa. Jos projektin elementit aikataulu, laajuus ja kustannus eivät ole balanssissa – joutuu toimittaja usein tasapainoilemaan laadun kustannuksella, jotta projekti pysyy kannattavana.
Asiakkaan tulisi pystyä valitsemaan jo alussa kolmesta elementistä (aika, kustannus, laajuus) ne kaikkein tärkeimmät. Kaikkia näitä elementtejä ei voi saada mukaan projektiin, vaikka haluaisikin. Tässä on olennaista ymmärtää, että osa yhdistelmistä on helpompia toteuttaa kuin taas toiset. Esimerkiksi aikataulu ja laajuus on yhdistelmä, jota on hankalampi toteuttaa, koska resurssien lisääminen ei läheskään aina nopeuta kehitystä samassa suhteessa.
Olen kuullut usein väitteen, että ketterän projektin ostaminen on kuin avoin shekki toimittajalle. Pidän tätä väitettä täysin vääränä. Tällöin pitäisikin kysyä; tiedetäänkö oikeasti riittävän hyvin mitä ollaan ostamassa ja toimittamassa.
IT-projektien vaatimukset tarkentuvat usein matkan aikana ja tätä varten tarvitsemme joustoa projektin toteutukseen. Finn-ID:lle on erittäin tärkeää, että ratkaisumme helpottavat konkreettisesti asiakkaittemme arkea ja tuovat käyttäjille iloa jokapäiväiseen tekemiseen. Ketterä kehitys ei siis ole avoin shekki vaan edellytys onnistuneelle projektille, jossa sopimalla asioista voidaan ennustaa myös kustannukset.
