Autorul – Craig Larman – vorbește despre Scrum, XP, Unified Process și Evo, prezentând fiecare metodă în parte, arătând în același timp diferențele și asemănările dintre metode, punctele slabe, punctele forte și principalele greșeli făcute în adoptarea lor.

Un lucru enervant la prima vedere sunt multiplele repetări ce apar pe parcursul unui capitol, dar la finalul cărții am ajuns să-mi dau seama că tocmai acele repetări au făcut să mi se întipărească bine în minte tot ce am citit.

Foarte proastă alegere. De ce? Pentru că în majoritatea cazurilor, am pierdut o parte din weekend (sau chiar tot weekend-ul) lucrând. La fel de prost aleasă e şi ziua de vineri pentru că dacă nu termin la timp, voi lucra în weekend pentru a fi totul gata până luni dimineaţa.

Şi totuşi, chiar dacă pare foarte evident, nu mi-am dat seama de lucrul ăsta până nu am citit cartea de care vorbeam într-un articol anterior.

Ok, revenind… ce am zis mai sus nu e valabil doar la deadline-uri ci la orice obiectiv intermediar din ciclul unui proiect. Ca project manager, dacă setezi un obiectiv pentru luni sau vineri, oferi timp echipei să repare/finalizeze lucrurile în weekend. Problema cu astfel de abordări, pe lângă oboseală, e faptul că pierzi oarecum controlul şi nu poţi să ştii cât anume s-a muncit în timpul săptămânii şi cât în weekend. Iar din acest motiv, e posibil să faci estimări greşite în viitor, formând un cerc vicios care poate întârzia mult un proiect.

Bun, şi dacă nu e clară concluzia, data viitoare când negociezi/planifici un deadline/obiectiv, încearcă să-l stabileşti la mijlocul săptămânii. Sigur, acest lucru nu garantează succesul, dar va reduce drastic munca din timpul weekend-ului, astfel că se poate determina progresul proiectului într-un mod mult mai realist.

De cele mai multe ori, oamenii (dintr-o echipă) se gândesc la cât de multe pot să facă, planificând astfel întregul proiect cu gândul la cât de mult pot să lucreze. Un lucru nu tocmai bun, deoarece ar trebui să se gândească la cât de puţin lucrează de fapt.

Din lungul şir de greşeli, probabil greşeala asta am făcut-o de cele mai multe ori, efectul fiind în cel mai „bun” caz multe nopţi nedormite, iar în cel mai rău caz vă imaginaţi voi…

Cred că e un lucru evident faptul că dintr-un program de 8 ore pe zi, nu se lucrează 8 ore. Ai pauză de masă, ai pauză de cafea/ţigară, mai ai o sedinţă, un telefon, etc. Ajungi să lucrezi doar 4-5 ore pe zi. Dacă mai citeşti un email, o ştire, nişte RSS-uri, forumuri, bancuri trimise de colegi, situaţia e clară iar productivitate tinde spre zero. Dar despre asta o să vorbesc într-un articol viitor.

Şi totuşi, e greu să treci peste modul de gândire „cât de mult”. Ştii că nu lucrezi 8 ore pe zi, dar îţi planifici proiectele ca şi cum ai lucra 8 ore non-stop. Multiplică asta cu numărul de oameni din echipă ca să vezi dimensiunea dezastrului ce te aşteaptă.

I love deadlines. I like the whooshing sound they make as they fly by. (Douglas Adams)

Deşi am câţiva ani de experienţă în spate (a se citi câţiva ani de greşeli) uneori mai fac greşeala asta şi nu-mi vine să cred. Analizând situaţia în timp, am identificat 3 motive:

1. La început mă supra-estimam. În naivitatea mea, chiar credeam că pot lucra 8 ore pe zi non-stop, la productivitate maximă. Oricât de genial(ă) eşti, lucrul ăsta e imposibil de atins.
2. După un timp am ajuns la concluzia evidentă că ziua de lucru nu are 8 ore, dar parcă nu eram conştient de acest fapt. Asta e un fel de „nu vezi pădurea din cauza copacilor”. Recunoaşterea şi conştientizarea e primul pas spre „vindecare”.
3. Am un client nou, vreau să-l impresionez şi-i promit „luna de pe cer”.

Toate astea duc la o muncă enormă peste program care pe o perioadă îndelungată nu e tocmai sănătoasă. Iar dacă îţi faci un raport între banii ceruţi pe proiect şi munca depusă îţi dai seama că sclavii o duceau mai bine.

Ţine seama de toate astea când planifici următorul proiect, când promiţi rezolvarea unui task şi în special când semnezi un contract!

Many software people are optimistic. They are trained to be optimistic in school, where every project can be completed in one semester (with a sufficient number of all-nighters) [citat din Manage It!].

Oh da, am simţit asta pe propria piele şi abia acum încep să mă trezesc la realitate. Cam târziu aş putea spune, deoarece am terminat facultatea în 2005.

Din 2003, de când am firma, am făcut toate greşelile posibile şi imposibile în ceea ce priveşte managementul proiectelor, fie ele software sau nu. Cu toate astea, cele mai multe proiecte s-au încheiat bine şi la timp. De ce? Pentru că nu erau de dimensiuni foarte mari şi au existat destule nopţi nedormite (vezi mai sus).

Greşeala cea mai mare pe care o poate face un tânăr antreprenor e să trateze superficial, sau, mai rău, să creadă că ştie să facă project managenent. Cea mai gravă consecinţă nu e întârzierea proiectelor ci faptul că nu poţi să te dezvolţi. Efectiv nu poţi să-ţi scalezi afacerea şi vei fi copleşit de probleme când încerci s-o faci.

Eu am făcut şi greşeala asta care, dacă mă uit în urmă, îmi dau seama că m-a costat foarte mult. Uneori e destul de greu să conştientizezi lucrurile astea, chiar dacă par evidente.

Am scris aceste rânduri tocmai pentru a conştientiza şi mai tare acest fapt, pentru a-mi exprima propria frustrare faţă de modul în care mi-am gestionat proiectele până de curând şi pentru a-mi promite că mă voi schimba.

Nu în ultimul rând, am scris aceste rânduri pentru cei aflaţi la început cu propria afacere. Investiţi timp şi bani (cărţi) pentru a învăţa despre managementul proiectele software. În timp, recompensa va fi enormă!

Deşi e prima carte de project management pe care o citesc (deci nu am un termen de comparaţie) eu vă recomand Manage It!. Am cumpărat-o de pe Amazon şi mi-a fost livrată aprox. într-o lună de la data comenzii. Probabil următoarea achiziţie va fi Agile and Iterative Development: A Manager’s Guide. Dacă aveţi alte recomandări, vă rog să lăsaţi un comentariu.

Ps: o să urmeze şi alte articole din categoria „Project Management”, articole în care o să-mi scriu părerea despre cele citite şi învăţate din cărţi, şi – cel mai important – din experienţă.