Elisa IT-juht: miks arendusprojektid tegelikult pidevalt üle tähtaja jooksevad?

Olukord, kus arendusprojektid üle tähtaja jooksevad, on sama tavaline kui see, et mõni remondiprojekt taaskord üle lubatud aja ja eelarve piiride nihkub. Kui tihti viidatakse, et probleemis on süüdi liiga optimistliku ajaraami välja pakkunud arendustiimid, siis Elisa IT-juhi Villu Teearu sõnul tasub enamasti aga probleeme otsida mujalt.

“IT-tiimid tahaksid kogu hingest projektidega õigeks ajaks valmis saada ja kui nad oma ajahinnanguid annavad, siis ei paugutata numbrilt puusalt, vaid analüüsitakse päriselt kõik läbi ja käiakse lauale realistlik ajaraam. Aga pärast seda, kui ajaraam on välja käidud, hakkab tihtipeale juhtuma üksjagu olukorda muutvaid asju, mille tõttu ei suuda töid õigeks ajaks ära teha kõige nobedamate näppudega programmeerija,” lausus ta.

Peamiste olukordadena hakkavad tavaliselt esile kerkima scope creep ehk algselt paika pandud töö skoobi suurenemine, erisuguste äriliste nõudmiste muutumine, erinevate varem üles märkimata jäänud nüansside ja erijuhtude selgumine ja hulgaliselt muud, mis lõpuks töömahtu oluliselt suureneb. See tähendab enamasti seda, et arendustiimid andsid algse töömahu prognoosi pealt tõepärase ajahinnangu, aga selleks ajaks kui projekt lõpuks valmis saab, on reaalne nõutud töömaht märgiliselt tõusnud.

Uute ülesannete ja nõudmiste lisandumise kõrval tekitab tõelist ohtu ajahinnangutega eksida Teearu sõnul ka see, kui ühe korraga üritatakse läbi töötada liiga suur tükk tööd. “Näiteks kui tekib olukord, kus arendustiimi ajahinnang hakkab ületama aastat, on sisuliselt võimatu, et see hinnang saab olla täpne. Aastase ajaraami sees on lihtsalt nii palju ettearvamatuid muutujaid, mis muudavad kaugesse aega pandud eesmärgi saavutamise sisuliselt võimatuks – kõik võib lihtsalt veel muutuda,” selgitas ta.

Rohi on olemas

Viimast mure aitab küll suuresti lahendada agiilsed arenduspraktikad, kus tiimid töötavad sprintide kontekstis ja ühe korraga hinnatakse vaid mingile jupile kuluvat aega, kuid ka siis võivad eelnevad ohud pead tõsta. “Äripoolel pole tihti midagi peale hakata teadmisega, et moodulid 1 ja 3 suuremast asjast saavad valmis ülehomme. Nad tahaks teada, millal kõik valmis saab ehk millal saab toote kasutusele võtta. Siin hakatakse aga jälle põrkuma vastu seda, et väga kauges tulevikus kindlaid tähtaegasid välja lubada on üsna võimatu,” ütles Teearu.

Nii see kui ka scope creep on koht, mida saab lahendada vaid avatud suhtlusega ja sellega, et nii äripool kui arendustiim mõistavad täpselt, mis on teise poole vajadused ja võimalikud takistused. Niisamuti seda, mis on kõige mõistlikumad tegevused parimate tulemuste saavutamiseks. Selle kõrval on olulisel kohal ka see, et IT-tiim kui eksperdid julgeks ja oskaks vajadusel jala maha panna ning teised osapooled seda ka kuulda võtaks.

Teearu tõi näiteks, et tihti ei pruugi IT-maailmaga mittekursisolevad inimesed realistlikult eeldada, kui palju mõned lisatööd aega võivad võtta. “Mõeldakse, et laseme teha muutuse X, see võtab ju ainult viis minutit. Aga reaalsuses võib selle muutuse taga olla meeletu kogus taustatööd ja üks arendaja peab sellega tegelemisele kulutama terve oma töönädala. On ilmselge, et sellise asja tõttu hakkavad edasi lükkuma ka kõik muud tähtajad,” selgitas ta.

See ongi tema sõnul koht, kus IT-tiim tervikuna, või vähemasti projektijuht, peab suutma kõikidele seotud osapooltele selgitada, mis nende esitatud soovidega tegelikult kaasneb. Kui osapooled nõustuvad, et mingi muutuse tõttu lükkuvad edasi ka kõik teised tähtajad, siis saab asja töösse panna. Kui aga väikese soovi kõrval suurt ajakulu nähes mõttest loobutakse, saab tööd endiselt õiges graafikus hoida. “Pealtnäha tundub kõik lihtne, aga enamasti on iga lihtsa asja taga terve lai tööpõld, mida ei osata näha,” märkis ta.

Tellijad ei pruugi teada, mida nad tegelikult tahavad

Sageli võib lisatööde vajadus tuleneda ka sellest, et reaalsed soovid hakkavad seotud osapooltel tekkima siis, kui nende ette jõuab midagi käegakatsutavat. See on ka põhjus, miks soovitab Teearu paljude erinevate stakeholderitega projektides võimalusel kaaluda MVP loomist või vähemalt suures osas tulevane toode paberil valmis joonistada.

“Inimesed on visuaalsed ja kui midagi on juba natukenegi katsutav, tekib alati meeletus koguses ideid, millele varem üldse ei mõeldagi. Saadakse aru, et siin-seal peaks veel mõni nupp olema ja kui panna midagi siia, peaks midagi juhtuma seal. Algses skoobis neid asju sees ei olnud, aga kui need vajadused piisavalt vara tuvastada, on võimalik projekti aegsasti muuta – üheskoos leppida kokku uues tähtajas või praakida välja mõned kaugema otsa nice to have asjad, mis uue konteksti valguses enam nii olulised ei tundu,” ütles ta.

“Muidugi on oluline ka see, et arendustiimid saaks aru, mis on see, mida tellijad tegelikult ootavad. Ideaalses maailmas on kuskil list prioriteetidest, või vähemasti on tiimidel piisava kogemuse pealt tekkinud arusaam, millele on ajasurve korral mõistlik kõige rohkem keskenduda. Kui on teada, et tellija jaoks on kõige olulisem see, et logo oleks õiges kohas, aga tal on suhteliselt ükskõik sellest, mis värvi on lehe jalus, on ajanappuse korral võimalik esimeses järgus keskenduda sellele, mis on päriselt kõige vajalikum,” rääkis ta.

Niisamuti on mõistliku ajakasutuse juures oluline ka see, et töö tegijad suudaks tellijale ära selgitatakse, miks on tarvis ühele või teisele asjale aega kulutada. “Mida paremini tellija aru saab, mida tehakse ja miks tehakse, seda lihtsam on tal ka omalt poolt prioriteetide järjekorda paika saada. IT-asjadest teadmata on näiteks lihtne lükata mõni andmebaasi teema kõige taha ja suruda peamise tegevusena visuaalset poolt puudutavaid töid. Aga kui tegevuste taga olev loogika on ära selgitatud, on enamasti võimalik kokku saada mõistlik plaan, mis rahuldab kõik vajadused ja mille saab kõik tööd tehtud ettenähtud aja jooksul,” lausus Teearu.