Analiza unui change request

changeDefinitia unui change request difera in functie de persoana chestionata si de rolul persoanei respective in cadrul unui proiect. Desi toate aceste definitii vorbesc de fapt despre acelasi lucru, ele difera datorita viziunii fiecarui participant la proiect.

Pentru project manager, un change request reprezinta de fapt o cerere de modificare a setului de specificatii pe care proiectul il avea pana in acel moment. O cerere venita de la cineva cu putere de decizie in cadrul proiectului (clientul sau altcineva). Una care va fi analizata, iar daca rezultatul analizei este unul pozitiv – va fi estimata, planificata si implementata. In functie de costul change request-ului respectiv (ore de lucru necesare / buget), acesta va avea un impact mai mic sau mai mare asupra proiectului in sine – existand uneori posibilitatea sa-i schimbe complet cursul.

Pentru CEO, change request-ul reprezinta ceva cerut de un factor decizional important din cadrul proiectului – deci ceva care trebuie neaparat luat in calcul.

Pentru developer, reprezinta deseori un stres in plus. Probabil ca va trebui sa refaca o anumita parte a proiectului pentru realizarea careia a depus un efort considerabil pana atunci, ceea ce inseamna ca munca respectiva se va pierde. Sau poate ca modificarea ceruta presupune alte modificari care trebuie facute in avans, la alte parti ale proiectului, pentru a pregati terenul. Poate chiar modificari de arhitectura, care vor afecta o parte fundamentala si – in consecinta – tot ceea ce a fost cladit pe acea parte.

Pentru client, change request-ul se incadreaza intr-una dintre cele trei situatii de mai jos :

  • Vine de la o persoana cu influenta majora asupra proiectului. Un sponsor, cel mai probabil. Cineva cu o putere de decizie mai mare decat clientul.
  • Reprezinta o adaptare a proiectului la cerintele pietei careia i se adreseaza.
  • E ceva ce clientul avea de gand sa faca de la bun inceput, dar a uitat sa spuna – sperand ca acea functionalitate “se va intelege de la sine” (nu, din pacate nu e gluma).

Indiferent de viziunea proprie a fiecarui participant la proiect asupra change request-ului, un lucru e clar. Si anume – change request-ul trebuie analizat inainte de toate. Intentiile cu care e trimis un change request sunt de regula dintre cele mai bune. Toti clientii doresc succesul proiectului propriu. Nimeni nu pune pe picioare / finanteaza un proiect din dorinta de-a-l vedea cum esueaza. Asadar, cand project managerul va primi un change request pentru analiza, va trebui sa presupuna ca – din perspectiva clientului – acest request urmareste un outcome pozitiv.

Analiza change request-ului va detalia impactul sau asupra proiectului, din toate punctele de vedere. Pentru ca acest impact sa poata fi vizualizat cat mai clar, trebuie luate in calcul cateva aspecte – dupa cum urmeaza. Nota : dau lista urmatoare in ideea ca se aplica pentru change request-uri consistente.

  • Exista anumite specificatii – implementate sau planificate pentru implementare – care vor intra in conflict cu specificatiile din change request ?
  • In ce mod va fi afectata performanta produsului final? Dar nivelul de calitate al acestuia?
  • Exista in cadrul echipei de dezvoltare persoane cu skill-urile necesare pentru a implementa request-ul ?
  • Cat anume se va pierde din efortul deja investit in cadrul proiectului, daca acest change request se va implementa ?
  • Implementarea request-ului respectiv implica noi costuri, la nivel de arhitectura a proiectului (hardware / licente software) ?
  • Vor exista costuri recurente, dupa implementarea change request-ului (ca de exemplu, diverse abonamente lunare/anuale pentru anumite servicii externe) ?
  • Cum vor fi afectate procesele ce vor urma dupa ce dezvoltarea produsului va fi completa (campanii de marketing / tutoriale pentru clienti / etc.) ?
  • In ce mod va fi afectata experienta utilizatorilor care vor folosi produsul final?
  • Care este durata necesara implementarii change request-ului (in ce mod afecteaza calendarul de development) si care va fi costul aditional necesar (impactul asupra bugetului) ?

Desigur, sunt si alte intrebari care se impun atunci cand change request-ul este tinut “sub lupa”. Pe cele de mai sus le consider insa absolut necesare.

Rezultatul analizei va trebui discutat cu toti factorii decizionali din cadrul proiectului. Vor trebui discutate toate aspectele si implicatiile – atat pozitive cat si negative. Daca in urma discutiei va primi unda verde – tinand cont de consecintele ulterioare, prevazute si explicate in analiza – atunci va fi planificat pentru implementare.

Orice change request va avea consecinte ulterioare, in cadrul proiectului. Cu cat e mai mare, cu atat consecintele pot deveni si ele semnificative. O analiza corecta va evidentia toate aceste consecinte, alaturi de argumentele pro si contra – si va asigura suficienta claritate pentru ca factorii decizionali implicati sa poata lua o decizie corecta.

Ce fel de probleme va pun change request-urile in general?

Add a Comment

Your email address will not be published. Required fields are marked *