Zašto procjene razvoja softvera uvijek promaše, i kako dobiti procjenu s kojom možete planirati

Razgovor obično izgleda ovako. Voditelj traži izmjenu na ekranu za narudžbe: novo polje, novo pravilo za popuste, mali izvještaj. Programer malo razmisli i kaže: „Otprilike dva tjedna.” Dva mjeseca kasnije posao još nije gotov, a voditelj se pita je li programer lagao, ljenčario ili jednostavno ne zna raditi svoj posao.

Najčešće nije ništa od toga. Procjena je vjerojatno bila iskrena za posao kakav je bio opisan prvi dan. Problem je što posao s prvog dana i posao koji je na kraju isporučen nisu bili isti posao, i što su ona dva tjedna podrazumijevala dva tjedna neprekinutog rada kojih nikad nije bilo.

Ovaj članak je za vlasnika, direktora ili voditelja poslovanja koji mora planirati oko softvera i stalno ga nešto iznenadi. Objašnjava zašto procjene promašuju, gdje vrijeme stvarno odlazi i kako tražiti procjenu s kojom zaista možete planirati.

Procjene počinju široko, i to je normalno

Steve McConnell, autor standardne knjige o procjeni softverskih projekata, opisuje cone of uncertainty, odnosno konus neizvjesnosti. Na samom početku posla, dok je to tek ideja, procjena može promašiti i do četiri puta u bilo kojem smjeru. Dva tjedna mogu zapravo biti pola tjedna, ili osam tjedana. Kako se posao definira, dizajnira i započne, raspon se sužava.

Faza	Realan raspon za „dva tjedna”
Ideja opisana jednom rečenicom	0,5 do 8 tjedana
Dogovoreno što treba raditi	1 do 4 tjedna
Zahtjevi napisani i provjereni	1,3 do 3 tjedna
Dizajn gotov, rad započeo	1,6 do 2,5 tjedna

McConnell to naziva najboljim slučajem. Raspon se sužava samo kad netko stvarno donese odluke koje uklanjaju neizvjesnost. Samo protok vremena ga ne sužava.

To je prvi razlog iznenađenja: jedan broj izgovoren prvi dan, za zahtjev od jedne rečenice, najnepouzdanija je procjena koju ćete ikad dobiti. A većina „dva tjedna” izgovori se upravo u tom trenutku.

Gdje vrijeme stvarno odlazi

Čak i kad je procjena za pisanje koda točna, kod je samo dio posla. Realna podjela „dvotjedne” izmjene na poslovnoj aplikaciji koja radi već godinama:

Posao	Obično uračunat u procjenu?	Tipičan udio
Pisanje novog koda	Da	40 %
Razumijevanje postojećeg koda koji se dira	Djelomično	15 %
Testovi i ispravljanje onoga što testovi pronađu	Često ne	15 %
Code review i izmjene nakon reviewa	Rijetko	10 %
Isporuka, konfiguracija, migracija podataka	Rijetko	10 %
Pitanja, pojašnjenja, čekanje na odgovore	Nikad	10 %

Udjeli su ilustrativni, nisu izmjereni, ali tko god je isporučivao softver prepoznat će ih. Ako je programer procijenio samo prvi redak, iskren zbroj bio je bliže četiri ili pet tjedana i prije nego što je išta pošlo po zlu. U starijim sustavima drugi redak je puno veći, što objašnjava naš članak o tehničkom dugu i sporom razvoju.

Kako dva tjedna postanu dva mjeseca

Najveći uzrok rijetko je sama procjena. To je ono što se događa nakon nje. Primjer, izmišljen ali tipičan:

1. 1. tjedanRad počinje kako je dogovoreno
2. 2. tjedan„Može li to riješiti i povrate?”
3. 3. tjedanHitan problem u produkciji, tri dana izgubljena
4. 4. tjedanDrugi projekt postaje glavni prioritet
5. 6. tjedanPovratak na posao, pola treba ponovno shvatiti
6. 7. tjedanPravilo za popuste se mijenja nakon prezentacije
7. 9. tjedanKonačno isporučeno

Nitko nije napravio ništa dramatično krivo. Svaki pojedini zahtjev bio je razuman. Zajedno su od posla od dva tjedna napravili posao od devet. Koliko je svaki od njih stvarno koštao:

Što se tražilo	Kako zvuči	Koliko stvarno košta
„Može li to riješiti i povrate?”	Još jedan slučaj	Nova pravila, novi testovi, često i preslagivanje onoga što je već napravljeno
Hitan problem u produkciji	Tri dana	Tri dana, plus vrijeme da se čovjek vrati u posao
„Stavi to na čekanje, drugi projekt je hitniji”	Pauza	Ponovno učenje posla kasnije, i rizik da se kod ispod u međuvremenu promijenio
Izmjena nakon prezentacije	Mala korekcija	Poništavanje i ponovna izrada dijela onoga što je gotovo
„Samo kratko pitanje”, nekoliko puta dnevno	Ništa	Prekinuta koncentracija, svaki put

Prebacivanje između poslova zaslužuje broj. Gerald Weinberg, autor knjiga o razvoju softvera, predložio je okvirno pravilo: svaki dodatni projekt na kojem osoba radi paralelno odnese oko 20 % njezina vremena samo na prebacivanje. Programer podijeljen između dva projekta ne daje svakom pola tjedna, nego bliže 40 %, a preostalih 20 % izgubi se negdje između.

Zašto pritisak ne pomaže

Kad rokovi klize, prirodna reakcija je pritisak: čvrst datum, dnevni sastanak o statusu, podsjetnik da kupac čeka. To obično pogorša stvar.

• Pod pritiskom procjene postaju kraće, ne bolje. Ljudi kažu broj koji završava sastanak, ne broj u koji vjeruju.
• Testovi i review prvi otpadaju. Rok je ispoštovan, greške stižu tjedan kasnije, a njihovo ispravljanje košta više od ušteđenog vremena.
• I sastanci o statusu su prekidi. Dnevna provjera zadatka koji kasni oduzima vrijeme samom zadatku.
• Dobri programeri to primijete. Stalni pritisak rokova uz stalne promjene prioriteta jedan je od razloga zašto odlaze dobri programeri.

Kako tražiti procjenu s kojom možete planirati

Procjenu razvoja softvera ne možete učiniti preciznom. Možete je učiniti korisnom.

1. Tražite raspon, ne broj. „Između dva i četiri tjedna” nosi više informacija od „tri tjedna”. Ako je raspon jako širok, i to je korisna informacija: posao još nije shvaćen.
2. Pitajte što bi ga produljilo. „Što bi od ovoga moglo napraviti šest tjedana?” Odgovor vam pokazuje rizike, a često i odluku koju možete donijeti odmah da jedan od njih uklonite.
3. Podijelite posao. Veliki posao procijenjen u komadu je nagađanje. Isti posao podijeljen na dijelove od po nekoliko dana, svaki isporučen i pokazan zasebno, je plan. Jasna specifikacija softvera tu puno pomaže.
4. Neka procjena uključi sve. Pitajte izravno: jesu li uključeni testovi, review, isporuka i migracija podataka? Ako nisu, dodajte ih.
5. Ponovno procijenite kad se nešto promijeni. Novi zahtjev znači novu procjenu, ne fusnotu uz staru.

Što vi kao direktor možete napraviti

Većina vremena izgubljenog u gornjem primjeru nije bila u rukama programera. Ovo je u vašima:

• Jedan kanal za nove zahtjeve. Ideje, greške i izmjene idu na jedno mjesto, a ne izravno onom programeru koji je najbliže.
• Prioriteti koji vrijede barem dva tjedna. Mijenjajte ih kad morate, ali ne svakih nekoliko dana. Plan koji izdrži dva tjedna vrijedi više od savršenog plana koji izdrži dva dana.
• Nove ideje idu u sljedeći krug. „Može li to riješiti i povrate?” je dobro pitanje, a odgovor glasi: može, u sljedećem dijelu posla, s vlastitom procjenom.
• Zaštitite vrijeme za koncentraciju. Manje sastanaka, manje kratkih pitanja i jedna osoba koja preuzima hitne probleme u produkciji, da ne prekidaju sve.
• Gledajte trend, ne jedan promašaj. Ako tim dosljedno premašuje procjene za 50 %, planirajte s 1,5 puta njihovim procjenama i radite na uzrocima. To je poštenije od pretvaranja da će sljedeći put biti drukčije.

Kad posao radi vanjski partner, ista logika vrijedi i za ugovor. Naš članak o tome je li bolja fiksna cijena ili naplata po satu objašnjava zašto fiksna cijena ne uklanja ovu neizvjesnost, nego je samo prebacuje u cijenu.

Pitanja koja najčešće čujemo

Zašto programer ne može jednostavno dati točan rok?

Zato što na početku nitko ne zna točno što će posao obuhvatiti, uključujući i onoga tko ga traži. Detalji izlaze na vidjelo tijekom rada. Točan datum na početku je obećanje, ne procjena, a obećanja dana u neizvjesnosti obično se prekrše.

Trebamo li svakoj procjeni dodati rezervu?

Skrivena rezerva za koju svi znaju obično se ionako potroši. Bolje je tražiti raspon, za stvari koje su stvarno važne planirati oko njegove gornje polovice i razloge za raspon držati vidljivima.

Naš tim uvijek kasni. Jesu li jednostavno spori?

Moguće, ali prvo provjerite druge uzroke: koliko se često mijenjaju prioriteti, na koliko projekata radi svaka osoba, koliko je prekida i koliko je kod star i zapetljan. Prema našem iskustvu, to objašnjava većinu kašnjenja.

Pomažu li tehnike procjene poput story pointsa?

Mogu pomoći timu da procjenjuje dosljedno i uoči vlastite obrasce. Ne pomažu kad se posao stalno mijenja ispod procjene. Prvo sredite tok posla, a tek onda tehniku.

Kako mi radimo

ProCoding je .NET studio iz Splita. Razvijamo i održavamo poslovne aplikacije, a velik dio dobrog rada je način na koji se posao planira: mali dijelovi koji se mogu pokazati svaki tjedan ili dva, procjene kao rasponi s imenovanim rizicima i izmjene koje idu u sljedeći krug umjesto da ometaju tekući. Na vašem projektu, s vašim timom ili kao freelance .NET developer unutar vašeg tima. Prvi korak je besplatan razgovor od 30 minuta.

Izvori

• The Cone of Uncertainty, Steve McConnell, Construx
• The Multi-Tasking Myth, Jeff Atwood, o okvirnom pravilu Geralda Weinberga za prebacivanje između projekata