Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä.

Transkriptio

1 Toiminnallisen määrittelyn tarina Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä.

2 Toimitusjohtajan pulma Tässä on toimitusjohtaja Roope, jonka tavoitteena on pyörittää Rengasmaster Oy:tä mahdollisimman menestyksekkäästi. Rengasmaster saa rahaa, kun myynti ja markkinointi onnistuvat saamaan autoilijat vaihtamaan talvirenkaansa juuri heidän avustuksellaan. Ei ole aivan yksinkertaista saada renkaanvaihtorumba sujuvaksi sekä asiakkaan että Rengasmasterin työntekijöiden kannalta. --- Roopella on tavoitteita: lisää rahaa Rengasmaster Oy:lle, paremmat työkalut omalle väelle, sujuvampaa asiointia asiakkaille. Voisiko tilannetta parantaa tietojärjestelmien avulla? Roopen ja Rengasmasterin ei tarvitse ihmetellä pidempään. He kutsuvat Reaktorin suunnittelijat paikalle.

3 Suunnittelijat tarttuvat toimeen Käyttöliittymä- ja konseptisuunnittelijat Marko ja Jenni käyvät tilanteen läpi Roopen kanssa. Roope kertoo Rengasmasterin liiketoiminnasta ja kolmikko tunnistaa yhdessä, mihin kaikkeen pitää perehtyä tarkemmin. Marko ja Jenni ryhtyvät selvittämään, mitä ongelmia kannattaa ratkaista tietojärjestelmällä ja missä ja kenellä se olisi käytössä. He menevät katsomaan ja kokemaan, missä pahin kipu tällä hetkellä on. Marko ja Jenni ryhtyvät seuraamaan Rengasmasterin huoltotiimin päivittäistä työtä.

4 Kentältä löytyy konkretiaa Marko ja Jenni tapaavat Aapon, Rengasmasterin toimistossa istuvan huoltohemmon. He seuraavat Aapon työntekoa aamupäivän ajan ja näkevät, kun Aapo käyttää nykyjärjestelmiä tosielämässä. Aapolla on erilaisia tavoitteita kuin Roopella. Arjen kiireistä ja asiakkaiden kanssa toimimisen kompastuskivistä saa tukevan käsityksen seuraamalla työtä siellä, missä se tapahtuu. Aapo osaa kertoa työnkulusta konkreettisesti ja näyttää esimerkkejä. Marko ja Jenni näkevät, kuinka varausjärjestelmä, sähköposti ja laskutusjärjestelmä eivät toimi yhteen. Suuri osa Aapon työajasta menee turhaan tietojärjestelmissä navigointiin asiakastilanteiden hoitamisen sijaan. Tänäkin aamuna syntyi pitkä jono.

5 Mitä todella tapahtui Marko ja Jenni kirjoittavat kaikki Aapon työn tarkkailussa eteen tulleet käyttötilanteet ylös: Käyttötilanne 1: Asiakas soittaa klo 9.03: Onnistuisiko talvirenkaiden vaihto pakettiautoon vielä tänään aamupäivällä? Käyttötilanne 2: Asiakas soittaa klo 9.19: Mulla on renkaiden vaihto varattuna tänään klo 11. Mä en pääse tulemaan, joten siirretään vaihto huomiselle. Milloin olisi aikaa? Käyttötilanne ja niin edelleen. Erilaisia tilanteita tunnistetaan kymmenittäin.

6 Tilanteista toiminnallisuuksia M & J ryhtyvät suunnittelemaan uutta käyttöliittymää selvitettyjen käyttötilanteiden perusteella. He tekevät käyttöliittymäsuunnittelun mahdollisimman kevyesti ja tehokkaasti: piirtämällä kynällä paperille. Marko ja Jenni piirtävät paperiproton, joka ratkaisee tiedossa olevat Aapon ja asiakkaiden käyttötilanteet suoraviivaisesti ilman turhia vaiheita. Simulointipohjainen suunnittelu pohjautuu Sari A. Laakson kehittämään menetelmään. Lisää Sarin työstä täällä.

7 Proton kanssa takaisin kentälle Marko ja Jenni menevät paperiproton kanssa Aapon luokse ja näyttävät, miten työtä tehtäisiin heidän suunnittelemalla uudella järjestelmällä. Aapolle tulee mieleen uusia esimerkkitilanteita, joita käyttöliittymällä ei vielä pysty tekemään. Ei hätää, muutoksen ja täydennyksen tekeminen on tässä vaiheessa todella helppoa! Marko ja Jenni palaavat suunnittelupöydälle uusien esiin tulleiden käyttötilanteiden kanssa. Työ jatkuu ja seuraavia protoversioita käydään läpi sekä Aapon, Roopen että muiden Rengasmasterin työntekijöiden kanssa. Aapo pystyy ottamaan kantaa käytännön työn tekemiseen, Roope osaa kommentoida liiketoiminnan näkökulmasta.

8 Pilkotaan ja priorisoidaan Muutaman suunnittelu-läpikäynti-suunnittelu -iteraation jälkeen Marko & Jenni esittelevät paperiprotoa Roopelle. Roope on tyytyväinen ja yllättynyt siitä, että syntynyt ratkaisu on jotain aivan muuta kuin mitä hän alunperin kuvitteli. Ohjelmiston rakentamisen ja käyttöönoton lisäksi Rengasmasterin pitäisi muutenkin optimoida toimintaansa. Selvisi mm. että Rengasmasterin kannattaisi perustaa oma huoltolinja asiakkaille, jotka saapuvat ilman ajanvarausta. Suunnitellussa ratkaisussa on tekemistä pitkäksi aikaa. Nyt pitää päättää, mistä on bisneksen kannalta järkevintä aloittaa ja millä laajuudella ryhdytään tekemään. Mihin ollaan valmiita nyt, mihin asetetaan rima? Tavoitteet pitää asettaa realistisesti.

9 Suunnitelmasta softaan Ohjelmiston toteutus alkaa. Aapon ja muiden käyttäjien elämään perehtyneet Marko ja Jenni auttavat järjestelmää rakentavaa tiimiä koko toteutuksen ajan. Käyttäjille arvokasta softaa voidaan julkaista jo pian: ensimmäinen tuotantoon vietävä versio voi olla vain pienen pieni osa kokonaisuudesta, mutta jos se on bisneksen kannalta tärkein ja käyttäjille juuri oikea, hyötyä ja iloa syntyy heti.

10 Tuotannossa! Mitä sitten? Julkaistun version käyttöä seurataan tarkasti. Marko ja Jenni käyvät vielä Aapon luona järjestämässä testin, jossa he seuraavat käyttöä kaikissa tunnetuissa tilanteissa. Paljastuu, että avoimen huoltolaskun muokkaus pitää tehdä vielä helpommin löydettäväksi. Kun tilanne ja ongelma ovat tiedossa, on parannus pian suunniteltu ja voidaan korjata seuraavaan versioon. --- Kun bisnestä palveleva järjestelmä on käytössä, Rengasmaster muuttuu. Asiointi muuttuu, tilauksia on ehkä enemmän, ruuhkaa vähemmän. Uusia ideoita herää ja toiminnan kehittämistä voi jatkaa moneen eri suuntaan. Sitten suunnitellaan lisää.

11