Product Owner co to za wymysl?

Witam,

Procuje od niedawna w nowej firmie. Cala grupa progamistow zarzadza Product Owner. Moje pytanie co to qur**** jest? Generalnie gosc siedzi i nic nie robi i w sumie co sie dziwic jak nie jest powiazany ze swiatem IT. Pracuje juz kila lat, a jak mowimy o cron job to nie ma bladego pojecia co to jest. Moje pytanie czy ktos pracowal z PO i jakie sa jego kluczowe obowiązki w pracy? Osobiscie uwazam, ze PO powinien wiedziec wszystko na temat projektu ze strony uzytkownika, ale on nawet tego nie wie. Cokolwiek jego nie zapytam to on nie wiem... I mowie tutaj o pytanie nieprogramistyczne. Po co komu PO? Do generowania wiekszych kosztow czy jak?

Hejtujesz rolę PO w podejściu Scrumowym czy ziomka z firmy?

Nie hejtuje, nie widze sensu istnienie w mojej druzynie PO. Ziomek sam w sobie jest ok. Ale jak widze, ze np mamy deadline caly team zapierdziela. My cos sie go pytamy, a on na luzie odpowiada, ze on w sumie nie wiem, zeby tam osobe 3cia zapytac. Ja biore odpowiedzialnosc za swoja prace i rzadko odpowiadam zdaniem nie wiem, albo spytaj sie kogos tam.

Wydaje mi sie, ze nasz PO wali troche w konia w robocie, ew ja nie rozumiem jego obowiazkow w pracy.

Może jego rola wynika z religijnego podejścia do Scruma? Nikt nie wie co PO ma dokładnie robić, ale w podręczniku napisane, że musi być :P

PO jest potrzebny przy wiekszych firmach.

PO (taka jaka ma mialem) przygotowala Acceptance Criteria i bronila (i rzeczywiscie to robila) przed PM. Jak odeszla na chorobowe to w ciagu 2 tygodni z kilku featurerow spadlismy do jednego

Tam gdzie pracowałem w metodyce scrum, PO rozwiązywał problemy, które napotykał zespół i zespół nie był w stanie dalej pójść ("drogi PO blokuje nas to i tamto"), podejmował decyzje, które user stories są ważniejsze i które powinny być dostarczone w ramach najbliższego sprintu. Nie znał się na technikaliach.

PO to powinien być gość który ustala listę ficzerów do zaklepania oraz priorytety.

PO dowiaduje się jakich ficzerów chcą klienci i ustala, czy i kiedy będą implementowane. Nie bardzo wiem jak taki ktoś miałby "zarządzać grupą programistów", ale jestem pewien, żeby lepiej tego nie próbował, bo sama taka myśl cuchnie jakimś mikromanagementem.

poniatowski napisał(a):

Witam,

Procuje od niedawna w nowej firmie. Cala grupa progamistow zarzadza Product Owner. Moje pytanie co to qur**** jest? Generalnie gosc siedzi i nic nie robi i w sumie co sie dziwic jak nie jest powiazany ze swiatem IT. Pracuje juz kila lat, a jak mowimy o cron job to nie ma bladego pojecia co to jest. Moje pytanie czy ktos pracowal z PO i jakie sa jego kluczowe obowiązki w pracy? Osobiscie uwazam, ze PO powinien wiedziec wszystko na temat projektu ze strony uzytkownika, ale on nawet tego nie wie. Cokolwiek jego nie zapytam to on nie wiem... I mowie tutaj o pytanie nieprogramistyczne. Po co komu PO? Do generowania wiekszych kosztow czy jak?

Zasadniczo powinieneś iść do waszego scrum mastera z takimi pytaniami w razie wątpliwości.

yarel napisał(a):

Tam gdzie pracowałem w metodyce scrum, PO rozwiązywał problemy, które napotykał zespół i zespół nie był w stanie dalej pójść ("drogi PO blokuje nas to i tamto"), podejmował decyzje, które user stories są ważniejsze i które powinny być dostarczone w ramach najbliższego sprintu. Nie znał się na technikaliach.

U mnie jest podobnie. Do tego PO to łącznik między devami a klientem - ogarnia wymagania itp. Może mam spaczony obraz scrum mastera ale u nas w zespołach scrum masterami są zazwyczaj team leaderzy, i tak naprawdę ich rola sprowadza się do prowadzenia codziennych spotkań.

@Aventus: We wcześniejszych pracach w IT, tez najlepszy programista prowadził scrum ( zazwyczaj team lead albo PR). W obecnej pracy PO prowadzi scrum i co lepsza nawet nie mówi co robi. Każdy powie od siebie w kilku zdaniach co zrobił wczoraj, co zamierza zrobić dziś itd. A on nic nie mówie. Czasem ktoś z teamu pyta się go na koniec. A ty co dziś będziesz robić, to się zawsze głośno śmieje i tylko mówi, że ma tam jakieś spotkanie albo, że musi, gdzieś zadzwonić i tyle.

U mnie PO odbiera bury, broni nas i głównie rozmawia z klientami. Poprzednio też tak bylo.

Aventus napisał(a):

yarel napisał(a):

Tam gdzie pracowałem w metodyce scrum, PO rozwiązywał problemy, które napotykał zespół i zespół nie był w stanie dalej pójść ("drogi PO blokuje nas to i tamto"), podejmował decyzje, które user stories są ważniejsze i które powinny być dostarczone w ramach najbliższego sprintu. Nie znał się na technikaliach.

U mnie jest podobnie. Do tego PO to łącznik między devami a klientem - ogarnia wymagania itp. Może mam spaczony obraz scrum mastera ale u nas w zespołach scrum masterami są zazwyczaj team leaderzy, i tak naprawdę ich rola sprowadza się do prowadzenia codziennych spotkań.

Tak, PO też realizował podobne zadania. Czasem struktura projektu wyglądała tak:

#K zespołów scrumowych - #L PO - #M architektów - #N klientów końcowych

• Klienci końcowi chcą różne funkcjonalności.
• PO pilnują by funkcjonalności zostały dostarczone w odpowiednim czasie dla klientów końcowych.
• Architekci starają się funkcjonalności ujednolicić bądź uogólnić i sprawić by się ze sobą nie "gryzły".
• Zespoły implementują.

SM jest osobną rolą - pilnuje by w sprincie zespół nie brał za dużo (tj. uwzględnia urlopy, święta, inne okoliczności i koryguje produktywność w dól, np.0,80 * srednia produktywosc zespolu per sprint, robi retrospekcje, na spotkaniach planingowych pilnuje by ludzie grali w scrum pokera i by zadania związane z user stories rozbijać na części, które da się zrobić w ciągu 1 dnia, oblicza jakieś tam velocity ).

Dodatkowo, scruma udawało się robić "zdalnie" wykorzystując:

• codzienne telekonferencję
• "wirtualnego" kanban boarda

Co do opisanego PO w wątku inicjalnym, to wydaje mi się, że sam nie musi wykonywać wszystkiego, tylko umożliwiać realizację czegoś i upraszczać problemy.
Oczywiście są różni ludzie i mają różny stosunek do pracy :-)

na spotkaniach planingowych pilnuje by ludzie grali w scrum pokera

Czyli jest przedszkolanką.

koryguje produktywność w dól,

Fakt, zbyt wysoka produktywność to w Scrumie grzech i się ją celowo obniża, żeby wyrównać velocity.

oblicza jakieś tam velocity

"jakieś tam velocity" to dobre określenie na coś, co nie ma żadnego odniesienia do rzeczywistości, a wynika z jakichś tam cyferek wymyślonych z kosmosu na estymacjach...

Może ma wiedzę biznesową, albo ogólnoprojektową. A nawet jeśli nie to nie widzę problemu. Skoro pracodawca mu płaci, znaczy że uważa go za wartego swojej ceny. I tylko problemem pracodawcy jest wydajność lub jej brak u jego pracowników. Chcącemu nie dzieje się krzywda. Masz 4 dobre rozwiązania:

1. Zaakceptować to jak jest.
2. Pogadać z szefem by próbować wyjaśnić sytuację.
3. Pogadać z PO i spróbować wyjaśnić sytuację.
4. Nie akceptować tej sytuacji i zmienić pracę.

A wybrałeś opcję nr 5: nic nie robić i żalić się na forum.

LukeJL napisał(a):

na spotkaniach planingowych pilnuje by ludzie grali w scrum pokera

Czyli jest przedszkolanką.

koryguje produktywność w dól,

Fakt, zbyt wysoka produktywność to w Scrumie grzech i się ją celowo obniża, żeby wyrównać velocity.

oblicza jakieś tam velocity

"jakieś tam velocity" to dobre określenie na coś, co nie ma żadnego odniesienia do rzeczywistości, a wynika z jakichś tam cyferek wymyślonych z kosmosu na estymacjach...

Nie czuję się w scrumie doświadczony, ale uważam, że z czasem estymacje stają się dokładniejsze (ile można się machnąć jak bardzo złożone jest zrobienie formularza i zapisanie danych w jakimś repo?) Dla mnie story pointsy są wyznacznikiem złożoności, a nie czasochłonności. Spotkałem się z założeniem, że 1 sp = 1 mendaj, co wg mnie jest głupie, bo trudność zadania nie zmienia się, a czasochłonność zależy od doświadczenia programisty. Ot takie punkciki jak "function pointy" czy "snapy", tylko inna metodyka to nazwa inna, a koncept podobny (zmierzyć rozmiar zadania).

Zespołowi to velocity nie wiem czy jest potrzebne, natomiast na poziomie zarządzania zespołami może być pokazywać, że zespół "dotarł się", ustabilizował produktywność, jak wypada na tle innych zespołów, ile czasu może zając osiągnięcie średniej/pełnej produktywności. Na poziomie zarządzania rozwojem produktów daje pewne pojęcie na temat tego co można założyć w roadmapie na rok, +2 lata, +3 lata (i czy to będzie miało pokrycie w mocach przerobowych firmy). Takie informacje zespołowi nie są potrzebne, bo zespoły pracują w innym horyzoncie czasowym.

Dzielę się po prostu wrażeniami i chętnie czytam o doświadczeniach innych. Ostatnio jakoś mniej ochoty na trollowanie czy złośliwośći, chyba pogoda jest temu winna :P

Ot takie punkciki jak "function pointy" czy "snapy",

Snapy? O użyciu snapchata do estymacji jeszcze nie słyszałem. W jaki sposób to się odbywa?

Na poziomie zarządzania rozwojem produktów daje pewne pojęcie na temat tego co można założyć w roadmapie na rok, +2 lata, +3 lata

Nierealistyczne. Przez 2-3 lata zespół może się rozlecieć, produkt może zostać przerwany, okoliczności rynkowe mogą się zmienić.

Poza tym - do zespołu mogą dojść nowi ludzie (czyli też wydajność się zmieni), sam zespół może nabrać nowej wiedzy (przez nieprzerwane 2 lata nad jednym produktem zespół powinien już o wiele szybciej robić te same rzeczy, ponieważ wie już jak, ma know how), ale np. może się zmienić stack technologiczny (np. przepisujemy wszystko z Pythona na NodeJS) albo platforma (np. była apka desktopowa, a będzie apka webowa). I to wszystko i tak zaora pieczołowicie wyliczaną "velocity".

Oczywiście, może istnieją projekty/dziedziny, które wymagają starannego planowania i w których waterfall bardziej się opłaca niż podejście zwinne, ale wydaje mi się, że najczęściej to ten uwielbiany przez kierownictwo waterfall i planowanie wszystkiego z dużym wyprzedzeniem jest czymś, co się nie sprawdza i co kończy się dużymi opóźnieniami (bo nie da się wszystkiego przewidzieć), albo chaosem (bo i tak będą zmiany w wymaganiach, nawet jeśli kierownictwo sobie coś naiwnie zaplanowało na 2-3 lata z wyprzedzeniem).

Z doświadczenia mogę powiedzieć iż oszacowania są tym lepsze im bardziej szacowane zadanie jest podobne do wcześniejszych zadań, które się robiło. Jednak jeśli zadania są do siebie mocno podobne (w sensie przebiegu wykonania) to znaczy, że automatyzacja pracy kuleje. Mamy więc dwa sprzeczne cele - albo automatyzujemy pracę albo tworzymy zadania, które łatwo oszacować.

A ja mam aktualnie bardzo fajnego PO.

Gość jest obecnie mocno biznesowy, siedzi w firmie już chyba z 10 lat i zanim do nas dotarł to przeszedł przez kilka działów, więc bardzo dobrze rozumie biznes jaki robimy od strony różnych działów. On jest odpowiedzialny za nasz produkt, odpowiada za jego wdrażanie w filiach w różnych krajach, konsultuje różne sprawy / problemy z lokalnymi konsultantami oraz jest bezpośrednio odpowiedzialny za nasz produkt przed zarządem. Jak któryś z działów chce go rozbudowywać to on mówi na kiedy to jest możliwe, ustala dla nas mapę drogą na cały rok, uzgadnia z zarządem i dyrektorami działów jakie featuresy zrobimy w danym roku. W sumie już nam się nieco produkt rozrósł, więc jaki inne działy czegoś mocno potrzebują, to robimy im nową apkę \ rozszerzenie w ramach naszej apki. itp.

Generalnie dla nas ten człowiek jest pośrednikiem pomiędzy nami, a np. działem sprzedażowym. Zbiera wymagania z odpowiedniego działu i to on podejmuje decyzje wiążące dla programistów, jak jakiś features ma wyglądać. Głównie pod kątem biznesowym (czy i na jakie kompromisy możemy sobie pozwolić), ale czasami również pod względem UI / UX (uwagi klienta lub swoje własne).

Zarząd jak chce nową rzecz, to nie idzie bezpośrednio do programistów, tylko wzywa PO na dywanik. I on im mówi, jakie aktualnie mamy zadania, jaki przerób i na kiedy ewentualnie możemy coś dostarczyć nowego.

W roli PO bardzo ważne są dwie rzeczy: ta osoba musi rozumieć biznes, który robi (i rolę produktu w tym biznesie) oraz być osobą decyzyjną. To ona podejmuje decyzje wiążące dla programistów, kiedy natrafiamy na ścianę i mamy kilka wersji obejścia (każda wiąże się z innymi konsekwencjami).

U mnie bardzo ambitny PO staral znalezc sobie prace w pracy ale z tego co widze to w porownaniu do deva albo testera to takie stanowisko wydmuszka bo scrum, bo inne korpo majo i bo kobiety przeciez musza miec cos.
Zajmuje miejsce i pracujemy na niego a czasami nawet niepotrzebnie komplikuje.

LukeJL napisał(a):

Ot takie punkciki jak "function pointy" czy "snapy",

Snapy? O użyciu snapchata do estymacji jeszcze nie słyszałem. W jaki sposób to się odbywa?

Nie o te snapy chodzi :D http://www.ifpug.org/about-snap/

Na poziomie zarządzania rozwojem produktów daje pewne pojęcie na temat tego co można założyć w roadmapie na rok, +2 lata, +3 lata

Nierealistyczne. Przez 2-3 lata zespół może się rozlecieć, produkt może zostać przerwany, okoliczności rynkowe mogą się zmienić.
Poza tym - do zespołu mogą dojść nowi ludzie (czyli też wydajność się zmieni), sam zespół może nabrać nowej wiedzy (przez nieprzerwane 2 lata nad jednym produktem zespół powinien już o wiele szybciej robić te same rzeczy, ponieważ wie już jak, ma know how), ale np. może się zmienić stack technologiczny (np. przepisujemy wszystko z Pythona na NodeJS) albo platforma (np. była apka desktopowa, a będzie apka webowa). I to wszystko i tak zaora pieczołowicie wyliczaną "velocity".

To, że będzie jeden zespół więcej, bądź w zespole zmieni się połowa składu, to jak to wpływa na średnią? Patrząc przez pryzmat 1 zespołu czy produktu trudno się nie zgodzić, że może to być tragedia. Jednak, gdy firma ma wiele produktów i wiele zespołów, to tego typu zmiana może być po prostu niezauważalna.

W ustawieniu, w którym brałem udział, było 12 zespołów scrumowych o podobnej konfiguracji (2 dev Java, 1 dev C, 1 dev C++, 1 .netowiec, 2 testerów - automatyczny + klikacz),
rozwijających 1 produkt (firma ma spore R&D). To, że ktoś decydował opuścić firmę nie wywoływało efektu motyla ;-) Co do stosów technologicznych, to w wybranej technologii pracuje zespół, który się na niej zna (więc już ma ustabilizowaną produktywność), ewentualnie firma decyduje się zainwestować w nową technologię, wówczas trudno oczekiwać dużej produktywności na samym początku.

Oczywiście, może istnieją projekty/dziedziny, które wymagają starannego planowania i w których waterfall bardziej się opłaca niż podejście zwinne, ale wydaje mi się, że najczęściej to ten uwielbiany przez kierownictwo waterfall i planowanie wszystkiego z dużym wyprzedzeniem jest czymś, co się nie sprawdza i co kończy się dużymi opóźnieniami (bo nie da się wszystkiego przewidzieć), albo chaosem (bo i tak będą zmiany w wymaganiach, nawet jeśli kierownictwo sobie coś naiwnie zaplanowało na 2-3 lata z wyprzedzeniem).

Do podejmowania decyzji nie potrzeba aptekarskiej precyzji. Jak masz np. produkcję ziemniaka, to znajomość średniej wydajność z ha + wielkość powierzchni gruntów pozwoli Ci zaplanować produkcję i nie ma bata, że wyprodukujesz więcej niż wydajność*powierzchnia, więc nie ma sensu brać na siebie zobowiązań w postaci dostawy więcej niż planowana produkcja (ziemniaki możesz zastąpić javą , ilością use casów, areał ilością zespołów scrumowych etc.)

Jak masz np. produkcję ziemniaka, to znajomość średniej wydajność z ha + wielkość powierzchni gruntów pozwoli Ci zaplanować produkcję
i nie ma bata, że wyprodukujesz więcej niż wydajność*powierzchnia, więc nie ma sensu brać na siebie zobowiązań
w postaci dostawy więcej niż planowana produkcja (ziemniaki możesz zastąpić javą , ilością use casów, areał ilością zespołów scrumowych etc.)

Nie wiem, czy masz background bardziej techniczny, czy biznesowy, ale mówisz teraz rzeczy typowo "menedżerskie", czyli zrzucanie wszystkiego do średniej, liczenie metryk, dodawanie, dzielenie... Trochę jak w tym żarcie, że PM jest osobą, która uważa, że skoro 1 kobieta rodzi dziecko w 9 miesięcy, to 9 kobiet urodzi dziecko w miesiąc).

Tylko, że tworzenie oprogramowania to nie do końca sadzenie ziemniaków, czy kładzenie rur (patrz: Dead Poets Society) tylko to bardziej praca twórczo-badawcza, programiści mają więcej wspólnego z artystami albo naukowcami niż z robotnikami, którzy znoszą palety na magazyn i których produktywność można łatwo przeliczyć.

(ziemniaki możesz zastąpić javą , ilością use casów, areał ilością zespołów scrumowych etc.)

Trochę jak "ziemniaki możesz zastąpić odkrywaniem czarnych dziur, czy komponowaniem symfonii, areał liczbą naukowców/muzyków" - będzie miało to podobny sens. Tzn. na pewno jakiś związek nawet w nauce czy sztuce jest (więcej astronomów = szybciej odkrywamy wszechświat; więcej artystów = szybciej powstanie arcydzieło, bo wymiana myśli, inspiracji, wspólna praca nad dziełem itp.), ale mimo wszystko wątpię, żeby był to liniowy związek na zasadzie 9 kobiet urodzi dziecko w 1 miesiąc, co tu chyba próbujesz sugerować.

nie ma bata, że wyprodukujesz więcej niż wydajność*powierzchnia

Tylko, że w programowaniu może się nagle okazać, że trudny problem okazuje się łatwy, bo jest gotowa biblioteka do danej rzeczy. Albo, że kto wpadł na ładne rozwiązanie (i napisał coś w 2 dni, co było estymowane na 2 tygodnie). Albo, znacznie częściej, okazuje się, że skala problemu jest większa i prosty z pozoru problem wymaga dużej pracy i "w kilka dni to napiszemy" zamienia się w miesiąc.

Estymować to można proste zadania, podobne do tych, które programiści robili już ileś razy (mówię już o rzeczach typowo technicznych, np. "zaklepanie formularza logowania, który się połączy potem z backendem" ), a nie całe większe ficzery w produkcie, których stworzenie wymaga współpracy osób z różnych dziedzin (np. frontendowiec, backendowiec, grafik, UX) i które stanowią wyzwanie projektowe i techniczne. Weź jakiś duży projekt, np. zrobienie klona Facebooka i spróbuj go podzielić na user stories i przelicz (dla danego zespołu) czas, w którym tego klona Facebooka będą w stanie wykonać... powodzenia ;)

@LukeJL:
Jeśli chodzi o mój background, to wykształcenie mam ścisłe (matematyka stosowana w finansach) + po dyplomowe z zarządzania, zaś w "IT" od 15 lat (od początku backend, Java, Oracle, systemy uniksowe). Potrafię docenić eleganckie rozwiązania, ale nie patrzę na IT jak na sztukę. Podejrzewam, że takie artystyczne postrzeganie pracy w IT jest postrzegane głównie przez środowisko IT. Artystów jest mało. Jeśli trafiają się malarze, to głównie od ścian i sufitów, zaś większość "dzieł" porusza kiszki, a nie duszę :P

Patrząc na tę anegdotkę o PM i ciąży, to ciążę traktowałbym tu jako niepodzielne zadanie. Wracając do sedna, można na estymatę większego problemu patrzeć jak na kombinację liniową estymat mniejszych problemów (to wersja dla tych, którzy zbytnio przywiązują się do średniej czy jednego czynnika).

To, że zadanie bylo estmowane na 2 tygodnie, zajęło 2 dni, to informacja na przyszłość. Po co zbierane są story points? Po to, żeby mieć podstawę do kolejnej estymacji "podobnego" problemu w przyszłości. Po co się estymuje? Żeby planować.

Po co planować i czy warto planować, a może lepiej "chwytać dzień" albo "żyć na krawędzi"? To już każda organizacja odpowiedzieć musi sobie sama.

Zrobienie "klona FB" jest wg mnie źle postawionym problemem, bo mówi nic n/t funkcjonalności, które należy wyprodukować. Jak masz rozbicie na funkcjonalności to możesz estymować, bo jak nie masz to co chcesz estymować?

@Miang: trudno się nie zgodzić, że w uprawie bierze się pod uwagę różne czynniki, aczkolwiek clue dyskusji nie stanowi uprawa ziemniaków, tylko wymiana doświadczeń, ewentualnie ostry flejm ;-) Flejmem jestem mniej zainteresowany.

Wybrałeś już co zrobisz? Wierzę, że nie stanie mu się krzywda.
IMHO powiedz mu w końcu kiedy skończysz te ficzery i będzie po sprawie

@INTERFERON_ALFA_STG: Nic mu się nie stało. Każde sprint kończę systematycznie i pracę oddaje w mierę w terminie :D Po prostu olałem gościa. Dalej nic nie robi, je 3 razy dziennie jogorty z wysoką zawartościa białka i patrzy na telefon. Jego życie. Moim skromnym zdaniem szkoda kasy firmy i troche to nie jest fair w obec reszty zespołu, poniewaz kazdy mowi o tym, ale co mamy zrobic? Donieść? Troche nie w naszym stylu. Także olać temat. Nie wiem tylko po co wkurzać wszystkich na około o ten status pracy po 2-3 razy na dzien. Z takim irytujacym tonem. To nic nie zmieni, no ale niech pyta. Mi to juz coraz mnie rozprasza.

Tzn? Nie rozumiem? Trzy razy dziennie Cie pyta o to że za trzy dni coś skończysz i trzy razu mu mówisz to samo? Może napisz mu to na jirze?
Czy to może chodzi o jakiś ważny ficzer i się upewnia że będzie?
Tak czy inaczej to z tego co łatwo można wychwycić on jest namiestnikiem Pana w Twoim projekcie. Nie oceniam czy powinienen być jednocześnie SM i PO. Ale że PO wymaga ficzerów to nie jest coś niesamowitego.
Często PO jest właścicielem kilku produktów, bo rzeczywiście jeden może zajmować niepełny etat.
Nie jest jasne w jaki sposób jest zatrudniony bo u mnie np był SC na outsurce i robił u nas jeden projekt i dwa inne równolegle gdzie indziej zdalnie u nas przy biurku.
Totalnie nie rozumiem dlaczego on miałby Ci się tłumaczyć z tego co robi? Jak chodzi o daily to PO nie powinien się wtrącać, poza szczególnymi przypadkami kiedy jego wiedza może coś uzupełnić lub pomoc. Daily to spotkanie dla zespołu, celem jest wymiana wiedzy i ewentualnych doświadczeń, wskazówek. Dla SC mówi się też o tym czy temat idzie zgodnie z harmonogramem i czy istnieją ryzyka. Sam PO zasadniczo jest zazwyczaj avatarem klienta i nie należy do zespołu.

// Ja znam taki scrum z autopsji, nie mówię że jest właściwy

Wyobraź sobie taki przykład, mam mieszkanie w innym mieście Polski. Zanim je wynajmę muszę zrobić remont. Powołuje na product ownera moja koleżankę z tego miasta. Zespołem są robotnicy. PO mnie reprezentuje, wie jaki parkiet, jakie drzwi, jakie płytki i wykończenia sobie życzę. Regularnie odbywa spotkania z robotnikami aby rozliczyć ich z pracy i ocenić postępy.

Mam nadzieję, że rozumiesz że pytanie przez parkieciarza czym się moja koleżanka zajmowała cały tydzień nie jest zbyt na miejscu?

Wątpliwości zostały rozwiane: wszyscy PO to krewni i znajomi królika.

Nawiązując do przykładu z remontem wyobrażasz sobie żebym zlecił bycie PO mojego mieszkania komuś obcemu?

Nawiązując do przykładu z remontem: czego robotnik może oczekiwać od koleżanki?