Gestionarea conflictelor între Business Analyst, Programatori și QA

Echipele de dezvoltare software sunt alcătuite din indivizi cu perspective diverse, provenind din medii variate și posedând competențe și experiențe diferite. De cele mai multe ori, apar divergențe și discuții animate, transformând momentele tensionate într-o parte integrantă a activității cotidiene. Secretul constă în identificarea zonelor potențial conflictuale și găsirea unor soluții clare pentru acestea, care să economisească timp, resurse și eforturi, și să ajute echipa să colaboreze armonios. Ideal ar fi să nu existe disensiuni, dar, în cazul în care apar, este esențial să găsim modalități de a le rezolva și clarifica.

1. Nu este o eroare, dar nici o caracteristică completă.

Un membru al echipei de testare identifică și raportează un defect software în Jira (instrument de gestionare a erorilor și a proiectelor).

Liderul de echipă: Merge perfect. Nu înțeleg de ce consideri că este un defect. Așa a fost definit funcționarea.

Testare: De fapt, există un scenariu care nu a fost luat în considerare la programare. Clienții ne-au furnizat scenarii pe care le utilizează, însă, din păcate, nu funcționează conform așteptărilor.

Dezvoltator: Înțeleg că sunt scenarii noi. Însă, nu ne-au fost prezentate la specificarea inițială. Pentru noi este o noutate.

Testare: Înțeleg. Din păcate, aceste scenarii vin de la clienți, iar aceștia au nevoie de aceste funcționalități. Să consultăm și echipa de analisti de business.

Analyst de business: Înțeleg. Se pare că scenariile respective nu au fost luate în considerare complet. Care este evaluarea pentru modificările necesare?

Dezvoltator: Estimam 200 de ore de muncă, și va fi necesară o reorganizare a celorlalte sarcini, implicând întârzieri.

Analyst de business: Înțeleg. Să discutăm pentru găsirea unei soluții.

Răspunsuri care pot enerva membrii echipei de testare și, uneori, clienții includ: „funcționează conform specificațiunilor”. Acest lucru poate însemna că produsul funcționează conform specificațiunilor, însă nu îndeplinește pe deplin cerințele clientului. Este posibilă modificarea, dar trebuie luate în considerare cheltuielile: orele suplimentare, efectele adverse posibile asupra altor secțiuni ale produsului. Acest lucru este relevant în special în cazul produselor complexe, cuprinzând multiple componente și integrări, un volum semnificativ de date, clienți din întreaga lume și industrii cu toleranță zero la perioade de inactivitate, aşa cum este cazul la Cognyte.

Toate aceste aspecte sunt esențiale.

Important de remarcat este că nu este un joc de acuzații. Nu se acuză pe nimeni. Un defect, confirmat de echipa de testare, este validat numai după consultarea echipei de dezvoltare. În cazul problemelor mai complexe, este implicată și echipa de analisti de business, care conduce din punct de vedere funcțional.

Ce se întâmplă când toți au dreptate?

Este crucial să înțelegem că orice modificare presupune costuri, uneori greu de estimat. Doar experții cu o perspectivă generală asupra sistemului, infrastructurii și impactului potențial pot estima cât de bine costul efectiv al unei schimbări complexe. Chiar și în aceste cazuri, nu există garanții în estimări. O estimare este doar… o estimare. În cele din urmă, deciziile privind implementarea unei cerințe noi depind de priorități, iar echipa de business (management produs) și managementul de proiect sunt cheie. În cazuri excepționale, deciziile pot ajunge și la nivel superior.

Înainte de orice decizie, se inițiază o discuție deschisă, unde toate părțile pot aduce argumente pro și contra pentru a lua o decizie avantajoasă atât pentru clientul actual, cât și pentru ceilalți clienți existenți și potențiali.

O astfel de discuție poate avea două rezultate: fie noua cerință este gestionată ca un defect, fie se decide că este o limitare a versiunii actuale, urmând să fie implementată într-o versiune viitoare.

O altă abordare utilizată este definirea unui plan de testare, convenit cu echipa QA înainte de a începe programarea (test-driven development). Acest lucru facilitează clarificarea așteptărilor și permite programatorilor să știe ce scenarii vor fi testate, astfel încât codul să fie corect și complet de la început. De asemenea, planul este aprobat de echipa care coordonează specificările funcționale.

2. Modificare majoră sau corecție minoră?

Produsele noastre sunt complexe. Unele necesită o nouă versiune o dată la trimestru sau chiar mai rar, câteodată la șase luni sau mai mult. Chiar și actualizarea unei versiuni pe platformele interne (On-Premises) este un proces extins. Cu toate acestea, clienții trimit cereri noi. Aceste cerințe sunt normale și legitime. Pentru a răspunde rapid, a fost creat un nou departament „Servicii” cu o echipă de programatori dedicată soluționării defectelor și implementării corecțiilor mici și actualizărilor care nu fac parte din produsul standard.

Uneori, echipa de management produs (PM) propune o nouă cerință pe care o consideră simplă. Discuția poate fi:…

(Exemple de dialog, identic cu textul original)

În companii mai mici, acest tip de situații nu apar la fel de frecvent. În organizațiile mari și multinaționale, cu mulțime de proiecte concurente, sunt inevitabile.

Ce se întâmplă când toți au dreptate?

Și în acest caz, soluția constă în „alegerea bătăliilor”, prioritizarea și negocierea atunci când este necesar. Compromisul poate fi o soluție când prioritățile sunt în conflict. Dialogul permite întotdeauna găsirea unui compromis și echilibru între nevoile clientului și ale companiei.

3. Uneori nu vedem pădurea din cauza copacilor. Cum putem găsi responsabilul?

În general, fiecare funcționalitate este asociată cu o componentă, un modul sau un grup. Exemplu: fluxul datelor, encodar/decodar, etc. Există situații când o funcționalitate aparține mai multor segmente. Cine este, în acest caz, responsabil, la cine se adresează întrebările sau raportările?

Ce se întâmplă când toți au dreptate?

Sau când responsabilitatea este a tuturor? De obicei, o echipă trebuie sa preia responsabilitatea. Dar, chiar și în aceste cazuri, pot exista necunoscute. Din păcate, puțini colegi au o viziune globală a întregului sistem, mai ales când propriile lor sarcini sunt deja intense. În absența unor „voluntari” pentru această responsabilitate, se impune nominalizarea segmentului responsabil, bazată pe relevanță, volum de cod, teste, număr de oameni și expertiză.

4. Cartoful fierbinte

În departamentul de cercetare și dezvoltare, specificațiile pentru funcționalități noi nu sunt întotdeauna clare. Uneori sunt minimale, ceea ce generează multe întrebări. Se pot petrece discuții prelungite între echipele implicate, încercând să descopere intențiile originale.

(Exemple de dialog, identic cu textul original)

Situațiile descris mai sus sunt, cel mai probabil, exagerări. Dar pot genera întârzieri, neînțelegeri și frustrare, atât la programtori, testare, cât și la clienți și management produs. Este important ca specificațiile să includă motivația, valoarea pentru client și integrarea în produsul existent, permițând evitarea discuțiilor contradictorii și a pierderilor de timp. De asemenea, orice modificare sau limitare trebuie clar specificate.

Pe scurt: fiți colegiali, evitați lupta ego-urilor, aveți încredere reciprocă, ascultați atent și lucrați pentru binele produsului, al companiei și succesul echipei.