Conflict între business analyst, programatori și QA: soluții [P]

Echipele de dezvoltare software sunt alcătuite din indivizi cu perspective, formații și experiențe diverse. Aceste diferențe duc deseori la conflicte și discuții animate, transformând momentele tensionate într-o componentă a muncii zilnice. Este crucial să se identifice zonele vulnerabile și să se găsească soluții clare pentru a economisi timp, efort și nervi, și pentru a ajuta echipa să colaboreze eficient. Ideal ar fi să nu apară astfel de neînțelegeri, dar, în caz contrar, este esențial să se găsească metode de rezolvare și clarificare.

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

Un membru al echipei QA identifică și raportează un defect (bug) în Jira.

Lead-ul echipei: Funcționează așteptat. Nu înțeleg de ce ar trebui considerat un defect. Așa a fost specificată funcționalitatea.

QA: De fapt, este un scenariu nou, ce nu a fost luat în calcul în timpul proiectării. Clientul a furnizat exemple de utilizare pe care productul nu le acceptă încă.

Programatorul: Înțeleg că sunt situații noi, dar specificaţiile nu le-au conținut.

QA: Înțeleg, scenariile provin de la client și funcționalitățile respective sunt esențiale pentru aceștia. Să consultăm echipa de business analisti.

Business analyst: Înțeleg contextul, aparent scenariile nu au fost luate în calcul. Care sunt estimările pentru modificările cerute?

Programator: Estimam 200 de ore de muncă. Va fi nevoie de o reprogramări a sarcinilor, întrucât sunt anticipate întârzieri.

Business analyst: Înțeleg. Să construim împreună o suită de modificări adecvate.

Răspunsul care poate enerva specialiștii QA și, uneori, clienții este: „funcționează conform specificaţiilor”. Aceasta înseamnă că produsul respectă specificațiile, dar nu întrunește în totalitate necesitățile clientului. Poate fi implementat, dar costurile trebuie luate în calcul, ținând cont de orele suplimentare și de posibilele efecte secundare asupra altor funcționalități, mai ales în proiecte complexe, cu volume mari de date, utilizatori globali și perioade de nefuncționare zero tolerance.

Este obligatoriu să se țină cont de factorii implicați.

Important: Nu este vorba de „blaming”. Echipa QA identifică un defect numai după consultarea cu echipa de dezvoltare. În cazuri complexe se implică și echipa de business analisti.

Ce se întâmplă când toată lumea are dreptate?

Orice modificare implică costuri, uneori greu de estimat. Numai specialiștii cu o viziune completă asupra sistemului pot estima costurile reale ale implementării unor modificări complexe. Chiar și în aceste cazuri, estimările sunt aproximări. În final, decizia de implementare depinde de priorități, și echipe, în mod special, echipele de business analisti, si managementul de proiect sunt implicate. În situaţii excepţionale, deciziile pot ajunge la nivel C-level.

O discuţie deschisă cu toate părţile implicate ajută la o decizie care să aducă beneficii pe termen lung, pentru clienţii existenţi, şi pentru cei potenţiali.

Discuțiile pot duce la două rezultate: fie cerinţa va fi rezolvată ca o corecție de defect, fie va fi considerată o limitare, implementată într-o versiune viitoare.

O altă abordare este definirea unui plan de testare, aprobat de echipa de QA, înainte de programare. Astfel se stabilesc așteptările și programatorii pot proiecta codul în direcţia anticipării cerințelor de testare.

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

Uneori noile versiuni apar doar o data pe trimestru sau la jumătate de an. Chiar și actualizarea unor componente este un proces complex. Cu toate acestea, clienții ne solicită neîncetat facilități noi.

Un departament dedicat „Servicii” se ocupă de gestionarea cerințelor clientului care nu merită a fi procesate prin procese de aprobare complicate.

Uneori, echipa de product management vine cu o cerinţă considerată facilă şi rapid de implementat, fără a parcurge procesele obișnuite de aprobare.

Deseori, echipele se confruntă cu o dilemă între nevoile clientului și complexitatea produsului.

Ce se întâmplă când toată lumea are dreptate?

Soluția este prioritizarea și negociere. Dialogul conduce întotdeauna la un compromis.

3. Responsabilitatea funcţionalităţii?

În general, fiecare funcţiune este alocată unei componente, modului, grupului, etc. Dar situaţii când o funcţionalitate implică mai multe părţi? Cine este responsabil, cine este contactul?

Ce se întâmplă când toată lumea are dreptate?

O echipă/segment preia responsabilitatea pentru funcționalitatea respectivă. Pot exista necunoscute și situaţii ignorate, mai ales atunci când o echipă este deja suprasărcită.

Soluția este de a alocat efectiv responsabilitate, ținând cont de relevanța, codul implicat, test case-uri relevante, număr de oameni și cunoştinţe.

4. Cartoful fierbinte

Uneori specificațiile pentru noi funcționalități nu sunt suficient de clare, generând întrebări și interpretare. Mai ales echipele de dezvoltare se pot simți neclare, implicate in contextul unor cerințe complicate.

Pentru sisteme complexe, dezvoltate pe parcursul mai multor ani, este dificil să se asigure că fiecare coleg are o imagine de ansamblu.

Pentru evitarea unor neînțelegeri viitoare, este esențială clarificarea motivaţiei, valorii pentru client și integrării în produsul existen. Specificarea limitărilor într-un documant central, cum ar fi Jira, este crucială.

Pe scurt: colaborarea, înţelegerea reciprocă şi concentrarea pe produs sunt esențiale pentru succesul echipei.