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

00:00:03,740 --> 00:00:05,299 [Michał Krajewski]
A z tej strony Michał. 

00:00:05,299 --> 00:00:33,239 [Piotr Durlej]
I dzisiaj chcielibyśmy przybliżyć taki koncept, który ostatnio przeczytaliśmy na podcaście,
podcaście e-e-e newsletterze lennego. Core 4, czyli o czterech najważniejszych me-metrykach z
perspektywy product managera, na które ten produkt że menadżer powinien patrzeć, powinien śledzić,
żeby określić, czy jego zespół inżynierów czy zespół inżynierów, z którym pracuje, ma-- działa na
odpowiednim, najwyższym możliwym zdrowym tempie. 

00:00:33,239 --> 00:00:46,759 [Michał Krajewski]
Tak, wydaje mi się, że to, te jest ciekawe, ponieważ Lenny i ogólnie polecamy. Jeśli ktoś ma na
cokolwiek produktowego wydawać pieniądze, no to chyba jego, jego podcast i jego substack to jest
miejsce, gdzie warto, warto zapłacić. 

00:00:46,759 --> 00:00:49,180 [Piotr Durlej]
Jego bot, Lenny Bot też jest bardzo fajny. 

00:00:49,180 --> 00:01:38,119 [Michał Krajewski]
Jest bot jego, więc ogólnie dużo ciekawych produktowych tematów. Ten temat jest produktowy, ale
bardziej na ty-- jest po tej stronie delivery i po tej stronie technicznej. Co z tego, co kojarzę,
jego, jego wpisy raczej się skupią bardziej na takim produkcie, produkcie, czyli właśnie co budować,
a mniej jak. I to jest ciekawe, bo tak naprawdę jest troszeczkę od-odbiciem od tego, co na co dzień
pisze. No i tutaj gościnnie właśnie pani Laura Taccio opisuje ten framework, który, który pozwala
product managerom, ale prawdopodobnie każdemu, kto zajmuje się delivery software'u, tech leadom,
team managerom, sprawdzić, jak zespół produktowy, jak szybko się i z jaką jakością porusza się do
przodu, nie? 

00:01:38,119 --> 00:01:45,019 [Piotr Durlej]
Tak, no bo chyba wszyscy się zgodzimy. To też duch Martego Kagana jest z nami i mówi, że 

00:01:45,019 --> 00:02:25,899 [Piotr Durlej]
kluczowe jest szybkość. Szybkość eksperymentowania, szybkość tworzenia nowych i walidowania nowych
betów. A do tego potrzeba sprawnego zespołu inżynierów. I bardzo często jest takie poczucie wśród
szczególnie osób, które są poza, poza jakby procesem tworzenia software'u, że kurczę, to zajmuje tam
dużo czasu, to jest drogie, to jest wolne. Rzadko kiedy można się spotkać z biznesowymi
właścicielami czy interesariuszami, którzy mówią kurczę, mój zespół inżynierów i produktowy działa
bardzo sprawnie, ale szybko. Ale co, co jakby można by powiedzieć to jakby chyba ogólnie jest
poczucie, że to są jakby bardzo nieefektywne zespoły, 

00:02:25,899 --> 00:02:53,939 [Piotr Durlej]
a te nieefektywność jest bardzo często percepcją, ponieważ nie ma dobrych metryk. No, ja tam w
przeszłości próbowałem z różnymi rzeczami, jakby eksperymentowałem w różny sposób. Próbowałem jakby
pokazać i pokazywałem, że kurczę, ten zespół zobaczcie, jaki fajny progres robi, jak fajnie jest
lepiej, ale trudno mi było znaleźć jeden taki standard, który byłby bardzo prosty do-do przekazania,
bardzo prosty do 

00:02:53,939 --> 00:03:05,959 [Piotr Durlej]
pokazania właśnie tym osobom nietechnicznym, osobom z marketingu, ze sprzedaży. Hej, zobaczcie, o
ile jest lepiej. No i właśnie ten Core 4 fajnie ugryzie ten ten problem. 

00:03:05,959 --> 00:03:30,539 [Michał Krajewski]
Tak, oni tutaj wspominają o czterech metrykach, które trzeba stosować łącznie. Tak? No nie powinno
się ich oddzielnie, oddzielnie patrzeć, tylko patrzeć łącznie. Jak my na przykład kwartał do
kwartału poruszamy się, jeśli chodzi o speed. Czyli oni tutaj proponują development velocity,
używając pull i merge requestów. Ile, ile tych pól, ile tych- 

00:03:30,539 --> 00:03:31,359 [Piotr Durlej]
Per inżynier 

00:03:31,359 --> 00:03:36,999 [Michał Krajewski]
Per inżynier per tydzień na przykład. Czyli tutaj pokazuje, jak często inżynier 

00:03:36,999 --> 00:03:38,859 [Michał Krajewski]
to robi. No-- 

00:03:38,859 --> 00:03:49,479 [Piotr Durlej]
Czyli dodaje jakąś część kodu to, która ma w teorii działać. Oczywiście wiadomo, że może być różnie
z tym, ale przynajmniej tempo zmian jest dość duże. 

00:03:49,479 --> 00:04:09,799 [Michał Krajewski]
Tak, tak jak mówię, nie można na to patrzeć tylko na to, tylko oczywiście cztery trzeba stosować
naraz. Wiadomo, jest to jakaś miara, tego też podejrzewam. Jak, na jak, jak bardzo dzielicie te
swoje feature nowe? Czy okazuje się, że inżynier jeden siedzi na przykład cały tydzień nad jednym
featureem, co pewnie jest suboptymalne, tak? Bo inszyk... 

00:04:09,799 --> 00:04:14,859 [Piotr Durlej]
I robi jednego ogromnego PR-a, którego nikt nie jest w stanie zrobić review- 

00:04:14,859 --> 00:04:17,779 [Michał Krajewski]
Review zrobić i nie jest w stanie 

00:04:17,779 --> 00:04:31,599 [Michał Krajewski]
tak naprawdę sprawdzić błędów wcześniej, zanim zrobisz, zanim zrobisz ten PR1, może warto zrobić 4 w
ciągu tygodnia, oczywiście. Druga metryka to jest quality. No i tutaj oni prezentują. 

00:04:31,599 --> 00:04:35,359 [Michał Krajewski]
No i tutaj tak po prostu jakość tego- 

00:04:35,359 --> 00:04:43,239 [Piotr Durlej]
Vibe check, nazwijmy to po prostu, nazwijmy to-- jakby to jest według mnie najsłabszy element, ale 

00:04:43,239 --> 00:04:46,919 [Piotr Durlej]
jakby tego, tego systemu, bo 

00:04:46,919 --> 00:05:00,859 [Piotr Durlej]
nie ma jasnego sposobu, żeby określić bardzo wyraźnego sposobu, żeby określić, okej, jak się
jakościowo, jak się pracuje, tak? Są różne jakby pytania, są różne testy, są różne kwestionariusze. 

00:05:00,859 --> 00:05:31,779 [Piotr Durlej]
No i bym powiedział, ale chodzi o to, jakby tą jakość w tworzeniu kodu bardzo trudno, trudno jakby
uchwycić. No i tutaj też mnie osobiście bardzo cieszy, dlatego że ja też próbowałem rozwiązać ten
problem w przeszłości i skończyło się też jakąś ankietą. Nie taką dokładną tutaj, jak proponuje
Laura, ale o chodzi o takie poczucie generalne, generalne poczucie, że deweloperzy czują, okay,
jakby to, co tworzymy jest jakościowe czy wystarczająco jakościowe, nie? 

00:05:31,779 --> 00:05:35,859 [Michał Krajewski]
Tak. No, oni tu prezentują to w formie takiej ankiety. Wydaje mi się, że 

00:05:35,859 --> 00:05:37,999 [Michał Krajewski]
jesteś w stanie 

00:05:37,999 --> 00:05:56,439 [Michał Krajewski]
na podstawie ankiety, jeśli osoby zaangażowane w ten projekt są w stanie określić, że no, w zeszłym
kwartale non stop walczyliśmy z problemami technicznymi, rzeczy, które tworzyliśmy, musieliśmy do
nich wracać. Każdy może mieć w głowie- 

00:05:56,439 --> 00:05:58,379 [Piotr Durlej]
Swoje flashbacki i swój Wietnam, no. 

00:05:58,379 --> 00:06:08,379 [Michał Krajewski]
Tak, swoją sytuację jak ta. No to wiadomo, że wtedy quality jest niższe. Natomiast jeśli czego nie
ma, feature działają, nie ma problemu. No to można to w jakiś sposób zmierzyć, nie? Oczywiście- 

00:06:08,379 --> 00:06:18,039 [Piotr Durlej]
To wydaje mi się, że, że trochę, trochę właśnie to wchodzi, wiesz, ten punkt, te dwa kolejne punkty,
czyli właśnie efektywność i impact, 

00:06:18,039 --> 00:06:42,979 [Piotr Durlej]
bo no właśnie te quality jest takie, bym powiedział bardziej, bardziej patrzące do przodu, bym
powiedział, że takie hope, nadzieja, na zasadzie, czy wiesz, czy wdrażamy jakieś nowe rzeczy, czy
jakby czy jakoś coś rozwijamy się, czy ten nasz proces jest jakby lepszy. I to jest jakby dość
trudne do uchwycenia i według mnie zależne bardzo od każdej jakby innej firmy. No ale jeszcze są te
dwa. 

00:06:42,979 --> 00:06:47,319 [Michał Krajewski]
Tak i wydaje mi się też, że-- 

00:06:47,319 --> 00:06:55,719 [Michał Krajewski]
ale to pewnie na końcu opowiemy o czymś, co chyba jest najważniejsze dla product managera. Ale teraz
kolejnym. 

00:06:55,719 --> 00:06:59,779 [Michał Krajewski]
No właśnie tym metryką, o której oni mówią, to jest 

00:06:59,779 --> 00:07:11,379 [Michał Krajewski]
effectiveness. Ale tu bardziej chodzi właśnie o takie experience developera, tak? Czy dokumentacja
jest dobra, czy ma czas na deep focus, na deep work, czy ma czas-- czy 

00:07:11,379 --> 00:07:18,999 [Michał Krajewski]
jest w stanie szybko zareagować, bądź inny dział jest w stanie szybko zareagować na jakiś incydent,
tak? Czy 

00:07:18,999 --> 00:07:29,399 [Michał Krajewski]
jest zadowolony też z pracy product managera, jeśli chodzi o planowanie na przykład i czy zna
priorytety, czy dobrze jest opisany ticket i tak dalej, nie? I tutaj właśnie 

00:07:29,399 --> 00:07:34,079 [Michał Krajewski]
też w formie ankiety, bo to wszystko jest tutaj w formie ankiet tak naprawdę opisane.