Câți dintre voi vă mai amintiți, din perioada în care erați copii, ce vă doreați să deveniți când veți fi mari? Când mamele noastre sau profesorii noștri ne întrebau: "Ce vrei să te faci când vei fi mare?" Poate unii dintre noi și-au dorit să devină piloți și să zboare peste tot în lume. Alții visam să fim bucătari și să pregătim mâncare pentru cei dragi. Sau poate ne doream să fim ca Neil Armstrong și să ajungem pe Lună. Cu siguranță, fetele și-au dorit să devină balerine, dansatoare, actrițe, exploratoare, visând să devină celebre. Ce vremuri, nu-i așa? Câți dintre voi ați dorit să deveniți QA, programatori, arhitecți software, BA sau PO?
Eram în clasa a 8-a, mă pregăteam pentru examenul de admitere și i-am spus mamei: "Vreau să devin make-up artist sau coafeză", iar ea mi-a spus: "Cum? Tu știi ce greu este să stai în picioare toată ziua și să te doară picioarele? Nu! Trebuie să mergi la Liceul de Informatică și să faci o muncă de birou, trebuie să te gândești la sănătatea ta…" Da, mulțumesc, mamă ... nu e ca și cum azi nu ne-am plânge mulți dintre noi de dureri de spate sau alte probleme de sănătate. Dar acesta ar fi un alt subiect de discuție.
Când eram copii, aceste meserii nu erau comune: QA, Programator, Arhitect Software. Ce să mai vorbim de Business Analyst sau Product Owner (PO)!
Câți dintre noi au avut BA sau PO în echipă acum cinci sau zece ani? Câți dintre noi au un BA sau un PO în echipă azi? Cu siguranță, acum, numărul acestor roluri este mult mai mare decât acum cinci sau zece ani.
Să facem un exercițiu de imaginație! Ce se întâmplă dacă nu ai un BA sau un PO care să scrie US (user stories) în echipă? Cine scrie criteriile de acceptabilitate? Cine documentează toate solicitările de a modifica aplicația? Cine vorbește cu clientul sau cu factorii decizionali?
În trecut (2000-2010), modul în care se dezvolta și se lucra la un produs era următorul. Cineva venea cu o idee. De obicei, ideea venea din partea managementului sau de la client sub forma câtorva propoziții, apoi toți membrii echipei contribuiau la acea construcție de idei. Programatorii trebuiau să decidă dacă ideea este fezabilă și să vină cu o soluție tehnică. Cei din rolurile de QA trebuiau să facă mai multe drumuri între programatori și manageri pentru a înțelege ce trebuia testat, dacă sistemul funcționa, dacă ceea ce s-a implementat este exact ceea ce își dorise managerul. Unele lucruri nu erau chiar clare. Trebuia prezentată implementarea persoanei care avusese ideea, ulterior solicitat feedback, pentru ca mai apoi să se ajungă tot la programatori cu noi solicitări de a schimba implementarea, care nu era completă sau, și mai rău, era ceea ce își imaginase managerul ...
Dar aveam timp să le facem pe toate. Aceste idei (care nu erau atât de mari) se implementau în 3, 6 sau chiar 9 luni. Proiectele mari aveau nevoie de câțiva ani. Se făcea release o dată sau de două ori pe an.
De ce nu facem același lucru și azi? Pentru că totul s-a schimbat, de la tehnologie la modul în care gândim, la răbdarea pe care o avem. Totul se desfășoară pe repede înainte. De câte ori nu am fost frustrați că aplicația este prea lentă, că pagina web nu răspunde suficient de repede? De câte ori apăsăm butonul Refresh în speranța că totul se va rezolva.
Toate acestea au avut consecințe și asupra mediului de business. Dacă nu ne mișcăm suficient de repede, pierdem trenul. Dacă nu implementăm ideea suficient de repede, cineva cu aceeași idee o va face disponibilă pe piață înaintea ta.
Așadar, ce s-a întâmplat mai precis? A apărut rolul de PO. ( Să fim sinceri, cine știa de rolul de PO acum cinci sau șase ani?) A apărut o nevoie, nevoia de a mișca lucrurile într-un ritm mai alert, de a da echipei informația de care are nevoie mai repede pentru ca echipa să finalizeze, bineînțeles, munca mai repede.
Rolul de PO sau cel de BA (deoarece uneori aceste roluri se suprapun) este ocupat de persoana care vorbește cu clientul, pregătește specificațiile în mai mult de două propoziții, scrie condițiile de acceptabilitate, stabilește priorități, monitorizează modul în care se efectuează modificările care au impact asupra planului inițial. Este mediatorul dintre client și echipă. Dacă acum zece ani, acest rol era împărțit printre sarcinile de lucru ale altor membri ai echipei sau era asumat de client, acum acesta aparține unei singure persoane din echipă.
De cele mai multe ori, clientul vine cu ideea, întrucât cunoaște care este obiectivul pe care dorește să îl atingă, dar nu știe cum poate să îl materializeze. Responsabilitatea unui PO este de a clarifica și de a înțelege ce dorește clientul și care sunt lucrurile de care are nevoie. Apoi, un PO trebuie să ghideze clientul, să îl consilieze, să îi ofere opțiuni, să prezinte argumente pro și contra. Bineînțeles, clientul va avea ultimul cuvânt și va face alegerile care i se potrivesc, dar sarcina unui PO este de a ajuta clientul și de a-l asista în deciziile sale.
Pentru a face toate acestea, un PO are nevoie de ajutor. Dar să fim realiști, un PO nu este un zeu, nu știe totul și mai mult nu el este cel care implementează proiectul. Un PO colaborează îndeaproape cu UI/UX, dar și cu arhitectul sau coordonatorul tehnic. Rolul UI/UX este de a crea o experiență de utilizare cât mai plăcută. Arhitectul va spune ce e fezabil și va veni cu soluția tehnica. În paralel, se va alcătui backlogul pentru echipa de dezvoltare, astfel încât să existe cât mai puține neclarități, iar programatorii să aibă user stories pregătite la începutul sprintului pentru a-l putea implementa.
Așadar, este rolul PO o necesitate? Cu siguranță, da.
de Péter Török
