Kuuluuko kiire kehitysprojektiin?

Olen välillä yrittänyt herätellä keskustelua kiireen keinotekoisuudesta projekteissa. Tällä tarkoitan tilannetta, joissa projektissa ei ole lainkaan suvantovaiheita kiireellisten ominaisuuksien tuottamiseksi, vaan tekijöillä on jatkuvat kiireelliset määräajat, milloin minkäkin ominaisuuden valmiiksi saattamiseksi. Tällainen voi jatkua kuukausia tai pahimmillaan jopa vuosia. Olen itsekin ollut kehittäjänä tällaisissa projekteissa. Asia, jonka tuona aikana opin oli se, että hyvin harva ominaisuus oli oikeasti aikakriittinen. Suureessa kiireessä valmiiksi työstetty ominaisuus odotteli viikkoja tai jopa kuukausia, ennen kuin kukaan liiketoiminnasta ehti testata tai validoida sitä. Väitteeni kiireen keinotekoisuudesta ei siis ole ainakaan täysin tuulesta temmattu. Erikoisinta aiheessa on itselleni kuitenkin ollut se, että kaikki eivät suostu myöntämään tällaisen olevan edes mahdollista.

Onko kiireen syy asenteessa?

"Minusta on mukavaa, kun on vähän kiire," sanoo moni. Huonoja uutisia. Olet adrenaliiniaddikti. :)

Kiire todellakin aiheuttaa (ainakin osassa meistä) hyvän tuntuisen huuman. Ongelmana on se, että jatkuva kiireen tuntu saa meidät myös stressaantumaan. Harvardin tutkimuksen mukaan tällainen tila laskee kognitiivisia kykyjämme. Emme pysty enää keskittymään yhtä laajoihin kokonaisuuksiin, vaan alamme keskittyä enemmän yksityiskohtiin. Älykkyysosamäärän lasku saattaa olla jopa 13-14 astetta.  Kiireellisyys saattaa siis olla jopa tavoiteltu tila. Siihen miksi tällaista tavoitellaan, on varmasti lukemattomia syitä, mutta itse olen kohdannut ainakin seuraavia edellä mainitun fiiliksen lisäksi.

Ominaisuuksien tehtailu

Toisin sanoen näytetään hyvältä paperilla, kun "korkean prioriteetin" tehtäviä saadaan aikaiseksi valtavia määriä. Tämä onnistuu parhaiten siten, että kaikki tehtävät asetetaan korkean prioriteetin tehtäviksi. Tuotetaan siis helpot ja nopeat ominaisuudet ensimmäiseksi, koska kaikki näyttää priorisoinnissa samalta. Tosiasiassa ei saada aikaiseksi yhtään enempää, todennäköisesti jopa vähemmän. Mutta sen tarkempaa analyysia tekemättä voi projekti näyttää tuottavan uskomattomia tuloksia.

Resurssien varmistus

Mikäli organisaatio toimii hyvin nopeasti resursoinnin vaihdoissa (jota täysin virheellisesti kutsutaan joskus jopa ketteryydeksi), syntyy nopeasti lieveilmiö, jossa projektipäälliköt näkevät eduksi pitää tiimiä "paniikki"-tilassa, jotta tarpeellisia resursseja ei jatkuvasti vaihdeta projektista pois. Jos resursointia muokataan kuitenkin mielivaltaisesti ulkopuolelta, sillä on harvoin merkitystä, missä tilassa projekteista siirrettävät henkilöt ovat. Näin ollen kiire aiheutetaan organisaation toimesta ja kärsijöinä ovat kaikki. Organisaation resurssihallinnassa on tällöin paljon suurempiakin vikoja, jotka tulisi ratkaista välittömästi. Resurssiongelmat korjaantuvat erittäin harvoin siirtelemällä henkilöitä projekteista toisiin. Korjausta tulisi ennemmin hakea kuorman ja kapasiteetin tasaamisesta.

Projektin pelastaminen

"Pääsimme taas todistamaan, miten joustavia ja (jälleen kerran virheellisesti) ketteriä me olemme. Pystyimme toteuttamaan tämänkin ominaisuuden aivan uskomattomassa aikataulussa kaikista ongelmista huolimatta.”

Valitettavasti tämä on itseään toteuttava ennustus, koska mitä enemmän teemme kiireessä, sitä enemmän teemme virheitä. Jossain vaiheessa ongelmat itsessään alkavat muodostua niin suuriksi, että ihan perustoiminnallisuuksien lisääminen alkaa olla jonkinasteinen sankariteko. Jos tämä on projektin jatkuva tila, niin tulisi miettiä miksi projektissa tarvitaan jatkuvaa pelastusta tai urotöitä.

Hallinnollisia syitä kiireelle

Resurssien vaihtuminen on selkeä haaste kaikille projekteille, ja sitä tulisi mahdollisuuksien mukaan välttää. Se on kuitenkin projektin ulkopuolisen tahon aiheuttama rasite, johon ei projektin sisältä pystytä juurikaan vaikuttamaan. Projektin sisäisessä hallinnassa on sen sijaan asioita, joilla on selkeä vaikutus kiireeseen.

Sankari- ja pilvilinna -arviot

Yksinkertaisesti sanottuna arvio on epäepärealistinen verrattuna tarjolla oleviin resursseihin ja toteutuksen monimutkaisuuteen. Sankariarviossa usein kokenut kehittäjä antaa hänellä tutusta teknisestä tehtävästä arvion, jonka hän itse pystyy saavuttamaan. Huonoimmassa tapauksessa vielä siten, että kyseinen kehittäjä on ollut mukana asiakkaan kanssa ideoimassa ja suunnittelemassa toteutusta. Tällöin hän on päässään suunnitellut toteutusta jo ideoinnin aikana, ja ehtinyt kysyä tarvittavia yksityiskohtia suunnitelmalleen. Realistisuus katoaa, kun tehtävän joutuu tekemään joku muu: Mahdollisesti henkilö jolle tekniikka, asiakas ja aihealue eivät ole entuudestaan tuttuja, ja jolle suunnitteluun osallistunut tekijä ei ole siirtänyt tietojaan.

Pilvilinna-arvio taas on muunnos, jossa kehittäjä antaa omasta tekemisestään arvion, joka saavutetaan vain mikäli mitään ongelmia ei synny. Kouluissa kerrottu vitsi, jossa arvio tulee kertoa aina piillä, johtuu nimenomaan tämän kaltaisista ongelmista. Mikäli arvio ei vastaa todellisuutta, tulee projektissa aivan varmasti olemaan kiire hyvin varhaisesta vaiheesta asti.

Projektin laajuuden muutokset

Kaikille on varmasti selvää, että mikäli yhden sijaan halutaan kaksi, se tulee viemään noin kaksi kertaa enemmän aikaa. Tämä tosiasia kuitenkin tahtoo unohtua, kun projektin laajuutta lähdetään muuttamaan. Mikäli uusi lisäys muuttaa jo aikaansaatujen ominaisuuksien toteutusta, tulee työmäärä olemaan vielä suurempi. Jos tämän arvioinnissa ja ennen kaikkea kommunikoinnissa tilaavalle taholle epäonnistutaan, on ongelma valmis. Projektin laajuuden muutokset johtuvat suurimmaksi osaksi alunperin epämääräisestä ja/tai tulkinnanvaraisesta määrittelystä. Toteutuksien yksityiskohtia tärkeämpää olisikin määritellä tarkasti haluttu lopputulos, ja siinä kriittisimmiksi katsotut ominaisuudet.

Suunnittelun puuttuminen

Eräs teknisten henkilöiden (=kehittäjien) perisynti on ylitoteuttaminen. Teknisesti tämä tarkoittaa sitä, että kun projektin tarpeisiin riittäisi vispilä, kehittäjät rakentavat yleiskoneen. Suurin syy tähän on se, että suunnitteluvaiheessa ei ole määritelty tarkasti niitä minimiehtoja, jotka tuotoksen tulee täyttää ja jolloin ominaisuus katsotaan valmiiksi. Varsinkin projektin alkuvaiheessa kehittäjät usein rakentavat ylikehittyneitä ominaisuuksia, jotka kuluttavat projektin resursseja turhaan.

Priorisoinnin puuttuminen tai epäonnistuminen

Jos priorisointia ei tehdä tai se on epäonnistunut, saatetaan käyttää (ja yleensä käytetään) aikaa sellaisten ominaisuuksien toteuttamiseen ja hiomiseen, jotka eivät olisi olleet elintärkeitä järjestelmälle. Kun järjestelmän valmistumisen määräaika alkaa lähestyä, saatetaan vihdoin alkaa nostaa esiin oikeasti tärkeitä, vielä toteuttamattomia ominaisuuksia. Ja kun kalenteriaika alkaa olla vähissä, tulee kiire tarkentaa ominaisuuksien määrittelyt ja luoda tekniset suunnitelmat niiden toteuttamiseksi. Tämä voi tapahtua siitä huolimatta, että kehitys olisi sujunut siihen pisteeseen asti mallikkaasti. Mikäli tuloksia odotetaan tapahtuvan syklisesti, esimerkiksi kerran kvartaalissa, saatetaan tässä oravanpyörässä pyöriä kuukaudesta toiseen.

Kieltäytymisen vaikeus

Tämä on ehkä se vaikein ongelma hyväksyä. Jos projektinhallintamalli itsessään ei sisällä selkeitä linjoja työn priorisointiin, ohjaukseen ja edistymisen visualisointiin, ei asiakkaalla todennäköisesti ole silloin käsitystä lisäpyyntöjen vaikutuksesta. Etenkin perinteisimmissä projekteissa on tavallista, että ”kiireellisiä” asioita pyydetään tehtäväksi ohi sovitun linjan. Ja asiakkaalle on vaikea sanoa ei. Monestakin syystä toimittaja/asiakas -suhteen dynamiikka on haastava. Tällöin projektipäällikkö tai vastaava taho saattaa luvata jonkin ominaisuuden edes ymmärtämättä sen lisäkuormaa projektin henkilöille. Valitettavan usein projektin muiden tehtävien määräaikoja ei myöskään muuteta, vaikka uutta työtä lisätään kylkeen. Tilanteessa ensimmäisenä kärsii laatu.

Kiireelle on paikkansa

Määräajat luovat tutkimusten mukaan kuitenkin tarpeellista painetta työn tehostamiseksi ja parantamiseksi. Toisaalta tutkimukset myös osoittavat, miten määräajat tappavat kehittymisen ja luovuuden.

Siitä huolimatta on tärkeää asettaa tavoitteita. Jos jokaisen tehtävän suorittamiseen on aikaa loputtomasti, niin päädytään tilaan, jossa jokainen ominaisuus on ylitoteutettu. On myöskin vaikea löytää motivaatiota sellaisen tehtävän suorittamiseen, jonka lopputulos ei näy missään. Mitä lähempänä konkreettinen tehtävään liittyvä tavoite on, sitä helpompi tekijälle on ymmärtää miksi ja (ehkä vieläkin tärkeämmin) miten tehtävä tulisi suorittaa.

Minullekin on tiimin kehittäjä retrossa todennut, että oli hieman liian vähän töitä ja sen vuoksi oli vaikea motivoitua tekemään tehtäviä. Eli työteho laski pelkästään sen vuoksi, että aikataulu oli liian väljä. On kuitenkin hyvä muistaa, että kyseessä ovat yksilölliset tarpeet, ja hyvän projektinjohdon tulisi pyrkiä ohjaamaan tiimiä valitsemaan sellainen tahti, jossa sen suoritus on parhaimmillaan niin laadullisesti kuin tehollisestikin.

Tavoitteet siis antavat tehtäville luontevaa vetoa ja tarkoitusta. On kuitenkin tärkeää, etteivät tavoitteet muutu jatkuvaksi kiireeksi.

Ketterät menetelmät eivät ole hopealuoti, mutta ainakin teräsvasara

Miten siis luoda määräaikoja, joilla saavutetaan niiden positiiviset vaikutukset, muttei kuitenkaan aiheuteta vahinkoa projektille ja tiimille? Oman kokemukseni pohjalta jatkuvasta kiireestä kärsivät vähiten ketterät projektit.

Ketterissä kehitysmenetelmissä korostuvat pitkälti samat leanit periaatteet. Tehdään asioita, joilla on suurin vaikutus lopputulokseen, eli jotka asiakas näkee tärkeimmiksi. Ei tehdä asioita, jotka eivät tuota arvoa (jotka eivät ole tärkeitä lopputulokselle tai tuottavalle prosessille). Annetaan kehittäjille valta määritellä työmäärä, jonka he pystyvät toteuttamaan laadukkaasti. Kehitetään jatkuvasti tuottamisen prosessia. Käytän esimerkkinä yleisintä ketterän kehityksen mallia eli SCRUMia.

SCRUMissa korostuu tehtävien priorisointi. Kaikki kehitysjonon asiat aina isoista kokonaisuuksista yksittäisiin ominaisuuksiin on priorisoitu. Projektilta tulisi löytyä selkeä visio, joka on perustana priorisoinnille. Työjonon hallinta on näin selkeää ja visualisoitavissa. Työt on järjestetty toteutettavaksi ilman päällekkäisiä prioriteetteja.

Kehitystiimi valitsee priorisoitujen ominaisuuksien listalta ne, jotka he kokevat ehtivänsä toteuttamaan laadukkaasti sprintin aikana. Koska työmäärä verrattuna resursseihin saadaan näin sellaiseksi, ettei se aiheuta turhia paineita, voidaan keskittyä tekemään tärkeimmät ominaisuudet kokonaisuuden kannalta riittävän laadukkaasti. Tämä taas vähentää automaattisesti tarvetta palata korjailemaan kiireessä toteutettuja asioita, ja akuutti stressi poistuu.

SCRUMissa muodostetaan konkreettinen lyhyen aikavälin tavoite, johon koko kehitystiimi voi sitoutua. Tämä mahdollistaa sen, että jos toteutus on uudelleen käytettävä, voidaan se suunnitella ja mitoittaa sellaiseksi jo ennen kuin se aloitetaan. Näin muodostuu luovan työskentelyn mahdollistava ja kuitenkin työtehoa ylläpitävä veto.

Kun kriittisimmät ominaisuudet saadaan ensimmäisenä valmiiksi, antaa se mielenrauhan niin kehittäjille, kuin liiketoiminnallekin. Se vapauttaa koko tiimin stressitilasta, ja antaa tilaa luoville toteutuksille ja uusille innovaatioille. Näin mahdollistetaan ketterän kehityksen ydin ja projekti, joka voi tuottaa kuviteltua suurempaa lisäarvoa.

Milloin olet itse julmetussa kiireessä käynyt ehdottelemaan laajennuksia toteutettavaan järjestelmään? Kiire voi pahimmillaan tappaa huomattavan kilpailuedun tuottavan innovaation, ja siksi se ei ole kenenkään etu.

Cloud1:ssa me suosimme ketteriä projektimalleja, joissa selkeä ja usein päivitettävä priorisointi on osoittautunut loistavaksi lääkkeeksi jatkuvan kiireen tuntua vastaan. Lue esimerkiksi case Alkosta, jossa SCRUMia on käytetty projektin hallinnassa onnistuneesti.