Sanna Talonen 

Laajan tuotekehitysprojektin organisointi ja 
hallinta ketterässä sovelluskehityksessä 

  

 

 

 

 

 

 

 
  

Vaasa 2024 

Tekniikan ja innovaatiojohtamisen akateeminen yksikkö 
Tietojärjestelmätieteen Pro gradu -tutkielma  

Tietojärjestelmätieteen maisteriohjelma 



2 

 

    

VAASAN YLIOPISTO 
Tekniikan ja innovaatiojohtamisen akateeminen yksikkö 
Tekijä: Sanna Talonen 
Tutkielman nimi: Laajan tuotekehitysprojektin organisointi ja hallinta ketterässä 

sovelluskehityksessä   
Tutkinto: Kauppatieteiden maisteri 
Oppiaine: Tietojärjestelmätieteen maisteriohjelma 
Työn ohjaaja: Jouni Lampinen 
Valmistumisvuosi: 2024 Sivumäärä: 99 

TIIVISTELMÄ: 
Tämän tutkielman tarkoituksena on luoda ymmärrys laajojen tuotekehitysprojektien 
projektinhallinnan haasteista ja pyrkiä löytämään niihin ratkaisuja ketteristä 
sovelluskehityksistä. Tutkielman kohteena ovat laajat tuotekehitysprojektit, joissa on kokeiltu 
perinteisiä projektinhallintamalleja ja havaittu niissä haasteita. Tutkielmassa pyritään löytämään 
parempi asiakastyytyväisyys käyttäen ketteriä menetelmiä. 
 
Tutkielman teoreettisen viitekehyksen rakentaminen aloitetaan esittelemällä ketterän 
menetelmän peruskäsitteitä. Teoriaosuudessa pyritään keskittymään nimenomaan laajojen 
organisaatioiden ketteriin menetelmiin saatavilla olevien tietojen valossa. Työ jatkuu 
lähtötilanteen kuvauksella. Tutkielman aineisto hankittiin keskisuuren kansainvälisen IT-
yrityksen Suomen osastolta. 
 
Tutkitun aineiston perusteella voitiin todeta, että asiakkaat olivat niin pettyneitä ainaisiin 
tuotekehitysaikataulun venymisiin, että heille sopi mikä tahansa muutos kuten esimerkiksi 
ketterään menetelmään siirtyminen. Riskeistä huolimatta ketterän menetelmän soveltaminen 
onnistui erinomaisesti ja asiakkaalle pystyttiin toimittamaan uusi tuote sovitussa ajassa. 
Asiakkaan innostus ja tyytyväisyys pehmittivät yrityksen ylintä kansainvälistä johtoa 
suhtautumaan neutraalimmin ketterään menetelmään, mutta työ jatkuu vielä tällä saralla ja 
kaikki mahdolliset kommunikointitilanteet pitää käyttää positiivisesti hyväksi. Tulevaisuudessa 
asiakkaan sovelluksiin pitää pystyä pureutumaan syvemmin, että ratkaisut ehditään aloittaa 
ajoissa. Tiimien tulee pilkkoa ominaisuuksia pienempiin osa-alueisiin, että työ voidaan jakaa 
mahdollisimman usealle tiimille. 
 
 
 
 
 
 
 
 
 
 
 
 
 

AVAINSANAT: projektinhallinta, ohjelmistotuotanto, ohjelmistotuotantoprosessi, 
ohjelmistokehitys, ketterät menetelmät, ison organisaation muutos ketterään menetelmään 

  



3 

 

    

UNIVERTITY OF VAASA 
School of Technology and Innovation 

Author: Sanna Talonen 
Title of the thesis: Laajan tuotekehitysprojektin organisointi ja hallinta ketterässä 

sovelluskehityksessä   
Degree: Master of Science in Economics and Business Administration 
Programme: Master’s Programme in Information Systems 
Supervisor: Jouni Lampinen 
Year of graduation: 2024 Pages: 99 

ABSTRACT: 
The purpose of this study is to get an understanding of the challenges of project management 
in the large-scale research and development projects and try to find solutions for agile methods. 
The target of the research is extensive research and development projects, which have been run 
with traditional project management models and challenges have been met. The aim of the 
study is to find better customer satisfaction by using agile methods. 
 
The construction of a theoretical framework for the study starts by introducing the basic con-
cepts of agile methodology. The aim of the theoretical part is to focus specifically in large or-
ganizations agile methods with the available information. Work continues by defining the base-
line. The material of the study was got from Finland section of the medium-size international IT 
company.  
 
It was found of from the researched material that customers were so disappointed from the 
schedule delays of development project that they were ready to accept any changes like this 
agile method. Regardless of the risks the agile development project success and the new prod-
uct were delivered to customer on time. The satisfaction of the customers influences positive 
to the attitude of the directors in America, but positive communication needs continue in all 
possible situations. In the future, the application of the customer’s needs to be studied deeply, 
so that solution can be started early enough. Team needs to divide feature in the smaller pieces, 
so that it can be done by many teams. 
 
 
 
 
 
 
 
 
 
 
 
 
 

KEYWORDS: project management, software engineering, software production process, soft-
ware development, agile methods, large-scale agile transformation 

  



4 

 

    

Sisällys 

1   Johdanto 10 

1.1   Tutkielman tarkoitus ja tavoitteet 11 

1.2   Tutkielman kulku 12 

2   Ketterät menetelmät teoria 13 

2.1   Scrum perusperiaatteet 18 

2.2   Agile-mallinnus käytännössä 19 

2.2.1   Agile-mallinnuksen arvot 19 

2.2.2   Keskeisimmät periaatteet 21 

2.2.3   Organisaatio 22 

2.2.4   Scrum toimintatavat ja aktiviteetit 24 

2.3   Sovellukset laajoissa organisaatioissa 25 

3   Lähtötilanne 29 

3.1   Vesiputousmalli 29 

3.1.1   Käytössä ollut tuotekehitysprosessi 30 

3.1.2   Haasteet ja ongelmat todettiin testausvaiheessa 32 

3.2   Iteratiivinen malli 34 

3.3   Haasteet 37 

3.4   Tavoitteet 41 

4   Työn rakenne 44 

4.1   Tutkimusaineisto 44 

4.2   Tutkimusstrategia eli case-tutkimus 45 

4.3   Tutkimuksen toteutus ja analysointi 46 

5   Ketterän menetelmän soveltaminen laajaan projektiin 48 



5 

 

    

5.1   Vaatimusten priorisointi 50 

5.2   Organisaation luominen 52 

5.3   Hallintamenetelmien luominen 55 

5.3.1   Palaverikäytäntö 56 

5.3.2   Raportointi 57 

5.4   Testaus 59 

5.5   Työkalut 62 

5.6   Metriikka 63 

5.7   Projektin dokumentit 71 

6   Projektinhallinnan arviointi käyttäjän näkökulmasta 72 

6.1   Asiakkaat 73 

6.2   Johtoryhmä 75 

6.2.1   Projektin ohjausryhmä 75 

6.2.2   Yrityksen Suomen osa-alueen projektijohtoryhmä 76 

6.2.3   Yrityksen projektijohtoryhmä 77 

6.3   Projektitiimi 79 

6.4   Projektipäällikkö 80 

7   Tulokset 83 

7.1   Laajan tuotekehitysprojektin haasteet 83 

7.2 Ketterän menetelmän soveltamisen tutkiminen laajaan tuotekehitysprojektiin 84 

7.3   Ketterän menetelmän soveltaminen ja parannusehdotukset 85 

8   Johtopäätökset 92 

8.1   Laajan tuotekehitysprojektin haasteet 92 

8.2 Ketterän menetelmän soveltamisen tutkiminen laajaan tuotekehitysprojektiin 93 



6 

 

    

8.3   Ketterän menetelmän soveltaminen ja parannusehdotukset 94 

Lähteet 97 

 

  



7 

 

    

Kuvat 
 

Kuva 1. Ketterän menetelmän perusperiaate. 13 

Kuva 2.  Vesiputousmalli ja iteratiivinen malli. 14 

Kuva 3.  Vesiputous- ja iteratiivinen malli yhdistettynä ketteräksi ohjelmisto-

kehitysmalliksi. 15 

Kuva 4.  Lean, Agile, Scrum ja XP menetelmien suhde. 16 

Kuva 5.  Ketterän ohjelmistokehityksen julistus. 16 

Kuva 6.  Scrum kehys.  19 

Kuva 7.  Tuotekehitysorganisaation eri ketterän menetelmän sovellustasot. 28 

Kuva 8.  Tuotekehitysprojektin vaiheet. 29 

Kuva 9.  Tyypillinen projektiorganisaatio. 30 

Kuva 10. Suomen yksikön prosessi sulautettuna globaaliin prosessiin. 32 

Kuva 11. Rational Rose integraatiomalli yrityksessä. 35 

Kuva 12. EMS-tuotekehityksen yleisiteraatiosuunnitelma. 36 

Kuva 13. Integraatiotestaussuunnitelma yhdelle uudelle toiminnolle. 37 

Kuva 14. Tuotekehitysprojektin aikataulusuunnitelma ja sen toteutuminen. 38 

Kuva 15. Projektin tuotteiden määrän (y-akseli) suunnittelu ja toteutus kuu-

kausittain. 39 

Kuva 16. Projektin kumulatiivinen henkilövuosisuunnitelma ja –toteutumamies-

työkuukausina. 41 

Kuva 17. Kehitysmallit. 43 

Kuva 18. Ensimmäinen projektiorganisaatio. 54 

Kuva 19. Uusi organisaatio kahden kuukauden jälkeen. 55 

Kuva 20. Kolmen viikon sprintin ylätason tapahtumat aikajanalla. 56 

Kuva 21. Uuden ominaisuuden testaustapahtumien kappalemääräinen suorit-

taminen scrum-tiimissä kumulatiivisesti. 59 

Kuva 22. Regressiotestitulokset neljän viikon kumulatiivinä. 61 

Kuva 23. Uusien ominaisuuksien kappalemääräinen toimitusvalmiuden suunnitelma 

ja toteutuma (y-akseli) kolmen viikon sprinteittäin (x-akseli). 64 



8 

 

    

Kuva 24. Yhden tiimin tehtävien suunnittelu- ja toteumaedistymäkaavio kolmen 

viikon iteraatioissa. 66 

Kuva 25. Automatisoitujen testien viikottainen tilanne. 67 

Kuva 26. Viikoittain muuttuneet C++ lähdekieliset ohjelmarivit. 69 

Kuva 27. Projektin uusien ominaisuuksin kappalemääräinen toimitusvalmiuden 

suunnitelman ja toteutuksen muutokset kuukausittain. 70 

  



9 

 

    

Lyhenteet 
 

APO Area product owner, aluetuoteomistaja 

CIP Controlled introduction plan,  

Daily Scrum Päiväpalaveri 

FO Feature owner, ominaisuusomistaja 

IOT testing  Interoperability testing, yhteentoimivuustesti 

MDS testing  Multi-dimensional system testing, eri sovelluskompinaatioiden 

testaaminen 

MPR Management phase review, tuotekehitysprosessin virstanpylvään 

katselmointi ja päätös projektin johtoryhmän kanssa 

MSR Management status review, tuotekehitysprosessin määrittelemä 

tilannekatselmointi projektin johtoryhmän halutessa 

NF testing New feature testing, uuden ominaisuuden testaus 

NPI New product introduction, uuden tuotteen esittely  

PCRG Product council review group, tuotteen päätöksiä tekevä 

johtoryhmä 

PLS Product launch support, tuotteen asiakkaalle viennin tuki 

PB Product Backlog, tuotteen kehitysjono 

PO Product Owner, tuoteomistaja 

SM Scrum Master, scrum mestari 

Sprint Sprintti 

ST Scrum Team, scrumtiimi (ts. tuoteomistaja, kehitystiimi ja scrum-

mestari) 

SDS testing Single-dimensional system testing, yhden sovelluskompinaation 

testaaminen 

SB Sprint Backlog, sprintin kehitysjono 

  



10 

 

    

1   Johdanto   

 

IT ala on jatkuvan muutoksen kourissa. Vuosikymmenien varrella on nähty IT-alan 

räjähtävä nousu, uusien innovaatioiden tulo ja myöskin kuplan puhkeaminen. 

Innovaatiot ja asiakkaiden tarpeet ovat määritelleet markkinoita. Innovaatiot ovat joko 

puhjenneet kukkaansa tai kuihtuneet pois. Kaiken tämän keskellä projektinhallinta on 

pysynyt pääosin muuttumattomana. Vesiputousmalli on vielä paljon käytetty 

projektinhallintametodi. Pienet yritykset ovat kokeilleet ja siirtyneet uusiin 

projektinhallintamekanismeihin, mutta isot yritykset ovat hitaita kokeilemaan uutta. 

Toisaalta taas uusien, parempien menetelmien hyöty näkyisi nimenomaan laajoissa 

projekteissa. Niissä haasteet ovat mittavia, joten haasteen muuttaminen positiiviseksi 

voimavaraksi näkyisi myös suurempana hyötynä kuin pienen yrityksen pienessä 

projektissa. 

 

Tässä tutkielmassa tarkastellaan laajan IT-tuotekehitysprojektin haasteita ja etsitään 

parempia ratkaisuvaihtoehtoja sen organisoimiselle ja hallinnalle ketterän menetelmän 

avulla, josta on hyviä kokemuksia pienillä projekteilla. IT-yrityksellä tarkoitan 

tietoliikennelaitteistoja ja -ohjelmistoja tuottavaa keskisuurta kansainvälistä yritystä, 

jolla on laaja asiakaskunta (yli 200 asiakasta) ympäri maailmaa. Asiakkaat ovat 

tietoliikennepalveluja tarjoavia verkko-operaattoreita. Laajalla tuotekehitysprojektilla 

tarkoitan henkilömäärältään isoa (250 suunnittelijaa) ja maantieteellisesti laajasti 

levinnyttä (kolme maanosaa). 

 

Työn lopputulos on selvitys, jossa ketterää menetelmää on kokeiltu laajaan 

tuotekehitysprojektiin. Ketteristä menetelmistä käytämme Scrum menetelmään, sillä 

sen lisäksi, että se on yrityksessämme tunnetuin ja siitä meillä on eniten kokemusta 

Scrum on myös yleisesti ottaen suosituin ketteristä menetelmistä (Theocharis 2015). 

Kaksi kokenutta projektipäällikköä ovat käyneet Scrum mestari kurssin ja he 

suosittelivat nimenomaan Scrum-menetelmää. Toisaalta yrityksen verkkohallintaryhmä 



11 

 

    

on käyttänyt Scrum-menetelmää usean vuoden hyvällä menestyksellä. Vaikka tämä 

ryhmä ei ole osana tulevaa tuotekehitysprojektia, niin heiltä kuitenkin voimme saada 

käyttökokemuksia ja apua tarvittaessa.  

 

Käytän tapaustutkimusta eli case-tutkimusta, joka soveltuu hyvin teorian ja käytännön 

kehittymisaskeliin ja antaa hyvät mahdollisuudet ymmärtää tapahtumien kulkua ja 

muutoksia. Selvitys keskittyy nimenomaan projektin organisointiin ja hallintaan, sillä 

näin laajan tuotekehitysprojektin siirtäminen ketterään menetelmään on erittäin 

haastavaa ja siitä on vain vähän kirjoitettua tietoa. Haluan jakaa yhden esimerkin 

ketterän menetelmän soveltamisesta laajaan tuotekehitysprojektiin. Toivon, että tämä 

työ auttaa ja tukee jotain toista samassa tilanteessa olevaa yritystä, joka pohtii samoja 

kysymyksiä. 

 

 

1.1   Tutkielman tarkoitus ja tavoitteet  

  

Tutkielman tarkoituksena on tutkia ketterän menetelmän soveltuvuutta laajaan 

tuotekehitysprojektiin. Tutkimusongelmaa lähestytään seuraavan kolmen tavoitteen 

kautta.  

  

Ensimmäisen tavoitteena on luoda ymmärrys laajan tuotekehitysprojektin haasteista. 

Mitkä ovat suurimmat ongelmat tuotekehitysprojektin suhteen? Mitkä asiakas kokee 

pettymykseksi? Mitä haasteille on tehty tähän mennessä? Ensimmäiseen tavoitteeseen 

vastataan teorialuvuissa tarkastelemalla aiheeseen liittyvää kirjallista ja sähköistä 

aineistoa sekä tutkimalla tuotekehitysprojektin lähtötilanteen haasteita.  

  

Toisena tavoitteena on tutkia ketterän menetelmän soveltamista laajaan 

tuotekehitysprojektiin. Miten laaja projekti eroaa pienestä projektista? Mitä asioita 

pitää erityisesti ottaa huomioon isossa organisaatiossa? Toiseen tavoitteeseen 



12 

 

    

vastataan tutkimalla ketterän projektinhallinnan kirjallisuutta ja soveltamalla sitä 

kansainvälisen IT-yrityksen projektinhallintaa. 

  

Kolmantena tavoitteena on testata ketterää menetelmää laajassa projektissa ja 

analysoida sen soveltuvuus mahdollisine parannusehdotuksineen. Tähän 

tavoitteeseen päästään analysoimalla laajan projektin onnistumiskokeilua.  

 

 

1.2   Tutkielman kulku  

 

Tutkielma alkaa tärkeiden käsitteiden kuvaamisella. Syvennän niihin liittyvää teoriaa 

kappaleessa kaksi. Kolmannessa kappaleessa kuvaan lähtötilanteen haasteineen ja 

tavoitteineen. Työn rakenteen kuvaan kappaleessa neljä. 

 

Viidennessä kappaleessa sovellan ketterän menetelmän teoria tietoa laajaan 

tuotekehitysprojektin muuttamisessa ketterän menetelmän mukaiseksi. Kuudennessa 

kappaleessa arvioin projektinhallinnan onnistumista käyttäjän näkökulmasta. 

Seitsemännessä kappaleessa kerään yhteen selvityksen tulokset. 

 

Kahdeksas kappale sisältää johtopäätökset ja keskeiset tulokset. Kerron siellä myös 

toimenpidesuositukseni ja jatkotoimenpide-ehdotukseni. 

 

 

 

  



13 

 

    

2   Ketterät menetelmät teoria 

 

Ketterä ohjelmistokehitysmenetelmä (agile software development) on tällä hetkellä 

tehokkain projektinhallinnan menetelmä. Perusperiaate on, että monitaitoinen tiimi 

tekee iteraatiokierroksen suunnitelman, toteuttaa sen ja toimittaa toimivan 

ohjelmistokokonaisuuden, kommunikoi suoraa, reagoi muutoksiin nopeasti ja kehittyy 

jatkuvasti kuten kuvassa 1 on esitelty. 

 

Kuva 1. Ketterän menetelmän perusperiaate.  

Ketterät menetelmät ovat ihan uusi ohjelmistokehitysmenetelmä, mutta toisaalta se 

sisältää vanhat menetelmät erinomaisesti soveltaen. Yksinkertaistaen voisi sanoa, että 

ketterät menetelmät ovat yhdistäneet vesiputousprosessin iteratiiviseen prosessiin. 

Kuvassa 2 on yksinkertaistettu vesiputousmalli, jossa vaiheet tehdään peräkkäin sekä 

iteratiivinen malli, jossa tuote valmistuu pala palalta etukäteen suunnitelluissa 

iteraatioissa. 

 

Iteraation 
suunnittelu

Toteutus

Toimitus & 
palaute



14 

 

    

 

Kuva 2.  Vesiputousmalli ja iteratiivinen malli.  

 

Kuvassa 3 on yhdistetty nämä kaksi mallia ketteräksi menetelmäksi. Siinä yhdessä 

iteraatiossa tehdään kaikki vesiputousmallin vaiheet pienelle tuotteen palaselle. 

Iteraation lopussa on siis olemassa testattu toimitettavaksi kelpaava pieni uusi 

toiminnallisuus. Toisin kuin iteratiivisessa mallissa ketterän menetelmän 

iteraatiokierroksien määrää ei voida tarkkaan sanoa. Tai jos kierrosten määrä sanotaan 

tarkkaan, niin sisältöä ei silloin voida kertoa etukäteen. Ketterissä 

ohjelmistotuotantomenetelmissä yhdistyy aiempien prosessien hyvät puolet. 

 

 

 

Esitutkinta

Määrittely ja 
suunnitteli

Toteutus

TestausAsiakastestaus

Käyttöönotto

Ylläpito

Valmistelu

Iteraatio 1

Iteraatio 2

Iteraatio 3

Iteraatio 4

Vesiputousmalli 

Iteratiivinen malli 



15 

 

    

 

 

Kuva 3.  Vesiputous- ja iteratiivinen malli yhdistettynä ketteräksi 
ohjelmistokehitysmalliksi. 

 

Jos kerran vesiputous- ja iteratiivinen malli ovat sulautuneet, niin herää kysymys, että 

onko ketterät menetelmät sittenkään puhtaasti ketteriä menetelmiä vai onko siihen 

sulautunut muitakin menetelmiä. Theocharis (2015) on tutkinut tiiminsä kanssa 

vesiputousmallin ja Scrum-menetelmän yhteyttä. Hän totesi, että heidän saamansa 

tiedon valossa erityisesti laajat kehitysprojektit käyttävät vesiputousmallin ja erityisesti 

Scrumin yhdistelmää. Erityisesti laajat organisaatiot käyttävät perinteistä prosessia 

perushallintoon sekä rajapintana muihin yrityksiin ja liiketoimintaprosesseihin kun taas 

kehitystiimit käyttävät puhtaammin ketteriä menetelmiä. 

 

Iteraatio 1

Iteraatio 2

Iteraatio n

Iteraatio 
n+1

Iteraatio 
n+2



16 

 

    

Agile on yleisnimi useille erilaisille ohjelmistokehitysmetodeille kuten Scrum, eXtreme 

Programming, DSDM ja Crystal Clear, joiden keskinäinen suhde on kuvattu kuvassa 4. 

(Björkholm 2021: 9). 

  

Kuva 4.  Lean, Agile, Scrum ja XP menetelmien suhde.  

 

Vuonna 2001 kokoontui 17 eri taustoilla varustettua asiantuntijaa keskustelemaan 

kahdeksi päiväksi ja lopputuloksena he allekirjoittivat ketterän ohjelmistokehityksen 

julistuksen (kuva 5).  

 

 

 

 

 

 

 

 

 

Kuva 5.  Ketterän ohjelmistokehityksen julistus (Agile Manifest b. 2001) 

 

Lean 
Agile 

Scrum 

XP 

 

Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä 
itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme: 

Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja 
Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota 

Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja 
Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa 

Jälkimmäisilläkin asioilla on arvoa, mutta 
arvostamme ensiksi mainittuja enemmän. 

 



17 

 

    

Agile sisältää kaksitoista perusperiaatetta, joista yhdeksän tärkeintä ovat lueteltu 

seuraavaksi (Björkholm 2021: 9). 

1. Priorisoida ja keskittyä maksimoidakseen sijoitetun pääoman tuotto. 

2. Läpinäkyvyys nähdä ongelma ja rakentaa luottamus. 

3. Iteratiivinen ja inkrementaalinen kehitys oppiakseen, saadakseen palautetta ja 

pienentää riskejä. 

4. Yhteistyö väärinymmärrysten minimoimiseksi ja erottaakseen ja turvata 

liiketoimintamallin tavoitteet. 

5. Kannustaa ja toivottaa muutokset tervetulleiksi, sillä muutokset ovat 

kuitenkin todellisuutta. 

6. Yksinkertaiset työkalut pystyäkseen soveltamaan prosessia toimintaan. 

7. Tavoitekeskeisyys taatakseen tehokkaan työskentelyn. 

8. Alituinen parantaminen tullakseen tehokkaammaksi. 

9. Korkea laatu, sillä virheet ovat kalliita. 

 

Lean perusperiaate on minimoida aika idean ja maksettavan tuotteen välillä. Tyypillisesti 

keskitytään työskentelemään kauaskantoisesti, minimoimaan riskit ja olemaan tehokas 

välttyäkseen tekemästä tarpeettomia asioita ja näkyviä ongelmia sekä parantamaan 

jatkuvasti prosessia. Keskeistä on nopea toimitus eli lyhyet toimitusajat, jolloin 

tuotannon pullonkauloja etsitään ja poistetaan. Tähän on olemassa useita työkaluja, 

joita Lead-periaatteessa käytetään. (Björkholm 2021: 10-11). 

 

Extreme Programming, josta käytetään lyhennettä XP, on kehittynyt vuosien varrella 

ohjelmistotuotannon parhaista menetelmistä. Parityöskentely ja -ohjelmointi yhdistää 

molempien kokemuksen ja usein johtaa parempaan tuottavuuteen ja laatuun. 

(Björkholm 2021: 16-17). 

 

 



18 

 

    

2.1   Scrum perusperiaatteet 

 

Kuten edellä on todettu, niin ketteriä menetelmiä on useita, mutta tässä tutkielmassa 

keskitymme pääasiassa Scrum menetelmään. Vuonna 1986 Hirotaka Takeuchi ja Ikujiro 

Nonaka kuvasivat scrumin kehitysprosessin. Scrum-sana tulee rugby-joukkueesta, jossa 

ryhmä pyrkii etenemään yksikkönä ja tekee tiiviisti yhteistyötä. Scrum-kehittäjiä ovat 

Jeff Sutherlandia, Ken Schwaberia, John Scumniotalesia ja Jeff Mckennaa. Ketterän 

ohjelmistokehitysmenetelmän keskeinen periaate on, että kehitys tiimi asettaa itse 

itselleen tavoitteet ja löytää keinot niiden saavuttamiseksi. Painopiste on 

joustavuudessa ja oppimisessa kierroksen aikana. (Wikipedia 2024, Scrum) 

 

Scrum-prosessi sisältää kolme vaihetta, jotka on esitetty kuvassa 6: esivaihe, 

tuotantovaihe ja jälkivaihe. Esivaiheessa luodaan tuotteen työlista kaikkine 

vaatimuksineen, jotka asetetaan tärkeysjärjestykseen ja niille määritellään 

työmääräarviot. Tässä vaiheessa määritellään myös projektitiimi ja muut projektin 

puitteet sekä korkean tason suunnitelma ja arkkitehtuurisuunnitelma perustuen 

tuotteen työlistan vaatimuksiin.  (Schwaber & Beedle 2002). 

 

Tuotantovaiheessa kukin iteraatiokierros sisältää vaatimusten analysoinnin, 

suunnittelun, toteutuksen, testauksen ja ohjelmiston toimituksen. Tärkeysjärjestyksessä 

olevasta tuotteen työlistasta valitaan iteraatiossa toteutettavat työt, joista muodostuu 

sprintin työlistaan. Yksi iteraatiokierros kestää viikosta kuukauteen, 

iteraatiokierroksessa tehdään useiden tuotteiden palasia ja samaa tuotetta tehdään 

useissa iteraatioissa. Loppupalaverissa katselmoidaan tulokset ja päivitetään 

tekemättömien töiden lista. Kun tekemätöntä toiminnallisuutta ei enää ole, niin 

iteraatiokierros voidaan todeta viimeiseksi. (Schwaber & Beedle 2002). 

 

Jälkivaiheessa suoritetaan ohjelmiston osien integrointi, järjestelmätestaus ja 

dokumentaatio. Lopullinen tuote voidaan toimitta asiakkaalle ja projekti on valmis. 

 



19 

 

    

 

Kuva 6.  Scrum kehys. (Schwaber & Beedle 2002). 

 

 

2.2   Agile-mallinnus käytännössä 

Seuraavaksi kuvaan Agile-mallinnuksen tärkeitä käytännön periaatteita kuten Agile-

mallinnuksen arvot, keskeisimmät periaatteet, organisaatio sekä Scrum toimintatavat 

ja aktiviteetit. 

 

 

2.2.1   Agile-mallinnuksen arvot 

 

Ambler (2002: 19) on jakanut Agilen arvot viiteen päätekijään: kommunikointi, 

yksinkertaisuus, palaute, rohkeus ja nöyryys. 

Ei enää vaatimuksia 

Sprint 

Sprintin 
tehtäväli

sta Tuottee
n 

työlista 

Standardit 
Sopimukset 
Teknologiat 

Resurssit 
Arkkitehtuuri 

Dokument
aatio 

Lopullinen 
julkaisu 

Uusi 
tuotelisäys 

Korkean tason 
suunnittelu, 
arkkitehtuuri 

Järjestelmä
n testaus 

Integraati

o 

Analysointi 
Suunnittelu 
Kehitystyö 

Testaamine
n 

Jakelu 

Esivaihe           Tuotantovaihe              Jälkivaihe 

Säännölline
n päivitys 

Työmääräa
rviot 

Priorisointi 

Suunnittelu 

Vaatimukset 



20 

 

    

Sebestyén (2016: 199-200) on tutkinut eri kommunikaatiomuotoja: kertominen, 

näyttäminen ja toiminnan harjoitus. Taulukko 1 todistaa selkeästi, että näiden kolmen 

kommunikaatiomuodon yhteiskäyttö on kaikista tehokkain sekä lyhyellä, mutta 

varsinkin pitkällä tähtäimellä. 

 

Taulukko 1.  Oppimistehokkuus ja kyky reagoida ajan kanssa. (Sebestyén 2016: 200) 

 Kommunikaatiomuoto 

 Kertoa Kertoa ja 

näyttää 

Kertoa, 

näyttää ja 

toiminta 

Muistaa kolmen viikon päästä 70 % 72 % 85 % 

Muistaa kolmen kuukauden päästä 10 % 32 % 65 % 

 

Kommunikointi on kaksisuuntaista, sillä siinä sekä annetaan että saadaan tietoa. 

Tuotekehitysohjelmiston menestykseen tarvitaan tehokasta kommunikointia, jossa 

koko projektin henkilöstö suunnittelijasta projektin sidosryhmiin kommunikoi 

keskenään. Mallinnus auttaa omien ideoiden kommunikoinnissa, muiden ideoiden 

ymmärtämisessä sekä kokonaiskuvan hahmottamisessa. (Amber 2002: 20). 

 

Ohjelmistokehityksessä yksinkertaistamista ei yksinkertaisesti voi painottaa liian 

paljon! Perusperiaate on pitää tänään mallinnus niin yksinkertaisena kuin mahdollista ja 

murehtia huomisen mahdollisista mallinnushaasteista huomenna. (Amber 2002: 22). 

 

Palautteen saaminen varmistaa, että työ on menossa oikeaan suuntaan. Kehitystiimi 

itsessään on yksi tärkeä palautteen lähde. Jos mahdollista, niin kohderyhmä pitäisi 

osallistua ja antaa palautetta jo tuotekehityksen aikana. Varmin tapa saada palautetta 



21 

 

    

on antaa projektin sidosryhmän käyttää ohjelmistoa. Neljäntenä sidosryhmän 

hyväksyntätestit varmentavat vaatimusten toteutumisen oikealla tavalla. (Amber 2002: 

22-23). 

 

Agile-kehityksen aloittaminen uudessa toimintaympäristössä vaatii rohkeutta. Vain 

tarpeellisen dokumentoinnin tekeminen vaatii rohkeutta. Totuttujen toimintamallien 

kyseenalaistaminen vaatii rohkeutta. Monimutkaisuuden hylkääminen ja 

yksinkertaisuudessa pysyminen vaatii rohkeutta. Priorisointi vaatii rohkeutta. Tiimiin 

luottaminen vaatii rohkeutta. Vaatii rohkeutta myöntää oma vajavaisuus ja virheensä. 

Mutta ennen kaikkea vaatii rohkeutta luottaa, että tulevaisuuden ongelmat pystytään 

ratkaisemaan tulevaisuudessa. (Amber 2002: 24-25). 

 

Parhailla suunnittelijoilla on nöyryys huomata, että he eivät tiedä kaikkea. 

Ohjelmistokehitysprojekti tarvitsee paljon erilaisia kykyjä: laaja-alaista ymmärrystä ja 

syvällistä osaamista. Toisen arvostaminen tasavertaisena asiantuntijana on nöyryyttä, 

joka auttaa menestymään. (Amber 2002: 25-26). 

 

 

2.2.2   Keskeisimmät periaatteet 

 

”Ohjelmisto on sinun päätavoitteesi” (Amber 2002: 28). Upea dokumentointi, mahtavat 

johdon statusraportit tai tuotemallit voivat oli kivoja, mutta jos ne eivät vie 

päätavoitetta eteenpäin, niin niihin ei kannata hukata aikaa. Täytyy löytyä rohkeutta 

keskittyä siihen mikä on tärkeää eli ohjelmistokehitys. (Amber 2002: 28). 

 

”Toinen tavoite on seuraavan ponnistuksen mahdollistaminen” (Amber 2002: 28). 

Laadukkaan ohjelmiston kehittäminen ei yksin riitä, vaan pitää luoda riittävä 



22 

 

    

dokumentointi jatkon tehokkaan mahdollistamiseksi, osaamisen siirtämiseksi 

suunnittelijalta toiselle ja henkilöstön motivoimiseksi. Järjestelmään kehittäessä pitää 

osata pitää silmällä myös tulevaisuutta. (Amber 2002: 28). 

 

Matkusta vähin matkatavaroin haluaa muistuttaa, että kaikki dokumentit ja 

mallinnukset, jotka päätetään pitää, täytyy myös ylläpitää matkan aikana. Vaatii 

rohkeutta ja hyvää kommunikointia karsia ylläpidettävä aineisto mahdollisimman 

pieneksi, mutta kuitenkin riittäväksi. (Amber 2002: 29). 

 

Oletus yksinkertaisen ratkaisun hyvyydestä on toimivat periaate. Yksinkertaisin ratkaisu 

on myös helpoin ylläpitää. 

 

Muutoksia tapahtuu jatkuvasti. Juuri muutokset tekevät ohjelmistokehityksestä niin 

jännittävän! Muutosalttius on Agile-mallintajan peruspiirre. Kun ohjelmisto on 

rakennettu yksinkertaiseksi, niin vaatimusten muuttuminen viime hetkelläkin on 

mahdollista. (Amber 2002: 30). 

 

 

2.2.3   Organisaatio 

 

Agile toimintamallissa on hieman erilainen tapa nähdä organisaatio kuin aiemmissa 

malleissa, sillä metodin mukaan vaikeat asiat pitää yksinkertaistaa niin paljon kuin vain 

mahdollista. Projektiorganisaatio sisältää seuraavat roolit: ohjausryhmä, viiteryhmä, 

projektinomistaja, projektijohtaja, tiimi ja asiakas. (Gustavsson 2007: 51-52).  

 

Näiden lisäksi on olemassa kaksi roolia, jotka harvoin määritellään 

projektimääritelmässä: linjaesimies ja resurssiomistaja. Linjaesimies vastaa ja omistaa 



23 

 

    

tuotteen ja sen arkkitehdin pitkällä tähtäimellä, kun projekti on loppunut. (Gustavsson 

2007: 54). Resurssiomistaja vastaa projektin henkilöstöstä, ja tämä vastuu on usein 

jakautunut usealle päällikölle organisaatiossa. Projektit tyypillisesti sisältävät myös 

materiaali- ja työkaluhankintoja, joten tarvitaan myös taloudesta vastaava päällikkö. 

(Gustavsson 2007: 55). 

 

Ohjausryhmä tulisi olla mahdollisimman pieni, jolloin päätöksenteko on nopeaa ja 

tehokasta. Palaverien tulee olla nopeita ja pitkiä keskusteluja välttävä. Jos päätöstä ei 

pystytä tekemään, niin sekin on tietoinen odottamispäätös ja silloin kirjataan jollekin 

ohjausryhmän jäsenelle lisätutkimistehtävä. (Gustavsson 2007: 56-59). 

 

Viiteryhmässä pitää vähintäänkin olla käyttäjä ja projektitulosten edunvalvoja. Tämä 

foorumi muodostuu kiinnostuneista, jotka voivat vaikuttaa projektituloksiin omilla 

kommenteillaan ja mielipiteillään. (Gustavsson 2007: 60-61). 

 

Tuotteen omistaja määrittelee tuotteen vaatimukset ja niiden prioriteetit toisiinsa 

nähden. Vaatimukset ovat yleensä hajaantuneet eri organisaation osasiin, jolloin 

haasteena on löytää yksi yksittäinen henkilö tähän rooliin. Tuotteen omistajan tulee 

pystyä puhumaan kehitystiimin kanssa samoilla termeillä ja hänen tulee pystyä 

vastaamaan tiimin kysymyksiin liittyen vaatimuksiin ja niiden prioriteetteihin. 

(Gustavsson 2007: 62-64). 

 

Asiakas-rooli voi olla asiakas tai sisäinen projektin tilaaja, joka pystyy määrittelemään 

käytössä olevan budjettitason. (Gustavsson 2007: 65-66). 

 

Projektinjohtajaa kutsutaan Scrum mestariksi erotuksena perinteiseen 

projektipäällikköön, sillä rooleissa on merkittäviä eroavaisuuksia. Scrum mestari on 



24 

 

    

ensikädessä valmentaja eikä johtaja. Hän tukee ja auttaa tiimiä tulemaan niin 

autonomiseksi ja tehokkaaksi kuin mahdollista. Scrum mestari ei tee päätöksiä tiimin 

puolesta, vaan hän on esteiden poistaja ja tiimin menestyksen mahdollistaja. 

Konkreettisia tehtäviä on epäselvien vaatimusten selvittäminen, resurssien hankkija, 

palaverin järjestäjä (päivittäiset-, sprintti- sekä aloitus- ja lopetuspalaverit), 

kommunikointi projektin sisä- ja ulkopuolelle sekä pysäyttää mahdolliset vaikeudet 

mahdollisimman nopeasti. (Gustavsson 2007: 67-71). 

 

Scrum-tiimillä on rygby-joukkuun ominaisuudet: itseohjautuva, selkeä tavoite ja 

kollektiivinen vastuu.  Ryhmänkoko ei saa olla isompi kuin, että jokainen voi nähdä 

jokaisen silmät ja että voi keskustella jokaisen yksittäisen tiimiläisen kanssa. Tiimin pitää 

muodostua jäsenistä, joilla on tarvittavat taidot ongelmien ratkaisemiseen. Kaikilla 

ryhmän jäsenillä pitää olla samat perustaidot ja sen lisäksi joillakin voi olla erityistaitoja. 

Tiimi on itse vastuussa töiden jakamisesta keskenään ja Scrum mestari on ryhmän 

auttaja. Laadun takaamiseksi ohjelmistotiimissä pitää olla myös testaaja. (Gustavsson 

2007: 75-82). 

 

Schwaber (1996) määrittelee, että yhtenä kehitystiimin jäsenenä on laatuvastaava. Näin 

hän pystyy huolehtimaan laadusta koko projektin ajan, ja testien suunnittelu ja tavoitteet 

pysyvät selkeinä kehitystiimille. Nopea palaute on edellytys hyvälle laadulle, joten testit 

pitää automatisoida. 

 

 

2.2.4   Scrum toimintatavat ja aktiviteetit 

 

Schwaber ja Beedle (2002) listaa Scrum-toimintatavat: tuotteen työlista, 

työmääräarviot, sprintti, sprintin tehtäväluettelo, päiväpalaveri, sprinttikatselmus ja 

sprintin jälkikäteistarkastelu. 



25 

 

    

• Tuotteen työlista muodostuu tuotteen vaatimuksista tietyllä ajanhetkellä ja 

vaatimukset ovat työlistalla prioriteettijärjestyksessä.  

• Työmääräarviot, joita tarkennetaan koko ajan, tekevät tuotteen omistaja 

yhdessä kehittäjien kanssa 

• Sprint on iteraatiokierros, jonka aikana tiimi kehittää tuotteesta uuden, 

toimivan version, joka on halutessa valmis asiakkaalle toimitettavaksi. 

• Sprintin tehtäväluettelo sisältää iteraatiokierroksen tehtävälistan, jonka 

kehitystiimi on itse valinnut suunnittelupalaverissa. 

• Päiväpalaverissa seurataan iteraatiokierroksen tehtävien edistymistä. Jokainen 

kehittäjä kertoo kolme asiaa: mitä on tehnyt edellisen palaverin jälkeen, mitä 

aikoo tehdä ennen seuraavaa palaveria ja mahdolliset ongelmat. 

• Sprinttikatselmuksessa sprintin viimeisenä päivänä tutkitaan 

iteraatiokierroksella kehitettyä tuoteversiota ja tuotteen työlista päivitetään.  

• Sprintin jälkikäteistarkastelussa tutkitaan iteraatiokierrosta ihmisten, 

yhteistyön, prosessin ja työkalujen osalta sekä määritellään parannuskohteet. 

 

 

2.3   Sovellukset laajoissa organisaatioissa 

 

On olemassa vain vähän kirjallisuutta, siitä miten ketterät menetelmät tulisi skaalata 

laajoissa organisaatioissa. Tyypillisesti viitekehykset painottavat joko organisaation 

näkökulmaa tai tuote- ja ohjelmistokehitystä. Toimiva ratkaisu skaalaamiseen löytyy 

useiden viitekehyksien, organisaation ketterän kulttuurin ja maalaisjärjen yhdistelmällä. 

(Lekman 2015).  

 

Vaikka kirjallisuutta laajoihin organisaatioihin soveltamisesta on vähän, niin silti pystyy 

muodostamaan selkeän kuvan perusperiaatteisiin nojaten. Jos Agile ei toimi 

organisaation pienessä yksikössä, niin aivan varmasti se ei tule toimimaan myöskään 

laajassa organisaatiossa. Toisaalta jos Agile soveltuu organisaation ajatusmaailmaan ja 



26 

 

    

yksittäisiin ryhmiin, niin silloin sitä pystyy soveltamaan myös useaan ryhmään. Helppoa 

se ei varmasti tule olemaan, mutta ei mikään muutos ole itsessään helppoa vaan kovaa 

työtä. 

 

Voimme tarkastella ketterän menetelmän soveltuvuutta pienii yksikköihin seuraavan 

tavoitelistan avulla (Amber 2002: 312-314).  

• Agile toimintamallia ollaan soveltamassa nimenomaan ohjelmistokehitykseen. 

• Agilen perusperiaatteet voidaan ja halutaan ottaa käyttöön. 

• Ohjelmistokehityksessä käytetään iteratiivista ja inkrementtaalista 

lähestymistapaa. 

• Vaatimukset ovat epävarmoja ja haihtuvia. 

• Päätavoite on ohjelmistokehitys. 

• Sidosryhmä on aktiivinen ja osallistuva. 

• Kehitystiimillä on valtuudet päätöksentekoon, jolloin heillä on mahdollisuus itse 

vaikuttaa onnistumiseensa ja epäonnistumiseensa. 

• Suunnittelijat ovat vastuullisia ja motivoituneita. 

• Organisaatiosta löytyy vähintään yksi, joka on erityisen innokas Agileen 

siirtymisestä. 

• Käytössä on riittävät ja asianmukaiset resurssit. 

 

Vastaavasti seuraava lista valottaa tilanteet, joissa Agile ei sovellu (Amber 2002: 314-

315). 

• Yksi tai useampi edellisestä listasta puuttuu. 

• Organisaation kulttuuri on suunnattu ohjailevaan prosessiin. 

• Tiimi on laaja ja se on jakaantunut 

 



27 

 

    

Mitä sitten tehdä, jos organisaatio ei ole ideaalinen? Ensinnäkin täytyy muistaa pitää 

asiat yksinkertaisena. Hyvä alku on kouluttaa tiimejä ja aloittaa keskustelu. Toiseksi 

täytyy muistaa, että Agileen siirtyminen ei ole helppo päätös. Siihen tarvitaan rohkeutta 

muuttaa ympäristöä ja totuttuja tapoja kuin myös sidosryhmien (erityisesti ylemmän 

johdon) tuki. (Amber 2002: 315-316).  

 

Kun Agile toimintamallia esittelee organisaatiolle, niin vastarintaa syntyy aivan varmasti. 

Yleisimmät organisaation ja kulttuurin haasteet ovat skeptiset suunnittelijat, yli-

innokkaat prosessipoliisit, paperigeneraattorit, keittokirjafilosofia, kyvyttömyys 

hyväksyä oikeaa epäonnistumisen syytä ja laaja dokumentointitarve avainhenkilöiden 

lähdön pelossa. (Amber 2002: 316-320). 

 

Vastaavasti projektitiimin haasteet ovat fyysisesti jakaantunut kehitystiimi, toimitus 

toiselle tiimille ja kiinteä hintainen sopimus. (Amber 2002: 320-321). 

Jos Agile toimintamalliin siirtymisen haasteita on paljon, niin silloin pitää valita jokin 

seuraavista vaihtoehdoista: siirtyä osittain Agileen, luovuttaa Agilen suhteen tai vaihtaa 

työpaikkaa. (Amber 2002: 324). 

 

Faktalista, jos organisaatio on sitoutunut Agileen (Amber 2002: 327-328): 

• Asiakkaat ovat aktiivisesti osallistumassa vaatimuksiin. 

• Vaatimusten muuttaminen on sallittua. 

• Vaatimukset ovat priorisoitu ja korkeimman prioriteetin vaatimukset tehdään 

ensin. 

• Ohjelmistokehitys on iteratiivista ja inkrementaalista. 

• Päätavoite on ohjelmistokehitys eikä dokumentointi. 

• Tiimin jokaisen jäsenen panos on tärkeä. 

• Asiat pyritään aktiivisesti pitämään niin yksinkertaisina kuin mahdollista. 

• Suurin osa kehitysprosessista hylätään. 



28 

 

    

• Asiakasrajapinta tekee liiketoimintapäätökset ja suunnittelijat tekevät tekniset 

päätökset. 

• Mallin sisältö on merkittävästi tärkeämpi kuin sisällön esitysmuoto. 

• Testaaminen on kriittinen mallinnuksen jatkon kannalta. 

 

Laani (2012: 98-99) todennut, että ketterän menetelmän vaikutus ulettuu koko 

yrityksen organisaatioon. Kuvassa 7 on henkilömääräisesti isoin osa-alue eli paikallinen 

projektitiimi kuvataan alimmaisena ja pienimääräisin yrityksen johto kolmion kärjessä. 

Jos ketterää menetelmää käytetään vain kehitystiimissä, niin ongelmaksi muodostui 

tuoteomistajan tuottama priorisoitu vaatimuslista sekä perinteiset 

toimitusvaatimukset aikatauluineen. Ketterän menetelmän laajentaminen koko 

ohjelmistotuotantoon ratkaisi useita ongelmia, mutta toi mukanaan uusia haasteita 

kuten perinteiseen veriputousmalliseen tavoiteasetantaan ja aikatauluun 

sitoutumiseen. Kun ketterä menetelmä laajennettiin koskemaan myös yrityksen 

johtoa, niin päästiin vesiputousmallin kahleista ja liiketoiminta alkoi ajatella uudella 

tavalla. (Laani 2012:98-106).  

 

 

Kuva 7.  Tuotekehitysorganisaation eri ketterän menetelmän sovellustasot.  

Yritys / 
Enterprise

Tuote / 
Ohjelmistoprojekti

Projekti / Tiimi

Liiketoiminta visio ja strategia
- Agile Enterprise

Tuotehallinta
- Agile tuotekehitys 
prosessi 

Ohjelmistohallinta
- Agile ohjelmisto 
kehitys prosessi



29 

 

    

3   Lähtötilanne 

  

Amerikkalaisen keskisuuren IT-yrityksen Suomen yksikön projektit ovat suoritettu 

perinteisellä vesiputousmallilla. Sen lisäksi yksikön 30 henkilön osastolla on kokemusta 

iteratiivisesta mallista, kun he olivat samassa projektissa Amerikan yksikön kanssa. 

Tyypillisesti yrityksen projektien projektihenkilöstö on jakaantunut usealle eri 

paikkakunnalle ja maahan. Projektikieli on englanti, joka on vain harvan äidinkieli. 

Suomen, Amerikan ja Intian väliset kulttuuri- ja aikaerot ovat iso haaste, mutta oikein 

käytettynä myös valtava mahdollisuus käyttää eri kulttuurien vahvuuksia ja 

vuorokauden jokaista tuntia projektin eduksi. 

 

 

3.1   Vesiputousmalli 

 

500 henkilön tuotekehitysorganisaatiossa oli käytössä perinteinen vesiputousmalli, joka 

etenee suoraviivaisesti vaihe vaiheelta kuten kuvassa 8 on esitetty. Alussa tehtiin 

projektisuunnitelma aikatauluineen, henkilöstöineen, tuotteineen ja budjetteineen. 

Kuten varmaan kaikissa tuotekehitysprojektissa suunnitelmissa oli kaksi isoa ongelmaa: 

aikataulu ja tuotteet. Projekti kesti liian kauan ja asiakkaat haluaisivat enemmän 

tuotteita. Projektisuunnitelmaa optimoitiin positiivisella ajatuksella, kunnes siitä 

jotenkin päästiin yksimielisyyteen. Sitten alkoi projekti. 

 

Kuva 8.  Tuotekehitysprojektin vaiheet. 

Esitutkinta
Määrittely 

ja 
suunnitteli

Toteutus Testaus
Asiakastes

taus
Käyttööno

tto
Ylläpito



30 

 

    

Tuotepäällikkö ja projektipäällikkö lähtivät kasaamaan projektia yhteityössä molemmat 

omasta näkökulmasta: tuotepäällikkö tuotteeseen tarvittavia ominaisuuksia ja 

projektipäällikkö organisaation tutkimisella. Projektiorganisaatioon (kuva 9) saatiin 

ensin paikalle tuotepäällikkötiimi, mutta muun organisaation saatavuus olikin ongelma, 

sillä he olivat vielä kiinni myöhästyneissä projekteissa. 

 

Kuva 9.  Tyypillinen projektiorganisaatio. 

 

 

3.1.1   Käytössä ollut tuotekehitysprosessi 

 

Yrityksellä on globaali prosessi ja Suomen yksiköllä on sen lisäksi tarkempi prosessi ja 

nämä molemmat prosessit noudattavat laatujärjestelmää. Kuten taulukossa 2 on 

esitetty globaali prosessi sisältää kuusi vaihetta (MPR, Management Phase Review), 

joista jokainen vaihe päättyy globaalin johtoryhmän katelmointiin ja päätökseen, että 

jatketaanko vai lopetetaanko projekti.  

Program 
Manager

SW1, PM 1& 
CD1

SW2, PM2 & 
CD2

System 
Engineers

HW, PM & 
CD

HW1, PM1

NPI

PTS SW

Documentat
ion

Testing, PM 
& CD

Regression 
test, PM

New feature 
Test, PM

Scalability 
test, PM

System test, 
PM

Product 
Manager

Maintenanc
e PM

Common 
System PM

Controlled 
Intro PM

Architecture 
PM



31 

 

    

Taulukko 2.  Yrityksen globaalin prosessin vaiheet. 

MPR Vaiheen nimi Määritelmä 

0 Esikatselmointi Projektin liikevaihtosuunnitelma ja projektin 

kustannusrakenne 

1 Suunnittelu Tuotteiden määrittelyvaihe alkaa 

2 Toteutus Projektin toteutus alkaa ja tehdään lupaus 

pilottiasiakastoimituspäivästä 

3 Testaus Testaus alkaa sisältäen integrointi- ja järjestelmätestauksen 

4 FCS Toimitus pilottiasiakkaiden tuotantoverkkoon 

5 GA Tuote on yleisesti saatavilla kaikille asiakkaille 

 

Suomen yksiköllä on tarkempi prosessi, joka kuvaa eri vaiheet (QR, Quality Review) 

yksityiskohtaisella tasolla. Sen lisäksi jokaisella osa-alueella on oma prosessinsa kuten 

järjestelmäsuunnittelu, ohjelmistokehitys, laitteistokehitys, dokumentointi, 

integrointitestaus, järjestelmätestaus, projektinhallinta, asiakaspilotointi ja tuotanto. 

Nämä kaikki prosessit ovat keskenään yhteensopivia ja ajan tasalla olevia, sillä 

projektin aikataulussa pysymistä on yritetty korjata kaikilla tavoin. 

 

Suomen prosessin QR-vaiheet linkittyvät saumattomasti globaaliin prosessiin MPR-

vaiheisiin (kuva 10). Tämä ei ole sinänsä yllätys, sillä Suomessa oli kehitetty uusi 

prosessi useita vuosia aiemmin ja sitä oli ylläpidetty ja päivitetty vuosittain. Toisaalta 

globaali prosessi kehitettiin kaksi vuotta aiemmin ja sen pohjaksi oli yllätykseksi otettu 

Suomen prosessi. Tämä oli tietysti myös helpotus, sillä meidän ei tarvinnut muuttaa 

mitään toimintaa sulautuaksemme uuteen globaaliin prosessiin. Samalla tuli 

itsevarmuutta, että me osaamme tehdä jotain oikein, sillä jos meidän prosessi kelpasi 

malliprosessiksi. Suomen QR-vaiheiden katselmointi ja jatkamispäätös tehtiin Suomen 

johtoryhmässä, mutta kun MPR- ja QR-vaiheet linkittyvät niin saumattomasti yhteen, 



32 

 

    

QR-vaiheet päätöspalaverit korvattiin MPR-vaiheen päätöspalaverilla. Huomioitavaa 

on, että Suomen kaksi alkuperäistä vaihetta, QR7 ja QR5, olivat jo jääneet 

tarpeettomina pois. 

 

 

Kuva 10. Suomen yksikön prosessi sulautettuna globaaliin prosessiin. 

 

Suomen prosessi perustui takaisinkytkentää eli kun aiemmissa vaiheissa ollaan tehty 

suunnitelma, niin myöhemmässä vaiheessa testataan tätä suunnitelmaa vasten. 

Arkkitehtuurisuunnitelma ja järjestelmäsuunnitelma tehdään QR8 vaiheessa. QR6 

vaiheessa aloitettiin moduulitestisuunnitelman tekeminen sekä lähdekielisen ohjelman 

toteutus hyväksyttyä arkkitehtisuunnitelmaa vasten. QR4 vaiheessa lähdekielinen 

ohjelmisto oli valmista ja aloitettiin moduulitestaus sekä integrointitestisuunnitelman 

teko. QR3 vaiheessa moduulitestaus oli hyväksytysti läpäisty ja integrointitestaus alkoi. 

QR2 vaiheessa integrointitestaus oli onnistuneesti ohi ja alkoi järjestelmätestaus. 

 

 

3.1.2   Haasteet ja ongelmat todettiin testausvaiheessa 

 

Prosessit ovat hyvin mietittyjä ja niitä noudatettiin hyvin, joten miten ihmeessä projektit 

voivat myöhästyä toistuvasti niin paljon? Esikatselmointi (MPR0) ja suunnitteluvaihe 

(MPR1) onnistuivat yleensä hyvin, kun systeemisuunnittelijat kirjoittivat dokumentit 

ylätason suunnitelmista. Suunnittelijat olivat tällöin tyypillisesti kiireisiä edellisen 

projektin loppuun saattamisessa ja kriittisten vikojen korjaamisessa, joten syvällisiä 

kommentteja perusteluineen ei ehditty tehdä. 

QR9MPR0 QR8MPR1
•QR6

•QR4
MPR2

•QR3

•QR2
MPR3 QR1MPR4 QR0MPR5



33 

 

    

Toteutusvaihe (MPR2) alkoi yleensä aavistuksen myöhässä, mutta suurin ongelma oli se, 

että taitavimmat suunnittelijat olivat vielä kiinni edellisessä projektissa. Tilanne paperilla 

näytti ehkä hyvältä, mutta tosiasia oli se, että edellisen projektin ongelmia ei pysty 

ennustamaan tarkasti, mutta se oli varmaa, että apuun kaivattiin juuri niitä taitavampia 

henkilöitä, jotka olivat avainasemassa uuden projektin pääsuunnittelijoina. 

Valintatilanteessa olemassa oleva projekti, jolla oli kiire asiakkaalle liikevaihdon 

toivossa, sai aina korkeamman prioriteetin. Näin aloitteleva projekti ajelehtii 

epämääräisenä luottaen sitoutuneiden ja osaavien pääsuunnittelijoiden venymiskykyyn. 

 

Ongelmat konkretisoituivat, kun integraatiotestaus pääsi eroon edellisestä projektista ja 

aloitti uuden tuotekehitysprojektin testaamisen. Vanhat testit eivät enää menneetkään 

läpi, sillä integraatiotestaus on ollut täysin edellisen projektin käytössä ja uutta 

lähdekielistä ohjelmaa on tuotettu valtava määrä ilman pääsuunnittelijoiden täyttä 

ohjausta. Yleensä päätettiin, että ohjelmoidaan nyt tuotteet valmiiksi ja korjataan viat 

sitten myöhemmin juuri ennen tuotteen toimittamista asiakkaalle. Tämä kostautui. 

Pahimmissa tapauksissa vikoja ei enää pystynyt korjaamaan ilman arkkitehtuurista 

remonttia, joten edessä oli vaikea päätös: otetaanko vielä lisää aikaa, poistetaanko uusi 

tuote vai poistetaanko vanha tuote. Tämä tapahtui aina loppumetreillä, jolloin aikaa oli 

jo käytetty paljon, sillä ensimmäinen vaihtoehto oli jo valittu useaan kertaan. Lopulta 

jouduttiin tekemään vielä yksi vaikea päätös eli poistamaan jokin vanha, olemassa oleva 

tuote tästä uudesta ohjelmistosta. 

 

Prosessi oli siis kunnossa ja sitä noudatettiin, mutta vain päästäkseen läpi 

katselmoinnista seuraavaan vaiheeseen. Katsantokanta oli, että onko asioita tehty 

oikein ja riittävästi sen sijaan, että paljonko meillä on piilotyötä jäljellä. Esimerkiksi 

toteutusvaiheen loppukatselmoinnissa todettiin, että uusien tuotteiden ohjelmisto oli 

kirjoitettu valmiiksi, joten voimme edetä seuraavaan vaiheeseen. Kun epäröimme, että 

kirjoitettu ohjelmisto voi olla täysi pommi eikä toimi ollenkaan halutulla tavalla, niin 

totesimme, että testaushan on nimenomaan seuraavassa vaiheessa eli hyväksytään 



34 

 

    

äkkiä tämä toteutusvaihe tehdyksi, että päästään testausvaiheeseen selvittämään tätä 

mysteeriä. Testausvaiheessa sitten todettiin, että ohjelmisto on mennyt täysin rikki, 

joten toteutusvaihe alkoi käytännössä alusta. Emme kuitenkaan palanneet prosessissa 

toteutusvaiheeseen, sillä tilanne paljastui vähitellen testauksen edetessä. Lopulta 

totuus oli näkyvissä ja asiakkaalle piti lähteä kertomaan, että hyvin edenneestä 

projektista huolimatta tulemme jälleen kerran myöhästymään paljon. 

 

Asiakkaat olivat todella kärsivällisiä, sillä tuotteet olivat hyviä ja odottamisen arvoisia. 

Suurin syy oli kuitenkin rautainen ammattitaito niin asiakasrajapinnassa kuin 

tuotekehityksessä sekä yhteen hiileen puhaltaminen. Ilman sitä korttitalo olisi hajonnut 

omaan mahdottomuuteensa. 

 

 

3.2   Iteratiivinen malli 

 

Rational Rose iteratiivinen ohjelmistokehityksen prosessi (RUP, Rational Unified 

Process) on kehitetty IBM:llä 2003, mutta se perustuu iteratiiviseen elinkarimalliin 1960-

luvulta. Iteratiivisessa elinkaarimallissa tehdään useita pieniä iteraatiokierroksia, joissa 

jokainen kierros sisältää samat vaiheet kuin vesiputousmallissa eli esitutkinnasta 

ylläpitoon. Jokaisella iteraatiokierroksella syntyy uusi versio sovelluksesta. Kun kaikki 

määritellyt iteraatiokierrokset on tehty, niin tuote julkaistaan asiakkaalle. (Wikipedia 

2024, Rational Unified Process) 

 

Yrityksessämme RUP oli käytössä USA:n toimipisteessä. Kun 30 henkilön Suomen 

tuotekehitysosasto siirrettiin auttaman USA:n tuotekehitystä, niin iteratiivinen 

kehitysmalli oli yksi uusi opeteltava asia. Vesiputousmallin jälkeen se tuntui 

aggressiiviselta hosumiselta, mutta erittäin tehokkaalta ja selkeältä. Ydinasiaksi ja 

suureksi eduksi nousi kommunikoinnin tehokkuus. Tuote muodostui laitteistosta, 

https://en.wikipedia.org/wiki/Rational_Unified_Process


35 

 

    

ohjelmistopaketista sekä EMS-ohjelmistosta. Tässä projektissa uusia laitteistoja tuli 

neljä ja jokaiseen niihin uusi, ladattava ohjelmistopaketti. EMS-ohjelmisto oli yksi 

ladattava ohjelmisto, joka tuki kaikkia näitä neljää uutta laitteistoa kuin myös kaikkia 

aiempia. 

 

Rational Rose Iteratiivista kehitysmallia sovellettiin siten, että koko kehitysjakso jaettiin 

neljään noin kuusi viikkoa kestävään iteraatiojaksoon (kuva 11), jossa tapahtui 

tuotekehitys ja yksikkötestaus. Laitteistokehitys (HW), sulautettuohjelmistokehitys 

(ESW) ja ohjelmistokehitys (EMS) tekivät omat iteraatiosuunnitelmat, joista sitten 

koottiin yksi yhteinen.  Jokaisen iteraatiovaiheen jälkeen alkoi ao. uusien osioiden 

integrointitesti sekä vanhojen tuotteiden systeemitestit.  

 

 

Kuva 11. Rational Rose integraatiomalli yrityksessä. 

 

Koska tuote muodostuu eri osien kokonaisuuksista, niin iteraatiosuunnitelman 

tekeminen vaati paljon kommunikointia eri ryhmien välillä. Integraatioryhmä ei testaa 

Iteraatio 
1

HW I1

ESW I1

EMS I1

Integraatiotestaus 
I1

Systeemitestaus 
I1

Iteraatio 
2

HW I2

ESW I2

EMS I2

Integraatiotestaus 
I2

Systeemitestaus 
I2

Iteraatio 
3

HW I3

ESW I3

EMS I3

Integraatiotestaus 
I3

Systeemitestaus 
I3

Iteraatio 
4

HW I4

ESW I4

EMS I4

Integraatiotestaus 
I4

Systeemitestaus 
I4



36 

 

    

toimintaa ennen kuin se on toteutettu kaikissa kolmessa kehitystiimissä. Kuva 12 

esittää EMS-tuotekehityksen iteraatiosuunnitelman yleiskuvaa. 

 

 

Kuva 12. EMS-tuotekehityksen yleisiteraatiosuunnitelma.  

 

Projekti sisältää useita uusia ominaisuuksia, jotka kehitetään ja testataan pieninä 

palasina eri iteraatioissa. Uuden ominaisuuden kehittäminen tulee aloittaa kaikkein 

vaikeimmasta ja epävarmimmasta osasta, jolloin yllätysten ratkaisemiseen on eniten 

aikaa (kuin jos haastavimmat osat tehtäisiin viimeisessä iteraatiossa). Kuva 13 esittää 

iteraatioiden integraatiotestaussuunnitelmaa, joka siis pohjautuu eri tuotekehityksen 

(HW, ESW ja EMS) iteraatiosuunnitelmiin. 

 

Valmistelu

•Yleissuunnitelma eri iteraatioiden sisällöstä

•Järjestelmäspeksit Iteraatio 1:n suunnitelmiin

Iteraatio 1

• Iteraatio 1:n lähdekielinen ohjelmisto ja yksikkötestaus

•Ohjelmistojulkaisu Iteraatio 1 + release note

•Järjestelmäspeksit Iteraatio 2:n suunnitelmiin

Iteraatio 2

• Iteraatio 2:n n lähdekielinen ohjelmisto ja yksikkötestaus

• Iteraatio 1:n viankorjaus

•Ohjelmistojulkaisu Iteraatio 2 + release note

•Järjestelmäspeksit Iteraatio 3:n suunnitelmiin

Iteraatio 3

• Iteraatio 3:n n lähdekielinen ohjelmisto ja yksikkötestaus

•Viankorjaus

•Ohjelmistojulkaisu Iteraatio 3 + release note

•Järjestelmäspeksit Iteraatio 4:n suunnitelmiin

Iteraatio 4

• Iteraatio 4:n n lähdekielinen ohjelmisto ja yksikkötestaus

•Viankorjaus

•Ohjelmistojulkaisu Iiteraatio 4 + release note



37 

 

    

 

Kuva 13. Integraatiotestaussuunnitelma yhdelle uudelle toiminnolle.  

 

Iteratiivinen kehysmalli oli tehokas ja toimiva, mutta ennen kaikkea erittäin 

kommunikoiva. Kun kahden vuoden projekti loppui, niin 30 henkilön Suomen 

tuotekehitysosasto palasi yrityksen Suomen tuotekehityksen tehtäviin. Siellä oli 

edelleen käytössä vesiputousmalli eikä yrityksen Suomen tuotekehityksen johto ollut 

vielä kiinnostunut iteratiivisen tai scrum-kehitysmalliin siirtymisestä. 

 

 

3.3   Haasteet 

 

Pitkän aikataulun perusteella voimme todeta, että tämän yrityksen 

tuotekehitysprojektien suurimmat haasteet ovat aikataulussa pysyminen, sovitun 

sisällön tuottaminen sekä laatu. Margaret Combe on todennut (Dye 1999: 363-364), että 

laajan organisaation haaste on sovittaa samanaikaisesti sekä kasvu- että 

ylläpitostrategia. Voimme todeta, että ongelmat ovat vuosikymmenestä toiseen samat, 

Iteraatrio 
1

Tuotteen 
lisäys ja 
poisto

•HW: -

•ESW: -

•EMS: lisäys ja 
poisto

Iteraatio 
2

Tuotteen 
lisäys ja 
poisto

•HW: prototype 
V0.1

•ESW: lisäys ja 
poisto

•EMS: elementin 
muokkaus

Iteraatio 
3

Elementin 
muokkaus

•HW: prototype 
V0.1

•ESW: elementin 
muokkaus

•EMS: 
Bugikorjaus

Iteraatio 
4

Elementin 
muokkaus

•HW: prototype 
V1.0

•ESW: 
Bugikorjaus

•EMS: 
Bugikorjaus



38 

 

    

sillä kasvu on käytännössä uutta sisältöä ja ylläpito laatua. Myös ratkaisut olivat edelleen 

hyvin samansuuntaiset eli tee selkeä strategia, jalkauta vastuu jokaiselle saavuttamaan 

tuo strategia ja mittaa saavutuksia tuota strategiaa vasten (Dye 1999: 368). Tulokset 

eivät kuitenkaan ole niin lupaavia, sillä varsinkin laajassa projektissa myös strategia on 

laaja, joten sen pilkkominen ja jakaminen koko organisaatiolle siten, että strategia on 

edelleen muuttumaton esim. kuuden kuukauden päästä on haastavaa, ellei jopa 

mahdotonta.  

 

Asiakkaan suurin pettymys on myöhästyvä aikataulu, sillä yrityksen antaman 

etenemissuunnitelma (= aikataulu + sisältö) perusteella asiakas suunnittelee omat 

päivityksensä ja omien asiakkaiden kommunikoinnin. Kyseessä saattaa olla hyvinkin 

laaja hanke, jossa yrityksemme on mukana vain yhtenä toimittajana. Kun muiden 

toimittajien laitteistoja ostetaan ja asennetaan aikataulun mukaan ja meidän laitteet ja 

ohjelmisto ovat myöhässä, niin asiakas joutuu hankalaan tilanteeseen. Hänen on 

mietittävä, että lykkääkö hän koko päivitystä tai tekeekö kaksi päivitystä (ensin muiden 

toimittajien ja sitten meidän myöhässä oleva). Tämä on kallista, kun aikataulu on 

myöhässä yli neljä kuukautta kuten kuva 14 esittää yrityksen viimeisestä 

vesiputousmallilla suoritetusta projektista. 

 

 

Kuva 14. Tuotekehitysprojektin aikataulusuunnitelma ja sen toteutuminen. 

MPR2

28-3-2009

6-7-2009

14-10-2009

22-1-2010

2-5-2010

10-8-2010

18-11-2010

26-2-2011

6-6-2011

14-9-2011

23-12-2011 T8600 FP3.1 Project Milestone Schedule 
Tracking

Today
MPR1
MPR2
MPR3
MPR4
MPR5



39 

 

    

Sovitun sisällön vaihtuminen ei käytännössä ole ollut ongelma, sillä yrityksen 

asiakasrajapinta tuntee hyvin asiakkaat ja neuvottelee sisällöstä ja sen pois jättämisestä. 

Käytännössä kaikkein tärkeimpiä asiakkaita kuunnellaan hyvin tarkasti, että he 

jatkossakin ostaisivat paljon ja tuottaisivat liikevaihtoa. Jos tärkeiden asiakkaan 

suunnitelmat muuttuvat, niin silloin sovitun uuden toiminallisuuden tärkeys laskee ja jos 

tuotekehityksessä on ongelmia, niin ominaisuus voidaan tiputtaa kokonaan pois. Kuva 

15 esittää yrityksen viimeisen vesiputousmallilla suoritetun projektin sisällön muutoksia. 

Kuvasta voi todeta, että sisältö on kasvanut projektin edetessä. Käytännössä lisätyt 

ominaisuudet ovat pieniä parannuksia, joiden tärkeys asiakkaalle on kasvanut sitä 

mukaa kuin projekti on myöhästynyt. 

 

 

Kuva 15. Projektin tuotteiden määrän (y-akseli) suunnittelu ja toteutus kuukausittain.  

 

Laadusta tulee ongelma, kun laitteiston myynti kasvaa ja kaikkea mahdollista asiakkaan 

konfiguraatiota ei pystytä ennustamaan ja testaamaan. Silloin pitää tehdä päätöksiä, 

että miten testataan ja toisaalta, että miten tulkitaan testitulosten vakavuutta. Päätös 

panostaa laatuun eikä uusiin ominaisuuksiin ei ole yksiviivainen. Uusien ominaisuuksien 

tekeminen laadun kustannuksella taas tulee maksamaan tulevaisuudessa paljon. 

 

0

5

10

15

20

25

30

35

40

1-2-2010 1-4-2010 1-6-2010 1-8-2010 1-10-2010 1-12-2010

T8600 FP3.1 Feature Change Rate
MPR2 Features In Scope MPR2 Features Not In Scope

Features Added after MPR2 In Scope Committed MPR2 Features

Total Features In Scope



40 

 

    

Henkilöstön usko omaan tekemiseen ja johtoryhmän päätöksen on haaste, joka syö 

positiivista ilmapiiriä ja innovatiivista intoa sisältäpäin. Jos tuotekehitystiimi ”tietää” jo 

projektia aloitettaessa, että se tulee myöhästymään eikä jaksa siitä enää raportoida 

katselmointikommenttina, niin tiimi ei selkeästi enää luota projektin johtoon. Silloin on 

aivan varma, että projekti tulee takuuvarmasti myöhästymään. Mutta miten saada 

kaiken nähneen ja kokeneen tuotekehitystiimin uskomaan, että tällä kertaa me oikeasti 

kuunnellaan teitä? Ja uskommeko itse, että tilanne on jotenkin merkittävästi toinen juuri 

tällä kertaa? 

 

Projektin ohjausryhmän lisäksi projektia seuraa yrityksen Suomen sekä Amerikan johto. 

Tässä törmätään kulttuurieroihin. Siinä missä Suomessa on totuttu raportoimaan 

haasteet, niin Amerikassa raportoidaan saavutukset. Suomessa saavutukset vain 

sivutetaan nopeasti, että päästään käsittelemään oikeita ongelmia yhdessä. Amerikassa 

ongelmat raportoidaan nopeasti positiivisin sanakääntein korjauslistan kanssa. Tässä on 

paljon opittavaa puolin ja toisin, mutta tosia-asia on se, että yritys on amerikkalainen ja 

Amerikassa tehdään isot päätökset, joten Suomen osa-alueen on opittava heidän 

raportointitapansa. 

 

Projektin henkilövuosisuunnitelma suurenee jokaisesta myöhästymisestä ja lisää 

projektin kustannuksia kuten kuva 16 osoittaa. Projekti on myöhässä yli neljä kuukautta, 

jolloin suunniteltu henkilöstötarve on yli neljä kuukautta pidempi. Sen lisäksi projekti on 

ylittänyt suunnitellun henkilöstöbudjetin jo kahdeksan kuukautta aiemmin, kun 

huomattiin, että tavoitteessa ei pysytä. Kaiken kaikkiaan henkilöstösuunnitelma yli 

kaksinkertaistui suunnitellun 1138 henkilöstökuukaudesta 2414 henkilöstökuukauteen. 

On sanomattakin selvää, että tämä on erittäin kallista yritykselle sen lisäksi, että projekti 

oli vielä myöhässä, jolloin takaisinmaksu tulee suunniteltua myöhemmin. 



41 

 

    

 

Kuva 16. Projektin kumulatiivinen henkilövuosisuunnitelma ja –toteutuma 
miestyökuukausina. 

 

 

3.4   Tavoitteet 

 

Tuotekehitysprojektien yksinkertainen tavoite on liikevaihdon lisääminen, joka onnistuu 

asiakkaiden liikevaihdon lisäämisen takaamisella. Tästä päästään tosiasiaan, että pitää 

tuntea asiakkaan tarpeet ja on pystyttävä vastaamaan niihin silloin kun asiakas niitä 

tarvitsee. 

 

Edellisen tuotekehitysprojektin palautteesta on tehty kehitystavoitteet 

• Pidä ohjelmistotuotteen laatu tasaisena ja korkeana. 

• Rohkaise kehitystiimejä antamaan realistiset aika-arviot ja toimintasuunnitelma 

aikataulumyöhästymisien välttämiseksi. 

• Tarkka tuotemäärittely pitää tehdä yhdessä toteutuksen kanssa. 

 

0

500

1000

1500

2000

2500

3000

T8600 FP3.1 Project Effort (in staff months)

Actual Planned Forecast



42 

 

    

Yritys oli tilanteessa, että yhteenkään epäonnistumiseen ei ole enää varaa. Nyt on 

tehtävä jotain radikaalisti toisin, otettava isoja riskejä, sillä saman jatkaminen johtaisi 

väistämättömään tuhoon. Agile-kehityksestä on paljon positiivisia kokemuksia ja 

tuloksia, mutta miten se soveltuisi näin laajaan tuotekehitysorganisaatioon? 

 

Toinen kysymys oli aika, sillä sitä ei nyt ole. Käytännössä Agileen pitäisi siirtyä 

välittömästi, mutta uuteen malliin siirtyminen näin laajalla joukolla tarvitsee 

pilotointiaikaa, kokeilua ja suunnittelua. Ja juuri aikaa ei nyt ole. 

 

Kommunikointiin tarvittaisiin myös aikaa, sillä Amerikan ylin yritysjohto on nähnyt 

aikatauluista lipsumista liikaa eikä ole myötämielinen uusille, riskialttiille 

projektinjohtomenetelmän muuttamiselle.  

 

Ja miten asiakkaat suhtautuvat? Kuinka he jaksavat ottaa vastaan uuden toimintatavan, 

kun heidän asiakkaat huutavat uusia toimintoja ja ominaisuuksia mahdollisimman 

nopealla aikataululla? Kun asiakkaille kerrottiin uudesta toimintamallisuunnitelmasta, 

niin he yllättivät täysin positiivisella vastaanotolla. He näkivät vaikutusmahdollisuutensa 

tuotteiden sisältöön ja julkaisuaikatauluun.  

 

Tonnquistin (2024: 409) mukaan ohjaus ja johtamismallit määrittelevät, että miten 

projekteja tulee ohjata ja johtaa kuin taas kehitysmalli määrittelee, että kuinka tulokset 

otetaan esille (usein hyvinkin tarkalla tasolla). Yrityksen projektit on nimenomaan 

ohjattu ja johdettu määriteltyjen päätöspisteiden mukaan (kuva 17), jossa ollaan 

katselmoitu, että miten projekti on onnistuttu johtamaan. Dynaamiset kehitysmallit, 

kuten esimerkiksi Agile ja Scrum, ovat malleja, joissa keskitytään suorittamaan pieniä 

virstanpylväitä (kuva 14), jotka sisältävät mahdollisuuden toimittaa asiakkaalle tämän 

pienen virstanpylvään sisällön eli esimerkiksi ohjelmistotuotteen. 

 



43 

 

    

 

 

Kuva 17. Kehitysmallit (Tonnquist 2024: 409). 

 

Tässä tilanteessa on paljon epävarmuutta ja riskinottoa, mutta jotain on muutettava ja 

nopeasti sillä muuten yritys kokee suuren alamäen. Toisaalta taas yrityksen Suomen 

johto- ja tuotekehityshenkilöstö ovat pitkään yrityksessä olleita huippuasiantuntijoita, 

jotka ovat valmiita venymään mihin vain, että tämä huippuosaaminen saadaan 

asiakkaiden käyttöön ja omaksi liikevaihdoksi.  

 

Päätös oli tehty: siirrymme Scrum-projektinvetomalliin nopeasti soveltaen. Sitten 

voimme ainakin sanoa, että kaikkemme yritimme viimeiseen asti! Yritetään siis toimia 

250 tuotekehityshenkilön kanssa siten, että asiakas saa mahdollisimman oikean 

tuotteen mahdollisimman oikeaan aikaan!  

 

  

Ohjausmalli Ohjata

Johtamismalli Johtaa

Kehitysmalli Suorittaa

      Päätöspiste 

      Virstanpylväs 



44 

 

    

4   Työn rakenne 

 

Tässä kappaleessa kuvataan tämän tutkielman rakenne. Tutkielman tarkoitus ja 

tavoitteet sekä tutkimuskysymykset ovat kuvattuna jo tutkielman kappaleessa 1.1. Tässä 

jatketaan kuvaamalla tutkimusainestoa eli kohdeorganisaatio. Toiseksi esitellään 

tutkimusstrategia eli case-tutkimus. Lopuksi tarkastellaan tutkielman toteutusta ja 

analysointia.  

 

 

4.1   Tutkimusaineisto  

  

Tässä tutkielmassa havainnoin kansainvälisen keskisuuren IT-yrityksen laajaa 

tuotekehitysprojektia. Yritys on amerikkalainen ja havainnointi tapahtuu Suomesta. 

Projektin kolmas kansallisuus on intialainen yritys, jota käytetään alihankintana. Tässä 

tutkielmassa kaikki tuotekehitysprojektit johdetaan ensimmäistä kertaa saman 

sateenvarjoprojektin alla. Henkilömäärä on 250 ja tutkielman tekijä toimi 

projektipäällikkönä. 

 

Tutkielmassa käytetty aineisto on kerätty aikavälillä 2011 – 2013, jolloin alussa vielä 

käytettiin vesiputousmallia ja 2013 koko organisaatio siirtyi ketterään menetelmään. 

Työn pääpaino on tarkastella tilannetta teoreettisen viitekehyksen läpi.  

 

Seuraavaksi esittelen kolme tyypillistä palautepuheenvuoroa 2011 

projektipalautteesta.   

  

”Teillä on loistava tuote ja innovatiivinen, hyödyllinen sovellus, mutta aikataulun 

siirtyminen ja sisällön muuttuminen kerta toisensa jälkeen syövät meidän 



45 

 

    

asiakasuskottavuuttamme. Haluamme, että annatte sellaisen aikataulun, joka oikeasti 

pitää.” (Asiakas).  

 

 ”Asiakas on tyytyväinen tuotteeseen, mutta myöhästymisen takia myynti ja sitä myötä 

rahavirta ovat auttamattomasti myöhässä.!” (Yrityksen johto).  

  

”Aikataulussa pysymisen on tärkeää ja alussa uskonkin siihen. Matkan varrella 

projektiin kuitenkin lisätään asiakkaalle tärkeitä sovelluksia, vaikka aikatauluongelmia 

on jo nykyisenkin sisällön kanssa.” (Projektipäällikkö).  

  

 

4.2   Tutkimusstrategia eli case-tutkimus  

 

Tässä tutkielmassa käytetään Case-tutkimusta, joka on havainnoivaa ja sopii hyvin 

ongelmalähtöiseen tutkielmaan kuten uuden kehitysprosessin käyttöönotto 

organisaatiossa. Tapaustutkimuksessa on tärkeä tapauksen määrittely, analysointi sekä 

ratkaisu. (Wikipedia 2024, Tapaustutkimus). 

 

Case-tutkimuksessa tutkitaan ja analysoidaan tapauksen taustalla olevia tekijöitä, syy-

seuraussuhteita sekä ympäristöä. 

”Laadullisiksi nimitetyt tutkimukset rakentuvat Töttöä (2004, 9-20) mukaillen 1) 
aiemmista, tutkittavasta aiheesta tehdyistä tutkimuksista ja muotoilluista 
teorioista, 2) empiirisistä aineistoista (suurimmaksi osaksi tekstimuotoisia tai 
sellaiseksi muutettuja aineistoja) sekä 3) tutkijan omasta ajattelusta ja 
päättelystä.” (Saaranen-Kauppinen & Puusniekka 2009: 9). 

 

 



46 

 

    

Yiniä (2009) mukaillen Case-tutkimuksen pääpiirteet ovat  

1. Tarkastellaan tutkittavaa aihetta syvällisesti. 

2. Huomioidaan ympäristö, historia ja muut vaikuttavat alueet.  

3. Hyödynnetään monipuolisesti kirjallisuutta, haastatteluja ja havaintoja. 

4. Käytetään yleisesti tiedossa olevaa teoreettista mallia, jota testataan tutkielman 

aikana.  

5. Pyritään ymmärtämään laajasti ja yleistämään, jos mahdollista.  

 

 

4.3   Tutkimuksen toteutus ja analysointi  

 

Tutkielma toteutettiin analysoimalla lähtötilanne. Keskeinen lähde oli palaute, jota tuli 

niin asiakkailta, ylimmältä johdolta kuin projektitiimeiltä. Amerikkalainen yli johto antoi 

enää yhden mahdollisuuden, joten Suomalainen yksikkö oli pakko-onnistumisen edessä. 

Ketteristä menetelmistä oli puhutta yrityksen sisällä ja muutama ryhmä yrittänytkin 

käyttää niitä, joten tiedettiin niiden hyödyt ja ymmärrettiin myös, että koko organisaatio 

pitää siirtyä käyttämään ketteriä mentelmiä. Toisaalta myös tiedettiin, että näin ison 

organisaation muuttaminen yhdessä yössä vesiputousmallista ketteräksi menetelmäksi 

on suuri riski -ellei jopa tuhoon tuomittu yritys. Näin kuitenkin päätettiin tehdä. 

 

Ostettiin muutama Agile konsulttipäivä auttamaan ylätason organisaatiokaavio 

tekemisessä, ja sitten vain alettiin systemaattisesti tiedottamaan sekä kuuntelemaan 

tuotekehitystiimien vastarintaa. Osa keskeisistä ja kokeneista pääsuunnittelijoista 

pitivät muutosta järjettömänä ja riskialttiina, mutta kun he ymmärsivät, että muuta 

vaihtoehtoa ei ole ja nyt pitää keskittyä tekemiseen eikä jo tehdyn päätöksen 

analysoitiin, niin tiimit saatiin puhaltamaan samaan hiileen. 

 



47 

 

    

Keskeisessä asemassa oli kommunikaatio ja läpinäkyvyys, että kehitystiimit voivat 

luottaa keskijohdon osaamiseen ja voivat itse keskittyä omaan osaamisalueeseensa. 

Kehitystiimit kokivat projektipäällikkö luotettavaksi, rehelliseksi ja tasapuolikseksi, joten 

kolmen viikon välein tapahtuvat koko projektia käsittävä informaatiopalaverit olivat 

keskeisessä osassa niin tiedon jakamisen kuin myös opetusmielessä. Siellä mitattiin 

kehitystiimin itse itselleen asettamia tavoitteita heidän sprint saavuttamiin tavoitteisiin.  

 

Ensimmäisen sprintin jälkeen vain intian tiimit olivat saavuttaneet tavoitteensa. Tämä 

oli äärimmäinen kolaus taivataville Suomen tiimeille ja he purnasivat, että intian tiimien 

tavoitteet olivat lapsellisen helppoja ja toisaalta ne olivat kysyneet heiltä apua niidenkin 

tekemiseen. Oppiminen tapahtui hitaasti, mutta varmasti, sillä intian tiimit olivat 

toimineet sinänsä Agilen mukaisesti, mutta Suomen tiimien ei pidä auttaa heitä, jos siitä 

ei ole etukäteen sovittu ja jos se ei ole heidän työtlistalla.  

 

Toisaalta Suomen tiimien pitää miettiä, että pitääkö jokaisen toiminnan olla 100%:sti 

tehty vai voisiko 70% riittää asiakkaan tarpeisiin? Tavoitteena on miettiä, että mikä on 

minimi, mitä asiakas tästä ominaisuudesta tarvitsee? Toteutetaan se ja laitetaan loput 

tulevaisuuden työlistalle ja otetaan seuraava tärkeä ominaisuus työalla 

minimitavoitteineen. Tämä oli valtava muutos, mutta kun sitä toistettiin, niin siitä 

alettiin näkemään hyötyjä. Ensimmäistä kertaa pääsuunnittelijoille tuli tunne, että me 

tosiaankin saadaan toimivia, pieniä palasia valmiiksi. 

 

  



48 

 

    

5   Ketterän menetelmän soveltaminen laajaan projektiin 

 

Meillä on siis 250 tuotekehitysinsinööriä kolmessa eri maassa neljällä eri paikkakunnalla. 

Laaja asiakaskunta, joka on innostunut tuotteesta, mutta kyllästynyt jatkuviin 

myöhästelyihin ja laatuongelmiin. Kilpailijat, jotka saavuttavat etulyöntiasemaamme 

joka kuukausi moninkertaisella tuotekehityshenkilöstöllään. Yrityksen amerikkalainen 

johtoryhmä, joka näkee laatuongelmat ja myöhästelyt, mutta ei välttämättä 

potentiaalia. Osakkeen omistajat, jotka vaativat tuloksia neljännesvuosittain.  

 

Vesiputousmallia on kokeiltu vuosikymmenet ja se on tiensä päässä. Sovellettua Scrum-

mallia kokeiltiin laajassa tuotekehitysprojektissa muutamalla ohjelmistotiimillä. Siinä 

todettiin, että osittain soveltaminen ei tuota tarvittavaa tulosta, joten on vain 

uskallettava siirtää koko tuotekehitys scrum-malliin. Toisaalta taas olemme yksi osa 

laajaa kansainvälistä yritystä, jolla on omat prosessinsa, joista ei ole lupa joustaa. 

Amerikan laatutiimi oli erittäin huolestunut tulevista muutoksista. Lukemattomista 

yrityksistä huolimatta he eivät suostuneet ymmärtämään, että muutoksessa 

raportoimme oleellista tietoa paljon aiempaa enemmän, vaikka jätämmekin 

epäoleellisen tiedon mittaamatta. Prosessiin ei ole tulossa mitään muutosta ketterän 

menetelmän soveltamisen helpottamiseksi. Lopulta yksinkertaistimme kommunikointia 

kertomalla, että seuraamme täysin olemassa olevaa prosessia. Yrityksen ylin Amerikan 

johto rauhoittui, ja laatutiimi halusi sukeltaa meidän scrum-metriikkaamme.  

 

Jos vielä vertaamme tuotekehityksen tilannetta aiempiin tavoitelistaan (kappaleessa 2.3 

Sovellukset laajoissa organisaatiossa), niin huomaamme, että ketterään menetelmään 

siirtyminen sisältää paljon riskejä. 



49 

 

    

• Ketterään menetelmään siirtymisessä tarvitaan rohkeutta muuttaa ympäristöä 

ja totuttuja tapoja kuin myös sidosryhmien (erityisesti ylemmän johdon) tuki. 

Valitettavasti meillä ei ole Amerikan ylimmän johdon tukea ollenkaan. 

• Suurin osa kehitysprosessista hylätään. Valitettavasti mitään ylätason 

prosessimuutoksia ei sallittu, vaan olemassa olevaa prosessia pitää edelleenkin 

noudattaa kuten vesiputousmallissakin. 

• Tiimi sijaitsee samassa toimitilassa. Valitettavasti tiimi on laaja ja jakaantunut 

kolmeen eri maanosaan. 

• Ohjelmistokehityksessä käytetään iteratiivista ja inkrementtaalista 

lähestymistapaa. Valitettavasti vain pienimuotoinen pilotti on tehty ja suurin 

osa tuotekehityksestä seuraa edelleenkin vesiputousmallia.  

• Vaatimukset ovat priorisoitu ja korkeimman prioriteetin vaatimukset tehdään 

ensin. Valitettavasti suurin osa vaatimuksista ovat kriittisiä ja asiakasrajapinta ei 

ole pystynyt laittamaan niitä tärkeysjärjestykseen. 

• Näiden lisäksi ohjelmistoprojektiin kuuluu kiinteästi laitteistotiimit, jotka 

kehittävät fyysisesti uudet tuotteet ohjelmistotuotekehityksen rinnalla.  

 

Kaikesta vastarinnasta ja riskeistä huolimatta päätimme siirtyä ketterään 

tuotekehitykseen, sillä saman toimintatavan jatkaminen olisi varman epäonnistuminen. 

Seuraavaksi esitellään ketterän tuotekehitysprojektin keskeisimmät tiedot. 

 

250 henkilön projektitiimi rooleihin jaettuna (maa) 

• 1 projektipäällikkö (Suomi) 

• 10 aliprojektipäälliköitä (Suomi ja USA) 

• 3 tuotepäällikköä (Suomi) 

• 11 systeemisuunnittelijoita (Suomi ja USA) 

• 125 ohjelmistosuunnittelijoita (Suomi, USA ja Intia) 

• 15 laitteistosuunnittelijoita (Suomi) 



50 

 

    

• 61 uuden tuotteen testisuunnittelijoita (Suomi, USA ja Intia) 

• 15 Regressiotestaus yms. testaus 

• 9 sekalaista: tuotemuutokset, pilottitestaus, systeemitestaus 

 

Ohjausryhmä 

• Projektipäällikkö 

• Projektihallinnan vetäjä 

• Tuotekehitysjohtaja 

• Tuotehallinnanjohtaja 

• Tekninen johtaja 

 

Johtoryhmä 

• Ohjausryhmä 

• Suomen toimitusjohtaja 

• Amerikan tuotekehitysjohtaja 

• Amerikan laatujohtaja 

 

 

5.1   Vaatimusten priorisointi 

 

Ensimmäinen vaihe on suunnitteluvaihe. Siinä projektipäällikkö yhdessä 

systeemisuunnittelijoiden ja tuotepäälliköiden kanssa hahmottaa asiakkaan tarpeita, 

aikatauluarviota, tuotekehitystiimin osaamista ja vapautumista edellisestä projektista. 

Projektihenkilöstö oli alle 20 henkilö. Koska kyseessä on hyvin luova vaihe, niin ketterän 

menetelmän soveltaminen ei tähän sovellu. Mutta koulutusmielessä puhuimme 



51 

 

    

kuitenkin ”scrum-kieltä”, sillä on erittäin oleellista, että tulevat tuotteenomistajat 

alkavat sisäistää scrum-metodologiaa ja -termejä.  

 

Keskeiseksi aiheeksi nousi vaatimus-lista. Tajusimme matkan varrella, että meillä on 

monenlaista priorisoitavaa ennen kuin projekti alkaa: tuotepäälliköt priorisoivat 

asiakkaiden toivomia ominaisuuksia ja systeemisuunnittelijat priorisoivat tuotteen 

teknologiaominaisuuksia. Nämä pitää saada samalle listalle ja saman priorisoinnin 

piiriin, että ketterää menetelmää pystytään hyödyntämään.  

 

Tästä syntyi kauan toivottu Excel-taulukko, johon kaikki toivotut uudet ominaisuudet 

olivat listattuna. Taulukkoon laitettiin paljon yksityiskohtaistakin tietoa, mutta pääasia 

oli, että nyt uudet ominaisuudet olivat listassa prioriteettijärjestyksessä. Listaan 

laitettiin myös työmääräarvioita. Mitä korkeampana ominaisuus oli listalla, niin sitä 

tarkempia speksejä ja arvioita siitä aloitettiin tekemään. Tämä ei aina ollut helppoa, sillä 

kärkituotteet olivat yleensä hyvin hankalia ja vaikeita. Mutta scrumin metodologian 

mukaisesti noudatimme tätä. 

 

Vähitellen projektin ylätason suunnitelma alkaa muotoutua. Esiin nousivat 

ominaisuudet, jotka ovat aivan pakko saada työnalle. Oli pakko priorisoida, että tärkein 

ominaisuus on organisoitava ensimmäisenä ja sille on etsittävä parhaat tekijät –vaikka 

se tarkoittaisi, että ”pikkuhomma” sijalla viisi jää tekemättä. Tämä oli hyvin vapauttavaa, 

sillä ennen näitä lukuisia ”pikkuhommia” on otettu työnalle, jolloin asiakkaalle on saatu 

ominaisuuksia, mutta se tärkein ominaisuus jää aina aloittamatta. Nyt se otetaan 

työnalle ensimmäisenä! Näin yksi aiemmin esitetty riski on saatu poistettua: 

Vaatimukset ovat priorisoitu ja korkeimman prioriteetin vaatimukset tehdään ensin. 

 

 



52 

 

    

5.2   Organisaation luominen 

 

Kolmessa maassa olevien 250 tuotekehityssuunnittelijan organisointi scrum-tiimeihin ei 

ollut ihan suoraviivainen asia. Periaatteeksi haluttiin, että tiimin on oltava samalla 

paikkakunnalla, mieluiten samassa rakennuksessa kuten aiemmin esitetty tavoite 

määritteli: Tiimi sijaitsee samassa toimitilassa. Tämä poissulki osaavien suomalaisten 

huippusuunnittelijoiden ja uusien kansainvälisten suunnittelijoiden samaan tiimiin 

laittamisen, joka olisi tiedon oppimisen lisäksi sulattanut myös kulttuurieroja. Ajatus oli 

siis muodostaa itsenäisiä scrum tiimejä kolmeen eri maahan. 

 

Seuraava päätös oli, että laitetaanko scrum-menetelmien mukaisesti testaajat scrum-

tiimeihin. Testisuunnittelijat ovat muotoutuneet vuosien varrella huippuasiantuntijoiksi, 

jotka tekevät uskomattoman määrän työtä ja joustavat aina. He ovat omassa 

organisaatiossa, jossa he tukevat toisiaan hyvässä, positiivisessa hengessä. Toisaalta 

taas nämä testisuunnittelijat ovat erittäin palveluhenkisiä ja toteuttavat joustavasti 

systeemi – ja ohjelmistosuunnittelijoiden toiveita. Samassa tiimissä 

testisuunnittelijoiden taidot laajenevat entuudestaan ja myös heidän laaja 

systeeminäkemys saataisiin ohjelmistosuunnittelijoiden tietouteen, jolloin 

todennäköisesti vältyttäisiin isoilta, kohtalokkailta virheiltä, jotka maksavat paljon 

projektin loppuvaiheessa. Kolmanneksi testisuunnittelijoita on erittäin vähän, joten 

miten vähästä jaetaan moneen tiimiin. Päätettiin, että laitetaan testisuunnittelijat 

scrum-tiimiin, mutta pidetään heidät matriisiorganisaation mukaisesti 

testiorganisaatiossa, jossa testipäällikkö on heidän esimiehensä ja vastaa testauksen 

kehittämisestä. 

 

Kolmas keskeinen päätös oli Scrum mestareiden valinta, tiimien koko ja henkilöstö. 

Olemassa olevista projektipäälliköistä leivottiin Scrum mestarit. Scrum-periaatteiden 

mukaisesti scrum-tiimin koko oli 7 +- 2 henkilöä. Testaajien mukaan tulo lisäsi tiimin 



53 

 

    

koon ylälukemiin, mutta jokainen tiimi käsiteltiin erikseen ja valittiin paras mahdollinen 

lähestymistapa. Jotkin tiimit sisälsivät 14 suunnittelijaa ja jokin tiimi vain neljä. Nämä 

olivat kuitenkin perusteltuja ja parempaa ratkaisua ei löydetty, joten päätimme lähteä 

liikkeelle 18 scrum ohjelmistotiimillä.  

 

Lisäksi oli kaksi laitteistotiimiä, jotka kehittävät laitteiston perinteisellä 

vesiputousmallilla, mutta soveltuvat muiden projektitiimien uuteen malliin. Koska 

laitteistotiimit koostuivat osaavista, toisensa ja muun projektihenkilöstön hyvin 

tuntevista huippuammattilaisista ja scrum ei tosiaankaan ole tarkoitettu 

laitteistokehitykseen, niin uskalsimme lähteä liikkeelle. 

 

Tuotepäälliköt nimettiin aluetuoteomistajiksi (APO, area product owner) ja 

systeemisuunnittelijat ominaisuusomistajiksi (FO, feature owner). Vastuualueet olivat 

selkeät. Jokaiselle tiimille nimettiin ominaisuusomistaja, joka on viikoittain yhteydessä 

tiimiin sekä aluetuoteomistaja, joka on ominaisuusomistajan työpari. Integrointi- ja 

systeemitestaus jatkavat omassa tiimissään. Scrum mestari on raportointivastuussa 

projektipäällikölle. Kuva 18 esittää pelkistetysti projektin ketterää organisaatiota, sillä 

tiimejä on todellisuudessa 18 sekä lisäksi vielä on kaksi laitteistotiimiä ja 

järjestelmätestaustiimi. 

 



54 

 

    

Kuva 18. Ensimmäinen projektiorganisaatio.  

 

Kun projektia oli ajettu kaksi kuukautta, niin huomasin, että emme saa scrum-

menetelmästä parasta tehoa. Olemme liikaa vesiputousmallin kahleissa. Uutena ideana 

oli keikauttaa vastuunjako ihan toisinpäin (kuva 19). Scrum mestareiden sijaan 

laitetaankin ominaisuusomistajat raportointivastuuseen. Scrum mestarit ovat vastuussa 

hallinnosta, tiimin henkilöstöstä, kokousten järjestämisestä, metriikan laatimisesta ja 

kaikesta muustakin käytännön asioita, mutta ominaisuusomistajat ovat vastuussa 

edistymäkaaviosta eli siitä, että miten valmis ominaisuus oikeasti on. 

Testing 
Project 

Sales / marketing  
Material  & training 

Scalability  
Testing 
Project 

Regression  
Testing 
Project 

Scrum 

Mast 

Testing 

SW dev 

S
y
st

e
m

 
sp

e
c 

F
e
a
tu

re
 

o
w

n
e
r 

Scrum 

Mast 

Testing 

SW dev 

S
y
st

e
m

 
sp

e
c 

F
e
a
tu

re
 

o
w

n
e
r 

Scrum 

Mast 

Testing 

SW dev 

S
y
st

e
m

 
sp

e
c 

F
e
a
tu

re
 

o
w

n
e
r 

Feature 
Owners 

Product 
owner 

SW1+ 
APO+Docs 

Delivery 
capability 
project 

S
W

2
 +

 A
P
O

 +
 D

o
cs

  

Pricing tool 

Docs project 

SW integration  

SW tools 

MCL 
mgmt 

Smoke testing  

Project Man-
ager 

SW3+ 
APO+Docs 

Scrum 

Mast 

Testing 

SW dev 

S
y
st

e
m

 
sp

e
c 

F
e
a
tu

re
 

o
w

n
e
r 

Scrum 

Mast 

Testing 

SW dev 

S
y
st

e
m

 
sp

e
c 

F
e
a
tu

re
 

o
w

n
e
r 

System 
engineer 

Customer 
documentation 



55 

 

    

Vaihto tuntuu isolta riskiltä, sillä ominaisuusomistajat eivät koe osaavansa 

projektipäällikön hommia, mutta he olivat valmiita yrittämään. Joillekin Scrum 

mestareille järjestely tuntuu syövän heidän arvostusta ja vaarana oli vetäytyminen, 

joten muutoksen kommunikoinnilla oli suuri merkitys. Ominaisuusomistajat ovat 

huippuasiantuntijoita ja nöyriä uuden tehtävän edessä, joten se edesauttoi muutoksen 

tekemisessä.  

 

         

 

 

 

 

 

Kuva 19. Uusi organisaatio kahden kuukauden jälkeen. 

 

Uusi organisaatio loksahti paikoilleen ja vastuu siirtyi aidosti ominaisuusomistajille ja 

scrum-tiimille, joten tämä organisaatio jatkui projektin loppuun asti. 

 

 

5.3   Hallintamenetelmien luominen 

 

Amerikan johdon kanssa on sovittu, että kansainvälistä prosessia noudatetaan. Toisaalta 

taas scrum-tiimejä ei saa häiritä vesiputousmallin tyylisillä ennustuksilla ja lupauksilla. 

Päätin, että minä projektipäällikkönä olen tässä välissä ja tuotan kaikki tarvittavat 

prosessin vaatimat katselmoinnit ja dokumentit systeemisuunnittelijoiden avustuksella. 

            Uusi organisaatio 

 

 

 

 

 

 

Scrum mestari
Testaussuunnitteli

ja

Ohjelmistosuunni
ttelija

Järjestelmämääritt
elija

Ominaisuus 
omistaja

     Ensimmäinen organisaatio 

 

 

 

 

 

 

Ominaisuusomist
aja

Testaussuunnitteli
ja

Ohjelmistosuunni
ttelija

Järjestelmämääritt
elija

Scrum 
mestari



56 

 

    

Epäilijöistä huolimatta tämä sujui oikein hyvin ja pidemmällä tähtäimellä meillä oli 

enemmän dataa tarjolla kuin aiemmissa projekteissa ja kansainvälisissä projekteissa. 

  

Koska tiimit ovat uusia ja tiimien nopeudesta ei ole tietoa, niin päätimme, että jokaisen 

tiimin on ajettava 2-3 sprinttiä ennen kuin se antaa aikataululupauksen. Tämä ei 

tietystikään ole yrityksen kansainvälisen prosessin mukaista, sillä siellä aikataululupaus 

annetaan suunnittelun jälkeen ennen toteutuksen aloittamista. Ja näistä 

aikataululupauksista meillä on huonot kokemukset! Siitä huolimatta otti oman aikansa, 

että yrityksen USA:n johtoryhmä hyväksyi tämän uuden käytännön.  

 

 

5.3.1   Palaverikäytäntö 

 

Projektihenkilöstö yleensä kritisoi projektin palaverien määrää, ja on yleisesti tiedossa, 

että scrum-menetelmässä ovat päivittäiset tiimipalaverit. Haasteena on saada tiimit 

innostumaan määrällisesti enemmistä palavereista ja tekemään työtä sen eteen, että ne 

ovat tehokkaita pikapalavereita. Kuten kuva 20 esittää yksi sprintti on kolmen viikon 

mittainen ja sen alussa on tavoiteasetanta- ja lopussa katselmointipalaveri jokaiselle 

tiimille sekä tietysti tavoitteen etenemisen seurantapalaveri. 

 

Kuva 20. Kolmen viikon sprintin ylätason tapahtumat aikajanalla. 



57 

 

    

Näin laajan projektin palaverimäärä on päätähuimaava. Palaverissa istuminen ei edistä 

asiakkaalle tehtävää tuotetta, mutta kommunikaatio pitää pelata, että jotain järkevää 

saadaan ulos tiukassa aikataulussa. Listasin kaikki palaverit (Taulukko 3) yhteen 

dokumenttiin seuraavine tietoineen: palaverin nimi, kohderyhmä, agenda, tiheys, kesto. 

Palaverienmäärä on valtava, mutta kyseessä on 250 henkilön tuotekehitysprojekti, joten 

yhden henkilön palaverimäärä ja -aika ei ole niin iso. 

 

Taulukko 3.  Yhden sprintin palaverit. 

Palaveri Kesto 
/ h 

Määrä PM APO FO SM Testaus, 
HW, NPI, 
CIP, doc, 
INM,Mainte-
nance, Laatu 

Kaikki 

APO 1,5 3 1 x x x   

Sprint 1 2 x x     

Info 0,5 1 x x x x x x 

Feature 2 1 x x x    

Core team 1,5 1 x  x * x  

Ohjausryhmä 1 3 x      

CAPEX 1 1 x   x *  

SOS 0,25 3-15 x   x *  

ECE#1 1 3 x * * * *  

Yht.   16 7 6 8 2 1 

     * osallistujia soveltuvin osin 

 

 

5.3.2   Raportointi 

 

Projektipäällikkö raportoi kerran kuukaudessa yrityksen Amerikan johtoryhmälle ja joka 

toinen viikko projektin ohjausryhmälle. Sen lisäksi oli Management Phase Review (MPR) 



58 

 

    

ja Management Status Review (MSR) Suomen johtoryhmälle. Asiakasrajapinnalle tein 

status-kalvosetin joka viikko, jota he voivat käyttää omiin esityksiinsä. Projekti-info koko 

projektihenkilöstölle oli kolmen viikon välein. 

 

Projektin riskien raportointi oli erittäin keskeisessä asemassa. Opin nopeasti, että jos 

muuta ei ehditä katsoa, niin yrityksen Amerikan johto haluaa nähdä riskitaulukon 

(Taulukko 4). Se olikin oiva työkalu avun saamiseen eli jos riski oli kasvanut, niin 

johtajalla oli tyypillisesti kolme kysymystä: mitä olet tehnyt asian eteen, mitä aiot tehdä 

ja kuinka minä voin auttaa. Viimeinen kysymys oli ratkaiseva monissa tilanteissa, sillä 

joskus hankintaprosessi oli tyssännyt, joten protoja ei tullut, joskus muiden tuotelinjojen 

avunpyynnöt häiritsivät projektiani ja joskus asiakkaan lisävaatimukset tulivat 

kohtalokkaalla hetkellä, joten oli mainio tilaisuus antaa Amerikan johtajan tehdä 

päätökset, sillä hän kuitenkin näki koko tilanteen. 

 

Taulukko 4.  Projektin riskit. 

# Määritelmä Mahdollinen Vaikutus Ratkaisu Tilanne nyt 

1 CDC2 ei tule valmiiksi 

ajoissa (2.5) 

Korkea Iso Priorisoidaan 

ominaisuudet 

Työnalla 

2 ECE#1 ei tule valmiiksi 

23.11 mennessä 

Korkea Iso Korkeampi 

prioriteetti 

Hallinnassa 

3 ECE#1 laatu on 

huonompaa kuin 

yleensä (< 97 %) 

Keskitaso Iso Enemmän 

testausta 

aiemmin 

Hallinnassa 

 

 



59 

 

    

5.4   Testaus 

 

Uuden tuotteen ominaisuustestaus tapahtuu scrum-tiimeissä, joiden lisäksi oli 

vesiputousmallista tutut regressio-, systeemi-, applikaatio, MDS-, SDS-, IOT- ja PLS-

testausta. Nämä ovat vesiputousmallissa olleet sen jälkeen, kun kaikki ohjelmiston 

tuotteet ovat valmiita, jolloin testausorganisaatio on tosi lujilla ja toisaalta virheet 

löytyvät aivan liian myöhään. Nyt yritetään venyttää niitä koko projektin ajalle, vaikka 

näin ensimmäisessä scrum-projektissa testihenkilöstä pääsee tulemaan projektiin vasta 

puoli vuotta myöhässä koska edellinen projekti vedettiin perinteisellä menetelmällä, 

joten testaajia tarvittiin erityisesti projektin lopussa.  

 

Kuva 21 esittää miten uusien piirteiden testien määrä kasvaa sekä näiden testien 

testitulokset. Tämä on ensimmäinen projekti, jossa uusia testejä on tehty ennen kuin 

ohjelmistokehitys on loppunut. Tämä on todella iso askel eteenpäin ja se näkyy myös 

uusien piirteiden laatutasossa. Kun testaus aloitettiin, kun ominaisuutta vielä 

kehitettiin, niin ohjelmistosuunnittelija sai palautetta työstään jo hyvin alkuvaiheessa ja 

näin ollen isoimmat sudenkuopat pystyttiin välttämään. 

 

 

Kuva 21. Uuden ominaisuuden testaustapahtumien kappalemääräinen suorittaminen 
scrum-tiimissä kumulatiivisesti. 

0

100

200

300

400

500

600

700

T
e
s
t 

C
a
s
e
s

New Feature Test Execution Results

Failed Passed Blocked Planned Replanned Test Execution

Execution Rate = 79%
Pass Rate = 83%



60 

 

    

Uuden ominaisuuden testauksen lisäksi pääpaino on testien automatisointi, jotta ne 

voidaan suoraan siirtää testipatteriin. Kun testi pystyttiin automatisoimaan jo heti 

alkuvaiheessa, niin sen uudelleen ajaminen oli nopeaa ja pystyttiin pitämään korkea 

laatu viikosta toiseen ilman testisuunnittelijan manuaalista työtä. Tämä on huikea 

kehitys aiempiin projekteihin, joissa testejä on aloitettu automatisoimaan vasta 

projektin lopussa. 

 

Regressiotestauksen tarkoitus on varmistaa viikoittain (kuva 22), että ohjelmiston 

aiemmat ominaisuudet vielä toimivat. Regressiotestaus on automaattitestausta hyvin 

laajalla testipatterilla, joka kasvaa koko ajan uusien ominaisuuksien lisäännyttyä. 

Haasteena on aika ja laatu. Miten tiheästi pitää testata, että tuote ei pääse 

huomaamatta rikkoontumaan ja toisaalta, miten käyttää rajalliset resurssit järkevästi, 

sillä ”turhaan” testaamiseen ei ole varaa? 

 



61 

 

    

 

Kuva 22. Regressiotestitulokset neljän viikon kumulatiivinä. 

 



62 

 

    

Näiden testien lisäksi on järjestelmätestaus, jossa varmistetaan, että uusi tuote toimii 

edelleenkin olemassa olevien muiden tuotteiden kanssa kuten järjestelmänhallinnan 

sekä kolmannen osapuolten laitteiden kanssa. Soveltuvuustestissä varmistetaan, että 

ääriarvot ja usean arvon konfigurointi yhtäaikaisesti toimivat edelleenkin. Pilottitestaus 

on asiakkaan toimitiloissa tapahtuva testaus, joka suoritetaan asiakkaan 

testilaitteistolle. 

 

 

5.5   Työkalut 

 

Olimme aiemmin käyttäneet Microsoft Project työkalua projektin suunnitteluun ja 

hallintaan. Hyvin pian huomasin, että tämä ei sovellu scrum-projektinhallintaan. 

Siirryimme Excelin käyttöön ja samalla aloitimme etsimään parhaiten sopivaa scrum-

työkalua. Työkaluryhmä oli tutustunut muutamaan scrum-työkaluun ja valitsimme 

mielestämme parhaiten meille sopivan pilottikäyttöön: ScrumWorksPro. 

 

Pilotointi tehtiin 15 henkilön voimin viikon aikana, siten että kaikki roolit, osastot, maat 

ja tuoteryhmät olivat edustettuna. Pilotoinnin kommentit ovat Taulukossa 5, johon on 

myös lisätty Rational Team Concert -työkalun näkemys ao. kommentista. Koska meillä 

ei ollut tästä työkalusta pilottiversiota, niin kysymysmerkki tarkoittaa, että tilanne pitää 

tarkistaa asiakastuesta. 

 

 

 

 

 



63 

 

    

Taulukko 5.  Pilotointikommentit. 

Kommentti ScrumWorksPro Rational Team Concert 

Tehtävien riippuvuus - + 

Viimeisen tehtävän päivitys - + 

Käyttäjien määrän rajoitus + + 

Teknologia Ratkaistavissa ? 

Hierarkia - ? 

Vaikeakäyttöinen + - 

Liityntä vikatietokantaan - ? 

Metriikka - + 

Ominaisuustason 
priorisointimahdollisuus 

- - 

Ominaisuuden jakaminen 
aliominaisuuksiin ja linkitys 

+ ? 

Työkalu pakottaa kiinteisiin rakenteisiin 
ja terminologiaan 

- - 

 

Teimme päätöksen, että tällä hetkellä juuri tässä aloitustilanteessa Excel tukee meitä 

parhaiten, sillä projektimme on niin suuri, että työkalua olisi niin paljon pitänyt soveltaa. 

Päätimme kuitenkin olla avoimia scrum-työkalulle tulevaisuudessa. 

 

 

5.6   Metriikka 

 

Yllä olevat testaus-metriikat ovat kuuluneet perusprojekteihin ennen scrumiakin, mutta 

yllätykseksemme Scrum-projektinhallintaan siirryttäessä teimme lisää metriikkaa. 

Yleensähän paperityöt vähenevät scrumiin siirryttäessä. Näin kävikin turhien 



64 

 

    

suunnitelmien suhteen, mutta scrum-tyylistä metriikkaa, jossa ennustetaan 

tulevaisuutta historian valossa, tuli lisää.  

 

Uutena metriikkana aloimme raportoida uusien ominaisuuksien valmistumista (kuva 

23). Aluksi ennustettiin uuden ominaisuuden valmistumisajankohta ja sitten 

raportoitiin sprinteittäin tätä valmistumisajankohtaa vasten. Tämä on hyvin 

yksinkertainen ja havainnollinen metriikka, jota yrityksen Amerikan ylin johto piti jopa 

parempana kuin heidän määrittelemät metriikat. Tässä mittarissa valmis ominaisuus 

tarkoittaa täysin valmista, testattua ja dokumentoitua tuotetta, joka voidaan toimittaa 

sprintin lopussa asiakkaalle. 

 

 

Kuva 23. Uusien ominaisuuksien kappalemääräinen toimitusvalmiuden suunnitelma ja 
toteutuma (y-akseli) kolmen viikon sprinteittäin (x-akseli).  

 

Tiedot tähän kuvaajaan saatiin taulukosta (Taulukko 6), jossa ylläpidettiin perustietoja 

uusista ominaisuuksista kuten tiimi, riskitaso, valmistumistavoite sekä tiimin 

omistautuminen. 

0

5

10

15

20

25

30

35

2012 w34 2012 w37 2012 w40 2012 w43 2012 w46 2012 w49 2012 w52 2013 w03 2013 w06 2013 w09

Feature readiness

Actual Features ready Features on track to Release schedule

Features not on track to Release schedule Planned Features ready

MPR



65 

 

    

Taulukko 6.  Uuden ominaisuuden tilannetieto. 

Nr

o 

Ominaisuu

s 

Tiimi

t 

Riskitas

o 

Tavoitepäiv

ä 

Tiimin 

sitoutumine

n 

Kommentti 

1 CDC2 E6, 

E7, 

C1, 

HW1 

Keski 8.2 Keski Riskisuunnitelm

a työn alla 

2 Ethernet C2 Pieni 7.12 Korkea Sisältyy ECE:ään 

3 Portit E5 Pieni 7.12 Korkea Sisältyy ECE:ään 

4 VLAN E5 Pieni 7.12 Korkea Sisältyy ECE:ään 

5 PWE silta C2, 

C6 

Keski 28.12 Korkea Uusi ominaisuus 

 

Ketterän menetelmän yksi parhaista mittareista on iteraatiokierroksen edistymäkaavio 

(kuva 24), johon on piirretty suunniteltujen tehtävien tavoitejana sekä todellinen jäljellä 

olevien tehtävien määrä. Tavoitejanassa koko iteraatiokierroksen tehtävät ovat jaettu 

iteraatiokierroksen päivillä, joka tässä projektissa on kolme viikkoa eli 15 työpäivää. 

Todellinen edistymä, että kuinka paljon tehtäviä on vielä jäljellä, kirjataan päivittäin 

pidetyssä sprinttipalaverissa. Tästä edistymäkaaviosta näkee yhdellä yleissilmäyksellä, 

että kuinka tiimin iteraatiokierros on edistynyt tavoitteeseen nähden, jolloin jo 

iteraation ensimmäisistä päivistä lähtien voidaan korjata toimintaa tämän 

yksinkertaisen kaavion palautteen perusteella. 

 



66 

 

    

 

Kuva 24. Yhden tiimin tehtävien suunnittelu- ja toteumaedistymäkaavio kolmen viikon 
iteraatioissa. 

 

Uusien ominaisuuksien testaus on aina aiemmissa projekteissa aloitettu vasta 

ominaisuuden koodaamisen jälkeen. Koska aikaa on ollut vähän, niin testaus on 

aloitettu manuaalisesti ja automaattiset skriptit on tehty vasta projektin 

loppuvaiheessa tai jopa asiakastoimituksen jälkeen. Nyt tavoitteena on tehdä ensin 

automaattiset skriptit, jolloin vältytään manuaaliselta työltä sekä saadaan samanlaista 

testausta viikosta toiseen. Ongelmana on testisuunnittelijoiden kiireellisyys edellisen 

projektin kanssa, johon he siis kehittävät tämän edellisen projektin automaattiskriptit. 

Kuva 25 raportoi automaattiskriptien tilannetta, jolloin tämä tärkeä työ tulee näkyviin. 

 

0

100

200

300

400

500

600

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Te
h

tä
vä

t 
ka

p
p

al
ei

tt
ai

n

Iteraatiokierros

Iteraation edistymäkaavio

Suunnitellut tehtävät Jäljellä olevat tehtävät



67 

 

    

 

Kuva 25. Automatisoitujen testien viikottainen tilanne. 



68 

 

    

Aiemmissa projekteissa ominaisuudet ovat raportoitu valmiiksi ja ollaan siirrytty 

testausvaiheeseen. Sen jälkeen projekti on venynyt, sillä testauksessa on havaittu 

paljon virheitä. Virheiden korjaus ja suppeneminen on vienyt todella paljon aikaa ja 

jälkikäteen on huomattu, että raportoitu ominaisuus ei sisältänyt kaikkia haluttuja 

piirteitä, joten toteutusta on jouduttu tekemään testausvaiheessa. Ketterään 

menetelmään siirryttäessä testaus tehdään heti toteutuksen jälkeen palasissa, mutta 

varmistaakseen projektin kypsyyden tehtiin yksinkertainen mittari raportoimaan 

muutettuja lähdekielisiä ohjelmarivejä (Kuva 26). Lähdekielisen ohjelmarivien 

muutokset pitäisi supeta radikaalisti lähdekielisen ohjelma- ja testausvaiheen jälkeen, 

jolloin tuote on lopputestauksessa ennen asiakkaalle toimittamista. 



69 

 

    

 

Kuva 26. Viikoittain muuttuneet C++ lähdekieliset ohjelmarivit. 

 



70 

 

    

Ketterän menetelmän positiiviset puolet alkoivat näkyä projektin ominaisuuksien 

muutosmetriikassa (Kuva 25). Aluksi luvattiin valmistaa vain ne ominaisuudet, jotka 

pystyttiin heti aloittamaan olemassa olevilla tiimeillä, mutta luvattiin myös ottaa 

työnalle asiakkaalle tärkeitä ominaisuuksia prioriteettijärjestyksessä, kun tiimit 

vapautuvat. Kuva 27 osoittaa, että projekti pystyi tuottamaan melkein kaksinkertaisen 

määrän uusia ominaisuuksia.  

 

 

Kuva 27. Projektin uusien ominaisuuksin kappalemääräinen toimitusvalmiuden 

suunnitelman ja toteutuksen muutokset kuukausittain. 

 

Uusi tarkoituksenmukainen metriikka puolusti erinomaisesti ketterän projekti-

menetelmän hyviä puolia ja toimi näin ollen hyvänä viestinnän apuna Amerikan 

ylemmälle johdolle sekä laatuosastolle.  

 

 

 



71 

 

    

5.7   Projektin dokumentit 

 

Tyypillisesti scrumiin siirryttäessä dokumenttien määrä vähenee. Tämä oli meidänkin 

tarkoitus, mutta koska olimme sopineet noudattavamme yrityksemme kansainvälistä 

ylätason prosessia, niin jokainen dokumentti oli tapauskohtainen.  

 

Esimerkiksi projektisuunnitelmadokumentti oli yksi keskeisimmistä dokumenteista, joka 

tosin vanhenee heti seuraavana päivänä eikä sitä ylläpidetä, joten scrum-menetelmässä 

tällainen dokumentti on tarpeeton ja vie vain turhaan aikaa. Kun aloin tarkemmin 

katsomaan, niin ylätason prosessi ei ole tarkkoja määritteitä, että millainen 

projektisuunnitelma pitää olla, joten tein yksityiskohtaisesti ylätason dokumentin, jossa 

oli asiat, jotka eivät muutu ja muilta osin dokumentissa oli linkki sinne, missä 

ajantasainen tieto on. Tämä tuntui mielekkäältä ja toimivalta, joten otimme tämän 

toimintatavan käyttöön. 

Ennen projektin aloitusta teimme ja katselmoimme seuraavat dokumentit: 

projektisuunnitelma, HW-projektisuunnitelma, testisuunnitelma, CIP-suunnitelma, PLS-

projektisuunnitelma, NPI-projektisuunnitelma ja asiakasdokumentointiprojekti-

suunnitelma. 

  



72 

 

    

6   Projektinhallinnan arviointi käyttäjän näkökulmasta 

 

Scrum-menetelmän mukaisesti palautetta kerättiin sprinteittäin koko matkan ajan eikä 

jätetty viimeiseksi työksi vesiputousmallin mukaisesti. Tämä on ehdottomasti oikea ja 

tehokas tapa, sillä projektin lopussa katseet ovat jo uudessa projektissa, muistetaan vain 

isot asiat ja on ainainen kiire. 

 

Tässä projektissa ensimmäinen iso muutos tapahtui kaksi kuukautta sen jälkeen, kun 

scrum-tiimit olivat aloittaneet. Tuntui, että tiimien aikatauluvastuu ei ollut oikeasti 

oikein kellään (vaikka paperilla tietysti jokainen oli vastuussa). Scrum mestarit olivat 

organisaattoreita, tiimin työn mahdollistajia ja tiimin ääni ulkomaailmaan. He siis 

kysyivät tiimin sitoutumisastetta ja saivat vastauksen, että tiimi oli sitoutunut tämän 

sprintin tavoitteisiin ja ylätasolla oman tuotteensa tekemiseen. Sitoutuminen oli tullut 

ja projekti eteni.  

 

Ominaisuusomistajat olivat oikeasti vastuussa tuotteen synnystä ja he miettivät, että 

miten asiakkaan haluama tuote voitaisiin saada vielä tehokkaammin ja nopeammin 

aikaiseksi. Ominaisuusomistajat ovat kuitenkin käytännössä teknisiä asiantuntijoita, 

joten epäilytti siirtää tuotteen raportointivastuuta heille. Kun päätös oli tehty, niin se 

loksahti heti paikoilleen. Toki ominaisuusomistajat kokivat epävarmuutta olemaan 

tiimin ääni, mutta selkeästi he olivat koko ajan kantaneet vastuuta, että tuote saadaan 

tehtyä. Hehän vastasivat vaatimusten prioriteettilistasta.  

 

Tämän ison muutoksen jälkeen tuli taas tunne, että rohkeita päätöksiä ja riskejä pitää 

uskaltaa tehdä. Odottaminen, pelkääminen ja tekemättä jättäminen ovat pahin 

vaihtoehto, sillä silloin ei ainakaan voida voittaa. Vääräkin päätös on parempi, sillä silloin 

ainakin opimme jotain –ja uuden, paremman päätöksen voi sitten tehdä sen pohjalta! 



73 

 

    

6.1   Asiakkaat 

 

Suurin osa asiakkaista oli ollut pitkään yrityksen asiakkaana aiemmalle tuoteperheelle, 

joten toimitsijan vaihtaminen olisi ollut iso kynnys. Asiakkaat joustivat aikataulun 

suhteen myös sen takia, että tarjottu tuote oli innovatiivinen ja kilpailukykyinen 

markkinoiden muihin tuotteisiin verrattuna. Asiakkaiden toive oli saada käyttöönsä 

mahdollisimman paljon uusia tuotteita mahdollisimman nopeasti, että he voivat palvella 

omia asiakkaitaan kilpailukykyisesti.  

 

Vesiputousmallin aikatauluongelmat konkretisoituivat asiakkaille ensimmäisenä 

olemassa olevan tuotteen laatuongelmina, kun ylläpitoa vähennettiin, että saatiin 

maksimaalinen henkilöstö uusien ominaisuuksien tekemiseen. Pian aikatauluongelmat 

näkyivät myös siinä, että uusia ominaisuuksia jouduttiin karsimaan ja silti uuden 

tuotteen aikataulu oli auttamattomasti myöhässä. 

 

Asiakkaat olivat jo todenneet, että yritys teki kaikkensa heidän palvelemiseksi ja oli 

rehellisesti tunnustanut ongelmansa. Kun avainasiakkaille puhuttiin ketteriin 

menetelmiin siirtymisestä, niin he olivat avoimia mille tahansa muutokselle ja toisaalta 

he uskoivat, että yritys teki kaikkensa. Olikin yllättävää, että asiakkaat ”ostivat” ketterät 

menetelmät ennen kuin yrityksen amerikkalainen johto. Asiakkaat uskoivat yrityksen 

näkemyksiin, että ketterällä menetelmällä myös asiakkaat voisivat vaikuttaa enemmän 

tuoteportfolioon. Sitäkin tärkeämpi oli tieto, että asiakkaat voisivat priorisoida uusia 

piirteitä koko ajan eikä vain vuosittain.  

 

Asiakkaille kerrottiin, että he voivat vapaasti vaihtaa uusien ominaisuuksien 

prioriteettijärjestystä niin kauan, kunnes ominaisuutta aletaan tehdä, ja kun tekeminen 

aloitetaan, niin se myös saadaan valmiiksi. Kun uusi tuote on valmis, niin se 

periaatteessa voidaan antaa asiakkaalle, jos niin sovitaan. Tämä oli huikea muutos 



74 

 

    

kahden vuoden välein tuleviin tuotepaketteihin, jotka olivat myöhässä ja uusien 

tuotteiden tärkeyskin oli muuttunut matkan varrella. 

 

Loistavat asiakassuhteet siis takasivat, että yritys pystyi siirtymään viimeiseen 

oljenkorteen, ketteriin projektinhallintamenetelmiin, amerikkalaisen johdon 

jarrutellessa. Asiakkaat olivat innokkaana mukana priorisoimassa omia tuotteitaan. 

Tietysti he halusivat kaikkiin uusiin tuotteisiin lupaukset mahdollisimman nopeasta 

toimituksesta, mutta ymmärsivät kokemuksesta, että lupauksella ei vielä omaa 

asiakasta rahasta. Nyt siis asiakas sai itse pitää tuoteprioriteettilistaa, hänelle kerrottiin 

suunnitelma kärkituotteen työnalle ottamisesta ja sitten kun tuotetta elettiin tehdä, niin 

tilanteesta raportoitiin. Kun tuote oli saatu tehtyä, niin asiakas sai halutessaan ottaa sen 

käyttöön tai odottaa seuraavan tuotteen valmistumista. 

 

Asiakas oli sitä mieltä, että resurssit käytettiin maksimaalisen tehokkaasti ja että hän saa 

oman tuotteensa mahdollisimman nopeasti tällä menetelmällä. Asiakkaan 

näkökulmasta tilanne oli läpinäkyvämpi kuin aiemmin ja jaettu tieto oli todellista ja 

uskottavaa. Tieto oli hyvin selkeää ja ymmärrettävää, jolloin asiakkaat kokivat, että 

kommunikointi on parantanut. Tietysti asiakkaat toivoivat, että heidän tuotetoiveet 

nousisivat yrityksen listalla korkeammalle ja että tuote tulisi valmiiksi nopeammin, 

mutta se on varmasti normaali toive kaikilta asiakkailta. Pääasia oli, että asiakas sai 

nopeammin uusia tuotteita ja että ne