Mikä on tuotekehityksen pelikirja?

Toimivaan tuotekehityksen tarvitaan toimintamalleja, yhdenmukaiset käytännöt ja roolit. Tuotekehityksen pelikirjat täyttävät akateemisten prosessimallien ja työkalujen välisen aukon. Pelikirja sisältää käytännönläheiset ohjeet (roolit, seremoniat, templatet) prosessimallin soveltamiseen. Pelikirjan avulla prosessit ja  parhaat käytännöt saadaan käyttöön ja niiden hyödyt ulosmitattua täysimääräisesti.

Pelikirja on uusi prosessi

Aikaisemmin ajateltiin, että organisaatioissa pitäisi keskittyä vahvasti prosesseihin. Prosesseja parantamalla pyrittiin saamaan aikaan tehokkuutta ja auttamaan tilanteissa, joissa 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.

Pelikirjat täyttävät sovittujen toimintamallien tyhjiön

Monille tiimeille on 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.

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 on päässyt näkemään paljon erilaisia tilanteita, missä pelikirja on auttanut organisaatioita oppimaan ja kehittämään toimintaansa prosesseja nopeammin.

Mihin tilanteisiin pelikirja sopii?

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