Monipaikkainen Johtaminen 1.12.2015

Suomen Ympäristökeskus, Mechelininkatu 34a, 00250 Helsinki.



Tamora Oy, Asko Mononen, Monipaikkainen johtaminen avoimessa digitaalisessa maailmassa.


Aloitus 9.00


Tamora Oy, Asko Mononen
Monipaikkainen tiimi ja sen dynamiikka

Klo 12.00 Lounas

Avoimen digitaalisen maailman työvälineet

Iltapäiväkahvi

Aihe jatkuu

Lopetus 16.00

 Monipaikkaisella johtamisella tarkoitetaan virtuaalijohtamista hajautetulle organisaatiolle.












 Tutustu sovelluksiin:








Ketterät menetelmät ovat syntyneet joitakin vuosia sitten. Idea on lähtöisin ohjelmistomaailmasta ja nyt sitä sovelletaan monille eri aloille. Perinteisen vesiputousmallin vastakohta. Perinteisessä mallissa lyödään aluksi lukkoon tulos. Joustavana tekijänä on aika ja hinta. Ketterissä menetelmissä aika ja hinta on kiinteät ja ominaisuudet joustaa. Mitä enemmän saamme toistoja, sitä tarkemmin voimme ennustaa mitä tulee ulos tuloksena.

Monesti projektilla kuitenkin on tietty minimitulos mitä halutaan.
Jos on ennalta määriteltyjä toistuvia projekteja, voimme kokemuksen perusteella ennustaa miten onnistutaan. Uusissa projekteissa emme voi ennustaa tulosta, jolloin ketterät menetelmät toimivat paremmin. 2-4 viikon sprinteissä voimme muuttaa tarvittaessa suuntaamme ja sopeuttaa tavoitettamme tehokkaammin.


10v sitten puoli henkilötyövuotta oli normaali suunnitteluaika projektille. Ero vesiputousmallin ja ketterän kehittämisen välillä on tuloksen jakautuminen. Vesiputousmallissa palava rahamäärä kasvaa loppua kohti, mutta samoin kasvaa myös riskit. Ensimmäisen kolmanneksen aikana ei ole vielä ongelmia, mutta ne alkavat kasvaa aina loppua kohden. Ketterissä menetelmissä pilkotaan projekti pienemmiksi palasiksi. Yleensä mieluiten asiakaslähtöiseksi. Tuotetaan koko ajan jotain hyödyllistä asiakkaalle jolloin rahasumma jakautuu tasaisemmin ja yksittäiset rahasummat ovat vesiputousmalleja pienempiä. Epäonnistumisen todennäköisyys pienenee loppua kohden. Jos projekti epäonnistuu, on sen halvinta epäonnistua mahdollisimman aikaisin.

Miten varmistetaan, että asiakas saa ainakin ne tärkeimmät asiat joita hän haluaa? Asiakas määrittää projektin tavoitteiden tärkeysjärjestyksen ja voi muuttaa sitä projektin edetessä.

Ulkoiset rahoittajat ja komissiot toimivat nykyisin ketterän mallin mukaan. Halutaan nopeasti tuloksia ja nopeasti muuttuvassa maailmassa ei ole mahdollista asettaa tavoitteita monen vuoden päähän. Projektia ja tavoitteita on voitava muokata ympäristön muutosten mukaisesti.



Mikä on minimituotos mitä olemme tekemässä tässä projektissa? Mihin asiakas on tyytyväinen ja mistä on hänelle jotain hyötyä? Rullalaudalla pääse jo eteenpäin ja asiakas pääsee liikkumaan, jolloin jonkinlainen toive on jo täytetty. Tästä eteenpäin vain tulos paranee ja minimi on jo saavutettu. Perinteisessä vesiputousmallissa hyöty tulee vasta projektin lopussa ja projektin aikana asiakkaalla ei ole vielä mitään käyttökelpoista.

Asiakas on koko ajan tiiviisti mukana projektin etenemisessä ja hän saa ajantasaista tietoa välietapeista.

Haasteena kehittymisen ja kehittämismotivaation ylläpitäminen. Monesti kuitenkin vaativan projektin lopuksi tulee motivaatin romahdus.Vesiputousmallissa pahin kiire ja paine painottuu projektin loppupäähän jolloin loppuunpalaminen ja uupumus ovat suurempia mahdollisuuksia. Ketterässä mallissa paine ja kuormitus jakautuu tasaisemmin projektin aikana, jolloin tekijöiden kuormitus ei kasva hetkellisesti liian suureksi. Parin viikon välein esiteltävät onnistuneet tuotokset motivoivat tekijöitä jatkamaan saman projektin parissa pidempään.


Product backlog on "lista" mistä tehtäviä otetaan työn alle. Ensimmäisinä listalla ovat aina tärkeimmät tehtävät.

Sprint backlog on tyypillisesti 2-4vko työrupeama missä tehtään yksi product backlogin tehtävä.

Daily scrum meetingeissä käydään läpi yhden vuorokauden aikana saavutettu edistys tai tehtävä. Näin näemme joka päivä edistystä projektissa. Sen sijaan, että lataisimme hillittömän tehtävälistan näkyviin, keskitymme ainoastaan yhteen tehtävään kerrallaan.

Nopeilla tilannekatsauksilla päästään eroon turhista kokouksista jossa on ihmisiä joita aiheet eivät koske mitenkään. Näin on mahdollista säästää aikaa ja keskittyä vain olennaisiin asioihin.

Kohtuullisen monimutkaisia asioita voidaan saada pyörimään kohtuullisen yksinkertaisilla metodeilla, kun ollaan järjestelmällisiä.


Käyttäjänä haluaisin tehdä jotain, jotta tapahtuisi jotain. Kaikki projektin tehtävät kirjoitetaan käyttäjälähtöiseen muotoon. Näin taataan, että loppuasiakas saa jotian hyötyä.


Kanban- taulussa prioriteetit muuttuvat, mutta tehtävät eivät tule valmiiksi ja poistu näkymästä.


Product owner ymmärtää kokonaiskuvan ja keskustelee esim. asiakkaiden kanssa. Hän tuntee työvaiheet ja kokonaisuuden, mutta ei välttämättä ymmärrä jokaista pienintä yksityiskohtaa.

Scrum Master varmistaa, että päivittäinen työ etenee. Kyselee ongelmat, selvittää ja raivaa etenemisen esteet. Saattaa yhteistyökumppanit yhteen ja kysyy tarvittaessa apua product ownerilta. Jakaa tehtäviä ja pysyy kärryillä kokonaisuudesta ja etenemisestä. Hän ei ole pomo, mutta hänen roolinsa on olla junailija ja mahdollistaja.

Scrum Team tekee tehtävä kerrallaan Product ownerin priorisoimia tehtäviä.

Product Owner katsoo suurta kuvaa ja hieman pidemmälle, kun taas Scrum Master on enemmän sisällä päivittäisessä työssä ja operatiivisessa toiminnassa.

Pomodoro- menetelmä Wikipediassa


Tehtävät määrittelee asiantuntija tai kokenut tekijä. Tee mielummin hieman liian isoja kokonaisuuksia mitä voit tarvittaessa purkaa pienempiin kokonaisuuksiin.


Post-it- lappumenetelmä on toimiva metodi silloin kun kaikki projektiin liittyvät tekijät ovat samassa tilassa. Jos projekti onkin globaali tai tekijät eivät muusta syystä pääse seuraamaan samaa taulua fyysisesti, voidaan käyttää avoimen digitaalisen maailman välineitä.




Esimerkkejä yrityksistä jotka ovat ottaneet asiakkaat mukaan toiminnan kehittämiseen käyttäjälähtöisesti. Ben&Jerry's:in suosituin jäätelömaku on heidän asiakkaidensa kehittämä. Tieto on nykyään niin helposti ja halvalla saatavilla, että salailu ei ole enää kannattavaa. Sen vuoksi kehittäminen voidaan tehdä täysin avoimeksi ja samalla asiakaslähtöiseksi.


7 kommenttia: