Vaatimukset selviksi

Opiskellessani IT-alaa reilut kaksikymmentä vuotta sitten ohjelmistoprojektien toteuttamiseen opetettiin käytännössä vain yksi tapa, vesiputousmalli. Tämän jälkeen on tullut monia uusia tapoja, scrum ja kanban muutamia mainitakseni. Jokainen tapa / prosessi kuulostaa paperilla täydelliseltä ja tähtää tietysti ohjelmistoprojektin onnistumiseen ja asiakkaan tarpeen täyttämiseen.

Urani aikan olen huomannut, ettei yksi mikään prosessi ole toista parempi. Prosessit ovat yleensä tehty täydellisille ihmisille, enkä ole toistaiseksi tavannut täydellistä ihmistä. Paljon riippuu projektin toteutuksesta. Projektilla on paremmat mahdollisuudet onnistua, jos projektin tavoite on selvä. Selvällä tarkoitan jotain muuta kuin “toteutamme uuden sukupolven sovelluksen X …”.  

Riippumatta projektimallista projektin tavoite kuvataan yleensä vaatimusten kautta. Joissakin malleissa vaatimukset yritetään kuvata täydellisesti ennen toteutus ja testaus vaiheita. Joissakin toisissa malleissa vaatimukset kuvataan yleisellä tasolla ja tarkennetaan projektin edetessä. Aika monessa projektissa tämä tehdään ohjelmistokehittäjien toimesta. Tässä ei sinänsä ole mitään vikaa, mutta ohjelmistokehittäjät eivät ole ongelma-alueen asiantuntijoita ja heiltä usein puuttuu kokemus, minkä alan parissa työskentelevät ovat saavuttaneet vuosien aikana.

Edellä mainitusta voisi helposti vetää aasinsillan, että toimialueen asiantuntijoiden pitää olla projektissa ja sitten homma toimii. Oikein ja väärin. Mukana oleminen ei ole itseisarvo vaan vielä tärkeämpää on saada heillä oleva tieto ohjelmistokehittäjien tietoon ja ymmärrykseen. Se, miten tämä vaihe toteutetaan sanelee aika pitkälle sen, onko projektilla onnistumisen mahdollisuuksia vai ei. Tämän lisäksi toinen tärkeä onnistumisen edellytys on, että toimialueen asiantuntijat ovat käytettävissä projektin aikana. Em. kaksi asiaa ovat oman kokemukseni mukaan tärkeämpiä kuin se, kuinka kokeneita tietoteknisiä asiantuntijoita projektissa on. Asiantuntijuutta tarvitaan, mutta vielä enemmän tarvitaan asiakkaan ymmärtämistä.

Kiitos, kun luit tekstin tänne saakka. Ensi kerralla kerron, miten vaatimusmäärittelyä voi lähestyä.