Kui tahad, et su It projekt laabuks ja oleks edukaks, alusta projekti dokumentatsioonist

Enamik IT arendusprojekte kukub läbi, sest eeltöö ei olnud piisavalt hästi tehtud. Enamik vaidlusi kliendi ja teenusepakkuja vahel tulevad asjadest, mis oleks võinud enne arendust läbi mõelda. Ei ole mõtet end petta - kui sa tahad edukat IT projekti, tee korralik eeltöö ka loo projekti dokumentatsioon.

Kuus viisi, kuidas projekti dokumentatsioon teeb projekti arenduse sujuvamaks.

Oma karjääri algusperioodil, kui alustasin tööd projektijuhina veebiagentuuris avastasin rääkimata saladuse, mille peale nagu keegi ei näinud mõtlevat ja defineerisin probleemi. Nimelt puudus enamikul projektidel korralik analüüs. Veelgi enam, ilma selleta ei olnud klientidel võimalik saada võrreldavaid hinnapakkumisi, mis selgelt eristuksid üksteisest ja mida oleks võimalik vähem asjatundlikumatel analüüsida.

Kas sina telliksid maja hinnapakkumised ja ehituse ilma projektita?

Lihtsustatult kirjeldades toimib tavapäraselt protsess kliendi vaatevinklist järgmiselt; klient kohtub arendajaga ja annab talle üldise kirjelduse selle kohta, mida ta ootab. Arendaja küsb erinevaid täpsustusi ja klient vastab. Sama ka teise ja ehk veel kolmanda ja neljanda arendajaga. Küsimused olid teised, ettepanekud teised ja sellest tulenevalt ka vastused arendajatele olid alati erinevad. Kuidas, saab sellisel juhul eeldada, et töö, mida iga arendaja pakub annab sama tulemuse? Kuidas saab adekvaatselt hinnata pakkumiste kvaliteeti või hinda, kui alginfo pole kõigil sama ning kõik arendajad on sinna midagi juurde mõelnud.

Sellele järgnev arendusprotsess päädis alati sellega, et klient hakkas projekti lõpus esitama küsimusi stiilis “kas te seda ei teegi või”, “ma arvasin, et see toimib nii”. Enamjaolt seepärast, et a) klient ei olnud kirjeldanud oma nägemust piisavalt hästi ja see ei olnud kirjeldatud selgelt b) Klient arutas funktsionaalsust ühe arendajaga, kuid mitte sellega, kellelt töö tellis. Hea idee, mida arutati, jäi algdokumentatsioonis üles tähendamata.

Sellise vaidluse järe ei olnud rahul ei klient ega arendaja, kelle mõlema jaoks oli protsess ebameeldiv. Selle asemel, et viidata tööde teostamise raames dokumentatsioonile või projekti plaanile, tekkisid vaidlused lähtuvalt kliendi rääkimata või dokumenteerimata ootustest. Või tekkisid vaidlused sellest, et arendaja ei olnud aru saanud kliendi kirjeldustest või vajadustest.

Selgitan allpool lahti, kuidas igale projektile detailse analüüsi tegemine aitab sul projekti arenduse protsessi kõigi osapoole jaoks paremaks teha.

Sul on võimalik saada omavahel võrreldavaid hinnapakkumisi

Ainult siis, kui kõikidele arendusteenuse pakkujatele jagada sama info on sul pakutavad lahendused omavahel võrreldavad. Kõik küsimused ning ettepanekud mida nad esitavad saab samuti vastatud ja dokumenteeritud algses dokumentatsioonis - selliselt on kõikide teenuse pakkujate vahel jagatud ka kõik tekkinud uued mõtted ja ideed.

Nagu ei hakkaks sa kunagi võtma maja ehituse pakkumisi ilma projektita on alati mõistlik ka oma projekt korralikult ja detailselt dokumenteerida. Kuidas muidu saad sa hinnapakkumisi, mille alusel teostatud töö annab sulle täpselt sama tulemuse?

Arenduspartneri vahetamine on lihtsam.

Probleem, mida IT agentuurid tihti näevad, kui nad satuvad rääkima kliendiga, kes soovib, et arendatud projekt võetaks uue arendaja poolt üle, on see, et projektil puudub dokumentatsioon. Kui projektil see puudub, siis on projekti üle võtmine keeruline, sest uus arendaja ei tea KUIDAS täpselt peab projekt töötama, millised on praegused kliendi vajadused ja probleemid mida projekt lahendama peab. Klient peab kõike juba kunagi räägitut uuesti kordama, kuna vajadused on kirjeldamata ja dokumenteerimata. Öelda, arendajale, et “vaata, kuidas praegune lahendus töötab” on kasutu ja isegi ohtlik, sest koodile otsa vaadates ei ole selge, mis on vanas lahenduses hea või halb. Mis on bugi ja mis mitte. Kord olin ise projektijuhi rollis sellises seisus ja tegin vea, loobudes dokumentatsiooni koostamise nõudmisest ja tekitasin lõpuks olukorra, mis kõigi jaoks halb oli.

Kui kliendil on aga kogu projekti vajadused dokumenteeritud on kliendil ka märksa lihtsam arenduspartnerit vahetada. Kui lisaks sellele on nõutud ka, et arendatud funktsionaalsus oleks testidega kaetud on see veel lihtsam. Ikka ja jälle näen ma kliente, kes jõuavad minu juurde jutuga, et arenduspartneriga on suusad ristis ja mina pean nentima, et alustame projekti dokumenteerimisest ja vajaduste kirjeldamisest.

Uute arenduste tellimine on lihtsam

Ka juhul, kui sa teed edukat koostööd olemasoleva arenduspartneriga on sul palju kasu sellest, kui sul on vajadused ja nõuded dokumenteeritud. Erinevate arenduste vahel võib teinekord olla kuid ja aastaid. Aga kui sul tekib vajadus uue arenduse järgi või muudatuse järgi on sul võimalik alati viidata dokumentatsioonis sellele, milline on praegune seis, milline on tuleviku seis ja milles seisneb vajalik muudatus.

See on oluline ka seetõttu, et ka arendusettevõttes vahetuvad töötajad ja sellise dokumentatsiooni puudumisel on uuel töötajal väga keeruline minna sisse süsteemi. Dokumentatsiooni olemas olles võidad aga sa suure tõenäosusega arenduse ajas.

Klient võidab arenduse kiiruses, hinnas ja kvaliteedis

Kui süsteemi toimimine on läbi mõeldud ja dokumenteeritud on arenduse hinna pakkujal vähem ootamatusi, mis tähendab, et sul on võimalik saada selgemaid, odavamaid ja paremini läbi mõeldud hinnapakkumisi. See on nii, nii uue arenduse, kui ka olemasolevale rakendustele muudatuste tellimisel. Ka sinu töötajad võivad vahetuda - ka neil on lihtsam projekti süveneda ja arenduspartneriga suhelda - kui sinu nõuded rakendusele on dokumenteeritud.

Kliendil on parem ülevaade arenduse käigust

Sul on igal hetkel võimalik võrrelda oma dokumentatsiooni ja vajaduste kirjeldusi sellega, mis on juba ära tehtud. Või, mis veelgi parem, lasta arendajal sinu jaoks seda ülevaadet ajakohasena hoida.

Sul on alusdokument kasutustestidele.

Korralik vajaduste kirjeldus on ka hea alus rakenduse testimisele. Tehku seda siis arendaja või on see sisseostetud kolmanda osapoole teenus. Mõlemal juhul on võimalik võtta dokumentatsioonist funktsioonide kirjeldus - mis on sama kõigile - ja vaadata, kas lahendus toimib nii, nagu kirjeldatud on. Samuti on siis lihtne süsteemselt välja tuua probleeme ja mittevastavusi dokumentatsioonile.

Mina saan sind sellise dokumentatsiooni kokkupanemisel aidata.

Olen erinevatel töökohtadel läbi töötanud paljude klientide erinevaid arendusvajadusi ning kirjutanud kokku projektide dokumentatsioone. Sama tööd olen teinud ka hiljem, konsultandina. Õnneks on nii mõnedki kliendid seda dokumentatsiooni loodud väärtust näinud ja hinnanud.