Asumare, justificare, rezolvare

Dezvoltarea unui proiect (in IT si nu numai) are la baza o estimare de timp. In functie de domeniu, aceasta estimare se da in ore, zile sau saptamani. In IT, unitatea de masura pentru asa ceva e ora.

Estimarea va cuprinde de regula si o anumita marja de eroare. Un factor de risc, o asigurare in plus ca procesul de dezvoltare se va incadra in numarul de ore estimat. Acest factor de risc e calculat in functie de complexitatea proiectului, gradul sau de dificultate, nivelele de pregatire a oamenilor implicati, numarul oamenilor implicati, etc.

Oricum, ideea e ca se ajunge la un numar de ore. Pe baza acestuia se elaboreaza un calendar de dezvoltare, cu date exacte de livrare pentru fiecare stagiu de dezvoltare si – implicit – pentru intregul proiect.

Marja de eroare despre care vorbeam mai sus se reflecta si in acest calendar. Un exemplu foarte simplu ar fi urmatorul.

Sa presupunem ca ai un task estimat la 32 de ore. Adica – 4 zile de lucru.
Daca – in calendar – data inceperii taskului este luni dimineata, atunci (conform estimarii) data finalizarii lui va fi joi seara.
Dar – avand in vedere dificultatea si complexitatea taskului (apreciate in functie de alti parametri) marja de eroare rezultata va fi (sa zicem) de 8 ore.
In calendar, asta inseamna o zi de lucru. Deci marja de eroare reflectata in calendarul taskului respectiv va muta data finalizarii lui de joi pe vineri (seara).

Respectarea calendarului dat pana in cel mai mic detaliu reprezinta situatia ideala. Si posibila, de altfel – atunci cand nu exista interferente menite sa ingreuneze sau sa stopeze temporar procesul de dezvoltare.
Sigur, unele dintre aceste interferente (in cazul in care apar) vor fi acoperite de marja de eroare – dar daca ele persista (ca numar si ca durata), atunci data finala de livrare va fi in pericol (cu tot cu marja de eroare pre-calculata).

Aceste interferente pot fi de orice natura :

  • Un membru al echipei care trebuie inlocuit, din diverse motive (personale sau profesionale).
  • Un element neprevazut in estimare, care apare in procesul de dezvoltare. Acest element n-a fost acoperit de estimarea data initial, dar trebuie realizat pentru a asigura bunul mers al dezvoltarii, de acum inainte.
  • Estimarea e – pur si simplu – incorecta. Aici, motivele pot fi multe. Cele mai frecvente tin de regula de faptul ca persoana care a estimat nu e aceeasi cu cea care se ocupa de dezvoltare, deci exista o diferenta de experienta si aptitudini, care va ramane ne-acoperita. Cand aceasta diferenta e prea mare, problema devine mai grava.
  • Inceperea taskului era conditionata de prezenta unor materiale (design, diverse module necesare, etc). In momentul in care – conform calendarului – taskul planificat ar fi trebuit inceput, aceste materiale nu erau (inca) finalizate. Data de incepere a taskului va fi amanata si – prin urmare – data finalizarii acestuia va fi de asemenea amanata.
  • etc.

Vorbim asadar de intarzieri cauzate de aceste interferente. Intarzieri care – inevitabil – vor duce la diverse probleme. Cele mai multe direct cu clientul, care-ti va reprosa nerespectarea calendarului (de multe ori, fara sa ia in considerare ca o mare parte din intarzierile respective au fost cauzate chiar de el – in diverse feluri).

Oricum – daca esti responsabil de proiect – situatia ta va fi putin delicata.Pentru ca era una dintre sarcinile tale sa faci tot ce-ti statea in puteri pentru a preveni problema respectiva.

In primul rand, va trebui sa justifici situatia in care s-a ajuns, de ce s-a ajuns aici si – pe buna dreptate – de ce n-ai impiedicat-o sa ajunga aici. In fata clientului si in fata celor care se afla deasupra ta in lantul ierarhic – daca ti se cere acest lucru. Atentie – a justifica nu inseamna a cauta un vinovat, un tap ispasitor. Ci doar a explica – folosind argumente clare si fapte exacte (sustinute de dovezi). Conteaza prea putin cine e vinovatul, cata vreme problema exista si trebuie oricum rezolvata. Asadar – explica situatia. De preferinta, cat mai simplu si usor de inteles pentru toata lumea.

In al doilea rand, va trebui sa oferi o solutie functionala pentru depasirea problemei. Asta e de multe ori una de compromis, dar trebuie sa fie valida si acceptata de catre client (care – pe drept sau pe nedrept – se va considera de cele mai multe ori “parte vatamata” in toata povestea). Solutia se va da in functie de tipul si complexitatea proiectului, dar si de starea lui actuala.

De exemplu, daca proiectul are un set de functionalitati terminate si unele neterminate, atunci se vor analiza cele terminate. Se va decide cate dintre ele au sens fara cele care sunt inca neterminate, se vor izola si lansa acestea. Cele neterminate vor fi de indata anuntate ca facand parte din urmatorul update (si se va incepe lucrul la ele).

Sau – daca proiectul inca are buguri (sesiunea finala de testing/bugfixing inca nu s-a incheiat), atunci se vor izola partile care nu au buguri (sau au foarte putine – caz in care acestea se vor prioritiza) folosind aceeasi logica din exemplul anterior. Apoi se vor lansa aceste parti si se vor concentra toate resursele pe rezolvarea de urgenta a bugurilor ramase, in ordinea prioritatilor recent stabilite.

Sigur, nu se intampla minuni peste noapte. Vor fi – din pacate – si proiecte care nu vor mai putea fi salvate. Insa va trebui sa te asiguri ca faci tot ce-ti sta in putere ca numarul lor sa tinda cat mai mult spre zero. Iar epuizarea oamenilor din echipa dupa ultima suta de metri (nu pe, ci dupa) pentru “a salva ce mai poate fi salvat” nu e o solutie. Pentru ca oboseala transforma rezolvarea unei probleme intr-o problema si mai mare, iar adancirea haosului nu aduce nici un beneficiu nimanui.

Oricat ai fi de bun, mai devreme sau mai tarziu vei gresi. Sigur, e indicat ca asta se se intample cat mai rar – dar (uneori) se va intampla. Pentru ca esti om. Poti fi un profesionist foarte bun, dar tot om ramai. Dar – cand gresesti – nu pierde vremea cu gasirea unor eventuali vinovati (oricum, ca sef de proiect – esti primul dintre ei). Indiferent daca-i vei gasi sau nu, problema tot va trebui rezolvata. Asadar, cauta o solutie acceptata de partile implicate (una de compromis e mai buna decat niciuna) si aplic-o. E mai bine sa rezolvi partial problema decat sa-ti consumi timpul negandu-ti eventuala vina sau aruncand-o pe altii (sau plangandu-ti de mila) – decat sa n-o rezolvi deloc.

Sursa imaginii – link.


One Comment

  • Reply Nicu |

    Sunt de acord, cel mai important intr-o situatia critica este sa oferi o solutie. Nu trebuie sa cauti o scuza, ci sa oferi ceva constructiv ce poate readuce proiectul pe linia normala de lucru.

    Dar din pacate in cazul estimarilor, de multe ori ele nu sunt facute in functie de cat este de lucru ci de cat este bugetul. Astfel o estimare de 120 de ore la un proiect, ca atata este bugetul, se ajunge sa se lucreze la proiectul respectiv si peste 200 de ore. Acestea sunt situatile in care ai nevoie de nervi de otel sa le scoti la capat.

Lasa un comentariu