Scrum Guide | 7. Najczęstsze błędy popełniane przez Product Ownera

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.

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.

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.