boBYTE CONSULTING

Ce am descoperit pana acum?
Evident ca marea majoritate a implementarilor de proiecte software nu se poate face fara un management adecvat. Insa ce inseamna cu adevarat management de proiecte software?
Intr-un numar incredibil de mare a cazurilor intalnite de noi Managerul de Proiect Software era un soi de "one man show": el era atat coordonatorul proiectului cat si Technical Lead Developer, System Analyst, Database designer, Web designer si multe altele. Din pacate aceasta este realitatea din Romania pentru firmele mici care, desi propun solutii software atractive atat ca pret cat si ca facilitati oferite, neavand suficient personal angajat, mizeaza intreaga incarcare pe o singura persoana.

Din aceasta cauza, desi Managerul de Proiect este o persoana suficient de calificata in toate domeniile enumerate mai sus, acesta sfarseste, din cauza de supraincarcare, prin a nu mai reusi sa-si execute functia initiala, si anume de a aplica metodologii prin care sa garanteze livrarea produsului in parametrii stabiliti de timp si de buget.

Ceea ce este si mai grav este ca problema tinde sa se extinda si catre case de software dedicate, unde rolul de Technical Lead Developer, System Architect si Project Manager incep sa devina una si aceeasi functie in cadrul unui proiect.

Ce este de facut?

In primul rand sarcina Managerului Proiect este sa convinga stakeholderii proiectului ca el este implicat in proiect strict ca persoana delegata sa supravegheze, masoare, raporteze si sa ia orice masura necesara pastrarii proiectului pe linia de lucru necesara. Nu de putine ori Managerii Romani de Proiecte Software provin din randul celor care, candva, au dezvoltat aplicatii sub conducerea unui alt Manager, si uita ca munca lor trebuie sa se focuseze de la acest nivel pe partea manageriala si mai putin pe lucruri tehnice. Multi inca, fortati de imprejurari sau nu, se implica la nivel de codare, si , uneori, intra atat de tare in procesul de dezvoltare incat uita sa-si mai exercite atributiile de baza ale functiei lor. Dragi Manageri de Proiect aflati in situatia aceasta, invatati sa va detasati de partea tehnica, priviti-o ca pe un hobby si dedidaci numai timpul liber unor astfel de activitati daca doriti sa oferiti o sansa proiectului pe care il conduceti! Riscul de a nu termina proiectul asa cum trebuie creste semnificativ in aceasta situatie, si nu cred ca va doriti sa ajungeti in postura in care trebuie sa explicati stakeholderilor de ce proiectul a intarziat din cauza unor probleme si voi n uati reactionat la timp (scuze de genul "Am fost ocupat cu alte lucruri" nu prea functioneaza :)

In al doilea rand sarcina Managerului de Proiect este sa "ia pulsul" echipei pe care o conduce. O echipa care este suprasolicitata pierde automat motivarea si concentrarea necesara dezvoltarii produselor conform planningului initial. Totodata implicarea activa in randul echipei (in pauza de masa, tigare si orice alt motiv pentru a va "insera" in mijlocul echipei conduse) ar trebui, pe de o parte, sa va ofere suficiente informatii despre moralul echipei, si pe de alta parte sa va asigure rolul de leader pe care trebuie sa-l subliniati echipei.

In al treilea rand un bun Manager de Proiect trebuie sa-si asume greselile si mai ales sa invete din ele. Indiferent de modul in care decideti sa conduceti un proiect, experienta acumulata din proiectele anterioare ar trebui deja sa va formeze niste "smoke detectors" care sa va alerteze in mod subconstient de faptul ca un risc asumat sau nu e pe cale sa deraieze intregul plan de proiect. "A gresi este omeneste. A gresi de doua ori acelasi lucru este prosteste". Pastrati acest lucru in minte, si veti reusi sa evitati inca din faza incipienta problemele care pot ameninta buna executie a proiectului pe care il conduceti.

Nu in ultimul rand utilizati metodologii de management ale proiectului. Six Sigma, PMBook basics, metode proprii, orice este mai bun decat a conduce un proiect "dupa ureche". Invatati sa va definiti propriile seturi de valori dupa care judecati buna executie a proiectului (termenul de Indicator Cheie de Performanta nu ar trebui sa va fie necunoscut). Invatati sa evaluati posibilitatile fiecarui membru din echipa inainte sa-i asignati un task pentru a nu avea surpriza neplacute. Invatati ce inseamna a efectua un buget corect al proiectului pentru a nu ajunge in situatia de a cere surse suplimentare de finantare. Si mai ales invatati sa evaluati starea proiectului cat mai obiectiv posibil, astfel incat sa nu lasati subiectivismul sa dauneze rapoartelor finale.

Cum procedam noi?

Nu avem pretentia ca acest paragraf sa va serveasca ca guideline pentru activitatea pe care trebuie sa o desfasurati, cum nu avem pretentia ca metodologia noastra este perfecta. Insa ce este cel mai important este ca avem o metodologie testata deja si in continua evolutie, iar schimbarea care aduce ceva bun este intotdeauna un eveniment care va multumi atat clientul cat si colegii Dvs.

In primul rand metoda noastra se bazeaza partial pe conceptul Six Sigma: dezvoltam metodologii prin care reducem numarul esecurilor intalnite pe parcusul ciclului de dezvoltare. Intreg procesul de Management al Proiectelor Software conceput de compania noastra se bazeaza pe urmatoarele principii:

• Defineste clar problema/riscul din cadrul Proiectului
• Propune o solutie coerenta care sa elimine/aplatizeze efectele problemei
• Impune aplicarea solutiei conform planului
• Masoara rezultatele aplicarii solutiei
• Raporteaza rezultatul procesului de schimbare

In al doilea rand ne bazam pe definirea clara a scopului si a livrabilelor proiectului. Recomandam metodologia TDD (Test-Driven Development) pentru ca aceasta permite, pe de o parte, metode prin care se poate conduce dezvoltarea cat mai aproape de solutia pe care si-o doreste clientul, si pe de alta parte permite echipei de programatori sa se focuseze pe livrarea unui produs tangibil, si nu pe concepte abstracte care, de multe ori, pot genera neintelegerea cerintelor initiale cu rezultate catastrofale in produsul livrat. Schimbarile in cadrul proiectului sunt permise numai dupa o analiza amanuntita a efectelor pe care acestea le pot produce planului de dezvoltare, si numai dupa acceptarea din partea clientului a planului de schimbare.

In al treilea rand avem definiti indicatori care ne permit monitorizarea rapida a situatiei proiectului in orice moment. Beneficiarii proiectului prefera sa obtina o informatie clara (chiar si in cazul in care proiectul iese in afara planului) decat sa primeasca informatii incomplete, sau incorecte. Efortul echipei de proiect poate fi directionat mai usor spre zonele cu probleme, astfel incat "agile-development" este o stare de facto a tuturor echipelor conduse de noi.

Nu in ultimul rand parcurgem in modul cel mai serios toate etapele necesare livrarii proiectului: analizam si producem use case-uri pentru toate scenariile functionale, dezvoltam planul de proiect in deplina cunostinta de restrictiile impuse (resurse, buget, timp), monitorizam implementarea planului cu strictete si raportam situatia proiectului in mod obiectiv.