by Va povesteam in articolul “dinamica echipelor” ca trebuie sa detectam fazele prin care trece o echipa in cadrul unui proiect: forming, norming, storming si performing, dar si sentimentele pe care le incearca membrii unei echipe pe parcursul acestor faze pentru a gestiona cat mai bine un proiect si echipa.
Spuneam atunci ca unii sunt entuziasti la inceput, altii sceptici. Sa ne ocupam astazi de cei entuziasti, pentru ca de obicei ne ocupam cel mai mult de cei sceptici, ignorind riscurile ce pot aparea de la cei entuziasti.
Multi vor zice ca este foarte bine sa ai o echipa entuziasta…Eu as zice, da, dar cu moderatie… 🙂
Sa incepem cu faza de planificare in care estimam proiectul ce urmeaza a fi dezvoltat. Cei mai multi experti tehnici pe care i-am intalnit si care concep marea parte din oferta sint genul optimist. Iata doar cateva initiative proprii:
1. estimeaza ca si cum ar lucra o persoana cu experienta in proiect, adica ei, sau cel mult colegii pe care ii stiu;
2. fac asumtii pe care nu le enunta in cadrul estimarii (“pai era clar ca trebuie sa avem sistemele instalate, nu am mai estimat si asta…!”); asumtiile pe care le fac, ascund si niste riscuri pe care nu le vad si sint ignorate mai apoi;
3. estimeaza taskurile de dezvoltare si activitatile de “code review”, “merging”, “unit testing” sunt uitate, sau strecurate discret in estimarile pentru dezvoltare;
Rolul PM-ului este foarte important in acest moment de initiere al proiectului. Ce am invat eu de-a lungul timpului este ca in aceasta etapa trebuie sa punem cat mai multe intrebari expertului, multe “de ce” si “cum”…
Desi expertul poate fi “deranjat” de atitea intrebari, mai ales daca nu ii contestase nimeni pina la acel moment estimarile, cu tact si diplomatie aceste intrebari trebuie insa puse.
O alta practica pe care am abordat-o de 2 ani, a fost sa initiez un workshop intern (dureaza maxim 2 ore) cu expertii din echipele mele, in care le-am explicat ce impact au niste estimari abordate cu entuziasm si cat de necesar este sa acoperim toate activitatile, chiar si cele minore. In acelasi timp, am pus niste regului de urmarit in cadrul procesului de estimare, de genul:
– Estimarea se face pentru un dezvoltator standard;
– Am construit o sectiune specifica in documentul de oferta cu asumtii si riscuri in care expertul trebuie sa contribuie cu cit mai multe sugestii;
Entuziasmul poate continua si in timpul dezvoltarii. Daca un optimist primeste un task de 5 MDs (de exemplu), este convins ca il poate face in 3 MDs (mandays) si atunci in primele 2 zile face orice alte activitati nelegate de proiect. Din nou, PM-ul trebuie sa aiba pirghii prin care poate controla aceste lucruri.
Totusi sa nu neglijam si partea buna a entuziasmului unei echipe: cu oameni entuziasti poti termina proiectele in timeline-uri care sint nerealiste, sau sa descoperim solutii pentru cele mai dificile cerinte ale clientului.
