Kuidas planeerida arendusprojekti tähtaegade mõistes?

Tänapäeval on tehnoloogilistel lahendustel ettevõtte efektiivsuse ja kasumlikkuse tõstmisel ning protsesside parandamisel väga tähtis roll. Ikka ja jälle räägitakse sellest, kuidas tooted ja teenused peavad jõudma tarbijateni kiiremini ja olema lihtsamini kättesaadavad, arvestades sealjuures erinevaid olukordi.

Võiks öelda, et paari aasta kõige parem näide on seotud covidiga, kui oli vaja kiiresti kohaneda ning aina rohkem käegakatsutavaid tooteid/teenuseid pidi kliendini jõudma ka interneti vahendusel.

Selle jaoks tuli nii mõnigi digilahendus kohandada, uuendada või lausa välja vahetada, et ettevõtte jätkusuutlikkust ning toimetulekut üleval hoida. Kõige olulisem kriteerium sellistel juhtudel on aeg.

Ameerika teadlane ja filosoof Benjamin Franklin (1706-1790) on lausunud kuulsaks saanud sõnad: “Üks täna on väärt kahte homset. Kaotatud aega ei leita enam kunagi. Aeg on raha.”

Paljud meie hulgast on terminiga “tähtaeg” pidanud silmitsi seisma erinevates olukordades, sh need, kellel on kokkupuude mitte ainult tehnoloogiliste lahenduste arendamisega, vaid ka tellimisega.

Oleme Trinidad Wisemanis (TWN) oma pikkade tegevusaastate jooksul kokku puutunud erinevate tähtaegadega. Nii mõnigi kord on tekkinud ärev tunne, kuna tähtaeg võib seada nii mõnedki piirangud, millega kliendid ei ole arendusprojekti planeerimisel arvestanud.

Järgnevalt toome, oma kogemustele tuginedes, välja 4 olulisemat soovitust tähtaegade osas, millega arendusprojekti planeerimisel arvestada.

Väga oluline on mõelda mitte ainult selle peale, millal projekt peab valmima, vaid ka sellele, millal on soovi sellega alustada.

Siinkohal tuleks läbi mõelda järgmised punktid:

Millisesse perioodi jääb kogu projekt?
Kui palju sündmusi jääb projekti perioodi sisse?
Kas on mõistlik alustada projektiga enne aasta lõppu või kohe aasta alguses?
Kas on hea, kui projekt avalikustatakse kasutajatele aasta lõpus või aasta alguses?

Miks on oluline vaadata üle ajaline periood algusest lõpuni? Tavaliselt antud perioodi kipuvad jääma olulised sündmused või pühad - olgu nendeks siis riigipühad või puhkepäevad, firma sündmused, suvepäevad, meeskonna liikmete puhkused vms.

Kindlasti ei ole hea mõte alustada ega lõpetada projektiga aasta lõpus või aasta alguses, sest näiteks detsembris on pikad pühad ning inimesed soovivad puhata. Aasta lõpus ja alguses toimuvad firmade jõulusündmused, tehakse aasta lõpetamise kokkuvõtteid ning planeeritakse järgmise aasta eelarveid.

Kõik need eelmainitud tegevused pikendavad tähtaega, kuna klient ega meeskond ei saa igapäevaselt projektiga tegeleda, vaid on hõivatud muude ettevõtte jaoks vajalike toimingutega.

Arendusprojekti planeerimisel tuleks mõelda ka selle peale, et kliendipoolsete lõppkasutajate sisend peab olema kokku pandud ja kogutud juba eelnevalt, kas siis analüüsi või disainimise käigus, näiteks prototüübi testimisel.

Tavaliselt kipub minema sedasi, et maja seest infot eelnevalt ei koguta, pigem jääb ta kitsasse ringi ning tõeline sisend tuleb alles siis, kui arenduse käigus tekib lisaküsimusi, mida analüüs ega disain ei kata.

Hullemal juhul, mida on ka TWNi projektides ette tulnud, saabub tagasiside alles siis, kui arendustegevused on enamjaolt tehtud ning arendus läheb juba kliendile testimisse. See võib aga tähendada, et tuleb midagi täiesti ümber teha või lisaarendust teostama hakata, kuna lahendus ei vasta lõppkasutaja ootustele.

Selline olukord mõjutab suuresti kogu arendusprotsessi pikkust, sealhulgas ka tähtaega. Väga oluline on ajaliste piirangutega projektis jälgida analüüsi ja skoopi ning hoida fookust, seda nii kliendi kui ka teenusepakkuja poolelt.

Kui aga tekib siiski selline olukord, kus on vaja olulisel määral muuta juba seni tehtut, tuleb arutada võimalusi tähtaegade pikendamise osas ning seda, kas ja kui palju paindlikkust on võimalik tekitada. Samuti tähendab see eelarve suurendamise vajadust.

Teinekord on lepingud aga väga jäigad - kindla eelarve ja ajagraafikuga, samuti võivad olla kirjas leppetrahvid. See tekitab omakorda lisapingeid - arendusmeeskond on sunnitud kiirustama, stressitase kasvab ning seetõttu võib kannatama hakata arenduse kvaliteet. Klient saab küll õigeks ajaks toote/teenuse valmis, kuid puudustega.

Selline tulemus jällegi tekitab stressi ja pahameelt kliendis. Nii tekib ahelreaktsioon, mille tagajärjel tekivad kommunikatsiooniprobleemid ja vaidlused ning taas tuleb mängu aeg. Kõik need vaidlused, testimised ja bug'ide parandused lükkavad kogu valmimise tähtaega edasi.

On tulnud ette ka olukordi, kus arvatakse, et paneme ruttu 2x rohkem arendajaid peale, et siis saab kiiremini valmis. Siin on omad miinused, millega tuleb arvestada: selline mõte tähendab suuremat rahalist kulu ettevõttele ja aega sellega kokku siiski ei hoia.

Enamjaolt on kliendi ootused peale lepingu sõlmimist sellised, et meeskond hakkab kohe arendusega pihta ning esimese paari kuuga saab juba näha tulemusi. Reaalsuses see kahjuks nii ei ole. Peale lepingu sõlmimist tuleb arvestada ca 1-2 kuud erinevate protsesside paikaloksutamisele, mida võiks nimetada ka sisseelamisperioodiks.

Millised tegevused siis lepingu alguses nii kaua aega võtavad?

Üldjuhul alustatakse arendusprojekti avakoosolekuga. Kutsutakse kokku juhtrühm, mis koosneb nii arenduspartneri kui ka kliendipoolsetest juhtivatest inimestest (nt projektijuht, tootejuht, kontaktisik, valdkonnajuht, turundusjuht) ning pannakse paika järgmised protsessid:

Kes mille eest vastutama hakkab?
Kes on kliendipoolne tooteomanik, kes annab vajadusel lisasisendit ning kinnitab tehtud tööd?
Kuidas ja kui tihti hakkavad toimuma regulaarsed koosolekud?
Kuidas toimuvad tööde üleandmised ja vastuvõtmised?
Milliseid suhtluskeskkondi kasutatakse?
Milliseid töömetoodikaid kasutatakse?
Kas on muudatusi projektimeeskonnas ja projektimeeskonna tutvustus?
Kas on tekkinud murekohti seoses tööde mahu, aja jms osas?

Kui avakoosolek on toimunud ja põhiprotsessid paika pandud, saab meeskond pihta hakata sisulisema tööga. See endiselt ei tähenda veel reaalseid silmaga nähtavaid tulemusi ehk arendust, vaid pigem järgmist:

arenduse ja testimise keskkondade ülesseadmine
õiguste-ligipääsude tellimine/taotlemine
suhtlus- ja dokumenteerimiskeskkondade seadistamine
dokumentatsioonide läbitöötamine
koosolekute aegade paikapanemine

Kõik need tegevused kokku võivadki võtta kuni 2 kuud ehk siis sellega tuleb arendusprojekti planeerimisel arvestada. Näiteks, kui klient pani paika projekti perioodi pikkuse, milleks on umbes 4 kuud, siis sinna tuleks kindlasti juurde arvestada kuni 2 kuud tööde algustegevuste peale.

Arendusprojekti planeerimisel on väga oluline arvestada aega ka testimisele. Testimine ei tähenda ainult seda, et teenusepakkuja poolt toimub arenduse testimine, vaid ka seda, et kogu projekti käigus on vaja testimine läbi viia ka kliendi poolt. Kindlasti tuleb mõelda selle peale, kas kliendipoolsel tooteomanikul või projektijuhil on selleks piisavalt aega.

Testimine võib toimuda iganädalaselt jupi kaupa, olenevalt millist metoodikat kasutatakse. Lisaks testitakse ka arenduse lõpus kogu lahendust.

Samuti võib testimise alla tuua sisuloome ehk inimesed, kes täidavad kogu veebi tekstide ja piltidega, sest ka nemad on mingis mõttes testijad. Kõik see võtab aega - olenevalt lahenduse suurusest võib selle peale minna mõni nädal kuni mitu kuud.

Kokkuvõtteks

Mõeldes läbi ja arvestades meie 4 väga olulise soovitusega enne, kui läheb lepingu sõlmimiseks, on suurem tõenäosus, et sinu arendusprojekt saab õigel ajal valmis.

Soovid oma ideid arutada?

Meie poole võib pöörduda igas projekti etapis - alates idee väljatöötamisest kuni uute digilahenduste loomise ja hindamiseni välja.

Võta ühendust

Kirjuta meile oma ideest ja leiame koos parima viisi selle elluviimiseks. Vastame kiiresti ning meie kogenud meeskond tagab, et projekt kulgeb edukalt alates esimesest mõttest kuni lõpliku teostuseni.

Kirjuta meile