“Ensinnäkin aikataulu tulee ylhäältä annettuna. Aikataulu ei alun perinkään ole realistinen. Liian kiireellä yritetään. Sitä ei etukäteen yritetäkään ottaa selville, onko se realistista vai ei.”
Vastaus otsikon kysymykseen tulee syvältä sisuskaluista. Markku Pietilä on ollut ohjelmistoalalla vuodesta -87. Kolkyt vuotta. Ura alkoi sovellusneuvojan tehtävistä, minkä jälkeen Markku on ollut ohjelmointi- ja suunnittelutehtävissä mm. finanssialalla ja Verohallinnossa. Viimeiset kymmenen vuotta hän on toiminut integraatioasiantuntijana ja arkkitehtinä.
“Suunnittelen, dokumentoin ja toteutan ratkaisuja, koodauskaan ei ole vierasta.”
Ohjelmistoprojektin määrittely ja testaus – älä tingi näistä
Useimmiten ohjelmistoprojekti siis menee vinoon jo ennen kuin se on kunnolla alkanutkaan. Mahdottoman aikataulun perään tulee epämääräinen kuvaus siitä, mitä siinä ajassa halutaan saada aikaan. Toisin sanoen määrittely jää vajaaksi.
“Jos ei työntekijä tiedä, mitä asiakas haluaa, siinä on huono lähtökohta.”
Määrittely vaatii aikaa, ja se pitää tehdä kunnolla erityisesti niissä hankkeissa, joissa ohjelmistoprojektit tilataan ulkoiselta toimijalta, joka ei tunne asiakkaan liiketoimintaa. Markku kertoo, että näin ei aina ole ollut.
“Muistan ajan, jolloin koodarit ja suunnittelijat saattoivat olla osa liiketoimintayksikköä. Määrittelyjä ei tarvinnut tehdä niin tarkasti, koska koodarit tunsivat liiketoimintaa, liiketoimintaa tekevät osasivat vähän tekniikkaa, ja kaikki keskustelivat keskenään. Nyt tilanne on toinen.”
Määrittelyn lisäksi toinen kriittinen piste on projektin lopussa. Liian usein maailmalle heitetään puolivalmis softa. Säästetään aikaa ja rahaa testausvaiheessa, ja käytetään niitä mieluummin sotkujen korjaamiseen julkaisun jälkeen.
Se nimittäin tiedetään, että kalliiksi käy, kun järjestelmät eivät toimi. Kunnollisella testauksella asiat paljastuvat ajoissa.
Testaus on vielä toistaiseksi työvoimavoittoista ja kallista puuhaa. Siihen kannattaisi kuitenkin panostaa. Se nimittäin tiedetään, että kalliiksi käy, kun järjestelmät eivät toimi. Kunnollisella testauksella asiat paljastuvat ajoissa.
Älä rakastu prosesseihin, muista integrointi
Valitettavan usein järjestelmien integrointia ei oteta huomioon heti alkuvaiheessa, vaan jätetään viime tinkaan. Markulla on muistoja sellaisestakin projektista, jossa uusittiin erikseen useita eri järjestelmiä miettimättä lainkaan, miten ne integroidaan. Sitäkin on nähty, että keskitytään exceleihin ja prosessikaavioihin ja unohdetaan tuote ja tavoite.
“Monesti prosessit ajavat ratkaisun edelle. Kuvitellaan, että jos noudatetaan prosesseja, kaikki on hyvin. Ollaan tyytyväisiä, kun ollaan noudatettu prosessia, mutta ei olla prosessin sisällä ymmärretty, mitä pitäisi tehdä.”
Ohjelmistoprojektissa viisas on se, joka kysyy tyhmiä
Valitus sikseen. Miten maailman voisi pelastaa katastrofaalisilta softaprojekteilta? Budjetti, aikataulu, määrittely – mitä asioita pitäisi tehdä paremmin?
“Pitää ymmärtää tehdä tyhmiä kysymyksiä ja löytää niihin vastaajat.”
Ostajan ei tarvitse ymmärtää tekniikkaa syvällisesti. Sen sijaan päätöksenteossa kannattaisi olla johdon lisäksi mukana joku projektityöntekijä, joka ymmärtää sekä tekniikkaa että jotain myös bisneksestä.
Markku vakuuttaa, että ostajan ei tarvitse ymmärtää tekniikkaa syvällisesti. Sen sijaan päätöksenteossa kannattaisi olla johdon lisäksi mukana joku projektityöntekijä, joka ymmärtää sekä tekniikkaa että jotain myös bisneksestä.
Onhan näitä nähty alalla kuin alalla: projekteja, joiden budjetit tuplaantuvat ja triplaantuvat ja aikataulut paukkuvat. Käyttäjät huutavat ja uutissivustojen palstat soivat. Yhden ainoan ongelman poistaminen voisi ratkaista mennessään kaikki muutkin.
“Suurin este on raha. Jos rahaa ei ole, jotain jätetään aina tekemättä.”