Käyttäjätarinoilla mitattavia tuloksia
Käyttäjätarinat ovat yleisin tapa kirjoittaa tuotteen kehitysjonon kohtia. Niiden yksinkertainen muoto sallii monipuolisen soveltamisen, mutta toisaalta heikentää helposti kuvauksen selkeyttä ja ymmärrettävyyttä. Asiaa voi parantaa empirismillä ja kokeilukulttuurilla, jossa mitattavissa oleva palaute ohjaa kehitystyötä rakentavaan keskusteluun.
Kehitysjonon kohtien kuvaamisen vaihtoehtoja
Käyttäjätarina on kuvaus halutusta toiminnallisuudesta, joka kerrotaan käyttäjän tai asiakkaan näkökulmasta. Käyttäjätarinassa käytetään asiakkaan ja käyttäjien sanastoa ja vältetään ottamassa kantaa tekniseen toteutukseen.
Esimerkiksi:
Valmentajana haluan kalenterin, jotta tiedän mihin menen kunakin aamuna.
Hyvä käyttäjätarina on itsenäisesti julkaistavissa ja tuottaa arvoa asiakkaille. Se on ymmärrettävä, selkeä, yksiselitteinen ja konkreettinen. Se on arvioitavissa, testattavissa ja mitattavissa ja ohjaa kehitystyötä sopivasti kannustaen vuoropuheluun käyttäjien ja kehittäjien välillä.
Kehitysjonon kohdan voi kirjoittaa myös suorasanaisena tekstinä:
Toiminnanohjausjärjestelmässä on kalenteri, joka sisältää valmennuspalveluiden aikataulut ja laskutettavan työajan.
Liiketoiminnan käsitemalli on yleinen tapa visualisoida käyttäjän sanastoa ja käyttöliittymäluonnos tulevan sovelluksen käyttöliittymää.
Käyttötapaus kuvaa käyttäjän ja järjestelmän vuoropuhelun:
- Valmentaja avaa kalenterin. Järjestelmä näyttää valmentajan tämän kuukauden kalenterinäkymän.
- Valmentaja valitsee kalenterista haluamansa päivän. Järjestelmä näyttää tapahtuman alkamis- ja päättymisajat, asiakkaat, ja tapahtuman agendan.
Esimerkkejä käyttäjätarinan jalostamisesta
Käyttäjätarinaa voi täydentää muilla kuvauksilla ja suullisilla ohjeilla kunnes toteutus alkaa. Usein se pilkkoutuu osiin, joissa eri osapuolet vuorovaikuttavat kehitettävän järjestelmän välityksellä.
Valmentajana haluan että myyjät merkitsevät kalenteriini varaamansa päivät ja tilat sekä sopimansa agendan, jotta pystyn hoitamaan valmennustapahtuman sovitulla tavalla.
Tämä selvittää siis tarkemmin, mitä kukin haluaa ja tekee. Sidos tuotteen tavoitteeseen luo kontekstin, jossa käyttäjätarinaa ymmärretään. Kyse on siis toiminnanohjausjärjestelmään liittyvästä kalenterista.
Käyttäjätarinan perusformaatin sijaan on paikallaan käyttää useampia erillisiä virkkeitä kuvaamaan kuka tekee ja mitä sekä käsiteltävät tiedot. Käsittelysäännöt kuvataan usein erillisessä liitteessä.
Kuvauksen taso tarkentuu mentäessä kohti piirretason kuvausta. Kaikkea ei ole tarkoitus kirjoittaa vaan luoda pohja vuoropuhelulle. Liiketoimintatavoite ja tekninen kuvaus erotetaan toistaan. Järjestelmän ylläpidossa ja tuessa tarvittava dokumentaatio on versioitu muun järjestelmädokumentaation yhteyteen.
Käyttäjätarina on ymmärrettävä, jos se on suoraviivainen tarina kuten esimerkiksi käyttäjän palvelupolku, asiakkaan ostopolku tai käyttäjän onnistunut vuorovaikutus järjestelmän kanssa.
Tietojärjestelmien hyödyt tulevat liiketoiminnan kehittymisen aikaansaamasta arvosta Esimerkissämme se syntyy siitä, että myyjät ja valmentajat onnistuvat valmennustapahtumien järjestämisessä. Kyse on siis tuotteen vaikuttavuudesta
Esimerkkimme on nyt jalostunut muotoon:
Mittarit
Asiakkaiden toiminnan muutoksesta syntyvällä arvolla on yleensä monta ristiriitaista ja päällekkäistä vaikuttavaa tekijää. Mittaristo tarkentuu siirryttäessä strategiasta tuotteeseen ja edelleen sen yksittäiseen käyttäjätarinaan. Esimerkiksi toiminnanohjausjärjestelmä pyrkii löytämään vaikuttavat tuotteet, tehokkaan toiminnan ja asiakkaat, joita haluamme palvella. Sen tavoite sisältää esimerkkimme valmentajan kalenterin tavoitteen.
Seuraavaksi luomme mittariston Goal-Question-Metric-menetelmällä. Kysymme ensin, millä kysymyksillä todennamme saavuttaneemme tavoitteemme. Lean-maailmassa käytetään sekä konkreettisia mittareita kuten virheiden määrä, hukan määrä ja läpimenoaika että subjektiivisia mittareita kuten asiakastyytyväisyys ja henkilöstön tyytyväisyys.
Esimerkissämme tunnistamme onnistumiseen vaikuttavat tekijät:
Mistä tiedämme, että valmentajan kalenteri on vaikuttanut valmennustapahtumien järjestämisen onnistumiseen?
- Valmennustapahtumien virheet
- Tyytyväisyys valmennustapahtumiin
- Järjestämiseen kuluva aika
- Hukka: odottelu, liiallinen työ, työn silpoutuminen
Toinen kysymys GQM:ssä on ”Miten mittaamme sen?” . Näin olemme saaneet käyttäjätarinamme muotoon:
Askeltava eteneminen
Ketterässä hankkeessa tuote koostetaan palauteen avulla löydettävistä paloista, inkrementeistä.
Valmentajan kalenterin tapauksessa portaikkomme voisi olla:
- Myyjät käyttävät valmentajan Outlook-kalenteria.
- Toiminnanohjausjärjestelmä lähettää varaukset valmentajan kalenteriin kokouskutsuina.
- Myös varausten poistot ja muutokset päivittyvät.
- Myyjillä yhtenäinen näkymä varaustilanteisiin valmentajakohtaisesti.
- Valmentajavaraukset toiminnanohjausjärjestelmän ohjaamana.
Koska suunnittelemme inkrementtejä kehitysjonon avulla, karsimme käyttäjätarinaa saadaksemme minimaalisen käyttökelpoisen ratkaisun. Työmääräarvio tarvitaan, jotta pystymme mitoittamaan työn sprintteihin. Opimme, että käyttäjätarina pitää kirjoittaa vain seuraavaa sprinttiä varten ja että sitä saa muuttaa. Liiketoiminnan tavoite säilyi, mutta teknistä toteutusta ja mittaristoa oli ennakoitu liikaa.
Palaute
Inkrementit tehdään sprinteissä valmiiksi ja otetaan todelliseen käyttöön. Asiakkaiden ja käyttäjien palautteesta opitaan mitä oikeasti pitää tehdä ja kehittäjät oppivat tekemään sen paremmin. Hyvät katselmukset muuttavat tuotteen kehitysjonon kohtia.
Palautteen kerääminen on alettu oppia, mutta se keskittyy liialti määrään ja on vain erinomaisuutta osoittava markkinointityökalu. Ketterässä kehitystyössä etsitään laadukasta, harkittua ja kohdennettua palautetta, joka auttaa oppimaan.
Palautteen hyödyntämisen pitää olla armotonta ja johtaa suunnanmuutoksiin kehitystyössä. Koska haluamme aidosti tietää, missä voimme parantaa, tarvitsemme mittareita. Esimerkissämme itseään monitoroiva kalenteri, joka seuraisi järjestelytyöhön kuluvaa aikaa ja virhetilanteita, olisi todennäköisesti parempi kuin byrokraattinen työaikaraportointi.
Reagoimisessa palautteeseen on myös paljon parannettavaa. Kokeilukulttuurissa muutokset eivät ole epäonnistumisia. Palautteen hyödyntäminen on organisoitua esimerkiksi sprintin katselmuksilla. Sopimuksemme ovat joustavia ja mahdollistavat muutokset. Emme myöskään seuraa alkuperäiseen suunnitelman toteutumista vaan pohdimme, mikä on paras jatko kussakin tilanteessa.
Yhteenveto
Käyttäjätarina on hyvä lähtökohta kuvaamaan ihmisten vuorovaikutuksia, jotka toteutetaan tietojärjestelmän ja sen käyttäjien vuorovaikutuksella. Se sopii karkeaan kuvaamiseen, mutta johtaa helposti liialliseen ja hitaaseen määrittelydokumentin kirjoittamiseen.
Hyvä käyttäjätarina kuvaa meneillään olevaa ja lähitulevaisuudessa julkaistavaa inkrementtiä. Se on tarkoituksellisesti epätäydellinen. Se ei ole järjestelmädokumentti vaan väline, joka ohjaa keskusteluun. Mittareiden tarkoituksena on luoda konkretiaa ja paljastaa faktoja, joiden avulla kehitystyön suuntaa voidaan muuttaa.
Sinua saattaisi kiinnostaa
Pentti Virtanen
Pentti on koulutukseltaan filosofian tohtori ja Certified Scrum Trainer. Hänen erityisalueenaan on toiminnan kehittäminen erityisesti ketterillä Lean- ja Scrum-ajattelumalleilla.
Pentin pitkä ja monipuoleinen työkokemus sisältää mm. käytännön projektijohtamista suuryhtiössa ja IT start-upin kasvutarinan 15 henkilöstä 500 henkilöön. Pentin tilaisuuksissa yhdistyvät vahva teoreettinen tausta ja opettavat tarinat hänen käytännön kokemuksistaan.