Responsabilitățile unui Business Analyst (BA) într-un proiect de dezvoltare _software_în care se folosește metodologiaAgile constituie un subiect foarte răspândit. În cadrul acestui articol vom trata doar o parte din el, încercând să oferim un răspuns la următoarea întrebare: “Care poate fi contribuția unui BA la livrarea unui proiect de dezvoltare software de către o echipă SCRUM?”
Pentru a delimita și mai clar subiectul acestui articol, vom încerca să oferim răspunsul din perspectiva unei echipe din cadrul unei companii IT de outsourcing (servicii externalizate). Această ‘nișă’ de domeniu permite deschiderea unei discuții prin intermediul răspunsului propus de acest articol.
Aceasta este una dintre cele mai întâlnite reacții ale echipelor SCRUM. Echipa SCRUM are un Product Owner (PO) – de obicei aflat la client –, un Scrum Master (SM), un Manager de proiect (PM) și un backlog. Prin urmare, totul este destul de clar – există ‘obiectul muncii’, sunt prezente rolurile de coordonare și de raportare, există și un responsabil de produs. La ce ne folosește un BA în echipă?
De fapt, în cadrul echipei SCRUM, există deja persoane care îndeplinesc atribuțiile unui BA, astfel rolul și responsabilitățile sunt deja in situ, lipsind doar o personificare a lor. Astfel, un programator senior sau un QA pot să aibă sarcini care ar fi destinate în mod normal unui BA; unele atribuțiuni sunt îndeplinite de către PM sau SM, iar altele de către PO. Astfel am obținut răspunsul pentru ‘locul’ pe care l-ar ocupa un BA in echipă.Însă trebuie să admitem faptul că în cele mai multe situații este dificil pentru o persoană din exterior să preia responsabilitățile de la membrii unei echipe deja formate. Ce se poate face în această situație?
Pentru început, ca oricare nou-venit într-o echipă, un BA trebuie să câștige încrederea colegilor. Pentru a putea face asta, trebuie să înțeleagă modul de lucru al echipei din perspectiva relațiilor dintre membrii ei și a proceselor interne. Discuțiile purtate cu membrii seniori ai echipei pentru a înțelege proiectul, studiu individual despre domeniul de activitate al clientului, înțelegerea nevoilor unei organizații care activează în respectivul domeniu, înțelegerea particularităților clientului, alături de atributele clasice ale unui BA (abilități de comunicare, cunoștințe despre metodologiile de lucru, atenția la detalii, etc.), sunt doar câteva dintre mijloacele pe care un BA le poate folosi pentru a câștiga încrederea echipei.
În al doilea rând, un BA trebuie să identifice punctele slabe ale proiectului, acestea fiind cele mai susceptibile pentru îmbunătățiri. Iată câteva dintre cele mai frecvente:
Ultimul aspect pe care îl vom menționa, dar cu siguranță unul dintre cele mai importante, este atitudinea. O atitudine cooperantă dar fermă, prin care se subliniază faptul că eforturile și cunoștințele echipei sunt apreciate, că există dorința de a ajuta echipa și de a îmbunătăți starea de fapt.
Prin urmare, putem concluziona că un BA poate să:
Bazându-se pe experiența anterioară, un BA ar trebui să se poată deprinde cu noile instrumente de lucru, sau să propună variante mai bune. Așa cum am menționat anterior, trebuie să ofere variante de îmbunătățire pentru diferite aspecte ale proiectului.
Nevoia de îmbunătățire a proceselor este un aspect prezent în foarte multe companii IT care activează in domeniul outsourcing, mai ales datorită faptului că procesele echipei SCRUM care lucrează într-un proiect externalizat sunt constituite ca un amestec dintre procesele interne ale companiei și procesele din cadrul companiei clientului. Analistul de business (BA) trebuie să înțeleagă motivele care au determinat adoptarea proceselor curente, iar apoi trebuie să propună schimbările care ar aduce valoarea cea mai mare pentru echipă. Astfel efortul de integrare se va diminua, iar echipa și clientul vor căpăta încredere în noul membru. Instrumentele care pot fi folosite în acest caz sunt programe pentru întocmire a diagramelor de proces (ex. MS Visio), suite de aplicații pentru birou (MS Office, Libre Office, Open Office).
Îmbunătățirea proceselor din organizația clientului poate fi un obiectiv pentru fazele ulterioare ale proiectului, în momentul în care analistul are o poziție mai solidă și a câștigat un capital de încredere semnificativ.
Documentarea specificațiilor este unul dintre aspectele care suportă îmbunătățiri de cel mai multe ori în cadrul unui proiect, din diferite puncte de vedere – al structurii, al actualizărilor, al integrării cu procesele și chiar al accesibilității. Un BA trebuie să analizeze starea curentă și apoi poate propune o soluție de ameliorare, în funcție de nevoile echipei. Exemple de îmbunătățiri: păstrarea documentelor într-un depozit accesibil (fie prin intermediul unei aplicații de versionare, fie virtual – wiki), care să permită referențierea celorlalte instrumente de urmărire a sarcinilor de lucru (ex. Atlassian Confluence, SharePoint, Github, Atlassian Jira, VersionOne). Crearea documentelor se va face în suitele de aplicații menționate anterior.
Desigur că pot apărea situații în care documentația de proiect să fie ori suficientă pentru nevoile echipei, ori absentă, dar considerăm că este loc de îmbunătățiri aproape tot timpul.
Pentru a putea să amelioreze acest aspect, analistul trebuie să cunoască _stakeholder-_ii, să identifice și să cadă de comun acord asupra unui plan de comunicare cu aceștia, dar, mai ales, să aibă girul conducerii firmei pentru a gestiona comunicarea. Mijloacele pe care le poate folosi sunt matrici RACI/RASCI (Responsible-Accountable-Consulted-Informed/ Responsible-Accountable-Support-Consulted-Informed), planuri de comunicare, la a căror întocmire să participe activ și analistul.
Această componentă a proiectului este una sensibilă, fie că este vorba de cerințele pentru produs sau doar cele ale echipei (Product Backlog și Team Backlog), pentru că în aceste elemente se regăsesc în modul cel mai vizibil procedurile și ‘obiceiurile’ vechi ale proiectului. Acest fapt determină rezistența sporită la schimbare, chiar dacă există argumente solide.
Există anumite tipuri de argumente care pot fi coroborate pentru a obține acceptarea schimbărilor, și anume: alinierea cu metodologia de lucru, consistența și claritatea cerințelor, structurarea și îmbunătățirea elementelor backlog-ului (Epic – User Story – Task), dar și a specificațiilor aferente, sunt câteva exemple în acest sens.
Aceasta este o provocare ‘pozitivă’ pentru analist într-un proiect nou, pentru că lipsa de claritate a cerințelor, absența sau calitatea slabă a specificațiilor sau designului sunt situații care permit analistului să prezinte soluții rapide și vizibile.
Pentru a oferi soluții acestor probleme, analistul are la îndemână o paletă largă de aplicații, după cum urmează:
Analistul trebuie să țină cont de convențiile existente legate de culori, de existența unui responsabil de design în organizația clientului sau în cadrul echipei.
Una dintre cele mai importante calități ale unui analist este abilitatea de a identifica în mod precis acele cerințe care necesită astfel de detaliere. Prezentarea detaliilor către echipă este, de asemenea, un pas important.
Echipa SCRUM trebuie cunoască detalii despre proiect, despre produs, dar trebuie să aibă și o imagine de ansamblu despre schimbările care se petrec în organizația clientului și în domeniul de activitate al acestuia. Deși nu afectează direct munca echipei, aceste informații influențează moralul acesteia, crescând nivelul de importanță care se acordă muncii fiecăruia dintre membrii ei. În același timp, analistul câștigă un capital de încredere prin faptul că oferă aceste informații.
Pentru a crește nivelul de informare, analistul are la îndemână o serie de instrumente, cum ar fi: discuții ad-hoc, interacțiuni regulate cu membrii echipei (în cadrul ceremoniilor SCRUM), prezentări ocazionale de informare.
Există o largă paletă de tehnici și instrumente care stau la dispoziția unui BA pentru a se integra într-o echipă SCRUM și pentru a-și aduce aportul la succesul proiectului. Folosind abilitățile și instrumentele prezentate mai sus, analistul poate influența atât procesele interne ale echipei, cât și procesele din organizația clientului, adăugând valoare produsului dar și celor două organizații implicate.
Așa cum menționam în primele paragrafe, feedback-ul pentru argumentația de mai sus este binevenit și va fi luat în considerare pentru viitoarele articole despre beneficiile pe care le poate aduce un BA într-un proiect de dezvoltare software externalizat care folosește metodologia SCRUM.
de Peter Lawrey
de Răzvan Costa
