Echipele de dezvoltare software sunt formate din persoane cu perspective, medii și experiențe diverse. Acest lucru conduce deseori la conflicte și discuții intense, transformând momentele tensionate în parte integrantă a muncii cotidiene. Soluția eficientă constă în identificarea potențialelor probleme și găsirea de soluții clare pentru a economisi timp, energie și efort și pentru a facilita colaborarea în echipă. Ideal ar fi evitarea acestor neînțelegeri, dar atunci când apar, este crucial să le rezolvăm și să le clarificăm.

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

Un membru al echipei QA identifică și raportează o eroare în sistemul de urmărire a proiectelor.

Lead Tehnic: Funcționează conform specificațiilor. Nu înțeleg de ce raportați o eroare.

QA: Este vorba de un scenariu neprevăzut la scrierea codului. Clientul a furnizat cazuri de utilizare care nu sunt gestionate în produsul actual.

Programator:  Înțeleg că sunt noi scenarii, dar nu ne-au fost comunicate la specificarea inițială.

QA: Sunt scenarii de utilizare furnizate de client, care trebuie integrate. Să discutăm cu echipa de business analisti.

Business Analyst: Înțeleg problema. Ce estimări avem pentru aceste modificări?

Programator: Estimăm 200 de ore de muncă. Trebuie să replanificăm proiectele.

Business Analyst: Înțeleg. Să găsim o soluție.

Răspunsul „funcționează conform specificațiilor”, poate supăra membrii echipei QA și uneori, clienții. Aceasta înseamnă că produsul respectă specificațiile, dar nu răspunde complet nevoilor clientului. Schimbările sunt posibile, dar trebuie luate în considerare costurile implicate: orele de muncă suplimentare și potențialul impact asupra altor părți ale sistemului, mai ales în cazul unui produs complex, cu multe componente și integrări, utilizatori globali și zero toleranță pentru întreruperi.

Modificările necesare sunt posibile, dar sunt asociate cu costuri. Se pot necesita ore suplimentare și efecte secundare asupra altor funcționalități. Acest lucru este evident în cazul unui produs complex, cu date ample, clienți globali, și operațiuni cu timp critic, aşa cum avem la Cognyte.

Este crucial să evaluăm aceste aspecte.

Important de menționat este că nu este un joc de acuzații. Dacă echipa QA identifică o eroare, aceasta se face în colaborare cu echipa de programatori. În cazurile mai complexe, echipa de business analisti este implicată.

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

Orice modificare are un cost, uneori greu de estimat. Doar persoanele cu o înțelegere completă a sistemului pot estima corect costul. Chiar și în aceste cazuri, estimarea nu este garantată. În cele din urmă, deciziile de implementare sunt guvernate de priorități, business analiștii și managementul de proiect. În situații speciale, deciziile pot ajunge chiar la nivelul conducerii superioare. Înainte de orice decizie, se inițiază o discuție deschisă pentru a lua o decizie benefică pe termen lung, pentru toți clienții.

O astfel de discuție poate concluziona cu rezolvarea noului cerință ca bug fix, sau cu clasificarea ei ca o limitare a versiunii actuale, pentru o implementare ulterioară.

O strategie suplimentară este să definim planul de verificare, convenit cu echipa QA, înainte de scrierea codului. Aceasta clarifică așteptările și ajută la crearea unui cod corect, conform cerințelor funcționale.

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

Produsele noastre sunt complexe și actualizările pot fi trimestriale, semestriale sau chiar mai rare. Chiar și actualizarea unui produs On-Premise este un proces întins. Cu toate acestea, clienții trimit cereri noi încontinuu. Pentru a gestiona această solicitare, am creat un departament de Servicii, cu o echipă dedicată corecțiilor rapide și actualizărilor punctuale.

Uneori, echipa de produs dorește modificări mici, care să nu necesite procesele complexe de aprobare și planificare. Discuția poate suna astfel:

Product Owner: Modificarea este mică, și clientul trebuie să evite o așteptare de șase luni.
Programator: O modificare mică poate afecta multe componente și necesită o evaluare amănunțită.
Product Owner: Deci clientul așteaptă șase luni?
Programator: Probabil, dacă nu sunt alte priorități mai urgente.
Product Owner: Discut cu clientul și analizăm situația.

În startup-uri sau companii mici, aceste situații nu apar la fel de frecvent. Dar în organizații mari, cu multe proiecte simultane, astfel de situatii sunt inevitabile.

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

Soluția constă în prioritizare și negociere acolo unde este necesar. Un compromis poate asigura un echilibru între necesitățile clientului și ale companiei.

3. Responsabilități în sisteme complexe

Fiecare funcționalitate este de obicei asociată cu o componentă sau un modul. Există însă cazuri în care o funcționalitate implică mai multe segmente. Cine este responsabil? Cum se gestionează întrebările și problemele?

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

Uneori, responsabilitatea este distribuită între mai multe echipe. În astfel de situații, o echipă este responsabilă pentru o funcționalitate, având totuși incertitudini. În lipsa unor „voluntari”, responsabilitatea este delegată uneori, ținându-se cont de criterii relevante.

4. Cartoful fierbinte

Uneori, specificațiile funcționalităților sunt incomplete sau prea abstracte. Acest lucru conduce la întrebări și interpretări diferite din partea dezvoltatorilor. Deși exagerat, uneori situațiile se pot petrece.

Oamenii sunt profesioniști, dar, în sisteme complexe dezvoltate de ani de zile, dificultăți pot apare atunci când sunt necesare informații complete.

Toate componentele au valoare și cele care doar scriu cod sau testează ar trebui să înțeleagă contextul funcționalităților, motivul implementării și valoarea adusă clientului. Acesta este un punct forte în evitarea confuziilor și erorilor viitoare. Specificații clare și motivația pentru fiecare cerință sunt importante în evitarea neînțelegerilor ulterioare.

Modificările sau limitele trebuie documentate clar. Documentăm aceste aspecte, în Jira, de exemplu.

Colaborarea, încrederea reciprocă și concentrarea pe beneficiul produsului sunt esențiale pentru a construi o echipă eficientă și pentru a gestiona eficient provocările.