Kun mieheni vei minut yllätysmatkalle Pariisiin, hän kertoi löytäneensä majoituksen hotellien hakukoneesta. Koska typerryin matkasta, niin aivoni menivät uuteen asentoon ja sain idean: voi kun työssäni lastensuojelussa olisi käytössä vastaavanlainen hakukone.
Työskentelin tuohon aikaan vuonna 2016 sosiaalipäivystyksessä, jossa usein piti löytää sijoituspaikka alaikäiselle lapselle. Mielikuvissani näin, miten näpyttelisin hakukoneeseen tarvittavat tiedot ja hakukone ehdottaisi eri vaihtoehtoja. Alle kaksi viikkoa matkasta perustin yrityksen ja lähdin testaamaan, toimisiko idea käytännössä.
Vapaiden paikkojen löytämiseksi piti soittaa läpi kymmeniä lastensuojelulaitoksia, mikä oli turhauttavaa ja työlästä. Tein karkean hahmotelman hakukoneesta, jossa lastensuojelulaitokset ylläpitäisivät omia tietojaan ja kuntien sosiaalityöntekijät löytäisivät tiedon vaikkapa vapaasta paikasta.
Tämän jälkeen tein kyselyn kymmenille kollegoille. Kysely toimi ohjelmiston stressitestinä: ratkaiseeko ohjelmisto aidon ongelman ja onko siitä hyötyä loppukäyttäjille. Jos se ei ratkaise mitään olennaista, niin kukaan ei halua maksaa siitä. Kyselyn perusteella hakukone ratkaisi aidon ongelman, joten luotin, että maksaja löytyy kyllä myöhemmin.
Yrittäjänä kannoin täyden taloudellisen, tuotannollisen ja juridisen vastuun projektin onnistumisesta. Seuraava ja tärkeä askel oli miettiä minkälainen hakukoneen tulisi olla. Olin työskennellyt aiemmin kehittämistyössä, joten oli luonnollista kutsua koolle ohjelmiston loppukäyttäjät ja käyttää joukkoälyä ohjelmiston suunnitteluun. Keräsin vapaaehtoisista koostuvan kehittäjäryhmän, mihin kuului ohjelmiston loppukäyttäjiä: sosiaalityöntekijöitä ja lastensuojelun palveluntuottajia. Tapaamiset kestivät kaksi tuntia kerrallaan ja tapaamisia oli yhteensä kolme. Työmenetelmänä käytettiin tulevaisuuden muistelua, tarinaan perustuvaa ideointia ja teemahaastattelua.
Loppukäyttäjiä pyydetään kuvittelemaan, että he ovat käyttäneet ohjelmistoa kymmenen vuoden ajan. Heiltä kysytään miltä ohjelmisto näyttää, mitä tietoja sieltä löytyy, mikä ohjelmistossa on parasta ja miten se auttaa sinua työssäsi. Ohjelmiston loppukäyttäjillä on paras toimialatuntemus, minkä arvoa ei voi liikaa korostaa. Tämän jälkeen siirrytään kuvitteellisiin käyttötapauksiin. Ryhmälle kerrotaan kolme erilaista asiakastapausta ja he heitä pyydetään kertomaan mitä asioita kukin ottaa huomioon, kun etsii juuri tähän asiakastapaukseen sopivaa palvelua. Tavoitteena on saada laaja-alainen ymmärrys hakukoneen tarpeista vaatimusmäärittelyä varten.
Teemahaastatteluissa kysyttiin mitä tietoja ohjelmiston tulee sisältää, tuleeko ohjelmisto olla integroituna toiseen tietokantaan ja mitkä olisivat hyvät hakukriteerit? Ymmärsimme pian, että hyvä hakukriteeri on riittävän yleinen, mutta ei liian yleinen. Ehdoton edellytys on, että ohjelmiston käyttäjät ymmärtävät ohjelmistossa käytetyt termit samalla tavalla. Koska valmiita määrittelyjä ei ollut olemassa, jouduimme yhdessä määrittämään niitä.
Kehittäjäryhmän tapaamisten jälkeen teimme prototyypin. Prototyyppi oli ns. minimun viable production eli moni toive oli jäänyt rannalle odottamaan myöhempää toteutusta. Seuraavaksi hakukone speksattiin ja ohjelmistotalot kilpailutettiin. Speksi toimi hyvänä asiakirjana ja siihen palattiinkin koodauksen eri vaiheissa. Ideasta toimivaan hakukoneeseen kesti 11 kuukautta.
No emme tietenkään. Keräämme jatkuvasti asiakaspalautetta ja kehitysehdotuksia, jotta ohjelmisto huomioi loppukäyttäjien alati muuttuvat tarpeet.
Tuotekehityslista (backlog) on kruununjalokivi, mistä pidämme hyvää huolta – onhan se myös suurin aineettoman oikeuden erä heti hakukoneen jälkeen, vaikkei sitä taseeseen kirjatakaan. Tuotekehityslistaan merkitään ehdotus, kuka sen on tehnyt ja miten kiireellinen se on. Ehdotus on kiireellinen, jos riittävän moni on toivonut sitä. Ehdotukset saavat päivänvalon versiopäivityksissä.
Palvelumuotoilu kannattaa tehdä yhdessä loppukäyttäjien kanssa. Ihannetapauksessa projektin johtaja on itse loppukäyttäjä, jolloin hän hengittää samaa ilmaa kuin ohjelmisto. Usein palvelumuotoilu on ulkoistettu konsulteille, joilla on vain ohut tuntemus toimialasta. Voisiko osa ohjelmistokehityksen ongelmista johtua tästä?