00:00:02,180 --> 00:00:03,859 [Piotr Durlej]
Dzień dobry, z tej strony Piotr. 

00:00:03,859 --> 00:00:05,420 [Michal Krajewski]
A z tej strony Michał. 

00:00:05,420 --> 00:00:22,799 [Piotr Durlej]
I dzisiaj łapiemy się z wami, żeby pogadać o czymś, co potencjalnie każdego z menadżerów spotyka.
Czyli wybierz to, co jest najważniejsze w tym momencie i dowieź, dowieź to jak najszybciej, jak to
możliwe. Czyli o priorytetyzacji zadań. 

00:00:22,799 --> 00:00:51,779 [Michal Krajewski]
Tak jest. No to jest temat, który każdy-- znaczy to jest chyba jeden z niewielu tematów, który jest
zawsze potrzebny w roli PM-a. No bo wiadomo, różne są firmy, różne konteksty, różne umiejętności są
wymagane. Natomiast priorytetyzacja no się pojawia zawsze i zawsze pada pytanie właśnie jak
priorytetyzować zadania? I tutaj służymy pomocą. Więc myślę Piotr co, zaczniemy od omówienia paru
metod takich, takiego teoretycznego nazwijmy to- 

00:00:51,779 --> 00:00:51,919 [Piotr Durlej]
Tak 

00:00:51,919 --> 00:00:52,699 [Michal Krajewski]
A później trochę- 

00:00:52,699 --> 00:00:54,000 [Piotr Durlej]
Powiemy jak jest. 

00:00:54,000 --> 00:00:58,219 [Michal Krajewski]
Opowiemy, jak my ich używaliśmy bądź nie używaliśmy, tak? 

00:00:58,219 --> 00:01:01,059 [Michal Krajewski]
No na pewno pierwszą metodą, którą o 

00:01:01,059 --> 00:01:41,479 [Michal Krajewski]
której słyszeliście, to jest RICE, czyli to jest skrót od reach Impact Confidence i Effort. No i to
jest najczęściej spotykana metoda, wydaje mi się. A przynajmniej najczęściej omawiana czy spotykana
w rzeczywistości zaraz powiemy. No i polega na tym, że określasz te cztery metryki, czyli reach -
zasięg, impact - wpływ, confidence -pewność i effort - wysiłek. I na podstawie tych czterech metryk
określasz finalny score, czyli ten właśnie RICE, który używasz do priorytetyzacji. Im wyższe, im
wyższy score ma dana inicjatywa, tym ma wyższy priorytet. Tak? 

00:01:41,479 --> 00:01:52,439 [Michal Krajewski]
No i to jest całkiem ciekawe. Ciekawy sposób myślenia o wszystkich inicjatywach, ponieważ stara się
określić w miarę 

00:01:52,439 --> 00:02:16,779 [Michal Krajewski]
w taki ilościowy sposób, jaki wpływ może mieć Twoja inicjatywa na całą firmę. Do ilu osób może
dotrzeć, ale też co mi się szczególnie podoba oszacowuje to Twoją pewność co do innych wyliczeń. No
i najważniejsze albo nie wiem, czy najważniejsze, ale ważne też daje tutaj ci daje twoim inżynierom
wkład, gdzie mogą określić ten wysiłek, tak? Ile to, ile to tak naprawdę powinno zająć, nie? 

00:02:16,779 --> 00:02:18,179 [Piotr Durlej]
No tutaj 

00:02:18,179 --> 00:02:22,139 [Piotr Durlej]
RICE zostało zrobione, jeśli dobrze kojarzę przez Intercoma. 

00:02:22,139 --> 00:02:26,479 [Piotr Durlej]
Czyli to jest taki jakby ten start-up, który, 

00:02:26,479 --> 00:02:42,499 [Piotr Durlej]
który się jakby zajmował właśnie zajmuje jakimś tutaj pomocą, tworzeniem narzędzia, żeby pomagać w
zarządzaniu klientami i feedbackiem i tak dalej. No i nawet oni tam też piszą, że, że tutaj, 

00:02:42,499 --> 00:02:53,719 [Piotr Durlej]
że to jest jakby pomoc też jakby dla PM-a i nie można jakby tego traktować tak z religijną,
religijnym fokusem, bo można czymś wziąć się za coś, co 

00:02:53,719 --> 00:03:05,099 [Piotr Durlej]
będzie miało niższy ten score. No bo wszystkie te fragmenty są bardzo subiektywne i to jest chyba
problem, który jest przy priorytetyzacji, że ta priorytetyzacja jest zazwyczaj bardzo subiektywnym 

00:03:05,099 --> 00:03:16,139 [Piotr Durlej]
jakby ćwiczeniem i, ale RICE tak jest, jest fajne, żeby coś zacząć, szczególnie jakby dla, jakby dla
PM-a. Na samym początku, jak nie wiadomo od czego zacząć, to można zacząć od RICE. 

00:03:16,139 --> 00:03:58,779 [Michal Krajewski]
Tak. Znaczy myślę, ja no szczerze, ja nie wiem, czy sugerowałbym zaczynanie od RICE, no bo to jest
jednak już taki w bardziej zaawansowanym sposób, w tym sensie, że wymaga od Ciebie wielu, określenia
wielu tych metryk, więc jego wadą jest na pewno to, że trochę zajmuje czasu stworzenie tego
wszystkiego. Musisz mieć te dane, na których budujesz te metryki. No i daje takie to, to, co chyba
sugerowałeś, tak? Takie poczucie fałszywe czasem pewności co do tych wyników, że o wyliczyłem to,
więc widocznie jest to najważniejsze i warto tutaj właśnie zrobić taki sanity check, że okej, wyszło
mi to, ale czy może źle po prostu zostało policzone. 

00:03:58,779 --> 00:04:04,959 [Michal Krajewski]
Jedną z zaletą tego RICE jest na pewno to, że zachęca do współpracy między zespołami. No bo musisz
tu- 

00:04:04,959 --> 00:04:05,479 [Piotr Durlej]
No właśnie, tak 

00:04:05,479 --> 00:04:25,919 [Michal Krajewski]
Mieć skład inżynierów, żeby powiedzieli ci ten effort, ale także te wszystkie metryki, na przykład
zasięg. Czasem nie jesteś w stanie sam policzyć albo impact i musisz się odezwać do innych zespołów,
żeby ci z tym pomogli. Więc wydaje mi się, że to jest taka fajna cecha RICE, że wymaga trochę od
Ciebie 

00:04:25,919 --> 00:04:28,059 [Michal Krajewski]
pójścia do innych zespołów, nie? 

00:04:28,059 --> 00:04:49,259 [Piotr Durlej]
Dla mnie najważniejszą rzeczą przy priorytetyzowaniu jest to, że właśnie, że musisz zadać pytania. I
RICE jest o tyle dla mnie jest super, dlatego, że musisz się zastanowić nad biznesowym impaktem
tego, co robisz, a nie tylko nad jakby effortem i tego, czy coś wydaje Ci się jakby i Twojemu
zespołowi, że jest sexy, czy jest ciekawe, czy atrakcyjne- 

00:04:49,259 --> 00:04:49,779 [Michal Krajewski]
Wartościowe 

00:04:49,779 --> 00:05:15,699 [Piotr Durlej]
Tak, dokładnie. Więc dlatego, dlatego jakby w mojej głowie RICE jest fajny. Nie z powodu tego, że
tutaj z powodu właśnie dokładnie tego, że musisz zadać właśnie pytania, pytania dalej. No ale inne
są jeszcze, też są inne te metody, metody i chyba tutaj value versus effort możesz zrobić tutaj deep
dive, jak miałeś z nim, z nimi jakby do czynienia Michał. 

00:05:15,699 --> 00:05:19,079 [Michal Krajewski]
No tak, to na takim poziomie teoretycznym 

00:05:19,079 --> 00:05:26,959 [Michal Krajewski]
to jest taki trochę uproszczony RICE właściwie. No bo masz value, czyli tutaj w value wpychasz
wszystko, co w RICE rozbijasz na te- 

00:05:26,959 --> 00:05:30,199 [Piotr Durlej]
A to nie macierz Eisenhowera taka bardziej? 

00:05:30,199 --> 00:05:40,939 [Michal Krajewski]
Tak, to jest taka macierz, tylko że, że masz uproszczone to w tym sensie. No bo RICE też jesteś w
stanie wrzucić sobie na taką macierz, prawda? Jeśli chcesz. Natomiast tutaj po prostu- 

00:05:40,939 --> 00:05:42,539 [Piotr Durlej]
Jakie możesz wrzucić? 

00:05:42,539 --> 00:06:21,829 [Michal Krajewski]
Tak. No tutaj, tutaj jest to by design. No i masz właśnie te value określone. Tutaj masz
skondensowaną tą wartość, którą w RICE wyliczasz. No i effort, czyli tutaj właśnie wysiłek. No i
wkładasz sobie te inicjatywy na taką macierz i możesz łatwo określić, czy coś ma wysoką wartość i
niski wysiłek.Czyli najwyższy priorytet, wysoka wartość, wysoki wysiłek. Czyli to już takie duże
projekty. Niska wartość, niski wysiłek. Czyli to mogą być te quick winy. No i tutaj niska wartość i
wysoki wysiłek, czyli tutaj coś, co jest nieefektywne i nie warto tego robić. No i to jest fajne pod
kątem wizualizacji na pewno. 

00:06:21,829 --> 00:06:36,109 [Michal Krajewski]
Jest proste w użyciu, prostsze niż RICE, no i jest prostsze dla interesariuszy do zrozumienia, de
facto. Natomiast pewnie jest za łatwa dla złożonych projektów. Za łatwa, za jakby uproszczona. 

00:06:36,109 --> 00:06:48,969 [Piotr Durlej]
Wszystko wpada do- wszystko wpada do jednego worka, że jest super ważne i super pilne i tak dalej. A
nic, nic z itemów Twoich jakby nie będzie nieważne i niepilne, najprawdopodobniej nie? 

00:06:48,969 --> 00:06:54,149 [Michal Krajewski]
No więc warto. Jest mocno subiektywna i wydaje mi się, że 

00:06:54,149 --> 00:07:28,269 [Michal Krajewski]
ja szczerze tego najmniej stosowałem. Może zaraz rozwiniemy, jak to u nas się rozkładało, tak? Ale
to jest takie, no po prostu te value jest problemem, bo później ktoś cię spyta, dlaczego według
ciebie ten value takie wysokie? No i wtedy zaczynasz-- musisz się tłumaczyć, gdzie w RICE jednak już
powinieneś ten proces myślowy przejść wcześniej i łatwiej Ci jest określić, dlaczego coś jest
wartościowe. No tutaj jest to trochę takie, no wydaje mi się, że to jest valuable, tak? Więc myślę,
że tutaj, no niekoniecznie. 

00:07:28,269 --> 00:07:43,549 [Piotr Durlej]
Niekoniecznie. No z mojej perspektywy bardzo często priorytetyzacja wypadała z roadmapy jakby
strategicznych, strategicznych działań, które trzeba było wziąć, które były, które były konieczne,
żeby osiągnąć ten impact, który 

00:07:43,549 --> 00:08:04,869 [Piotr Durlej]
razem właśnie z innymi interesariuszami czy jakby w organizacji dalej był, dalej był potrzebny. No i
tutaj, w momencie, kiedy, kiedy jest, kiedy są jego priorytety na poziomie, na poziomie jakiejś, nie
wiem, czy to nazwać ekipu-- epików, czy inicjatyw są ustalone, no to bardzo często, bardzo często
trzeba. 

00:08:04,869 --> 00:08:11,509 [Piotr Durlej]
No już ta kolejność zadań jest, jest rozłożona. No i tutaj mamy takie zabawy do tego, że jak 

00:08:11,509 --> 00:08:24,829 [Piotr Durlej]
PM ma priorytetyzować w momencie, kiedy w Scrumie tak naprawdę-- w Scrumie zgodnie z tym, co buy the
book, to powinny być kolejność, kolejność zadań robiona powinna być przez 

00:08:24,829 --> 00:08:55,389 [Piotr Durlej]
w danym sprincie właśnie przez zespół i product managerowi tutaj pełniącego rolę product ownera nic
do tego być nie powinno. Więc tutaj jakby jest ta priorytetyzacja na poziomie sprintów, nie? W
Kanbanie znowu ma się klasy usług, czyli w zależności od tego, skąd spływa dana usługa i jakie ma
warunki, no to inaczej jest traktowana i innym ma priorytet. Na przykład, jeśli jest request od
prezesa, to wiadomo, że wleci szybciej niż request od PM'a i- 

00:08:55,389 --> 00:08:58,089 [Michal Krajewski]
W kanbanie jest zawarte to rozumiem? No to- 

00:08:58,089 --> 00:09:27,849 [Piotr Durlej]
Oczywiście, że tak. Dlatego najlepszy, najlepszy system. No a w startupach za badaniem Pragmatyk
Inżyniera, takiego bloga bardzo fajnego, większość start-upów przyznaje się, że działa zgodnie z
podejściem planujemy, budujemy i dostarczamy, czyli też jest jakby jakieś tam planowanie fragmentów,
fragmentów pracy. Więc tutaj ta priorytetyzacja jest jakimś pomocnym narzędziem, ale 

00:09:27,849 --> 00:09:56,089 [Piotr Durlej]
jakby bardzo ciężko, w sensie bardzo ciężko będzie z sytuacją, że ma się dwie funkcjonalności, które
kurczę, no są jakby dość podobne i trzeba będzie się zastanowić nad które z nich, jakby które z nich
jakby jest-- szybciej trzeba się zdecydować. Najprawdopodobniej będzie rozmowa o priorytetyzacji z
poziomu PM'a powinna się odbywać na poziomie właśnie funkcjonalności, na poziomie epiców. Eee no. 

00:09:56,089 --> 00:10:01,869 [Michal Krajewski]
No tak, myślę, że te rzeczy, o których wspomniałeś właśnie. 

00:10:01,869 --> 00:10:15,349 [Michal Krajewski]
Jakieś takie requesty czy rzeczy, które, które de facto są jakimiś must have'ami, tak? No, tutaj
pewnie fajnie jest, zanim na przykład zaczniemy. I tak ja to stosowałem, zanim zaczniemy jakieś
wyliczenia RICE'owe, 

00:10:15,349 --> 00:10:28,169 [Michal Krajewski]
rzeczywiście zrobić taki wywiad, co jest takimi must have'ami? I dopiero-- I tutaj pomaga kolejny
framework, czyli MoSCoW. On jest też super subiektywny, natomiast on pomaga 

00:10:28,169 --> 00:11:25,869 [Michal Krajewski]
być na tej samej stronie, on the same page z stakeholderami. Przynajmniej w mojej głowie tak?
Ponieważ może daje Wam jakiś tam prosty framework do rozmawiania o tym, kto, co powinno być must
have'm, co powinno być should have'm, could have'm, a co nie będziemy robili, czyli ten won't have,
tak? Bardzo subiektywne oczywiście, ale proste w zrozumieniu, więc możliwe, że to jest jako pierwszy
krok. I tak jak mówię, ja to tak stosowałem, jako pierwszy krok dla rozmowy, że okej, określmy sobie
te nasze must have'y, określmy rzeczy, których nie chcemy robić. To też jest fajne, bo okej, to
wtedy usłyszysz od razu, okej, tego nie chcemy robić, gdzie w RICE jeśli wyjdzie Ci to jako
wartościowe, no to jest trudniej, tak? A tutaj od razu możecie sobie odrzucić część rzeczy, których
nie robicie i dopiero później zaczynacie, że tak powiem, taką bardziej ilościową estymację z tych
must have'ów, co jest najbardziej wartościowe? Co może powinniście zrobić na początku? 

00:11:25,869 --> 00:11:31,389 [Piotr Durlej]
MoSCoW? MoSCoW jest super pod tym względem właśnie, że do 

00:11:31,389 --> 00:12:06,249 [Piotr Durlej]
współpracy z interesariuszami. Bo jeśli założysz-- ja, co ja zrobiłem, raz mi się zdarzyło. Mi to
bardzo pomogło. Interesariusze nie byli zbyt zadowoleni. To było, że powiedziałem okej, w MoSCoW są
cztery kategorie. No to posegregujmy, które z kategorii są must. Dwadzieścia pięć procent ma być
must, dwadzieścia pięć procent ma być should, dwadzieścia pięć procent ma być could a dwadzieścia
pięć procent ma być want. I okazało się, że interesariusze włożyli osiemdziesiąt procent rzeczy do
must, a potem było pytanie okej, czy to jest aby na pewno must? Czy to jest aby na pewno past? No i
to- 

00:12:06,249 --> 00:12:06,909 [Michal Krajewski]
No, no, no, no.

00:12:07,479 --> 00:12:31,279 [Piotr Durlej]
I to bym powiedział, zmusiło, zmusiło do bolesnych jakby w-bolesnego wyboru, a mi ułatwiło, ułatwiło
bardzo pracę. No i potem właśnie z takich rzeczy buduje się, buduje się właśnie jakby roadmapy i w
momencie, kiedy masz już jakieś, jakąś właśnie taką strategię, wizję, nie wiem, większy jakby plan,
big picture, no to, no to wtedy też te priorytety też inaczej wypadają, nie? Bo wiadomo co, dlaczego
no 

00:12:31,279 --> 00:12:36,559 [Michal Krajewski]
Tak jest. No to ostatni, jaki chcieliśmy omówić tutaj jest twój, twój konik jakiś. 

00:12:36,559 --> 00:12:43,220 [Piotr Durlej]
Mój konik, go ahead. Mój konik, tak? Czyli weighted shorted job first. 

00:12:43,220 --> 00:12:51,519 [Piotr Durlej]
Generalnie śmiałem się z SAFE, czyli Scaled Agile Framework, ale to akurat jedna rzecz, trzeba
powiedzieć, że jedna rzecz tutaj 

00:12:51,519 --> 00:12:54,519 [Michal Krajewski]
Zaczyna się od jednej rzeczy, a później w sumie to takie... 

00:12:54,519 --> 00:13:04,220 [Piotr Durlej]
A w sumie tak. To, to jakby zróbmy sobie, zróbmy sobie w ogóle tam jakieś. Ja nawet nie wiem, co
tam, co tam trzeba robić jakby w SAFE tylko słyszałem, 

00:13:04,220 --> 00:13:07,659 [Piotr Durlej]
słyszałem płacz, płacz jakby ludzi, 

00:13:07,659 --> 00:13:25,819 [Piotr Durlej]
którzy próbowali jakby to stosować. Chodzi o to, że w wypadku WS-JF jest bardzo fajnie, bo odwrotnie
się kota ogonem, czyli na zasadzie zamiast wybierzmy, co jest jakby najważniejsze, jakby co, na tym
trzeba się priorytetyzować, to wybieramy, co 

00:13:25,819 --> 00:13:41,059 [Piotr Durlej]
robimy. Tworzymy kolejność od tego, co nas najbardziej boli, jeśli tego nie zrobimy do tego, co nas
najmniej boli, jeśli to zrobimy. Czyli trochę tutaj idziemy zgodnie z tym duchem, tego, że biznes ma
zawsze nieoczekiwane, 

00:13:41,059 --> 00:14:27,619 [Piotr Durlej]
Boże nieoczekiwane? Nieograniczone potrzeby, a my zawsze mamy ograniczone zasoby. No to, więc
zgodnie z taką myślą zastanówmy się, co jest największym, jakie zadanie ma największy koszt
opóźnienia, czyli jak najbardziej, jeśli tego nie zrobimy w tym momencie, no to najbardziej zaboli
biznes i podzielmy to przez, przez jakby czas pracy, ilość pracy, którą trzeba włożyć, nie? Więc
koszt zwłoki wylicza się, jest to mieszanka wartości biznesowej, presji czasu, czyli ma się ten
timing. To jest bardzo często krytyczne. No i właśnie i ta trzeci, trzeci czynnik redukcja ryzyka
bądź jakby otworzenie, wyzwolenie nowych szans. A więc o tyle to jest fajne, że bardzo, 

00:14:27,619 --> 00:16:06,039 [Piotr Durlej]
bardzo jest optymalnie, jeśli jest zastosowane, zastosowana ta, ta strategia może ułożyć Ci czym
masz się zająć, czym musisz się zająć, bo, bo inaczej nie weźmiesz, nie będziesz w stanie
maksymalnie dowieść wartości w danym czasie. Więc przynajmniej w teorii to jest jakby ułożone
zgodnie z tym, co powinno być najlepsze dla twojego biznesu. Kolejna rzecz wymusza te strategiczne
rozmowy, okej, co dają tą wartość? Więc jakby dla mnie ta, te ćwiczenie priorytetyzacyjne jest tutaj
zachowane, bo trzeba o tym rozmawiać. No i też wbrew pozorom nie jest aż takie skomplikowane, bo
potrzeba trzech wskaźników, u których można sobie dać jakiekolwiek, jakiekolwiek wartości czy ciąg
Fibonacciego, czy po prostu od jeden do dziesięć, czy cokolwiek. A no i tak samo jakby tutaj effort
to też wiadomo jak się, jak się tutaj estymuje. No ale problemy, problemy z tym no to niestety jak
wszystko przy priorytetyzacji jest dość subiektywne, bo tą wartość czy timing można, można jakby
różnie, różnie jakby robić. Też z racji, że skupia się na tych by proxy, skupia się na tych
rzeczach, które są małe, a dostarczają dużo, dużo wartości. No to też nie dasz-- jest bardzo duża
szansa na niedoszacowanie większych tematów, które dostarczają dużo wartości, na przykład
odblokowują wiele, wiele tematów. No i bardzo duży jest wpływ estymowania czasowego tak, że tutaj
wszystko dzielimy, więc jeśli zespół źle estymuje bardzo, no to tutaj można, można tutaj wyjść z
tego, wyjść z tego źle. No ja bardzo polecam 

00:16:06,039 --> 00:16:32,679 [Piotr Durlej]
to wychodząc z sytuacji długu technologicznego albo wychodząc z sytuacji takiej kryzysowej, jak
przychodzi się do organizacji i nie wiesz, nie wiesz, od czego się zająć, to mówisz okej, to my
teraz skupimy się na tym, co nam najszybciej dostarczy jak najwięcej wartości. I to jest coś, co
wszyscy interesariusze, jak i wszyscy jakby deweloperzy, cały zespół mówi okej, brzmi fajnie. Więc
to jest taki bardzo fajny, bardzo fajny framework, który mnie uratował 

00:16:32,679 --> 00:16:35,519 [Piotr Durlej]
raz czy dwa, jak musiałem wchodzić do organizacji. 

00:16:35,519 --> 00:16:39,219 [Michal Krajewski]
No wydaje mi się, że to-- tak, z tego, co opowiadasz, 

00:16:39,219 --> 00:16:49,599 [Michal Krajewski]
to trochę priorytety-- znaczy, pomaga ci doważyć, że tak powiem, te rzeczy związane z długiem
technologicznym. Więc to fajnie, bo w innych tych, 

00:16:49,599 --> 00:16:55,659 [Michal Krajewski]
tych frameworkach no to w RICE tak, możesz zawsze powiedzieć, że no jak się coś 

00:16:55,659 --> 00:17:06,179 [Michal Krajewski]
wydarzy, no to wtedy dług technologiczny ma bardzo wysoki score, no bo zasięg ich wpływ jest
ogromny, natomiast w praktyce pewnie nie jest to, nie jest to 

00:17:06,179 --> 00:17:12,259 [Michal Krajewski]
tak robione, a tutaj widzę, że rzeczywiście jest taki akcent na to, że okej, jeśli coś będziemy
zaniedbywać- 

00:17:12,259 --> 00:17:12,739 [Piotr Durlej]
Dokładnie. 

00:17:12,739 --> 00:17:23,579 [Michal Krajewski]
Przez jakiś czas, przez za długi czas, to, to nas to, to ugryzie. Więc tutaj okej, zróbmy to, jeśli
chodzi o dług technologiczny, wreszcie. Więc, brzmi spoko. 

00:17:23,579 --> 00:18:24,361 [Piotr Durlej]
Tak. No ale też tutaj też to, co trochę powiedziałem o tym, o tym sytuacji organizacji. Wydaje mi
się, że priorytetyzacja jest wypadkową, podobnie jak i frameworki jak, jak używasz zarządzania
zadaniami, zarządzania workflow, to wszystko jest wypadkowa tym, gdzie jest organizacja w tym
momencie, nie? Bo jeśli masz duży dług technologiczny, jeśli masz dużo zadań z kategorii keep the
lights on, czyli że po prostu jeśli tego nie zrobisz, to ci wybuchnie, to fajnie, że sobie
priorytetyzujesz na RICE zadania. Jak i tak one będą, nie będą top priorytetami, bo nagle się
okazuje, że klienci nie mogą używać Twojej aplikacji, nie? Więc, więc jakby tutaj trzeba wybierać
odpowiednie narzędzie do tego.Do tego environmentu, do tego środowiska, w tym, w tym jesteś. No i
wydaje mi się, że jeśli masz fajną, ustrukturyzowaną firmę i jakby tutaj spokojnie sobie możesz
działać nad nowymi ficzerkami, to wydaje mi się, że jakby RICE jest, jest spoko. 

00:18:24,361 --> 00:18:32,581 [Michal Krajewski]
Tak, jaka firma jest taka. Ja, mnie się wydaje tak, ogólnie to, co mówisz, tak? Ważne jest pierwszy
krok, to znać te metody i-i rozumieć, po co one są- 

00:18:32,581 --> 00:18:32,802 [Piotr Durlej]
Tak. 

00:18:32,802 --> 00:19:07,301 [Michal Krajewski]
Jak je, jak je stosować, a drugi to dostosować je właśnie do, do tej organizacji. No i nie stosować
religijnie ich, bo to jest najle-najlepsza albo, albo ta jest gorsza i tak dalej, tylko właśnie
stosować, próbować różnych podejść. I to chyba w każdej organizacji, w której ja byłem i Ty pewnie
też, tak? W każdej trzeba było dostosowywać te metody do organizacji, a nie na odwrót. Trochę jak ze
Scrumem powinno się robić tak? Co działa, powinno być stosowane, a nie zmuszamy ludzi do jakichś
nierealistycznych ram. No i tutaj właśnie próbujemy pewnych 

00:19:07,301 --> 00:19:42,441 [Michal Krajewski]
frameworków i sprawdzamy, które działają dobrze, które pozwalają nam szybciej działać, podejmować
lepsze decyzje. No to jest jakiś tam proces, więc to tu trzeba mieć jakiś buy-in od stakeholderów.
Ale no, pierwszy krok to po prostu znasz te metody i-i jesteś, jesteś w stanie wytłumaczyć się,
dlaczego stosujesz tą. Ja najwięcej stosowałem pewnie, pewnie Rice'a, ale tak jak wspominałem, tak
MoSCoW jako sposób na szybką taką ocenę ze stakeholderami, określenie, określenie, co według nich
jest must have'm, a dopiero później przejście do Rice'a, by móc sobie to poukładać, co powinniśmy
budować po kolei. 

00:19:42,441 --> 00:19:58,581 [Piotr Durlej]
Ja też bym powiedział, że w praktyce, w moim wypadku, najczęściej używałem MoSCoW, tylko że nie
nazywałem tego MoSCoW, tylko właśnie było określane, co jest, co jest jakby top priorytetem na dany
jakby, jakby na dany okres. A 

00:19:58,581 --> 00:20:13,261 [Piotr Durlej]
Tak dokładnie. I potem, w zależności od tego, jak dużo razem z zespołem mieliśmy przestrzeni, to
byliśmy w stanie sobie jakby określić resztę, resztę jego priorytetów, resztę priorytetów. 

00:20:13,261 --> 00:20:28,101 [Piotr Durlej]
No bo bardzo często właśnie w organizacjach są ulubione funkcjonalności czy jakieś kluczowe
inicjatywy, które muszą się, muszą się wydarzyć czy za których jest się rozliczanym. I potem jakby
dopiero zostaje ewentualna przestrzeń na 

00:20:28,101 --> 00:20:46,161 [Piotr Durlej]
jakieś bardziej, jakby autonomię od zespołu. No ale oczywiście, oczywiście jakby jest, jest z tym,
jest z tym różnie, bo też miałem. Też miałem sytuacje, w której dosłownie miałem totalnie wolną
rękę, jeśli chodzi o priorytety, no i wtedy, 

00:20:46,161 --> 00:20:56,081 [Piotr Durlej]
wtedy głównie skupiałem się na tym, co najczęściej było feedbackowane od klientów. Ale to było dawno
nieprawda. 

00:20:56,081 --> 00:21:06,101 [Michal Krajewski]
No tak, wydaje mi się, że to, co mówisz-- bo są dwie sprawy. Jedna to jest właśnie ta wolność, czyli
ten empowerment, który product manager 

00:21:06,101 --> 00:21:47,281 [Michal Krajewski]
ma czy powinien mieć. Natomiast to jest, to jest też duża odpowiedzialność, tak? Więc, więc musisz w
jakiś sposób uargumentować, dlaczego jakieś rzeczy robisz, tak? Na początku firmy nie będziesz tego
do końca wiedział. Dopiero z czasem, jak obrośniesz trochę futerko, to zaczniesz lepiej te decyzje
podejmować. I tutaj będziesz właśnie musiał zdobyć te zaufanie od organizacji, tak? Więc te metody
powinny ci pomóc. Ale oczywiście no to nie jest, to nie jest rozwiązanie wszystkich problemów. No i
jest też, też ten ostatni framework, z którego się często śmiejemy, czyli HIPO, czyli Highest Person
Opinion First Czy jakoś tak. 

00:21:47,281 --> 00:21:51,621 [Piotr Durlej]
Income chyba to było Income Person Opinion. Coś w tym stylu 

00:21:51,621 --> 00:22:26,401 [Michal Krajewski]
Coś tak w każdym razie. Właśnie, jeśli przyjdzie prezes i powie, że coś robimy, no to to robimy. No
i tutaj te frameworki wtedy są, no tylko takim zadaniem czysto teoretycznym. No bo niestety w takich
organizacjach po prostu wodzowskich, bym to tak nazwał, no robi się to, co się-- to, co leadership
zadecydował, że się robi. I jeśli leadership zadecyduje dobrze, no to jest super, a jeśli zadecyduje
źle, no to ma się ogromne, ogromne straty, tak? Ale też nie wiem, wydaje mi się, że w takiej
organizacji 

00:22:26,401 --> 00:22:37,801 [Michal Krajewski]
prawdopodobnie nie ma, jakby, nie ma co z tym walczyć, tak? Po prostu, możesz próbować robić te
frameworki i ewangelizować ludzi. Zawsze polecamy to. Natomiast będąc realistycznym- 

00:22:37,801 --> 00:22:48,281 [Piotr Durlej]
Nie no, to trzeba, trzeba realistycznie wiedzieć, wiedzieć, bym powiedział, jakie są jego
możliwości, co daje, co daje dana organizacja, co nie daje. Więc w momencie, kiedy 

00:22:48,281 --> 00:22:54,681 [Piotr Durlej]
ma się, bym powiedział takie odgórne, odgórne nakazy, no to bardzo fajnie. 

00:22:54,681 --> 00:22:56,881 [Piotr Durlej]
Tutaj, 

00:22:56,881 --> 00:23:10,781 [Piotr Durlej]
bardzo fajnie jest to jakaś inna jego specyfika. No i tak jak Michał mówi, no to właśnie budowanie,
budowanie zaufania, a-- i pokazanie, że można wykorzystać tą autonomię dobrze i sprawnie. 

00:23:10,781 --> 00:23:34,441 [Piotr Durlej]
No i w momencie, kiedy to wychodzi, to ta-- coraz więcej tej autonomii, coraz więcej tej wolności
swobodzie w priorytetyzacji też powinno być. No do tego, do tego fajnie mieć dane. Do tego właśnie
fajnie mieć założenia, do tego fajnie móc już wyliczyć, wyliczyć też ROI z tych, z tych jakby
priorytetów. A jeśli to się udało, no to wydaje mi się, że jako PM jest się w dobrym, bardzo dobrym
miejscu. 

00:23:34,441 --> 00:23:36,041 [Michal Krajewski]
Tak jest i kończąc- 

00:23:36,041 --> 00:23:38,521 [Piotr Durlej]
Bardzo dobrego miejsca Wam życzymy. 

00:23:38,521 --> 00:23:46,461 [Michal Krajewski]
Życzymy Wam tego dobrego miejsca. Kończąc temat, wydaje mi się, że jest troszkę lepiej w polskich
organizacjach niż było, więc poznajcie. 

00:23:46,461 --> 00:23:51,461 [Piotr Durlej]
Tak, wydaje mi się, że z każdym pięciolatką jak sobie porównuję 

00:23:51,461 --> 00:23:52,181 [Michal Krajewski]
Pięciolatką [śmiech] 

00:23:52,181 --> 00:24:06,261 [Piotr Durlej]
Pięciolatką, no to, no to jest, jest lepiej. Jeszcze, jeszcze pięć lat temu nadal bym powiedział
Scrum był defaultowy, nie? Teraz już to się trochę myśli, myśli się, patrzy się na różne jakby
opcje, to, co jest już super. 

00:24:06,261 --> 00:24:09,141 [Michal Krajewski]
No tak. No i sam product management jest na pewno dużo bardziej- 

00:24:09,141 --> 00:24:09,921 [Piotr Durlej]
Oj tak 

00:24:09,921 --> 00:24:14,721 [Michal Krajewski]
Zaaawansowany, więc znajdźcie te metody, stosujcie tam, gdzie 

00:24:14,721 --> 00:24:19,101 [Michal Krajewski]
to dla Was będzie działać skutecznie i-i powodzenia. 

00:24:19,101 --> 00:24:20,221 [Piotr Durlej]
Powodzonka!