Edellisessä hyvää kilpailutusta käsittelevässä jutussa käsiteltiin järkevää laatupisteytystä, mutta siinäkin perushaasteena nostettiin esiin se, että ilman jonkinlaista järkevää kuvausta siitä mitä ollaan tekemässä, ei voi oikein tehdä hyvää kilpailutusta. Siksi hyvän kilpailutuksen isoimpana, yksittäisenä edellytyksenä on hyvä vaatimusmäärittely. Hyvä vaatimusmäärittely on hyvän kilpailutuksen peruskivi, johon varsinainen tarjouspyyntö ja useimmat pisteytykseen liittyvät kysymykset nojaavat.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
10.8.2017
Ja kyllä, hyvä vaatimusmäärittely vaatii aika paljon työtä ja ennenkaikkea päätöksiä siitä mitä ollaan tekemässä, ja jonkin verran päätöksiä myös siitä kuinka se tullaan tekemään. Hyvä vaatimusmäärittely ei mene kuitenkaan liikaa yksityiskohtiin, jättäen tilaa toteuttajalle tehdä asioita parhaalla mahdollisella tavalla.
Käytännössä vähänkin isommasta projektista tehtävä hyvä vaatimusmäärittely on silti useita kymmeniä sivuja tiukkaa tekstiä – eli aika paljon sitä aikaa ja vaivaa tarvitaan. Ihanteellisesti hyvää dokumenttia myös tuetaan jo suuntaa-antavilla malleilla, jopa havainnekuvilla. Dokumentin tehtävähän on antaa tarjoajille mahdollisimman yksiselitteinen kuva siitä palvelusta ja kokonaisuudesta, jota ollaan ostamassa.
Aina ei tietysti vaatimusmäärittelyä tarvita, mutta silloin ei ole kyse projektin ostamisesta, vaan tällöin yleensä ostetaan vain resursseja. North Patrolinkin asiakkaissa on paljon sellaisia tahoja, joilla on jonkun tärkeän palvelun ympärille perustettu varsin pysyvä oma kehitystiimi, ja ajoittain sen tiimin koodareita kilpailutetaan. Tämä on se tyypillisin poikkeus perussääntöön, ja tällaisissa tilanteissa emme mekään North Patrolissa näe järkevänä vaatimusmäärittelyn tekemistä. Oman tiimin perustaminen palvelun kehitykseen vaatii kuitenkin varsin paljon johtamiskykyä asiakkaan omalta organisaatiolta, ja myös varsin runsaasti rahallisia resursseja palvelun pitkäjänteiseen kehitykseen, joten kovin yleiseksi malliksi oma kehitystiimi ei tule koskaan muodostumaan.
Vaatimusmäärittely, tuotejono, tuotevisio, konseptisuunnitelma…
Vaatimusmäärittelyllä voi olla monia muotoja, jopa erilaisia nimiä. Esimerkiksi ketterässä kehityksessä puhutaan paljon tuotevisiosta ja tuotejonosta (”product backlog”). Periaatteessa nämä kaksi dokumenttia voivat yhdessä muodostaa hyvin samantyyppisen kokonaisuuden kuin mitä hyvä vaatimusmäärittely käsittelee. Käytännössä tuotejono ja tuotevisio ovat kuitenkin yleensä enemmän toteutusvaiheen tarkoituksiin tehtyjä dokumentteja, joiden avulla voi olla hankalaa kilpailuttaa, koska dokumentit on tarkoitettu toteutuksen tueksi, ei tarjouskilpailun läpivientiin.
Yleisin haaste on se, että tuotejonon ja tuotevision lukemisella ei saa kovin hyvää kuvaa siitä kokonaisuudesta mitä ollaan ostamassa (hyvä tuotevisio ja tuotejonohan on yleensä enemmän sisäinen kirkastus siitä mihin ollaan menossa, ei varsinainen palvelun kuvaus). Yleensä tuotevisio ja tuotejonohan ovat lähinnä työkaluja, jotka luodaan vasta toteutusvaiheen alussa, ja tällöin ne usein luodaan vahvasti perustuen vaatimusmäärittelydokumenttiin. Usein tuotejonon kohdat viittaavatkin tarvittaessa kilpailutusvaiheessa luotuun vaatimusmäärittelydokumenttiin.
Jotkut suunnittelutoimistot ja digitoimistot myös vierastavat termiä vaatimusmäärittely, ja mieluiten tuottavat esimerkiksi konseptisuunnitelmia. Parhaat näistä voivat ollakin hyvin samantyyppisiä kuin vaatimusmäärittely-otsikolla tuotetut dokumentit, mutta yleensä konseptisuunnitelmiksi nimetyt dokumentit ovat melko ”ulkomuotovetoisia”, eli pahimmillaan vain sekalaisia kokoelmia alustavia leiskoja.
Kevyet html-prototyypit ovat myös yleistyneet viime vuosina, ja näistä onkin usein paljon hyötyä palveluiden alkuvaiheen suunnittelussa, mutta kilpailutuksen kannalta nekin ovat ongelmallisia, koska eivät ole yksinään kovin hyviä selittämään tarjoajille miten asioiden pitäisi toimia, ja mitä kaikkea ”pinnan alla” pitäisi tapahtua. Käytännössä hyvänkin html-proton tueksi pitää kirjoittaa laadukas vaatimusmäärittely. Tällöin dokumentti voi toki viitata html-protoon runsaasti, ja näin kirjallisen dokumentin ei tarvitse olla valtavan laaja.
Kilpailevista lähestymisistä huolimatta, pidämme North Patrolissa edelleen vaatimusmäärittely-otsikkoa erittäin hyvänä otsikkona dokumentille, joka kuvaa tavoiteltavan palvelun keskeiset tavoitteet, palvelun peruskonseptin, keskeiset toiminnalliset vaatimukset käyttäjien kannalta, ylläpidon vaatimukset, tekniset vaatimukset sekä liittymät muihin järjestelmiin.
Sisältö vaihtelee, dokumentin runko ei välttämättä
Vaatimusmäärittelydokumenttien sisältö voi vaihdella rajustikin palvelusta toiseen, mutta yleensä otsikkotasolla dokumentit ovat samansuuntaisia. Esimerkiksi nuo edellä mainitut mainitut otsikot toimivat hyvin niin isoille verkkopalveluille, verkkokaupoille kuin vaikkapa räätälöidyille B2B-tilauskanaville.
Esimerkiksi parhaillaan HILMA:ssa oleva Gradia.fi-verkkopalvelun toteutuksen kilpailutus ja sen vaatimusmäärittely on hyvä esimerkki keskisuuren verkkopalvelun konseptin ja vaatimukset kuvaavasta vaatimusmäärittelystä. Vaatimusmäärittely on North Patrolin tuottama ja perustuu myös North Patrolin vetämään valmisteluvaiheeseen ja konseptisuunnittelutyöhön. Dokumentti on hieman yli 60 sivuinen Word-dokumentti (pdf-versio on ladattavissa vielä jonkin aikaa), joka sisältää myös suuntaa-antavia rautalankamalleja siitä millaisia sivupohjia ja toiminnallisuuksia uuteen verkkopalveluun halutaan.
Esimerkiksi viitatussa tapauksessa iso osa kuvauksesta keskittyy jo olemassa olevien toimintojen kuvaamiseen ja niiden toteutuksen vaatimiin asioihin. Harva organisaatiohan aloittaa enää tänä päivänä verkkopalvelunsa tekemistä puhtaalta pöydältä, ja yhtä harvoin edellinen verkkopalvelun konsepti laitetaan täysin uusiksi.
Aina kuitenkin palveluun tulee jotain uutta. Tarjoajien kannalta onkin erityisen olennaista, että uusi konsepti ja uudet toiminnallisuudet ovat kuvattuna riittävällä tasolla, jotta näillekin kokonaisuuksille voidaan antaa realistinen työmääräarvio, vaikka niiden osalta ei olekaan esittää yksityiskohtaisia suunnitelmia tai aiempia sovellutuksia. Erityisesti uusien toimintojen kuvauksessa me North Patrolissa suosimme rautalankamalleja, jotka antavat suuntaa-antavaa käsitystä siitä miten palvelun halutaan toimivan, mutta eivät vielä mene visuaalisen suunnittelun tasolle. Käyttöliittymästä rautalankamallit toki antavat jo aika vahvoja suuntaviivoja, mutta silti toimittajien työhön tulee kuulua lopullinen käyttöliittymäsuunnittelu.
Ehkä yksittäinen, isoin liikkuva tekijä vaatimusmäärittelyissä on juuri konseptin kuvaus ja sen kuvauksen kattavuus. Joskus konsepti muuttuu todella paljon, jolloin tarvitaan enemmän konseptisuunnittelutyötä ja myös sen tulosten dokumentointia. Joskus muutokset edelliseen palvelun versioon ovat pienempiä, ja tällöin dokumentti voi keskittyä enemmän nykytilan hyvään kuvaukseen. Joskus taustalla voi olla html-prototyyppikin, johon vaatimusmäärittely voi viitata aina sopivissa kohdissa.
Joskus voi olla myös järkevää jättää konseptin kuvaus hyvin kevyeksi, ja ostaa suunnittelutyötä osana ostettavaa projektia, mutta tällöin hinnoittelumallin pitää olla sitten vastaavasti joustavampi (esimerkiksi tavoitehintamalli).
Esimerkiksi Gradian tapauksessa projektille haetaan sitovaa, kiinteää hintaa, ja tämä edellyttää aina varsin kattavaa vaatimusmäärittelyä. Kaikkia yksityiskohtia ei tällöinkään tarvitse kuvata, mutta etenkin uuden konseptin keskeiset toiminnallisuudet on kuvattava kattavasti, kuten viitattu esimerkkidokumentti tekee.
Gradian tapauksessa työtä helpottaa myös se, että alustaksi on jo esivalittu Drupal, joten vaatimusmäärittely keskittyy kuvaamaan asioita, jotka eivät tule Drupalista valmiina, vaan ovat nimenomaan Gradian verkkopalvelulle uniikkeja toiminnallisuuksia ja vaatimuksia. Suurin osa dokumentista keskittyykin uuden verkkopalvelun konseptin, toimintojen, hakutoimintojen ja muiden erityisasioiden kuvaukseen.
Dokumentti sisältää myös paljon verkkopalveluille tärkeitä perusasioita, kuten sivupohjien ja navigaatiojärjestelmän kuvausta. Lisäksi tässä kyseisessä palvelussa suurin osa sisällöistä tulee integraatioiden kautta muista järjestelmistä, joten näiden rajapinnat on kuvattu esimerkkien kautta ja kuvauksessa on viitattu myös rajapintojen nykytoteutuksiin.
Tärkeintä on eheä kokonaisuus
Palvelusta riippuen, dokumentin sisältö vaihtelee siis varsin paljonkin. Toisen verkkopalvelun vaatimusmäärittelyä ei kannata lähteä kopioimaan. Inspiraatiota ja mallia toki kannattaa katsoa muilta, ja esimerkiksi North Patrolin vaatimusmäärittelyjä on HILMA:ssa lähes läpi vuoden saatavilla (toki nämä ovat vain julkishallinnon caseja). Valitettavasti HILMA:ssa ei ole arkistoa, joten ajoittain mallidokumenttien saatavuus voi olla toki varsin heikkokin.
Tärkein oppi pitää kuitenkin olla se, että vaatimusmäärittelyn pitää olla yhtenäinen, eheä kokonaisuus. Hyvä vaatimusmäärittely kertoo tarinan. Se kertoo tarinan organisaatiosta, joka haluaa ostaa uuden ja hienon palvelun, ja se kertoo mitä kaikkea sinne halutaan laittaa, mitä toimintoja siellä halutaan olevan ja mihin muihin järjestelmiin se halutaan liitettävän. Tämä tarina pitää kertoa riittävällä tarkkuudella, mutta ennenkaikkea tasaisella tarkkuudella. Hyvä vaatimusmäärittely kertoo riittävästi konseptista, riittävästi ylläpidon odotuksista, riittävästi tekniikasta.
Dokumenttia ei kannata pilkkoa useaksi dokumentiksi, koska tällöin tarina aina kärsii. Ja tarina on tärkeä. Tarjoajien on tärkeätä ymmärtää koko palvelun luonne ja tavoitteet, ei pelkästään yksityiskohtia sieltä täältä.
Parhaat tarjoukset ja parhaat kumppanit tulevat aina sieltä missä kokonaisuus on ymmärretty, tarina on sisäistetty. Siksi tarinan kertomiseen pitää panostaa, siksi hyvä vaatimusmäärittely on hyvän kilpailutuksen peruskivi.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Parhaat muotoiluratkaisut tuote- ja palvelusivuille (15.5.2024 klo 10:00). Ilmoittaudu webinaariin
