Useissa yrityksissä järjestelmähankinta alkaa määrittelytyöpajoilla, joissa on mukana useiden toimintojen edustajia ja joissa kaikki saavat tuoda esiin omat utopistisetkin toiveensa. Mukana voi olla myös ulkopuolinen konsultti, jonka erikoisosaaminen saattaa asemoitua vahvasti määrittelydokumenttien tuottamiseen.
Määrittelydokumenttien suo?
Työpajojen runsassanaiset ja toiverikkaat keskustelut eivät sellaisenaan voi toimia vaatimuksina järjestelmälle, joten jokin muu formaatti tarvitaan. Usein keskustelut typistyvät taulukkomuotoisiksi, monikymmenrivisiksi vaatimusluetteloiksi, joihin kirjataan kaikki tärkeiksi nousseet vaatimukset. Valitettavasti vaatimusluettelo lyhentää aiemman, paljon sisältöä tarjonneen keskustelun muutamaan, ulkopuolisesta joskus tulkinnanvaraiselta kuulostavaan lauseeseen. Tarjoukset täytyy kuitenkin saada, joten vaatimusluettelo saatelehtineen päätyy järjestelmätoimittajalle.
Ongelmana tässä toimintamallissa on, että sekä järjestelmätoimittajat että yrityksen oma henkilöstö tulkitsevat määrittelyä jokainen omalla tavallaan. Otetaan esimerkiksi vaatimus “Näkymiä voi rajata”. Vaatimuksen kirjoittajalle konteksti on ollut varsin selvä, hän tarkoitti nimenomaan käyttöoikeuksin tapahtuvaa rajaamista, mutta jo yrityksen sisällä tulkinnalle jää liikaa varaa. Yhdelle yrityksen henkilölle on rajaaminen tehtävän tyypin mukaan olennaisen tärkeää, toinen tarkoittikin rajaamista tehtävän tilan mukaan. Toimittaja tekee lauseesta oman tulkintansa. Täyttyykö vaatimus “Näkymiä voi rajata”? Voidaanko toimittajien antamia tarjouksia verrata keskenään ja varmistua siitä, että kaikki ovat tarjonneet samaa asiaa? Mutta ennen kaikkea: Voidaanko saada järjestelmä, joka vastaa haluttuun tarpeeseen?
Vaihtoehto vaatimusluetteloille
Väitän, että tarkkojen vaatimusmäärittelyjen kokoaminen ja dokumentointi ottaa enemmän kuin se voi antaa. Riskinä piilee myös väärien asioiden päätyminen vaatimuslistalle. Tarpeita ja vaatimuksia mietittäessä on tärkeä saada kuvattua se, MITÄ haluamme järjestelmällä tehdä, puhutaan myös käyttötapauksista. Pitkissä määrittelysessioissa fokus joskus katoaa, ja päädytään määrittelemään sitä, MITEN haluamme järjestelmää käyttää. Miten-kysymykseen osaa parhaiten vastata järjestelmätoimittaja, ja kyvykäs sellainen osaa tarjota myös vaihtoehtoja, haastaakin. Mutta vain sinä tiedät vastauksen kysymykseen: Mitä. Älä siis määrittele pikkutarkkojen toiveiden pilvilinnaa, vaan keskity käyttötapausten kautta määrittelemään vain välttämätön.
Artikkelin toisessa osassa kerron, miten määritellään vain välttämätön. Artikkelin toinen osa julkaistaan ensi viikolla, pysy kuulolla!