Oletko joskus kuullut verkkopalvelusta, saitista, portaalista, kauppapaikasta, hilavitkuttimesta, joka olisi määritelty projektin alkuvaiheessa liian tarkasti? Oletko kuullut projektista, jossa asiakas ja toimittaja olisivat alusta lähtien nähneet tulevan verkkopalvelun sielujensa silmillä viimeistä pilkkua myöten samanlaisena?
Liian usein liian moni asia jää epäselväksi. Projektin osapuolilla ja tiimin jäsenillä on keskenään poikkeava käsitys siitä mitä ollaan tekemässä. Yksi rakentaa pitsihuvilaa ja toinen asuntoautoa.
Hyvä esimerkki tästä voisi olla ylläpitotyökalu. Toimittaja tekee lomakepohjaisen kilkkeen, jossa lopulliset muotoilut tehdään html:llä. Asiakas tai ainakin asiakkaan loppukäyttäjä odottaa saavansa Wordin ominaisuuksilla varustetun wysiwyg-toimitusjärjestelmän.
Onneksi on olemassa tapa, jolla viestiä siten, että nämä näkemykset lähentyisivät toisiaan. Kunhan sitä vaan käytettäisiin useammin ja perusteellisemmin. Ai mikä? No se vaatimusmäärittely!
Vaatimusmäärittely on, ainakin näin projekti-ihmisen näkökulmasta, verkkopalvelun toteuttamisen kivijalka. Ilman perusteellista määrittelyä on erittäin vaikeaa tuottaa haluttua lopputulosta, tai lopputulosta ylipäätään, ainakaan aikataulussa ja budjetissa.
Määrittelyn tavoitteena on kuvata yksiselitteisesti, ymmärrettävästi ja hyvin rajatusti tuotettavan verkkopalvelun sisällöt, toiminnallisuus ja teknisen toteutuksen reunaehdot. Vaatimusmäärittelyhän on saanut nimensä siitä, että siinä kuvataan järjestelmä sen tulevien käyttäjien tarpeiden/vaatimusten näkökulmasta. Yleinen menetelmä tämän kuvaamiseen ovat käyttäjien näkökulmasta lähtevät käyttötapauskuvaukset.
Vaatimusmäärittely kuvaa tilaajan ja toimittajan välisen yhteisen ymmärryksen siitä, millaista verkkopalvelua ollaan tekemässä. Siksi onkin olennaista, että molemmat osapuolet ovat myös ymmärtäneet dokumentin sisällön samalla tavalla ja riittävällä tarkkuudella ja hyväksyneet sen ennen toteutusvaiheen aloittamista. Ilman riittävää määrittelyä toteusvaihetta ei juuri kannattaisi aloittaa.
Mistä kaikesta pahasta huolella tehty vaatimusmäärittely meidät sitten pelastaa? Luovan prosessin edetessä esiin putkahtelevat uudet vaatimukset ja ominaisuudet kirjataan herkemmin osastoon “jatkokehitysideoita“. Tai ainakin ne höylätään sovitun muutoksenhallintaprotokollan läpi. Tällä saattaa olla ratkaiseva vaikutus projektin aikatauluun ja budjettiin. Erityisen kiitollinen hyvin tehdystä määrittelystä saa olla projektin loppuvaiheessa. Hyväksymistestaus ja projektin päättäminen sujuvat huomattavasti paremmassa yhteisymmärryksessä, kun on olemassa selkeä, riittävän yksityiskohtainen kuvaus tavoitteena olleista lopputuloksista.
Ja mikä kaikkein tärkeintä, saattaa käydä jopa niin, että sekä toimittaja että asiakas ovat edelleen sitä mieltä, että palvelusta tuli sellainen kuin pitikin. Ja voi sattua niinkin, että kaikki projektin osapuolet ovat tyytyväisellä mielellä onnistuneen projektin saavutusten edessä. Utopiaako? Ei, vaan määrittelyä. Tämän allekirjoittanevat kaikki, jotka ovat olleet mukana hyvin määritellyssä projektissa.