Co kryje się w Product Backlogu - seria: "Jak żyć?"

Cześć Rafał. Cześć Pawle. Dzisiaj spotykamy się w atmosferze spowolnionego internetu. Zobaczymy co z tego wyjdzie. Miejmy nadzieję, że będzie dobrze. Mam bardzo proste pytanie do Ciebie. Chciałem jeszcze tylko ponarzekać przed pytaniem, że wypiłem właściwie całą kawę, którą sobie przygotowałem na ten odcinek, więc najwyżej zrobimy refill w trakcie. Dobra. Powiedz mi taką prostą rzecz. Dużo się o tym słyszy, mało się o tym mówi. Czym jest Product Backlog? Czym jest Product Backlog? Szalenie istotne pytanie. Miałem taką rozmowę ze swoim tatą.

ze swoim tatą a propos Scruma i innych tam rzeczy. Trochę na kanwie tłumaczenia ludziom niewtajniczonym, co się w życiu robi. No i rozmawialiśmy właśnie, tu była rozmowa na działce, więc rozmawialiśmy właśnie o tym, jak można by zaprząc koncepcję myślenia produktowego do tego, czym mój ojciec się zajmuje od kilku lat, a mianowicie swoją działką, którą sobie zakupili z mamą i tą działkę rozwijają, domek tam postawili i tak dalej, i tak dalej. Więc czym jest Product Backlog również w tym kontekście? Product Backlog jest jedną listą rzeczy, pomysłów, eksperymentów, zmian, wymagań, zwał jak zwał, rzeczy, które chcielibyśmy pewnie zwalidować.

Ja chciałem powiedzieć rzeczy, które chcielibyśmy wrzucić do produktu, ale moim zdaniem to bardziej powinniśmy iść tropem empirycznym rzeczy, pomysłów, które chcielibyśmy zwalidować. Więc taka krótka odpowiedź. Możemy podrążyć. Tak, chętnie. Po prostu zawsze myślałem, że Product Backlog to jest lista rzeczy, które chcemy wykonać, ale ta narracja o tym, że chcemy je zwalidować, sprawdzić eksperymentalnie jest ciekawsza. Dobra. Czy jest obok Product Backlogu jakaś lista rzeczy, które już są zatwierdzone i wchodzą do produktu?

Okej, ale żeś z ciekawej perspektywy do tego podszedł. To ja spróbuję jeszcze raz wycofać trochę, ale to będzie związane z twoim pytaniem, bo popatrz, że takie popularne... To jest ta rozmowa, którą mieliśmy przed sekundą. Mieliśmy taką rozmowę, drodzy widzowie naszego kanału, o tym, że Scrum jest po prostu... Wylewa się takie wiadro pomyj na Scrum, że ten Scrum nie działa i to się wylewa w dużym stopniu z takiej narracji, że kurdebele miało być nowe podejście do zarządzania projektami I cholera, nie działa ten skram. I on nie działa z miliona powodów, ale jednym z powodów jest takie mentalne nastawienie, że właściwie dalej robimy to samo, co robiliśmy, tylko teraz będziemy robić to Zwinnie, iteracyjnie, cokolwiek. I popatrz, że to myślenie przekłada się też na nasze postrzeganie tego biednego Product Backlogu.

Budujemy autostradę, stawiamy dom, Nie wiem, nawet moglibyśmy zaryzkać stwierdzenie, wchodzi jakaś regulacja unijna, ona jest dokładnie opisana, 35 rzeczy, które trzeba zaadresować. Tam nie ma za wiele miejsca na empiryzm, nie? Bardzo długo odpowiedziałem na twoje, nie wiem czy nie, nawet nie wiem, czy odpowiedziałem na twoje pytanie, Rafał. Tak i nie. No ale dałeś, bo tam była zatwierdzona lista, nie? Tak, tak. Więc tutaj tak, jak najbardziej. Fajnie, że rozróżniłeś. Dwa światełka. To trochę Product Backlog i, nie wiem, Project Backlog? Nie wiem, czy jest coś takiego? Project i Project Scope, o tak byśmy powiedzieli. O tak, czyli ten zakres.

I my stawiamy znak równości często między tymi rzeczami. To są dwie fundamentalnie inne rzeczy. Dobra, czyli Product Backlog jest bardziej listą pomysłów? Tak. Do sprawdzenia? Ok. Z tego co rozumiem... I jak, tylko jeszcze dodam, jak dla kogoś, bo może tak być, cholera, to dla wszystkich jakby, dla wszystkich, nie wiem, może są ludzie, którzy są Alfami, Omegami i od razu łapią te różnice. Ja to zawsze po prostu trafiłem, pewne rzeczy potem do mnie wsiąkały, ale jak mamy problem ze zrozumieniem tych koncepcji, to niech każdy się zastanowi nad swoim życiem prywatnym, które to, nie chcę powiedzieć, że jest produktem, absolutnie nie chcę iść w tą narrację, to dziwna narracja, ale Ale tam jest backlog rzeczy do zwalidowania.

Taki efekt utopionych kosztów, tak? Że zrobiliśmy, no spróbujmy to wypchnąć, ale czasem próba wypchnięcia jest dla nas bardziej kosztowna niż po prostu porzucenie czegoś i zajęcie się czymś sensowniejszym, nie? To tu można zahaczyć o Product Ownership, w ogóle o Ownership, nie? On jest też ownerem jakby tego, on jest ownerem swojej marki, więc on też ma świadomość, że nie może wypuścić, że inaczej. To jest to, o czym też rozmawiamy na szkoleniach, że tam jakby... To jest świetne, bardzo się dziękuję za ten przykład, teraz mi się to w głowie jakby wskoczyło na tym miejscu. Na PSPO jest taki jeden moment, w którym dyskutujemy o wartości i mówimy o tym, żeby... Jest takie sformułowanie po angielsku, favor value over revenue extraction.

Super, odkryłem po prostu jakieś konfiguracje dźwięków, zestaw, melodię, która na pewno jakby jest czymś unikalnym, się wyróżnia, a reszta idzie do kosza, nie? Tak, ale nie odczułbyś jej, nie grając, tak? Tylko nagle, o! To jest dyscyplina, to jest dyscyplina, to jest dyscyplina, nie? Zgadza mi się. Odbiegliśmy a propos dyscypliny. Nie wiem ile to trwało, ale poruszyliśmy temat Backlogu produktu. Czyli co, mamy listę pomysłów, którą trzeba zwalidować, nie? Tak jest. I moim następnym pytaniem jest, czym są elementy Product Backlogu? Czym są elementy Backlogu produktu? To jest kolejne fundamentalnie istotne pytanie.

Mamy tutaj dowolność, więc nikt nie powinien nas zmuszać do tego, żeby pracując nad na przykład głęboko technicznym produktem, się wciskać w technikę definiowania pomysłów, eksperymentów jako historyjki użytkownika. Więc w backlogu produktu są product backlog itemy, elementy backlogu produktu, a technika, którą wykorzystujemy do ich Definiowania już jest bardzo kontekst dependent i zależy od nas. Faktycznie w bardzo wielu przypadkach z tytułu tego, że jest to wdzięczna technika, bo bardzo mocno to osobno odcinek User Stories triggeruje rozmowę o potrzebach użytkownika, to faktycznie User Stories, czyli historyki użytkownika są taką popularną formą. Ale w backlogu produktu będziesz miał nieskończone rzeczy z poprzednich sprintów, które Product Owner uważa za istotne.

Czyli informacja o tym, że ta ściana została nie wymurowana, tylko żeśmy ją zrobili z kartonu gipsu, desek i trzciny. I wygląda okej, bo żeśmy ją otynkowali, wygląda to jak reszta, ale jak przyjdzie mocniejsze trzęsienie ziemi albo wichura, to tak jak na tym memie, Andrzej to jebnie. Dobra, w zasadzie odpowiedziałeś mi na moje następne pytanie, czyli co może zawierać Product Backlog, czyli w zasadzie wszystko. Elegancko. A czy tematy związane z utrzymaniem? Mogą być w Backlogu produkty czy nie mogą? Jak myślisz? Utrzymanie. Produkt istnieje, coś im robisz, dłubiesz. Wyobraź sobie, że zacząłeś pracować nad produktem, tam go wiesz, odbudujemy go iteracyjnie, inkrementalnie, przyrostowo, on już jest na rynku, zaczyna działać, zaczynają wpadać tematy związane z jakimś tam utrzymaniem tego produktu.

Co kryje się w Product Backlogu Tu mam dobry przykład z naszego osobistego podwórka, czyli walka ze stroną internetową i jej przyspieszanie. Więc poprawki błędów, przyspieszanie strony, zabawy czasem z czcionkami, fontami.

Wszystko siedzi w jednym backlogu razem z pomysłami na nowe rzeczy na serwisie. Z mojej perspektywy, jak ja się bawię tutaj w Product Foundera, a ty się bawisz w dewelopera, w tej układance Scrumowej, zarówno ty chcesz mieć jasną wiedzę, co jest dalej w kolejce, co jest najistotniejsze, jak wyglądają proporcje w backlogu, A ja też chcę mieć rozeznanie, że dobra, no jakby Rafał siedzi obecnie, nie ma go, jest wyjęty, bo między innymi przyspiesza serwis, więc dlatego nie leci jakaś nowa funkcjonalność związana, nie wiem, z nowym sposobem płatności, na przykład albo ratalnej czy coś, nie? Więc... I Product Owner maksymalizuje wartość, bo Product Owner się zastanawia, dobra, co jest dla mnie ważniejsze w tej chwili? Co jest dla mnie ważniejsze w tym momencie? Czy ważniejsze jest to, żeby serwis zaczął śmigać szybciej, bo na przykład często ludzie wchodzą z mobile'a, się frustrują?

Czy ważniejsze jest to, że będą mogli płacić ludzie Stripe'em, nie? Albo PayPal'em, albo tam czymś innym? Co kryje się w Product Backlogu? I kolejny temat poruszamy również na twoich, w takim sensie, że ty też jesteś osobą zaangażowaną, siedzisz w tym produkcie, rozumiesz ten biznes, więc jesteś, totalnie też jakby takie jest oczekiwanie, żebyś też mi powiedział, człowieku, ogarnij się, nie jakby, odpuść sobie tego PayPala, w Polsce nikt z niego nie korzysta na przykład, nie? Tak, czasem nawet z racji tego, że ja widzę produkt od środka, to jestem w stanie podpowiedzieć ci, że czegoś nie możemy zrobić zanim, czegoś innego nie zrobimy, tak? Nawet nie, że nie możemy. Czasem wystarczy, że nie powinniśmy, bo coś wydłuży czas pracy.

I teraz taka trywialna dyskusja trwa właśnie wokół tego, jak priorytetyzować elementy w backlogu produktu. No i na radarze się pojawia Moscow. Moscow to jest taka technika istniejąca do priorytetyzacji elementów scope bardziej, project scope'u. Ja to znam z tego świata projektowego. Moskoł mówi o tym, że są wymagania, które są mustami, M są wymagania, które są shouldami, to jest S, couldami i wantami, czyli tak zwanymi, że ich nie zrobisz. No i narracja Scrumowa jest taka, że backlog produktu nie jest spriorytetyzowany, Czyli nie opieramy się tylko i wyłącznie w oparciu o priorytety, kolejkując ten backlog produktu, tylko że backlog produktu jest uporządkowany, czyli on jest ułożony w jakiejś kolejności realizacji tych rzeczy.

Mam wrażenie, że to jest trudniejsze ogólnie, ale z perspektywy pracy zespołu Scrumowego jest to znacznie rozsądniejsze rozwiązanie, bo kolejkowanie zmusza Product Ownera albo osobę, inaczej kogoś, na kogo Product Owner to deleguje, Do odpowiedzenia sobie na jedno fundamentalnie istotne pytanie pod tytułem, od czego zaczynamy albo co robimy następne. A priorytetyzacja niekoniecznie ci to powie, bo jak korzystasz z takich narzędzi jak Mosko albo inna matryca priorytetyzacji, to często wylądujesz w takiej sytuacji, że stwierdzisz sobie, że robię tą działkę, robię ten domek na działce i sobie myślisz, że to ogrodzenie. Musi być czy nie musi? Nie, ogrodzenie to jest maska. Musi mieć dach nawet. Co kryje się w Product Backlogu?

Nie wiem, jakaś tam ścieżka, ścieżka od bramy, to jest duża działka, od bramy do domku, żeby jak pada deszcz i tak dalej, można było suchą tą przejść, nie? To jest ważne czy nie? No to też jest must, nie? I po prostu prowadzisz tą rozmowę z tymi interesariuszami często i słyszysz kurde same musty, no, same musty. Ja nie bez powodu życiłem tym dachem, chodziło o to, że dach jest must, ale nie możemy go zrobić z pierwszego, no. No tak, tak, tak, masz rację. No więc to nas zmusza do tego, że dobra, no wzruszyła nas twoja historia, drogi product ownerze, ale musisz to ułożyć w kolejności, nie? Czyli jakby od czego zaczynamy. I to dlatego Backlog Group jest uporządkowany. Okej. I deweloperzy mają duży wpływ na tą kolejność.

Właśnie przez pryzmat tego, co powiedziałeś, dlatego wskoczyłem w ten temat, bo ty do mnie przyjdziesz i powiesz mu, nie ma sensu robić tego ogrodzenia na przykład, dopóki nie zajmiemy się wzmocnieniem rowu melioracyjnego wokół działki, bo to ogrodzenie po prostu wpadnie do tego rowu. I mimo tego, że ja uznałem, że ten ruch melioracyjny niech sobie będzie taki jaki jest i go zrzuciłem na sam dół backlogu, to ty jako osoba, która siedzi i wykonuje tą pracę, odpowiada za to how, uczulasz mnie, no nie stary, to jest jakby ważniejsze. Czyli tu pojawia się też temat takiej współpracy między Product Ownerem i resztą zespołu, tak? I znowu cudownie wskakujemy w fundamentalne różnice między podejściem produktowym i projektowym.

I ta ścieżka to już w ogóle jest niewykonalna. Trzeba się zastanowić nad jakimś drenażem. I jeżeli nie masz tego biznesu, no to gdzie jesteś? Jesteś w lesie. Będziesz musiał kombinować po prostu. Zaczniesz samemu się zastanawiać nad maksymalizacją tej wartości. Więc ten biznes jest potrzebny, żeby ci powiedział, dał ci jakiś kierunek działania. Biznes w rozumieniu Product Ownera oczywiście. Product Owner z tego co rozumiem jest takim przedstawicielem biznesu w naszym zespole. Ale z tego co rozumiem zdarza się, że Product Owner jest zewnętrzny. Zewnętrzny? Jak rozumiesz zewnętrzność Product Ownera? Że biznes, który przychodzi do Ciebie daje Ci swojego Product Ownera.

Tak, no, no, no, no, zdecydowanie, to jest bardzo pożądana sytuacja. Znaczy, bo wiesz, to jest znowu temat, który wymaga pogłębienia, bo jak ja słyszę zewnętrzny Product Owner, to mi się od razu w głowie ustawia, to jest moje uproszczenie tej sytuacji, z skanowy też moich doświadczeń, mi się ustawia relacja, dobra, czyli to pewnie jest relacja klient-dostawca i klient swojego Product Ownera wstawia dostawca, Wiesz, jakby relacja firma-firma, a często możemy wskoczyć w inne środowisko i sobie pomyśleć, uruchamiamy podejście produktowe, scrumowe w dużym korpo i też mamy wtedy ludzi z IT, którzy są, kontrybuują, tworzą te zespoły i jest ktoś z biznesu, kto przychodzi i też tam jest często, mimo tego, że to nie są dwie firmy, to też często jest taka, wiesz, taka relacja, a tam...

Skram i praca produktowa opiera się na tym, że te dwa światy się ze sobą zbliża i też jakby jasno się edukuje, to jest rola Scrum Mastera, edukuje o oba te światy, jak powinna ta relacja wyglądać. No i potem obserwujemy oczywiście, czy ona idzie w tą stronę, czy nie. Jeżeli nie, no to trzeba jakieś działania korygujące. Powiedz mi jeszcze taką rzecz, bo rozmawiamy o tym Product Backlogu. Jak w ogóle powstaje Product Backlog? Jak go stworzyć? Nie mamy nic, przychodzi biznes, mówi, że chce coś.

Niech będzie ten domek na działce. I co się dalej dzieje? Kto go tworzy? Jak go tworzy? To jest dobre pytanie, bo tutaj nasz ukochany przewodnik po Scrum jest bardzo okrojony w zawartość, czyli to jest takie ciekawe zjawisko, które też odkrywałem, że jak się zajrzy do Scrum Guide'a, to jest nagle takie podejście, że i nagle Od pewnego dnia objawiony tutaj był nam Product Owner i Backlog produktu i wszystko. Więc w praktyce bardzo ważna rzecz. Myślę, że od tego trzeba zacząć. I totalnie możemy narysować analogię do naszej pracy, współpracy.

Zacznij od tego, co masz. Masz jakieś pomysły w głowie? Zrzuć te pomysły i zacznij o tych pomysłach. To będzie zrąb jakiejś listy. Zacznij o tych pomysłach jak najszybciej rozmawiać. To będzie de facto refinement albo jakaś pielęgnacja tego. Ustalcie, które z tych pomysłów są gotowe do developmentu, do obróbki i zacznijcie nad nimi pracować. I w międzyczasie zajmijcie się identyfikacją kolejnych pomysłów. Ale ważne jest to, żeby te kolejne pomysły wynikały z tej pętli empirycznej. Czyli Chodzi mi o to, że czasami będzie tak, wiesz, jeżeli robisz piętnastą mobilną aplikację bankową, nie? To umówmy się, to jakby ty już wiesz, to już masz długą tą listę w głowie, jeżeli byłeś Product Ownerem na przykład w innych instytucjach tego typu, nie?

I tutaj będziemy mniej mówić o empiryzmie. Tutaj zahaczymy o tą predykcyjność, bo nie odkrywamy tutaj Ameryki na nowo. Cały czas oczywiście jest miejsce na walidację jak najszybszą, bo może nasz customer base jest zupełnie inny. Pomyśl sobie o tym, jak wiele lat temu mBank wchodził na rynek jako bank digitalowy bardzo mocno. Oni na maksach. Co kryje się w Product Backlogu?

Co się dzieje? Chociażby, że jak się loguje, to może się zalogować na 15 różnych sposobów. Co się dzieje po zalogowaniu? Jaki ekran widzi? I tak dalej, i tak dalej. Więc User Story Mapping to jest jedna fajna technika, Ona na pewno, to jest warsztat, kilkugodzinny warsztat, w którym powinien brać udział cały zespół, interesariusze idealnie, ktoś powinien to facylitować, to jest trudny warsztat, wiesz, to wymaga przestrzeni, online'owo możesz to robić w Muralach i innych Miro, fajnie by było spróbować się spotkać, jeżeli to jest możliwe oczywiście, w jednej lokalizacji stanąć przed tablicą. Co kryje się w Product Backlogu?

Ale pomaga też takie rozpisanie sobie, jakie są elementy tego systemu i wejście w głębiej po prostu, co te elementy powinny robić. Czyli to jest taka trochę praca, wiesz, przy tablicy. Ważne, żeby tam był cały zbiór ludzi, którzy się zastanawiają, dobra, jak zdekomponować ten duży... Musimy się wtedy z tym zespołem zastanowić, jak ten duży element systemu, w jaki sposób można by go rozłożyć na mniejsze kawałki. Tutaj to się nazywa dekompozycją. Chyba tak staram się termin z angielskiego wyciągnąć, ale jakbyście mieli coś googlować, to właśnie Product Backlog Item Decomposition. Są różne narzędzia do tego dostępne. Takie najpopularniejsze, na które pewnie traficie, to będzie model pajączka Spider Majka Kona, który jest wdzięcznym takim bazowym modelem.