Miten tuotekehityksen pelikirja rakennetaan?
Miten tuotekehityksen pelikirja rakennetaan?
Ensimmäisessä pelikirja -blogissamme käsittelimme sitä, mikä tuotekehityksen pelikirja on, ja minkä takia sitä kannattaa harkita organisaation toiminnan parantamisen keinona. Tällä kertaa haluamme esitellä lukijalle, miten pelikirjaprojekti käytännössä etenee. Olemme tehneet kymmeniä erilaisia pelikirjoja eri tarpeisiin, ja olemme nähneet monia eri tapoja rakentaa ja hyödyntää pelikirjoja.
Miten tuotekehityksen pelikirja rakennetaan?
Tietyt perusvaiheet toistuvat pelikirjan rakentamisessa melkein aina.
Vaikka pelikirjan rakentaminen on joka kerta hiukan erilaista riippuen tarpeesta, pelikirjan tyypistä, organisaatiosta ja pelikirjan vaikutuspiiriin kuuluvien henkilöiden määrästä, tietyt perusvaiheet pelikirjan rakentamisessa toistuvat melkein aina. Tämän blogin tarkoituksena onkin antaa pelikirjaa harkitsevalle käsitys siitä, miten rakennushanke etenee, eli mitä on odotettavissa, kun pelikirja tilataan.
Kannattaako tuotekehityksen pelikirja rakentaa itse, vai käyttää siihen ulkoisia asiantuntijoita?
Puhumme tässä ”tilaamisesta”, mutta pelikirjanhan voi rakentaa myös omin voimin, sillä aina ei ole pakko käyttää ulkoisia experttejä siihen. Ulkoisten apuvoimien käytöllä saadaan kuitenkin seuraavia etuja:
- Niillä avainhenkilöillä, joiden pitäisi yrityksessä pelikirja rakentaa, on usein aika kiire – ulkoinen apu auttaa tekemään asiat nopeammin ja perusteellisemmin.
- Ulkoisille asiantuntijoille on usein helppo puhua asioista, ongelmista ja toimintatavoista, joiden esiin nosto yrityksen omalle henkilökunnalle voisi ”pörhentää höyheniä”. Pelikirja kuvaa sovitut toimintatavat, mutta usein pelikirjaprojekteiden yhteydessä havaitaan asioita, joita kannattaa myös ratkaista nykytoimintamallia paremmin.
- Expertit, jotka ovat nähneet jo monia muitakin pelikirjaprojekteja ja joilla on mahdollista rakentaa pelikirja perustuen ”kirjastoon” hyvin toimivia toimintamalleja, voivat auttaa paljon erityisesti, jos toimintamallit eivät ole täydellisen hyvin määriteltyjä. Tämä nopeuttaa myös sovitun toimintamallin löytymistä ja konsensuksen saavuttamista
Pelikirjahankkeen aloitus – mitä tapahtuu ennen tilaamista tai rakentamispäätöstä?
Tuotekehityksen pelikirja rakennetaan tarpeeseen, ei pelkästään mukavuuden takia. Aivan aluksi kannattaa tunnistaa, miksi tarvitset pelikirjaa, ja mitä hyötyä sillä haetaan. Näitä hyötyjä voi olla usein esimerkiksi seuraavat:
- Halutaan selkeyttää usean eri tiimin tai alihankkijan toimintatapoja, jotta yhteistoiminta sujuisi tehokkaammin, vähemmillä konflikteilla ja paremmalla laadulla.
- Halutaan parantaa tiimin tai organisaation omaa toimintaa tai kehittää itseohjautuvuutta tai itseoppimista
- halutaan parantaa jotain osa-aluetta, esimerkiksi tietyn työkalun käyttöä, tai vaikkapa asiakaspalautteen tai -ymmärryksen tiedon levittämistä organisaatiossa.
- Halutaan parantaa jotain organisaation portfoliohallintaa, esimerkiksi ideoiden tai projektien portfoliohallintaa.
- Halutaan selkeyttää organisaation rooleja.
Tarpeita on paljon muitakin erilaisia, mahdollisuuksia kuvaa ehkä parhaiten seuraava kuva:
Tässä vaiheessa, ennen varsinaista pelikirjan rakentamisen aloittamista, olisi myös tarpeen määritellä tavoitteet pelikirjalle ja hankkeelle.
- Kuinka kauan haluamme, että rakentaminen kestää?
- Kuinka paljon voimme käyttää rahaa?
- Mitä haluamme tulokseksi, ja miten voimme mitata tuloksia?
- Miten rakennusprojektin etenemistä seurataan ja ohjataan?
- Mitä rakentaminen tarkoittaa – miten paljon haastatteluja, työpajoja, prototyyppikierroksia yms. on odotettavissa?
- Ainakin alustava ajatus siitä, millaisessa muodossa pelikirja dokumentoidaan, ja minne
- Pelikirjan ”deployment” ja jatkokehityksen suunnittelu
Suunnittelu ja tavoitteet luovat raamit pelikirjan rakentamiselle.
Nämä asiat ovat todella tärkeitä. Aikataulu, ajatus tuotoksista ja alustava rakentamisen toimenpiteiden suunnittelu auttaa ymmärtämään, miten kauan hankkeessa menee, ja antaa mahdollisille ulkoisille asiantuntijoille raamit toiminnalle. Lisäksi – tuotekehityksen pelikirja ei auta ketään, jos se tehdään, mutta jää vain johdon pöytälaatikkoon. Käyttöönotto on otettava huomioon jo siinä vaiheessa, kun pelikirjaa päätetään alkaa tekemään. Samoin, mikään toimintamalli, joka on jäässä eikä kehity lisää, ei pidemmän päälle auta parempiin tuloksiin. Jatkokehittämisen vastuuta kannattaa ajatella jo tässä vaiheessa.
Pelikirjaakaan ei kannata rakentaa vesiputousmallilla!
Vaikka tässä kirjataankin asioita pelikirjan rakentamisen suunnitelmaksi, kannattaa muistaa, että näihin suunnitelmiin kannattaa suhtautua kuin aina kaikkiin suunnitelmiin – ne muuttuvat varmasti, kun päästään toteutusvaiheeseen. Tarvitaan ehkä lisää työpajoja, lisää kommenttikierroksia, muutoksia ensimmäisiin pelikirjaversioihin ja niin edelleen. Hyvä pelikirjaprojektikin on ketterästi toteutettu! Rakentamisen aikana kannattaa hienosäätää toteutussuunnitelmaa.
Toteutusvaihe
Haastattelut ja työpajat
Toteutusvaihe aloitetaan yleensä aikatauluttamalla haastattelut ja työpajat seuraavien viikkojen ajalle. Tarkempi suunnittelu kannattaa tehdä vasta ensimmäisten kontaktien jälkeen. Ensimmäisten työpajojen jälkeen aloitetaan myös alustavan pelikirjan raakamateriaalin kerääminen ja tallennus. Pelikirjamateriaali voi rakentua joko dokumentteihin, tai sitten se voidaan rakentaa confluenceen tai vastaavaan wikityyppiseen paikkaan kaikkien nähtäville.
Referenssimallien käyttö
Työpajat voidaan toteuttaa joko niin kutsutusti ”puhtaalta pöydältä”, tai sitten voidaan ottaa lähtökohdaksi joku Contribyten vastaava referenssimalli. Usein referenssimallin käytöllä saadaan etuna se, että keskustelu etenee nopeammin kohti haluttua toimintatapaa. On usein helpompi osoittaa jotain mallia, ja huomata miten emme toimi tällä tavalla, vaan jollain muulla tavalla. Referenssimallin käytöllä voidaan myös verrata organisaation omaa toimintatapaa referenssimalliin, ja katsoa tulisiko sitä kautta ideoita parempaan toimintatapaan.
Työpajoissa käydään läpi eri alueita niin, että paikalla on organisaation parhaat ”tietäjät”. Työpajoissa pyritään siihen, että paikalla ei ole liikaa ihmisiä, liian isot työpajat ovat tehottomia. Työkaluihin liittyvissä pelikirjoissa tehdään ensimmäisten työpajojen jälkeen nopeasti protoilua ja konfigurointeja, jotta päästään nopeasti kokeilemaan työkaluja ja ymmärtämään jatkostepit.
Prototyypit, simulaatiot ja mallin soveltaminen
Toimintatapoja kuvaavissa pelikirjoissa saatetaan tässä rakennusvaiheessa tehdä työpajojen jälkeen tai lisäksi erilaisia simulaatioita, joissa pyritään nopeasti havaitsemaan, miten malleja kuvata tai soveltaa. Esimerkiksi SAFe-käyttöönotoissa on erityisen tärkeää SAFen sovellussuunnitelma – eli miten organisaatio ottaa SAFen käyttöön.
Alustavien tulosten katselmukset
Katselmointi kannattaa tehdä varhaisessa vaiheessa!
Työpajojen, prototyyppien ja mallinnusharjoitusten jälkeen, heti kun on jotain näytettävää, pyritään pelikirjaprojektissa järjestämään sopiva setti katselmuksia, missä katsotaan alustavia tuloksia, niiden dokumentointimallia, ja työkalujen osalta prototyyppikonfiguraatioita. Tavoitteena katselmuksilla on saada tärkeimmät kommentit ja suunnan säädöt, jotta työ etenee koko ajan oikeaan suuntaan. Katselmusten jälkeen on yleensä selvää, millaisilla toimenpiteillä saadaan ”lopullinen” versio pelikirjasta tehtyä.
Joskus katselmuskierroksia tulee enemmän, joskus selvitään yhdellä tai kahdella, se riippuu aika paljon hankkeen laajuudesta, ja siitä, miten paljon on toimintatavoissa epäselvää. Mitä enemmän katselmuskierroksia tulee, sitä enemmän pelikirjalle yleensä on ollut selkeää tarvetta!
Pelikirjan 1.0-version hyväksyntä ja koulutuksen suunnittelu
Kun tuotekehityksen pelikirja on hyväksytty ja paketissa, täytyy se seuraavaksi jalkauttaa. Tämä tarkoittaa yleensä, että suunnitellaan sopiva setti koulutustilaisuuksia. Nämä vaativat oman materiaalin. Koulutustilaisuudet voivat olla webinaareja, e-learning tyyppisiä, luokkahuonekoulutuksia, etäkoulutuksia, tai sitten yksilöitä tai tiimejä valmentavia sessioita. Näiden yhdistelmäkin on tietenkin mahdollinen. Koulutuksen kesto vaihtelee toteutustavasta ja koulutettavien määrästä.
Koulutus kannattaa ajoittaa mahdollisimman lähelle hetkeä, jolloin mahdolliset uudet toimintatavat tai työkalut ovat ihmisten käytettävissä. Harjoitukset ja simulaatiot ovat pakollisia! On myös otettava huomioon, että työkalut ja uudet toimintatavat saattavat tarvita tukihenkilöä, joka vähintään vastaa kysymyksiin, mutta mahdollisesti myös auttaa ja tukee käyttöönotossa.
Jalkautusvaihe
Tässä vaiheessa koulutukset ja käyttöönotot käynnistyvät. Vaihe saattaa kestää organisaation koosta riippuen viikosta, vaikka useaan kuukauteenkin. Tärkeää tässä vaiheessa on pitää huolta siitä, että käydään läpi jokainen henkilö ja tiimi, johon pelikirja vaikuttaa, ja kuunnellaan ja otetaan palautetta sekä pelikirjan sisältöön, että koulutusmateriaaliin ja -tapaan. Palautteesta saadaan arvokasta tietoa siitä, miten koulutusta pitää muokata, jotta se toimisi tehokkaammin, ja pelikirjaan sisältöön liittyvä palaute auttaa muovaamaan jatkokehityssuunnitelmaa.
Motivaatio on helpompi ylläpitää, jos ihmiset ymmärtävät, mitä etua heille on toimia pelikirjassa kuvatulla tavalla.
Muutosvastarinnan hallinta
Tiimikohtaisella koulutuksella pystytään myös varmistamaan, että kaikki ymmärtävät uuden toimintamallin tai työkalun hyödyt ja syyt, miksi sitä käytetään. Loppuviimeksi työkaluja käyttää ja toimintaa pyörittää ihmiset organisaatiossa, ja meidän pitää motivoida heitä toimimaan halutulla tavalla. Tämä motivaatio on helpompi löytää ja ylläpitää, jos ihmiset ymmärtävät, mitä etua heille on toimia pelikirjassa kuvatulla tavalla. Näin vähennetään muutosvastarintaa. Myös mittaaminen on tärkeää. Jalkautusvaiheessa pitää seurata ja kontrolloida, että pelikirjan toimintatapoja myös käytetään.
Pelikirjasta ei ole hyötyä, jos toiminta ei seuraa sen ohjeviivoja.
Jalkautusvaiheen lopuksi kerätään yhteen saatu palaute ja päivitetään pelikirjan sisältö ja jatkokehityssuunnitelma. Pelikirjaa ei saa jättää nukkumaan versioon 1.0, vaan sitä pitää kehittää ja ylläpitää. Tämä tarkoittaa usein sitä, että pelikirjalle määritellään omistaja, jonka vastuulla jatkokehitys organisaatiossa on. Ulkoista apua voi käyttää tähänkin, esimerkiksi ajastamalla muutaman kuukauden päähän työpajan, jossa kartoitetaan vielä lisää käytännön asioita, mitä pelikirjan käytössä on tullut vastaan. Seuraavassa blogissa kerromme vielä lisää, mikä on tärkeää pelikirjan jatkokehittämisessä!
Arto Kiiskinen
Senior Consultant
Arto on urallaan nähnyt tuotekehitystä monista eri näkökulmista. Hänellä on kokemusta mm. Product Ownerin, Scrum Masterin ja tuotekehitysjohtajan tehtävistä. Niin isojen kuin pientenkin firmojen toimintatavat ovat tulleet tutuiksi. Arto rakastaa parantaa organisaatioiden oppimista sekä tuoteomistajien osaamista, ja kirjoittaa blogeja eri aiheista. Koska retrospektiivit on yksi Arton suosikkiaiheista, ovat jotkut asiakkaat antaneet hänelle lisänimen "Retromies". Vapaa-aikana Arto yrittää elää terveellisesti, ostaa mahdollisimman paljon autoja, katsoo yhä uudelleen Tähtiportti-sarjan jaksoja ja opiskelee Personal Traineriksi. Arto on kirjoittanut kirjan "OWN IT – 8 Simple Secrets of Product Owner Success". Lisää Arton ajatuksia voi lukea täältä.