Skąd brać Product Ownerów?

Ten odcinek zainteresuje w szczególności osoby, które stoją przed wyborem Product Ownera i nie wiedzą, gdzie go znaleźć. Pytanie „skąd brać Product Ownerów” nieustannie powtarza się w naszej codziennej pracy z klientami, dlatego zdecydowaliśmy się dogłębnie na nie odpowiedzieć w odcinku. W trakcie odsłuchu poznasz najczęstsze wzorce poszukiwania Product Ownerów oraz kilka wskazówek, na co zwrócić szczególną uwagę.

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Zobacz wersję wideo:

TRANSKRYPCJA

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.