Planificarea simpla a proiectelor software

De Joel Spolsky
Tradus de catre Adrian Spinei
Verificat de catre Petru Paler
Martie 29, 2000

In octombrie trecut, nord-vestul Statelor Unite a fost impanzit cu reclame la un produs numit
Acela, un nou tren expres pe ruta Boston - Washington. Cu reclame la TV si afise cam peste
tot, ai crede ca s-a creat macar un pic de cerere pentru noul serviciu Amtrak.
E posibil. Amtrak nu a reusit sa afle. Acela a fost amanat, apoi din nou amant, asadar
campania de marketing a fost vizibila in vreme ce serviciul Acela nu era inca disponibil. Ceea
ce-mi aminteste de cugetarea unui responsabil de marketing cand unul din produsele sale a
primit o cronica extrem de favorabila cu o luna inainte de a fi pus in vanzare : "Publicitatea
este excelenta ! Ce pacat ca nu poti cumpara blestematia!"
Companii de jocuri cu ego-urile umflate au o mare placere din a se lauda pe site-urile lor ca
urmatorul joc va fi comercializat "atunci cand e gata". Calendar? N-avem nevoie de prostia de
calendar! Noi suntem programatori de jocuri beton! Majoritatea companiilor nu au parte de
acest lux. Intrebati-i pe cei de la Lotus. Atunci cand au comercializat versiunea 3.0 de la
produsul lor 123, acesta necesita un procesor 80286, care inca nu era prea raspandit. Ei au
amanat produsul inca 16 luni in vreme ce l-au limitat din greu ca sa poata lucra in 640k de
memorie, care era limita la un 8086. Atunci cand au terminat, Microsoft avea deja 16 luni de
avans in dezvoltarea Excel-ului, si, ca o uriasa gluma a destinului, procesorul 8086 era deja
invechit!
In vreme ce scriu aceste randuri, Netscape's 5.0 este intarziat cu aproape doi ani. Partial,
aceasta se datoreaza faptului ca au facut greseala sinucigasa de a arunca tot codul si de a
reporni de la zero: aceeasi greseala care a trimis Ashton-Tate, Lotus, si Apple's MacOS in
pubelele istoriei software. Netscape si-au putut vedea partea de piata la browsere variind de la
aproape 80% la cam 20% in tot acest timp, neputand face nimic ca compenseze competitia,
din cauza ca produsul lor software cel mai important era desfacut in 1000 bucati pe podea si
nu putea fi folosit la nimic. Aceasta decizie, mai mult decat orice altceva, a fost bomba
nucleara pe care Netscape si-a detonat-o in interiorul firmei. (renumita scrisoare deschisa a lui
Jamie Zawinski contine toate detaliile).
Asadar, aveti nevoie de un calendar. Aceasta este o sarcina de care aproape nici un
programator nu vrea sa auda. In experienta mea, vasta majoritate a programatorilor incearca
sa scape fara sa faca nici un fel de calendar. Dintre putinii care il fac, majoritatea au fost
obligati de superiori sa il faca, il fac fara interes si nimeni nu crede in calendarul fixat cu
exceptia managementului, care simultan crede si ca "nici un proiect software nu se poate
termina la timp" si in existenta OZN-urilor.
Si-atunci de ce nimeni nu face un calendar ? Din doua motive esentiale. Unu, treaba este
extrem de complicata. Doi, nimeni nu crede ca ar fi util la ceva. De ce sa mai scrii un calendar
atunci cand stii precis ca nu va fi corect ? Exista o perceptie cum ca aceste calendare sunt
gresite in mod sistematic si doar se inrautatesc pe masura ce trece timpul, si-atunci de ce sa
mai suferi ?

Citit mai jos o modalitate simpla de a face calendare corecte.

1) Folositi Microsoft Excel. Nu va complicati cu softuri pretentioase gen Microsoft Project.
Problema cu Microsoft Project este ca porneste de la ipoteza ca doriti sa petreceti o groaza de
timp gandindu-va la dependente. O dependenta apare atunci cand aveti doua taskuri, din care
unul TREBUIE sa fie completat inainte ca al doilea sa poata incepe. De fapt, experienta spune
ca in software dependentele sunt atat de evidente incat nu merita efortul de a le formaliza
explicit.
O alta problema cu Project este ca se presupune ca vei fi capabil sa apesi pe un mic buton si
gata, ai "rebalansat" proiectul. Inevitabil, aceasta inseamna ca se vor rearanja si realoca
diverse sarcini la persoanele din echipa. Intr-un proiect software, treaba aceasta este cam
lipsita de sens. Programatorii nu se pot schimba asa de usor intre ei. Ii va lua de sapte ori mai
mult timp lui John sa corecteze bug-urile Ritei decat Ritei sa corecteze bug-urile Ritei ! Iar
daca incerci sa aloci programatorul de interfete utilizator pe o problema de WinSock, el o sa
inghete productivitatea pentru o saptamana, invatand sa programeze WinSock. Concluzia :
Project este perfect pentru planificarea constructiei de cladiri, nu pentru software.
2) Pastrati un format simplu. Formatul standard pe care il utilizez pentru calendare este atat
de simplu incat il puteti memora chiar acum, pe loc. Porniti doar cu sapte coloane:

Daca aveti mai multi dezvoltatori in echipa, fie pastrati o fila separata pentru fiecare dintre ei,
sau puteti face o coloana cu numele dezvoltatorului alocat pe fiecare task.
3) Fiecare functionalitate este compusa din mai multe task-uri. Un bun exemplu de
functionalitate este adaugarea unui corector gramatical la programul dumneavoastra.
Adaugarea unui corector gramatical consista in cateva task-uri mici, separate pe care
programatorul trebuie sa le execute. Practic, cea mai importanta parte a creatiei unui calendar
este alcatuirea acestei liste de taskuri. De unde si regula de baza:
4) Numai programatorul care scrie codul poate sa estimeze durata. Orice alt sistem in
care managementul a scris un calendar si l-a inmanat programatorilor este sortit esecului.
Numai programatorul care va face munca efectiva isi poate da seama care sunt pasii necesari
pentru a implementa functionalitatea. Si numai acesta poate estima cat dureaza fiecare din
acesti pasi.
5) Utilizati task-uri marunte. Aceasta este o regula de baza pentru a face calendarul ca sa
functioneze efectiv. Taskurile trebuie sa fie masurate in ore, nu zile. (Cand vad un calendar
care se masoare in zile, sau chiar saptamani, stiu imediat ca e fantezist). Poate credeti ca un
2

calendar cu task-uri marunte e doar ceva mai precis. Gresit! Foarte gresit! Cand porniti cu un
calendar cu task-uri largi si apoi le spargeti in task-uri mai marunte veti ca peste un rezultat
diferit, nu doar unul mai precis. Este un numar complet diferit. De ce se intampla acest
lucru ?
Atunci cand alegeti task-uri marunte, va fortati sa intelegeti realmente care sunt pasii necesari.
Scrierea procedurii foo. Crearea unui dialog. Citirea fisierului wav. Acesti pasi sunt usori de
estimat, pentru ca ati mai scris proceduri, creat dialoguri si citit fisiere wav si inainte.
Daca sunteti neglijenti si alegeti task-uri "grase" (de tip "implementarea corecturii
gramaticale") atunci nu prea v-ati gandit la ceea ce vreti sa faceti. Iar daca nu v-ati gandit la
ceea ce vreti sa faceti, atunci nu aveti cum sa stiti cat timp va va lua.
Ca o regula de baza, fiecare task trebuie sa ia intre 2 si 16 ore. Daca aveti un task de 40 de ore
(o saptamana) pe calendar, inseamna ca nu l-ati "despicat" suficient.
Iata si alt motiv pentru a alege task-uri marunte, va forteaza sa analizati functionalitatea cu
pricina. Daca aveti o functionalitare zglobiu numita "Integrare cu Internet" si pentru care
estimati cu larghete 3 saptamani, aveti o mare problema. Dar daca trebuie sa precizati ce
metode aveti de gand sa scrieti, atunci veti fi fortat sa despicati functionalitatea. Fiind fortat
sa planificati in avans la acest nivel, se va elimina o mare parte din instabilitatea proiectului
software.

6) Tineti evidenta estimarii originale si curente. Atunci cand adaugati o noua

functionalitate la calendar, estimati cat de mult va lua completarea ei si umpleti valorile
coloanelor Orig[inal] Est[imat] si Est[imare] Cu[renta]. Pe masura ce proiectul avanseaza,
daca va ia mai mult (sau mai putin) decat ati preconizat, puteti modifica valoarea din coloana
estimarii curente. Acesta este cel mai bun mod de a invata din greseli si de a invata pe viitor
cum sa faceti o estimare cat mai buna a taskurilor. Majoritatea programatorilor nu au nici cea
mai mica idee despre cate de mult va lua un task. Este in regula. Atata vreme cat calendarul
permite invatarea continua si modificarea continua, calendarul va fi util. (Va fi poate nevoie sa
anulati anumite functionalitati sau sa amanati proiectul, dar calendarul va fi mereu corect in
sensul in care va va arata o situatie realista a proiectului). Am observat ca majoritatea
programatorilor invata sa estimezee taskuri foarte bine dupa aproximativ un an de experienta.
Dupa ce taskul este terminat, coloanele Estimare Curenta si Trecut vor fi identice, iar campul
Ramase va ajunge la 0.
7) Actualizati coloanele in fiecare zi. Pentru a face aceasta, nu e nevoie sa va folositi
cronometrul in timp ce munciti. Chiar inainte de a pleca acasa, sau inainte de a adormi sub
birou daca sunteti unul dintre acei maniaci, pretindeti ca ati lucrat vreme de 8 ore (ha!),
ganditi-va la ce taskuri ati lucrat, si impartiti 8 ore in cele cateva coloane in concordanta cu
bilantul pe care l-ati facut. Campurile ramase sunt calculate automat de catre Excel.
In acelasti timp, modificati coloana de Estimare Curenta pentru diverse taskuri pentru a
reflecta realitatea. Actualizarea zilnica a calendarului nu ar trebui sa va ia mai mult de doua
minute. De aceea am numit metoda "Planificare simpla" -- pentru ca este rapid si usor.

8) Planificati concedii, vacante, etc. Daca planificarea proiectului se intinde pe cam un an,
fiecare programator va avea macar 10-15 zile de concediu. Va trebui sa aveti un task in
calendar pentru concedii, unul pentru sarbatori, si pentru orice alta activitate susceptibila sa
consume timpul echipei. Ideea este ca data de livrare poate fi calculata facand suma
coloanelor cu timpul ramas si divizand cu 40 -- rezultatul reprezinta numarul de saptamani de
lucru ramase, cu totul inclus.
9) Puneti timpul de debug in calendar! Debugging-ul este cel mai dificil de estimat.
Ganditi-va ;a ultimul proiect la care ati lucrat. Sansele sunt ca debugging-ul a luat cam 100% 200% din timpul care a fost necesar pentru scrierea aceluiasi volum de cod. De aceea trebuie
sa prevedeti aceasta activitate in calendar, si probabil va fi una dintre cele mai mari.
Iata cum merge treaba. Sa presupunem ca un dezvoltator lucreaza la task-ul wava. Estimarea
originala a fost de numai 16 ore, dar deja 20 de ore au trecut si se pare ca va fi nevoie de inca
10 ore de lucru. Asa ca dezvoltatorul scrie 30 in dreptul Estimarii Curente si 20 la Trecute.
La sfarsitul etapei, toate aceste "alunecari" au inceput probabil sa se cam adune. Teoretic,
pentru a aduce la zi planificarea trebuie anulate cateva functionalitati. Din fericire prima
functionalitate pe care o putem taia contine acel mare task numit Buffer care are deja o
sumedenie de ore alocate.
In principiu, dezvoltatorii corecteaza codul pe masura ce il scriu. Un programator nu trebuie
niciodata sa lucreze la cod nou daca ar putea in acest timp sa corecteze erori. Numarul de
buguri trebuie sa ramana cat mai mic in proiect la un moment dat, pentru doua motive:
1) Este mai usor sa corectezi buguri in aceeasi zi in care ai scris codul. Poate fi foarte dificil si
consumator de timp sa fixezi buguri o luna mai tarziu cand ai cam uitat cum functioneaza
codul.
2) Corectarea bugurilor seamana un pic cu cercetarea stiintifica. Este imposibil de estimat
cand veti rezolva un bug. Daca la un moment dat exista o lista cu doar unul sau doua buguri
important, este usot de estimat cand va fi livrat produsul, pentru ca factorul greu de estimat
are o pondere mica in volumul total de munca ramasa de efectuat. Pe de alta parte, daca sunt
sute sau mii de bug-uri importante ramase, este imposibil de prezis cand vor fi rezolvate.
Daca dezvoltatorii corecteaza bug-urile pe masura ce avanseaza, care ar mai fi rostul unui task
de debugging ? Evident, chiar daca incerci din greu sa rezolvi toate bug-urile pe masura ce
inaintezi, la sfarsitul fiecarei etape apare inevitabil o suma de probleme care se ivesc doar
dupa ce bug-testerii (in intern sau beta) gasesc bug-urile intr-adevar dificile.
10) Puneti timpul de integrare in calendar. Daca in echipa este mai mult de un programator,
vor exista puncte in care se dezvolta lucruri inconsistente care trebuie aduse la un numitor
comun. Mai multi programatori pot implementa cutii de dialog multiple pentru aceleasi
functionalitati. Cineva care va lua "la periat" toate meniurile, acceleratoarele de tastatura, etc.
va gasi in mod sigur lucruri de curatat si de organizat, puncte de redundanta si de incoerenta.
De indata ce doua persoane lucreaza in comun pe aceeasi bucata de cod, vor apare erori de
compilare si de logica -- ele vor trebui corectate, iar timpul necesar va fi un task pe calendar.
11) Calculeaza un buffer ("tampon") in orar. Lucrurile au tendinta sa debordeze fata de
previziunile initiale. Sunt doua tipuri importante de buffer la care veti vrea sa va ganditi.

Primul: trebuie acoperite taskurile ce dureaza mai mult decat estimarea. Al doilea: luati in
calcul existenta unor task-uri la care nu v-ati gandit ca vor apare, cum ar fi de exemplu ca
managementul a decis ca implementarea functionalitatii wawa este SUPER IMPORTANTA si
trebuie obligatoriu sa faca parte din urmatorul release.
Vei fi surprins sa afli ca toate concediile, sarbatorile, debugging, integrare, buffer-ul s-ar putea
sa se adune la un volum de timp mai mare decat task-urile efective. Daca esti atat de surprins
inseamna ca nu programezi de foarte mult timp, nu-i asa ? Ignora aceste lucruri pe riscul tau.
12) Niciodata nu lasa managerii sa dicteze programatorilor sa reduca o estimare. Multi
manageri novici cred ca pot "motiva" programatorii sa lucreze mai repede dandu-le calendare
dragute, "stranse" (nerealist de scurte). Cred ca acest gen de motivatie este absolut stupida.
Atunci cand sunt in intarziere, ma simt deprimat si total nemotivat. Atunci cand sunt in avans
fata de orar, sunt agreabil si productiv. Calendarul nu este locul in care sa se efectueze jocuri
psihologice.
Daca managerul forteaza reducerea estimarilor, iata ce trebuie sa faci. Creeaza-ti o coloana
noua in calendar care se numeste Estimarea lui Radu (presupunand evident ca numele tau
este Radu). Scrie estimarea ta acolo. Lasa managerul sa faca orice-o vrea cu coloana
Estimare curenta. Ignora estimarile managerlui si atunci cand proiectul se termina, compara
cine e mai aproape de realitate. Am observat ca numai amenintand sa fac asa ceva face
minuni, in special cand managerul isi da seama ca tocmai s-a angrenat intr-un concurs cu miza
de a arata cat de incet poti lucra!
De ce managerii incompetenti incearca sa convinga dezvoltatorii sa reduca estimarile?
La inceputul proiectului, managerii tehnici se intalnesc cu cei care conduc afacerea si apar cu
o lista de functionalitari care ei cred ca va dura 3 luni, dar in realitate va lua cam 9. Cand te
gandesti la scrierea de cod fara a lua in considerare toti pasii care trebuie efectuati, totdeauna
pare ca va lua n timp, cand in realitate va lua aproximativ 3n timp. Cand faci un calendar real
si aduni toate task-urile, vei realiza faptul ca proiectul o sa ia mult mai mult timp decat s-a
prevazut initial. Este evident.
Managerii incompetenti incearca sa rezolve acest lucru gandindu-se cum sa convinga oamenii
sa lucreze mai repede. Acest lucru nu este foarte realist. Poti fi capabil sa angajezi mai multi
oameni, dar ei vor trebui sa ajunga la regimul de croaziera si probabil vor lucra la sub 50%
din eficienta vreme de cateva luni (afectand si productivitatea celor ce vor trebui sa-i asiste).
Mai mult, la piata de munca actuala incercarea de a adauga cativa programatori buni va lua
cel putin 6 luni.
Poti fi eventual capabil sa obtii 10% mai mult cod de la dezvoltatori dar la costul de a-i "arde"
100% intr-un an. Castigul este mic, iar strategia seamana cu a-ti manca propriile seminte in
loc de ale semana.
Poti sa fii capabil sa scoti 20% mai mult cod tragand de oameni sa lucreze din greu, fara sa tii
seama de cat de obositi sunt. Boom, timpul de debugging se dubleaza. O miscare absolut
gresita care se rezbuna intr-un mod aproape karmic.
Dar niciodaca nu poti sa obtii 3n volum de munca in n timp, iar daca tu crezi ca poti, te rog
spune-mi la ce companie lucrezi ca sa fiu sigur ca n-o sa iau vreodata actiuni acolo.

13) Un calendar e ca o colectie de cuburi de lemn. Daca ai o gramada de cuburi de lemn

care nu intra intr-o cutie, ai doua alternative : iei o cutie mai mare sau lasi afara cateva cuburi.
Daca livrarea este in 6 luni si pe calendar sunt 12 luni, ori livrarea trebuie intarziata ori niste
functionalitati trebuie eliminate. Pur si simplu blocurile nu se pot micsora, iar daca sustii ca se
poate, te lipsesti de cea mai elementara oportunitate de a putea prevedea viitorul mintindu-te
pe tine insisi despre acest viitor.
Un alt efect interesant al calendarelor este ca te forteaza sa tai functionalitati. De ce acest
lucru este pozitiv ? Hai sa presupunem ca avem doua functionalitati : una care este efectiv
utila care va face produsul absolut exceptional (exemplu: tabelele in Netscape 2.0) si o alta
care este relativ usoara si pe care programatorii ar adora s-o implementeze (de exemplu : tagul
BLINK), dar care nu serveste unui scop util sau de marketing.
Daca nu faceti un calendar, programatorii vor incepe cu functionalitatea usoara/amuzanta. Ei
vor intarzia, si singura alegere va fi ori sa intarzie livrarea ori sa anuleze functionalitatea
utila/importanta.
Daca faci un calendat, chiar inainte de a incepe treaba vei realiza daca trebuie sa tai ceva, asa
ca vei taia functionalitatea usoara/amuzanta si va ramane de dezvoltat doar cea
utila/importanta. Fortandu-te sa tai functionalitati, vei sfarsi prin a face un produs mai
puternic, mai bun, cu un amestec mai judicios de functionalitati si care are sanse sa fie livrat
la timp.
Imi amintesc cand am lucrat la Excel 5. Lista initiala de functionalitati era enorma si ar fi
depasit cu mult calendarul. Groaznic, ne-am gandit. Toate aceste functionalitati sunt superimportante. Cum vom putea trai fara un wizard de editare de macro-uri ?
Dupa cum s-a dovedit ulterior, nu am avut de ales, asa ca am taiat pana ce am ajuns la "piele
si os" ca sa facem fata livrarii. Toti au fost nemultumiti de taieturi. Ca sa ne calmam
resentimentele, ne-am spus ca nu taiem functionalitati ci doar le amanam pentru Excel 6, din
moment ce ele sunt mai putin importante.
Pe masura ce Excel 5 se apropia de completare, am inceput sa lucrez la Excel 6 cu un coleg.
Eric Michelman. Am parcurs impreuna lista functionalitatilor de "Excel 6" care fusesera
taiate. Am fost absolut socati sa vedem ca eram in fata celei mai incoerente liste de
functionalitati imaginabila. Nici una dintre ele nu merita implementata. Nu cred ca nici una a
fost implementata in urmatoarele 3 versiuni. Procesul de subtiere a functionalitatilor pentru a
acomoda livrare a fost cel mai bun lucru posibil. Daca nu am fi facut asta, Excel 5 ar fi luat
cam de 2 ori mai lung si ar fi inclus 50% functionalitati inutile. (Nu am nici un dubiu ca exact
acest lucru s-a intamplat cu Netscape5/Mozilla: nu a existat calendar, nu a existat o lista
definitiva de functionalitati, nimeni nu a vrut sa taie nimic, si nu s-a putut livra. Cand se va
livra, vor avea o sumedenie de briz-brizuri cum ar fi clienti de IRC cu care nici n-ar fi trebuit
sa piarda vremea.)
Appendix: Lucruri pe care e bine sa le stii despre Excel
Unul dintre motivele pentru care Excel este un produs excelent pentru calendare este ca
programatorii care lucreaza la el il folosesc pentru mentinerea propriilor calendare ! (Nu multi
dintre ei ruleaza scenarii de afaceri alambicate ... sunt totusi programatori !)

Shared Lists Folosind comanda File/Shared Lists permite tuturor sa deschida fisierul in
acelasi timp si sa modifice simultan. Din moment ce intreaga echipa va actualiza constant
calendarul, este extrem de util.
Auto Filter Aceasta este o modalitate excelenta de a filtra calendarul in asa fel incat, de
exemplu, poti vedea numai functionalitatile care iti sunt alocate. Combinat cu Auto Sort, poti
vedea toate taskurile in ordinea prioritaitii, ceea ce constituie efectiv un "TODO list"
actualizat automat. Cooooool!
Pivot Tables Aceasta este o modalitate excelenta de a vedea sumare si tabele incrucisate, De
exemplu, se poate face un grafic care arata orele ramase pentru fiecare dezvoltator, pentru
fiecare prioritate. Tabelele pivot sunt ca painea feliata si milkshake-urile cu ciocolata. Trebuie
sa inveti sa le folosesti pentru ca vor transforma Excel-ul intr-o unealta de un milion de ori
mai puternica.
Functia WORKDAY din Excel Analysis Toolpak este o excelenta metoda de a obtine date
precise dintr-un calendar.

Acest articol a aparut initial in engleza cu numele Painless Software Schedules