Postoji fraza koja se vrlo često koristi – ne možeš da planiraš ako ne možeš da izmeriš. Istina, merenje funcioniše odlično u brojnim industrijama kao što su građevina, proizvodnja, prodaja... Međutim, zašto sa softverom ne možemo da merimo ovako efikasno?
Merenje produktivnosti developera nam nekako ipak izmiče, uprkos brojnim alatima koji su napravljeni baš za tu svrhu, ali i njeno povećanje.
Za developere je važno da se isporuči maksimalna vrednost korisnicima. Važno je i usmeravanje energije i inovacija na najbolji mogući način prema ciljevima kompanije.
Iako je mnogima jasno da nije lako izmeriti produktivnost onako kako bismo to želeli i kako smo navikli, pojedini mitovi i dalje opstaju.
10x developer
Postoji teorija, dobrim delom potkrepljena podacima, da su najbolji developeri 10 puta bolji od najgorih. S obzirom na to razlike u platama ne govore ovome u prilog, očito je pravi pogodak za kompanije da pronađu jednog takvog i plate ga „samo“ 2 ili 3 puta više od ostalih programera.
Studije koje su se bavile ovom problematikom čak su izrodile i analizu koja je pokazala da je u jednom trenutku 20 odsto ljudi realizovalo oko 50% posla.
Samim tim, menadžeri bi trebalo da se oslobode ovih drugih 80% neproduktivnih i da zapošljavaju samo one developere koji se nalaze u vrhu onih 20 odsto – ali svima je jasno da to - niti je izvodljivo, niti realno rešenje za uspeh.
Neko će biti prirodno talentovan, neko će imati odgovarajuće lične osobine da se uklopi u tim, neko će imati želju da pomera granice, dok će drugi biti zadovoljni prosekom. Teško je, da ne kažemo nemoguće, sve ovo pronaći u jednoj osobi.
Tradicionalni metodi merenja
Hajde da vidimo koji načini merenja produktivnosti se koriste i koji su njihovi nedostaci.
- Radni sati
Deluje kao najočigledniji izbor. Ako ste radili 10 sati umesto 8, to znači da ste uspeli da obavite 125 odsto svog posla. Prosta matematika. Međutim, jasno je da ova računica ne važi za sve. Zapravo, rad koji traje satima zapravo može biti sjajan način da smanjite produktivnost.
- Linije izvornog koda
Zvuči kao sjajan odraz nečije kreativnosti i produktivnosti. Potrebno je samo pratiti koliko je linija koda neko napisao i sve ostalo će se samo složiti.
Međutim, postoji mnogo problema sa ovom metrikom...
Podstiče štancovanje linija koda kako bi se dostigli traženi brojevi, iako je rešenje sa 200 linija mnogo brže ili bolje od rešenja problema sa npr. 1.000 linija koda.
Ponekada je rešenje da se kod obriše, a 5.000 linija bagovitog koda je svakako gore od 1.000 linija bez ikakvih grešaka.
Developeri takođe mogu samo da kopiraju kod kako bi zadovoljili normu, a da pritom ne uzmu brojne druge bitne faktore (koji usporavaju „rad“) kao to su tehnički dug, loš dizajn ili verovatnoća za pojavljivanje bagova.
- Broj defekata
Ideja iza ovog rešenja jeste merenje broja defekata koji je svaki developer napravio. Iako može izgledati razumno, postoji nekoliko razloga zbog kojih je ovo loša mera produktivnosti.
Favorizuje popravljanje bagova nauštrb razvoja novih funkcija, obeshrabruje developere da se posvete većim projektima, i najvažnije, nisu svi bagovi isti.
Mit koji nikako da nestane
Prva i osnovna greška jeste to što ne možemo pretpostaviti da se sve što developer radi može konzistentno meriti. Da je moguće, najveći mozgovi Applea, IBM-a, Intela Microsofta i Amazona bi svakako pronašli način da to urade.
Jasno je da developeri znaju ko je bolji, ali ne postoji broj niti sistem rangiranja koji možemo da napravimo i to objektivno izmerimo.
I na samom kraju, vreme za odmor i vraćanje energije, prkosni akt potpune neproduktivnosti je ključan za mentalno blagostanje i sreću svih ljudi, pa čak i developera.