Palvelumuotoilu on osa laadunvarmistusta

Uutisotsikoita lukiessa tulee helposti mieleen, että yritykselle räätälöidyn ohjelmiston tilaaminen on kuin rulettia pelaisi. Jotkut projektit saadaan läpi ennätysajassa ja juuri niinkuin on sovittu, mutta toiset projektit viivästyvät, ylittävät budjetin ja loppujen lopuksi toimivat täysin erilailla kuin on ajateltu. Miksi palvelumuotoilu on noussut tärkeään rooliin nykyaikaisessa softankehityksessä?

”Henkilökohtaisesti vihaan termiä palvelumuotoilu, mutta jokainen softaprojekti pitäisi alkaa sillä että toimittajan pari teknistä henkilöä jalkautuu päiväksi kyselemään tyhmiä loppukäyttäjältä. Eli siis kysyvät, että miksi missäkin vaiheessa painetaan mitäkin nappia ja miten softan eri osien toiminnallisuudet heijastuvat reaalimaailmaan. Jos tätä ei tehdä, on laadunvarmistus vedetty vessanpöntöstä alas ennen kuin projekti on ehtinyt edes alkaa.”

Nämä sanat minulle sanoi vuosia testausta tehnyt ammattilainen, joka oli lopen turhautunut ristiriitaisiin määrittelyihin ja asiakkaan vuodatuksiin siitä kuinka toimitettu softa ei vastaa heidän tarpeitaan. Vaikka lainaus kärjistää ongelman ainoastaan yhteen ainoan asiaan, on siinä silti totuuden siemen, jotka pitäisi ottaa huomioon softaprojektia suunnitellessa.

Palvelumuotoilu on hyvä tapa varmistua siitä, että kaikki projektin jäsenet ovat tietoisia siitä mitä ohjelmistolta odotetaan ja millaisia polkuja käyttäjät kulkevat operoidessaan ohjelmistoa.

Usein palvelumuotoilu mielletään ainoastaan asiakasrajapinnan ominaisuudeksi. Vähintään yhtä suuri osa palvelumuotoilua tulisi tehdä myös ohjelmiston käyttäjän näkökulmasta. Jos toimittajalle ei kerrota mikä ongelma ohjelmiston on tarkoitus ratkaista tai edes sitä mikä on ohjelmiston käytetyin ominaisuus, on täysin mahdotonta luoda ohjelmisto joka täyttää kaikkien loppukäyttäjien tarpeen. Palvelumuotoilun pitäisi siis aina ulottua koskemaan myös niitä käyttäjiä, jotka ohjelmistoa tulevat käyttämään.

Kun ohjelmiston suunnittelijat ja tekijät ymmärtävät miksi ohjelmistoa tehdään ja mitkä ovat ne ongelmat mitkä ohjelmiston pitää ratkaista, on kaikki piirun verran helpompaa. Kun määrittelyssä huomataan virhe tai se on epäselvä, voidaan asia korjata jo ohjelmistoa tehtäessä. Jos toimittajalla ei ole ymmärrystä siitä miten juuri tehtyä toiminnallisuutta tullaan käyttämään, on myös mahdotonta huomata, jos tehty toiminnallisuus ei täytä niitä tarpeita joita sen käyttäjä siltä tulee vaatimaan. Tämä aiheuttaa bugin ja valtavasti lisätyötä. Pahimmillaan tilanne eskaloituu määrityksen pilkuntarkaksi tutkimiseksi, joka on täysin turhaa työtä niin ohjelmiston toimittajalle, kuin tilaajallekin. Jos koko projekti koostuu tällaisista keskeytyksistä, on sanomattakin selvää että projektityöryhmän resurssit valuvat aivan muuhun työhön kuin pitäisi.

Palvelumuotoilu on hyvä tapa varmistua siitä, että kaikki projektin jäsenet ovat tietoisia siitä mitä ohjelmistolta odotetaan ja millaisia polkuja käyttäjät kulkevat operoidessaan ohjelmistoa. Kun suunnitellun ohjelmiston käyttäjäpolut ja kontaktipisteet on selkeästi määritelty, on ohjelmiston laadunvarmistus lähtenyt liikkeelle oikealla jalalla.