În ziua de astăzi, software development a devenit un termen foarte uzitat. Dar câți dintre noi ne-am întrebat cum ajunge un software pe calculatorul nostru?
Nu există un răspuns simplu la această întrebare, în schimb putem să privim în detaliu modul în care interacționează de regulă un grup de oameni, cum se înțeleg la fiecare pas al procesului și, nu în ultimul rând, să descoperim ce importanță are rolul de Business Analyst în cadrul echipei de software development.
Începutul oricărui proiect implică parcurgerea anumitor etape. Întâi, alocăm timp să ne cunoaștem în cadrul echipei. Unii suntem mai lipsiți de îndrăzneală, dar cu timpul începem să fim mai vocali și să interacționăm, luând parte la discuții constructive, care pot fi contradictorii, într-o primă fază. În final, ne găsim ritmul și fiecare se simte parte a echipei, știind ce are de făcut.
Acest proces a fost cel mai bine conturat pentru prima dată de Bruce Tuckman, cercetător american în psihologie. Acesta, în 1965, a configurat modelul "forming-storming-norming-performing". Tuckman consideră că fiecare etapă are caracteristici proprii. A denumit perioada de început, "Forming", drept o perioadă de cunoaștere când echipa se întâlnește, se familiarizează cu proiectul și începe alocarea primelor taskuri. Totodată, a menționat că în acest pas membrii echipei tind să lucreze mai mult individual și toată lumea își arată cea mai frumoasă latură.
După fazele incipiente urmează ceea el a numit "Storming", a doua etapă de formare a echipei. În acest punct, adeseori, apar primele neînțelegeri și primele păreri contradictorii ale membrilor. Fiecare și-a format deja o părere despre ceilalți coechipieri și începe să își facă auzită vocea, încercând să creeze o ierarhie informală în echipă. Tuckman a considerat perioada de "Storming" a fi cea mai dificilă pentru că oamenii se pot simți judecați, pot apărea tensiuni și schimburi de idei care pot duce la un mediu de lucru ostil.
A treia etapă, "Norming", descrie însă o stare de calm în cadrul echipei. Aici toți cei implicați au reușit să își rezolve conflictele atât interpersonale cât și cele de opinie și totul începe să decurgă natural, cu familiaritate. Membrii echipei dezvoltă conexiuni interpersonale și legături de încredere, astfel încât toți își îndreaptă atenția înspre îndeplinirea scopului comun: livrarea proiectului.
Există însă încă o etapă după cea de "Norming", numită "Performing". Pasul acesta descrie o stare de normalitate peste medie, unde toată lumea lucrează la cel mai înalt nivel, iar proiectul înaintează cu o viteză mai mare decât ceea estimată. Majoritatea echipelor ajunge eventual în acest punct, mai rapid sau mai târziu în funcție de leadership, dar există de multe ori riscul de a regresa la "Storming", în cazul în care se schimbă componente majore din echipă sau chiar conducerea echipei.
Business Analystul este persoana care are cea mai strânsă legătură cu clientul. Îl înțelege, îl îndrumă și notează cerințele acestuia pentru a putea livra software la comandă și astfel a-i satisface cel mai bine cerințele de business. Prin cunoștințele și experiența pe care le deține, Business Analystul poate ajuta clientul să înțeleagă în amănunt care îi sunt nevoile în cadrul acelui proiect. Prin urmare, el descompune cerințele în părți mici care se pot trata incremental prin User stories de către echipă. Totodată, Business Analystul trebuie să prioritizeze și să organizeze aceste User stories pentru a urma planul care va duce la livrarea proiectului conform dorinței clientului; în plus, trebuie să se asigure că la fiecare pas există comunicare cu clientul pentru a se atinge scopul final propus.
Într-o echipă formată din Developers, QA, Project Managers, Scrum Masters, Team Leaders sau alte funcții pe care, în cele ce urmează, o să le numim leadership, putem observa că Business Analystul are, de fapt, mai multe coordonate pe care trebuie să le urmeze pe lângă cele de a ține legătura cu clientul și de a forma cerințele prin User stories. De aceea, merită de privit mai în detaliu cum poate contribui un Business Analyst la procesul de formare a echipei de-a lungul proiectului.
Fiecare pas al proiectului implică un grad diferit de formare în cadrul echipei, astfel putem considera că și implicarea Business Analystului este diferită în funcție de moment.
În primul rând, Business Analystul trebuie să fie în permanentă legătură cu persoanele direct implicate în leadershipul proiectului, cum ar fi Project Managerul, Team Leadul sau Scrum Masterul, aceste persoane având o influență mare în echipă și un cuvânt de spus în modul în care se tratează și se rezolvă conflictele. Considerăm ca un Business Analyst trebuie mereu să țină legătura atât la nivel unu-la-unu cu membrii echipei de leadership, dar și la nivel de grup, cu ceilalți membri ai echipei. Astfel se poate stabili o "politică" de grup referitoare la modalitatea de abordare echipei, luându-se, în același timp, în considerare nevoia de business a clientului. Comunicarea Business Analystului cu echipa de leadership este esențială din două perspective: pe de o parte, Business Analystul trebuie să fie conștient de capacitatea echipei și de schimbările din echipă ce pot afecta evoluția proiectului pentru a putea prevedea corect nevoia și tipurile de taskuri pentru viitorul apropiat (informație provenită de la echipa de leadership), iar pe de altă parte, leadershipul trebuie să fie tot timpul conștient de nevoia de business a clientului (informație cel mai bine cunoscută de către un Business Analyst care poate analiza și documenta aceste nevoi).
Cum am menționat , implicarea Business Analystului trebuie să fie proporționată în funcție de etapa în care se află proiectul.
În fazele incipiente din "Forming", inclusiv de la momentul primelor introduceri, Business Analystul trebuie să susțină comunicarea și să arate o neutralitate în ceea ce privește exprimarea de opinii. Conform lui Tuckman, la faza de "Forming", oamenii sunt mai timizi și de aceea este nevoie de o comunicare cât mai facilă și deschisă. Acum leadershipul proiectului trebuie să organizeze sesiunile de "get-to-know" între membri echipei, iar Business Analystul trebuie să arate că este dornic să cunoască oameni noi, să-și împărtășească experiențele și să creeze un mediu prietenos pentru a îndruma restul colegilor să fie deschiși în a comunica. Totodată, fără susținerea reciprocă între leadership si Business Analyst, echipa va percepe un mediu puțin propice dezvoltării, poate chiar haotic.
Probabil cel mai greu pas din mersul echipei este cel de "Storming": echipa deja știe să comunice eficient, membrii sunt confortabili unii cu ceilalți, iar opinii contradictorii vor apărea mereu. În acest punct, unul dintre cele mai importante aspecte este ca Business Analystul - cel care cunoaște cel mai bine următorii pași în implementarea proiectului sau existența unor aplicații deja implementate) - să își arate disponibilitatea față de echipă și să îi îndrume acolo unde este cazul.
Business Analystul poate detensiona o conversație prin luarea unei decizii care să deservească nevoia finală a businessului; oricând apare o neînțelegere, el trebuie să fie mediatorul conversației având cunoștințe despre nevoile de business ale clientului. Dar luarea unei decizii poate detensiona situația doar în cazul în care Business Analystul a ascultat părerea tuturor părților implicate și a argumentat concret tuturor alegerea unei anumite variante cu claritate și transparență. În mod similar cu prima fază, între Business Analyst și leadership trebuie să existe o susținere reciprocă, altfel creându-se premisele aceluiași mediu ostil și haotic.
Trecând peste "Storming", în etapa de "Norming" de obicei taskul de mediator al Business Analystului se diminuează. Membrii echipei știu deja că pot apel la Business Analyst pentru a rezolva orice întrebare despre proiect.
Similar cu etapa de "Norming", în cel de "Performing", Business Analystul nu mai este mediatorul, ci mai degrabă este încurajatorul echipei. În această fază, oamenii deja au învățat că și ei pot lua decizii care contribuie la bunul mers al proiectului și pot lucra în echipă cu ce putem numi performanță. În acest punct, Business Analystul are rolul de a da încredere și mai multă oamenilor, de a încuraja mersul proiectului și de a se asigura că la final rezultatul răspunde nevoii de business a clientului.
Cum am descris deja, Business Analystul trebuie să fie un element dinamic în echipă pentru că aceasta este mereu într-un proces de evoluție. Business Analystul trebuie mereu să fie mediatorul între obiectivul businessului, incursiunile interpersonale ale membrilor în diferitele etape ale modelului Tuckman și politica leadershipului pentru conducerea proiectului, doar prin adaptarea la elementele listate Business Analystul poate avea un impact pozitiv și semnificativ pentru a se asigura că proiectul își atinge țelul de business eficient și cu o echipă care are mereu un spirit de performanță.
Vorbind din experiența personală de Business Analyst în cadrul companiei PitechPlus, am experimentat cât de importantă este atitudinea cu care abordez un proiect. Încă din pasul în care începeam un proiect (forming) am observat cum echipa are tendința de a complica unele subiecte, și aici nu mă refer la discuții contradictorii care deseori pot fi constructive. Prin faptul că m-am oferit să mediez, să discut unu-la-unu cu oamenii, să susțin mereu un mediu calm și constructiv, am ajuns să avem un proiect cu performanțe și clienți extrem de fericiți.
Așadar, indiferent de rolul pe care îl aveți în echipa de proiect, de experiența pe care o aduceți, mereu luați în considerare imaginea de ansamblu și mereu fiți deschiși să adresați întrebări și să cereți îndrumare. Veți primi răspunsul și veți face parte dintr-o echipă de succes.
de Ovidiu Mățan
de Ovidiu Mățan
de Vlad Petrean
de Ovidiu Mățan
