Aeg on alati suhteline – tegijal kulgeb see kiiresti, ootajal aeglaselt. Seega pole arendusele kuluva aja planeerimine samuti just niisama Exceli tabeli numbritega täitmine. Tarkvaraarendusfirma Singleton soovitab, kuidas tarkvaraarenduses ajakulu planeerida.

Millest koosneb tarkvaraarendusele kuluv aeg?

Põhimõtteliselt võib suuremaid üldistusi tehes jagada tarkvaraarendusele kuluva aja järgmistesse osadesse, kui võtta näiteks veebi ja selle back-endi või mobiiliäpi tegemise (erinevatel projektidel võib ajakulu olla üsna erinev):

1. ärianalüüs ja planeerimine – mõni nädal väiksema projektiga, kauem suurematega
2. tarkvara disain ja arendus – mõni kuu väiksema projektiga, 4-6 kuud keskmise, aasta või enam suure projektiga
3. testimine – tavaliselt 2-4 nädalat, probleemide avastamisel aeg pikeneb
4. juurutus – mõni kuu kuni lõpmatus (juurutuse käigus võib ka pidevalt tarkvara täiustada)

Iga ajaetapp neist kuuest võib ootamatult pikemaks venida, seega ega see suuresti ei aita kaasa teadasaamisele, kui kaua lõpuks aega kokku läheb.  Lühemaks muidugi ka, aga seda tunduvalt harvemini. Õige aja saab ette planeerida siis, kui kõik ülaltoodud  tarkvaraarenduse etapid on õigesti hinnatud. Siis pole pahane kumbki pool – ei arendaja, kellel lisatöödega tähtajad kuhjuvad ega tellija, kes tahaks kindlal ajal oma tellitud lahenduse kasutusele võtta, sest muidu jääb äritulu, mida loodetakse uuest rakendusest saada, saamata.

Milleks on ajakulu teadmine oluline nii kliendile kui arendajale?

Klient tahab valmis toote kätte saada kindlaks tähtajaks, et see hakkaks firmale kohe tulu teenima. Seni tuleb endistviisi läbi ajada või mõni ajutine lahendus leida. Mida kauem kestab arendus, seda suurem on kulu. Seega määrab arendusele kuluv aeg üsna suures osas ära ka arenduse hinna.

Arendaja jaoks on ajakulu teadmine oluline tiimitöö planeerimisel: millal erinevate etappidega valmis ollakse, kuidas kasutada mõne spetsiifilisema osa arendamiseks spetsialistide ressurssi ja millal võib oma vabanenud tiimi muude tööülesannete jaoks taas vabaks saada.

Muidugi on ka selliseid projekte, kus toimub pidev arendus (nn continuous development), kuid ka siis on hea teada, palju jooksvalt aega kulub, et saaks planeerida töötajate töökoormust ning vajadusel neid jagada erinevate projektide vahel. Jagamine toimub samuti ikka ajaliselt, sest vaevalt et keegi samal hetkel suudaks kahe kliendi asjadega ühe arvuti tagant korraga tegeleda.

Miks on aja planeerimine nii keeruline?

Kõik võiks ju olla tegelikult väga lihtne: sina ütled, mida vaja, kirjeldad seda võimalikult täpselt ning arendaja ütleb, mitu töötundi kulub, et see valmis teha. Lisaks on tähtis see, palju inimesi asjaga tegelema hakkab.

Paraku on tarkvaraarenduses esialgsest plaanist sihtmärgi suunas liikumine üsna sarnane kulgemisega ühest linnast teise.

Sa võid hakata jalgsi astuma – kütust ei kulu, saapad ehk natuke kuluvad, aga kohale jõudes oled üsna kokkuhoidlikult hakkama saanud, mis sest, et matkasid mitu päeva.

Võid ka jalgrattaga minna – saab mitu korda kiiremini. Autoga on veelgi kiirem, aga siis peab olemas olema auto ja piisavalt kütust. Bussiga võib teise linna viia 50 inimest korraga – aja- ja rahavõit on veel suurem.

Ka arenduses on algusest lõppu jõudmiseks samamoodi palju erinevaid valikuid. Väikeses mõne-mehelises firmas nokitseb keegi sinu projekti kallal teiste projektide kõrvalt ja jõuadki sihtpunkti samamoodi, nagu jalgsi või jalgrattaga – tasapisi ja odavalt.

Kui aga tahad, et roolis oleks professionaalne juht ja ei peaks lõputult ootama, on vaja tarkvaraarendajat, kus tegeleb projektiga asjatundlik meeskond. Muidugi juhib seda tiimi ka kogenud projektijuht, kelle tähtsamate tööülesannete hulka kuulub muuhulgas ka aja planeerimine.

Kui keeruliseks või lihtsaks võib kõik lõpuks minna?

Iga ettevõtte äritarkvara on tihedalt seotud selle firma äriga. Hea projektijuht elab sisse ettevõtte ärisse ja saab aru, mille jaoks arendust tehakse. Muidugi on ideaalne, kui arendaja on samas valdkonnas midagi juba teinud.

Samas võib hea kogemusega projektijuht täiesti uues valdkonnas kiiresti sisse elada.

Selleks, et ärist paremini aru saada, tulebki alustada ärianalüüsist ja selle põhjal tarkvaraarenduse planeerimisest. Alustada võib esimestest kohtumistest või videokõnest, milles klient selgitab oma äri lähemalt ja arendaja tutvustab oma kogemusi, kuidas võiks vajaminevaid lahendusi üles ehitada ning millised on arendusvõimalused.

Ilmselt saab juba mõne esimese kohtumisega selgeks, kas tegemist on projektiga, mis on tüüpiline (arendajal on sellise lahendusega kogemus olemas või on selliseid asju varem juba palju tehtud ning näited avalikult kättesaadavad). Mõnel juhul võib koguni arendaja soovitada mõne valmislahenduse kasutusele võtmist (näiteks kliendihaldustarkvara, raamatupidamislahendus, tööde planeerija jne), aga kui esimeste vestluste käigus selgub mõni erilisem või unikaalsem funktsioon, siis saab arendaja piirduda vaid lisamooduli arendamisega olemasolevale rakendusele, kui see on võimalik. Aega kulub vähem, kui esialgu arvati ja mõlemad pooled võidavad.

Kõige raskem on ajaliste hinnangutega siis, kui projekt on keeruline ja varem pole midagi sellist tehtud. Arenduses võib siis vaja minna uuenduslikku või spetsiifilist tehnoloogiat, näiteks tehisintellekti. Projektis võib sel juhul tulla ette ootamatusi ja nende jaoks tuleb arvestada ajavaru.

Kui palju lisaaega vaja?

20% kõikidest projektidest võivad muutuda nii-öelda ajaõgijateks, eriti just eelmises peatükis mainitud keeruliste ja täiesti uuenduslike tarkvaraarendustega. Sel juhul peab lisaaega kindlasti rohkem planeerima.

Tavaliselt aga arvestavad projektijuhid 5-25% lisaaega iga tähtaja juurde olenevalt projekti keerukusest.

Ohtlikud väljendid, mis ajakulu pikendavad

Lõpetuseks ka mõned näited ohtlikest väljenditest klientide poolt, mis võivad ettenähtud ajakava kergesti õhku lasta.

“Me ei tea täpselt, mida tahame, aga tehke midagi valmis, siis vaatame.” – võib üsna kindel olla, et selgeltnägija võimeid arendajal pole. Tehakse midagi valmis, kuid siis järgneb ümbertegemine, sest taheti midagi muud, aga mida täpselt, ei tea.

“Tegelikult võiks siia juurde veel mõned olulised funktsioonid lisada.” – muidugi võib tarkvaraarenduse käigus selguda, et alguses jäi midagi kahe silma vahele ja vaja oleks veel midagi, aga esialgne ajakava siis enam ei kehti. Tuleb tagasi tulla algse planeerimise juurde.

“Me arvasime, et see on ka hinna sees.” – kui poolel teel selgub, et midagi peeti enesestmõistetavaks ning et see tuleb projektiga kaasa, siis tuleks uuesti üle rääkida, mis siis ikkagi projekti hulka kuulub ja alustada jälle planeerimisest, kui soovitakse midagi lisaks.

“Tehke meile uus Youtube/Facebook/Twitter” – miks mitte, aga “uue” Facebooki tegemise ligikaudne maht arvatakse olevat miljon töötundi. Küsimus on hinnas.

Kõik on siiski võimalik!

Tarkvaraarenduse planeerimine pole siiski kaugeltki lootusetu kohvipaksu pealt ennustamine, selle jaoks on veel üks lihtne nipp, mis aitab graafikus püsida.

See nipp on ajapuhver. Kui arendaja ja tellija jagavad ühiselt arendusprojekti väiksemateks osadeks, siis iga etapi järele on hea jätta kas mõnepäevane või pikem ajapuhver, mille jooksul pole planeeritud tõsist planeerimist, arendust, testimist või juurutamist. Paratamatult võib mõnes etapis rohkem aega kuluda kui teises ja siis saab need ajapuhvrid täita ilma lõpptähtajaga ummikusse jooksmata.