Mentionsy

Podcast dla liderów IT i nie tylko.

Dzisiaj mamy jeden z tych odcinków, które bardzo lubimy, czyli wywiady z gośćmi, spotkania z gośćmi.

Moim gościem dzisiaj jest Jarosław Burda, senior product owner w Emacs, z którym pracowałem przez ponad 6,5 roku.

Dzięki wielkie, że przyjąłeś zaproszenie do podcastu Nerd Management.

Powiedz nam słuchaj taką rzecz, bo Ty jesteś Product Ownerem z krwi i kości, senior Product Ownerem, jak już mówiliśmy z Krzyśkiem i od strony lidera, lidera zespołu, lidera technicznego, powiedz mi po co tak naprawdę jest ten Product Owner?

Niektórzy myślą w ten sposób, że jak jest jakiś problem, to warto mieć jakąś osobę, która w pełni odpowiada za ten problem, za rozwiązanie tego problemu.

No i ja właśnie jestem takim Product Ownerem, który bierze odpowiedzialność za rozwiązanie jakichś problemów.

Jak to z Twojego doświadczenia jest, jeżeli chodzi o zespoły deweloperskie?

Bo mi się wydaje, tak z mojego doświadczenia, że to jest różnie, że z odpowiedzialnością u deweloperów

Jako produktor stoisz tak naprawdę pośrodku.

Jak chcesz chaty połączyć?

Po pierwsze to jest taka kwestia, żeby zbudować jakąś taką synergię i współodpowiedzialność za ten program, który się rozwiązuje.

Tak na koniec dnia, tak jak wcześniej powiedziałem, ten problem jest jakby na barkach Product Ownera.

To zespół techniczny odpowiada za rozwiązanie techniczne tego problemu.

Natomiast z perspektywy Product Ownera jest niezwykle istotne, żeby ten zespół też zaangażować po to, żeby on użyczył swoich umysłów w tej całej podróży związanej z tym problemem, produktem, rozwiązaniem.

No bo ta historia zaczyna się od tego, że problem został w jakiś sposób wstępnie zdefiniowany.

No i wtedy się zaczyna taka podróż.

Podróż przez to, żeby ten problem na początek dobrze zrozumieć.

Można sobie wyobrazić, że taka osoba zanurza się samodzielnie w ten problem i ten problem w jakiś sposób

Waliduje, uczy się, rozmawia z użytkownikami, rozmawia z biznesem, szuka danych i próbuje ten problem jakoś określić i ponownie zdefiniować, zredefiniować, zwalidować.

Natomiast bez wsparcia zespołu takiego inżynierskiego

Z reguły powiedzmy jest trochę gorszy niż ten wynik tej takiej synergii różnych umysłów.

I to co ty właśnie zwracasz przy budowaniu zespołów, że te umysły są jakoś zdywersyfikowane, że ludzie mają różny background, mają różny wiek, mają różne doświadczenia za sobą.

I jakby ta bogactwo, różnorodność tych umysłów sprawia, że rozpoznanie tego problemu, jego eksploracja jest dużo bardziej skuteczna.

Także poza tym, że zespół odpowiada za rozwiązanie techniczne, to jeszcze użycza swoich umysłów, swoich mocy obliczeniowych, każda z nich jest trochę inna, po to, żeby ten problem dobrze zbadać, dobrze go zrozumieć i ponownie zredefiniować.

Różne od tego wynikającego z tego, powiedzmy, naukowego podejścia do jego eksploracji.

Ciekawą rzecz powiedziałeś odnośnie podejścia naukowego czy różnego typu zasad, workflows, sposobów pracy w projektach.

No ale gdybyś ty miał powiedzieć...

Jaka forma z Twojej praktyki współpracy z zespołem deweloperskim, współpracy z liderem jest najbardziej skuteczna, najbardziej praktyczna i też najłatwiejsza do zastosowania, wdrożenia?

Z mojego doświadczenia to wygląda trochę tak, że ten zespół to musi sobie poukładać sposób pracy taki, jak najbardziej rezonuje w tym zespole.

Z mojej perspektywy istotne jest, żeby ten proces był taki iteracyjny, żeby pozwalał na szybko wkładać rzeczy do procesu, szybko je walidować i szybko też dostawać w jakiś sposób rezultat tej walidacji.

Drugi element jest taki, żeby w tym procesie była okazja, żeby ten proces przydział tej synergii umysłów, o której wcześniej wspominałem.

Może właśnie na początek warto, kiedy ten zespół jest sformułowany, warto podejść tak bardzo kanonicznie do tych metodyk, żeby nałożyć na siebie wszystkie te ograniczenia i żeby tą płaszczyznę zbudować tak jakby w pełni.

Takie najbardziej dojrzałe zespoły, z którymi miałem okazję pracować, one z czasem wypracowywały sobie własną metodę.

Na zasadzie widziałem Product Ownerów, którzy wrzucali coś do zespołu i znikali.

Ich nie było, ale też widziałem Product Ownerów takich, którzy pracowali ramię w ramię w tym zespole pod względem rozwiązania problemu.

Ta druga, dlatego że w interesie Product Ownera jest to, żeby wykorzystać potencjał zespołu technicznego.

Inwestując w komunikację z zespołem i włączenie tego zespołu w ten proces, Product Owner otrzymuje taki zwrot z inwestycji w postaci lepszych rozwiązań, zaskakujących.

To nie ma szans zaistnieć albo ma bardzo znikome szanse, żeby zaistnieć, jeżeli nie ma właśnie tej intensywnej pracy z zespołem na co dzień.

To nawet wam powiem, że to jest bardzo dobra rzecz dla was jako dla liderów, żeby mieć po pierwsze dobrego product ownera, ale po drugie dobrze z nim żyć, bo żyjąc dobrze z product ownerem, ustawiając cały proces, jesteśmy w stanie

To jest Evan Lapointe.

Natomiast można też trochę zagłębić się jakby w te jego prace związane z takim neuroscience, jeśli chodzi o pracę zespołów.

Ewan był gościem podcastu Leniego Raczyńskiego.

Podlinkujemy wszystko w notatkach do tego odcinka.

Generalnie zachęcam też Nerd Managerów do tego, żeby zaglądali na podcast Leniego, dlatego że to jest takie bezpośrednie źródło informacji z Doliny Krzemowej, jak ludzie pracują nad produktami, ale też jak inżynierowie pracują z produktami.

Evan jako jeden z elementów tego, żeby zespół pracował w wydaniu, to jest danie temu zespołowi jakiegoś znaczącego celu.

Wobec tego ta twoja obserwacja niejako jest potwierdzona w badaniach naukowych Evana, że cel jest jakby kluczowy dla tego, żeby ten zespół wszedł na wyższy poziom takiego performance'u.

Jest jeszcze jedna rzecz, ona chyba tam nie była w podcaście wymieniana.

To jest kultura zespołu i mi to kiedyś dało taką perspektywę rozpoznawania, czy ta postawa zespołu jest odpowiednia do tego, żeby rozwiązywać wspólnie problemy.

Ewon to podzielił na cztery czy pięć takich poziomów.

Ten poziom najniższy to jest to, kiedy rozmawiamy o rozwiązaniu jakimś i zespół wychodzi z pozycji takiego

Poszukiwania negacji tego rozwiązania problemu.

Czasem jest ciężko rozpoznać, dlatego że czasem ta negacja rzeczywiście jest uzasadniona.

Często poruszamy się w takim mało zdefiniowanym obszarze i tu z jednej strony jest łatwo zanegować sytuację ze względu na to, że ta praca product ownera nie była właściwie wykonana i jest za dużo niewiadomych rzeczy, ale też łatwo z drugiej strony zanegować cokolwiek.

Bo z natury ten... Czyli Ci chodzi o to, że się nie da, po prostu się nie da, tego się nie da, to nie pasuje, to złe.

Kolejne poziomy to jest poszukiwanie, żeby ten product owner podał instrukcję, jak rozwiązać, jak opracować to rozwiązanie.

Kolejny poziom był, żeby ten product owner podyktował to rozwiązanie samo w sobie.

Natomiast te poziomy, które dawały duży zwrot, jeśli chodzi o efektywność zespołów, to jest poziom, kiedy zespół poszukuje takiego głębokiego zrozumienia.

Jeżeli rozmawiamy o zespole, to on się nie koncentruje na

Odrzuceniu, na instrukcjach, na rozwiązaniu, tylko on się koncentruje na tym głębokim zrozumieniu kontekstu, głębokim zrozumieniu problemu i wtedy ta praca staje się efektywna i taką pracę najbardziej lubię w zespołach, kiedy są otwarci na zagłębienie się w problemy.

Jeżeli mamy w zespole, załóżmy, samych juniorów, którzy marudzą, narzekają, albo z drugiej strony, no samych takich seniorów, którzy zjedli wszystkie rozumy i tak naprawdę uważają, że są najmądrzejsi na świecie, a w praktyce niekoniecznie dużo produkują, czy niekoniecznie dużo są w stanie rozwiązać, no to musimy sobie zdawać z tego jako liderzy sprawę i zadbać o to, żeby ten zespół

Nie zapomnijcie zasubskrybować oraz zafollowować mnie!

To musi być też na tyle dojrzały, ludzie muszą być na tyle ogarnięci i doświadczeni, też muszą mieć postawę określoną do tego, więc to jest ważne na etapie budowania zespołu, żeby takich ludzi też mieć.

No i na koniec dnia w sumie tak z mojej perspektywy, no to też jedni i drudzy są potrzebni, no bo czasem są takie zadania proste, prawda, które najzwyczajniej w świecie ktoś musi zrobić i są rzeczy takie koncepcyjne, gdzie naprawdę trzeba się zmurzyć, trzeba wejść głęboko w temat, trzeba się z nim uzasadnić,

Nie wszyscy zespole muszą się angażować w pracę kreatywną.

Natomiast konieczne jest, żeby w zespole były jedna, dwie, może trzy osoby, które odnajdują w tym swoją pasję i chcą dołączyć do tej podróży związanej z budowaniem rozwiązań i produktów.

No dobra, ale to teraz wrzućmy taki kij w mrowisko, słuchaj, bo ja widziałem ostatnio, że w sumie ty jako dobry product owner, który jest ogarnięty w technologiach bieżących, używa narzędzi AI, widzi w tym fun i chce się tym bawić, tak naprawdę chyba już nie potrzebuje tak naprawdę zespołu developerskiego.

Pochwal się, co ty żeś tam zrobił ostatnio.

Dzisiaj jeszcze patrzymy na to w ten sposób, dotykając tego samemu, że możemy w jakiś sposób tą produktywność naszą poprawić.

Natomiast są predykcje takie, że rzeczywiście niektóre z zawodów o jakiejś takiej charakterystyce dużej powtarzalności pracy

Teraz trudno powiedzieć, czy Product Owner mógłby zastąpić AI-em zespół deweloperski.

Ja jakby ostatnio miałem takie doświadczenie, które no wspominam dość ciężko.

Tak, podziękujemy.

...drastycznych zmian na rynku pracy, że te, tak jak dzisiaj sobie mówimy o tym, że AI pomoże nam zwiększyć naszą produktywność o ileś procent, no to Craig uważa, że pewne zawody będzie można zastąpić całkowicie.

Budzi się taka konkluzja, która może też wpływać na jakiś niepokój, że rzeczywiście te role, które wymagają w szczególności takiej rutyny, te role mogą być bardzo zagrożone.

W tych publikacjach jest takie bardzo naukowe podejście.

Oni mierzą, jak im pomagają narzędzia AI i co-piloty i te wszystkie narzędzia związane z oprogramowaniem.

Natomiast prawdopodobnie skończy się na zwielokrotnieniu tej efektywności zespołów.

Jestem w stanie podać zespołowi dużo lepiej opisane wymagania, które gdzieś powstały w wyniku tego researchu wcześniejszego.

Jak zespo ł i PO moga działac razem z AI?

Tym kodem można się dzielić, można go wziąć i potem spróbować go użyć.

Na taki compliance raczej firmy nie chcą wydawać dużo pieniędzy i product ownerowie nie chcą angażować zespołów na długo, żeby takie problemy rozwiązywać.

To był problem polegający na tym, że trzeba zbierać dokumenty prawne dotyczące produktów.

...że prawdopodobnie stoimy przed takim dylematem albo wcale, albo kilka osobomiesięcy pracy.

Wchodząc w ten lowablo, ja właściwie chciałem tam narysować prototyp po to, żeby wspólnie potem zrobić taki brainstorming.

Jak tą funkcjonalność możemy w jakiś prosty sposób...

Na skróty, zbudować po to, żeby dostarczyć chociażby MVP.

Natomiast cała ta praca frontendowa związana z załączaniem dokumentów, drag and drop, listowaniem produktów, stronicowanie, jakieś komponenty, które umożliwiają wybieranie wielu produktów, podłączanie do jednego dokumentu.

Te wszystkie funkcjonalności niejako mamy dane po...

Po paru godzinach promptowania w Lowablu i wręcz do takiej decyzji, taką decyzję podjęliśmy.

Jako MVP bierzemy front wygenerowany przez maszynę i spinamy to z tym naszym backendem, żeby podać prawdziwe produkty, żeby te dokumenty zapisać u nas w infrastrukturze.

Do tej pory by to nie było możliwe.

Do tej pory byśmy postawili siebie i tą organizację przed faktem albo bardzo drogo, albo wcale.

Produktywność razy ileś, a nie chciałbym tutaj teraz estymować o ile razy, bo to jest też łatwe do podważenia.

Bo że się to wrzucili na product, to obsługuje pliki i działa dużo szybciej niż powinno, prawda?

I z tego doświadczenia twojego, powiedz, jak ty to widzisz, jeżeli chodzi o też przyszłość programistów?

No bo jeżeli ty jako Product Owner, mając wiedzę biznesową, wiedzę domenową, mając zebrane wymagania, potrafiąc użyć narzędzi, które wypromptując, wyklikają ci to, co trzeba, to gdzie tak naprawdę jest potrzebny ten zespół deweloperski?

Na pewno jest potrzebna rola programisty do tego, żeby to zintegrować, żeby to zwalidować, żeby w przyszłości, jeżeli okazałoby się, że to rozwiązanie jest użytkowane i jest użytkowane w coraz większej skali, żeby sprawić, żeby to było skalowalne, żeby to było bezpieczne.

Kolejna potrzeba, która się tu pojawia, to jest... wracamy z powrotem do tych umysłów.

Potrzebne są umysły tych ludzi, no bo my do tego rozwiązania doszliśmy, czy pomysłu na to rozwiązanie doszliśmy po iluś dniach pracy z biznesem, z użytkownikami, z tymi dokumentami.

Zatem jeżeli myślimy o zespołach, jak ja to sobie wyobrażam, to potrzebne są takie kompetencje full stackowe, takie bardziej wszechstronne, żeby integrować, dobierać, zastępować.

A do tego właśnie ta kreatywność i ta otwartość, te umiejętności takie społeczne, miękkie, do tego, żeby być w stanie użyczyć swojego umysłu do rozwiązania problemów.

Czyli to nie jest tak, że programści są do wywalenia i bezużyteczni, więc oni się tak przydają, tylko muszą awansować tak naprawdę na ten wyższy poziom, czyli jeżeli macie ludzi, którzy będą klepać tylko i wyłącznie kod, no to ich czas już jest policzony albo właściwie to już się skończył, ale ci, którzy potrafią myśleć, chcą myśleć, chcą się rozwijać, tak naprawdę potencjał tutaj jest ogromny i to jest, jeżeli mówimy o AI, to tak naprawdę narzędzie, które dobrze wykorzystywane może tą pracę przyspieszyć.

Jak zespo ł i PO moga działac razem z AI?

Bo ja tam określiłem pewien model współpracy Product Ownera z zespołem nad produktem, nad rozwiązywaniem problemów biznesowych.

Że ten Product Owner jest tą osobą, która odpowiada w pełni za to rozwiązanie.

Może przykład, powiedzmy, szef działu handlowego, czy nie wiem, szef, liga, obserwuje pewien problem albo objawy, wobec tego zgłasza się do IT z prośbą o rozwiązanie tego problemu jakby cyfrowo, w postaci jakiegoś rozwiązania informatycznego.

Roboty mamy po to.

Pojawia się jakiś może analityk biznesowy, systemowy.

Może pojawia się jakiś kierownik projektu, który to wszystko orkiestruje, spina.

I w pewnym momencie te wymagania powstają.

On ma target do zrobienia, który jest dużo wyższy niż poprzedni i jego nie obchodzi koszt.

Jego pochodzi deadline.

I dochodzi do budowania tego rozwiązania w oparciu o te wymagania, o ten design, który został stworzony gdzieś poza zespołem.

W jaki sposób ten projekt się nie udaje?

On im wszystko podał, a oni to skiepścili.

I to jest właśnie ta sytuacja, kiedy nie ma właścicielstwa i to jest ten kontrast między tym, że właścicielstwo jest i to właścicielstwo jest w postaci właśnie product managera czy product ownera, który pracuje razem z zespołem nad rozwiązaniem tego.

Te koncepcje pracy nad pełną własnością i empowermentem zespołów produktowych i product managerów, product ownerów.

I tutaj warto wspomnieć i też zachęcam Nerd Managerów do tego, żeby też sięgnęli do literatury albo przynajmniej do tych linków, które umieścimy pod tym odcinkiem.

Empowered.

O budowaniu zespołów produktowych takich empowered.

I tam się właśnie to ukształtowało, jakby moje postrzeganie, jaka jest rola tego product managera i product ownera.

Tam znajdziecie opis, co to jest product team, że on jest empowered product team.

Za jakie obszary w tym rozwiązaniu odpowiadają jakie osoby?

Tam znajdziecie też, że istotna jest ta synergia umysłów, o której wspomniałem.

Dlatego, że coraz większy nacisk jest budowanie po co my to robimy?

Bo proces to jest to wyrażać szybko, pewnie w oparciu o dane empiryczne zebrane wcześniej i podążanie po kroku.

Natomiast tutaj nacisk jest dużo na to po co my to robimy i jak my dążymy do rozwiązania tych problemów i czynimy te rozwiązania bardziej prawdopodobnymi.

To jest bardzo dobrą konsekwencją wprowadzenia tych właśnie narzędzi, AI, technologii, przyspieszenia mocnego tej technologii, że nie będziemy robić bzdurnych rzeczy, czy po prostu głupich, nikomu niepotrzebnych, bo ktoś akurat znajdzie się inwestor, który gdzieś tam się naczytał, że

Jak położy kilka baniek na aplikację do zarządzania niczym, to wyciągnie coś.

W końcu trzeba zacząć myśleć, po co to robimy, mieć to wszystko ułożone, żeby miało to ręce i nogi.

I myślę, że to jest mega dobre podsumowanie tego, czym się ty zajmujesz jako Product Owner.

Powiedz mi jeszcze taką rzecz, gdybyś miał...

Jedną rzecz, może albo kilka rzeczy, co nie wiem, jedną, dwie, trzy, jak uznasz, przekazać takim świeżo upieczonym liderom, początkującym liderom, których nie wyszkolili, których nie nauczyli jak być dobrym liderem.

To właśnie jest chyba wyjście z tej perspektywy zespołu wytwórczego.

Po co my to robimy?

To jest to, że w modelach, które przyszły do nas z Doliny Krzemowej, w tych modelach podstawą jest ten empowerment zespołu.

Wobec tego pracą takiego managera jest to, żeby dać temu zespołowi, umożliwić temu zespołowi złapania kontekstu tej organizacji, kontekstu tego celu, po co my to robimy, znalezienia, wymuszenia tego celu na tym otoczeniu, bo jeżeli product manager czy owner nie przynosi go, to oznacza, że coś jest dysfunkcyjnego, to właśnie ten nerd manager musi się rozejrzeć, że coś tu nie gra.

I doprowadzić do sytuacji, czy zwalidować, dlaczego to nie gra, dlaczego nie ma celu, dlaczego product manager nie sięga do zespołów, żeby budować rozwiązania.

Kolejną rzeczą to jest, że ci ludzie w zespole, oni muszą też być w jakiś sposób zmotywowani, zachęceni do tej otwartości i do tej odwagi, po to, żeby oni mogli wyrazić swoje zdanie.

Po to, żeby to wyrażenie tego zdania wiązało się z jakąś taką bezpiecznym otoczeniem, bo bezpieczne otoczenie sprawia, że to wyrażenie zdania staje się bardziej naturalne.

Tylko na początek musi być to bezpieczeństwo, że ja mogę, że nie będę skarcony, że się nie będą ze mnie śmiać.

Bo każde zdanie wypowiedziane przez kogokolwiek w trakcie takich warsztatów, brainstormingu i tak dalej, ono i każde jest cenne.

Nawet jeżeli wydaje się nieadekwatne, ono jednak pobudza do jakiejś refleksji odnośnie tego, nad czym my teraz pracujemy albo przynajmniej nam pozwala zdefiniować, że ten obszar jest poza naszym zainteresowaniem.

Powiedz jeszcze na koniec, gdzie można Cię znaleźć, gdyby chciał ktoś poszerzyć temat, dopytać, jeszcze zebrać więcej informacji, jak najłatwiej się z Tobą skontaktować.

Także podlinkujemy też profil Jarka w notatkach do tego odcinka, także śmiało walcie do Jarka, chętnie pomożemy.

To teraz już chyba wiecie czemu zawsze gdy słyszałem z naszej firmy opinie o Jarku to były same pozytywne dotyczące jego profesjonalizmu i tego w jaki taki skondensowany, analityczny sposób podchodzi do tych rzeczy, którymi się zajmuje.

Wszystkie linki, materiały i książki, o których mówił Jarek, podlinkujemy w notatkach do tego odcinka, także zobaczcie koniecznie, bo trochę tego było i warto z tego korzystać, warto się tym zainteresować.