Miten tietojärjestelmien määrittelyä voisi tehdä paremmin ja nopeammin? Tämä kysymys on noussut esiin, kun tekoälyavusteinen koodaaminen on tuonut sekä määrään että laatuun kohdistuvaa painetta määrittelyyn.

Pureuduimme määrittelyn ja palvelumuotoilun parhaisiin käytäntöihin helmikuussa, kun kokoonnuimme asiakkaidemme kanssa aamupäiväksi Espoon modernin taiteen museoon EMMAan.

Aamutapahtumassa keskustelimme alustuspuheenvuorojen pohjalta siitä, mitä onnistunut vaatimusmäärittely tänä päivänä edellyttää. Keskeiseksi teemaksi nousi ajatus siitä, että vaatimusmäärittely on monimuotoista: onnistunut lopputulos syntyy vasta silloin, kun tietotekninen, liiketoiminnallinen ja käyttäjälähtöinen näkökulma ovat tasapainossa. Jos yksikin näkökulma jää puuttumaan, määrittely jää väistämättä vajaaksi.

Alta voit halutessasi siirtyä suoraan sinua eniten kiinnostavaan teemaan:

Miksi kolme näkökulmaa?
Parhaat opit kustakin näkökulmasta
Palvelumuotoilun ja määrittelyn yhteispeli on ratkaisevaa
Tasapaino syntyy monipuolisesta osaamisesta, ei roolinimikkeiden määrästä
Tulevaisuudessa määrittelijän rooli laajenee, ei kapene

Miksi kolme näkökulmaa?

Vaatimusmäärittelyllä on kolme juurta, jotka juontuvat eri tieteenaloista ja ajattelutavoista. Ajattelutavat ovat peräisin eri aikakausilta, mutta iästään huolimatta kaikki ovat erittäin relevantteja nykypäivän määrittelyssä.

• Tietotekninen näkökulma syntyi 1970-luvulla, kun ohjelmistokehitys ammattimaistui. Sen kysymys oli yksinkertainen: miten tämä rakennetaan? Määrittelyn tehtävä oli kääntää epämääräiset toiveet täsmällisiksi ohjeiksi koneelle. Tämä koulukunta nojaa tietojärjestelmätieteeseen ja ohjelmistokehityksen menetelmiin.
  
  Määrittelyjen selkeys on noussut tekoälyavusteisen koodaamisen myötä entistä tärkeämpään rooliin. Tekoäly ei pysty tuottamaan laadukasta koodia, jos vaatimukset eivät ole yksiselitteiset.

• Liiketoiminnallinen näkökulma nousi esiin 1990-luvulla. Kysymys muuttui muotoon: mitä se maksaa ja mitä se tuottaa? Määrittelyn tehtävänä oli varmistaa, että lopputuote tukee strategiaa ja investointi maksaa itsensä takaisin. Taustalla vaikuttavat liiketaloustiede, strateginen johtaminen ja lean-ajattelu.
  
  Liiketoiminnallinen näkökulma on itsestään selvästi erittäin tärkeä myös tekoälyn aikakaudella. Vaikka koodin tuottaminen on nopeaa ja helppoa, kustannuksissa on silti arvioitava liiketoiminnallinen hyöty vs. järjestelmän koko elinkaaren aiheuttamat kustannukset.

• Käyttäjälähtöinen näkökulma vahvistui 2000-luvulla. Sen kysymys on: mitä ongelmaa tämä ratkaisee? Tavoitteena on, että lopputuote vastaa aidosti käyttäjän tarpeeseen. Tämä koulukunta ammentaa muotoilusta, sosiologiasta, kognitiivisesta psykologiasta ja design thinking-menetelmistä.
  
  Käyttäjälähtöisellä näkökulmalla on erittäin iso merkitys kuluttajatuotteiden määrittelyssä. Yritysten sisäisten järjestelmien kehityksessä käyttäjän kokemusta ei perinteisesti ole koettu yhtä tärkeäksi. Meidän ajatuksemme Reflectorilla kuitenkin on, että käyttäjälähtöisen näkökulman työkalut ja ajattelutapa tuo selviä hyötyjä myös yrityksen sisäisiin järjestelmiin, esimerkiksi vähentämällä käyttäjän tekemiä virheitä.

Parhaat opit kustakin näkökulmasta

Kukin näkökulma tuo määrittelyyn omat parhaat oppinsa. Kaikkien kolmen näkökulman opit ovat relevantteja myös tekoälyajan määrittelyssä. Yhdenkin näkökulman parhaiden käytäntöjen sivuuttaminen tekee määrittelystä vajaan.

Tietoteknisen näkökulman vinkit

• Kirjoita vaatimus niin, että sen voi tulkita vain yhdellä tavalla.

• Muotoile jokainen vaatimus testattavaksi. Jos sitä ei voi todentaa, sitä ei voi myöskään hyväksyä.

• Älä unohda ei-toiminnallisia vaatimuksia. Esimerkiksi suorituskyky, tietoturva ja ylläpidettävyys ratkaisevat lopputuotteen elinkaaren.

• Muista määritellä toiminta myös poikkeustilanteissa.

• Pidä jäljitettävyys kunnossa. Jokaisen vaatimuksen tulee linkittyä alkuperäiseen tarpeeseen ja toteutukseen.

Liiketoiminnallisen näkökulman vinkit

• Kysy jokaisen vaatimuksen kohdalla, miksi tämä on tärkeää. Jos vastaus ei löydy strategiasta tai liiketoiminnan tavoitteista, vaatimus kannattaa haastaa.

• Priorisoi avoimesti. Kaikkea ei voi eikä kannata tehdä, ja päätös siitä mitä jätetään pois, on yhtä tärkeä kuin päätös siitä mitä tehdään.

• Tee kustannus-hyötylaskelma näkyväksi. Päätös on helpompi tehdä, kun investoinnin perustelu on kirkas.

• Varmista, että vaatimukset palvelevat koko organisaatiota, eivät vain yksittäisen tiimin tai yksikön näkemystä.

Käyttäjälähtöisen näkökulman vinkit

• Johda vaatimus todellisesta käyttötilanteesta, älä oletuksesta. Käy paikan päällä, havainnoi ja kysy.

• Kuuntele käyttäjän omaa kieltä. Sanottu toive on harvoin sama kuin todellinen tarve, ja juuri sen tarpeen löytäminen on määrittelijän tärkein tehtävä.

• Testaa vaatimuksia matkan varrella. Iteraatio on halvempaa kuin korjaaminen jälkikäteen.

• Muista, että käytettävyys on osa vaatimusta, ei jälkikäteen lisättävä kuorrutus.

Palvelumuotoilun ja vaatimusmäärittelyn yhteispeli on ratkaisevaa

Käyttäjälähtöisen näkökulman nousu 2000-luvulle tultaessa on hieman hämärtänyt tietoteknisen näkökulman (eli määrittelyn tai vaatimusmäärittelyn) ja käyttäjälähtöisen näkökulman (eli palvelumuotoilun) rooleja onnistuneessa tietojärjestelmäprojektissa.

Kuluttajatuotteiden suunnittelussa palvelumuotoilu on vakiinnuttanut paikkansa. Toisaalta yritysten sisäisten järjestelmien kehittämisessä palvelumuotoilu ei ole pystynyt syrjäyttämään määrittelyä ja vaatimusmäärittelyä samalla tavoin kuin kuluttajatuotteissa. On luonnollista, että yritysten sisäisten, usein monimutkaisten järjestelmien kehittämisessä korostuu tietotekninen ja liiketoiminnallinen näkökulma.

Meidän teesimme on, että käyttäjälähtöisellä näkökulmalla on ehdottomasti paikkansa myös yritysten sisäisten järjestelmien kehittämisessä. Käyttäjälähtöinen näkökulma löytää helposti paikkansa muiden näkökulmien rinnalla.

Käytännössä paras lopputulos syntyy, kun palvelumuotoilua ja määrittelyä tehdään peräkkäin ja limittäin.

➜ Palvelumuotoilu tuo asiakasymmärryksen ja konseptin.
➜ Vaatimusmäärittely jalostaa konseptin tarkoiksi vaatimuksiksi, joista voidaan toteuttaa toimiva järjestelmä.

Ilman palvelumuotoilua lopputulos voi olla teknisesti täydellinen mutta käyttäjälle hankala. Ilman vaatimusmäärittelyä lopputulos voi olla emotionaalisesti syvä mutta teknisesti mahdoton.

Tasapaino syntyy monipuolisesta osaamisesta, ei roolinimikkeiden määrästä 

Kun projekteja pyritään tekemään entistä tehokkaammin ja pienemmällä porukalla, nousee helposti esiin kysymys vaadittavien roolien määrästä. Voisiko määrittelyssä vaadittavia moninaisia rooleja yhdistää tai voisiko jossakin tapauksissa yksi henkilö huolehtia kaikista rooleista?

Meidän näkemyksemme on tämä:

• Pienissä tiimeissä rooleja voi yhdistää (esim. Palvelumuotoilija + Vaatimusmäärittelijä).

• Isoissa hankkeissa on hyödyllisempää pitää roolit erillään, mutta tehdä tiivistä yhteistyötä. Esimerkiksi yhteiset workshopit, jaettu backlog, prosessien kuvaaminen yhdessä.

Yksikin henkilö pystyy tuomaan määrittelyyn kaikki näkökulmat, mutta se vaatii henkilöltä itseltään kykyä tarkastella omaa tekemistään eri näkökulmista käsin. Mikä näkökulma itseltä tulee luonnostaan, ja mikä vaatii enemmän keskittymistä? Uhkaako joku näkökulma jäädä pimentoon ja aiheuttaa ongelmia lopputuotteen laadulle?

Tulevaisuudessa määrittelijän rooli laajenee, ei kapene  

Lopuksi keskustelimme vielä tulevaisuuden vaatimusmäärittelystä. Miltä 2030-luku näyttää? Tekoäly ja automaatio nopeuttavat muutostahtia entisestään. Vaatimukset muuttuvat dynaamisiksi ja syntyvät yhä useammin datasta ja prosesseista. Niitä on tulkittava jatkuvasti.

Muutokset eivät tarkoita sitä, että vaatimusmäärittelijän rooli katoaisi, päinvastoin. Rooli muuttuu vaativammaksi ja strategisemmaksi. Vaatimusmäärittelijästä tulee eräänlainen arkkitehti, joka yhdistää liiketoiminnan tavoitteet, teknologian mahdollisuudet ja eettiset reunaehdot. Hän hallitsee systeemiajattelun, tulkitsee tekoälyn tuottamia vaatimusehdotuksia ja fasilitoi muutosta organisaatiossa.

Mielenkiintoista on, että tekoälyn aikakaudella kaikki kolme näkökulmaa korostuvat samanaikaisesti. Tekninen ymmärrys on välttämätöntä, jotta tekoälyn rooli osataan rajata oikein. Liiketoiminnallinen ote on välttämätöntä, jotta strateginen jäljitettävyys säilyy. Käyttäjälähtöinen näkökulma on välttämätöntä, jotta dynaamisesti syntyvät vaatimukset palvelevat aidosti ihmistä.

Määrittelyn ja palvelumuotoilun monipuoliseen osaamiseen ja kolmeen näkökulmaan panostaminen kannattaa juuri nyt, ja se tulee kantamaan hedelmää vielä 2030-luvullakin.