Guida Scrum | 7. Gli errori più comuni del Product Owner

Nel post di oggi ci concentreremo sulle sfide più comuni che i Product Owner devono affrontare. Ti diremo anche come prepararti per le situazioni in cui questi errori del Product Owner si verificano più spesso.

Errori del Product Owner – sommario:

1. Cosa potrebbe andare storto tra il Product Owner e il Cliente
2. Sfide che il Product Owner deve affrontare riguardo al resto dello Scrum Team
3. Riepilogo

Cosa potrebbe andare storto tra il Product Owner e il Cliente

Il Product Owner è la persona che è personalmente responsabile dei fallimenti dello Scrum Team. A causa di questa posizione al di fuori delle attività del team, si ritiene che il Product Owner sia l'unico collo strizzabile . In altre parole, è il Product Owner che soffre di più quando lo Scrum Team va male. Quindi, come affrontare le situazioni problematiche quando compaiono o, meglio ancora, impedire che si verifichino in primo luogo?

Per rispondere a questo punto, abbiamo fornito un'analisi chiara e approfondita di alcuni dei principali errori di Product Owner e Clienti nella tabella seguente insieme a una discussione dettagliata di ciascuno.

Incapacità di stabilire le priorità

L'errore di non sapere come stabilire le priorità è la rovina di molti Product Owner. Perché la definizione delle priorità delle attività è una competenza fondamentale? Perché quando tutto diventa ugualmente importante, il Product Goal scompare. Questo è l'effetto voluto dell'attività dello Scrum Team.

Il problema nasce già durante le prime conversazioni con i clienti sull'Obiettivo Prodotto. Il cliente di solito vuole che tutte le sue idee siano realizzate nel modo più rapido ed economico possibile. Il compito del Product Owner è quello di stabilire un elenco di priorità. Il suo compito è quello di creare un elenco di aspettative chiare e fattibili ordinate dalla più alla meno importante, sulla base delle aspettative non strutturate dei clienti.

Il problema dell'assegnazione delle priorità il più delle volte deriva dall'incomprensione delle aspettative del cliente. Appare quando il Product Owner non è in grado di estrarre dal Cliente informazioni sui reali Obiettivi del Prodotto. Questa è la risposta alla domanda a quali esigenze dovrebbe rispondere il prodotto.

Allora come ti proteggi da questo errore? Primo: ascolta attentamente il cliente. In secondo luogo, impara a porre domande sull'obiettivo e sul funzionamento di ciascuna funzionalità del prodotto. Terzo: negoziare e limitare gli obiettivi da raggiungere. E per questo, avrai bisogno di assertività.

Quando il Product Owner ha un elenco di attività da svolgere, esistono metodi collaudati per migliorarne la progressione e l'elaborazione. Ad esempio, l'utilizzo della cosiddetta matrice di Eisenhower viene utilizzato per assegnare priorità alle attività in base a criteri di importanza e urgenza.

Mancanza di assertività del Product Owner

Il problema strettamente correlato all'incapacità di stabilire le priorità è la mancanza di assertività. Risulta in attività in coda in modo inappropriato e porta a bloccare la realizzazione dell'obiettivo del prodotto aggravandolo con attività eccessive. Pertanto, la capacità di dire di no al cliente è fondamentale.

L'assertività del Product Owner dovrebbe basarsi su tre pilastri:

• conoscenza delle capacità del team,
• conoscenza delle soluzioni utilizzate e sviluppate dal team,
• consapevolezza del proprio ruolo e valore in base al proprio posto nello Scrum Team.

Pertanto, uno dei modi più importanti per prevenire problemi di assertività è che il Product Owner lavori quotidianamente con lo Scrum Team. Questo lo aiuterà a costruire convinzioni realistiche sul tempo e sulla capacità di implementare le idee del Cliente.

Competenze commerciali insufficienti

Il prossimo errore di cui vorremmo discutere è la mancanza di adeguate qualifiche commerciali. I punti di forza di questi Product Owner sono solitamente le qualifiche specializzate. Le loro competenze sono più strettamente legate all'area del Team di sviluppo che al business. Mancano quindi conoscenze consolidate e pratiche sulla concorrenza, sulle regole del mercato e sul cliente finale del prodotto creato dallo Scrum Team.

Non esiste un rimedio semplice, poiché può verificarsi in situazioni molto specifiche. Sicuramente, tuttavia, una buona linea d'azione per un Product Owner è riconoscerlo e continuare ad apprendere e acquisire esperienza e competenze aziendali.

Sfide che il Product Owner deve affrontare riguardo al resto dello Scrum Team

La capacità di dare priorità ai compiti, l'assertività del Product Owner e le sue elevate capacità di business sono i prerequisiti necessari per creare un Product Backlog esemplare, la base a lungo termine dello Scrum Team. Se il Backlog non è delineato in modo coerente e accurato, i problemi nella relazione Product Owner-Cliente si riverseranno nella relazione Product Owner-altro membro dello Scrum Team. E, a loro volta, influiscono direttamente sull'efficacia dello Scrum Team. Quali altre insidie ​​attendono il Product Owner nei suoi rapporti con gli altri membri dello Scrum Team?

Per semplificare, abbiamo presentato in una tabella i problemi tra Product Owner e Scrum Team. Di seguito puoi trovare una discussione dettagliata di ogni problema e suggerimenti per le soluzioni.

Scarso carisma

Quotidianamente, il compito del Product Owner è quello di coordinare le linee guida del Cliente con il modo in cui vengono implementate dal Team di Sviluppo. Ciò richiede indubbiamente la giusta autorità, capacità di ascolto e carisma.

Il problema dell'autorità insufficiente non può essere risolto dall'oggi al domani. Richiede un lavoro a lungo termine sulle competenze trasversali. E anche acquisire conoscenze sulla portata dei compiti e delle abilità degli altri membri del team.

Competenze specialistiche insufficienti

Come abbiamo scritto nell'articolo rispondendo alla domanda Chi è un Product Owner?, il ruolo di un Product Owner non è strettamente tecnico. Tuttavia, conoscere le basi delle competenze specialistiche dei membri del Team di sviluppo può aumentare significativamente l'autorità di un Product Owner. Qualifiche insufficienti nell'area di competenza del team non solo possono generare problemi con il carisma e l'autorità del Product Owner. L'errore di non interessarsi a ciò in cui sono specializzati i membri del Team di Sviluppo e alle basi delle loro competenze può generare situazioni divertenti, ma anche situazioni con conseguenze commerciali e interpersonali disastrose.

Pertanto, affinché lo Scrum Team possa fornire prodotti della migliore qualità, il Product Owner deve avere una conoscenza approfondita del prodotto. Non dovrebbe essere difficile ottenere la giusta qualifica considerando che il Product Owner fa parte di un team di professionisti. Possono fornire non solo spiegazioni ma anche suggerimenti su dove ottenere conoscenze nel loro campo.

Indipendenza

Il Product Owner deve essere in grado di prendere decisioni in modo indipendente. Naturalmente, la questione chiave è conoscere le condizioni dello Scrum Team e comunicare costantemente con il Team di sviluppo. Tuttavia, è il Product Owner che è ritenuto responsabile dell'efficacia delle sue azioni. Per questo motivo, i Product Owner devono rafforzare la propria autorità e assumersi la responsabilità delle decisioni che prendono. L'ultima chiamata alla direzione del team, alla definizione delle priorità e all'accettazione dei compiti spetta a loro.

Riepilogo

Abbiamo scoperto gli errori più comuni del Product Owner. Il ruolo di Product Owner non è facile. Ecco perché, quando lo prendi, vale la pena prepararsi ai problemi che gli altri hanno incontrato sul loro cammino.

I problemi di relazione con il cliente di solito derivano da una mancanza di assertività, incapacità di stabilire le priorità e capacità commerciali insufficienti.

Gli errori di Product Owner che emergono durante il lavoro con il resto dello Scrum Team derivano dalla mancanza di indipendenza e dall'insufficiente carisma della persona che ha assunto il ruolo di Product Owner. Un altro motivo potrebbe riguardare la mancanza di competenze specialistiche e la riluttanza o la mancanza di tempo per ampliare le conoscenze.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Linkedin e Twitter.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog