Przewodnik po Scrumie | 7. Najczęstsze błędy Product Ownera

Opublikowany: 2022-04-14

W dzisiejszym poście skoncentrujemy się na najczęstszych wyzwaniach, przed którymi stoją Właściciele Produktów. Podpowiemy Ci również, jak przygotować się na sytuacje, w których te błędy Product Ownera zdarzają się najczęściej.

Błędy Product Ownera – spis treści:

  1. Co może pójść nie tak między Właścicielem Produktu a Klientem
  2. Wyzwania stojące przed Product Ownerem dotyczące reszty Zespołu Scrumowego
  3. Streszczenie

Co może pójść nie tak między Właścicielem Produktu a Klientem

Właściciel Produktu to osoba, która jest osobiście odpowiedzialna za niepowodzenia Zespołu Scrumowego. Ze względu na to stanowisko wykraczające poza działania zespołu, uważa się, że Właścicielem Produktu jest pojedyncza kręcona szyja . Innymi słowy, to Właściciel Produktu najbardziej cierpi, gdy Zespół Scrumowy się nie powiedzie. Jak więc radzić sobie z kłopotliwymi sytuacjami, gdy się pojawiają, a jeszcze lepiej zapobiegać im w pierwszej kolejności?

Aby odpowiedzieć na to pytanie, w poniższej tabeli przedstawiliśmy jasną i dogłębną analizę niektórych głównych błędów Właścicieli Produktów i Klientów wraz ze szczegółowym omówieniem każdego z nich.

Błąd Wygenerowany problem Propozycje rozwiązania
Niezdolność do ustalania priorytetów Niezoptymalizowany Backlog Produktu, rozmycie Celu Produktu Wysłuchanie, zadawanie pytań, negocjowanie Celu Produktu z klientem, staranne przetwarzanie wyników negocjacji
Brak asertywności Zbyt wiele zadań do wykonania przez Zespół Scrumowy Myśląc realistycznie, znając i pamiętając możliwości zespołu
Niewystarczające umiejętności biznesowe Ryzyko obniżenia wartości biznesowej Produktu stworzonego przez Scrum Team Ciągłe uczenie się i nabywanie kompetencji biznesowych

Niezdolność do ustalania priorytetów

Błąd polegający na tym, że nie wiemy, jak ustalić priorytety, jest zmorą wielu właścicieli produktów. Dlaczego priorytetyzacja zadań jest podstawową kompetencją? Bo gdy wszystko staje się równie ważne, Cel Produktowy znika. Taki jest zamierzony efekt działania Scrum Team.

Problem zaczyna się już podczas pierwszych rozmów z klientami na temat Celu Produktowego. Klient zazwyczaj chce, aby wszystkie jego pomysły zostały zrealizowane jak najszybciej i jak najtaniej. Zadaniem Product Ownera jest ustalenie listy priorytetów. Jego zadaniem jest stworzenie listy jasnych i możliwych do zrealizowania oczekiwań uszeregowanych od najważniejszych do najmniej ważnych, w oparciu o nieustrukturyzowane oczekiwania klientów.

Problem z priorytetyzacją najczęściej bierze się z niezrozumienia oczekiwań klienta. Pojawia się, gdy Właściciel Produktu nie jest w stanie wydobyć od Klienta informacji o rzeczywistych Celach Produktu. To odpowiedź na pytanie, na jakie potrzeby ma odpowiadać produkt.

Jak więc uchronić się przed tym błędem? Po pierwsze – słuchaj uważnie klienta. Po drugie, naucz się zadawać pytania dotyczące Celu i działania poszczególnych funkcji produktu. Po trzecie – negocjuj i ograniczaj Cele do osiągnięcia. A do tego potrzebujesz asertywności.

Gdy właściciel produktu ma listę zadań do wykonania, istnieją sprawdzone metody usprawnienia ich postępu i opracowania. Na przykład, wykorzystanie tak zwanej macierzy Eisenhowera służy do priorytetyzacji zadań według kryteriów ważności i pilności.

Brak asertywności Product Ownera

Problemem ściśle związanym z niemożnością ustalenia priorytetów jest brak asertywności. Skutkuje to niewłaściwie kolejkowanymi zadaniami i prowadzi do zablokowania realizacji Celu Produktowego poprzez nałożenie na niego nadmiaru zadań. Dlatego umiejętność powiedzenia klientowi „nie” jest kluczowa.

The most common mistakes of Product Owner

Asertywność Product Ownera powinna opierać się na trzech filarach:

  • znajomość możliwości zespołu,
  • znajomość stosowanych i rozwijanych przez zespół rozwiązań,
  • świadomość swojej roli i wartości w oparciu o swoje miejsce w Zespole Scrumowym.

Dlatego jednym z najważniejszych sposobów zapobiegania problemom asertywności jest codzienna praca Product Ownera z Zespołem Scrumowym. Pomoże mu to zbudować realistyczne przekonania o czasie i umiejętności realizacji pomysłów Klienta.

Niewystarczające umiejętności biznesowe

Kolejnym błędem, o którym chcielibyśmy porozmawiać, jest brak odpowiednich kwalifikacji biznesowych. Mocnymi stronami tych Product Ownerów są zwykle specjalistyczne kwalifikacje. Ich kompetencje są ściślej związane z obszarem Zespołu Deweloperskiego niż z biznesem. Brakuje więc ugruntowanej, praktycznej wiedzy o konkurencji, o regułach rynku i finalnym kliencie produktu stworzonego przez Zespół Scrumowy.

Nie ma na to prostego lekarstwa, ponieważ może wystąpić w bardzo specyficznych sytuacjach. Z pewnością jednak dobrym sposobem działania dla Product Ownera jest uznanie tego i ciągłe uczenie się oraz zdobywanie doświadczenia i kompetencji biznesowych.

Wyzwania stojące przed Product Ownerem dotyczące reszty Zespołu Scrumowego

Umiejętność nadawania priorytetów zadaniom, asertywność Product Ownera oraz jego wysokie umiejętności biznesowe są niezbędnymi warunkami do stworzenia wzorowego Backlogu Produktu, który jest długofalowym fundamentem Zespołu Scrumowego. Jeśli Backlog nie jest spójny i dokładny, problemy w relacji Właściciel Produktu-Klient przeniosą się na relacje Właściciel Produktu-inny członek Zespołu Scrumowego. A z kolei bezpośrednio wpływają na efektywność Zespołu Scrumowego. Jakie inne pułapki czyhają na Właściciela Produktu w jego relacjach z innymi członkami Zespołu Scrumowego?

Dla ułatwienia przedstawiliśmy w tabeli problemy pomiędzy Product Ownerem a Scrum Team. Poniżej znajdziesz szczegółowe omówienie każdego problemu oraz propozycje rozwiązań.

Błąd Wygenerowany problem Propozycje rozwiązania
Niewystarczająca charyzma Zespół Deweloperski nie wykonuje zadań zawartych w Backlogu, opinia Właściciela Produktu jest kwestionowana Budowanie autorytetu opartego na umiejętnościach miękkich i wiedzy
Niewystarczające umiejętności specjalistyczne Niezrozumienie codziennych działań i możliwości Zespołu Deweloperskiego Orientacja na specjalizacje członków zespołu, a także zdobywanie wiedzy z zakresu specjalizacji Zespołu
Niezależność Rozmycie odpowiedzialności Wzmocnienie

Słaba charyzma

Na co dzień zadaniem Product Ownera jest koordynacja wytycznych Klienta ze sposobem ich realizacji przez Zespół Deweloperski. Wymaga to niewątpliwie odpowiedniego autorytetu, umiejętności słuchania i charyzmy.

Problemu niewystarczających uprawnień nie da się rozwiązać z dnia na dzień. Wymaga długotrwałej pracy nad umiejętnościami miękkimi. A także zdobywanie wiedzy o zakresie zadań i umiejętności innych członków zespołu.

Niewystarczające umiejętności specjalistyczne

Jak pisaliśmy w artykule odpowiadającym na pytanie Kto jest Product Ownerem?, rola Product Ownera nie jest ściśle techniczna. Jednak znajomość podstaw specjalistycznych umiejętności członków Zespołu Deweloperskiego może znacząco zwiększyć autorytet Product Ownera. Niewystarczające kwalifikacje w obszarze kompetencji zespołu mogą generować problemy nie tylko z charyzmą i autorytetem Product Ownera. Błąd braku zainteresowania tym, w czym specjalizują się członkowie Zespołu Deweloperskiego i podstawami ich kompetencji, może generować zabawne sytuacje, ale także sytuacje o katastrofalnych konsekwencjach biznesowych i interpersonalnych.

mistakes of Product Owner

Dlatego, aby Zespół Scrumowy mógł dostarczać produkty najwyższej jakości, Właściciel Produktu musi mieć dogłębne zrozumienie produktu. Uzyskanie odpowiedniej kwalifikacji nie powinno być trudne, biorąc pod uwagę , że Product Owner jest częścią zespołu profesjonalistów. Mogą udzielić nie tylko wyjaśnień, ale także sugestii, gdzie zdobyć wiedzę na temat swojej dziedziny.

Niezależność

Właściciel Produktu musi być w stanie samodzielnie podejmować decyzje. Oczywiście kluczową kwestią jest znajomość warunków Zespołu Scrumowego i ciągła komunikacja z Zespołem Deweloperskim. Jednak to Właściciel Produktu ponosi odpowiedzialność za skuteczność swoich działań. Z tego powodu Właściciele Produktów muszą budować swój autorytet i brać odpowiedzialność za podejmowane przez siebie decyzje. Do nich należy ostateczne wezwanie do kierowania zespołem, ustalania priorytetów i akceptacji zadań.

The most common mistakes of Product Owner

Streszczenie

Odkryliśmy najczęstsze błędy Product Ownera. Rola Product Ownera nie jest łatwa. Dlatego biorąc go, warto przygotować się na problemy, które inni napotkali na swojej drodze.

Problemy z relacjami z klientami zwykle wynikają z braku asertywności, nieumiejętności ustalania priorytetów i niewystarczających umiejętności biznesowych.

Błędy Product Ownera pojawiające się podczas pracy z resztą Zespołu Scrumowego wynikają z braku samodzielności i niedostatecznej charyzmy osoby, która objęła rolę Product Ownera. Innym powodem może być brak specjalistycznych umiejętności i niechęć – lub brak czasu na poszerzanie wiedzy.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Linkedin i Twitterze.

Scrum Guide | 7. The most common mistakes of Product Owner caroline becker avatar 1background

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu