ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 142
Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ 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.

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

▼ TOATE ARTICOLELE ▼

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects

INTERVIURI VIDEO