Ghid Scrum | 7. Cele mai frecvente greșeli ale Product Ownerului

În postarea de astăzi ne vom concentra asupra celor mai frecvente provocări cu care se confruntă proprietarii de produse. De asemenea, vă vom spune cum să vă pregătiți pentru situațiile în care aceste greșeli ale Product Ownerului apar cel mai des.

Greșeli ale proprietarului produsului – cuprins:

1. Ce poate merge prost între proprietarul produsului și client
2. Provocări cu care se confruntă Product Ownerul cu privire la restul echipei Scrum
3. rezumat

Ce poate merge prost între proprietarul produsului și client

Product Owner este persoana care este personal responsabilă pentru eșecurile echipei Scrum. Din cauza acestei poziții dincolo de activitățile echipei, se consideră că Product Owner este singurul gât care poate fi strâns . Cu alte cuvinte, Product Owner este cel care suferă cel mai mult atunci când echipa Scrum merge prost. Deci, cum să faceți față situațiilor supărătoare atunci când apar sau, mai bine, cum să le împiedicați să se întâmple în primul rând?

Pentru a răspunde la acest punct, am oferit o analiză clară și aprofundată a unor greșeli majore ale proprietarilor de produse și ale clienților în tabelul următor, împreună cu o discuție detaliată a fiecăreia.

Incapacitatea de a stabili priorități

Greșeala de a nu ști cum să prioritizeze este nenorocirea multor Product Owners. De ce este prioritizarea sarcinilor o competență de bază? Pentru că atunci când totul devine la fel de important, obiectivul de produs dispare. Acesta este efectul dorit al activității echipei Scrum.

Problema începe deja în timpul primelor conversații cu clienții despre Obiectivul Produsului. Clientul dorește de obicei ca toate ideile sale să fie realizate cât mai repede și mai ieftin posibil. Sarcina Product Ownerului este de a stabili o listă de priorități. Sarcina lui este de a crea o listă de așteptări clare și fezabile, clasificate de la cele mai importante la cele mai puțin importante, pe baza așteptărilor nestructurate ale clienților.

Problema cu prioritizarea provine cel mai adesea din neînțelegerea așteptărilor clientului. Apare atunci când Proprietarul Produsului nu este capabil să extragă informații despre Obiectivele reale ale Produsului de la Client. Acesta este răspunsul la întrebarea la ce nevoi ar trebui să răspundă produsul.

Deci, cum vă protejați de această greșeală? În primul rând, ascultați cu atenție clientul. În al doilea rând, învață să pui întrebări despre obiectiv și cum funcționează fiecare caracteristică a produsului. În al treilea rând – negociați și limitați obiectivele de atins. Și pentru asta, vei avea nevoie de asertivitate.

Când Product Owner are o listă de sarcini de făcut, există metode dovedite pentru a îmbunătăți progresul și elaborarea acestora. De exemplu, utilizarea așa-numitei matrice Eisenhower este folosită pentru a prioritiza sarcinile în funcție de criteriile de importanță și urgență.

Lipsa de asertivitate a Product Ownerului

Problema care este strâns legată de incapacitatea de a prioritiza este lipsa de asertivitate. Are ca rezultat sarcini neadecvate puse în coadă și duce la blocarea realizării obiectivului de produs prin combinarea acestuia cu sarcini excesive. Prin urmare, capacitatea de a spune nu clientului este crucială.

Asertivitatea Product Ownerului ar trebui să se bazeze pe trei piloni:

• cunoasterea capacitatilor echipei,
• cunoașterea soluțiilor utilizate și dezvoltate de echipă,
• conștientizarea rolului și valorii lor în funcție de locul lor în echipa Scrum.

Prin urmare, una dintre cele mai importante moduri de a preveni problemele de asertivitate este ca Product Owner să lucreze zilnic cu echipa Scrum. Acest lucru îl va ajuta să-și construiască convingeri realiste despre timpul și capacitatea de a implementa ideile Clientului.

Abilități insuficiente de afaceri

Următoarea greșeală pe care am dori să o discutăm este lipsa calificărilor corespunzătoare în afaceri. Punctele forte ale acestor proprietari de produse sunt de obicei calificări specializate. Competențele lor sunt mai strâns legate de aria echipei de dezvoltare decât de business. Așadar, lipsesc cunoștințe bine stabilite, practice despre concurență, despre regulile pieței și despre clientul final al produsului creat de Echipa Scrum.

Nu există un remediu simplu pentru aceasta, deoarece poate apărea în situații foarte specifice. Cu siguranță, totuși, un bun curs de acțiune pentru un proprietar de produs este să recunoască acest lucru și să continue să învețe și să câștige experiență și competențe de afaceri.

Provocări cu care se confruntă Product Ownerul cu privire la restul echipei Scrum

Abilitatea de a prioritiza sarcinile, asertivitatea Product Owner-ului și abilitățile sale înalte de afaceri sunt premisele necesare pentru crearea unui Product Backlog exemplar, fundația pe termen lung a echipei Scrum. Dacă Backlog-ul nu este descris în mod consecvent și precis, problemele din relația Product Owner-Client se vor răspândi în relația Product Owner-altul membru al echipei Scrum. Și, la rândul lor, ele afectează direct eficacitatea echipei Scrum. Ce alte capcane îl așteaptă pe Product Owner în relațiile sale cu ceilalți membri ai echipei Scrum?

Pentru a fi mai ușor, am prezentat într-un tabel problemele dintre Product Owner și Echipa Scrum. Mai jos puteți găsi o discuție detaliată a fiecărei probleme și sugestii de soluții.

Slabă carisma

Zilnic, sarcina Product Ownerului este să coordoneze liniile directoare ale Clientului cu modul în care acestea sunt implementate de către Echipa de Dezvoltare. Acest lucru necesită, fără îndoială, să aveți autoritatea potrivită, abilitățile de ascultare și carisma.

Problema autorităţii insuficiente nu poate fi rezolvată peste noapte. Este nevoie de muncă pe termen lung pe abilități soft. Și, de asemenea, obținerea de cunoștințe despre domeniul sarcinilor și abilităților altor membri ai echipei.

Abilități de specialitate insuficiente

După cum am scris în articolul care răspunde la întrebarea Cine este un Product Owner?, rolul unui Product Owner nu este strict tehnic. Cu toate acestea, cunoașterea elementelor de bază ale abilităților specializate ale membrilor echipei de dezvoltare poate crește semnificativ autoritatea unui Product Owner. Calificările insuficiente în aria de expertiză a echipei nu pot genera doar probleme cu carisma și autoritatea Product Owner-ului. Greșeala de a nu fi interesat de ceea ce sunt specializați membrii Echipei de Dezvoltare și de bazele competențelor lor poate genera situații amuzante, dar și situații cu consecințe dezastruoase de afaceri și interpersonale.

Prin urmare, pentru ca Echipa Scrum să livreze produse de cea mai bună calitate, Product Owner trebuie să aibă o înțelegere aprofundată a produsului. Nu ar trebui să fie dificil să obțineți calificarea potrivită, având în vedere că Product Owner face parte dintr-o echipă de profesioniști. Ei pot oferi nu numai explicații, ci și sugestii despre unde să obțină cunoștințe despre domeniul lor.

Independenţă

Proprietarul de produs trebuie să fie capabil să ia decizii în mod independent. Desigur, problema cheie este să cunoști condițiile echipei Scrum și să comunici constant cu echipa de dezvoltare. Cu toate acestea, Proprietarul produsului este considerat responsabil pentru eficacitatea acțiunilor sale. Din acest motiv, proprietarii de produse trebuie să -și construiască autoritatea și să-și asume responsabilitatea pentru deciziile pe care le iau. Apelul final privind conducerea echipei, prioritizarea și acceptarea sarcinilor le aparțin.

rezumat

Am descoperit cele mai frecvente greșeli ale Product Ownerului. Rolul unui Product Owner nu este unul ușor. De aceea, atunci când îl iei, merită să te pregătești pentru problemele pe care ceilalți le-au întâlnit în drumul lor.

Problemele relațiilor cu clienții provin de obicei din lipsa de asertivitate, incapacitatea de a stabili priorități și abilități insuficiente de afaceri.

Greșelile Product Ownerului care apar în timpul lucrului cu restul echipei Scrum rezultă din lipsa de independență și carisma insuficientă a persoanei care a preluat rolul de Product Owner. Un alt motiv se poate referi la lipsa competențelor de specialitate și lipsa de dorință - sau lipsa timpului pentru extinderea cunoștințelor.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Linkedin și Twitter.

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Vizualizați toate postările

Ghid Scrum:

1. Glosar de termeni de bază, roluri și noțiuni
2. Ce este Scrum?
3. Valorile Scrum
4. Cum implementezi Scrum în compania ta?
5. Echipa Scrum - ce este și cum funcționează?
6. Cine este un proprietar de produs?
7. Cele mai frecvente greșeli ale Product Ownerului
8. Cine este Scrum Master?
9. Caracteristicile unui bun Scrum Master
10. Cele mai frecvente greșeli ale Scrum Master
11. Ce statistici și valori ar trebui să urmărească Scrum Master?
12. Cooperare între Product Owner și Scrum Master
13. Echipa de dezvoltare în Scrum
14. Cele mai frecvente greșeli ale dezvoltatorilor
15. Artefacte Scrum
16. Scaling Scrum
17. Sprint Backlog
18. Ce este Product Backlog?
19. Ce sunt User Stories?
20. Crearea celei mai bune povești de utilizator cu INVEST
21. Cele mai frecvente greșeli ale User Story
22. Criterii de acceptare a poveștii utilizatorului
23. Estimare și Story Points în Scrum
24. Planificarea Pokerului
25. Joc de estimare a echipei
26. Definirea creșterii
27. Evenimente Scrum
28. Ce este Sprint în Scrum?
29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
30. Ce este un grafic Burndown?
31. Cum se creează și se interpretează un grafic de ardere?
32. Avantajele și dezavantajele diagramei de ardere
33. Panouri Kanban în Scrum și Scrumban
34. Viteza în Scrum - Viteza echipei de dezvoltare
35. Scrum zilnic
36. Planificarea sprintului
37. Sprint Review
38. Ce este o retrospectivă Sprint?
39. Greșeli frecvente în timpul unei retrospective de sprint
40. Creșterea backlog-ului de produse