Etichetă: Dezvoltare Software

Cum să depășim conflictele dintre business analiști (product management), programatori și QA [P]

Echipele de dezvoltare software sunt formate din oameni care pot avea mentalități diferite, provin din medii diferite, au skill-uri și experiențe diferite, etc. De multe ori apar conflicte și dezbateri aprinse, ajungându-se astfel ca momentele tensionate să facă parte din munca de zi cu zi. Cheia este să identifici zonele în care pot apărea probleme și să găsești soluții clare pentru ele, care să economisească timp, energie, și nervi, și să ajute echipa să lucreze împreună. Ideal ar fi să nu existe astfel neînțelegeri, dar în cazul în care se întâmplă este nevoie să găsim modalități de a le rezolva și clarifica. Iată câteva exemple de conflicte precum și soluțiile pe care le-am întâlnit în Cognyte. 1. Nu este o eroare, dar nici nu este chiar o caracteristică. Unul din membrii echipei de QA detectează și ridică un bug (o eroare software) în Jira (Instrument de Urmărire a Problemelor și Managementul de Proiect). Team Lead: Merge bine. Nu înțeleg de ce spui că e bug. Așa a fost specificat că trebuie să funcționeze. QA: De fapt, este un scenariu pe care nu l-ai luat în considerare când ai scris codul. Clientul ne-a trimis niște scenarii pe care ei le folosesc și, din păcate, nu funcționează cu ce le-am livrat noi. Programatorul:  Ok, pot înțelege că sunt scenarii noi, dar nouă nu ni s-a spus atunci când au fost făcute specificațiile. Pentru noi este ceva nou. QA: Înțeleg, din păcate, scenariile acestea vin de la client și ei au nevoie de funcționalitățile acestea. Hai să vedem ce zice și echipa de business analiști. Business analist: Înțeleg ce spuneți, pare că nu am luat în considerare scenariile respective. Care sunt estimările pentru schimbările acestea? Programatorul: Estimăm 200 de ore de lucru, și va trebui să replanificăm ce facem acum, pentru că este clar că vom avea întârzieri. Business analist: Ok, înțeleg. Hai să discutăm astfel încât să găsim o soluție. Răspunsul care îi poate enerva pe cei de la QA și, uneori, pe clienți este: „funcționează conform specificaţiilor”. Practic, acest lucru înseamnă că  produsul funcţionează conform specificaţiilor, dar nu satisface pe deplin nevoile clientului. Este posibil să putem schimba, dar trebuie să ținem cont de costuri: orele de lucru care vor întârzia alte evoluții la deteriorarea mai multor sisteme (mai ales atunci când vine vorba de un produs complex, bogat în date, cu componente și integrări, precum și de utilizatorii activi din întreaga lume). Categoric se pot face schimbările necesare, dar trebuie să ținem cont și de costurile pe care le implică. Sunt ore suplimentare de care trebuie să ținem cont, apoi pot exista efecte adverse, posibil impact în alte zone ale produsului care pot face ca alte funcționalități să nu mai meargă. Asta este foarte posibil atunci când discutăm de un produs complex, cu multe componente și integrări, cu un volum de date semnificativ, clienți din toată lumea, și mai ales o industrie cu toleranță zero pentru perioadele de nefuncționare (zero tolerance for downtime), așa cum avem la Cognyte. Toate aceste aspecte trebuie luate în considerare. Ce este important de înțeles, este că nu vorbim de un „blaming game”. Nu arătăm pe nimeni cu degetul. Dacă echipă de QA ridică și confirmă în final un bug, este numai după ce se consultă și cu echipa de programatori. Dacă, în schimb, este o problemă mai complexă, atunci se apelează și la echipa de BA (business analist), cea care conduce din punct de vedere funcțional produsul. Ce se ȋntâmplă când toată lumea are dreptate? Este important să înțelegem că orice modificare are un cost, care nu este întotdeauna ușor de evaluat. Doar cei care cunosc cum funcționează întregul sistem, infrastructura sa și posibilul impact, pot estima cât de cât corect costul real al implementării unei schimbări complexe. Și chiar și în aceste cazuri, nu există o siguranță în estimare. O estimare este doar… o estimare. În final, deciziile de a implementa o cerință nouă depinde de priorități, iar echipa de business analiști (product management) și project management este implicată aici. În cazuri speciale, deciziile pot ajunge și la C-level. Totuși, înainte de orice decizie, inițiem o discuție deschisă, unde toate părțile implicate pot veni cu argumente pro și contra, încercând să luăm o decizie care să ne ajute pe viitor, atât din punct de vedere al clientului actual, cât și a altor clienți existenți sau potențiali. O discuție de acest tip poate duce la două rezultate: fie noua cerință va fi rezolvată ca un bug fix, fie vom decide că este o limitare a versiunii actuale urmând să o implementăm într-o versiune viitoare. O altă abordare pe care o avem este de a ne defini un plan de testare, convenit cu echipa de QA, înainte de începerea scrierii codului (test driven-development). Acest lucru ajută la definirea clară a așteptărilor și permite programatorilor să știe ce scenarii vor fi testate, astfel încât să poată scrie codul cât mai corect de la început. De asemenea, planul de testare este aprobat de echipa care coordonează cerințele funcționale. Această metodă ajută la reducerea bug-urilor și asigură o bună aliniere între echipe din punct de vedere al înțelegerii noilor cerințe. 2. Modificare majoră sau corecție minoră? Am menționat că produsele noastre sunt complexe. Unele dintre ele sunt atât de complicate încât o nouă versiune poate apărea doar o dată pe trimestru sau chiar mai rar, uneori la șase luni sau chiar mai mult. Chiar și actualizarea unei versiuni pe platformele interne (On-Premises) este un proces semnificativ. Nu este vorba doar de un „click pe un buton”. Totuși, asta nu împiedică clienții să ne trimită cerințe noi în tot acest timp. Aceste solicitări sunt normale și legitime. Pentru a răspunde rapid tuturor clienților, am creat un nou departament numit „Servicii” (Services). Prin acest departament, există o echipă de programatori dedicată pentru a rezolva bug-uri și a implementa mici corecții și actualizări care nu sunt parte din produsul global standard. Ei sunt primii care interacționează cu clienții atunci când apare o problemă. Uneori, echipa de produs (Product Management- PM)