Ce înseamnă să fii Product Owner?

Salut! Eu sunt Emilia și sunt Product Owner de, aproximativ, cinci ani. Sunt, o persoană ambițioasă și comunicativă și mi-am întărit de-a lungul timpului convingerea că, cel puțin din punct de vedere profesional, putem face orice ne propunem, câtă vreme suntem  dispuși să investim timp pentru a învăța. Dacă vrei să fii dezvoltator și tocmai ai absolvit Facultatea de Istorie, nu te crampona de asta. Cât timp ești pasionat și ești dispus să înveți, poți ajunge acolo. Eu, de exemplu, am ajuns să mă ocup de proiecte tehnice,  deși nu am un background tehnic, pentru că am fost curioasă, mi se părea foarte cool ce făceau oamenii din jurul meu și  am vrut să înțeleg din ce în ce mai mult, până când am ajuns în punctul în care am înțeles cel mai important lucru – mi-am dat seama că îmi plăcea ceea ce făceam și simțeam că evoluez.   

Am avut diferite roluri până să ajung aici. Am lucrat în vânzări, am cochetat cu marketing și resurse umane, după care am ajuns într-o companie, care la vremea respectivă, îți dădea posibilitatea să înveți de toate. Până sa devin “product passionate”, am făcut suport tehnic și project management pentru proiecte de dezvoltare de software. Din fiecare am încercat să învăț cât de mult am putut și consider că m-au propulsat puțin câte puțin până în punctul în care mi-am dat seama ce-mi place cel mai mult

Titlurile de Product Owner/Product Manager sună, atunci când le auzi pentru prima dată, pompos și totodată ambiguu. E foarte dificil să înțelegem ce presupune rolul de Product Owner dacă ne raportăm la sensul propriu al sintagmei.

În cele mai multe domenii de activitate și, cu precadere în Software Development, a devenit foarte în vogă să se lucreze după modele Agile.

Primul pas, pentru a înțelege ce înseamnă să fii Product Owner, este acela de a da un sens ideii pe care vrem să o aducem la viață, analizând, etapă cu etapă, unde vrem să ajungem, care este produsul pe care vrem să-l dezvoltăm, cu alte cuvinte, care este viziunea și cea mai bună strategie pentru a ajunge unde ne dorim.

În al doilea rând, trebuie să  înțelegem ce presupune Agile și modelele acesteia de lucru, pentru că de-aici vine, de fapt, numele de Product Owner.  

Ce este Agile?

Pornind de la sensul de bază al cuvântului, agile e ceva ce ne permite să facem lucrurile ușor și rapid și caracteristica cea mai importantă a acestei metode este adaptabilitatea. În realitatea profesională, Agile este o metodologie de lucru și are mai multe practici sau modele de lucru, dintre care cele mai folosite sunt SCRUM și KANBAN.

Cel mai comun model Agile utilizat în IT este SCRUM, un framework ușor de înțeles și dificil de implementat, după cum spun și autorii lui.  

Este folosit, în general, pentru implementarea unor proiecte complexe lăsând loc pentru creativitate și schimbare.

SCRUM are la baza niște valori, niște reguli simple și o echipă compusă din trei roluri: echipa de dezvoltare, un Scrum Master și un Product Owner.

Tot ce aveți nevoie să știți despre SCRUM se regăsește în Scrum Guide, o lectură de aproximativ douăzeci de minute, super utilă.

Ce înseamnă să fii Product Owner și cum poți să ajungi acolo?

Cel mai important lucru, în acest rol, este acela de a cunoaște foarte bine produsul. Fie că începem un proiect de la zero, fie că dezvoltăm ceva ce exista deja, trebuie să știm ce vrem să facem și, cel mai important, unde vrem să ajungem.

Cea mai rapidă și sigură variantă pentru a învăța o aplicație sau un produs, de orice fel, este aceea de a oferi suport pentru utilizatorii acestuia, deoarece, făcând asta, suntem puși în cele mai complicate și neașteptate situații sau moduri în care produsul este folosit.  Asta ne ajută să înțelegem atât funcționalitățile cât și felul în care a fost implementat. Rolul de PO presupune să dobândești, în egală măsură, cunoștințe de business și tehnice.

Un alt aspect, la fel de important, este să învățăm cum se implementează un proiect, care sunt etapele acestuia, și mai ales ciclul de dezvoltare, de la implementare, testare până când ajunge în mâinile utilizatorului.

Sigur, sunt și situații în care putem ajunge direct în rolul de PO, prin programe de internship sau de mentorat, și putem învăța toate acestea făcând jobul zi de zi.

Indiferent cum ajungem acolo, ca Product Owneri, responsabili de ceea ce livrăm și de maximizarea valorii produsului pe care îl dezvoltăm, trebuie să avem mereu, în prim plan, nevoia utilizatorului, să înțelegem cum folosește produsul pe care îl punem la dispoziție, ce putem face în așa fel încât să-i facilităm munca, ce putem să-i oferim în așa fel încât să-i sporim încrederea în produs și cum putem să fim competitivi și să atragem cât mai mulți clienți.

Totodată, e important să dezvoltăm o relație constructivă cu echipa SCRUM dar și cu utilizatorii, deoarece PO-ul este acela care traduce nevoia clientului echipei care implementează. El este cel care decide ordinea în care se dezvoltă produsul, bazându-se pe stategia de maximizare a valorii acestuia în timp ce optimizează munca echipei.

Product Ownerul exprimă clar ce urmează să fie implementat, până la nivelul la care fiecare membru al echipei a ințeles ce trebuie să facă și tot el este cel care ia feedback de la client, asigurându-se că rezultatul este cel dorit.

Deciziile Product Ownerului sunt reflectate de felul în care task-urile la care se lucrează sunt ordonate și pentru ca el să aibă succes, întreaga organizație trebuie să le respecte.

Sunt oameni care spun că rolul de PO este și ușor și greu, dar mai ales, cool. Experiența de până acum mi-a demonstrat asta. Cel mai cool este că, făcând rolul acesta, putem dobandi foarte multe abilități care ne pot deschide oportunități viitoare diverse.

Tips and Tricks pentru POs

  • Asigurați-vă că echipa SCRUM din care faceți parte are toate rolurile în structura sa și că fiecare membru își ințelege rolul și modul de lucru din cadrul echipei și organizației.
  • Conturați viziunea produsului.
  • Setați așteptări corecte clientului.
  • Găsiți-vă aliați care să vă ajute să puneți la cale o strategie bună pentru a vă îndeplini obiectivele.
  • Colaborați în permanență cu toți stakeholderii și fiți mereu disponibili pentru a răspunde întrebărilor echipei de dezvoltare.
  • Nu vă lăsați intimidați de acronime precum MVP, SP, MD, RFC sau de cuvinte mistice precum roadmap, backlog, acceptance criteria, user stories. Pe acestea din urmă, va trebui sa le scrieți voi pe atât de autentic și de clar pe cât vreți să fie transpuse în cod, dar toate se învață on a daily basis.
  • Nu vă panicați după primele discuții cu echipele tehnice care, deși par că vorbesc “birds language”  la o primă audiție, sunt, de regulă, very nice and smart guys de la care aveți multe de învățat.

Distribuie articolul pe: