Voiam să fac un articol despre eficiența Responsabilul de Produs (Product Owner) și mi-am dat seama că încă nu am scris pe blog despre obligațiile acestui rol.
Care sunt obligațiile Responsabilului de Produs?
Rolul Responsabilului de Produs nu are tradiție, și-i percepem importanța diferit în funcție de gradul de experiență cu Scrum. Sper ca articolul de mai jos să clarifice obligațiile acestui rol și să lumineze drumul echipelor Scrum în permanenta și umana lor luptă pentru control.
1. Satisfacția clientului
Pornind de la pe cine servește Responsabilul de Produs, putem afirma că Responsabilul de Produs trebuie să vegheze asupra satisfacției persoanei sau grupului de persoane care l-a(u) împuternicit. Din motive de ergonomie am preferat satisfacția clientului în loc de satisfacția persoanei sau a grupului de persoane care l-a(u) împuternicit.
Tototdată, am fost nevoit să aleg între Responsabil cu satisfacția clientului și Responsabil cu reprezentarea intereselor clientului. Inițial, mai toți Responsabilii de Produs pornesc ca mandatari ai clientului. Adică, sunt împuterniciți să facă ce vor, dar execută întocmai. Însă, pe măsură ce își exersează rolul,acesta-și face amprenta din ce în ce mai vizibilă, clientul îndepărtându-se de aspectele fine ale produsului.
Astfel, în trunchiului de piramidă alăturat, satisfacția clientului, indiferent cum se măsoară și de ce este determinată, se află în capul obligațiilor.
2. Definirea produsului
2.1. Viziunea produsului
Adesea, pielea Responsabilului de Produs este purtată de oameni cu experiență în operațiuni. Dacă vorbim de refacerea unei noi versiuni, de obicei este un vechi utilizator. Dacă vorbim de un nou produs care ar trebui să faciliteze munca unei categorii de operatori de calculator, foarte probabil că din aceste rânduri se va alege și Responsabilul de Produs. În firmele mari, cu departament de IT, se preferă analiști sau foști șefi de proiect.
Nu sunt nici antreprenori, nici administratori, nici lideri, nici specialiști de marketing. Este prea ușor să se supună influențelor externe și să nici nu-și marchezi viziunea în vreun fel cu ideile proprii. Aici se vede experiența unui Responsabil de Produs.
De câțiva ani sunt foarte activ în achiziția de clienți outsourcing. Am văzut sute de clienți. Rar să se fi gândit la viziunea produs, iar cei care o fac de obicei sunt startup-uri și-au fost nevoiți să aibă o viziune în călătoria lor de capital. Rolul de Responsabil de Produs este inexistent, iar viziunea are multe lacune.
După ce am descoperit Lean Startup, trimit sistematic clienții să completeze Business Model Canvas*. În timp, mi-am făcut propria-mi listă de întrebări cheie care-mi permite să articulez acele elemente din viziune pe care să fondez o strategie de proiect.
*Business Model Canvas este un exercițiu indispensabil când lucrăm la un produs sau serviciu nou accesibil publicului larg, însă ineficient pentru software intern sau noi versiuni.
2.2. Foaia de parcurs
De la viziune la produs, Responsabilul de Produs devine acel strateg care înșiruie evenimentele principale și indispensabile succesului și se pun premizele ciclului de viață al produsului: conferințe și evenimente, audituri, alfa, beta, întruniri importante, loturi de funcționalități și livrări, etc.
De notat! Orice produs software nou înseamnă înainte de toate o schimbare. Dacă literatura Scrum vorbește mult despre produsele care țintesc noi piețe sau utilizatori din afara companiei, despre managementul schimbării se face referire prea puțin. De exemplu, există posibilitatea ca noul produs să înlocuiască slujba cuiva? Sau, ce se întâmplă cu șeful IT care interpretează noua versiune ca o critică la ceea ce s-a construit inițial.
În scurt timp, foaia de parcurs ar trebui să devină o adevărată strategie de produs.
2.3. Conținutul produsului
De la viziune, foaia de parcurs și, foarte probabil, caietul de sarcini, se creează Backlog-ul de Produs. M-am obișnuit să văd caietul de sarcini (cerințele inițiale) cu mult înainte viziunii și surprinzător. Poate că așa este și normal. Cineva are o idee, apoi o rafinează într-o formă haotică de specificații, urmând ca abia apoi să se gândească la utilitate când încearcă să-i convingă pe ceilalți să i se susțină proiectul. Nefericirea vine când noul Responsabil de Produs n-are nici în clin nici în mâneca cu ce s-a făcut până la el/ea, dar aceasta este o altă poveste.
Indiferent care este sursa inițială de sugestii și cerințe, Responsabilul de Produs le așează și le ordonează în Backlog-ul de Produs. După ghidul Scrum, și pe bună dreptate, altfel faceți orice altceva, doar Scrum nu, Responsabilul de Produs este unica autoritate care răspunde pentru conținutul produsului. Bineînțeles că-și poate delega din sarcini, ori echipei de dezvoltare, ori unui asistent propriu în afara cadrului Scrum. Însă rămâne responsabil cu definirea corectă, abia suficient (just enough) și abia la timp (just in time) a așteptărilor.
Am citit despre User Story Mapping în cartea User Story Mapping: Discover the Whole Story, Build the Right Product. Această tehnică poate contribui masiv la inițializarea Backlog-ului de produs și la revizuirea viziunii și a foii de parcurs. Experiența mea rămâne limitată. Am folosit User Story Mapping la definirea ScriuCod nu la nu la creionarea unui produs.
3. Inspectarea produsului
3.1. Testarea
O regulă de aur spune că cine definește așteptările se și asigură că ceea ce a primit corespunde așteptărilor (principiul levierului). Prea des această responsabilitate este delegată complet unui „tester”. Chiar dacă acest lucru se întâmplă, tot Responsabilul de Produs răspunde cu dacă există un decalaj între așteptări și realitate.
3.2. Feedback
Revizuirea Sprintului este oportunitatea perfectă pentru a lui feedback și de la alți interlocutori, mai puțin implicați în cotidianul dezvoltării proiectului: viitori utilizatori, clienți, fondatori, etc.
Mi se pare important de menționat că există Responsabili de Produs care nu au nevoie de feedback de la alte persoane, le face rău și-i îndepărtează de la viziune. Așa este mitul lui Steve Jobs. Deși este foarte ciudat să mă așez în text foarte aproape de așa nume și sper să nu se interpreteze greșit, recunosc că și mie-mi place să lucrez singur și să-mi iau feedback altfel, mai degrabă din metode științifice specifice marketingului decât prin părerea subiectivă a câtorva utilizatori. Dar, într-un final, tot feedback se numește, iar orice Responsabil de Produs trebuie să se asigure că și-l primește devreme, înainte să-și fi cheltuit întregul buget și să nu mai poată adapta.
3.3. Adaptarea
Sună ca un curs despre procesele empirice. Astăzi, aproape toată lumea a auzit de ciclul PDCA, și PDSA. Totuși, în practică, chiar și Scrum-ul este anemic în multe aspecte de adaptare. Noroc că echipelor de dezvoltare le este ușor să se umfle în pene și să-i ceară Responsabilului de Produs să-și ajusteze definițiile. Dar adaptarea nu se rezumă la conținutul produsului și la ajustările specifice rafinării cerințelor. Întregul ciclu de viață, foaia de parcurs, acceptanța, ba chiar și viziunea necesită ajustări în funcție de ceea ce ne învață realitatea.
4. Proces
4.1. Ciclul de viață al produsului
Atât timp cât există produsul există și Responsabilul de Produs cu Backlog său. Responsabil cu noile direcții pe care produsul le va lua prin stadiile ciclului de viață, rămâne Responsabilul de Produs. Din păcate, de cele mai multe ori, la scurt timp după dezvoltare, în ochii managementului produsul trebuie să treacă într-un fel de mentenanță, când abia dacă se poate spune că acesta a luat viață.
4.2. Respectarea procesului
Indiferent de noile elemente adăugate peste cadrul Scrum, Responsabilul de Produs trebuie să respecte procesul așa cum este el definit.
4.3. Acceptanța
Indispensabilă când facem outsourcing, chiar dacă acceptanța nu poartă neapărat o denumire atât de pompoasă. Putem să ne referim la acceptanță ca la acel proces generic în care utilizatorii și piața adoptă produsul, timp în care echipa de dezvoltare trebuie să rămână activă/disponibilă. Acesta este unul din motivele pentru care acceptanța nu ar trebui să fie îndepărtată prea mult de livrările intermediare, finalul fiecărui sprint. Personal, cer ca Responsabilul de Produs să se asigure că dă feedback despre întreg conținutul sprintului livrat la o distanță mai scurtă sau egală cu durata sprintului de dezvoltare.
4.4. Decizia de a livra
Fiecare sprint este un exercițiu de livrare, vezi istoria Scrum și aterizarea proiectului. Rolul de Responsabil de Produs vine la pachet cu decizia de a merge în producție(life) sau nu și doar persoana în acest rol poate lua această decizie.
Mituri despre perimetrul Responsabilului de Produs
Reponsabilul de Produs are mână liberă pe buget
Există mai multe mituri despre Responsabilul de Produs. Unul dintre acestea este bugetul produsului. De cele mai multe ori bugetul nu este ceva ce Responsabilul de Produs poate schimba. Bugetul vine laolaltă cu obiectivul de a obține un maxim de utilitate în constrângerile date, fie ele de buget, de timp sau orice altceva.
Responsabilul de Produs este un dictator
Un alt mit, și aici mă opresc, constă în puterea absolută a Responsabilul de Produs asupra produsului. Trăim într-o lume în care toată lumea este influențată de toată lumea. La fel, și Responsabilul de Produs își vinde viziunea, convinge investitorii să mai investească sau să meargă alături de el, poate fi destituit, etc. Da! Reponsabilul de Produs are decizia de a face ce vrea cu produsul. Însă, nu cred că va fi de mare succes dacă neglijează nevoile clienților săi sau a celor care i-au acordat încrederea. De altfel, Responsabilul de Produs este foarte des pus în postura de a-și apăra deciziile și de a negocia termeni specifici lumii complexe în care trăim. Acesta este un rol dificil.
Obligațiile Responsabilului de Produs (Product Owner)
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 5937 ori