Pasi Kovanen

Pasi Kovanen

Software with Passion

Päätös ohjelmistokehityksen ostamisesta on samalla päätös asiakkaan merkittävästä sitoutumisesta hankkeeseen kehitysvaiheen aikana.

Toki softaa voi hankkia samalla tavalla kuin esimerkiksi talopaketin: käytä päivä toiveiden listaamiseen ja saat valmiin tuotteen puolen vuoden päästä. Tällainen lähestymistapa on myös varmin tapa epäonnistua, kun kyse on softasta.

Toisin kuin talopaketit, joissa valitaan perusratkaisu jota voi ehkä rajoitetusti muokata, tilatut ohjelmistoprojektit on tarkoitettu uniikkien ongelmien ratkaisuun – muutenhan valmisohjelmien käyttäminen olisi järkevämpää. Projektin kuluessa asiakkaan näkemys tarpeistaan tarkentuu ja muuttuu. Alunperin tärkeiksi koettujen asioiden merkitys vähentyy, ja huomataan että mukaan tarvitaan aivan uutta toiminnallisuutta. Ohjelmoijat ovat voineet ymmärtää asiakkaan vaatimuksia väärin, tai alunperin hyvältä tuntunut idea ei olekaan kovin toimiva ratkaisu valmiissa käyttöliittymässä.

Koska ohjelmistoa ei voi kosketella, syntyy helposti harhakäsitys että sen muuttaminenkin on helppoa missä vaiheessa tahansa. Kuitenkin ohjelmistoissa on monimutkainen arkkitehtuuri (katso ”Ryhmärunous”) jota voi verrata rakennuksen arkkitehtuuriin, ja vastaavasti muutosten tekeminen on sitä helpompaa (eli halvempaa) mitä aikaisemmassa vaiheessa tarve havaitaan.

Projektin alkuvaiheessa asiakkaalla on siis tiedossa mitä hän haluaa – se on kuitenkin usein eri asia kuin mitä asiakas oikeasti tarvitsee.

Muista varmistaa ohjelmistotoimittajan kyvykkyys reagoida hankkeen aikana esille tuleviin muutostarpeisiin. Ketterät menetelmät iteratiivisine malleineen ja välitoimituksineen auttavat tässä, ja niiden tarkempaa merkitystä käsittelemme myöhemmin blogissa.

Tykkäsitkö artikkelista?

Anna pienet aplodit!