#13 Programista vs PM, czyli o relacji Development-Operations. Paulina Piechaczek i Michał Warda

Słuchacie Iteracji, podcastu EL Passion. Rozmawiamy o designie, dewelopmencie, biznesie i o tym, jak pogodzić wszystkie racje w IT, nie tylko dla kodujących. Cześć wszystkim, witamy w podcastie Iteracja. Dzisiaj jest ze mną Paulina. Cześć wszystkim. A ja jestem Michał. Ja jestem CTO w EL Passion. A ja jestem Agile Project Managerem w EL Passion. Dokładnie. I dzisiaj będziemy rozmawiać na bardzo ciekawy dla nas temat, mianowicie o relacje pomiędzy operations i zespołem developerskim w ramach budowania aplikacji dla klientów. Chyba ja ci nie mówiłam, skąd się wziął w ogóle pomysł na ten odcinek. Nie, nie mówiłaś. Mam taką małą anegdotę.

Kiedyś wynajęłam sobie biurko w przestrzeni coworkingowej. No i pierwszego dnia, kiedy wszyscy pytają się, czym się zajmujesz, gdzie pracujesz, to na moją odpowiedź, że jestem project managerem w firmie zajmującej się produktami cyfrowymi, Jeden developer stwierdził, a, to ty jesteś ticketiarą. No i podejrzewałam, co ma na myśli, ale chciałam go tak delikatnie podpytać, o co mu chodzi. No i mówi, no wiesz, no taki proxy manager, wy tylko przekazujecie dalej informacje, zarządzacie Giro i tyle. Poczułam takie lekkie ukłucie, bo zaczęłam się zastanawiać w ogóle, skąd wziął się taki stereotyp, bo już kilka razy słyszałam o czymś takim, no i zaczęłam drążyć właśnie, drążyć ten temat, no i stwierdziłam, dobra, jeżeli ludzie spoza naszej firmy tak mówią, to zapytam wewnątrz.

Czy też tak uważasz, że jesteśmy tikaciarzami, brzydko mówiąc? No i czy też w twojej głowie pojawia się pytanie, co ta osoba w sumie robi przez cały dzień? No bo jest częścią zespołu, ale nie wytwarza niczego tak namacalnie. To jest bardzo trudne pytanie i wydaje mi się, że wiem skąd pochodzi ten stereotyp. Mi się bardzo przez lata, jak dewelopowałem projekty, to bardzo często też właśnie nie współpracowaliśmy z project managerami. W sumie nasza współpraca z project managerami w ramach EL Passion zaczęła się jakieś 3-4 lata temu dopiero.

Więc stosunkowo niedawno, biorąc pod uwagę, że Software House ma już z 11 czy 12 lat. A na to miał wpływ rozwój firmy? Tak. Miało na to wpływ bardzo dużo w sumie czynników, ale przede wszystkim odkrywanie przez nas wartości właśnie w roli też Project Managera. To nie było takie oczywiste dla nas. Mieliśmy w przeszłości bardzo, może nie bardzo dużo, ale mieliśmy w przeszłości projekty, w których ewidentnie czuliśmy się swobodniej, kiedy mieliśmy wolną rękę i też w naszej głowie project manager był osobą, która by nam niepotrzebnie komplikowała nasze relacje z bezpośrednim klientem.

Tak to było w głowie, tak jak mówię, winne jeszcze kilka lat temu, ze względu na moje relacje poprzednie w niektórych projektach, tak miałem w głowie. To wynikało raczej z charakterystyki tego, w jaki sposób próbowaliśmy budować projekty. I dla mnie jest duża różnica pomiędzy naszym Agile Project Managerem, co samo w sobie jest trochę nietypowe, a taką rolą Project Managera rynkową. I odpowiadając na pytanie, czy myślę tak samo, myślę, że nasza rola jest zupełnie inna niż to, jak ludzie patrzą na tę rolę na zewnątrz.

A jak ty patrzysz na tę rolę? Bo ja... Czekałam na odpowiedni moment, żeby wejść, ale chciałam też usłyszeć, co myślisz. No bo to jest twoja perspektywa, dewelopera głównie. I wiem też, że zmieniłeś nastawienie, bo wspomniałeś mi kiedyś o tym, dlatego też pomyślałam, że to jest dobry pomysł, żebyśmy my się spotkali. Jak ja to widzę? Podejrzewam, że osoby, które mówią takie rzeczy, po prostu nie pracowały z nami. Rzeczywiście może być tak, że patrząc na tę rolę tak płytko, spłycając ją, może się komuś wydawać, że to rzeczywiście jest przeklikiwanie, administracja jiry, przepisywanie zadań, przekazywanie informacji, no bo bardzo często project manager jest takim łącznikiem między klientem, czyli światem biznesowym, a technologią, więc

Rozumiem taki pogląd, że to może być taki właśnie proxy manager, który przekazuje i nic więcej, ale to rzeczywiście bardzo... To jest związane ze środowiskiem, w jakim pracujemy, bo mówiłeś, że na początku pracy, kiedy Mieliście, zakładam, mniejszy zespół i ten kontakt z klientem był bezpośredni. Ty wchodziłeś w rolę PMA, tak trochę nieświadomie, więc brałeś te obowiązki, które zwykle osoba na stanowisku project managera przyjmowałaby te obowiązki. Ty to robiłeś, więc nic w przyrodzie nie ginie. To było tylko przez inną osobę zarządzane. Tak, wydaje mi się, że po prostu

Dużą wartość, produkt ostateczny czerpię z tej relacji pomiędzy osobami i tej konieczności komunikacji. I rola project managera nazywanego proxy managerem wtedy w mojej głowie była właśnie tym, że OK, to jest osoba i z niej zdejmujemy obowiązek tego, żeby komunikowała się z klientem. I mi to od razu w głowie się kojarzyło z niebezpieczeństwem tego, że zamiast mieć osobę, zamiast mieć sztab ludzi, którzy pracują nad produktem, który spełnia Oczekiwania klienta. Mamy sztab ludzi, którzy pracują nad produktem, który spełnia oczekiwania osoby innej, która jakby parafrazuje to, co klient mówi.

I wtedy to się udaje rzeczywiście, ale jeżeli mamy zespół 5-6 osobowy plus klienta, który nie do końca rozumie technologię, no to jest problem. No i w tym momencie wchodzimy my, agile project managerowie. Co znaczy to agile w ogóle też trzeba chyba wyjaśnić, bo taki powiedzmy zwykły project manager Ma swoje określone zadania. On skramie nie jest jednoznacznie wpisany, ale generalnie jego zakres obowiązków jest jasny. W EL Passion ta rola jest Jest takim zlepkiem trzech ról, bo to jest z jednej strony taki typowy PM, który dba o budżet, zarządza timeline'em, informuje klienta, więc wykonuje takie podstawowe administracyjne, można powiedzieć, obowiązki.

Kolejną rolą, takim kolejnym etapem to jest Scrum Master, czyli osoba, która dba o procesy scramowe, o to, żeby były one wykonywane poprawnie, żeby były w ogóle, bo o tym też się często zapomina. I ostatnią rolą to jest, tutaj możemy użyć tego słowa proxy, proxy product owner, czyli ktoś, kto wykonuje wizję klienta, Przy okazji pomagając mu układać backlog, osoba, która jest takim mostem pomiędzy zespołem i klientem. Czyli mamy taką trójstopniową rolę, która w EL Passion sprawdza się. Ale oczywiście to też zależy od klienta, jaki do nas przychodzi i jakie potrzeby chciałby zaspokoić i jakie też ma możliwości, no bo mając swój zespół, w którym na pokładzie jest Product Owner, to my też staramy się współpracować z tym klientem tak, żeby wszystkie dziury, które się pojawiają w komunikacji w zespole, łatać naszymi kompetencjami.

Ja szczególnie, wracając do tego, bo tak mówiłem o historii, jak kiedyś myślałem i jak teraz myślę, to zorientowanie się, że ta trzecia rola, którą wymieniłaś, ten proxy product owner, Izolujesz, w sensie ty, czyli jakiejkolwiek osoba pełniąca tę rolę, izolujesz ludzi od klienta, tylko że uzupełniasz kompetencje klienta w kontekście rządzenia, ownerowania w zespole, który potrzebuje tego, bo tego zespół potrzebuje. To jest my, ja pamiętam, robiliśmy kiedyś statystykę odnośnie tego, jak zespół developerski

Subiektywne. I bardzo szybko zorientowaliśmy się, że A, i na koniec, jeszcze poza tym, że mieli ocenić wszystko od 1 do 5, to było jeszcze ocenienie tego subiektywne, jak dobrze ci się pracowało w tym projekcie. Tylko, że to było tak bardziej naukowo, nie chcę powiedzieć naukowo, ale nie tak uproszczone, jak ja teraz mówię, ale mieli ocenić to, jak się bardzo im podobało w projekcie i zauważyliśmy kolosalną korelację pomiędzy tym, Kiedy Product Owner był oznaczony wysoko, to zespół czuł się bardzo dobrze. Jeżeli Product Owner był zupełnie niezgodny ze Scrum Guidem, jakby ze sztuką, z takim odczuciem Product Ownera,

To deweloperzy i designerzy też, bo to cały zespół, ogólnie zespół deweloperski to jest dla mnie cały zespół odpowiedzialny za dostarczenie produktu od A do B. Czyli też design, development, devops, wszyscy, wszystkie osoby, które nad tym pracują. Wracając Była kolosalna korelacja pomiędzy oceną Product Ownera i zadowoleniem z projektu i praktycznie nie było żadnej korelacji innej z żadnym innym czynnikiem. Więc ta rola Product Ownera była kluczowa zawsze. Zawsze była dla nas kluczowa i to było 5 lat temu, 10 lat temu zawsze była kluczowa. I jak zauważyłem, że przychodzą do nas klienci, którzy tej roli nie potrafią wypełniać i mają fajne pomysły, mają fajne chęci,

To zauważyłem, jak dużą wartość przynosi osoba, która je w tym wesprze. I że my, jako firma, możemy pełnić tę usługę wspierania klienta. I to zmieniło moje spostrzeżenia na temat, w ogóle właśnie to wymyślenie, to nazwanie tego nie tak bardzo project managementem, tym stricte, ale też agile project managementem, to wytłumaczenie tych różnych ról, w które się wcielasz na przykład w projekcie, to mi dużo wytłumaczyło. Tak, też wiem, że ta nazwa nie powstała z dnia na dzień. To była iteracja za iteracją i pomysłów było wcześniej kilka, ale stanęło na tym, że to jest Agile Project Manager, no bo jesteśmy agile, pracujemy w Scrumie. Mówiłeś, że zespoły oczekują tego, żeby pracować w Scrumie.

Ja myślę, że one są na to gotowe. I przygotowane w pełni na to. Już nauczyliśmy się procesów, które zachodzą, więc nagle jak tej osoby w roli Product Ownera nie ma albo ona jest, ale nie do końca spełnia oczekiwania zespołu, no to pojawia się problem. I to jest bezdyskusyjne. Widzę, że się zgadzamy. Chciałabym podjąć jeszcze temat Scrum Mastera, bo to też jest bardzo ciekawy wątek. Nie chciałabym być tutaj adwokatem wszystkich Scrum Masterów, ale przez to, że wchodzimy też w taką rolę, to zaczęłam się zastanawiać, widząc tytuły filmików na YouTubie typu, co robi Scrum Master przez 8 godzin.

Też rola Scalamastera akurat była dla mnie zazwyczaj zrozumiała, ale też rozumiem, tego też się nauczyłem po tym, jak zacząłem pracować z większą ilością ludzi. Czuję, że to jest Żeby posiadać w zespole osobę, która jest w stanie wypełnić tę rolę, albo inaczej, można zbudować zespół, który się świetnie wypełni wszystkie inne role potrzebne do tego, żeby budować produkt bez osoby posiadającej kompetencje wykonywania tej roli i może się zawalić cały projekt. Ogólnie nauczyłem się tego, że To też filmiki z internetu, jak zostać deweloperem 10x, czy jak zostać deweloperem 100x, czyli osobą, która jest w stanie zrobić wszystko dla wszystkich, ze wszystkim.

O, to zacznę od tego pytania. Mam jeszcze dużo pytań. Okej, to ja się cieszę, że zadałeś to pytanie, bo chciałam też to poruszyć. No bo z jednej strony mamy stereotypy i mity na temat PM-a. A propos mitów, żart, uwaga, obiecam, że będzie żart. Jaki jest najgorszy mit w Project Managerze? Google Meet. Wow. Dobrze, kontynuujmy, kontynuujmy. Utnijmy tutaj. Tak, mity i stereotypy na temat PM-ów wiemy jakie są. Ja swoje stereotypy i mity na temat deweloperów oczywiście też mam, no bo o to chodzi właśnie, to są dwa światy i zawsze będą jakieś konflikty, zawsze będzie Jakaś różnica między nami, bo nasze prace są różne.

Więc ja nigdy nie lubiłem takiego podejścia, nigdy nie chciałem mieć, ja się obawiałem na przykład tego project managementu, że właśnie Będziemy mieć takie przyzwolenie dla zespołu całego, że będzie osoba, na którą będą zrzucać rzeczy, których nie chcą robić. Nienawidzę tego, w sensie, szczerze. W sensie, dla mnie to jest tak kluczowe, żeby każdy, kto jest na przykład na spotkaniu, na planowaniu, czy na czymś, żeby był skupiony, żeby rozumiał, żeby aktywnie w nim uczestniczył. Nieważne, czy jest backendowcem, frontendowcem, designerem, Projekt managerem czy klientem, jeżeli są takie planowania, to dla mnie tak kluczowa jest ta obecność, że bałem się zawsze tego, że mając jedną osobę, która zawsze na przykład prowadzi takie spotkanie, że będzie takie przyzwolenie, nagle się zrobi taka atmosfera w firmie, że każdy powie, a tamta osoba się tym zajmie.

I tego bardzo nie lubię. Wiesz, że wciąż jest takie zagrożenie. Wiem, wiem, wiem. Nawet jeżeli jest ten project manager i on nie bierze na klatę wszystkiego, to wśród designerów, developerów zawsze jest jakiś frontman, nie? Zawsze jest osoba, która pogada z klientem, która ma gadane, która... Uśmiechasz się, bo to zwykle jesteś ty, nie? Tak, no. No i takie zagrożenie jest zawsze, niezależnie czy ten PM jest, czy nie. Tak, ja pamiętam naszą konwersację jakiś czas temu na temat tego, jak pracowaliśmy w jednym projekcie razem, wytłumaczyć jednemu deweloperowi, że to nie jest tak, że on przyjdzie i dostanie wszystko gotowe, ale nie spędzajmy nad tym czasu. Chciałem powiedzieć, że Dopiero po latach zorientowałem się, że da się zbudować atmosferę, w której nie ma przyzwolenia na takie zachowania.