W dzisiejszym wpisie skoncentrujemy się na najczęstszych błędach popełnianych przez Product Ownera. Podpowiemy też, jak przygotować się do sytuacji, w których te błędy najczęściej się pojawiają.

Błędy popełniane przez Product Ownera – omówione zagadnienia:

  1. Problemy na linii Product Owner – Klient
  2. Problemy na linii Product Owner – reszta Scrum Team
  3. Podumowanie

Problemy na linii Product Owner – Klient

Product Owner jest osobą, która personalnie odpowiada za niepowodzenia Scrum Team. Z racji swojej pozycji wykraczającej poza działania zespołu mówi się, że jest single wringable neck, czyli pojedynczym karkiem do skręcenia. Innymi słowy, to właśnie on najbardziej ucierpi w sytuacji, gdy praca Scrum Team nie idzie po myśli Klienta i inwestora. Jak zatem radzić sobie w problematycznych sytuacjach i chronić się przed najczęstszymi błędami?

Dla ułatwienia przedstawiliśmy problemy z klientem w tabelce. Pod nią znajdziecie szczegółowe omówienie każdego z problemów.

Błąd Generowany problem Sugestie rozwiązania
Nieumiejętność ustalania priorytetów Niezoptymalizowany Backlog Produktu, rozmywanie się Celu Produktu Słuchanie, pytanie, negocjowanie Celu Produktu z Klientem, uważne opracowanie wyników negocjacji
Brak asertywności Zbyt wiele zadań do wykonania przez Scrum Team Myślenie realistyczne, wiedza i pamięć o możliwościach zespołu
Niewystarczające kwalifikacje biznesowe Ryzyko obniżenia wartości biznesowej Produktu wytworzonego przez Scrum Team Nieustanne uczenie się i zdobywanie kompetencji biznesowych

Nieumiejętność ustalania priorytetów

Błąd polegający na nieumiejętności ustalania priorytetów to zmora wielu Product Ownerów. Dlaczego ustalanie priorytetów zadań jest kluczową kompetencją? Ponieważ w momencie, gdy wszystko staje się tak samo ważne, znika z oczu Cel Produktu. Czyli zamierzony efekt działania Scrum Team.

Problem zaczyna się już podczas pierwszych rozmów z klientami dotyczących Celu Produktu. Klient chce bowiem zwykle, aby zrealizować wszystkie jego pomysły jak najszybciej i jak najtaniej. Zadaniem Product Ownera jest więc ustalenie listy priorytetów. Jego zadanie polega na stworzeniu listy jasnych i możliwych do zrealizowania oczekiwań uszeregowanych od najważniejszych do najmniej ważnych. A trzeba to zrobić na podstawie nieustrukturyzowanych oczekiwań klienta.

Problem z priorytetami najczęściej ma źródło w niezrozumieniu oczekiwań klienta. Pojawia się wraz z niemożliwością wydobycia z klienta informacji o realnym Celu Produktu. Czyli odpowiedzi na pytanie, na jakie potrzeby produkt ma odpowiadać.

Jak więc chronić się przed tym błędem? Po pierwsze – słuchać uważnie klienta. Po drugie, nauczyć się zadawać pytania dotyczące Celu i sposobów działania poszczególnych funkcjonalności produktu. Po trzecie – negocjować i ograniczać Cele do zrealizowania. A do tego potrzebna będzie asertywność.

Gdy Product Owner trzyma już w ręce listę zadań do wykonania, w ich prioretyzacji i opracowaniu mogą pomóc sprawdzone metody. Na przykład zastosowanie tak zwanej macierzy Eisenhowera służącej do ustalania priorytetów zadań według kryteriów ważności i pilności.

Brak asertywności Product Ownera

Problemem, który ściśle łączy się z nieumiejętnością prioretyzacji jest brak asertywności. Wtedy do problemu nieodpowiednio ustawionej kolejki zadań prowadzącej do realizacji Celu Produktu dochodzi problem ich nadmiernej ilości. Dlatego zdolność powiedzenia nie klientowi jest naprawdę kluczowa.

The most common mistakes of Product Owner

Asertywność powinna być oparta na trzech filarach:

  • wiedzy o możliwościach zespołu,
  • wiedzy o używanych i rozwijanych przez zespół rozwiązaniach,
  • świadomości własnej roli i wartości opartej o miejsce w Scrum Team.

Dlatego jednym z najważniejszych sposobów zapobiegania problemom z asertywnością jest codzienna praca Product Ownera ze Scrum Team. Dzięki temu zbuduje on realistyczne przekonania dotyczące czasu i możliwości realizacji pomysłów Klienta.

Niewystarczające kwalifikacje biznesowe

Następnym błędem, który chcielibyśmy omówić jest brak odpowiednich kwalifikacji biznesowych. Mocnymi stronami tych Product Ownerów są zwykle kwalifikacje specjalistyczne. Ich kompetencje wiążą się ściślej z obszarem działania Zespołu Developerskiego, niż z biznesem. Brakuje zatem ugruntowanej, praktycznej wiedzy dotyczącej konkurencji, zasad działania rynku, a także finalnego odbiorcy produktu tworzonego przez Scrum Team.

Nie ma prostego remedium, które zaradziłoby temu problemowi. Szczególnie, że może on pojawiać się w bardzo specyficznych sytuacjach. Z pewnością jednak dobrym kierunkiem działania dla Product Ownera świadomego jego istnienia jest nieustanne uczenie się i zdobywanie doświadczenia i kompetencji biznesowych.

Problemy na linii Product Owner – reszta Scrum Team

Zdolność prioretyzacji zadań, asertywność Product Ownera oraz jego wysokie kwalifikacje biznesowe składają się na umiejętności służące do stworzenia wzorowego Backlogu Produktu, czyli długoterminowej podstawy działania Scrum Team. Jeśli Backlog nie został zarysowany spójnie i trafnie, problemy w relacji z klientem przeniosą się na relację Product Owner – pozostali członkowie Scrum Team. A co za tym idzie, wpłyną bezpośrednio na skuteczność działania Scrum Team. Jakie jeszcze pułapki czekają w relacjach z pozostałymi członkami Scrum Team?

Dla ułatwienia przedstawiliśmy problemy na linii Product Owner – Scrum Team w tabelce. Poniżej znajdziecie szczegółowe omówienie każdego z problemów.

Błąd Generowany problem Sugestie rozwiązania
Niewystarczająca charyzma Zespół Developerski nie wykonuje zadań zawartych w Backlogu, zdanie Product Ownera jest podważane Budowanie autorytetu opartego na kompetencjach miękkich i wiedzy
Niewystarczająca kwalifikacje specjalistyczne Niezrozumienie codziennego działania oraz możliwości Zespołu Developerskiego Orientacja w specjalizacjach członków zespołu, a także zdobywanie wiedzy na temat obszaru działania Zespołu
Niesamodzielność Rozmywanie odpowiedzialności Wzmocnienie autorytetu

Niewystarczająca charyzma

W codziennej pracy Product Owner ma za zadanie koordynowanie wytycznych Klienta ze sposobem ich realizacji przez Zespół Developerski. Bez wątpienia wymaga to posiadania odpowiedniego autorytetu, posłuchu i charyzmy.

Problemu niewystarczającego autorytetu nie da się rozwiązać z dnia na dzień. Wymaga długotrwałej pracy nad kompetencjami miękkimi. A także zdobywania wiedzy na temat zakresu zadań i umiejętności pozostałych członków zespołu.

Niewystarczająca kwalifikacje specjalistyczne

Jak pisaliśmy w artykule odpowiadającym na pytanie Kim jest Product Owner?, rola Product Ownera nie jest rolą stricte techniczną. Jednak znajomość podstaw specjalistycznych umiejętności członków Zespołu Developerskiego może znacząco podbudować autorytet Product Ownera.

Niewystarczające kwalifikacje w obszarze działania zespołu mogą nie tylko generować problemy z charyzmą i autorytetem Product Ownera. Błąd polegający na braku zainteresowania tym, w czym specjalizują się członkowie Zespołu Developerskiego, oraz podstawami ich kompetencji może generować zabawne sytuacje, ale również sytuacje o katastrofalnych skutkach biznesowych i interpersonalnych.

Dlatego też, aby Scrum Team mógł dostarczać produkty najlepszej jakości, Product Owner musi dokładnie rozumieć ich istotę. Zdobycie odpowiednich kwalifikacji nie powinno być trudne biorąc pod uwagę, że Product Owner jest częścią zespołu złożonego z profesjonalistów. Mogą oni służyć nie tylko wyjaśnieniami, ale również podpowiedzieć, z jakich źródeł warto czerpać wiedzę na temat ich dziedziny.

Niesamodzielność

Produkt Owner musi potrafić samodzielnie podejmować decyzje. Oczywiście kluczową kwestią jest znajomość uwarunkowań Scrum Team, oraz nieustanne rozmowy z Zespołem Developerskim. Jednak to właśnie Product Owner odpowiada głową za skuteczność jego działania. Z tego powodu musi budować swój autorytet i brać odpowiedzialność za podejmowane decyzje. Ostatnie słowo dotyczące kierunku działania zespołu, prioretyzacji i akceptacji zadań należy właśnie do niego.

The most common mistakes of Product Owner

Podsumowanie

Rola Product Ownera nie należy do łatwych. Dlatego podejmując się jej warto przygotować się na problemy, na które na swej ścieżce napotkali inni.

Problemy w relacjach z Klientem zwykle mają swe źródło w braku asertywności, nieumiejętności stawiania priorytetów oraz niewystarczających kompetencji w dziedzinie biznesu.

Trudności pojawiające się podczas pracy z resztą Scrum Team mogą wypływać z braku samodzielności. Ich powodem może być też niewystarczająca charyzma osoby, która podjęła się tej roli, a także brak specjalistycznych kwalifikacji i niechęć – lub brak czasu – na poszerzanie wiedzy.

Sprawdź kolejny wpis z tej serii, tym razem dotyczący pracy Scrum Mastera.

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 7. Najczęstsze błędy popełniane przez Product Ownera caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?