ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 24
Abonament PDF

Povestea unui Product Owner

Bogdan Giurgiu
Group Product Owner
@Endava
MANAGEMENT

Scopul acestui articol este de a clarifica rolul și responsabilitățile unui Product Owner*, după cum a fost observat și implementat în mediul software din Cluj de către autor. Subiectul este vast și nu poate fi acoperit în întregime într-un singur articol, dar aș dori să ofer unul dintre numeroasele puncte de vedere prin care subiectul poate fi abordat în interiorul fiecărei echipe și companii.

Rolul Product Owner-ului (PO)

Mai întâi de toate să pregătim scena și să clarificăm un lucru de la bun început: rolul Product Owner-ului este asociat metodologiei Scrum și ar trebui să existe într-un mediu Agile sănătos. Este adevărat că fiecare companie este Agile în propriul său fel, iar acesta nu este un lucru rău. Diversitatea este bună atâta timp cât rămânem fideli principiului de bază "Inspectează și Adaptează". Dacă sunt de acord că oricine se poate auto-denumi Agile atâta timp cât respectă principiul de bază, cu Scrum este o poveste diferită. Fie aplici Scrum, fie ScrumBut. Este important să lămurim conexiunea directă dintre Scrum si rolul PO. În alte metodologii, responsabilitățile PO sunt de obicei împărțite între diferiți membri ai echipei, cum ar fi (dar fără a se limita la): managerul proiectului, managerul produsului, arhitect, etc. .

Aș dori să încep prin a-l cita pe Mike Cohn, unul dintre fondatorii Scrum-ului:

Product Owner-ul este de obicei un utilizator important al sistemului, sau cineva din marketing, managementul produsului sau oricine are o înțelegere solidă a utilizatorilor, a sectorului de piață, a competiției și a tendințelor viitoare din domeniu sau tipul de sistem care este dezvoltat.

Reținem ideea principală a acestui citat : existența unei paletă largi de potențiali candidați la acest rol. În rândurile următoare vom dedica o analiză acestui citat. Începem cu prima afirmație:

"Product Owner-ul este de obicei un utilizator important al sistemului... ."Am lucrat într-un scenariu similar, în care un utilizator principal al sistemului a preluat responsabilitățile asociate produsului. Acest utilizator principal avea viziunea și el a fost cel care a trasat direcția. Dar cum acest utilizator venea dintr-un domeniu care nu avea legătură cu industria IT și Scrum, a fost nevoie de ajutor adițional pentru a transpune viziunea într-un Product Backlog. Acest ajutor poate fi oferit în diverse forme. Într-un prim scenariu, cu condiția ca utilizatorul principal să aibă lățimea de bandă necesară și dorința de a-și asuma responsabilități în plus, acesta poate deveni Product Owner (după cum este descris în metodologia Scrum), cu instruirea profesională adecvată. Nu am văzut să se întâmple prea des acest lucru, deoarece, în cele mai multe cazuri, utilizatorul principal nu are lățimea de bandă sau dorința de a se muta în această poziție. De aceea, al doilea (și cel mai des întâlnit) scenariu este divizarea responsabilităților care vin cu acest rol în două, iar utilizatorul principal va deține viziunea și direcția, iar o persoană din echipa Scrum, un Product Owner delegat, va crea și va deține Product Backlog. Acest aranjament este ilustrat în Figura A de mai jos și este una dintre formulele în care am lucrat, jucând rolul Product Owner-ului delegat. Din propria experiență, am observat că utilizatorul principal care joacă rolul de "Product Owner" așa cum este ilustrat mai jos, nu deține bugetul pentru a-și realiza viziunea, și nici nu e interesat de întoarcerea investiției (Return of Investment) pentru produs. Din perspectiva cuiva care nu investește direct bani în produs, dar resimte impactul direct al noii funcționalități, returnarea investiției este întotdeauna pozitivă. În acest scenariu, un alt jucător va intra în arenă și va lua responsabilitatea administrării bugetului. În funcție de companie și politica sa, această persoană poate fi un manager de proiect sau un manager de resurse.

Figura A: Clientul sau Utilizatorul Principal drept Product Owner

Scenariul de mai sus are o valența diferită atunci când un Client preia rolul de Product Owner. Similar cu situația de mai sus, în majoritatea cazurilor acest Product Owner va lucra cu un Product Owner delegat, care este responsabil cu crearea Product Backlog-ului. Schimbarea constă în deținerea bugetului, deoarece acest Product Owner va fi interesat direct de ROI, din cauză că banii investiți în produs provin din buzunarele sale.

Să trecem mai departe cu analizarea afirmației "Product Owner-ul este … cineva din marketing, managementul produsului…". Convingerea mea puternică este că Departamentul de Marketing al unei companii ar trebui să aibă una dintre cele mai creative echipe. Ei trebuie să fie în fruntea afacerii și trebuie să aibă acea "înțelegere profundă a sectorului de piață și a competiției." În mediul în care am lucrat, Marketingul avea o colaborare strânsă cu echipa de Produs. Ideile care erau uneori generate în interiorul departamentului creativ de marketing erau de obicei digerate și transformate în interiorul echipei de Produs. Acesta este un alt scenariu obișnuit pe care l-am întâlnit, în care cineva din echipa de Produs, în cele mai multe cazuri un Manager de Produs, va deține produsul. În această organizare, persoana care joacă rolul Managerului de Produs trebuie să aibă cunoștințele necesare și lățimea de bandă pentru a juca și rolul de Product Owner. Acesta este scenariul perfect, într-adevăr, în care Product Owner-ul deține viziunea, creează backlog-ul și are și bugetul pentru realizarea viziunii. Această organizare este reprezentată în figura B de mai jos, iar eu am creat produse și din acest rol. Este un rol antrenant care îți dă o mare putere, căci ești direct răspunzător de ROI pentru fiecare caracteristică și eu a trebuit să pun în balanță funcționalitatea furnizată cu bugetul investit. În această organizare, putem afirma categoric că Product Owner-ul este dedicat produsului și echipei, pe toate nivelurile.

Figura B: Reprezentantul Echipei de Produs drept Product Owner

Până acum am analizat diferite situații în care Product Owner-ul se poate regăsi, dar și o gamă largă de persoane care pot ocupa acest rol. Acum că am identificat câteva dintre responsabilități, vom săpa mai adânc în această zonă. Aș vrea să pun accentul pe cele prezentate mai jos, chiar dacă spectrul responsabilităților poate (și de obicei așa se întâmplă) să includă alte activități.

Responsabilități ale Prodcut Owner-ului

Product Owner-ul trebuie să reprezinte și să supravegheze interesul părților implicate. Această colaborare este crucială pentru succesul produsului. Comunicarea dintre beneficiarii produsului, PO și echipă este permanentă și are drept obiectiv clar menținerea implicarii tuturor față de produs și asigurarea unui feedback constant la toate nivelurile.

O altă responsabilitate importantă este aceea de a crea și de a "dichisi" în mod continuu Product Backlog-ul. În această activitate, Product Owner-ul ar trebui să caute ajutor de la Echipa Scrum. Odată ce viziunea a fost comunicată Echipei și unele funcționalități cheie au fost identificate, Echipa poate ajuta la cristalizarea Product Backlog-ului, care este mai detaliat decât viziunea. Mie personal mi s-a întâmplat asta la începutul călătoriei, în timpul unui Sprint Zero și în mod constant pe parcursul vieții produsului în timpul sesiunilor de planificare al unui release. În timpul acestor sesiuni, detaliile fine sunt identificate sub formă de User Stories** care vor fi supuse unui proces de definire a priorității, condus din nou de Product Owner.

Aș dori să subliniez un aspect important: trebuie să existe o relație simbiotică între PO și Echipă. Unul nu poate exista fără celălalt, iar prin această simbioză, ambele părți implicate ar trebui să prospere. Mediul este un factor cheie pentru ca această simbioză să existe. Ce ar trebui să ofere mediul pentru a încuraja această relație? Personal, cred că un mediu sănătos trebuie să hrănească creativitatea și inovația mai întâi de toate. Mediul în care oamenilor li se dă putere și sunt încurajați să vină cu idei și soluții, este mediul în care se vor întâmpla lucruri benefice. Product Owner-ul are responsabilitatea de a crea și îngriji acest mediu, deoarece produsul său va fi direct afectat de gradul de motivare a echipei.Rolul unui lider într-o echipă poate fi jucat de mai multe persoane, dar este crucial pentru succesul produsului să existe un lider puternic în persoana Product Owner-ului.

Dar cum poate cineva să motiveze o echipă? Personal, cred că cel mai bun răspuns este: prin pasiune. Un Product Owner trebuie să fie pasionat de domeniul și de linia de afacere pe care încearcă să le acopere. Dacă faci ceva din pasiune, va fi natural să rămâi pe primul loc în acest joc și să fii la curent cu piața, competiția și cu toate noutățile legate de domeniul respectiv. Dacă cineva își îndeplinește sarcinile cu pasiune, aceasta nu va mai fi o doar slujbă de la 9 la 6, în fond nu va mai fi o slujbă … va fi un hobby, ceva ce faci din pasiune. Dacă PO are această pasiune pentru domeniu, ea va fi contagioasă în interiorul echipei și, fără îndoială, va motiva pe fiecare membru în parte. Jack Welch, fost președinte și CEO al GE, sintetizează acest lucru foarte bine în următoarea afirmație:

"Liderii de afaceri buni creează o viziune, articulează viziunea, dețin cu pasiune viziunea și o conduc neîncetat spre împlinire".

O altă caracteristică esențială a unui bun Product Owner este competența sa în crearea unei experiențe unice pentru utilizator (UX). El sau ea nu va trebui să ofere soluții UX din acest rol de Product Owner, dar ar fi grozav ca să fie capabil(ă) să ofere ceva mai mult decât o viziune și un backlog. Backlog-ul produsului este în esență un set de funcționalități și, nu mă înțelegeți greșit, acestea sunt esențiale pentru succesul produsului, dar felul în care "ambalezi" aceste funcționalități și le prezinți utilizatorului joacă, de asemenea, un rol crucial. Să analizăm exemplul clasic al iPhone-ului și competitorii din fruntea mediului Android. Dispozitivele Android pot cu ușurință să se ridice la funcționalitatea unui iPhone, în hardware și software, dar diferența principală de astăzi constă în experiența utilizatorului, care a devenit un criteriu de vânzare major, cheie, pentru Apple. A devenit extrem de important ca Product Owner-ul să fie capabil să lucreze cu un expert UX pentru a defini mai bine partea de experiență pentru utilizator.

În concluzie, eu îmi imaginez Product Owner-ul ca fiind un lider pasionat, cu o foarte bună cunoaștere a domeniului, a afacerii și cu suficiente cunoștințe Scrum pentru a face lucrurile să meargă bine, o combinație care s-ar putea să nu fie atât de ușor de găsit…

Pentru a afla mai multe despre acest rol, apelați la adresa: careers.endava.com/ProductOwnerTraining.

* Product Owner - Cel care deține responsabilitatea pentru un produs.

** User Stories - Un format standard de definire a funcționalităților pentru a fi incluse în Product Backlog.

LANSAREA NUMĂRULUI 89

Prezentări articole și
Panel: Programming

Joi, 21 Noiembrie, ora 18:00
Liberty Technology Park

Înregistrează-te

Facebook Meetup

În aceeaşi ediţie ... (24)

▼ TOATE ARTICOLELE ▼

Sponsori

  • comply advantage
  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects