Innovaatiopeleihin perustuva ketterä vaatimusmäärittelymenetelmä

Innovaatiopeleihin perustuva ketterä vaatimusmäärittelymenetelmä Oulun yliopisto Tietojenkäsittelytieteiden laitos Pro gradu -tutkielma Teemu Pyykölä 22.2.2011

2 Tiivistelmä Vaatimusmäärittely on ohjelmiston kehityksessä yksi tärkeimpiä osioita. Pieleen mennyt vaatimusmäärittely voi tuomita koko projektin epäonnistumaan eikä tätä seikkaa havaita pahimmassa tapauksessa ennen kuin projekti on ohi. Ketterään vaatimusmäärittelyyn on kehitetty erilaisia ratkaisuja, joista suurin osa perustuu hyvin pitkälle asiakkaan ja kehittäjän vuorovaikutukseen. Vaatimusmäärittelyssä tulisi pyrkiä saamaan asiakkaan tarpeet selville mahdollisimman aikaisessa vaiheessa, jotta muutokset kehitystyön loppuvaiheessa voitaisiin minimoida. Suuret muutokset järjestelmän vaatimuksiin kehitystyön aikana voivat pahimmillaan johtaa koko järjestelmän arkkitehtuurin muutoksiin. Innovaatiopelit ovat markkinatutkimukseen tarkoitettuja menetelmiä, joissa asiakas otetaan mukaan ideointiin. Asiakkaalta pyritään saamaan tietoja ja tuotteen käyttöön liittyviä ideoita pukemalla suunnittelutilaisuus pelimäiseen muotoon. Asiakasta voidaan pyytää eläytymään tilanteeseen, jossa tuote on tietynlaisessa käytössä. Näin saadaan asiakas miettimään seikkoja, jotka eivät välttämättä tulisi normaalissa suunnittelutilanteessa mieleen. Innovaatiopeleihin liittyy joskus pitkäkin prosessi ennen kuin tulokset saadaan käytettävään muotoon. Ketterässä ohjelmistokehityksessä on tavoitteena päästä toteuttamaan ohjelmistoa mahdollisimman nopeasti. Tämä ristiriitaisuus täytyisi saada ratkaistua, mikäli innovaatiopelejä halutaan käyttää ketterässä vaatimusmäärittelyssä. Tässä tutkimuksessa pyrittiin keventämään innovaatiopeleihin liittyvää prosessia. Lisäksi tavoitteena oli tutkia voiko innovaatiopelejä käyttää ketterässä vaatimusmäärittelyssä. Tutkimuksessa käytettiin suunnittelutieteellistä tutkimusmenetelmää. Tutkimuksen aikana rakennettiin paperiprototyyppi Prune the product tree -innovaatiopelin käyttämiseen vaatimusmäärittelyssä. Paperiprototyypin lisäksi tutkimuksessa tehtiin malli, jolla puun voi siirtää digitaaliseen muotoon jatkokäsittelyä varten. Kehitettyä paperiprototyyppiä testattiin Kauppamajakka Oy:ssä. Asiasanat Innovaatiopeli, ketterä, vaatimusmäärittely, luova ohjelmistokehitys, Hohmann

3 Alkusanat Tämän tutkielman ajatus lähti Projekti II -kurssista, jossa käsiteltiin innovaatiopelejä. Menetelmän käyttö vaatimusmäärittelyssä tuntui hyvältä. Aluksi ajatuksena oli tehdä gradun yhteydessä internet pohjainen sovellus innovaatiopelien käyttöön, mutta ajan käytön ja menetelmän paremman ymmärtämisen vuoksi päädyttiin tekemään paperiprototyyppi. Kiitos ohjaajilleni professori Jouni Similälle ja FT Raija Haloselle. Kiitän myös Kauppamajakka OY:ta mahdollisuudesta testata kehitettyä menetelmää. Lisäksi kiitän kaikkia, jotka ovat auttaneet gradun teossa. Pulkkilassa 22.2.2011 Teemu Pyykölä

4 Sisällysluettelo Tiivistelmä...2 Alkusanat...3 1. Johdanto...6 2. Vaatimusmäärittely...8 2.1 Vaatimusmäärittelyn vaatimukset...8 2.2 Luova vaatimusmäärittely...10 3. Ketterät vaatimusmenetelmät...11 3.1 Kasvotusten kommunikointi...13 3.2 Iteratiivinen vaatimusmäärittely...14 3.3 Äärimmäinen vaatimusten priorisointi...14 3.4 Vaatimusten muutosten hallinta jatkuvalla suunnittelulla...14 3.5 Prototyypit...15 3.6 Testivetoinen kehitys...15 3.7 Katselmoinnit ja hyväksymistestit...16 3.8 Product backlog...16 4. Innovaatiopelit...17 4.1 Yleistä innovaatiopeleistä...17 4.2 Prune the product tree...19 4.3 Remember the future...20 4.4 Spider web...20 4.5 Product box...21 4.6 Buy a feature...21 4.7 Start your day...22 4.8 Show and tell...23 4.9 Me and my shadow...23 4.10 Give them a hot tub...24 4.11 The apprentice...24 4.12 20/20 vision...24 4.13 Speed boat...25 5. Innovaatiopelien käyttö ketterässä vaatimusmäärittelyssä...27 6. Tutkimusmenetelmät...30 7. Tutkimuksen eteneminen ja tulokset...33 7.1 Suunnitelma...33 7.2 Ensimmäinen iteraatio...33 7.3 Toinen iteraatio...34 7.4 Kolmas iteraatio...34 7.5 Ensimmäinen testi...35 7.6 Neljäs iteraatio...36 7.7 Ensimmäinen testi Kauppamajakka Oy:ssä...37 7.8 Toinen testi Kauppamajakka Oy:ssä...37 7.9 Viides iteraatio...38 7.10 Kuudes iteraatio...40 8. Kehitetty menetelmä...41 8.1 Puumalli...41 8.2 Käyttö ketterissä menetelmissä...41 8.3 Menetelmän käyttö...42 9. Keskustelu...43 10. Yhteenveto...45

5 Lähdeluettelo...47 Liite A. Ensimmäinen versio lehdestä ja oksasta...51 Liite B. Toinen versio lehdestä ja oksasta...52 Liite C. Kolmas iteraatio...53 Liite D: Ohje asiakkaalle vaatimusmäärittelyyn...57 Liite E: Vaatimukset Kauppamajakka Oy:n testistä...58 Liite F: PHP ohjelma XML tiedoston muotoiluun...60 Liite G: Lopullinen testi.xml...62

6 1. Johdanto Innovaatiopeleistä osana ketterää vaatimusmäärittelyä on julkaistu hyvin vähän tieteellistä tutkimusta. Kuitenkin niiden merkitys on suuri, sillä niiden avulla asiakkaalta voidaan saada tehokkaasti tietoa vaatimuksista. Innovaatiopelien avulla yritys pyrkii saamaan asiakkaalta tarkempaa palautetta tuotteen ominaisuuksien priorisointiin. Innovaatiopelejä on erilaisia, mutta yleinen piirre niille on tuotteen ominaisuuksien lisääminen ja poisto. Tuotetta voidaan mallintaa peleissä esimerkiksi puuna, johon lisätään oksia ja lehtiä ominaisuuksia kuvaamaan. Ketterissä kehitysmenetelmissä pyritään kehittämään asiakkaalle tärkeimmät ominaisuudet ensin ja näin tuomaan lisää liiketoiminta-arvoa kehitettävälle sovellukselle. Ketterät menetelmät pyrkivät ratkaisemaan ohjelmistoon tulevia muutoksia ottamalla ne paremmin huomioon kehitysprosessissa. Ketterät menetelmät toimivat usein sykleittäin, jolloin jokainen ohjelmiston kehitysvaihe käydään läpi kaikissa sykleissä. Innovaatiopelit sopinevat hyvin ketterien menetelmien kanssa rinnan käytettäväksi, sillä molemmat menetelmät pyrkivät priorisoimaan toteutettavia ominaisuuksia. Ketteriä menetelmiä on toisaalta kritisoitu vaatimusmäärittelyvaiheen vähäisestä huomioon ottamisesta. Ketterät menetelmät pyrkivät vähentämään ohjelmistotuotannossa syntyvää dokumentoinnin määrää ja keskittymään itse kehitystyöhön. Tällöin olisi hyvä keksiä keino, jolla saadaan asiakkaalta nopeasti tarkkoja vaatimuksia. Vuonna 2000 raportoitiin, että vain 26 % ohjelmistoprojekteista oli katsottu onnistuneeksi. Tarkemmassa tarkastelussa kävi ilmi, että puolet projektien lakkautuksista johtui vaatimusmäärittelyvaiheen heikosta laadusta. Sama määrä onnistuneista projekteista katsottiin onnistuneiksi hyvän vaatimusmäärittelyn takia. (Eberlein & do Prado, 2002) Perinteisessä ohjelmistokehityksessä pyritään eliminoimaan muutokset ohjelmiston vaatimusmäärittelyssä ja siten vähentämään kustannuksia. Ketterissä menetelmissä puolestaan pyritään vähentämään muutoksista aiheutuvia kustannuksia. Ketterät menetelmät rohkaisevat tekemään nopeasti yksinkertaisen version ohjelmistosta, jotta käyttäjältä saadaan palautetta nopeasti. Kun sovelluksen kehittämistä jatketaan, ohjelmiston rakennetta parannetaan helpottamaan jatkossa tulevien ominaisuuksien implementoimista. (Highsmith & Cockburn, 2001.) Tutkimuskysymyksenä on, miten innovaatiopelejä voidaan käyttää vaatimusmäärittelyssä? Lisäksi tutkitaan, millä menetelmällä vaatimusmäärittelyprosessia voidaan tukea ja saada visuaalisemmaksi sekä helpommaksi asiakkaalle. Visuaalinen lähestymistapa tarjoaa mahdollisuuden tehdä menetelmä luonnollisemmaksi ja käyttäjäystävällisemmäksi (Chen, Chen & Kavi, 2002). Tutkimuksen tavoitteena oli tehdä prototyyppi, jonka avulla innovaatiopelejä voidaan käyttää ketterässä vaatimusmäärittelyssä. Lisäksi tutkimuksen tavoitteena oli muokata Hohmannin (2006) esittelemää innovaatiopelien prosessia keveämmäksi ja siten sopimaan paremmin ketterään ohjelmistokehitykseen. Tutkimus tehtiin

7 konstruktiivista tutkimusmenetelmää käyttäen. Tutkimuskysymykseen vastaamaan rakentamalla mallista paperiprototyyppi. pyrittiin Tässä tutkielmassa tukeuduttiin Luke Hohmannin (2006) tulkintaan innovaatiopeleistä perinteisen markkinatutkimuksen korvaajana ja täydentäjänä. Kehitetty menetelmä jätettiin paperiprototyyppi asteelle, eikä siitä lähdetty tämän tutkimuksen yhteydessä kehittämään eteenpäin. Menetelmän testaus tehtiin vain yhdessä kohteessa ja testin yhteydessä kehitettiin eteenpäin olemassa olevaa järjestelmää. Kehitetty menetelmä suunnattiin vaatimusmäärittelyn ensimmäisiin vaiheisiin. Vaatimusmäärittelyssä aikaiset vaiheet ovat tehty epämuodollisesti ja ilman työkalutukea (Yu, 1997). Tutkielman toisessa luvussa käydään läpi vaatimusmäärittelyn teoriaa. Lisäksi tehdään katsaus luovaan vaatimusmäärittelyyn ja kuvataan, mitä siitä on kirjoitettu aikaisemmin. Ketterät vaatimusmäärittelymenetelmät kuvataan kolmannessa luvussa. Neljännessä luvussa esitellään innovaatiopelit Luke Hohmannin (2006) mukaan. Viidennessä luvussa peilataan innovaatiopelejä olemassa olevaan teoriaan ja käydään läpi tähän asti tehtyä tutkimusta innovaatiopelien käytöstä vaatimusmäärittelyssä. Kuudennessa luvussa esitellään tutkimusmenetelmät ja seitsemännessä tutkimuksen kulku. Kahdeksannessa luvussa esitellään tutkimuksessa kehitetty malli, joka perustuu Prune the product tree -innovaatiopeliin. Yhdeksännessä luvussa kehitettyä mallia verrataan olemassa olevaan teoriaan.

8 2. Vaatimusmäärittely Vaatimusmäärittelyä pidetään usein yhtenä tärkeimmistä ja vaikeimmista vaiheista ohjelmistokehityksessä. Vaatimusmäärittely sisältää vaatimusten määrittelemisen ja ylläpidon. Vaatimusmäärittelyvaiheeseen panostaminen vähentää virheitä ja riskejä sekä parantaa ohjelmiston laatua. Mitä aikaisemmin vaatimuksiin päässeet virheet havaitaan, sitä helpompi ne on korjata (Lauesen & Vinter, 2001). Ohjelmistoprojektin epäonnistuminen liittyy usein vaatimusmäärittelyssä tehtyihin virheisiin, kuten käyttäjäpalautteen puuttuminen, vaatimusten epämääräisyys sekä muuttuvat tai puutteelliset vaatimukset. Vaatimusvirheet johtuvat yleensä vääristä oletuksista, sivuutetuista vaatimuksista ja puutteellisista vaatimuksista (Young, 2002; Lauesen & Vinter, 2001). On arvioitu, että 85% virheistä saa alkunsa vaatimusmäärittelyn aikana (Young, 2002). Suurin osa virheistä liittyy käyttöliittymän suunnitteluun (Lauesen & Vinter, 2001). NASAn julkaiseman datan mukaan vaatimusmäärittelyyn käytetty aika korreloi negatiivisesti projektin budjetin ja aikataulun ylittymisen kanssa. (Damian & Chisan, 2006.) 2.1 Vaatimusmäärittelyn vaatimukset Vaatimusmäärittely on yhteydessä muihin ohjelmistokehityksen vaiheisiin. Hyvät vaatimusmäärittelymetodit parantavat kehittäjien kykyä komminikoida asiakkaan kanssa ja antavat paremmat mahdollisuudet arvioida projektin kulkua. (Damian & Chisan, 2006.) Asiakkaiden kanssa kommunikoinnin merkitys kasvaa entisestään, mikäli vaatimukset eivät ole täysin selviä kaikille (Emam, Quintin, Madhavji, 1996). Myös kehitystiimin sisäinen kommunikointi paranee hyvien vaatimusmäärittelymetodien myötä. Kehittäjät voivat käyttää vaatimuksia tarkistaakseen ominaisuuksien yksityiskohtia. (Damian & Chisan, 2006.) Fernández ja Monzón (2000) esittelevät metamallin vaatimusten eri osa-alueiden vaikutuksista toisiinsa. He ovat kehittäneet mallin, jotta vaatimukset voidaan arkistoida esimerkiksi tietokantaan ja siten seurata niiden muuttumista sekä vaikutusta toisiinsa.

9 Kuva 1. Vaatimusten metamalli (Fernándes & Monzón, 2000, s. 2.) Asiakkaan edustajan tulisi olla sitoutunut, asiantunteva, yhteistyökykyinen, edustava ja valtuutettu (Boehm, 2002; Turner & Boehm, 2003). Jos asiakkaan edustaja ei ole yhteistyökykyinen, hän aiheuttaa turhautumista kehitysryhmässä. Asiakkaan tulee olla edustava, jotta hän voi antaa todenmukaisia vaatimuksia järjestelmään. Jos asiakas ei ole valtuutettu, hukataan aikaa hyväksymisen kyselyyn ylemmiltä tahoilta tai pahimmassa tapauksessa annetaan luvattomia sitoumuksia. Jos asiakas ei ole sitoutunut, hän ei tee tarvittavia esivalmisteluja eikä ole paikalla, kun kehitysryhmä tarvitsee tietoja. Mikäli asiakkaan edustaja ei ole asiantunteva, hän voi aiheuttaa viivästyksiä tai epäkelvon tuotteen. (Turner & Boehm, 2003.) Kukin vaatimus tulisi olla tarpeellinen, verifioitavissa, saavutettavissa oleva, yksiselitteinen ja selkeä, johdonmukainen, jäljitettävissä, tiivis, implementaatiovapaa ja sillä tulisi olla uniikki numero. Implementaatiovapaalla tarkoitetaan vaatimusta, jonka toteutukseen ei oteta kantaa. (Young, 2002.) Vaatimuksen tulisi kuvata mitä tehdään, ei miten tehdään. Vaatimusten tulisi kuvailla vain, mitä tapahtuu järjestelmän käyttöliittymän ja ympäristön välillä (Zave & Jackson, 1997). Kehittäjien ja asiakkaiden tulisi yhdessä evaluoida annetut vaatimukset, jotta ne ovat kaikki tarpeellisia (Young, 2002). Onnistunut vaatimusmäärittely vaatii asiakkaiden tarpeiden ymmärtämisen. Vaatimusmäärittely alkaa huonosti määritellyistä ja usein ristiriitaisista ideoista järjestelmän toiminnasta. Vaatimusmäärittelyn ongelma-alue on suurempi kuin ohjelmiston ratkaisualue. Vaatimusmäärittelyn aikana ratkaisualuetta pienennetään ja tehdään päätöksiä ohjelmiston kehittämiseen liittyen. (Cheng & Atlee, 2007.) Vaatimusmäärittely ei ole suoraviivainen prosessi, vaan se sisältää myös suuria vaatimusten tai mallin uudelleen järjestelyjä. Tällainen prosessi on yleistä myös yleisellä tasolla toimivissa ongelmanratkaisumalleissa. (Nguyen & Swatman, 2003.) Ongelma voidaan esittää ristiriitana uusien vaatimusten ja systeemin prototyypin kesken (Sushkov et al., 1995).

10 2.2 Luova vaatimusmäärittely Luovuudelle on useita eri määritelmiä. Luovuus liittyy kuitenkin useimmiten ongelman ratkaisuun. Luovuus ymmärretään erityisesti innovatiivisiksi odottamattomiksi ratkaisuiksi ei-triviaaliin tai ilkeisiin ongelmiin (wicked problem). Luovuutta tukevissa tekniikoissa kommunikoinnin tukeminen on usein pääroolissa. Vaatimusmäärittelyssä joudutaan usein ratkaisemaan ilkeitä ongelmia. Ilkeä ongelma on ongelma, jota ei voida kuvata malleilla. Näin ollen sitä ei pystytä ratkaisemaan suoraviivaisesti järkiperäisellä, tieteellisellä tai teknisellä lähestymistavalla. (Mitch, Anesi & Berry, 2002.) Ratkaisu löytyy usein kehittäjän tietotaidon ulkopuolelta, joten on löydettävä keino siirtää tietoa liiketoiminta-alueelta toiselle (Sushkov, Mars & Wognum, 1995). Alkuvaiheen vaatimusmäärittelyssä käytetään kognitiivista ja systemaattista metodia. Kognitiiviset metodit sisältävät aivoriihen kaltaiset menetelmät. Systemaattiset metodit käyttävät muodollista lähestymistapaa. (Sushkov, Mars & Wognum, 1995.) Vaatimusmäärittelyssä suosituin luovan ajattelun tekniikka on aivoriihi. Myös erilaisia roolipelipohjaisia skenaarioita on käytetty. Yhteistä näille tekniikoille on ongelman pyörittäminen erilaisista näkökulmista. Vaatimusmäärittelyssä luovuus on sekä ongelma että sen ratkaisu. Ongelman luovuudesta tekee kolme seikkaa: asiakkaat, jotka löytävät enemmän vaatimuksia kuin haluavat sovellukseen toteutettavan. Lisäksi vaatimusten ymmärtämisessä on virheitä sekä valmiiksi tehtyjen ohjelmiston osien ympäristö ja vaatimukset muuttuvat. Vaatimusmäärittely itsessään on ongelmallista, koska kehittäjät haluavat siirtyä suunnitteluun ja toteutukseen. Toisaalta, jos vaatimukset dokumentoidaan tarkasti, on niiden muuttaminen hankalaa. (Mitch, Anesi & Berry, 2002.) Vaatimusmäärittelyprosessi ei ole suoraviivainen, vaan se sisältää kriisipisteitä, joissa vaatimukset ja järjestelmän malli voivat muuttua. Kriisipisteen jälkeen muodostettu malli ei ole vain parannettu vanha malli, vaan se on voitu rakentaa kokonaan uudelleen. Uuden mallin kehittämiseen ei ole välttämättä käytetty systemaattista analyysia. Kehittäjä on pyrkinyt löytämään parhaimman kyseiseen tilanteeseen sopivan mallin. (Nguyen & Swatman, 2003.) Onnistuakseen vaatimusmäärittelyssä täytyy tuntea kohteena oleva liiketoimintaympäristö ja -prosessi. Vaatimusmäärittelijän tehtävä on auttaa asiakasta ymmärtämään, mitä tämä todella tarvitsee. (Orr, 2004. ) Vaatimusmäärittelyssä käytettyjen termien pitäisi perustua ympäristöön, johon järjestelmä tehdään (Zave & Jackson, 1997). Alkukantaiselle termille tulisi tarjota informatiivinen yksiselitteinen selitys (Zave & Jackson, 1997). Vaatimukset kirjoitetaan yleensä luonnollisella kielellä ja ne kuvaavat mitä halutaan yksityiskohtaisen spesifikaation sijaan (Sommerville, 2005; Botaschanjan, Pister & Rumpe, 2004).

11 3. Ketterät vaatimusmenetelmät Agile Manifesto (2001) on ketterien menetelmien taustalla. Se määrittelee neljä perusarvoa ketterille menetelmille. (Dybå & Dingsøyr, 2008.) Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja Toimivaa ohjelmaa enemmän kuin kokonaisvaltaista dokumentaatiota Asiakkaan vuorovaikutusta enemmän kuin sopimusneuvotteluja Muutokseen reagoimista enemmän kuin suunnitelman seuraamista (Agile Manifesto, 2001.) Ketterät menetelmät ja vaatimusmäärittely nähdään usein yhteensopimattomina asioina (Paetsch, Eberlein & Maurer, 2003; Ho, Johnson, Williams, Maximilien, 2006). Perinteinen vaatimusmäärittely nojaa vahvasti dokumentointiin, jotta opittuja asioita voidaan siirtää tuleviin projekteihin (Paetsch et al., 2003). Ketterät menetelmät puolestaan painottavat asiakkaan kanssa kommunikointia, jotta asiakkaalla ja kehittäjillä olisi sama tavoite (Paetch et al., 2003). Dybå ja Dingsøyr (2008) ovat käyneet läpi 36 eri artikkelia liittyen ketterään ohjelmistokehitykseen. Artikkeleissa on käyty läpi muun muassa siirtymisprosessia perinteisestä kehitysmenetelmästä ketterään kehitysmenetelmään. Suuri osa artikkeleista käsitteli extreme programming -menetelmää. Lisäksi joukossa oli useampi artikkeli, jotka käsittelevät ketteriä menetelmiä yleisesti. Yhtä lukuun ottamatta kaikki artikkelit pitivät ketteriä menetelmiä uusina menetelminä. Yhdessä artikkelissa ketterät menetelmät kuvailtiin olevan dokumentoituja seikkoja, jotka tulevat luonnostaan. Artikkelissa käydään läpi koko ohjelmiston kehityskaari. (Dybå & Dingsøyr, 2008.) Ketterien menetelmien suunnitteluperiaatteet kuvataan taulukossa 1. Asiakkaan odotetaan olevan mahdollisimman paljon kehitysryhmän käytettävissä (Bose, Kurhekar & Joydip, 2008). Ketterissä menetelmissä ei odoteta, että asiakas pystyy antamaan yksityiskohtaiset vaatimukset heti aluksi. Ketterät menetelmät pyrkivät pitämään työskentelytavat mahdollisimman yksinkertaisina. Menetelmiin on helpompi lisätä ohjeita, kuin poistaa niitä. (Fowler & Highsmith, 2001.)

12 Taulukko 1. Ketterien menetelmien suunnitteluperiaatteet (Dove, 2006 s. 5). Kehittyvät standardit Valmiiden frameworkkien käytöllä saadaan valmiiksi sovelluksen sisäinen vuorovaikutus. Itsenäiset moduulit Moduulit ovat erillisiä ja itsellisiä uudelleen käytön parantamiseksi. Moduulien yhteensopivuus Moduulit jakavat ennalta määritellyn rajapinnan. Uudelleenkäyttö Moduulit ovat korvattavissa ja käytettävissä uudelleen. Päällekkäisyys ja monimuotoisuus Päällekkäisiä moduuleita hyödynnetään niin, että vaihtoehtojen määrä saadaan sopivaksi ja virheensietokykyä parannettua. Samankaltaisten moduulien monimuotoisuutta hyödynnetään uudelleenkäyttämällä metodeja. Elastinen kapasiteetti Moduulien määrä voi muuttua frameworkin sisällä. Suora interaktio Moduulit suhteita pyritään välttämään. kommunikoivat suoraan keskenään ja ketjutettuja Lykätty sitoutuminen Moduulien suhteiden määrittämistä pyritään lykkäämään mahdollisimman myöhäiseen vaiheeseen. Hajautettu kontrolli ja suunnittelumetodin sijaan. informaatio Moduuleita ohjaa käyttötarkoitus Itse-organisoituva Moduulien suhteet muodostuvat itsestään. Cao ja Ramesh (2008) löysivät empiirisessä tutkimuksessaan seitsemän erilaista ketterää vaatimusmäärittelymenetelmää, jotka ovat käytössä yrityksissä. Yritykset pyrkivät saamaan ketterillä vaatimusmäärittelymenetelmillä selville tarkemmin asiakkaidensa tarpeet ja tekemään siten parempia sovelluksia. Menetelmät perustuvat pitkälti asiakkaan kanssa kommunikointiin ja niiden tavoitteena on saada oikeat korkean tason vaatimukset mahdollisimman aikaisessa vaiheessa. Näin pyritään vähentämään muutoksen tarvetta ohjelmistotuotannon loppuvaiheessa, jolloin muutoksien tekeminen on kalleinta. Kehittäjät luottivat ketteriin vaatimusmenetelmiin niin paljon, että käyttivät niitä jopa turvallisuuskriittisten sovellusten suunnittelussa. Cao ja Ramesh löysivät artikkelissaan seitsemän erilaista käytössä olevaa ketterää vaatimusmäärittelymenetelmää. Paetsch et al. (2003) mukaan asiakkaan mukana olo projektissa oli kriittistä projektin onnistumiselle. Taulukossa 2 on listattu 16 yrityksen käyttöaste ketterille kehitysmenetelmille. Nämä menetelmät on jatkossa kuvattu tarkemmin vertailupohjan muodostamiseksi innovaatiopeleille. (Cao & Ramesh, 2008.)

13 Taulukko 2. Vaatimusmäärittelymenetelmien käyttöaste 16:ssa Caon ja Rameshin (2008, s.67) tutkimassa yrityksessä Käyttöaste Kasvotusten kommunikointi Iteratiivinen vaatimusmäärittely ÄärimJatkuva Proto- TestiKatselmäinen suunnittelu tyypit vetoinen moinnit vaatimusten kehitys ja testit määrittely Korkea 8 9 10 8 8 5 11 Keskitaso 8 5 6 6 3 1 4 Matala 0 2 0 2 0 0 1 Ei käytä 0 0 0 0 5 10 0 Kriitikkojen mukaan ketterien menetelmien keskittyminen koodiin voi johtaa organisaation muistin häviämiseen, koska dokumentaatioon ei panosteta (Turk, France & Rumpe, 2002). Ketterät menetelmät tukeutuvat usein prototyyppeihin vaatimusmäärittelyn avuksi. Ei-toiminnalliset määrittelyt voivat jäädä silloin vähälle huomiolle, mikä voi pahimmassa tapauksessa aiheuttaa projektin epäonnistumisen. Asiakkaan kanssa voi olla vaikea määritellä ei-toiminnallisia vaatimuksia. (Eberlein & do Prado Leite, 2002.) 3.1 Kasvotusten kommunikointi Kasvotusten kommunikoinnissa pyritään tehokkaaseen ideoiden jakamiseen asiakkaan ja kehittäjän kesken. Dokumentaatio jätetään vähemmälle huomiolle. Korkean tason vaatimukset voidaan määritellä esimerkiksi käyttäjätarinoilla ja näitä dokumentteja käytetään myöhemmin lähtökohtana tarkemmalle vaatimusmäärittelylle. Lisäksi ennen uuden toiminnallisuuden toteuttamista kehittäjät keskustelevat vielä asiakkaan kanssa tarkemmin vaatimuksesta. (Cao & Ramesh, 2008.) Kasvotusten kommunikoinnin hyötyjä on asiakkaan parempi vaikutuskyky toteutettavaan sovellukseen, jolloin asiakas voi ohjata kehitystyötä haluamaansa suuntaan paremmin. Tarkempi käsitys asiakkaan tavoitteista vähentää tarvetta dokumentaatiolle ja hyväksymisprosesseille. Haasteina ovat suuri vuorovaikutustarve asiakkaan ja kehittäjän välillä. Projektille voi aiheuttaa suuria vaikeuksia, mikäli kehittäjä ei pääse hyvään vuorovaikutukseen asiakkaan kanssa. Lisäksi menetelmässä oletetaan, että asiakas pääsee samaan tilaan kehittäjien kanssa ja on käytettävissä, kun kehitystiimi häntä tarvitsee (Turk et al., 2002). Kasvotusten kommunikointi ei myöskään sovi etätyönä tehtävään kehitykseen (Turk et al., 2002). Useamman asiakkaan ollessa mukana projektissa vaatimusmäärittelyt saattavat kasautua ja aiheuttaa liikaa työtä yhteen kehityssykliin. Lisäksi perinteiseen vaatimusmäärittelyyn tottuneet asiakkaat saattavat suhtautua epäilevästi ketterään vaatimusmäärittelyyn. (Cao & Ramesh, 2008.)

14 3.2 Iteratiivinen vaatimusmäärittely Iteratiivinen vaatimusmäärittely perustuu ajatukseen, että vaatimukset muuttuvat koko kehitysprosessin ajan. Korkean tason vaatimukset tehdään kehityssyklin alussa. Dokumentaatiota ei juuri käytetä ja asiakkaan kanssa keskustellaan kehityssyklissä toteutettavista vaatimuksista. (Cao & Ramesh, 2008.) Iteratiivisen vaatimusmäärittelyn etuja ovat hyvän asiakassuhteen muodostuminen kommunikoinnin kautta sekä helposti ymmärrettävät vaatimukset. Haasteiksi muodostuvat kustannusten sekä aikataulun arviointi, sillä vaatimuksia ei lyödä etukäteen lukkoon. (Cao & Ramesh, 2008.) Toisaalta kehittäjät saattavat pyrkiä vanhasta tavastaan lyömään kaikki vaatimukset heti lukkoon (Tattersall, 2002). Lisäksi vaatimukset saattavat muuttua huomattavasti kehityksen aikana. Vähäinen dokumentointi saattaa aiheuttaa ongelmia kehitysryhmän sisäisessä kommunikoinnissa ja henkilöstön vaihtuessa uuden kehittäjän voi olla vaikeampi päästä sisälle järjestelmän kehitykseen. (Cao & Ramesh, 2008.) Projektin vaatimukset voivat olla selvillä liian myöhään, jotta ne ehtisivät kaikkien kehittäjien saataville ajoissa. Ei-toiminnalliset vaatimukset saattavat jäädä jopa määrittelemättä kokonaan, sillä asiakkaat keskittyvät usein vain toiminnallisiin vaatimuksiin (Cao & Ramesh, 2008). On mahdollista, että suunniteltua vaatimusta ei pystytä toteuttamaan kyseisessä kehityssyklissä. Tällöin se siirtyy eteenpäin seuraavaan sykliin ja jää pahimmassa tapauksessa kokonaan toteuttamatta. Vaatimus saattaa myös olla liian suuri toteutettavaksi yhden syklin aikana, jolloin se joudutaan joko pilkkomaan pienemmiksi kokonaisuuksiksi tai osoittamaan useammalle syklille. (Tattersall, 2002.) 3.3 Äärimmäinen vaatimusten priorisointi Ketterissä menetelmissä tärkeimmät ominaisuudet toteutetaan ensimmäisenä, jolloin asiakas näkee jo aikaisessa vaiheessa, mikä järjestelmän liiketoiminta-arvo on. Perinteisessä ohjelmistokehityksessä vaatimukset priorisoidaan kerran, mutta ketterissä menetelmissä vaatimukset priorisoidaan jokaisen kehityssyklin aikana. (Cao & Ramesh, 2008.) Etuna menetelmässä on asiakkaan mahdollisuus vaikuttaa toteutettaviin vaatimuksiin läpi ohjelmiston kehityksen. Kun asiakas on mukana kehityksessä, hän voi antaa kehittäjille perusteet toteutuksista, jolloin myös kehittäjät ymmärtävät paremmin asiakkaan tarpeet. Paetsch et al. (2003) suosittelevat antamaan vaatimusten priorisoinnin kokonaan asiakkaalle ja kehittäjä kertoo, mitä teknisiä riskejä ja vaikeuksia valintaan sisältyy. Haasteena on markkina-arvon nouseminen usein päällimmäiseksi kriteeriksi priorisoinnille. Myös ei-toiminnallisten vaatimusten jääminen taka-alalle voi aiheuttaa suuria refaktorointitarpeita. (Cao & Ramesh, 2008.) 3.4 Vaatimusten muutosten hallinta jatkuvalla suunnittelulla Vaatimusten muutosten hallinta jatkuvalla suunnittelulla pyrkii täyttämään asiakkaan tarpeet jättämällä tilaa vaatimusmuutoksille. Menetelmässä lähdetään olettamuksesta, että muutokset on halvempi toteuttaa ketterässä menetelmässä kuin perinteisissä ohjelmistokehitysmenetelmissä. Kehittäjän ja asiakkaan välillä tapahtuvalla

15 kommunikoinnilla pyritään vähentämään ylläpidon tarvetta. Asiakkaan kanssa keskustellaan ennen uuden ominaisuuden toteuttamista, jotta asiakkaan tavoitteet ymmärrettäisiin paremmin. Kehittäjä saa myös jatkuvaa palautetta sovelluksesta. (Cao & Ramesh, 2008.) Etuna menetelmässä on aikainen ja jatkuva seuranta, joka vähentää suuria muutostarpeita. Muutokset ovat lähinnä kosmeettisia seikkoja, jotka saattavat koskea esimerkiksi käyttöliittymäelementtien sijoittelua. Tämän seurauksena muutokseen käytetyt resurssit vähenevät. Haasteena on arkkitehtuurin varhainen valitseminen. Jos arkkitehtuuri ei tue kaikkia asiakkaan haluamia ominaisuuksia, sen uudelleen teko tulee kalliiksi myöhemmässä vaiheessa. Myös refaktoroinnin yhteydessä voidaan joutua tekemään paljon uudelleen koodausta. (Cao & Ramesh, 2008.) 3.5 Prototyypit Prototyyppejä käytettäessä vaatimusmäärittelymenetelmänä sovelluksen tärkeät ominaisuudet tehdään ensimmäisenä. Asiakas pääsee kokeilemaan sovelluksen toiminnallisuutta aikaisessa vaiheessa ja pystyy antamaan kehityksen varhaisemmassa vaiheessa palautetta sovelluksesta. Prototyyppejä on kahta erilaista tyyppiä, pois heitettävä prototyyppi auttaa ymmärtämään vaikeita vaatimuksia ja kehitysprototyyppi tarjoaa asiakkaalle toimivan järjestelmän osan (Paetsch et al., 2003). Prototyyppi voi olla myös paperiprototyyppi tai prototyyppi, jossa kehittäjä matkii järjestelmää (Paetsch et al., 2003). Lopullinen sovellus voi myös olla toiminnallinen prototyyppi. Prototyyppien käyttämistä vaatimusmäärittelyssä edesauttaa pyrkimys julkaista sovellus mahdollisimman pian.(cao & Ramesh, 2008.) Etuna prototyyppejä käytettäessä on asiakkaalta saatava palaute sovelluksesta aikaisessa vaiheessa. Haasteena ovat mahdolliset riskit, mikäli prototyyppi tehdään tuotantokoodiin. Prototyypit on tyypillisesti tehty nopeasti, jolloin kehityksessä ei voida ottaa välttämättä tarvittavassa määrin huomioon muunneltavuusja turvallisuusvaatimuksia. Asiakas saattaa myös saada väärän kuvan sovelluksen valmiudesta ja kieltäytyy maksamasta jatkokehitystä. (Cao & Ramesh, 2008.) Kun prototyyppi on hoitanut tehtävänsä se tulisi hävittää. Prototyypit säilytetään kuitenkin usein spesifikaation osana tai muistuttamaan miten kyseinen asia huomattiin. (Pinheiro, 2003.) 3.6 Testivetoinen kehitys Testivetoisessa kehityksessä kehittäjä luo testejä ennen uuden toiminnallisuuden kirjoittamista. Williamsin, Maximillien ja Voukin (2003) mukaan testivetoisesti kehitetty sovellus sisälsi 40 % vähemmän virheitä kuin perinteisemmillä menetelmillä tehty sovellus. Testit vastaavat vaatimusmäärittelyissä määritettyjä toiminnallisuuksia ja niiden kirjoittaminen tulisi nähdä osana vaatimusmäärittely- ja suunnitteluvaiheita. (Cao & Ramesh, 2008.) Testivetoisen kehityksen etuja on koodin ja vaatimusten yhdistäminen yhtenäiseksi paketiksi. Mikäli vaatimuksiin tehdään muutoksia, muutoksen toimivuus testataan myös tarkasti. Haasteena on toimintatapojen muutos useisiin muihin kehitysmenetelmiin nähden. Testien luomiseen ja ajamiseen tulisi käyttää automatisoituja työkaluja (Williams et al., 2003). Automatisointi antaa kehittäjälle nopeasti palautetta sovelluksen

16 toimivuudesta muutosten jälkeen (Williams et al., 2003). Kehittäjät eivät ole tottuneet kirjoittamaan testejä etukäteen, joten tapojen muutos vaatii itsekuria. Testien kirjoittaminen edellyttää lisäksi tarkkaa tuntemusta järjestelmän vaatimusmäärittelyistä. (Cao & Ramesh, 2008.) 3.7 Katselmoinnit ja hyväksymistestit Jokaisen kehityssyklin lopussa pidetään kokous asiakkaan, kehittäjien, johtoryhmän sekä laadunvalvonnan kesken. Näissä kokouksissa kehittäjät esittelevät syklin aikana tehdyt uudet ominaisuudet, ja asiakas sekä laadunvalvonta esittävät kysymyksiä kehittäjille. Caon ja Rameshin tekemän tutkimuksen mukaan näissä kokouksissa tuli ilmi vain pieniä seikkoja, kuten ikkunoiden elementtien asemointia. (Cao & Ramesh, 2008.) Etuna katselmoinneissa ja hyväksymistesteissä on asiakkaalle tarjottava raportti kehityksen edistymisestä. Kokouksen aikana voidaan varmistaa, että projekti on edennyt oikeaan suuntaan, lisätään asiakkaan luottamusta kehitystiimiin ja tunnistetaan ongelmat jo aikaisessa vaiheessa. Haasteena on kokoukseen käytettävä aika, joka voi nousta yhtä suureksi kuin perinteisissä menetelmissä. Asioista ei kuitenkaan pidetä kirjaa samassa mittakaavassa kuin perinteisissä menetelmissä. Asiakkaalta saattaa puuttua tietotaito hyväksymistestien kirjoittamiseen, jolloin kehittäjän laadunvalvonnan on avustettava asiakasta. (Cao & Ramesh, 2008.) 3.8 Product backlog Backlog on Scrum -menetelmässä hyödynnettävä vaatimusmäärittelymenetelmä. Scrummissa projekti alkaa pidemmällä suunnittelukokouksella. Kokouksessa määritellään ominaisuudet, jotka halutaan saada aikaan esimerkiksi seuraavan kuuden kuukauden aikana. (Sutherland, 2004.) Product backlogiin kirjattavia elementtejä ovat virheet, asiakkaan kehityspyynnöt, kilpailevien tuotteiden ominaisuudet ja teknologian päivitykset (Schwaber, 1995). Product backlogiin kirjataan kaikki sillä hetkellä tiedossa olevat vaatimukset. Tämän jälkeen product backlog priorisoidaan ja jaetaan pienemmiksi osiksi päätetyn julkaisuaikataulun mukaan. (Mahnic & Drnovscek, 2005.)

17 4. Innovaatiopelit Innovaatio nähdään usein hallitsemattomana ilmiönä. Kehitetään useampi eri tuote ja luotetaan, että onnistumiset kattavat epäonnistuneetkin yritykset. Innovaatiosta tulee hallittua, kun luovutaan yleispätevistä resepteistä sekä ymmärretään erilaisten sääntöjen ja työtapojen pätevän erilaisessa kontekstissa. (Miller, Olleros, Molinié, 2008.) Tässä luvussa käytetään päälähteenä Hohmannin (2006) kirjaa, sillä innovaatiopeleistä löytyy vain vähän tieteellistä kirjoitusta. Tuotekehityspelit (R&D games) on Conley et al. (1997) mukaan esitellyt ensimmäisen kerran Dasgupta ja Stiglitz artikkelissa Industrial Structure and the Nature of Innovative Activity vuonna 1980 The Economic Journal lehdessä (Conley, Mansouri, Temimi, 1997). Luke Hohmann (2006) on esitellyt innovaatiopelit tapana saada asiakkailta paremmin palautetta ja ideoita. Innovaatiopelit eivät noudattele peliteoriaa (Miller et al, 2008). Niihin osallistuu useita itsenäisiä pelaajia, ne voivat kestää pitkän ajan ja ovat strategisesti monimutkaisia (Miller et al, 2008). Innovaatiopelejä voidaan soveltaa periaatteessa minkä tahansa tyyppisen tuotteen kehitykseen. Innovaatiopelejä voidaan käyttää markkinointitutkimukseen, mutta pelejä voidaan myös soveltaa usein sellaisenaan vaatimuksien määrittelyyn. Innovaatiopeleissä pyritään saamaan asiakkaalta ideoita tuotteen ominaisuuksista ja rohkaisemaan asiakasta miettimään, mitä ominaisuuksia hän valmiilta tuotteelta odottaa. (Hohmann, 2006.) 4.1 Yleistä innovaatiopeleistä Miller ja Floricel (2004) esittelevät kolme eri tapaa käyttää innovaatiopelejä. Ensimmäinen on päästä edelle kehityksessä investoimalla tuotekehitykseen ja koettaa kehittää siten uusia markkinoita ja saada maine innovatiivisena yrityksenä. Toisena tapana on lisätä tuotelinjan arvoa lisäämällä olemassa oleviin tuotteisiin uusia ominaisuuksia. Kolmas vaihtoehto on kehittää uutta liiketoimintaa, vaikka se saattaisikin syödä vanhoja markkinoita. (Miller & Floricel, 2004.) Gray, Brown ja Macanufo (2010 s.10) vertaavat peliä näytelmään, joka koostuu kolmesta eri kohtauksesta. Ensimmäisessä näytöksessä tehdään näyttämö ja koetetaan saada osallistujat mahdollisimman avoimiksi mieleltään. Toisessa näytöksessä tutkitaan ja kokeillaan. Kolmannessa näytöksessä tehdään päätökset ja johtopäätökset. Kolmannessa näytöksessä katsotaan tehtyä työtä kriittisesti ja pohditaan, mitä voidaan toteuttaa ja mitä ei. Hohmann (2006) peilaa innovaatiopelejä laadulliseen markkinatutkimukseen ja esittelee neljä eri tapaa käyttää innovaatiopelejä. Ensimmäinen tapa on ohjattu markkinatutkimus. Siinä etsitään vastauksia ennalta määriteltyihin kysymyksiin tukemaan tuotteeseen tehtäviä muutoksia. Toinen tapa on asiakaskeskeinen innovointi, jossa pyritään löytämään uusia markkinoita. Kolmas tapa käyttää innovaatiopelejä on pyrkiä ymmärtämään asiakkaiden tarpeita. Neljäs tapa on hyödyntää innovaatiopelejä lujittamaan asiakassuhdetta. Markkinointitutkimuksen prosessi jaetaan Hohmannin

18 mukaan viiteen eri vaiheeseen. Nämä ovat kysymysten muodostus, datan tyypin selvittäminen, datan hankkiminen, datan analysointi ja toiminta. (Hohmann, 2006.) Markkinointitutkimuksen ensimmäisessä vaiheessa määritellään kysymykset ja mietitään, mitä vastauksilla tehdään. Suunnitelmien ei kuitenkaan tarvitse olla kovin tarkkoja vielä tässä vaiheessa. Toisessa vaiheessa suunnitellaan, minkälaista dataa asetettujen tavoitteiden saavuttamiseksi vaaditaan. Samalla kysymyksiä voidaan tarkentaa ja selkiyttää. Kolmannessa vaiheessa päätetään, mitä menetelmää datan keräämiseksi käytetään sekä laitetaan se käytäntöön. Neljännessä vaiheessa analysoidaan data. Viidennessä vaiheessa tehdään saadun datan ja analyysin perusteella päätökset tuotteeseen tehtävistä muutoksista. Nämä voivat vaihdella uuden tuotteen kehittämisestä päätökseen olla tekemättä mitään. (Hohmann, 2006.) Markkinointitutkimuksessa data määritellään ensisijaiseksi tai toissijaiseksi. Ensisijainen data vastaa suoraan määriteltyihin kysymyksiin. Toissijainen data on aikaisemmin kerättyä tai julkistettua dataa, joka ei vastaa kysymyksiin, mutta voi auttaa esimerkiksi markkinoiden koon määrittelemisessä. Ensisijaista dataa saa helpoimmin suoraan asiakkailta. (Hohmann, 2006.) Hohmann (2006) esittelee kirjassaan 12 innovaatiopeliä, joita hänen mukaansa voi hyödyntää markkinatutkimuksessa. Peleihin on annettu tietyt aloitustilanteet sekä säännöt, joiden mukaan pelejä pelataan. Hohmann esittää, että asiakkaat kutsutaan tilaisuuteen, joka voi kestää muutamia tunteja. Tilaisuudessa asiakkaat voidaan jakaa ryhmiin ja kukin ryhmä pelaa omaa peliään. Asiakkaat osallistuvat peliin erilaisin odotuksin ja mahdollisuuksin ottaa riskejä (Miller & Floricel, 2004). Tämä on hyvä ottaa huomioon ryhmiä jaettaessa. Järjestäjä saattaa ottaa tilaisuudessa valokuvia tai videota jälkiprosessoinnin helpottamiseksi. Lisäksi tilaisuudessa pitäisi Hohmannin mukaan olla tarkkailijoita, jotka tekevät havaintoja asiakkaista tarkkailukorteille pelin aikana. (Hohmann, 2006.) Jälkiprosessointi koostuu asiakkaan tekemien tuotosten, tarkkailijakorttien sekä videon ja kuvien tutkimisesta. Asiakkaan tekemät tuotokset käsittävät kaiken materiaalin, joka pelien yhteydessä on tehty. Materiaali vaihtelee kunkin pelin mukaan. Osa peleistä tuottaa materiaalia, joka voidaan näyttää suoraan kehitysryhmälle. Pelin aikana tarkkailijat kirjoittavat huomionsa korteille, joista kullakin tulisi olla vain yksi huomio. Jälkiprosessoinnissa kortit lajitellaan ja samaan asiaan viittaavat kortit asetetaan lähelle toisiaan. Tarvittaessa kortista voi tehdä kopion ja asettaa sen useampaan ryhmään. Mikäli useampi tarkkailija on huomannut saman asian, hävitetään muut saman seikan sisältävät kortit ja lisätään säilytettyyn korttiin numero, joka esittää, moniko tarkkailija huomasi asian. Kustakin ryhmästä voidaan tehdä yläkortti, joka sisältää pääasian. Lopuksi järjestäjä pyytää tarkkailijoilta seikat, jotka he nostaisivat tärkeimmiksi pelin lopputulokseksi. Hohmannin mukaan aikaa jälkiprosessointiin tulisi varata 40 työtuntia. (Hohmann, 2006.) Lopuksi valmistellaan kaksi raporttia, yrityksen sisäinen sekä asiakkaille jaeltava. Asiakkaille jaeltava raportti voi olla keveimmillään yhden sivun kooste asioista, jotka tulivat ilmi pelin aikana. Raskaimmillaan raportti voi sisältää tarkankin suunnitelman uusien seikkojen huomioon ottamisesta. Raportin tulisi kuitenkin kertoa asiakkaille, että heidän ideansa on otettu huomioon ja niitä on pohdittu. Sama raportti tulisi lähettää myös asiakkaan kanssa yhteistyössä oleville henkilöille yrityksen sisällä, jotta he tietävät saman kuin asiakkaatkin. (Hohmann, 2006.)

19 4.2 Prune the product tree Prune the product tree on innovaatiopeli, jossa pelaajien tehtävänä on poistaa ja lisätä oksia sekä lehtiä puuhun, joka esittää tuotetta. Lehdet esittävät tuotteen toiminnallisuuksia ja oksista muodostuu osakokonaisuuksia. Prune the product tree vaatii paljon esivalmisteluja, mutta se on skaalautuva eikä vaadi asiakkaan puolelta suurta valmistautumista. Tuloksena pelistä saadaan puu, joka esittää asiakkaan mielikuvaa seuraavan tuoteversion ominaisuuksista. (Hohmann, 2006.) Yksi tuotteen kehittämisen suurimmista ongelmista on saada oikea ja täydellinen kuva kaikesta, mitä on tehtävä. Tähän voidaan käyttää erilaisia verkkokuvioita, kuten roadmappeja. Roadmapit kuvaavat tuotteen kehityksen esimerkiksi aikajanalla (Garcia & Bray, 1997). Roadmap kuvaa tuotteen kriittiset pisteet ja auttaa aikatauluttamisessa määrittämällä mahdolliset vaihtoehtoiset reitit (Garcia & Bray, 1997). Prune the product tree antaa asiakkaalle paremman mahdollisuuden antaa palautetta tuotteesta ja muokata tuotteen ominaisuuksia kuin roadmap. Asiakkaan on myös helpompi tunnistaa puukuviosta tuotekokonaisuudet, jolloin työajan jakamisen perustelu on helpompaa. (Hohmann, 2006.) Peliin valmistaudutaan valitsemalla puun tyyppi. Hohmann (2006) antaa kuusi erilaista esimerkkiä puun tyypille. Nämä ovat kuusi, pensas, omenapuu, paju, mänty sekä tammi. Puun tyypin tulisi peilautua tuotteeseen. Mikäli kyseessä on uusi tuote, voidaan sitä kuvaamaan ottaa esimerkiksi nopeasti kasvava paju. Uudelle tuotteelle voidaan myös tehdä useampi vaihtoehtoinen runko. Jos taas kyseessä on vanhaan tuotteeseen lisättävä ominaisuus, voidaan ottaa puuksi jykevärunkoinen tammi. Ominaisuudet voivat olla valmiiksi määriteltyjä ja tulostettuja lehtiä, jotka asetellaan puun ulkopuolelle. Lisäksi uusien ideoiden saamiseksi on hyvä olla myös tyhjiä lehtiä. Tyhjien ja valmiiksi määriteltyjen lehtien suhde riippuu siitä, kumpaan suuntaan peliä halutaan painottaa. (Hohmann, 2006.) Puun piirtäminen voidaan tehdä käsin tai se voidaan tehdä tietokoneella. Puusta ei kuitenkaan saisi tehdä liian hienoa, sillä asiakkaat voivat olla tällöin haluttomia tekemään merkintöjä puuhun. Osallistujat jaetaan 5 10 hengen ryhmiin ja jokaiselle ryhmälle annetaan oma puu. Tuotteen valmiit ja jäädytetyt ominaisuudet kuvataan paksumpina oksina, ja uudet ominaisuudet ohuempina oksina sekä lehtinä. Puulle voidaan antaa useampi kasvukerros, esimerkiksi väreillä erotettuina, kuvaamaan ominaisuuksien ikää. Myös vanhempiin kasvukerroksiin voidaan laittaa ominaisuudet liimattavilla lapuilla, jolloin osallistujat voivat poistaa vanhoista ominaisuuksista ne, jotka eivät ole heille tärkeitä. (Hohmann, 2006.) Tulosten prosessointi tapahtuu tutkimalla puiden muokkausta. Poistettujen ominaisuuksien perusteella voidaan saada vinkkejä vähemmän tärkeistä ominaisuuksista ja niiden poistoa myös itse tuotteesta voidaan harkita. Puun muodosta voi päätellä, onko kaikkiin ominaisuuksiin kiinnitetty tarpeeksi huomiota. Mikäli asiakkaat ovat lisänneet johonkin oksaan paljon lehtiä, voidaan päätellä, että kyseiseen ominaisuuteen tulisi kiinnittää enemmän huomiota. Lehtien sijainnista voidaan päätellä, miten nopeasti asiakkaat haluavat uudet ominaisuudet käyttöönsä. Jos suuri osa lehdistä on lähellä runkoa, asiakkaat haluavat mahdollisesti nopeampia julkaisuja. (Hohmann, 2006.)

20 Prune the product tree -pelistä on olemassa myös variaatio Grow the product tree. Siinä pelaajat eivät poista lehtiä vaan ainoastaan lisäävät niitä. Grow the product tree on käytännöllinen, jos halutaan saada aikaan paljon uusia vaihtoehtoja. (Sahota, 2010,) 4.3 Remember the future Remember the future -pelissä asiakkaalle annetaan muistiinpanovälineet ja pyydetään asiakasta kuvittelemaan, että hän on käyttänyt tuotetta tietyn ajan kyseisestä hetkestä tulevaisuuteen. Asiakkaan tulisi kuvitella, miten tuote on tässä ajassa auttanut häntä. Kysymyksen asetteluun tulisi kiinnittää huomiota, jotta asiakkaalta saadaan hyödyllisiä vastauksia. Remember the future auttaa hahmottamaan asiakkaan odotuksia tuotteesta. Peli ei vaadi suuria valmisteluja etukäteen asiakkaan tai yrityksen puolelta. Silti peli on hyvin skaalautuva. (Hohmann, 2006.) Pelin valmisteluissa voidaan piirtää aikajana ja pyydetään osallistujia kuvittelemaan, että he ovat esimerkiksi kuukauden tulevaisuudessa. Tämän jälkeen heitä pyydetään muistelemaan, mitä he tekivät kaksi viikkoa sitten tuotteella. Riippuen pelin tavoitteesta aikajana voi olla kuukaudesta vuosikymmeneen. Suuren osallistujamäärän pelissä voi olla myös useampia kysymyksiä. Pelin pelaaminen tapahtuu rohkaisemalla osallistujia keskusteluun. Tämä voi tapahtua yksilökohtaisella tasolla kertomalla osallistujille, että he esittävät tulokset pelin lopuksi koko ryhmälle. Osallistujat voidaan jakaa myös ryhmiin, jolloin koko ryhmä työskentelee saman kysymyksen ääressä. Ryhmästä valitaan johtaja, joka vastaa tulosten taltioinnista sekä niiden esittelemisestä muille ryhmille. Keskusteluvaiheessa osallistujille annetaan muutama minuutti kertoa tuloksensa muille ja tämän jälkeen tuloksista keskustellaan kaikkien kesken. (Hohmann, 2006.) 4.4 Spider web Spider web voi auttaa huomaamaan uusia liiketoimintamahdollisuuksia esittämällä, miten asiakkaat näkevät yhteydet tuotteiden ja palveluiden kesken. Peliä pelataan laittamalla tuotteen nimi ympyrän keskelle. Asiakkaita pyydetään lisäämään valmiina olevan tuotteen ympärille palveluita sekä tuotteita, jotka heidän mielestään liittyvät päätuotteeseen. Samaan aikaan asiakkailta kysellään, miksi heidän mielestään näin on. Asiakkaita pyydetään yhdistämään paperilla olevat elementit toisiinsa viivoilla ja korostamaan esimerkiksi väreillä tärkeitä suhteita. Spider web -peli on skaalautuvuudeltaan keskiluokkaa. Lisäksi asiakkaiden täytyy käyttää hieman enemmän aikaa peliin valmistautumiseen kuin Prune the product tree tai Remember the future -peleissä. (Hohmann, 2006.) Spider web -peliin on otettu ideoita kontekstikaavio -vaatimusmäärittelytekniikasta. Kontekstikaavio -tekniikassa esitetään järjestelmän sisäisten ja ulkoisten osien vuorovaikutus toisiinsa nähden (Lauesen, 2002. s. 76). Kontekstikaaviolla saadaan päätettyä kehityksen aikaisessa vaiheessa, mitä ominaisuuksia sovellukseen otetaan ja mitä jätetään pois (Lauesen, 2002. s. 76). Siihen voi liittyä käyttäjiä, muita järjestelmiä, sensoreita ynnä muita vastaavia osia. Mikäli pelin ohjaaja on kokenut kontekstikaavion käyttäjä, hän saattaa pyrkiä ohjaamaan peliä liikaa omien oletuksiensa suuntaan. Ohjaajan tulisi pyrkiä olemaan mahdollisimman paljon vain tarkkailijana ja sivussa itse pelistä. (Hohmann, 2006.)

21 Peliin valmistautuminen aloitetaan miettimällä, mitä yhteyksiä asiakkaiden halutaan tutkivan. Näitä voivat olla yritysten väliset yhteydet, ympäristö, jossa tuotetta käytetään, eri tuotteiden väliset yhteydet, käyttäjien väliset yhteydet tai eri käyttäjäroolien väliset yhteydet. Asiakkaille voidaan antaa näistä tai itse mietittyjen yhteyksien listalta muutama vaihtoehto, joista valita. (Hohmann, 2006.) 4.5 Product box Product box -pelissä asiakasta pyydetään tekemään tuotteelle laatikko, jollaisen hän ostaisi esimerkiksi marketista tai messuilta. Asiakkaille annetaan pahvilaatikoita, joista heidän tulee tehdä tuotelaatikko. Kun laatikko on valmis, asiakkaita pyydetään myymään tuote muille peliin osallistuville. Asiakkaiden myydessä tuotetta sen tekijälle he kiinnittävät huomiota ongelmiin, jotka tuotteen tulisi heidän mielestään ratkaista. Koska tilassa on muitakin asiakkaita, voi heidän toimintansa antaa vinkkejä, mitä mieltä he ovat kyseisistä asioista. Product box vaatii paljon esivalmisteluja, mutta asiakkaan ei tarvitse juuri valmistautua ennakkoon. Product box on myös hyvin skaalautuva. (Hohmann, 2006.) Ostotilanteessa asiakas haluaa uskoa, että tuote ratkaisee hänen ongelmansa. Kyseessä ei ole pelkästään ongelmat, jotka myyjä kertoo tuotteen ratkaisevan, vaan myös asiakkaan todelliset ongelmat. Kun asiakas myy tuotteen takaisin sen tekijälle, hän kertoo, mitä todella odottaa tuotteelta. Myyntitilanteessa kannattaa myös tarkkailla muiden peliin osallistujien reagointia. Muiden osallistujien reaktioista voidaan huomata asioita, jotka ovat myös yleisimmin tärkeitä, ja tuotteen kehityksessä voidaan ottaa ne huomioon. (Hohmann, 2006.) Peliin valmistautumiseen täytyy varata paljon aikaa. Pelaajat tarvitsevat tuotelaatikon tekoon liimaa, tusseja ja mahdollisesti muita tarvikkeita. Työskentelypöydät on hyvä suojata esimerkiksi paperilla. Pelaajille voidaan myös antaa mahdollisuus suunnitella laatikko paperille ennen oikean laatikon tekoa. Suunnitelmat voi säästää analysointivaihetta varten. Itse laatikon tulisi olla suhteellisen iso. Hohmann suosittelee käyttämään 30.5x12.7x33cm (12x5x13 tuuman) valkoista laatikkoa. Laatikon ei kuitenkaan tulisi olla paljoa suurempi, sillä yhtenä pelin ajatuksena on rajoittaa käytössä olevaa tilaa. Laatikoita tulee hankkia tarpeeksi, jotta niitä on kaikille sekä muutama ylimääräinen. Lisäksi peliin tulisi tuoda muutama valmis tuotelaatikko toimimaan esimerkkinä. Näitä voivat olla murolaatikot, jogurttien pahvit tai vanhat kuluttajaluokan ohjelmistojen laatikot. (Hohmann, 2006.) 4.6 Buy a feature Buy a feature -peli auttaa hahmottamaan, mitkä ominaisuudet tuotteeseen on laitettava, jotta asiakkaat ostaisivat tuotteen tai päivittäisivät sen uuteen versioon. Pelissä luodaan ennakkoon lista ominaisuuksista ja annetaan asiakkaille tietty määrä rahaa käytettäväksi ominaisuuksien ostoon. Osa ominaisuuksista voi olla hinnoiteltu niin korkealle, että yksi asiakas ei voi ostaa kyseistä ominaisuutta. Tällöin useamman asiakkaan on pistettävä rahat yhteen ominaisuuden ostoa varten. Tämä lisää keskustelua asiakkaiden kesken ja voi antaa kehittäjälle paremman kuvan asiakkaiden tarpeista. Buy a feature vaatii paljon ennakkovalmisteluja ja asiakkaan tulisi valmistautua peliin samassa määrin kuin Spider web peliin. Buy a feature on hyvin skaalautuva peli. (Hohmann, 2006.)

22 Buy a feature auttaa asiakasta laittamaan tuotteeseen ehdotetut ominaisuudet tärkeysjärjestykseen. Asiakkaalla ei välttämättä ole suunnitteluvaiheessa oikeaa käsitystä omista tarpeistaan. Jos kehittäjä esittää listan ominaisuuksista, voi tuloksena olla, että asiakas haluaa ne kaikki. Tällöin ominaisuuksien priorisointi jää kehittäjän tehtäväksi. (Hohmann, 2006.) Peliin valmistautumisen eniten aikaa vievä osa on ominaisuuksien listaaminen ja hinnoittelu. Liian lyhyt lista ominaisuuksia vie pelistä mielenkiinnon ja liian pitkä pitkittää peliä tarpeettomasti. Hohmann suosittelee peliin otettavaksi 14 30 ominaisuutta. Jokainen ominaisuus nimetään kuvaavasti. Lisäksi ominaisuudesta kerrotaan lyhyt kuvaus ja lista eduista. Ominaisuuksista tulisi karsia sellaiset, jotka on jo päätetty lisätä tuotteen seuraavaan versioon. Kannattaa suosia sellaisia ominaisuuksia, jotka voidaan lisätä tuotteeseen seuraavien 1 3 kehityssyklin aikana. Ominaisuuksien hinnoittelussa voidaan käyttää apuna todellisia kuluja. Hintoja voidaan kuitenkin muokata vastaamaan tuotteelle asetettuja odotuksia ja kehittäjien vahvuuksia. Pienitöinen ominaisuus, jota ei nähdä tärkeäksi tuotteen kannalta, voidaan hinnoitella korkeammalle kuin sen työmäärä edellyttäisi. Vastaavasti suuritöinen ominaisuus, joka on tärkeä osa tuotetta, voidaan hinnoitella halvemmaksi. (Hohmann, 2006.) Ominaisuuksien hinnoittelun jälkeen päätetään, paljonko rahaa asiakkaille annetaan käyttöön. Pelin tarkoitus on lisätä asiakkaiden välistä kommunikaatiota jakamalla summa sopivasti asiakkaiden kesken. Hohmann suosittelee, että asiakkaille jaettavan summan tulisi riittää 30 60 prosenttiin listatuista ominaisuuksista. Yksittäinen asiakas ei kuitenkaan saa pystyä ostamaan liian montaa ominaisuutta. Jos asiakkaan organisaatio haluaa lähettää peliin useamman kuin yhden edustajan, on rahan jakaminen mietittävä eri lailla. Rahat voidaan jakaa organisaatiokohtaisesti. Tämä kuitenkin voi vaikeuttaa pelin kulkua, koska jokainen ryhmä keskustelee eniten keskenään. Saman organisaation edustajat voidaan jakaa eri ryhmiin. Tällöin he keskustelevat omien etujensa mukaisesti, mutta eivät saa tukea ryhmän sisältä. Pelaajille jaettavaa rahamäärää voidaan muuttaa pelaajakohtaisesti. (Hohmann, 2006.) 4.7 Start your day Start your day auttaa hahmottamaan, milloin ja miten asiakkaat käyttävät tuotetta. Tuotteella saattaa olla erilaisia funktioita riippuen päivän tai vuoden ajasta. Peliä pelataan tekemällä isokokoinen kalenteri ja pyytämällä asiakkaita lisäämään kalenteriin tapahtumat, jotka liittyvät tuotteeseen. Tämän tulisi auttaa kehittäjää näkemään, miten tuote vaikuttaa asiakkaiden päivään. Start your day auttaa saamaan tuotteen käytöstä paremman kuvan kuin suoraan kysymällä. Kun asiakkaat tekevät merkintöjä kalenteriin, he tekevät samalla merkintöjä eri käyttötilanteista. Start your day vaatii paljon esivalmisteluja ja asiakkaan valmistautumista vaaditaan saman verran kuin Buy a feature tai Spider web -peleissä. Pelin skaalautuvuus on keskiluokkaa. (Hohmann, 2006.) Peliä pelataan antamalla pelaajille ennakkoon tulostetut kalenterit tai levittämällä iso paperi seinälle. Pelaajia pyydetään kuvailemaan paperille tapahtumat, joissa he käyttävät tuotetta. Näin pelaajat miettivät tuotteen käyttöä pidemmältä ajalta kuin vain viimeisimmän käyttökerran perusteella. Samalla pelissä saadaan selvitettyä, minkälaisissa yhteyksissä tuotetta käytetään. (Hohmann, 2006.)

23 Peliin valmistautuminen aloitetaan miettimällä, ketä asiakkaita peliin kutsutaan. Peliin kannattaa pyrkiä kutsumaan asiakkaita, joiden oletetaan käyttävän tuotetta erilaisissa tilanteissa ja eri aikaan päivästä. Tämä saattaa myös vaikuttaa siihen, minkälainen kalenteri pelaajalle kannattaa antaa. Eri pelaajien tekemiä merkintöjä voidaan seurata esimerkiksi antamalla jokaiselle asiakkaalle erivärinen kynä. (Hohmann, 2006.) Ennen pelin aloittamista osallistujille annetaan hetki aikaa miettiä, miten he käyttävät tuotetta. Tämän jälkeen asiakkaita pyydetään tutustumaan seinälle tulostettuihin kalentereihin, jotta he voivat päättää, minkälaista aikajaksoa he haluavat tarkastella. Kalenterit voivat olla tulostettuna esimerkiksi viikko-, kuukausi- tai vuosijaksoille. Kun osallistujat ovat lopettaneet merkintöjen tekemisen, pidetään 15 minuutin tauko ja kalenterit valokuvataan. Lopuksi pelin järjestäjä käy tulokset läpi ja rohkaisee osallistujia keskustelemaan. (Hohmann, 2006.) 4.8 Show and tell Show and tell -pelissä asiakasta pyydetään tuomaan jokin tuotteella tuotettu asia peliin. Tämä voi olla esimerkiksi ohjelmalla tuotettu dokumentti. Pelin aikana asiakas kertoo tuomastaan asiasta. Asiakkaan tulisi kertoa, miten asiaa on muokattu tuotteella ja miten tuotetta on käytetty. Kehittäjän tulisi kiinnittää huomiota tuotteen erikoiseen käyttöön, onko tuotteen jotakin ominaisuutta jätetty käyttämättä ja mihin tuotetta on ylipäätään käytetty. Show and tell vaatii asiakkaalta sekä kehittäjältä paljon valmistautumista eikä se ole kovin skaalautuva. (Hohmann, 2006.) Peliin valmistautuminen vaatii paljon työtä asiakkaalta. Tämän takia pelistä tulisi tiedottaa etukäteen ja antaa tarkat ohjeet, mitä osallistujien odotetaan tuovan. Asiakkaalta tulisi myös ajoissa kysyä, voiko järjestäjä pitää esiteltävät materiaalit, jotta tämä ei tule yllätyksenä. Järjestäjän on hyvä tuoda esimerkki kaikesta, mitä tuote pystyy tuottamaan. Tällöin voidaan kysyä asiakkaalta, miksi hän ei käytä tiettyä ominaisuutta, jos sitä ei ole asiakkaan tuomissa materiaaleissa. (Hohmann, 2006.) 4.9 Me and my shadow Me and my shadow -pelissä kehittäjä seuraa asiakkaan tuotteen käyttöä välillä kysellen, miksi hän tekee asiat, kuten tekee. Pelissä voi olla myös useampia asiakkaita ja muut asiakkaat kertovat, mitä tuotetta käyttävä asiakas tekee. Lisäksi muilta asiakkailta voi kysellä, tekisivätkö he asiat samoin kuin kyseinen asiakas. Me and my shadow vaatii keskinkertaisen määrän ennakkovalmisteluja, mutta asiakkaan on valmistauduttava hyvin peliin. Peli ei ole kovin skaalautuva. (Hohmann, 2006.) Tämä peli hyödyntää etnografista tutkimusta. Etnografinen tutkimus on alkujaan kulttuuriantropologiasta (Myers, 1999). Ongelmana etnografisessa tutkimuksessa on, miten olla vaikuttamatta seurattavan kohteen työskentelyyn (Myers, 1999). Paras paikka seuraamiseen on asiakkaan normaali työskentelytila. Erillinen huone on mahdollinen, mutta se on kallis kalustaa ja voi vaikuttaa asiakkaan käyttäytymiseen. Peliin valmistautuminen vaatii myös tarkkuutta johtuen yksityisyyden ja tietoturvan vaatimuksista. Peli kestää usein myös kauemmin kuin muut innovaatiopelit ja voi maksaa enemmän. (Hohmann, 2006.)

24 4.10 Give them a hot tub Give them a hot tub -peli noudattelee aivoriihen periaatteita. Näitä ovat kriittisyyden pois jättäminen, mahdollisimman villien ajatusten heitteleminen, ideoiden määrän maksimoiminen sekä ideoiden kehittäminen eteenpäin (Isaksen, 1998). Asiakkaiden kesken käydään läpi ideoita, jotka on kirjoitettu paperilapuille. Ideoiden joukkoon laitetaan sellaisia ideoita, joita ei käytännössä ole mahdollista toteuttaa kyseisessä tuotteessa. Kun asiakas huomaa tällaisen idean, hän alkaa pohtia, miten ideaan pitäisi suhtautua. Asiakas voi hylätä idean heti, aivan kuin sitä ei olisi pelissä ollenkaan tai hän alkaa sovittaa ideaa tuotteeseen. Tällöin voi tulla yllättäviäkin lopputuloksia. Give them a hot tub vaatii vähäisen määrän esivalmisteluja, eikä asiakkaan tarvitse valmistautua kovin tarkkaan. Skaalautuvuudeltaan peli on keskiluokkaa. (Hohmann, 2006.) Omituinen ominaisuus tekee asiakkaan vaivautuneeksi. Tämän takia hän pyrkii alitajuisesti pääsemään eroon tunteesta. Yleisin tapa on olla piittaamatta ominaisuudesta, mutta joskus asiakas voi pyrkiä muuttamaan ominaisuutta tuotteeseen sopivaksi. Tässä prosessissa voi tulla innovaatioita, joita ei muuten tulisi edes ajateltua. (Hohmann, 2006.) Peliin valmistautuminen kestää vähintään kahden kokouksen ajan. Ensimmäinen kokous on lämmittelykokous, jossa päätetään alustavasti omituiset ominaisuudet. Ominaisuudet päätetään tekemällä ensin lista ominaisuuksista, joita tuotteeseen on suunnitteilla. Kokouksien välillä on hyvä pitää parin päivän tauko, jonka aikana osallistujilla on aikaa miettiä omituisia ominaisuuksia. Kokousten lopputuloksena on lista, jota käytetään pelissä. Ominaisuuksien täytyy kuitenkin olla sellaisia, että ne ovat sovitettavissa tuotteeseen. Jos ne ovat liian hankalia, asiakkaat hylkäävät ne välittömästi. (Hohmann, 2006.) 4.11 The apprentice The apprentice -pelissä kehitysryhmä lähtee tekemään kohderyhmän työtä heidän kanssaan. Työnteon yhteydessä kehitysryhmä saa hyvän kuvan asiakkaan kohtaamista ongelmista. Kehitysryhmän tulee työskennellä asiakkaan kanssa kahdesta päivästä viikkoon. The apprentice vaatii asiakkaalta ja kehittäjältä paljon valmistautumista. Peli ei ole kovin skaalautuva. (Hohmann, 2006.) The apprentice kestää kauemmin kuin useimmat pelit. Aikaväli voi vaihdella parista päivästä pariin viikkoon. Aikaa menee kohderyhmän työhön perehtymiseen ja eri työvaiheisiin tutustumiseen. Pelin pelaaminen tapahtuu kohderyhmän työpaikalla. Pelaajat tulevat tuotetta kehittävästä yrityksestä ja heitä tulee neuvoa tekemään paljon kysymyksiä pelin aikana. Pelaajien olisi myös hyvä pitää päiväkirjaa pelin aikana. Lyhyet päivittäiset kokoukset ovat mahdollisia. Näihin kokouksiin voidaan kutsua myös asiakkaan edustajia, jolloin he voivat korjata mahdolliset väärinymmärrykset. (Hohmann, 2006.) 4.12 20/20 vision 20/20 vision -pelissä tuotteen ominaisuudet kirjoitetaan jokainen omalle kortilleen. Kortit sijoitetaan väärinpäin pöydälle. Tämän jälkeen kortit nostetaan yksi kerrallaan seinälle ja pyydetään asiakasta vertaamaan nostettua ominaisuutta jo seinällä oleviin

25 ominaisuuksiin. Ominaisuus sijoitetaan seinälle sopivalle korkeudelle sen mukaan, miten asiakas arvostaa kyseistä ominaisuutta. Kun kaikki ominaisuudet on käyty läpi, saadaan priorisoitua tuotteen ominaisuudet. Asiakkaalle priorisointi on helpompaa, koska hän saa paremman käsityksen myös tuotteen muista ominaisuuksista. (Hohmann, 2006.) Peliin valmistautuminen tapahtuu valitsemalla 8 20 ominaisuutta ja kirjoittamalla ne kukin omalle kortille. Kortin toiselle puolelle kirjoitetaan, mitä se tuo lisää tuotteeseen. Korttipakkoja tehdään kolmesta neljään. Kullekin kortille tehdään yksinkertainen luonnosten joukko. Joukko saa arvot matalasta korkeaan. Jos tuotteena on esimerkiksi keittiökello ja tavoitteena päättää kotelon materiaalit, suunnittelujoukon alkiot voivat olla matalasta korkeaan: muovi, alumiini ja ruostumaton teräs. Suunnittelujoukot auttavat pelin pelaamisessa, sillä asiakkaat voivat kysellä, miten suunnittelu vaikuttaa muiden ominaisuuksien toteuttamiseen. Peliä kannattaa pelata ensin yrityksen sisällä, jotta tekniikka tulee tutuksi ja tuotekehityksen omat prioriteetit tulevat selviksi. (Hohmann, 2006.) Pelissä pari ensimmäistä ominaisuutta ovat yleensä nopeasti priorisoituja. Kun ominaisuudet taululla lisääntyvät, peli hidastuu ja asiakkaat alkavat väitellä enemmän ominaisuuksien paikasta. Pelin ohjaajan tehtävä on rohkaista väittelyä. Pelissä tulisi välttää ominaisuuksien liittämistä yhteen siten, että useampaa ominaisuutta muutetaan aina samoin. Pelaajat voivat haluta myös yhdistää useamman ominaisuuden yhdeksi tai jakaa yhden useammaksi. Tämä on yleensä hyväksi pelin kululle, sillä ne antavat tietoa asiakkaan tarpeista. Pelin ohjaajan tulisi päättää ominaisuuksien muokkaamisesta. (Hohmann, 2006.) 4.13 Speed boat Speed boat -pelissä asiakasta pyydetään tunnistamaan tuotteessa ominaisuudet, joista he eivät pidä. Pelissä piirretään taululle moottorivene, joka kuvaa tuotetta. Asiakkaita pyydetään lisäämään veneeseen ankkureita, jotka ovat ei-toivottuja ominaisuuksia. Ankkurit kuvataan paperilapulle ja lapulle voidaan myös laittaa arvio, miten paljon nopeampaa vene kulkisi ilman ankkuria. Muiden lisäämiin ankkureihin voidaan lisätä huomautuksia, mikäli muut asiakkaat ovat samaa mieltä. Kun kaikki ankkurit on lisätty, asiakkaita pyydetään selittämään tarkemmin, mitä he ovat ankkureilla tarkoittaneet. (Hohmann, 2006.) Speed boat antaa asiakkaille mahdollisuuden kertoa hallitusti, mistä seikasta he eivät pidä tuotteessa. Pelin tavoitteena on antaa kullekin asiakkaalle henkilökohtainen mahdollisuus antaa palautetta. Mikäli kokous hoidetaan suullisesti, on mahdollista, että joku asiakkaista hallitsee liikaa keskustelua tai keskustelu menee liikaa tuotteen sättimiseen. (Hohmann, 2006.) Peliin valmistautumisessa tulisi tehdä parhaansa, jotta peli pysyy mahdollisimman leikkimielisenä. Pelialustaa voidaan koristella veneen kuvilla sekä esimerkiksi kalatarroilla. Merkintäkortteihin voidaan tulostaa ankkurin kuva ja niin edelleen. Peliin tulisi pyrkiä kutsumaan asiakkaita, jotka eivät ole liian dominoivia tai negatiivisia. Jos tällaisia asiakkaita on tulossa peliin, voi olla hyödyksi pitää kaksi erillistä pelitilannetta, toinen hiljaisemmille asiakkaille ja toinen dominoiville. (Hohmann, 2006.)

26 Pelaaminen aloitetaan pelin esittelyllä. Tämän jälkeen osallistujille annetaan muutama minuutti miettimiseen. Jos osallistujat eivät lisää ankkureita taululle, voi pelin vetäjä pyytää joltakin muutamaa ankkuria ja laittaa ne itse taululle. Ankkureiden lisäämiseen ei tule antaa vuoroja, vaan osallistujat saavat laittaa ne taululle silloin kun haluavat. Ankkureiden lisäämisen loputtua pelin vetäjä käy läpi kaikki ankkurit. Tämä viestii osallistujille, että heidän antamansa palaute on tärkeää. Kaikki osallistujat saavat osallistua keskusteluun kaikista ankkureista. Järjestäjän ei tulisi puolustella tai yrittää ratkaista ongelmaa. Hän ainoastaan yrittää ymmärtää, miten ankkuri hidastaa asiakkaita. Samankaltaisia ongelmia sisältäviä ankkureita voi käsitellä ryhmissä prosessin nopeuttamiseksi. (Hohmann, 2006.)

27 5. Innovaatiopelien käyttö vaatimusmäärittelyssä ketterässä Yritysten saadessa lisää henkilöstöä tuotekehitykseen on yhden yrityksen vaikea pysyä kilpailijoiden edellä innovaatiossa. Mahdollisuutena on yhteistyön tekeminen kilpailijoiden kanssa tai tuotekehityksen ulkoistaminen. Avoimet ja interaktiiviset ohjelmistomallit ovat nopean innovaation ytimessä. Avoimet ohjelmistomallit mahdollistavat jatkuvan pääsyn ajantasalla olevaan tietoon. Mallit tarjoavat myös määritellyt rajapinnat, joiden avulla ulkoiset suunnittelijat voivat työskennellä itsenäisesti. (Quinn, 2000.) Ohjelmistotalojen elinkelpoisuus korkean elintason maissa voi olla kiinni kyvystä luoda arvostettuja tuotteita tiiviissä yhteistyössä asiakkaan kanssa (Aen, 2008). Innovaatiopelit on alunperin tarkoitettu markkinatutkimuksen tekoon, mutta ne sopivat myös korkean tason vaatimusten määrittelyyn. Esimerkiksi Prune the product tree -pelissä pelaajat tekevät ominaisuuspuun lisäämällä ja poistamalla ominaisuuksia tuotteesta mieltymystensä mukaan. Toinen peli, jota voisi käyttää suhteellisen suoraan apuna vaatimusmäärittelyssä voisi olla Buy a feature. Buy a feature auttaa priorisoimaan sovelluksen ominaisuudet, jotka asiakkaat haluavat seuraavaan tuotteen versioon. Spider web -innovaatiopeli on saanut vaikutteita vaatimusmäärittelymenetelmästä nimeltään context diagramming (Hohmann, 2006). De la Barra ja Crawford (2007) ennakoivat luovan ajattelun tärkeyden korostuvan seuraavan vuosikymmenen aikana. He esittävät kysymyksen, kuuluuko keksiminen vaatimusmäärittelyprosessiin ja kenen se tulisi tehdä. Asiakas ei välttämättä tunne omia tarpeitaan tarpeeksi hyvin. Suunnittelija näkee tehtäväkseen tehdä mahdollisimman hyvä suunnitelma annettuja vaatimusmäärittelyjä vastaan. Ohjelmoijat ovat monesti liian kaukana asiakkaasta ymmärtääkseen asiakkaan vaatimukset syvällisemmin. Vaatimusmäärittely on ideaalisin vaihe keksimiselle, sillä vaatimusmäärittelijät ovat lähellä asiakasta. Heillä on tuntemusta sekä asiakkaan liiketoiminta-alasta että tekniikasta. Vaatimusmäärittelijöitä syytetään, jos projekti ei miellytä asiakasta. Vaatimusmäärittelijät pystyvät myös kertomaan parhaiten, onko keksinnöstä apua asiakkaalle. (de la Barra & Crawford, 2007.) Essence menetelmässä pyritään hyödyntämään ketterien menetelmien periaatteita kuten inkrementaalista kehitystä, alhaista byrokratiaa ja asiakkaiden sekä kehittäjien käyttämistä samassa kehitystiimissä (Aaen, 2010). Tehokkaiden vaatimusmäärittelykokousten vetäminen voi osoittautua vaikeaksi. Ongelmiksi voivat nousta heikko kommunikaatio, toisten osallistujien huomioon ottamattomuus (lack of empathy with other stakeholders) tai huono kokouksen ennakkosuunnittelu. Ratkaisuksi Mahaux ja Maiden (2008) ehdottavat muun muassa seuraavia improvisaatioteatterin ohjaajien käyttämiä keinoja. Osallistujat eivät saisi kieltää tai väittää vastaan mihinkään, mitä heille sanotaan. Osallistujien tulisi pyrkiä viemään aina kohtausta eteenpäin. Informaatiota, jota jaetaan eteenpäin, tulisi käsitellä kuin lahjaa. Jos saat jotakin, anna jotakin eteenpäin. Pidä hauskaa kohtauksen tekemisessä. (Mahaux & Maiden, 2008.)

28 Luovassa ohjelmistokehityksessä tulisi de la Barran ja Crawfordin (2007) mukaan lisätä rooleja luovaan projektiryhmään. Roolit ovat samansuuntaisia kuin Hohmannin (2006) esittelemät roolit innovaatiopelien toteutuksessa, vaikkakin rooleja on enemmän kuin Hohmannin esittelemät. Projektiryhmään tulevat roolit ovat etsivä, tutkija, taiteilija, insinööri, tuomari ja tuottaja. Etsivän vastuulla on etsiä ja koota mahdollisimman paljon tietoa käsillä olevasta ongelmasta. Etsivä ei saisi tehdä oletuksia kokoamistaan tiedoista, vaikka ymmärtäisikin ongelman. Tutkija tutkii, mitä ongelma-alueella ja sen kontekstissa voi tapahtua jatkossa. Tutkija selvittää, mitä pitkän aikavälin vaikutuksia ongelmalla on. Taiteilija muokkaa muiden keräämiä tietoja uusiksi ideoiksi. Insinööri tutkii uudet ideat ja arvioi niiden toteutuskelpoisuuden. Tuomari tekee ideoista hierarkian ja päättää, mitkä toteutetaan ja mitkä hylätään. Tuomarin tulisi myös huomata mahdolliset virheet ideoissa ja hallita riskit. Tuottaja implementoi ideat. (de la Barra & Crawford, 2007.) Toisaalta Aaen (2010) ehdottaa vain kolmea roolia vaatimusmäärittelyyn. Nämä ovat ankkuri, haastaja ja vastaaja. Haastaja on asiakkaan rooli. Asiakas tarjoaa haasteita ryhmälle esittämällä vaatimuksia. Vastaaja vastaa haasteisiin ja pyrkii ylittämään asiakkaan odotukset. Ankkuri pitää yllä luovaa prosessia. Lisäksi on olemassa lapsen rooli, jonka kautta voidaan esittää omituisia ideoita tai kritiikkiä asioiden etenemisestä. (Aaen, 2010.) Extreme Programming -menetelmässä määritellään seuraavat roolit kehitysryhmässä: ohjelmoija, asiakas, testaaja, mittaaja, valmentaja, konsultti sekä johtaja. Jotta Extreme Programming -menetelmästä saadaan enemmän luovuutta tukeva, voidaan valmiiksi määriteltyihin rooleihin yhdistää luovuutta tukevat roolit. de la Barra ja Crawford (2007) jakavat roolit kahteen eri kategoriaan: perusroolit ja tukiroolit. Etsivän rooli on asiakkaalla, sillä asiakas ottaa ensimmäisen yhteyden kehitysryhmään. Tutkijan rooli jakautuu asiakkaan ja kehitysryhmän johtajan välille. He vastaavat ongelman tunnistamisesta ja mahdollisten ratkaisujen etsimisestä. Taiteilijan rooli on kehittäjällä, jonka vastuulla on analysointi, suunnittelu ja ohjelmointi. Tuomarin rooli on mittaajalla ja asiakkaalla. Tuottajan rooli on asiakkaalla. (de la Barra & Crawford, 2007.) Tukevat roolit ovat haastaja, ajatusmylly, fasilitaattori ja manageri. Haastaja pyrkii tuomaan esille erilaisia näkökantoja ideoihin ja siten auttamaan luovaa prosessia. Ajatusmylly (the think tank) on konsultin rooli, joka auttaa kehitysryhmää ulkopuolisena asiantuntijana. Fasilitaattori on valmentajan rooli, joka avustaa ryhmää. Manageri johtaa ryhmää ja pyrkii takaamaan kehitystyön tehokkuuden. Manageri vastaa Extreme Programming -menetelmän johtajaa. (de la Barra & Crawford, 2007.) Baskerville et al (2003) käsittelevät artikkelissaan Internetsovellusten kehittämistä. Internetsovelluksien kehittäminen on ongelmallista, sillä markkinoille on usein kiire ja kilpailua voi olla perinteisiä markkinoita enemmän. Tästä johtuen kehittäjät saattavat joutua toteuttamaan sovellusta jo ennen kuin he ymmärtävät kunnolla vaatimusmäärittelyjä. Artikkelissa todetaan, että Internet-Speed -käytännöt ovat sovellettuja käytäntöjä ketteristä kehitysperiaatteista. On tärkeää olla hyvässä suhteessa asiakkaaseen, sillä hyvä kommunikointi nopeuttaa epäselvien ja epävarmojen vaatimusten selventämisessä. Asiakkaiden työskentely tulisi artikkelin mukaan siirtää kehitteillä olevaan järjestelmään, jotta kehityssykliä saisi lyhennettyä. (Baskerville et al, 2003.) Eberleim ja do Prado (2002) esittävät, että vaatimusmäärittelyssä pitäisi ottaa huomioon ero käyttäjän ja asiakkaan välillä. Asiakas ei välttämättä ole loppukäyttäjänä tehtävässä järjestelmässä. Ketterissä menetelmissä asiakas antaa monesti palautetta prototyypistä.

29 Olisi huomattava, että yksi henkilö ei usein pysty antamaan kaikkia ohjelmiston vaatimuksia. Esimerkiksi loppukäyttäjä ei välttämättä ole tietoinen kaikista turvallisuusmääräyksistä, jotka kehitettävää järjestelmää koskevat. (Eberleim & do Prado, 2002.) Innovaatiopelit sisältävät elementtejä, joita voitaisiin mielestäni käyttää esimerkiksi de la Barran ja Crawfordin (2007) esittelemässä menetelmässä. Asiakas on menetelmässä keskeisessä roolissa. Innovaatiopelit sisältävät keinoja, joilla asiakas saadaan miettimään tarkemmin omia tarpeitaan kehitettävän järjestelmän osalta. Aalborgin yliopiston tietojenkäsittelytieteen laitos on kehittänyt Essence metodin. Essence laajentaa ketteriä menetelmiä tukemaan paremmin innovaatiota (Aaen, 2008). Essencestä pyritään tekemään kevyt, helppo ja hauska käyttää (Aaen, 2008). Essenceen on otettu vaikutteita roolipeleistä ja siihen liittyvät pelit ovat saaneet vaikutteita Hohmannin innovaatiopeleistä (Aaen, 2008). Ongelmia tuottaa mielestäni lähinnä innovaatiopelien suhteellisen raskas prosessi, kun taas ketterässä kehityksessä asiakkaan ongelmat olisi hyvä saada selville mahdollisimman nopeasti. Jos asiakkaalle annetaan tehtäväksi ennakkoon miettiä järjestelmän ominaisuuksia, ei voida olla varmoja, että kyseiset ominaisuudet todella ovat tarpeellisia. Asiakkaallakaan ei välttämättä ole selkeää käsitystä siitä, mitä järjestelmältä odottaa. Innovaatiopelien sovittamiseksi ketteriin menetelmiin sopivaksi niitä tulisi kehittää kevyemmiksi. Jo jälkiprosessointia vähentämällä innovaatiopeleistä saataisiin huomattavasti kevyempi menetelmä. Ongelmaksi saattaa tulla tässä tilanteessa pelin antamien tulosten väheneminen. Toisaalta mielestäni vaatimusmäärittelyssä innovaatiopelejä ei tarvitse analysoida yhtä tarkasti kuin markkinointitutkimuksessa. Asiasta ei kuitenkaan ilmeisesti ole vielä tutkimusta tehty.

30 6. Tutkimusmenetelmät Tietojenkäsittelytieteen tutkimusta hallitsee kaksi eri paradigmaa. Käyttäytymistiede ja suunnittelutiede. Käyttäytymistiede pyrkii kehittämään ja varmistamaan teorioita, jotka ennustavat tai selittävät ihmisten ja organisaatioiden käyttäytymistä. Käyttäytymistieteen juuret ovat luonnontieteellisissä metodeissa. Suunnittelutiede pyrkii laajentamaan ihmisten ja organisaatioiden kykyjä luomalla uusia ja innovatiivisia artefakteja. Suunnittelutieteellisen tutkimuksen täytyy täyttää kaksi kriteeriä ollakseen validi (Kueshler, Vaishanvi, 2008). Tutkimuksen taustan täytyy olla suunnittelutieteellinen ja tutkimuksen täytyy osoittaa yhteydet tutkimustieteellisiin perusteorioihin, mid-range teorioihin ja artefaktin kehittämiseen (Kueshler, Vaishanvi, 2008). Suunnittelutieteessä tieto hankitaan tekemällä artefakti ja sen juuret ovat insinööritieteissä. (Hevner, March, Park, Ram, 2004.) Suunnittelutiede tietojenkäsittelytieteessä pyrkii luomaan ja evaluoimaan ohjelmistoa sekä algoritmeja ja siten ratkaisemaan ongelmia. Tuloksen laajempi analysointi voidaan tehdä empiirisillä tai laadullisilla metodeilla. Suunnittelutieteellinen metodi koostuu kahdesta eri vaiheesta. Ne ovat artefaktin rakentaminen ja evaluointi. Tavoitteena on tehdä toimiva työkalu ja saada tietoa kehittämisprosessin yhteydessä. Kokeilu ja erehdys on alussa yleistä. Tutkimuksen alkuvaiheessa voidaan luoda useitakin kokeiluja ennen lopullisen artefaktin kehittämisen aloittamista. Innovaatio on tärkeässä roolissa onnistuneessa suunnittelutieteellisessä tutkimuksessa (Kasanen, Lukha, Siitonen, 1993). Ilman innovaatiota tutkija ei pysty kehittämään uutta ratkaisua kyseessä olevaan ongelmaan (Kasanen et al, 1993). Suunnittelutieteen kaksi perustavaa kysymystä ovat Minkä työkalun uusi artefakti tarjoaa? ja Miten työkalu demonstroidaan?. (Hevner et al., 2004.) Hevner et al. (2004) esittelevät seitsemän ohjenuoraa käytettäväksi tietojenkäsittelytieteen suunnittelutieteessä. Nämä ohjenuorat ovat 1) tuotos on artefakti, 2) ongelman on oltava relevantti, 3) artefaktin evaluointi, 4) tutkimuksen hyödyllisyys, 5) tutkimuksen perusteellisuus, 6) suunnitelma tutkimusprosessina ja 7) tutkimuksen kommunikointi. 1) Tuotos on artefakti. Suunnittelutieteellisen tutkimuksen lopputulos on määritelmän mukaan hyödyllinen artefakti. Järvinen ja Järvinen (2000) mukaan suunnittelutieteen artefakti voi olla käsitteistö, malli, metodi tai realisointi. Kokeellisesta tutkimuksesta tulisi kuvailla kolme elementtiä (Kitchenham, Pfleeger, Pickard, Jones, Hoaglin, El-Emam & Rosenberg, 2002). Kuvataan taustatiedot olosuhteista, joissa tutkimus tehdään (Kitchenham et al, 2002). Käydään keskustelua tutkimushypoteeseista ja kuinka niihin päädyttiin (Kitchenham et al, 2002). Haetaan tietoa aiheeseen liittyvästä tutkimuksesta (Kitchenham et al, 2002). Artefakti tulisi kuvailla tarpeeksi hyvin, jotta se voidaan implementoida. Artefakti on harvoin täysimittainen sovellus vaan se määrittää ideat, käytännöt ja tekniset mahdollisuudet. (Hevner et al., 2004.)

31 2) Ongelman on oltava relevantti. Tutkimuksen päämäärä suunnittelutieteessä on kehittää teknologiaan perustuva ratkaisu tärkeään ongelmaan. Tutkimusongelmaa ei tulisi määritellä vain listana testeistä, jotka tullaan suorittamaan (Kitchenham et a, 2002). Ongelman takana oleva idea tulisi esitellä tutkimuksen tulosten yhteydessä (Järvinen & Järvinen, 2000 s. 105), Ongelma voidaan määritellä tavoitetason ja nykyisen tason eroina. Ongelman ratkaisu puolestaan voidaan määritellä miten nykytasosta päästään tavoitetasoon. (Hevner et al., 2004.) 3) Suunnitelman evaluointi. Artefaktin laatu, tehokkuus ja hyödyllisyys on voitava esitellä toimivilla evaluointimenetelmillä. Koska suunnittelu on usein iteratiivista, evaluointivaiheet tarjoavat tarvittavat dokumentit artefaktin arviointiin. Suunnittelutieteessä artefakti on usein tarkoituksella monimutkainen, jotta siitä saadaan toimiva käytännössä (Kueshler, Vaishanvi, 2008). Suunnittelutieteen tutkimus voi alkaa yksinkertaistetulla ongelmalla, jota muokataan iteraation myötä. (Hevner et al., 2004.) 4) Tutkimuksen hyödyllisyys. Toisin kuin muissa tieteenhaaroissa tietojenkäsittelytieteessä ei ole määriteltyjä standardeja, mitä tutkimukseen liittyviä tietoja siihen olisi liitettävä (Kitchenham et al, 2002). Suunnittelutieteellisen tutkimuksen tulisi tuottaa uutta tietoa vähintään yhdestä seuraavista alueista. Artefakti, joka on yleisin suunnittelutieteen tuotos. Tutkimus voi laajentaa tai parantaa perustutkimusta, luovasti kehitetyllä mallilla, metodilla tai ohjelmistolla. Luovasti käytetty metodi ja uudet evaluointimetriikat tuovat tutkimukseen kontribuutiota. (Hevner et al., 2004.) 5) Tutkimuksen perusteellisuus. Suunnittelutieteellisessä tutkimuksessa sekä artefaktin kehittämiseen ja sen evaluointiin käytettävät metodin on oltava hyväksi todettuja. Suunnittelutieteessä voidaan hyödyntää sekä määrällistä että kvalitatiivista tutkimusta (Kasanen et al, 1993). Käyttökelpoinen tutkimus voi tulla pelkästään empiirisistä havainnoista (Kitchenham et al, 2002). Tutkimuksen perusteellisuus tulee aikaisemman teoreettisen tutkimuksen ja hyväksi havaittujen kehitysmetodien käyttämisestä. (Hevner et al., 2004.) 6) Suunnitelma tutkimusprosessina. Suunnittelutiede on luonnostaan iteratiivista parhaan ja optimaalisimman ratkaisun etsimistä. Heuristiset menetelmät tuottavat toteuttamiskelpoisen suunnitelman, joka voidaan implementoida käyttöympäristöön. Suunnittelutieteessä ongelma usein yksinkertaistetaan, jotta tutkimus saadaan alkuun. Kehityksen iteraation myötä tutkimusongelmaa laajennetaan realistisempaan suuntaan. (Hevner et al., 2004.) 7) Tutkimuksen kommunikointi. Suunnittelutieteellinen tutkimus tulisi suunnata sekä teknisesti että hallinnollisesti orientoituneille henkilöille. Teknisesti orientoituneet tarvitsevat riittävästi yksityiskohtia, jotta kuvailtu artifakti voidaan implementoida ja saada käyttöön

32 tietyssä käyttöympäristössä. Näin artifaktin tarjoamat hyödyt saadaan organisaation käyttöön. Lisäksi muut tutkijat voivat käyttää teknisiä yksityiskohtia hyödyksi jatkotutkimuksessa. Hallinnollisesti orientoituneet tarvitsevat tarpeeksi yksityiskohtia artifaktin toiminnasta päättääkseen kannattaako sitä implementoida tai ostaa organisaation käyttöön. (Hevner et al., 2004.) Tässä tutkimuksessa hyödynnetään Hevner et al. (2004) esittelemiä ohjenuoria. Tutkimus tehdään iteratiivisesti siten, että kunkin iteraation jälkeen suunnitellaan seuraavan iteraation tehtävät. Ennen iteratiivista kehitystä esiteltiin kuitenkin suunnitelma, josta tuli ilmi kehitettävän mallin pääkohdat. Hevner et al. (2004) esittelemät ohjenuorat sisältyivät tutkimukseen seuraavasti. Tuotos on artefakti: kehitetty paperiprototyyppi on laskettavissa artefaktiksi. Ongelman on oltava relevanttii: Vaatimusmäärittelyvaihe on tärkeä vaihe ohjelmistokehityksessä ja siihen tulisi etsiä uusia vaihtoehtoja. Artefaktin evaluointi: paperiprototyyppiä jalostettiin iteraatioiden myötä. Tutkimuksen hyödyllisyys: tutkimuksessa kehitettyä paperiprototyyppiä voi hyödyntää ohjelmallisen työkalun kehityksessä. Tutkimuksen perusteellisuus: luvuissa 2-5 on käyty läpi tutkimukseen liittyvää teoriaa. Suunnitelma tutkimusprosessina: tutkimus on tehty iteratiivisesti kehittäen. Tutkimuksen kommunikointi: tutkimus on esitelty Tietojenkäsittelytieteen laitoksen tutkielmaseminaarissa. Lisäksi se on talletettu yliopiston kirjaston kokoelmiin.

33 7. Tutkimuksen eteneminen ja tulokset Tutkimuksen aikana kehitettiin paperiprototyyppi Prune the product tree pelistä. Prototyyppi kehitettiin tukemaan korkean tason vaatimusmäärittelyä ja toimimaan apuna asiakkaan ja kehittäjän välisessä keskustelussa. Paperiprototyypin kehittäminen tapahtui kuudessa eri iteraatiossa ja kehityksen aikana tehtiin kolme eri testiä. Testien jälkeen käytiin hieman läpi jälkiprosessointia. Jälkiprosessoinnin helpottamiseksi kehitettiin XML -kieleen perustuva kuvausmenetelmä, jolla puu saadaan siirrettyä digitaaliseen muotoon. Lisäksi tehtiin PHP -kielellä ohjelma jäsentämään puu luettavampaan muotoon. Tutkimuksen aikana kehitettyä mallia testattiin Pulkkilassa toimivassa Kauppamajakka OY:ssä. Kauppamajakka on perustettu 2004 ja se työllistää kuusi henkeä. Tuotevalikoimaan kuuluvat muun muassa taiteilijatarvikkeet, taloustavarat, vaatteet ja työkalut. (Kauppamajakka, 2010.) Kokeilun yhteydessä määritellään Kauppamajakkaan uusi kassajärjestelmä. Vanha järjestelmä on hankittu valmiina tuotteena, mutta sitä on räätälöity hieman toimittajan toimesta. Seuraavissa luvuissa kuvataan konstruktion toteutus. 7.1 Suunnitelma Paperiprototyyppi rakennettaisiin valkotaululle käyttämällä magneetteja. Valkotaulun etuna on, että siihen voitaisiin tehdä lisämerkintöjä tussilla. Oksat ja lehdet tehtäisiin valmiiksi ennen pelisessiota. Lehtiä voitaisiin tehdä useampaa väriä, mikäli se osoittautuisi tarpeelliseksi. Tämä täytyisi miettiä pelin ensimmäisissä testeissä. Tavoitteena olisi tehdä vähintään yksi pelisessio ennen metodin testausta Kauppamajakassa. Näin pystyttäisiin toivottavasti paremmin arvioimaan lehtien ja oksien määrä sekä niiden suhde toisiinsa. Oksa ja lehti pyrittäisiin suunnittelemaan taitettavaksi. Näin sisäpintaan saataisiin lisää tilaa huomioiden kirjoittamiseen ja huomiot eivät menisi hukkaan, kuten vaarana voisi olla erillisiä papereita käytettäessä. Magneettien ansiosta oksat ja lehdet ovat helppo irrottaa, mikäli pelin aikana tulee lisää ajatuksia kyseisestä ominaisuudesta. Pelin aikana puun eri vaiheet taltioitaisiin ottamalla siitä valokuvia. Myös videoiminen on mahdollista, mikäli osallistujat antavat luvan siihen. Eräs mahdollisuus voisi olla myös ajastettu kamera, joka ottaa valokuvan jalustalta tietyin väliajoin. Tämä tosin ei välttämättä sovi ainoaksi dokumentointikeinoksi, sillä pelaajat voivat olla kameran edessä. 7.2 Ensimmäinen iteraatio Ensimmäinen versio oksasta ja lehdestä on liitteessä A. Tässä vaiheessa haettiin vain elementtien muotoja. Elementit tulostettiin ja niitä kokeiltiin jääkaapin oveen. Tässä vaiheessa ilmeni, että oksia tulisi olla useampaa eri kokoa. Samalla ilmeni, että oksia

34 olisi hyvä pystyä jatkamaan lisäämällä toinen elementti ensimmäisen perään. Oksia päädyttiin tekemään kolmea eri kokoa. Lisäksi kustakin oksasta tehtäisiin kaksi versiota, joista toinen esittää oksan latvaa ja toinen oksan runkoa. Valkotaulu laitettiin tilaukseen tulevia testauksia ajatellen. Myös mahdollisuutta käyttää pahvia sekä liimaa tai sinitarraa mietittiin, mutta valkotauluun päädyttiin sen monipuolisuuden takia. Pahvilta olisi ollut käytännössä mahdoton poistaa tai muokata siihen kynällä tehtyjä muistiinpanoja. Lisäksi tussi näkyy kauemmaksi kuin lyijykynä tai kuulakärkikynä. Magneetteja on myös helpompi järjestää uudelleen tarpeen niin vaatiessa. Oksat ja lehdet kiinnitetään valkotauluun käyttämällä magneettiteippiä. Oksassa päädyttiin käyttämään magneetteja elementin päädyissä ja lehteen ne liimataan keskelle. Näin ne haittaavat mahdollisimman vähän kirjoittamista. Oksa on helppo laittaa haluttuun kulmaan kahden magneetin ansiosta. Valkotaulutussi osoittautui huonoksi vaihtoehdoksi paperille kirjoittamiseen, sillä se näkyy läpi mikäli tussia painetaan yhtään kovemmin paperiin. Pelisessioon täytyisi hankkia joko lyijykyniä tai kuivamustekyniä. 7.3 Toinen iteraatio Toisessa iteraatiossa lehti ja oksa muokattiin taitettavaksi. Tulostuksen jälkeen tuli ilmi, että taitettuna lehdet ja oksat eivät pysy kunnolla kiinni. Tämän takia lisättiin pieni lukko pitämään puolia yhdessä. Toinen versio oksasta ja lehdestä löytyy liitteestä B. Valkotaulu saapui postissa, joten ensimmäiset kokeilut lopulliselle alustalle päästiin aloittamaan. Elementtejä ei kuitenkaan vielä tulostettu isompia määriä. Puun juuri on vielä suunnittelun alla. Voi olla, että se päädytään piirtämään valkotaulutussilla. Paperista juuri voi olla hankala tehdä. Piirtämällä juureen saisi myös vaihtelua eikä se olisi aina samanlainen. Lehtiin ja oksiin kirjoittamiseen kokeiltiin piirtoheitintussia, mutta myös se näkyy paperista läpi. Yhtenä vaihtoehtona voisi olla elementtien liimaaminen pahville ennen taittelua, jolloin tussit eivät varmaankaan näkyisi läpi. 7.4 Kolmas iteraatio Kolmannessa iteraatiossa keskityttiin oksien muokkaamiseen. Oksalle tehtiin latvaosa ja skaalattiin kaksi pienempää oksaa. Paperiprototyypin grafiikat on tehty vektorigrafiikalla, joten niitä voi skaalata tarpeen mukaan myös suuremmaksi ilman rajoituksia tai pikselöitymistä. Pienemmät oksat skaalattiin siten, että kaksi elementtiä kustakin koosta mahtuvat A4 paperille. Näin saadaan paperin kulutusta pienennettyä hieman. Grafiikkatiedostoja täytyy luultavasti muuttaa ennen testien aloittamista, sillä oksia ja latvaosia ei oletettavasti mene yhden suhde yhteen. Suhteesta olisi oikeastaan tehtävä arvio ennen tulostusta. Lisäksi juuresta ja rungosta tehtiin ensimmäiset versiot. Juuresta ja rungosta ei tehty taitettavaa toisaalta niiden suuren koon vuoksi ja toisaalta runkoon ei pitäisi tulla kovin paljoa merkintöjä. Kolmannessa iteraatiossa tehdyt muutokset näkyvät liitteessä C. Pelin prosessia myös alettiin suunnittella tässä iteraatiossa. Ennen pelin alkua osallistujille olisi hyvä jakaa yhden A4 paperin ohjeistus pelin kulusta. Näin osallistujat

35 pystyisivät tutustumaan peliin ennen itse pelisessiota. Pelin prosessia ei kuitenkaan tulisi luultavasti määritellä kovin tarkkaan, jotta innovatiivisyys säilyy. 7.5 Ensimmäinen testi Ensimmäiseen testiin kutsuttiin osallistujia lähipiiristä. Aiheeksi valittiin joulun suunnittelu, koska siitä oletettiin löytyvän kaikilta ajatuksia. Järjestelmän suunnittelu olisi ollut tällä osallistujajoukolla vaikeaa, sillä kaikilla oli erilainen tausta. Lisäksi tarvetta yhteiseen käyttöön olevalle järjestelmälle ei ollut. Testi osoittautui tarpeelliseksi, sillä siinä löytyi kehitystarpeita jatkoa ajatellen. Valkotaulu asetettiin pöydälle makaamaan ja testaajat kerääntyivät pöydän ympärille. Käytössä oli lisäksi valkotaulutusseja sekä valkotaulusieni. Kaikki edellisissä luvuissa esitellyt elementit oli tulostettuna ja magneetilla varustettuna. Lehtiin ja oksiin kirjoitusta varten käytössä oli lyijykyniä. Testin lopuksi annettiin mahdollisuus vapaamuotoiseen kirjallisen palautteen antamiseen. Ensimmäisenä testissä tuli ilmi, että osallistujat kirjoittivat mieluummin valkotauluun, kuin tulostettuihin elementteihin. Hohmann (2006) huomautti, että pelissä käytettävät elementit eivät saa olla liian hienoja, jotta osallistujat tekevät niihin merkintöjä. Kyseessä saattaa olla sama asia. Elementit kannattaisi ehkä yksinkertaistaa poistamalla taitos. Tarvittavat huomiot voisi lisätä vaikka post-it lapuilla elementteihin. Tulostetuista elementeistä käytettiin jonkin verran lehtiä. Oksia ja rungon osia käytettiin enemmän. Näihinkään ei tosin tehty juuri merkintöjä. Oksista käytettiin kahta suurempaa kokoa, mutta pienimmät oksat jäivät kokonaan käyttämättä. Lisäksi valkotauluun piirrettiin itse lehtiä mieluummin kuin käytettiin valmiiksi tehtyjä lehtiä. Peli tuki kuitenkin hyvin testin aikana käytyä keskustelua. Testaajat pitivät hyvänä mahdollisuutta tehdä merkintöjä valkotauluun. Lehteen tehtiin lisämerkintöjä mindmapin tyyliin vetämällä viivoja lehden ympärille. Kuvassa 2 on esimerkki tämän tyyppisestä lehdestä. Myös valkotaulun sijoittamista pöydälle pidettiin hyvänä ajatuksena. Valkotaulun ympärille mahtui enemmän väkeä, kun se oli makuullaan. Mikäli valkotaulu olisi ollut pystyssä, sen ympärille olisi mahtunut vain yksi tai kaksi henkilöä. Testaus dokumentoitiin valokuvaamalla. Koska itse elementteihin ei tehty juuri ollenkaan merkintöjä, niitä ei päästy hyödyntämään dokumentoinnissa. Valokuvia otettiin itse testaustilanteesta sekä lopputuloksesta.

36 Kuva 2. Osa valkotaulun sisällöstä Testin jälkeen saadusta palautteesta tuli ilmi, että testaajat pitivät tämän tyyppisestä menetelmästä. Testaajat alkoivat miettiä, miten he pystyisivät käyttämään tämän tyyppistä menetelmää omassa työssään apuna. Ajatuksia oli muun muassa opetuksen tukena käytettäväksi peliksi ala-asteen tunneilla. Perusteluina oli, että lapset voisivat pitää taululle piirtämisestä. Palautteessa pohdittiin myös pelin dokumentointia jatkokäsittelyä varten sekä aiheen laajuuden vaikutusta pelin kulkuun. 7.6 Neljäs iteraatio Neljännessä iteraatiossa palattiin oksan ja lehden osalta yksinkertaisempaan malliin. Taitos poistettiin molemmista elementeistä. Lisäksi ensimmäisen testin perusteella lehden kokoa lisättiin kaksinkertaiseksi pituus- sekä leveyssuunnassa. Lehdet ja oksat päädyttiin laminoimaan ennen magneetin kiinnitystä. Näin niihin voi käyttää valkotaulutusseja, joka näkyy paremmin kuin lyijykynä. Valkotaulutussi lähtee myös pois pyyhkimällä muovista, joten samoja elementtejä voidaan käyttää useammassa kokoontumisessa ja korjaukset ovat mahdollisia. Prosessin suunnittelu jatkui ja tässä vaiheessa tehtiin lyhyt ohje, jonka voi jakaa asiakasorganisaatioon ennakkoon (liite D). Ohje sisälsi esimerkin oksasta sekä lehdestä.

37 Pelin ohjeistus pyritään pitämään mahdollisimman lyhyenä, jotta liian määritelty prosessi ei veisi tilaa innovaatiolta. 7.7 Ensimmäinen testi Kauppamajakka Oy:ssä Ensimmäinen testi Kauppamajakka Oy:ssä tehtiin torstaiaamuna kello yhdeksän. Testiin osallistui kolme henkilöä. Testiin osallistujat tekivät samalla myös asiakaspalvelutyötä. Aamu oli odotettua vilkkaampi ja lisäksi yksi työntekijä oli sairaslomalla, joten testi oli katkonainen. Keskustelua ei juuri päässyt syntymään, sillä yksi testiin osallistujista joutui olemaan käytännössä koko ajan pois testipaikkana toimineesta kahvihuoneesta. Lisäksi kassalla oli asiakkaita suhteellisen tiheään. Testiin kulunutta aikaa on myös tämän takia vaikea arvioida. Taululle kertynyt aineisto oli lähinnä nykyisen järjestelmän puutteita. Testissä käytetyt valmiiksi tulostetut elementit toimivat suhteellisen hyvin ja lehdille sekä oksille tehtiin merkintöjä. Testin alku oli toisaalta hiljaista. Osallistujilla ei ollut aikaisemmpaa kokemusta käytetyn kaltaisesta tekniikasta. Uusille osallistujille olisikin ehkä hyvä pitää jonkinlainen harjoitus, jossa tekniikka tulisi tutuksi. Kaksi testiin osallistujista oli tutustunut ennakkoon tulostettuun ohjeeseen. Ohjetta ei pidetty kovin selvänä. Ohje vietiin Kauppamajakkaan noin viikkoa ennen testiä. Ohjetta oli tulostettu viisi kappaletta. 7.8 Toinen testi Kauppamajakka Oy:ssä Toinen testi aloitettiin kello 16 ja se kesti 17.30 asti. Testi sijoittui osaksi palveluajalle, mutta iltapäivällä kauppa oli hiljaisempi kuin aamusta. Tämän ansiosta testiin osallistui jatkuvasti vähintään kaksi henkilöä. Osallistujat olivat myös valmistautuneet testiin kirjaamalla vaatimuksia ennakkoon ylös. Lehtiä ei tässä testissä käytetty, vaan käytössä olivat ainoastaan post-it laput. Tämä oli tarpeen osaksi valkotaulun pienen koon vuoksi. Lisäksi osallistujat näkivät post-it laput helpommiksi käyttää. Oksat olivat käytössä testissä. Jälkiprosessointia varten post-it laput liimattiin asiaankuuluvaan oksaan. Haaraumia tuli yhteen oksaan. Lisäksi osallistujat käyttivät post-it lappuja siten, että yksi lappu vastasi yhtä oksaa. Testissä päätettiin kehittää olemassa olevaa järjestelmää, sillä osallistujat mielsivät sen helpommaksi kuin uuden järjestelmän suunnittelun. Testin lopputulokseen tämä vaikutti siten, että testissä käsiteltiin suhteellisen korkean tason vaatimuksia. Kuvassa 3 on lopullinen puu.

38 Kuva 3. Kauppamajakka Oy:n testin lopputulos Testin aikana vaatimuksia kirjattiin taululle yhteensä 54. Vaatimukset kattoivat kaikki kassajärjestelmän osa-alueet. Osa-alueet laitettiin taululle testin alussa oksina. Vaatimukset olivat selkeitä, vaikkakin niiden toteuttaminen järjestelmään olisi vaatinut usein vielä tarkennuksia. Määriteltyjen vaatimusten avulla oli kuitenkin mahdollista saada kuva suunnitellun järjestelmän laajuudesta. Testin jälkeen vaatimukset kirjattiin tietokoneelle tekstitiedostoksi, jossa puun malli kuvattiin sisennyksillä. Tekstitiedosto on liitteessä E. 7.9 Viides iteraatio Viidennessä iteraatiossa keskityttiin tuloksien analysointiin. Saadut vaatimukset pyrittiin listaamaan product backlogin muodossa. Product backlog on yleensä kuvattu listana (Paetsch & Eberlein, 2003; Sutherland, 2004). Tämä asetti omat ongelmansa puumallin kuvaukseen. Saadut vaatimukset yritettiin ensin lisätä taulukkolaskentaohjelmaan, mutta se ei osoittautunut tarpeeksi joustavaksi vaihtoehdoksi. Puumallin esittämistä yritettiin pistämällä eri tasot omiin sarakkeisiinsa, mutta se vaikeutti huomattavasti tiedoston käsittelyä sekä luettavuutta. Lisäksi attribuuttien lisääminen vaatimuksiin oli hankalaa. Lopulta vaatimukset päädyttiin kirjoittamaan XML -muotoiseen tiedostoon. XML -tagien sisäkkäisellä sijoittelulla puun kuvaus tuli luonnostaan. Lisäksi tageihin oli helppo lisätä tarvittavat attribuutit. Attribuutteja pystytään myös poistamaan tai lisäämään tarpeen mukaan eikä tiedoston muotoilu mene sekaisin. Alla on esimerkki XML -tiedostosta. Seuraavassa iteraatiossa tulisi tehdä esimerkiksi PHP:llä ohjelma,

39 joka tulostaa vaatimukset luettavampaan muotoon. Lisäksi olisi hyvä, jos puun oksia pystyisi supistamaan tarpeen mukaan. <?xml version="1.0" encoding="utf-8" standalone="yes"?> <group name="varasto"> <item assignedto="" priority="">tuoteryhmänäkyvyys</item> <item assignedto="" priority="">selaus nimikkeellä, koodilla, hinnalla, tuoteryhmällä, saldolla, päivämäärä (tulopäivämäärä)</item> <item assignedto="" priority="">puutelista</item> <item assignedto="" priority="">tuotteen sijainti myymälässä, varastossa jne. (varasto I, II, III)</item> <group name="tuotteet"> <item assignedto="" priority="">kate% eri tuotteille/ryhmille</item> <item assignedto="" priority="">hävikkiseurannat</item> <item assignedto="" priority=" >infoa tuottesta <info>soveltuvuus, materiaali, ym.</info></item> <item assignedto="" priority="">tietyn tuotteen ostomäärä esim. vuoden aikana</item> <item assignedto="" priority="">sesonkituote</item> </group> <group name="kampanjat"> <item assignedto="" priority="">mainoskampanja</item> <item assignedto="" priority="">aikajakso</item> <item assignedto="" priority="">poistotuotteet</item> <item assignedto="" priority="">mahdollisuus useisiin yhtäaikaa</item> <item assignedto="" priority="">tavaran toimittajien tarjoukset</item> <item assignedto="" priority="">kampanjakohtainen raportti</item> <item assignedto="" priority="">mainoksen suunnittelu</item> </group> </group> Tiedosto alkaa XML version ja merkistön määrittelemisellä. Tämän jälkeen määritellään group -tagilla oksan nimi. Group -tagin sisään määritellään kukin vaatimus omalla item -tagilla. Item saa attribuuteiksi priority, joka kuvaa vaatimuksen prioriteetin, ja assignedto, joka kertoo kenelle vaatimus on annettu tehtäväksi toteuttaa. Attribuutteja

40 voi lisätä tarpeen mukaan. Oksan määrittely loppuu </group> -tagiin. Group -tageja voi lisätä sisäkkäin ilman rajoituksia, jolloin niillä saadaan määriteltyä puun rakenne. 7.10 Kuudes iteraatio Kuudennessa iteraatiossa toteutettiin PHP -ohjelma helpottamaan XML -tiedoston lukemista. PHP:n lisäksi käytettiin JavaScriptiä. JavaScriptillä toteutettiin eri puun osien piilottaminen. Tämä tehtiin luomalla jokaisesta otsikosta linkki, jota klikkaamalla alaosiot menevät piiloon ja tulevat näkyviin. XML -tiedostoon jouduttiin tekemään hieman muutoksia. Info -tagi siirrettiin item -tagin attribuutiksi käsittelyn helpottamiseksi. Lisäksi ensimmäiselle tasolle lisättiin groups -tagi, joka sisältää koko tiedoston sisällön. Koska PHP käsittelee XML -tiedoston sisäkkäisinä taulukkoina, tämä helpotti algoritmin tekoa. Toteutetun ohjelman lähdekoodi on liitteessä F. Ohjelman käyttämä testi.xml tiedosto on listauksena liitteessä G. Kuva 4. Kuvakaappaus XML -tiedostosta jäsenneltynä. Kuvassa 4 on kuvakaappaus tehdystä ohjelmasta. Jotta ohjelmasta saataisiin paremmin käytettävä, siihen tulisi lisätä tuki tehdä muutoksia tiedostoon. Lisäksi siihen tulisi lisätä mahdollisuus lisätä tekijä kullekin vaatimukselle. Nämä ominaisuudet tosin löytyvät valmiina esimerkiksi Mozilla Foundationin tekemästä Bugzillasta, joten voisi olla kätevää myös tehdä vaatimusten vienti kyseiseen järjestelmään. Tämän hetkisellä ohjelmalla voidaan tulostaa lista määritellyistä vaatimuksista esimerkiksi asiakkaalle menevään raporttiin. Vaatimusten listasta voidaan piilottaa osia, jos halutaan keskittyä tiettyihin oksiin. Jatkokehittämällä ohjelmasta saataisiin työkalu, jota voidaan käyttää kehitystyössä työnjakoon.