Vaatimusmäärittelystä monille tulee mieleen paksut dokumenttipumaskat, joita väännetään tuskaisesti ja joita kukaan ei viitsi tai jaksa lukea. Toisaalta turhan moni ketteryyden kannattaja tuumaa, ettei vaatimuksia tarvitse enää määritellä – riittää kun jutskataan ihmisten kanssa. Mikä on siis ”oikein”?
Törmäsimme kollegan kanssa talvella tapaukseen, jossa potentiaalinen asiakas pyysi meiltä konsultointia heidän keskeisen järjestelmänsä uusimiseen. Tarjouspyyntö oli kovin lyhyt: kuvailtiin ylimalkaisesti, mitä nykyinen järjestelmä teki ja kysyttiin, mitä maksaisi uuden hankkiminen ja kuinka kauan se kestäisi. Luimme tekstiä useampaan kertaan silmät pyöreinä: voiko nykypäivänä tulla tällaisia pyyntöjä. Näköjään voi. Otimme yhteyttä tarjouspyynnön lähettäjään ja kyselimme vähän tarkemmin. Todellakin heillä oli käsitys, että kun kertoo muutamalla sanalla tarpeen, niin sen perusteella pystyy toimittamaan uuden järjestelmän tai ainakin kertomaan, mitä sellainen maksaa. Koetimme vähän avittaa ja sanoimme, että voisimme tarjota konsultointia uuden järjestelmän vaatimusten määrittelyyn – edes ihan kevyesti. Homma jäi siihen. En tiedä, löysivätkö sellaisen konsultin, joka täytti heidän toiveensa…
Miksi vaatimuksia pitäisi kuvata?
Kysypä itseltäsi, laitatko silmät kiinni ja valitset lomareissun kohteen umpimähkään? Tai ostatko auton yhtään miettimättä tai selvittämättä faktoja? Tai vaihdatko asuntoa miettimättä, millaista tarvitset tai mitä se maksaa? Tuskinpa!
Tästä huolimatta vielä nykyäänkin tapahtuu niin, että kun lähdetään uusimaan tietojärjestelmää, niin ei sen kummemmin mietitä, mitä oikeasti tarvitaan ja mistä ollaan valmiita maksamaan. Lieneekö ihme, että kustannukset karkaavat käsistä. Valitettavasti tuntuu, että sama tendenssi on levinnyt muihinkin hankkeisiin… Ja kun aikataulu pettää, se yleensä tarkoittaa kasvavia kustannuksia.
Osaako toimittaja lukea ajatuksia? Jaa, se riippuu onko toimittaja ollut tekemisissä kyseisen liiketoiminta-alueen kanssa kuinka pitkään. Ja varsinkin jos ollaan jo valmiiksi tuttuja eli on tehty yhteistyötä pitkään. Silloin toimittaja voi jo arvata tai päätellä puolesta sanasta, mistä on kyse. Vaan entäpäs jos jommalla kummalla puolella onkin uusi ihminen – silloin tämä ei toimikaan. Itse törmäsin tähän kuvioon kymmenkunta vuotta sitten, kun eräissä yrityksissä tapahtui sukupolven vaihdos: tuli paljon uusia nuoria ihmisiä sekä tilaajan että toimittajan puolelle. Nyt ei enää ymmärrettykään toisiaan puolesta sanasta. Oli pakko ruveta kuvaamaan asioita tarkemmin, mikä tarkoitti että myös itse projektit tulivat ryhdikkäämmiksi.
Tarvitaanko dokumentaatiota?
Yksiselitteisesti kyllä.
Ai miksikö? Eikö riitä, että jutellaan asiat selviksi? Oletko huomannut, että jos palaverissa on 5 ihmistä eikä kirjata asioita ylös, niin viikon päästä kukin heistä muistaa asiat omalla tavallaan. Saat siis 5 eri versiota samasta asiasta. Nimittäin jokainen muistaa itselleen tärkeät asiat, ja siten kuin itse ne ymmärsi eli tulkinnan. Ja ne vähemmän tärkeät asiat unohtuvat. Tärkeät päätökset on siis syytä kirjata, jotta meillä säilyy yhteinen käsitys asiasta.
MUTTA ei dokumentointia dokumentoinnin vuoksi! Kuten alussa mainitsin, kukaan ei jaksa lukea paksua mappia tavaraa. Pitää miettiä mitä oikeasti tarvitaan. Riittäisivätkö user storyt tai kanban-lappuset? Vai pitäisikö oikein speksata? Nyt tulee konsultin vastaus: ”se riippuu…”
Tähän ei ole oikeaa vastausta. Dokumentointityyli ja työskentelytavat kannattaa valita projektin kriittisyyden mukaan. Kriittisyyttäkin on monenlaista: Ovatko ihmishenget vaarassa, jos ohjelmistossa on bugi? Tuleeko isoja taloudellisia menetyksiä? Mitä jos myöhästytään joulumarkkinoilta? Kas kun ei paljon lämmitä, jos joulumarkkinoille tarkoitettu kännykkä valmistuu vuodenvaihteessa – markkinarako meni jo.
Monet ketteryyden kannattajat sanovat, että perusperiaatteisiin kuuluu ettei dokumentoida. Ei pidä paikkansa. Agile manifesto sanoo, että toimiva koodi on TÄRKEÄMPÄÄ kuin täydellinen dokumentaatio. Se ei siis korvaa dokumentaatiota. Toisaalta, vaikka olisi kuinka hienot speksit tahansa, mutta ohjelma ei toimi, ei sovelluksella tee mitään. Älkää ymmärtäkö väärin, olen itse täysin ketteryyden ja leanin kannalla – ne ovat paljon tehokkaampia tapoja kunhan ne tehdään oikein.
On myöskin olemassa ns. liiallista dokumentointia. Silloin vaatimukset on kuvattu liian tarkasti, mikä voi johtaa siihen, ettei mahdollinen toimittaja edes uskalla tarjota mitään, kun heillä ei ole juuri sellaista kuin vaatimuksissa on kuvattu.
Mitä sitten pitäisi määritellä?
Lyhyesti:
- Ketä varten sovellusta tai järjestelmää tehdään tai hankitaan? (Sidosryhmät ja käyttäjäryhmät)
- Mitä toimintaprosesseja sen pitäisi tukea?
- Mitä toiminnallisuutta siinä pitäisi olla? Mitä käsittelysääntöjä?
- Mitä tietoja pitäisi käsitellä?
- Mistä ne saadaan tai mihin ne välitetään? Tapahtuuko osa toiminnallisuudesta muualla? (Integraatiot)
- Kuinka hyvin järjestelmän pitäisi toimia ja minkälaisissa olosuhteissa? (Ei-toiminnalliset vaatimukset)
- Onko jotain reunaehtoja?
Ja jos yrityksessä tai organisaatiossa on tehty kokonaisarkkitehtuuria, osa määriteltävistä asioista saadaan sieltä – ei siis tarvitse lähteä tyhjästä liikkeelle. Vaatimusmäärittely tehostuu siis entisestään.
Erilaisiin tilanteisiin sopivista tekniikoista ja kuvaustavoista kuulet lisää Coalan kurssilla Tehokas vaatimusmäärittely, jonka löydät Oppia.fi:stä.
Tervetuloa Coalan maksuttomiin webinaareihin, ilmoittaudu jo nyt mukaan Oppia.fi webinaarikalenterin kautta!
Tarja Raussi
Kirjoittaja on kokonaisarkkitehti ja konsultti Coalasta. Yli 25 vuoden aikana Tarja on tehnyt monenlaista, mutta jo varsin aikaisin hän huomasi, että kokonaisuuksien hallinta ja kuvaaminen ovat hänen ominta aluettaan. Niinpä pitkän määrittely- ja mallintamiskokemuksen jälkeen oli luontevaa siirtyä kokonaisarkkitehtuurin ja laadunhallinnan pariin. Tarjasta on hienoa, kun saa kanssatekijät tai valmennettavat oivaltamaan asioita.