Celor într-o poziție similară cu a mea le recomand să învețe să aprecieze provocările rolului de Product Owner și le garantez că acestea nu vor face decât să îi ajute să devină Product Manageri mai buni.

Primele user story-uri pe care le-am scris și habar nu aveam că așa se numesc

Ce se întâmplă când ai în față o oportunitate de maximă importanță, trebuie să acționezi rapid pentru a fi primul care iese în piață și totuși metodologia de implementare folosită în companie este clasicul Waterfall? Se întâmpla în anul 2014.
Modul în care un proiect prindea viață și era lansat implica, la acel moment, un Product Manager care strângea toate informațiile și cerințele proiectului într-o documentație stufoasă, care ajungea în primă fază la echipa de Marketing. Marketing-ul crea toate design-urile necesare pentru promovare, mock-up-urile și textele folosite. Când toate acestea erau gata, documentația ajungea la un Project Manager, în mâinile căruia rămânea tot restul procesului de implementare propriu-zisă.
Când totul era considerat terminat, QA-ul începea testarea finală înainte de lansare. Waterfall clasic. Doar că la acel moment, realizând oportunitatea pe care o aveam în față și nu trebuia să o scăpam, am înțeles că pur și simplu nu pot pierde timp scriind aceea documentație. Luni dimineață, la prima oră, am început ziua trimițând un email simplu către toate persoanele ce urmau să fie implicate în proiect, cu o listă de 10 cerințe minime („must-have”-urile) care trebuiau să fie făcute pentru a lansa cât mai repede.
Cerințele erau scrise într-un mod sumar: „The customer needs to be able to…”. Acestea au fost primele User Story-uri pe care le-am scris și primul MVP (Minimum Viable Product) pe care l-am definit – doar că în acel moment nu aveam habar că așa se numesc.

A fi Agile cu adevărat se poate învăța după 2 zile de training și din ce citești în cărți? Total greșit

La începutul anului 2015, HEG a început tranziția de la Waterfall la Agile, alegând Scrum ca metodologie de implementare a stilului Agile. Programatorii au fost împărțiți în echipe de Scrum care urmau să includă și un tester, nevoia de Project Manageri a dispărut –în schimb apărând în peisaj un rol nou, cel de Scrum Master. După mai bine de doi ani ca și Product Manager, deveneam în cele din urmă și Product Owner pentru două dintre echipele de Scrum nou formate.
Nu vă păcăliți crezând că a fi Product Owner va fi ușor având în vedere experiența din spate ca Product Man- ager. A scrie User Story-uri e la fel de ușor ca a scrie documentații de proiect, a colabora cu echipa de Scrum e la fel de ușor ca a trimite documentația unui Proj- ect Manager, a fi Agile cu adevărat se poate învăța după 2 zile de training și din ce citești în cărți? Total greșit – a fi Product Owner a însemnat de fapt un set total nou de provocări, unele cu care nu m-am confruntat înainte în rolul de Product Manager. Câteva dintre lecțiile cele mai importante pe care le-am învățat în ul- timele 9 luni sunt:
1. Nu trata User Story-urile ca bucăți mai mici ale documentațiilor de proiect
Una din primele lecții învățate la începutul carierei în Product Management a fost că o documentație de proiect trebuie să conțină toate feature-urile dorite pentru că în caz contrar, nimic nu se mai putea adăuga sau schimba în faza de producție. De la proiect la proiect, evaluam ce a fost uitat, unde au fost neclaritățile, unde interveneau schimbările cel mai des în idea de a nu uita și data viitoare când scriam o documentație. Astfel, documentele deveneau din ce în ce mai stufoase (recordul meu personal e undeva la 30-40 de pagini), și era din ce în ce mai greu să distingi ce era cu adevărat important, în goana de a scrie o documentație cât mai completă.
Formatul clasic al unui User Story e simplu: „As a [persona/role], I want to [do this], so that [I get this benefit].” Dacă începi prin a„rupe” o documentație în bucăți mai mici și pur și simplu a le rescrie pentru a se potrivi formatului unui User Story, imediat o să îți dai seama că e aproape imposibil. A defini un rol nu este simplu, și dacă toate User Story-urile tale încep cu„As a user”, poate ar trebui să le reevaluezi. User Story-urile, spre deosebire de cerințele punctuale ale unui proiect, definesc problema și beneficiul în a o rezolva, nu soluția. Documentațiile lasă prea puțin loc pentru creativitatea necesară rezolvării problemelor. Într-o anumită măsură, ele limitează implicarea echipei de implementare în găsirea celei mai bune soluții posibile. Tratați User Story-urile ca o invitație la discuție și veți fi surprinși de rezultate.
2. Fă legătura între„ce” și„de ce” – dar lasă echipa să decidă „cum”
Business Case. Un termen foarte cunoscut nouă, Product Managerilor. Practic, o analiză completă asupra beneficiilor aduse de implementarea unei idei noi sau a unui proiect, a costurilor asociate, ale metricilor succesului, ale pieței și a competitorilor. Un document necesar, mai mult sau mai puțin stufos ca mărime, care obligatoriu conține și câteva diagrame în Excel.
Iată însă adevărul dur: echipei tale de Scrum nu îi pasă de buget, de vânzări, de profit, de costuri, de cote de piață sau de proiecții financiare. Așa că nu încerca să justifici un proiect printr-o invitație de a citi un Business Case – pentru că da, ai ghicit, nimeni nu îl va citi.
Echipei îi va păsa în schimb dacă înțelege cum face o diferență pentru utilizator și unde aparesi este adaugat valoare în experienta utilizatorului. Este responsabilitatea ta ca Product Owner de a comunica clar nu doar problema pe care vrem să o rezolvăm („CE”-ul), ci și de ce vrem să o rezolvăm („DE CE”-ul). Fără a înțelege cu adevărat „DE CE”-ul din spatele unei probleme, problema în sine și mai ales rezolvarea ei („CUM”) va fi lipsită de sens.
Întotdeauna specifica contextul în care apare problema și valoarea în a o rezolva dacă ți se pare greu să explici asta, e timpul să te întrebi dacă chiar merită să investești timp în a implementa acel ceva.
Prioritizarea va deveni și ea mai ușoară dacă vei încerca să faci de fiecare data asta. Lasă-ți apoi echipa să decidă „CUM” va rezolva problema. Și, după ce proiectul e lansat, adu-ți aminte să vii înapoi în mijlocul echipei și să le arăți impactul muncii lor.
3. Cum devii parte din echipă (sau cum îi faci pe programatori să te placă)
Ca Product Manager, ești obișnuit să interacționezi constant cu toate departamentele din companie de la echipa de marketing, la echipele de vânzări și suport, la departamentul de finanțe și departamentul juridic. Când vine vorba însă de echipele de programatori, de obicei totul trece printr-un Project Manager sau Development Manager, doar în rare ocazii ai oportunitatea să vorbești direct cu cei ce vor implementa efectiv proiectul tău.
În majoritatea companiilor de IT există în mod tradițional o divizare clară între rolurile orientate spre business și rolurile tehnice. Agile-ul este menit să schimbe acest aspect dar asta nu se întâmplă instantaneu. Este nevoie de timp până când Product Owner-ul este acceptat ca fiind cu adevărat parte din echipa de Scrum și, din punctul meu de vedere, aceasta este cea mai mare provocare a acestui rol. Comunicarea e cea mai importantă dar comunicarea fără încredere nu duce la nici un rezultat, iar încrederea se construiește în timp, deci nu te aștepta ca echipa să te urmeze orbește. Rolul de Product Owner nu aduce cu el autoritate în fața mem- brilor echipei – toți sunteți pe poziții egale și în primul rand Product Owner-ul trebuie să înțeleagă asta.
În poziția de Product Manager suntem puși adesea să ne gândim din perspectivă clientului. Adu această experiență cu tine și pune-te în locul echipei de fiecare dată când există un dezacord. Există tot timpul un motiv în spate străduiește-te să-l înțelegi. Ce vede acea persoană și tu poate nu vezi? S-ar putea să fii surprins. Ca Product Owner, e responsabilitatea ta să fii un sprijin pentru echipă, să fii întotdeauna disponibil când există întrebări sau nelămuriri, să faci tot ce îți stă în putință să îndepărtezi toate obstacolele și da, uneori să aduci cafea și gogoși (nu am întâlnit programator căruia să nu îi placă gogoșile până acum). Dar în afară de asta, pur și simplu trebuie să îți lași echipa să facă ce știu ei mai bine. Rolul tău este să permiți echipei tale să creeze valoare. Și numai când le vei demonstra asta celor din echipa ta, le vei câștiga încrederea și respectul.
4. Nu uita că ești încă Product Manager
E foarte ușor să fii prins în părțile de execuție a unui proiect atunci când ești Product Owner. Nu uita că rolul pe care îl deții este atât strategic, cât și tactic. Ce m-a ajutat foarte mult în ultimul an a fost să- mi setez timp special în fiecare săptămână pentru a fi numai Product Manager. Care sunt ultimele păreri ale clienților despre produsul tău? Ce au mai făcut competi- torii în ultima vreme? Care e evoluția proiectelor deja lansate? Ce probleme trebuie să rezolvăm pentru clienții nostril?
Fă-ți timp să răspunzi la aceste întrebări, prioritizarea unui Backlog și scrierea User Story-urilor nu sunt singurele tale responsabilități. Nu uită că atât strategia pe termen lung cât și livrarea pe termen scurt sunt la fel de importante și merită aceași atenție.

Am șansa să experimentez din ambele lumi

Multe companii din IT au la acest moment Product Manageri care îndeplinesc și rolul de Product Owneri – există numeroase articole care dezbat avantajele și dezavantajele acestei practici. Pentru mine, șansa de a fi și Product Owner a însemnat o oportunitate de creștere și de obținere a unei perspective noi față de ce învățasem anterior în rolul clasic de Product Manager. Practic, am șansa să experimentez ce e mai bun din ambele lumi, care, deși într-o anumită măsură diferite, au în cele din urmă același scop realizarea de produse pe care clienții să le iubească. Celor într-o poziție similară cu a mea le recomand să învețe să aprecieze provocările rolului de Product Owner și le garantez că acestea nu vor face decât să îi ajute să devină Product Manageri mai buni.