Skąd brać Product Ownerów?

Pytanie „skąd brać Product Ownerów” nieustannie powtarza się w naszej codziennej pracy z klientami. W tym materiale poznasz najczęstsze wzorce poszukiwania Product Ownerów oraz kilka wskazówek, na co zwrócić szczególną uwagę, by dobrze wytypować osobę do pełnienia odpowiedzialności Właściciela Produktu.

W jakich miejscach poszukiwać osób do roli Product Ownera?

Rozważamy poniżej funkcje, role albo miejsca, z których warto szukać kandydatów do pełnienia odpowiedzialności Właściciela Produktu.

Product Manager 

Jednym z możliwych kandydatów na rolę Product Ownera może być osoba obecnie pełniąca funkcję Product Managera. W organizacjach, gdzie struktura produktowa jest już częściowo ukształtowana lub funkcje zarządzania produktem istnieją w obszarze biznesowym, osoba pełniąca tę funkcję może być naturalnym wyborem na stanowisko Właściciela Produktu. W realiach firmy pracującej w Scrumie przejęcie odpowiedzialności scrumowej przez Product Managera często pozwala na skuteczne połączenie zarządzania produktem z wymaganiami frameworka.

Czy Product Manager ma „pod sobą” Product Ownera odpowiedzialnego za dostarczanie? Taki model działania jest często spotykany w organizacjach. A może odwrotnie, to Product Owner zarządza produktem, a w jego otoczeniu funkcjonują Product Managerowie dostarczający wsad do podejmowania decyzji? Albo może właściwym podejściem jest traktowanie Product Ownera jako odpowiedzialności przypisanej do osoby pełniącej funkcję Product Managera w organizacji (i obie odpowiedzialności skupione są w jednej osobie)? Spotykamy w organizacjach wszystkie te warianty i uważamy, że takie decyzje strukturalne są zależne od kontekstu danej firmy – nie mamy tu jednej zawsze sprawdzającej się rekomendacji.

„Właściwa” osoba z biznesu z prawem do decydowania

Kolejny często spotykany wzorzec to wybór Product Ownera bezpośrednio z obszaru biznesowego. Oznacza to, że rola trafia do osób mających realny wpływ na decyzje dotyczące dostarczanych produktów lub usług. Tym, co odróżnia to podejście od wcześniej opisanego, jest brak przywiązania do konkretnych etykiet stanowisk. Niezależnie od tego, jaką funkcję pełni obecnie kandydat czy jest specjalistą w danej dziedzinie, strategicznym Project Managerem czy kierownikiem nie kierujemy się etykietami, lecz analizujemy, kto obecnie posiada najlepsze kompetencje, wiedzę i pozycję, by przejąć odpowiedzialność za produkt. Oprócz kompetencji i wiedzy warto również uwzględnić poziom zaufania, jakim dana osoba cieszy się w organizacji. Istotne jest to, czy kandydat ma wystarczający autorytet, by przejąć odpowiedzialność Product Ownerską. Mowa o odpowiedzialności rozumianej jako realna decyzyjność i rozliczalność za rezultaty i wyniki, a nie formalna rola podporządkowana zewnętrznemu sterowaniu czy ścisłemu nadzorowi. Wzorzec polegający na poszukiwaniu odpowiedniej osoby wśród przedstawicieli „biznesu” sprawdza się zwłaszcza w organizacjach, które nie mają jeszcze ugruntowanej struktury produktowej lub w których zespoły powstają w sposób wymykający się obowiązującym schematom.

Analityk biznesowy albo systemowy

Przy braku wsparcia i współpracy ze strony „biznesowej” może się okazać, że spośród wszystkich dostępnych kandydatur to właśnie analityk będzie najbardziej oczywistym wyborem. Warto jednak dobrze się zastanowić, czy dana osoba jest gotowa przyjąć odpowiedzialność za produktowe myślenie. Wielu analityków (biznesowych lub systemowych) funkcjonuje dziś w paradygmacie realizacji projektu lub rozwoju systemu. Tymczasem perspektywa „buduję produkt, zarządzam produktem” to sposób myślenia właściwy Product Ownerowi i procentujący w dłuższej perspektywie. Dotychczasowi analitycy rzadko uwzględniają ten aspekt lub nie przywiązują do niego większej wagi.

Umiejętność analitycznego myślenia i cała dziedzina wiedzy z tego obszaru to elementy, które realnie wspierają pracę Product Ownera, szczególnie w zakresie porządkowania i strukturyzowania Backlogu Produktu. Kompetencje analityczne ułatwiają również formułowanie trafnych pytań. To uniwersalny fundament, który może wspierać osobę pełniącą rolę Product Ownera.

Warto jednak pamiętać, że część tych kompetencji może zostać celowo rozwinięta w zespole i stopniowo przekazywana Developerom. Niezbędne będzie również zdobycie wiedzy dotyczącej pozycjonowania produktu. Zrozumienie konkurencji czy ustalanie cen to kolejne obszary, które mogą stać się elementem odpowiedzialności. To szereg decyzji czysto produktowych, które dla analityka pracującego dotąd bez kontekstu produktowego, wykonującego analizy na potrzeby różnych interesariuszy, może oznaczać konieczność uzupełnienia wiedzy i dostosowania się do nowego kontekstu.

 Osoba z doświadczeniem procesowym

Do pełnienia funkcji Product Ownera szczególnie wartościowe są osoby, które miały okazję poznać organizację z różnych perspektyw i pracowały w wielu działach. Przykładowo, ktoś mógł rozpocząć pracę w dziale wsparcia klienta, następnie przejść do Call Center, a potem zajmować się sprzedażą lub określonym obszarem produktu, by finalnie wejść w rolę Product Ownera. To osoba z dobrym zrozumieniem funkcjonowania firmy, świadoma źródeł przychodu, oferty produktowej, dostępnych możliwości i ograniczeń. Daje to szeroką perspektywę organizacyjną i zdecydowanie ułatwia szybkie odnalezienie się w kontekście konkretnego produktu lub usługi.

Wskazówka ta dotyczy projektów, w których zwinność wykorzystywana jest poza obszarem produktów cyfrowych czy systemów IT, na przykład w usprawnianiu procesów lub organizacji. W takich przypadkach może się okazać, że rola produktowa nie istnieje albo osoby, które mogłyby ją pełnić, patrzą na organizację inaczej niż ktoś z doświadczeniem procesowym. Chodzi o osoby „z pola bitwy”, posiadające szerokie, praktyczne doświadczenie procesowe. Znajomość układów sił, rozumienie perspektyw interesariuszy oraz wyczucie, kto wspiera daną inicjatywę, a kto podchodzi do niej sceptycznie może również być istotną korzyścią do pełnienia roli PO.

Project Manager

Choć rola kierownika projektu może się różnić w zależności od organizacji, można wskazać pewien wspólny zakres odpowiedzialności z funkcją Product Ownera. Niektórzy PM-owie odpowiadają bezpośrednio za zakres, cele i końcowy sukces projektu. Kolejnym atutem Project Managerów, którzy przechodzą do roli PO, jest szerokie obycie w pracy z interesariuszami.

Jeśli Project Manager ma doświadczenie w tej konkretnej firmie, prawdopodobnie potrafi sprawnie radzić sobie z zarządzaniem oczekiwaniami i napięciami wewnętrznymi. Potrafi godzić sprzeczne potrzeby i działać dyplomatycznie w trudnych sytuacjach. W części firm te umiejętności mogą nie być kluczowe, ale w innych stanowią podstawę skutecznego pełnienia roli Product Ownera.

Osoba techniczna

Kolejnym wzorcem jest powierzanie roli Product Ownera osobom z doświadczeniem technicznym (architektowi, senior developerowi, Tech Leadowi). Przykładem sensownego scenariusza może być powierzenia osobie technicznej produktu o charakterze biznesowym, który jednocześnie jest mocno innowacyjny technologicznie. Znajomość technologii, intuicja techniczna, bieżący kontakt z nowinkami, to wszystko może stanowić niezbędny wkład w przygotowanie konkretnego produktu.

Trzeba jednak zaznaczyć, że to podejście wiąże się z pewną pułapką. Zdarza się, że osoby techniczne w roli Product Ownera, ze względu na wcześniejsze doświadczenia, ograniczają kreatywność zespołu, pełniąc równocześnie funkcję PO i nieformalnego architekta rozwiązań. Zbyt mocna ingerencja w rozwiązanie (nawet w dobrej wierze) z perspektywy zespołu może być niekorzystna.

W organizacjach, gdzie transformacja zwinna rozpoczyna się po stronie IT, należy ostrożnie podchodzić do powoływania osób technicznych do roli PO w zespołach pracujących na rzecz biznesu. Choć trudniejsza, bardziej wartościowa może okazać się ścieżka poszukiwania kandydata po stronie biznesu. Taka inwestycja może dać lepsze efekty niż prostszy scenariusz: powołanie architekta, analityka systemowego, programisty czy lidera zespołu. Argumenty przemawiające za technicznymi PO warto zarezerwować dla produktów o stricte technicznej naturze (np. backend, narzędzia chmurowe, rozwiązania do monitoringu).

Zatrudnienie zewnętrzne

Warto dopuścić możliwość zatrudnienia PO z zewnątrz organizacji, szczególnie gdy planujesz zbudować większy zespół Product Ownerów. Taka decyzja może przynieść dobre rezultaty. Do ewentualnie posiadanych już osób z silnymi kompetencjami biznesowymi, procesowymi i znajomością wewnętrznych zależności dokładasz osoby ze świeżym spojrzeniem i doświadczeniem z innych organizacji.

Warto przy tym jasno powiedzieć: takie zatrudnienie wiąże się z większym ryzykiem, m.in. z niepewnością co do dopasowania kulturowego. Nowa osoba musi poznać Twój produkt, niezależnie od wcześniejszego doświadczenia. Mimo to warto mieć z tyłu głowy taki wariant, szczególnie w sytuacjach, gdy w organizacji brak jakichkolwiek struktur produktowych. W wielu firmach brakuje też innych wspomnianych wyżej funkcji (analityków, kierowników projektów) czy ogólniej mówiąc – osób z wystarczającym doświadczeniem, by objąć rolę PO.

W jednej z organizacji, którą wspieraliśmy podczas transformacji zwinnej, pojawił się konkretny problem. Najlepsi kandydaci biznesowi, znajdujący się na tzw. krótkiej liście, zostali uznani za zbyt kluczowych, by mogli porzucić swoje dotychczasowe obowiązki i przejąć rolę Product Ownera. Argument, że to właśnie oni byliby najlepszymi PO, nie przekonał decydentów w tej konkretnej firmie. Zrodziła się myśl, że należałoby znaleźć osoby, które mogłyby ich zastąpić, lub zdelegować ich obowiązki. Ostatecznie firma zdecydowała się na model zatrudniania Product Ownerów z zewnątrz, uznając osoby wewnętrzne za zbyt strategiczne.

Zatrudnianie z zewnątrz niesie ze sobą ryzyka, ale warto spojrzeć na to również jako na szansę na odświeżenie sposobu myślenia. Osoba z zewnątrz może przełamać przekonania np. „u nas się tak nie robi” i „tak się nie da”

Podsumowanie

Podsumowując, miejsc i strategii poszukiwania PO jest wiele. W organizacjach IT podejście do rekrutacji będzie inne niż w firmach spoza branży technologicznej. W organizacjach nie-IT ten proces wygląda inaczej. Inaczej też rekrutują firmy, które rozwijają własne produkty, niż te, które świadczą usługi, jak np. software house’y. Dlatego strategię i sposób działania warto dopasować do konkretnej firmy i jej realiów.

Porady dla osób, która szukają Product Ownerów

Mamy kilka porad opartych na naszych praktycznych doświadczeniach związanych z rekrutowaniem lub wyłanianiem osób do funkcji PO. Warto wiedzieć, na co zwrócić uwagę i czym się inspirować, będąc w trakcie poszukiwań takiej osoby.

1. Najpierw definicja celu i produktu, potem powołanie PO

Najpierw zdefiniuj cel i określ, co właściwie jest produktem w twojej firmie. Dopiero potem powołuj Product Ownerów. W praktyce wiele organizacji pomija ten etap, od razu chce znaleźć ludzi lub powołać PO bez wcześniejszej refleksji. Zamiast zadać sobie trudniejszego pytania i przeprowadzić konieczną rozmowę: Jak definiujesz produkt lub produkty? Jakie mają cele i priorytety?

To długa rozmowa na najwyższym poziomie abstrakcji. Dotyczy strategii, celów, taktyk, planowanych kroków rozwoju produktu. Te elementy mogą determinować, ilu PO potrzebujesz i z jakimi kompetencjami oraz o jakiej charakterystyce. Warto z tej refleksji wyciągnąć też założenie na jakim poziomie seniority i z jakim osadzeniem w organizacji musi być rozważana osoba. To wszystko w znacznie większym stopniu powinno determinować potrzeby, niż to, kto akurat jest „pod ręką”. Nawet dynamiczne organizacje rzadko wymieniają osoby na kluczowych stanowiskach produktowych. Efektem może być wielomiesięczne trwanie w układzie będącym skutkiem błędnego początku.

2. Dzisiejsza struktura i role niech nie determinują obsadzania PO

Aktualna struktura organizacyjna i przypisane role nie powinny determinować tego, kto zostanie Product Ownerem. Popularnym, ale niekoniecznie trafnym wzorcem jest automatyczne nominowanie obecnych kierowników działów czy obszarów do roli Product Ownera, zwłaszcza jeśli wybór ogranicza się do jednej struktury organizacyjnej.

Przejście na myślenie produktowe oraz mnogość możliwych wymiarów produktu sprawiają, że dotychczasowy sposób organizacji może być niekompatybilny z nowym podejściem do definiowania produktu i wartości. Dlatego warto spojrzeć szerzej. Lepiej nie ulegać złudzeniu, że „wiemy, gdzie szukać” i że odpowiedni Product Ownerzy już czekają w znanych strukturach. Zacznij od pustej kartki. Wychodź od realnych potrzeb, a nie od tego, co już masz dostępne w strukturze.

3. Kompetencje, a nie giełda gotowych nazwisk

Skup się na potrzebnych kompetencjach, a nie na dostępnych nazwiskach. Transformacja zwinna może być okazją do przeglądu osób pełniących dziś role biznesowe i zadania sobie pytania, czy faktycznie chcesz im powierzyć odpowiedzialność produktową. W niektórych miejscach możesz odkryć nadmiar potrzebnych kompetencji, a to sprawia, że pula kandydatów może ułożyć się w ciekawy i nieoczywisty sposób.

To delikatna sprawa, ale obserwując różne organizacje, widzimy tu konkretną pułapkę. Pada propozycja: „Może Kowalski?”, „Nie, Kowalski nie”, bez jasnego uzasadnienia, bo ktoś ma o nim złą opinię. Myślenie nazwiskami na wczesnym etapie powoływania PO może prowadzić do zapętleń i uruchamiać rozgrywki personalne, zamiast wspierać racjonalne podejście, wybór najlepszych osób do danej pozycji.

4. Znajomość produktu ważniejsza niż wiedza jak pracować zwinnie

W procesie wyboru warto zwrócić większą uwagę na znajomość produktu i otoczenia niż na poziom kompetencji zwinnych. Z doświadczenia wiemy, że choć kompetencje zwinne obejmują szeroki zakres wiedzy, są one zazwyczaj łatwiejsze do przyswojenia niż nadrobienie kilku lat doświadczenia rynkowego osoby biznesowej. Dlatego przy rekrutacji Product Ownerów w pierwszej kolejności zwracaj uwagę na to, czy kandydat odnajdzie się biznesowo.

Warto wziąć sobie do serca tę wskazówkę szczególnie wtedy, gdy organizacja pracuje już w sposób zwinny i planuje reorganizację lub przejście na kolejny poziom dojrzałości. W niektórych organizacjach jednym z obszarów do usprawnienia okazuje się dobór osób do roli Product Ownera. Jeśli dotychczasowi PO nie spełniają oczekiwań, pojawia się argument: „niedomagają, ale przynajmniej znają Scruma”. Tymczasem znajomość Scruma może być najmniej istotnym argumentem przemawiającym za daną osobą. Scrum jest do nauczenia, od tego są Scrum Master i zespół. To nie jest nic wyjątkowego, sprawna osoba biznesowa bez doświadczenia w Scrumie może to szybko nadrobić.

5. Obecna rola i jej wykonywanie przez konkretną osobę nie determinuje jak realizowana będzie nowa odpowiedzialność

Nie zaobserwowaliśmy wyraźnej korelacji między sukcesem w roli Product Ownera a byciem wyjątkowo cenionym pracownikiem w poprzednich rolach. Mówiąc wprost, nie trzeba do tej roli wybierać wyłącznie „dzisiejszych gwiazd” w firmie. Zdarza się, że kompetencje product ownerskie drzemią w osobach, które aktualnie znalazły się na bocznym torze lub nie błyszczą w obecnej roli. Warto uważać, by nie oceniać kandydatów wyłącznie przez pryzmat ich obecnej pozycji, np. jako wybitnych kierowników produktu, analityków czy Product Managerów. W zamian zadaj sobie pytanie: kogo faktycznie potrzebujesz w roli Product Ownera? Bycie „gwiazdą” w zarządzaniu projektami może się okazać wręcz obciążeniem w roli Product Ownera, a nie atutem.

6. Najważniejsze jest nastawienie do nowej roli

Z naszej perspektywy bardzo ważne jest, by dać ludziom szansę się wykazać. Co przez to rozumiemy? Z doświadczenia wiemy, że na pewnym etapie ważniejsze od treści CV może być nastawienie i gotowość do podjęcia wyzwania.

Przykład z praktyki: Spotkaliśmy osoby, które, choć wcześniej przypominały „leniwego kota korporacyjnego”, pod wpływem możliwości objęcia roli PO nagle odżywały. W tej nowej odpowiedzialności pokazywały zupełnie nową stronę siebie taką, której wcześniej nie ujawniały. Tego rodzaju zaangażowania nie było w ich „poprzednim wcieleniu zawodowym”.

7. Nie każdy zespół musi być zbudowany zgodnie z ogólnym schematem

Ostatnia porada, która stawia znaki zapytania przy wcześniejszych, to ostrzeżenie przed wpadaniem w szablony aplikowane z zasady w każdym zespole.

Jeśli tworzysz model współpracy w organizacji produktowej, zachowaj czujność, by nie zamienić go w sztywną procedurę. Nie wprowadzaj schematów typu „wszyscy PO pochodzą z tego działu” albo „każdy zespół musi mieć jednego PO”. Zbyt sztywne podejście może zaciemniać obraz i utrudniać dostrzeżenie niuansów oraz wyjątków od reguły. Nawet jeśli coś zwykle się sprawdza i jest rekomendowane to może się okazać, że w jednym, nietypowym zespole warto postąpić inaczej.

Pamiętaj, że powołanie osoby do roli zarządzającej produktem, w szczególności właściciela produktu w rozumieniu Scrum, to obszar złożony. Wpływa na to bardzo wiele czynników i nad większością z nich nie masz kontroli. Nasze porady bazują na praktycznych obserwacjach, ale nie stanowią gwarancji sukcesu. Warto przefiltrować te wskazówki przez własne wyczucie i kontekst organizacyjny.

Materiały dodatkowe

Polecamy też dodatkowe źródła, które mogą poszerzyć temat „Skąd brać Product Ownerów?”:

• Raport Scrum Alliance na temat kluczowych kompetencji Product Ownera
• Badanie naukowe dotyczące dopasowania roli PO w skali dużych organizacji
• Przewodnik na temat przeprowadzania rekrutacji osób do roli Product Ownera

📄Transkrypcja podcastu „Skąd brać Product Ownerów?”

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Kuba: Pięćdziesiąty piąty odcinek, czyli ten, który na Twoich uszach, będzie na temat odpowiedzi na pytanie – skąd brać Product Ownerów? Skąd w ogóle takie pytanie i dlaczego postanowiliśmy poruszyć ten temat? Zaskakująco często jest to pytanie, które do nas wraca, czy to na szkoleniach, gdy rozmawiamy o odpowiedzialności Product Ownera, czy to w czasie konsultacji podczas transformacji, czy uruchamiania zespołu. Ok, fajnie, skąd wziąć Product Ownera? Skąd wziąć osobę do tej roli? Jak ją gdzieś tutaj wybrać, czy ustanowić w ramach firmy? Poświęcimy odcinek calutki tylko i wyłącznie na takie szerokie odpowiedzenie na to pytanie, bo odpowiedź nie jest prosta, łatwa, przyjemna i dwuzdaniowa. Myślimy, że ten odcinek będzie szczególnie wartościowy dla osób, które stoją przed odpowiedzią na takie pytanie. Wybierasz lub wybieracie w ramach większej grupy w firmie Product Ownera, w trakcie właśnie transformacji zwinnej, albo w ramach istniejących już zespołów zwinnych trzeba danego Product Ownera zastąpić, bo na przykład Product Owner awansował, albo zmienił firmę, czy zmienił jakoś miejsce w strukturze, no i musimy zastąpić istniejącego Product Ownera kolejną osobą. Jeśli jednak nie jesteś w takiej roli, osoby, która decyduje o powołaniu nowych Product Ownerów, to i tak liczymy z Jackiem, że będzie wartość i inspiracja z tego odcinka, no bo tutaj prawdopodobnie w takim razie jesteś w funkcji wspierającej zespoły, czy to lider zespołu, czy to kierownik projektu, czy to Scrum Master, Agile Coach. Ta dyskusja, którą za chwilę opowiemy, czy te przykłady prawdopodobnie fajnie, jeśli umiesz lub będziesz umieć odtworzyć takie argumenty również i zabrać również głos w tego typu procesach.

Jacek: Struktura tego odcinka będzie następująca. Najpierw opowiemy o wzorcach, skąd brać Product Ownerów i wskażemy tutaj bardzo konkretne przykłady, na bazie naszych doświadczeń, a następnie podzielimy się konkretnymi poradami w kontekście wybierania miejsc, z których Product Ownerów będziemy do naszej organizacji, nazwijmy to – sprowadzać. O konkretnych pułapkach odpowiedzialności Product Ownera, opowiemy z kolei w kolejnym odcinku. Jest kilka powtarzających się wzorców, które najczęściej obserwujemy, jeśli chodzi o wybór miejsca, skąd pochodzi Product Owner i teraz po tych najczęściej powtarzających się wzorcach przejdziemy.

Kuba: Natomiast podkreślę, że te wzorce wymieniamy w kolejności, powiedzmy, że losowej. Więc w szczególności nie wyciągajcie wniosków, że coś jest najpierw, a coś jest potem. Pierwsza taka rzecz z naszego przemyślenia, czy z listy, to funkcja Product Managera. Mówimy tu o organizacjach, w których struktura w jakiś sposób produktowo jest już poukładana, albo częściowo w biznesie takie funkcje istnieją. Osoba, która dzisiaj zarządza produktem, decyduje o jego rozwoju, czy decyduje o jakichś jego poszczególnych aspektach, w realiach firmy, która wykorzystuje Scruma, może być dobrym kandydatem na funkcje Product Ownera i wejście w tę odpowiedzialność scrumową, łącząc jednocześnie w firmie funkcję zarządzania produktem.

Jacek: To właściwie mogłoby otworzyć kolejny wątek pod tytułem, czy to Product Manager ma, nazwijmy to pod sobą Product Ownera, który odpowiada za dostarczanie? Bo taki sposób pracy bardzo często obserwujemy w organizacjach. Czy może jest w drugą stronę? Że to Product Owner zarządza produktem i w swoim otoczeniu ma Product Managerów, którzy dostarczają Product Ownerowi wsadu do podejmowania decyzji. Czy może tak naprawdę to powinno być tak, że Product Owner, to jest pewna odpowiedzialność przypisana do osoby, która ma funkcję Product Managera w organizacji? Czyli de facto mamy obie, tak nazwijmy to odpowiedzialności, czy zakresy odpowiedzialności mamy skupione w jednej osobie i na pewno nie będzie to odcinek, w którym będziemy dywagować na ten temat. Natomiast dla takiej przejrzystości i czystości tej myśli Kuby, myślę, że warto ten kontekst dodać, ponieważ różne organizacje różnie sobie tę strukturę organizują.

Kuba: Jak taką dywagację pociągnąłeś, to ja dopowiem jedną ważną rzecz. Taki scenariusz, że powołujemy Product Ownera z kogoś, kto dzisiaj jest w roli Product Managera. To jeszcze, niech to będzie dokładnie tego samego produktu, dotyczyć będzie rola managera i jednocześnie ownera w zespole scrumowym. Wydaje się to być bardzo prosty scenariusz, ale od razu myślę, że jeśli tutaj są gdzieś pułapki, to to, że istniejąca dzisiaj odpowiedzialność i zakres obowiązków Product Managera, może pokrywać się, ale nie w stu procentach z odpowiedzialnością Product Ownera. Taki Product Manager, jeśli był przyzwyczajony na przykład do braku samoorganizacji w realizacji pewnych zadań, no to może mieć na początku pewne wyzwania. Więc niezależnie od tego, że spośród wielu opcji tu się wydaje, że jest praktycznie prawie to samo, to i tak bym zadbał o to, żeby upewnić się i gdzieś tam na początku sobie zakontraktować, że wchodząc w odpowiedzialność Product Ownera scrumowego, odpowiadam za to, za to i za to. Drogi zespole, oczekuję od Was tego, tego i tego. Natomiast nie zakładajmy, że – aha, już mamy gotowca w postaci Product Managera.

Jacek: Kolejny wzorzec, który obserwujemy, to jest wzorzec, w którym Product Owner jest wybierany, nazwijmy to z biznesu. Czyli generalnie poszukujemy Product Ownera wśród osób, które są zdolne decydować w kontekście dostarczanych produktów, czy dostarczanych usług. To, co wyróżnia ten sposób postępowania od porady, którą podzielił się Kuba, jest to, że tutaj generalnie nie będziemy patrzeć na konkretną etykietę. Czyli jakby niezależnie w jakiej roli znajduje się aktualnie nasz kandydat, czy to jest jakiś specjalista z konkretnego obszaru, czy jakiś fachowiec w swojej dziedzinie, czy może jakiś strategiczny Project Manager, może kierownik, tak naprawdę nie chcemy kierować się tymi etykietami, a raczej chcemy się zastanowić, kto na dzień dzisiejszy ma najlepsze kompetencje, ma najlepszą wiedzę i jest w najlepszej pozycji, żeby wziąć za siebie odpowiedzialność produktową.

Kuba: Oprócz kompetencji i wiedzy, to jeszcze bym dorzucił do puli, że decydent pewnie też zreflektuje, czy to jest osoba, względem której jest już w organizacji zaufanie. Czy to jest osoba, która ma autorytet do tego, żeby mieć zdelegowaną odpowiedzialność Product Ownerską? Taką zdelegowaną w takim naszym porządnym zrozumieniu, czyli osoba, która podejmuje decyzje, która rozliczana jest za rezultaty, za wyniki, a nie osoba, którą będzie ktoś sterował, albo ktoś ją będzie ściśle nadzorował. Ten scenariusz, ten wzorzec, że szukamy kogoś właściwego w biznesie, on jest szczególnie potrzebny w organizacjach, które produktowo dzisiaj poukładane nie są, albo te zespoły są tworzone w jakiś taki sposób, który dzisiejszej strukturze trochę się wymyka. No i wtedy jest osobna, dosyć duża kwestia, kto będzie tą właściwą osobą i ta osoba może być powołana z bardzo różnych ról biznesowych. W innego typu firmach dosyć nasuwającym się łatwo kandydatem na odpowiedzialność Product Ownerską, jest obecnie osoba w funkcjach analityka. Zwłaszcza jeśli po stronie biznesowej tej struktury produktowej nie ma. Jeśli nie ma jakiegoś wsparcia, czy współpracy, to może się okazać, że spośród wszystkich możliwych kandydatur, dzisiaj pełniącą rolę osoba analityka, może być kandydatem na Product Ownera. Tu bym się dwa razy zastanowił, czy to jest osoba, która weźmie na siebie taki bagaż myślenia produktowego. No bo wielu analityków też musi przejść też taką ścieżkę z myślenia – robię projekt albo rozwijam system, w zależności od tego, kto ma bardziej jaką optykę. Jednak na perspektywę, buduję pewien produkt, zarządza produktem, takie myślenie product ownerskie procentuje w przyszłości. W małym stopniu dotychczasowi analitycy takie rzeczy uwzględniają, albo tak bardzo się o takie rzeczy martwią.

Jacek: Ja często obserwuję ten wzorzec w praktyce i dobry background analityczny, umiejętność analitycznego myślenia, jakby cała dziedzina wiedzy związana z tym obszarem, to jest coś, co pomaga, co często przykładowo pomaga utrzymać pewien porządek i strukturę w Backlogu Produktu. Pozwala zadawać właściwe pytanie. Jest na pewno takim, powiedziałbym uniwersalnym fundamentem. W sensie zestaw tych kompetencji, które pomagają. Natomiast, tak jak mówi Kuba, będzie się to wiązało z tym, że być może te kompetencje, warto będzie promować w zespole, żeby ostatecznie je wręcz przekazać do Developerów. Natomiast jest do odrobienia na pewno konkretna lekcja związana z tym, jak pozycjonujemy nasz produkt. Jaka jest konkurencja? Być może dojdzie odpowiedzialność za ustalanie jakichś cenników. Tak więc cała masa decyzji takich czysto produktowych, które dla analityka będącego w takim procesie, powiedzmy bezkontekstowym, czyli robię różne analizy na zamówienie różnych osób. To może będzie wymagało tego, żeby tę wiedzę sobie dociągnąć, zdobyć, czy wyrównać. Kolejnym wzorcem, który obserwujemy, jest poszukiwanie Product Ownera pośród osób z szeroko rozumianym doświadczeniem procesowym. Tutaj w szczególności wartościowe może być rozglądnięcie się za osobami, które widziały organizację z różnych perspektyw i pracowały w różnych działach. Czyli przykładowo osoba mogła zaczynać swoją przygodę w jakimś wsparciu Klienta. Mogła przejść następnie do Call Center, żeby zająć się sprzedażą, żeby zająć się jakimś obszarem, kawałkiem produktu i na przykład wejść dopiero z tego punktu w rolę Product Ownera. Czyli taka osoba, która ma dobre zrozumienie, jak działa firma. Dobrze rozumie skąd przychodzą pieniądze. Dobrze rozumie, jakie są produkty, jakie są możliwości, jakie są ograniczenia. Czyli tak bym to sparafrazował. Osoba, która jadła z wielu pieców, co pozwala szeroko spojrzeć na organizację i na pewno z mojej perspektywy ułatwia szybsze odnalezienie się przy konkretnym produkcie, czy usłudze, do której taki Product Owner zostanie przypisany.

Kuba: To jest rada, czy takie miejsce, gdzie byśmy szukali Product Ownerów chyba szczególnie w projektach, w których zwinność jest wykorzystywana niekoniecznie do produktów cyfrowych, czy do rozwoju systemów IT. Zwłaszcza jeśli usprawniamy organizacje, czy usprawniamy jakiś proces, właśnie może się okazać, że te osoby produktowe, albo nie istnieją, albo nie tak patrzą na organizację, jak taka osoba właśnie z doświadczeniem. Nazwijmy to pola bitwy, z doświadczeniem właśnie szerokim, procesowym. Może się okazać, że ta osoba dzisiaj już nawet niekoniecznie jest w tym obszarze, który głównie będzie czerpał z efektów jakiegoś projektu, czy pracy danego zespołu zwinnego. Ale na przykład kiedyś tam była i przy okazji poskakała jeszcze po paru miejscach w firmie. No tutaj jakoś tak to się dzieje, że mamy bardzo dobre skojarzenia z osobami, które gdzieś przechodzą przez wiele miejsc w jednej firmie. Zaczynają widzieć pewne rzeczy trochę szerzej. Szerzej niż optyką pojedynczego zespołu, czy pojedynczego kroku w jakimś takim rozbudowanym procesie biznesowym. Następnym źródłem, z których czasem czerpani są Product Ownerzy, czy osoby wchodzące w tę odpowiedzialność, jest grono Project Managerów. Tutaj w różnych organizacjach funkcja kierownika projektu jest realizowana na różne sposoby, ale widzę taką powiedzmy, wspólną pulę. Niektórzy kierownicy projektu mocno odpowiadają za zakres projektu, za cel tego projektu. Za jakieś osiągnięcie sukcesu. Druga zaleta, o której myślę, która może być mocną stroną Project Managerów, którzy potem przechodzą w funkcje Product Ownera, to jest obycie (szeroko rozumiane) z interesariuszami. Czyli jakaś forma. Po pierwsze znajomości tych różnych gier sił, rozumienie też kto reprezentuje jaką optykę, może nawet już takie zagadnienia związane z tym, kto jest przychylny, kto jest sceptyczny do tego, co realizujemy? No jeśli mamy doświadczenie jako kierownik projektu w ogóle, a już w szczególności w danej firmie, może się okazać, że będziemy też umieć sprawnie sobie poradzić sobie z tymi kwestiami takimi właśnie zarządzania oczekiwaniami. Pogodzenia pewnych rzeczy. Rozwiązania pewnych rzeczy dyplomatycznie. W niektórych organizacjach nie jest to tak potrzebne, ale w innych to może się okazać, że jest kluczowe zagadnienie, które sprawi, że nie każda osoba może wejść w tę funkcję product ownerską.

Jacek: Kolejnym wzorcem jest poszukiwanie odpowiedzialności Product Ownera wśród osób o doświadczeniu technicznym. Wyobraźmy sobie, że mamy produkt, który na koniec dnia jest produktem biznesowym, ale jednak jest na przykład bardzo innowacyjny od strony technologicznej. Pewne zrozumienie i czucie technologii, obycie, świadomość, obcowanie na bieżąco z technologią, może powodować, że to jest właśnie ten insite, który jest nam potrzebny do tego, żeby jakiś konkretny produkt przygotować. Oczywiście, jak mówię o tym możliwym rozwiązaniu, no to jednocześnie przychodzi mi do głowy pewna pułapka, która się wiąże z takim podejściem. Mianowicie widziałem osoby w roli Product Ownera, które ze względu na wcześniejsze doświadczenia techniczne, w znacznym stopniu ograniczały możliwości pracy kreatywnej w zespole, poprzez to, że ta osoba łączyła w sobie często rolę Product Ownera, ale też nazwijmy to rolę takiego wstępnego architekta rozwiązań. No więc właściwie zespół dostawał już gotowe rozrysowane płytki elektroniczne, albo bardzo dobrze przygotowaną jakąś tam strukturę oprogramowania, albo właśnie w rozwiązaniach IoT już gotowy miks, jak ten sprzęt będzie chodził z oprogramowaniem. No, co oczywiście z perspektywy osób będących w zespole, po prostu jest niekorzystne. Pewne rozwiązania, które potencjalnie narodziłyby się w zespole, nie mają już przestrzeni, żeby zakwitnąć.

Kuba: Ten wzorzec z powołania osoby technicznej do odpowiedzialności Product Ownera, jest tutaj na naszej liście. Jest przez nas wymieniony, ale szczególnie chyba bym zaznaczył taką przestrogę, że zwłaszcza w organizacjach, w których transformacja zwinna jest inicjowana po stronie IT, dwa razy się zastanówmy, czy osoby techniczne powoływać do product ownerstwa w zespołach, jednak pracujących na rzecz biznesu. Ta trudniejsza ścieżka poszukania kogoś po stronie biznesowej. Być może namówienia, przekonania, wyjaśnienia. Cała ta zabawa może być o wiele bardziej wartościową ścieżką, niż trochę prostszy scenariusz. Ok, to architekt, analityk systemowy, czy właśnie ktoś z programistów, lider zespołu – te osoby powołujemy. Czasem trzeba. Czasem może nie ma innego kandydata, ale tutaj jednak powody, dla których osoby techniczne nadają się do roli Product Ownera, jednak chyba byśmy zatrzymali do tej sfery produktów, które same w sobie mają naturę bardziej techniczną. To jest może jakiś back end, to są jakieś narzędzia. Coś w stylu cloud, z którego korzystamy, czy jakieś narzędzia do monitoringu. Tam ten Product Owner może być techniczny, bo to jednocześnie jest takie, to jest narzędzie techniczne. Natomiast osoba biznesowa raczej będzie się nadawać do produktów takich biznesowych. Wszystkie te poprzednie wzorce, one wszystkie mówiły o wyłanianiu Product Ownera z istniejących już w organizacji osób w różnych rolach, czy funkcjach. Natomiast dopuśćmy też możliwość zatrudnienia zewnętrznego, zwłaszcza dopuśćmy tę opcję, jeśli tych Product Ownerów mamy trochę więcej. Wtedy to może uzyskać taki fajny efekt, że do istniejących osób, o mocnych kompetencjach właśnie produktowych, procesowych, osobach obytych też w dyplomacji i polityce wewnętrznej, dokładamy też osoby ze świeżym spojrzeniem zewnętrznym, widzące inne organizacje. Być może w naszej branży, być może zupełnie spoza naszej branży. Takie zatrudnienie jest o wiele bardziej ryzykowne, to też sobie głośno powiedzmy, no bo nie do końca będziemy wiedzieć, czy będzie dopasowanie kulturowe. Też ten dystans będzie do pokonania, żeby się wgryźć w ten nasz konkretny produkt, niezależnie od tego, co ta osoba wie, przychodząc do naszej firmy. Mimo wszystko miejmy z tyłu głowy również taki wariant zwłaszcza na takie przypadki, w których w organizacji po prostu struktur produktowych nie ma. Też w wielu firmach nie ma tych funkcji, które wymienialiśmy. Lista jest długa, ale w niektórych organizacjach nie znajdziemy analityka, kierownika projektu, czy osób ze sporym i szerokim doświadczeniem chcącym wejść w tę funkcję product ownerską.

Jacek: W jednej z organizacji, którą wspierałem w procesie zwinnej transformacji, spotkałem się z takim problemem. Mianowicie najlepsi kandydaci biznesowi, którzy byli jakby na krótkiej liście, ostatecznie zostali uznani jako zbyt krytyczni dla biznesu, żeby rezygnowali ze swoich obowiązków i wchodzili w rolę Product Ownera. W tej konkretnej organizacji argument, że właśnie to są najlepsze osoby do tego, żeby stać się Product Ownerem, ostatecznie ten argument nie przekonał osób decyzyjnych. Pojawiła się taka myśl, że trzeba byłoby poszukać osób, które ich te osoby zastąpią, albo ta ich praca będzie musiała być zdelegowana, więc w tej konkretnej organizacji mocno postawili na taki model, w którym zatrudniamy jednak Product Ownerów z zewnątrz, bo te osoby biznesowe są krytyczne. Tak więc to zatrudnienie zewnętrzne, tutaj motywatory mogą być różne. Ja taki kontrargument na to Kuba, co powiedziałeś, jeśli chodzi o to, że przychodzi osoba z zewnątrz – z jednej strony tak, są ryzyka, a z drugiej też spojrzałbym na to z tej perspektywy, że to może być spore odświeżenie. Czyli na przykład, przychodzi Product Owner z organizacji o zupełnie innej kulturze i pokazuje swoją postawą, jak mógłby wyglądać Product Owner ship, w sytuacji, w której osoby, które są wewnątrz organizacji, do której zatrudniamy, czują, że jest jakiś sufit. Czują, że tak nie można, że tak tu nigdy nie było. Bo X, bo Y, bo Z. Tak więc jakby takie rozważne i świadome mieszanie tym zatrudnianiem zewnętrznym i wewnętrznym myślę, że może dać fajne i ciekawe efekty. Podsumowując tę część odcinka, jak widzisz, te miejsca, w których możemy szukać Product Ownerów i te strategie mogą być bardzo różne, trochę inaczej będziemy rekrutować Product Ownerów w organizacjach IT. Trochę inaczej będziemy rekrutować w organizacjach nie IT. Inne spojrzenie będzie w organizacjach, które budują swoje własne produkty. Inne spojrzenie będzie w organizacjach, które raczej świadczą usługi, czyli na przykład software house’y. Tak więc warto dobrać strategię i podejście też konkretnie do firmy, w której się znajdujemy.

Kuba: Natomiast na to pytanie, skąd brać Product Ownerów mamy też taką odpowiedź pod kątem dziewięćdziesięciu stopni. Czyli może nie wprost odpowiadamy na pytanie, skąd brać, bo tutaj już wystarczająco dużo o tym mówiliśmy w pierwszej części, która już jest za Tobą. Mamy też kilka porad takich też mocno z naszych praktycznych doświadczeń. Jakie kwestie wziąć pod uwagę, czy jakimi sprawami się zainspirować, gdy jesteśmy w toku takiego procesu? Reszta odcinka będzie właśnie dokładnie o tych poradach. Zacznę od porady, która w tym temacie – skąd brać Product Ownerów, jest dla mnie chyba najważniejsza. Tutaj już chyba kolejność ma znaczenie, przynajmniej dla mnie. Najpierw zdefiniujmy sobie cel i zdefiniujmy sobie, co jest produktem, a dopiero później myślmy o powoływaniu Product Ownerów. Wydaje się bardzo naturalne, bardzo takie klasyczne – zacznij od celu, zacznij od dlaczego. Natomiast w wielu organizacjach jednak jest takie myślenie przeskakiwania etapu, szukania już od razu gotowych osób, czy chęć powoływania tych Product Ownerów. Zamiast zastanowić się, czy czasami nie ma jeszcze trochę trudniejszej rozmowy do przeprowadzenia. Jak my definiujemy nasz produkt lub produkty firmowe? Jakie są tam naustawiane cele? Jakie są też może priorytety? To jest cała długa rozmowa o tym takim najwyższym poziomie abstrakcji. Strategia, cele, pewne kroki, taktyka rozwoju produktu. Te rzeczy mogą w jakimś stopniu determinować, ilu w ogóle Product Ownerów potrzebujemy i jakich potrzebujemy? O jakiej charakterystyce osób? Jakim poziomie seniority, mówiąc po staropolsku? Jakim poziomie może wewnątrz firmowych? To wszystko może determinować, w o wiele większym stopniu kogo potrzebujemy, niż to, kogo mamy dostępnego, bo czasami możemy w taką pułapkę wpadać. Odwrotnej inżynierii. Mamy tych pięć osób, to do nich dopasujemy całą resztę. To nie jest dobry pomysł, bo te momenty takie powiedzmy transformacyjne, one są dosyć rzadkie w organizacjach. Nawet organizacje, które są dynamiczne, to i tak akurat takich kluczowych osób, no nie zmieniają tak często. Firma może wiele miesięcy zostać z pewnym układem, który jest pokłosiem złego rozpoczęcia rozmowy.

Jacek: Druga wskazówka, którą chcemy się podzielić, jest taka, żeby dzisiejsza, ta aktualna struktura i role, które mamy w organizacji, nie powinny determinować obsadzania odpowiedzialności Product Ownera. Czyli przykładowo, takim bardzo popularnym wzorcem jest pomysł, żeby aktualnych kierowników, konkretnych działów, czy obszarów nominować do roli Product Ownera, albo wybierać ich z jakiejś jednej, konkretnej struktury. Bardzo często przejście na myślenie produktowe, też to, co Kuba powiedziałeś – ilość tych wymiarów, jakie możemy sobie przyłożyć do produktu, żeby w ogóle też dobrze zrozumieć, co jest produktem, powoduje, że stary sposób zorganizowania organizacji może być już niekompatybilny z tym, jak zaczęliśmy w procesie zwinnej transformacji myśleć, czym w ogóle jest nasz produkt i gdzie leży wartość. Tak więc warto spojrzeć szerzej. Warto odsunąć to takie przyjemne uczucie, że wiemy, gdzie powinniśmy zajrzeć i właściwie tam już tych Product Ownerów mamy. Raczej tutaj byśmy rekomendowali z Kubą, żeby zmazać tablicę. Zacząć od pustej kartki. No i faktycznie wyjść bardziej od potrzeb, niż od tego, co aktualnie mamy na stole. 

Kuba: Trzecia rada, ona dalej jest bardzo podobna do tego wątku, który już był poruszony. Skupmy się na potrzebnych kompetencjach, a nie na giełdzie nazwisk, które mamy do dyspozycji. Może się okazać, że taka transformacja na przykład, może być okazją do rewizji istniejących w dzisiejszych rolach biznesowych osób i takiej refleksji, czy to są faktyczne osoby, którym zaufamy, czy powierzymy tę odpowiedzialność produktową. Może się też okazać, że w jakimś miejscu mamy trochę więcej tych kompetencji, niż są potrzebne, więc ta pula może się nam dosyć w ciekawy i taki nieoczywisty sposób budować. Zdefiniujmy sobie potrzebne kompetencje, czyli z tych poprzednich porad już wynika, nie patrzymy na strukturę, patrzymy mocno na to, jaki produkt, jaki cel jest. Popatrzmy też na to, jakie mamy kompetencje, jakie mamy osoby, którym jesteśmy gotowi powierzyć pewną odpowiedzialność, a niekoniecznie od razu szafujmy, czy operujmy imionami, nazwiskami. Tutaj tak, no to jest delikatna sprawa, ale patrząc na te procesy w różnych organizacjach, widzę jednak taką pułapkę. To może Kowalski? Nie, Kowalski nie. Ale takie jest niedopowiedzenie, bo ktoś tam coś źle o nim myśli. I takie wspólne myślenie nazwiskami na wczesnym etapie takiego powoływania Product Ownerów może zapętlać, czy może uruchomić taką rozgrywkę bardziej polityczną, niż w tym miejscu akurat by się przydało, jak najwięcej bardzo racjonalnego, takiego bardzo może nawet nieludzkiego podejścia. OK, najlepsi kandydaci, najlepsze osoby do tej funkcji. Osoby, które oczywiście same tego chcą, ale też osoby, które organizacja chce powołać do tego.

Jacek: Kolejna porada jest taka, że warto w procesie wybierania zwrócić uwagę na to, w jakim stopniu konkretna osoba zna produkt i otoczenie, niż na to, jak ta osoba radzi sobie z pracą zwinną. Moje doświadczenie jest takie, że te kompetencje zwinne, pomimo iż jest to bardzo szeroki obszar wiedzy, one co do zasady są prostsze do przyswojenia, niż w jakimś takim przyspieszonym kursie, odtworzenie przykładowo pięciu lat obecności na rynku jakiejś osoby biznesowej. Tak więc osobiście rekrutując Product Ownerów w przeszłości przede wszystkim zwracałem uwagę na to, jak ta osoba odnajdzie się biznesowo i dopiero w drugim kroku patrzyłem na kompetencje zwinne, no bo wiedziałem, że to kompetencje zwinne będziemy w stanie w szybki sposób uzupełnić, nadrobić. Łatwo też było z postawy osoby odczytać taką powiedzmy estymatę, ile czasu zajmie tej osobie przyswojenie tej wiedzy. Właściwie po takiej rozmowie już jakby czułem, czy ta osoba w ogóle ma chęć, żeby tę wiedzę uzupełniać, czy nie. Natomiast ta znajomość produktu i taka umiejętność odnalezienia się biznesowego z naszej perspektywy, no jest tutaj jakby takim kluczowym czynnikiem. 

Kuba: Dopowiem taki ważny przypadek w kontekście tej rady, że to może być szczególnie istotne, czy warto sobie to wziąć szczególnie do serca w momencie, gdy nasza organizacja jest już w toku pracy w jakiś sposób zwinny i chcemy to zreorganizować, zrewidować, przenieść na jakiś nowy poziom. Coś, co widuję czasem w niektórych organizacjach, to to, że jednym z punktów – powiedzmy takiej do usprawnienia jest to, jakie osoby powołaliśmy do roli Product Ownera. Na przykład, jeśli te dotychczasowe osoby w roli Product Ownera z jakiegoś powodu nie domagają, to czasami argumentem na ich rzecz jest – no dobra nie domagają, ale już, chociaż znają Scruma. Może się okazać, że to, że znają Scruma, to jest akurat najmniejszy argument za. No bo poznać tego Scruma, od tego jest Scrum Master, od tego jest zespół. To nie jest jakiś kosmos, żeby tutaj sprawnie funkcjonująca w środowisku biznesowym osoba jeszcze bez tych doświadczeń nie mogła tego nadrobić. Natomiast, tak jak Jacek mówi – nadrobić pięć lat doświadczeń w biznesie, być może też z innych organizacji w tych funkcjach, to może nie być do nadrobienia. To jest tylko pewne wyobrażenie, jak to funkcjonuje i o wiele trudniejsze zagadnienie. Następna porada, którą warto też sobie rozważyć to to, że tak sięgamy pamięcią i nie widzimy ścisłej korelacji między tym, że ktoś się sprawdził fajnie w odpowiedzialności Product Ownera i jednocześnie był mocno cenionym pracownikiem w poprzednich swoich rolach. Czyli tak obierając to z dyplomacji, to nie jest tak, że do Product Ownerów trzeba wybierać same dzisiaj gwiazdy w swoich funkcjach, bo może się okazać, że te kompetencje product ownerskie jakby chowają się u osób, które dzisiaj gdzieś tam wpadły w jakąś boczną uliczkę, może trochę osiadły w dzisiejszej swojej funkcji, czy zawodzie. Więc tutaj bądźmy czujni na, to gdy rozważamy różne kandydatury, czy nie oceniamy tych kandydatur przez to, jakim dzisiaj ktoś jest świetnym kierownikiem projektu, analitykiem, czy Product Managerem. No zadajmy sobie pytanie – jak przewidujemy, czy kogo potrzebujemy do funkcji product ownerskiej, bo niektóre z tych argumentów, że ta osoba jest dzisiaj gwiazdą kierowania projektami na przykład, może się okazać, że to do roli Product Ownera będzie wręcz obciążeniem, a nie tylko neutralne. Więc tutaj bądźmy czujni na to, że dzisiejsze gwiazdy w innych funkcjach niekoniecznie będą gwiazdą product ownerską i na odwrót. Fajnie rozkwitają, czy rosną w tej odpowiedzialności osoby, które wcale nie były gdzieś tam na szczycie różnego rodzaju rankingów wydajności, czy takiej powiedzmy sławy wewnątrz organizacyjnej.

Jacek: I nawiązując do tego rozkwitania, o którym mówisz, ważne z naszej perspektywy jest to, żeby dać osobom się wykazać. Co tutaj mamy na myśli? Nasze doświadczenie jest takie, że na pewnym etapie ważniejsze może być nastawienie i taka gotowość podjęcia wyzwania, niż powiedzmy sobie to, co wynika z konkretnego CV danej osoby. Tak więc taki przykład. Spotkałem się z osobami, dla których motywacja, żeby wejść w rolę Product Ownera była na tyle wysoka, że właśnie z takiego leniwego kota korporacyjnego w momencie, kiedy dostały opcję zrobienia czegoś nowego, świeżego i to miało taki charakter ekspedycji, wyprawy, jakiejś takiej fajnej przygody, no to nagle ta osoba odżywała no i się okazywało, że pełniąc tę konkretną odpowiedzialność, jakby pokazuje się od zupełnie innej strony, czego nie robiła – nazwijmy to, w swoim poprzednim wcieleniu. Więc to nastawienie, gotowość chęci, no one często są takim wskaźnikiem, który może, ale oczywiście nie musi być dobrym tropem, który może być pomocny przy wyborze Product Ownera. 

Kuba: I ostatnia porada, która w dużym stopniu przekreśla, albo inaczej – stawia znaki zapytania przy poprzednich, to kwestia niewpadania w szablony. Nie wpadania w szablony na dwóch poziomach. Pamiętajmy, że takie powołanie osoby do takiej roli właśnie zarządzającej produktem, czy właśnie tutaj bycie właścicielem produktu w rozumieniu scrumowym to jest domena złożona. Jest tyle czynników i to na większość z nich nie mamy wpływu, które mogą determinować, że ktoś się sprawdzi, a ktoś się nie sprawdzi. Że nie ma jednej jedynej słusznej drogi. Część z tych naszych porad, czy propozycji raczej wspomina o tym, co w praktyce zaobserwowaliśmy, ale to nie jest recepta na sukces. Po pierwsze, sami to sobie przefiltrujmy przez swoje wyczucie, ale też, nawet jeśli w ramach organizacji tworzymy jakiś model współpracy, to bądźmy bardzo, bardzo czujni na to, czy nie proceduryzujemy, czy właśnie nie wprowadzamy jakiegoś szablonu, że wszyscy Product Ownerzy są stąd, albo każdy zespół ma jednego Product Ownera. Może się okazać, że takie zbyt sztywne, zbyt twarde podejście nam tutaj psuje, czy zaciemnia obraz na pewne niuanse, pewne odstępstwa od reguł. Nawet jeśli co do zasady coś mocno rekomendujemy, albo zazwyczaj nam się sprawdza, to może się okazać, że w tym jednym, jedynym nietypowym zespole, albo w tym jednym układzie zachowajmy się trochę inaczej. Czyli uważajmy na takie szablony. Uważajmy tutaj na tabelki, zasady, wytyczne i te takie mocne reguły typu zawsze, albo nigdy, albo każdy, bo się łatwo wyłożymy. Niestety pojedyncze zespoły, czy nawet całe kawałki firmy mogą bardzo na tym ucierpieć, jeśli sobie zaaplikujemy „One way of working” i jedna ścisła wytyczna, jak to ma być na przykład z powołaniem właśnie Product Ownera.

Jacek: Ta porada, którą się podzielił, to jest ostatnia porada, którą dla Ciebie mamy w dzisiejszym odcinku. Wszystkie notatki z tego odcinka wraz z linkami do materiałów, które wspominamy, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/55.

Kuba: Kuba: Wiemy z ankiety, że słuchacie nas nie zawsze zaraz po nagraniu i że sięgacie też do odcinków archiwalnych, które, mimo że powstały kilka lat temu, no naszym zdaniem nadal mają sens. Nadal się pod nimi podpisujemy. Istnieje spora szansa, że też ten odcinek słuchasz później niż pod koniec stycznia 2021, a wtedy go planujemy oryginalnie wypuścić. Jeśli szukasz bieżących informacji, co jeszcze robimy oprócz podcastu, znajdziesz je na naszej stronie, na Facebooku i  na Linkedinie. Zachęcam Cię do obserwowania tych kanałów, jeśli jeszcze tego nie robisz. Może w momencie, gdy tego słuchasz mamy dla Ciebie coś ciekawego do zaproponowania. Sprawdź to! 

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

———

To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę!