Käsi pystyyn kaikki, jotka eivät ole koskaan työtä tilatessaan maininneet asialla olevan kiire. Ainakin oma käteni pysyy visusti alhaalla. 😉

Kylppäriremontin olisi hyvä olla pian ohi, että pääsisi taas suihkuun. Kun uusi auto on tilattu, sen olisi syytä samantien pihassa – odottaminen on yhtä piinaa! Sama koskee tietysti myös ohjelmistoprojekteja. Mutta mihin kaikkeen kiire vaikuttaa? Lue eteenpäin, saatat yllättyä.

Projektiliiketoiminta on luonteeltaan epätasaista

Oma tulkintani projektiliiketoiminnasta on se, että työtä ei kertakaikkiaan voi olla sopivasti.

Tai voi hetkellisesti, mutta ei jatkuvasti. Tämä johtuu siitä, että kun tarpeita ilmenee, niitä aletaan sitä mukaan täyttämään. Ja tarpeethan syntyvät, kun ne syntyvät.

Joku jo varmaan miettii, että eihän kaikkea tarvitse aloittaa samanaikaisesti? Totta, mutta ollaanpa ihan rehellisiä. Jos sanoisin, että alamme todella mielellämme työstää projektia – sanotaanko vaikkapa 5 kuukauden päästä – niin olisitko itse valmis odottamaan? Siis riippumatta siitä onko projektilla ihan oikeasti ehdoton deadline vai olisiko vain tosi kiva saada projekti nopeasti läpi, kun kerran homma saatiin jo tilausvaiheeseen. Veikkaanpa, että kauppa napsahti jo naapurifirmaan. 🙂

Tämä johtaa siihen, että projektiliiketoiminnassa työt on otettava sisään, kun siihen on mahdollisuus. Muuten kaupat menevät sivu suun. Joko työtä on liikaa (sinänsä hyvä tilanne) tai sitten sitä on liian vähän (ketäs tänään lomautetaan?). Kiireettömyys ja projektiliiketoiminta nyt vain ovat lähtökohtaisesti riitainen aviopari.

Onko kiire pahasta?

Tunnustan: minä pidän kiireestä. Se on olotila, jossa on pakko saada aikaiseksi.

Ei voi siirtää ensi viikolle, kun tärkeä deadline paukkuu ylihuomenna.

Kiire siis sopii minulle. Kääntöpuolena on se, että jos liian monella projektilla on kiire samanaikaisesti, se voi aiheuttaa stressiä. Ihminen pystyy keskittymään vain tiettyyn määrään asioita kerrallaan tehokkaasti.

Projektiorganisaation näkökulmasta optimaalista olisi keskittää ihminen kerrallaan aina yhteen projektiin. Kun projekti päättyy, aloitetaan seuraava. Tämä tarkoittaisi, että toimittaja yksin päättäisi aikataulutuksen. Ken tässä aina onnistuu, lämpimät onnittelut!

Aikataulutus sinänsä on hyväksi projekteille. Se asettaa rajat milloin kunkin oma panos olisi annettava. Kiireen tunteen luominenkin voi joskus olla myös tehokas apuväline. Se voi auttaa ylisuoriutumaan. Ongelma on vain se, että jos jokaisella projektilla on aina kiire, ei tapahdu ylisuoritusta, vaan itse asiassa alisuoriudutaan. Ihminen turtuu nopeasti kaikkeen.

Mistä kiire syntyy projekteissa?

Väittäisin, että iso osa projektikiireistä syntyy about seuraavasti:

  • “Pomo sanoi, että tämä meidän verkkopalvelu pitäisi uusia. Mieluiten nopeasti, jos mahdollista. Tässä hukataan rahaa joka päivä. Pitäisi saada kuulemma kuukauden sisällä projekti alkuun ja nyt tammikuussa olisi oiva hetki pistää uusi projekti tulille.”
  • “Tässä on nyt mennyt hiukan odotettua kauemmin pähkäillessä. Kaikenlaista odottamatonta kiirettä on ollut. Itse asiassa huhtikuu on jo menossa, mutta vielä en ole ehtinyt tehdä asian hyväksi mitään. Ensi kuussa sitten!”
  • “No niin, vihdoinkin alkaa helpottamaan! Parin viikkoa enää kesäkuun alkuun ja pitäisi saada toimittaja valittua ennen juhannusta.”
  • “Nyt on kiire! Loma lähestyy ja mökin laituriremppakin on jo buukattu, tällä viikolla on pakko valita projektille toimittaja. Voin sitten rauhassa lomailla ja hommat etenee kun lomailen.”
  • “No niin poijjaat. Tässä olisi tää projekti. Lomailen tästä 5 viikkoa eteenpäin, palataan asiaan sitten demojen kera kun palailen. Elokuussa palvelun olisi syytä pyöriä, on sen verran paljon tää homma myöhässä. Asiakkaillekin on jo lupailtu uutta palvelua jo maaliskuusta lähtien.”

Esimerkkini on ehkä kärjistys, mutta kokemusperäisesti ei niin kaukana totuudesta. Yleensä projektin “hautomisvaihe” on 6-12kk, jonka jälkeen tehdään toimittajavalinta. Kun toimittaja on valittu, on kiire yleensä tulenpalava. Ajatus projektista on hautunut jo pitkään ja se luo mielikuvan kiireestä, kun projekti on vihdoin saatu alkuun. Tosiasiallisesti kiire on useimmiten vain tunne.

Mihin kiire vaikuttaa ohjelmistoprojektissa?

Oletko koskaan miettinyt miten kiire vaikuttaa ohjelmistoprojektiin? On toki olemassa positiiviisiakin vaikutuksia, mutta useimmiten kyse on jokin seuraavista:

  • Hätäily on kallista. Erityisesti uuden liiketoiminnan luominen ohjelmiston avulla vaatii kypsyttelyä. Idea jalostuu, konsepti kiteytyy ja käsitys toiminnallisuuksien tärkeydestä elää. Joko se tapahtuu ennen projektia, sen aikana tai sen jälkeen. On tapauskohtaista mikä on järkevin vaihe kussakin projektissa. Yksi asia on kuitenkin selvää. On paljon kustannustehokkaampia miettiä ensin ja koodata vasta sitten. Saman asia koodaaminen moneen kertaan uudestaan on väkisinkin tyyristä.
  • Laatu kärsii. Kun aikataulu on kuristettu minimiin, on jostain pakko karsia. Yleensä koodauksesta ei voi juuri karsia. No mistä sitten? Pilotointi ei ole niin pakollista. Viikko saa riittää. Testaus on myös helppo uhri – 2 päivää ja ohjelmisto tuotantoon. Dokumentaatio on yliarvostettua – leikataan! Tämä tarkoittaa käytännössä, että korjaukset tehdään tuotantovaiheessa eli loppuasiakkaat kärsivät.
  • Tekemisen henki laimenee. Ohjelmiston synnyttäminen on aika puhtaasti asiantuntijatyötä. Kun on hyvä fiilis, syntyy hyvää jälkeä. Kun fiilis kärsii, runnotaan väkipakolla maaliin. Viimeiset viilaukset jäävät helposti tekemättä.

Nurinkurista tässä on se, kaikissa edellä mainituissa tapauksissa ostaja kärsii eniten.

Tuppaa käymään niin, että vaikka vilpitön tarkoitus oli varmistaa ohjelmistoprojektin onnistuminen, tulos oli juuri päinvastainen. Liian kova kiire voi tappaa projektin kuin projektin.

Milloin kiire on perusteltua?

Oman kokemukseni mukaan kiire on 80% tunnetta, 20% todellista. Todelliseen kiireeseen liittyy aina jokin selkeä, helposti ymmärrettävä ja hyväksyttävä reunaehto. Hyvä esimerkki on ohjelmistotuotteen lanseeraustilaisuus. Jos se tapahtuu 1.10.2013, niin ohjelman on syytä olla silloin valmiina. Harmillisesti 50% näistäkin deadlineista on syntynyt nurinkurisesti. Lanseeraustilaisuus on lyöty lukkoon ennenkuin projekti on kilpailutettu, toimittaja valittu ja varmistettu kauanko toimittaminen kestää. Kysymys kuuluu: kenen vika on, jos aikataulut pissivät?

Toinen selkeä tapaus on sellainen, jossa nykyinen verkkopalvelu yskii niin pahasti, että uusi on pakko saada ja nopeasti. Tässäkin tapauksessa 50% tapauksista tilanne olisi voitu ennaltaehkäistä. Vain harvoin tilanne pääsee tosiasiallisesti yllättämään yrityksen totaalisesti housut kintuissa. Palvelun suosio on esimerkiksi niin huima, että suorituskyvyn rajat tulevat vastaan paljon ennakoitua nopeammin. Usein tilanne olisi kuitenkin ennakoitavissa hyvissä ajoin, mutta siihen tarttuminen on liian hidasta.

Valtaosa tapauksista menee kuitenkin heittämällä kategoriaan: on kiire, koska on kiire.

Miten väärältä kiireeltä voi välttyä?

Kiire on hallittavissa oleva asia projektissa siinä missä muutkin projektiriskit. Tässä muutama vinkki:

  • Vaikka liiketoiminta sallisi vain 3 kuukautta 6 kuukauden projektille, ei tilanne ole välttämättä mahdoton. Voisiko toiminnallisuuksia karsia niin paljon, että projektin ensimmäinen versio olisi puristettavissa 3 kuukauteen?
  • Joulukuussa tehdään 50% myynnistä, mutta ohjelmistoprojektin toimitus venyy väkisin maaliskuulle. Jos näin on, hyväksy asia. Seuraavanakin vuonna on joulukuu. Silloin verkkopalvelusi on varmasti viimeisen päälle pilotoituna ja iskussa!
  • Ohjelmistoprojekti on kahden kauppa: toimittajan ja tilaajan. Jos tilaajan resurssit ovat tiukilla, projekti tulee venymään. Se on kylmä fakta.
  • Käytä toimittajaa, joka hyödyntää ketteriä menetelmiä. Ketterät menetelmät varmistavat, että jokaisessa sprintissä syntyy pala valmista ohjelmistoa. Ohjelmisto on koko ajan periaatteessa lanseerausvalmiudessa.
  • Älä sanele aikataulua, vaan neuvottele se toimittajasi kanssa. Varaudu tulemaan vastaan aikataulutoiveissasi, jos toimittajasi perustelee tilanteen asiantuntevasti. Jos epäilet toimittajan kantaa, hae toinen mielipide asiaan.
  • Muista, että projekti tehdään sinulle. On oma etusi, että se tehdään rauhassa ja laadukkaasti!

Lopuksi on hyvä mainita, että aikataulutukseen realistisesti suhtautuvien määrä tuntuisi olevan lievästi nousussa. Yksi syy saattaa olla se, että ollaan jo eletty useampi ohjelmistoprojekti ja osataan varata sille sopiva aika. Esimerkiksi kolmatta verkkokauppaversiotaan tilaava asiakas suhtautuu yleensä totaalisen eri tavalla projektiin kuin ensimmäistään odotteleva.

Hyviä ja onnistuneita ohjelmistoprojekteja kaikille!