Mikä on pelikirja? – Ketterä ohjeistus parempiin toimintatapoihin!

Mikä on pelikirja?

Kaikkien organisaatioiden toiminnassa on varaa parantamiseen. Parhaat organisaatiot parantavat toimintaansa joka päivä ja joka hetki. Toiminnan parantaminen lähtee yleensä siitä, että tehdään jotain, katsotaan tuloksia, ja yritetään analysoida, mitä voisi parantaa tai miten voitaisiin päästä lähemmäs tavoiteltua tilaa. Toiminnan parantaminen voi sisältää työtapoja, työkaluja tai niiden käyttöä, toiminnan ohjaamista, tai myös vaikkapa tapoja testata ja päättää, millaisia ominaisuuksia yrityksen tuotteisiin ja palveluihin kehitetään.

Pelikirja tuo avun näiden dokumentointiin ja jakamiseen!

Pelikirja on uusi prosessi

Aikaisemmin ajateltiin, että organisaatioissa pitäisi keskittyä vahvasti prosesseihin. Prosesseja parantamalla pyrittiin saamaan aikaan tehokkuutta, ja auttamaan tilanteissa, missä henkilöt vaihtuvat, tai on paljon muistettavaa. Prosessit ovat edelleen toki monissa tapauksissa tarpeen, mutta prosesseilla on pari ongelmaa. Ne ovat usein päässeet kasvamaan ja pöhöttymään suuriksi, kankeiksi ja joustamattomiksi. Usein ne ovat myös unohtuneet, kun tekeminen rutinoituu. Pölyttynyt paksu prosessikansio ei enää elä jokapäiväisen tekemisen mukana, eikä useinkaan voi muuttua kovin ketterästi. Ihminen ei ole prosessiyhteensopiva.

Pelikirja täyttää sovittujen toimintamallien tyhjiön

Monille tiimeille onkin ketterien toimintamallien yleistyessä tullut tietynkaltainen sovittujen toimintamallien "tyhjiö". Ei enää olekaan olemassa ohjeita tai sopimuksia, mihin viitata, että näin me ajattelimme toimia. Ja tiimeillä on vaikeuksia kokea, että heillä on jotain annettavaa sovittujen toimintatapojen kehittämiseen. Näissä tilanteissa kannattaa harkita uuden keveämmän toiminnan sopimisen mallia: pelikirjaa.

Pelikirjalla tarkoitetaan kevyttä ohjeistusta tai sopimusta toimintatavoista.

Mutta mikä siis on tämä pelikirja? Pelikirjalla tarkoitetaan kevyttä, helposti ylläpidettävää ja käytettävää ohjeistusta tai sopimusta toimintatavoista. Erilaiset pelikirjat ovat nopeasti yleistyneet myös Suomessa. Pelikirjakehityksen pioneerina Suomessa Contribyte (nyk. Eficode) on päässyt näkemään paljon erilaisia tilanteita, missä pelikirja on auttanut organisaatioita oppimaan ja kehittämään toimintaansa prosesseja nopeammin.

Esimerkkejä erilaisista tilanteista, missä pelikirjaa kannattaa harkita

Uuden työkalun käyttöönotto tai työkalujen tehokkaampi käyttö

Työkalujen itseohjautuvassa käytössä (esimerkiksi Wiki- tai Confluence-tyyppiset työkalut) on ongelmana se, että ihmiset osaavat käyttää työkaluja hyvin eri tasoisesti, ja jos kaikille annetaan vapaus tehdä ihan mitä haluavat, tieto ei säily helposti haettavana ja navigoitavana, ja kalliista työkaluista saadaan vain murto-osa niiden potentiaalista irti.

Organisaation tiimien (ketterien) toimintatapojen terävöittäminen / sisäänajo

Tiimien toimintaa pitää kehittää koko ajan, ja useissa organisaatioissa eri tiimeillä on jo hyviä toimintatapoja, mutta ne eivät välttämättä ole käytössä aivan kaikissa tiimeissä. Entäpä jos keräisimme kaikista tiimeistä hyvät toimintatavat pelikirjaan, ja sitten vielä lähtisimme teroittamaan näitä jo valmiiksi hyviä toimintatapoja yhä paremmiksi?

Useiden eri alihankkijoiden yhteistoiminta

Yrityksissä on usein eri toimintakulttuureita. Jos yhteisistä pelisäännöistä ei sovita, konfliktit ovat väistämättömiä. Erityisesti tuotekehitysprojekteissa, joissa käytetään off-site alihankintaa, on erityisen tärkeä sopia miten työtä ohjataan, määritellään, hallitaan riippuvuuksia, ja millaisien kriteerien mukaan työtä toimitetaan seuraavaan työvaiheeseen eteenpäin.

Yrityksen tuotekehitysvoimavarojen, projektien ja tuotteiden portfolioiden hallinta

Erilaiset resurssien kohdentamisen ohjaamistavat, projektien gate-katselmoinnit, projektien resurssipainotuksen ja riskien hallinnan keinot ja tuoteportfolion hallinta voivat myös olla asioita, jotka kannattaisi dokumentoida pelikirjaan

Asiakaspalautteen, ideoiden ja tuotekehityksen asiakaslähtöisyyden parantaminen

Tuotekehitys ei saisi jäädä eristyksiin asiakkaasta ja asiakaspalautteesta. Olisi hyvä varmistaa, että kaikilla tuotekehityksen ihmisillä on tarpeeksi tietoa kaikkeen ajantasaiseen asiakastietoon ja palautteeseen. Myynnin, tuotehallinnan ja tuotekehityksen yhteistoiminnasta kannattaisi myös sopia

Eri roolien selkeyttäminen

Useimmissa organisaatioissa erityisesti tuotekehityksen roolit, tuoteomistaja, Scrum-tiimi, Scrum Master, tuotepäällikkö, muut erilaiset johtajat ovat vähän epäselviä ja käytännössä sopimatta. Roolien pelikirja voisi selventää tilannetta

Pelikirja on helppo jalkauttaa, kehittää ja ylläpitää.

Pelikirja on matalan kynnyksen apu ongelmiin!

Pelikirja on siis käyttökelpoinen monissa erilaisissa tilanteissa. Pelikirjan etu on se, että se on prosessia helpompi lähestyä, ylläpitää, muuttaa, kehittää ja myös jalkauttaa. On myös ehkä helpompi saada koko organisaatio kokemaan, että pelikirja on "heidän oma" toimintamalli, sopimus työtavoista ja työkalujen käyttötavasta.

Ei kai se ole mikään kansio?

Palataan siihen, mikä oikein on pelikirja. Pelikirja voi manifestoitua erilaisilla tavoilla. Usein se dokumentoidaan joko Confluenceen tai dokumenttiin, vaikkapa PowerPointtiin. Pelikirja voi myös sisältää ohjevideoita, templaatteja tai työkalujen tapauksessa esimerkiksi työkalujen näyttöjen ja dashboardien määrityksiä. Tärkeintä on, että pelikirja on jossain, missä siihen pääsee jokainen helposti käsiksi, ja on selkeästi kerrottu, miten pelikirjaa jatkokehitetään.

Pelikirjan rakentaminen, käyttöönotto ja ylläpito on suunniteltava kunnolla

Pelikirja ei rakennu itsestään, vaan sen pystyttäminen on oma projektinsa. Contribytellä ja nyt Eficodella on paljon kokemusta erilaisista pelikirjaprojekteista. Rakennuksessa ja käyttöönotossa on omat selkeät steppinsä ja vaiheensa, ja ulkoista apua voi käyttää joko koko matkan pelikirjan onnistuneeseen jalkautukseen, tai sitten vain osassa rakennusprojektia. Käyttöönoton jälkeen on tärkeää sopia, miten pelikirja kehittyy jatkossa, ja miten siihen voi antaa palautetta ja kehitysideoita. Käsitellään rakentamista, käyttöönottoa ja jatkokehitystä tulevissa blogeissa!