Procenjivanje rokova (za programere)

Redovno će ti tražiti procenu roka koji je potreban za obavljanje nekog zadatka. U članku se govori o tome kako najbolje da priđeš takvom zahtevu, i šta je najbolji odgovor kadgod te neko pita za procenu.

Vukašin Stojkov - 12. Jul, 2018.

Počev sa ovim člankom pokrećemo serijal članaka baziranih na i inspirisanih klasičnom naslovom Pragmatični programer. Prenosićemo glavne teme iz ove knjige (za koju vas svakako ohrabrujemo da je pročitate u celosti), uz primere iz prakse, bilo kao dopune glavnim temama ili kao zasebne članke. Pošaljite nam vaše kritike ili predloge za primere iz prakse ovde.

Sasvim je izvesno da će te u tvom programerskom poslu nekada pitati da daš procenu roka potrebnog za realizovanje nekog zadatka. Sasvim je moguće da će te to pitati redovno. Ma koliko to ponekad bilo nezahvalno, priroda timskog posla je takva da se posao i planovi moraju usklađivati vremenski, i sasvim je razumno da je u takvoj postavci stvari davanje procena rokova neophodna stvar.

U isto vreme, rokovi umeju da budu i veoma nezgodna stvar, naročito kada se promaše, jer je procena vremena potrebnog za različite zadatke inherentno kompleksna. Iz toga sledi da je procena rokova jedna od najvažnijih programerskih veština, koja, ako je dobro razviješ, može da bude veoma korisna tebi i tvom timu, a ukoliko je usavršiš može da deluje nestvarno precizno, kao magija.

Vrste preciznosti i vremenske jedinice

Jedan od prvih, najvažnijih koraka koji treba da preduzmeš u davanju procene roka je shvatanje toga koja vrsta roka se traži od tebe. Da li se od tebe očekuje okvirna ili tačna procena? Ako te baka pita kada dolaziš verovatno je zanima da li da ti spremi ručak ili večeru, a ukoliko te ronilac zarobljen pod vodom sa ograničenom količinom kiseonika pita istu stvar, verovatno ga zanima odgovor koji je tačan u minut. U zavisnosti od očekivanja možeš proceniti kako da formiraš procenu i koji nivo preciznosti možeš da pružiš, ako uopšte možeš.

A u zavisnosti od toga kakav je rok koji procenjuješ možeš izabrati i vremensku meru kojom ćeš ga iskomunicirati, jer će one formirati očekivanja tvojih saradnika. Ukoliko iskomuniciraš rok u velikom broju vremenskih jedinica, ljudi mogu očekivati visok nivo preciznosti. Ukoliko proceniš da će nešto biti urađeno za 300 minuta, ili za 130 dana, efekat će biti dosta drugačiji nego ako kažeš za oko pet sati, ili za oko šest meseci.

Ovako možeš razmišljati o jedinicama koje ćeš koristiti:

ROK            KORISTI

1-15 dana      dane
3-8 nedelja    nedelje
8-30 nedelja   mesece
30+ nedelja    dobro razmisli pre nego što daš procenu

Jedan od najbržih “hakova” koji ti mogu pomoći da daš dobru procenu roka je to da naprosto pitaš nekoga ko ima dosta iskustva sa sličnim projektima, što je skroz zdravorazumsko ali se ponekad izgubi iz vida.

Primer iz prakse

Mi smo uveli sat kao jedinicu pošto nam je takav bizins model — klijentima treba procena koja je bazirana na satima. U međuvremenu smo shvatili da je to dobar model i za procenu celog projekta.

Kad imamo ceo opseg projekta sednemo i odvojimo koliko god vremena je potrebno, dva dana, za detaljnu analizu svega što treba da se uradi. Projekat se razbija na sitnije taskove, tako da nijedan ne prelazi 32 sata. Procenu krećemo od najmanje jednog do najviše 32, koristeći stepen dvojke tako da zadaci moraju da se procene na neki od ovih rokova — 1, 2, 4, 8, 16 ili 32 sata. Kada smo uveli ovaj sistem primetili smo da se dosta smanjuju greške pri procenama. 

Uveli smo i poker estimate — šaljemo poziv troma članova tima, od kojih jedan mora biti senior, da daju procenu dužine zadatka, i te procene su tajne sve dok ih svi ne pošalju. Tek onog trenutka kad su svi učesnici poker estimate-a dali procenu onda postaju javne i tek onda svi mogu da vide šta je neko drugi dao. Često se dešava da ljudi imaju velika razilaženja u procenama, recimo da od tri developera jedan da 16, drugi daju 4, što nam pomaže da vidimo da nešto nismo shvatili. Tada je praksa da sednemo i usmeno porazgovaramo o zadatku i vidimo šta je to što je neko precenio ili potcenio.

— Ivan Stepanović, StuntCoders

Kada procene nemaju smisla i kako se postaje bolji u njima

Najbitnije doduše je to da se dobro, potpuno razume opseg posla. Radi ovoga možeš kreirati mentalni model projekta, razbijen na pojedinačne komponente uz opise toga kako one mođusobno funkcionišu.

Uz sve navedeno, sva pravila procenjivanja rokova padaju u vodu kada su u pitanju izuzetno kompleksni, veliki projekti. Na takvim projektima je često jedini način za davanje procena rokova to da se na njima radi i da se na osnovu stečenog iskustva procena kreira. Ovo je nešto što menadžmentu može biti teško da prihvati, ali je tvoja dužnost da im pomogneš da shvate da je to jedini način da očekuju smislenu procenu.

Na kraju, da bi stekao veoma razvijenu, “magičnu” sposobnost za procenjivanje rokova, potrebno je da vodiš računa o tome kako ti prolaze procene. Zapisuj svaku procenu koju daješ, i nakon što se projekat završi, vidi koliko je tačna bila, i za svaku koja nije bila dobra probaj da shvatiš i naučiš zašto je to bilo tako.

Primer iz prakse

Kada su veliki projekti u pitanju ne radimo procenu celine, već pišemo dokument koji se zove Work Breakdown Structure i on se radi po principu podeli i zavladaj. To znači da pokušamo da uočimo sve manje taskove u okviru velikog taska i onda dajemo procene za svaki njih taskova.

A koliko se može omanuti sa procenom smo se podsetili na jednom skorom projektu koji je bio vezan za redizajniranje jednog postojećeg sajta. Problem je bio što nismo uložili dovoljno vremena da se procene svi aspekti projekta, sve što je trebalo u okviru njega da se napravi. Imali smo nekih par metoda naplaćivanja koje smo morali da pišemo i za koje nije postojala neka integracija, pa smo morali da ih pišemo od nule i to nas je dosta usporilo i izazvalo je dosta neprocenjenih sati na projektu.

Umesto da smo nekih 10, 20 ili 30 utrošili na početku da dobro analiziramo opseg posla, došli smo do toga da smo projekat radili dva puta duže nego što smo inicijalno planirali, što je dovelo do nekih 400-500 sati posla na koje niko nije planirao, što je trošak koji smo najvećim delom mi pokrili.

— Ivan Stepanović, StuntCoders

Bonus

Umesto zaključka, evo bonusa. Najispravniji odgovor u svakoj situaciji u kojoj ti neko traži odgovor je sledeći — “javiću vam malo kasnije”.

Rubrika pragmatično programiranje je pod pokroviteljstvom StuntCodersa →