Klasyczny PM i Agile - Marta Stopyra
Klasyczny PM i Agile - Marta Stopyra
Basia: Cześć, witajcie w kolejnym odcinku Agile Bez Scenariusza. Dzisiaj kolejny odcinek z serii PLUS, czyli mamy gościa, a w zasadzie gościnię, Martę Stopyra. Powiedziałabym, że nasza ekspertka od IT, Powiedziałabym też, że chyba najbardziej ogarnięty człowiek, jakiego znamy. Patrycja często mówi o tym, że ja jestem takim ogarniaczem. Ja przy Marcie to pikuś. Więc Marta świetnie zorganizowana kobieta, mama protagonerka, przedsiębiorczyni, ma swoją własną markę Digitally Her, robi przedużo, jest mentorką, prowadzi kursy, ma swój podcast, ma swoją firmę, przecież to tutaj się dzieje już bardzo dużo. Więc jak sama o sobie mówi, obywatelka świata, ja do tego bym dodała, tak jak już powiedziałam, ogarniaczka. Kocha podróżować, kocha robić inspirujące rzeczy, inspiruje przede wszystkim, ale też lubi uczyć się języków obcych, praktykować jogę I pewnie do tej listy Marta sama chętnie dodałaby jeszcze multum rzeczy. Więc Marta, witaj w naszym podcascie.
Marta Stopyra: Cześć dziewczyny. Powiem szczerze, że czuję się tak trochę nie wiem co powiedzieć. Dziękuję bardzo, ale chyba już nic więcej nie będę dodawać. Rzeczywiście lubię robić wiele różnych rzeczy, ale Basia, tak jak ty to przedstawiłaś, to ja bym tak o sobie pewnie nie powiedziała w ten sposób. Natomiast dziękuję bardzo za to. Rzeczywiście działam w IT, uczę o IT. Zaczynałam z Digitally Her w 2019 roku, ucząc osoby nietechniczne, takie które nie studiowały informatyki, project managerów, scram masterów, o IT, tak żeby jeszcze lepiej rozmawiało I współpracowało z deweloperami. Obecnie też zajmuję się transformacją cyfrową, transformacją AI w ostatnim czasie I zarządzaniem projektami, produktami.
Patrycja: Super, dzięki bardzo za to, że dopowiedziałaś jeszcze te dwa zdania o sobie. Dzisiaj z Martą będziemy rozmawiać o temacie właśnie, jak taki klasyczny Project Management ma się do takiego jakiegoś zwinnego świata, z którym my jesteśmy z Basią bardzo blisko. To tak skrótowo. Może zacznijmy od tego, Marta, bo powiedziałaś, że pracujesz jako product owner, teraz obecnie wcześniej miałaś to doświadczenie jako PM. Chciałabyśmy się spytać na dzień dobry, jaki jest Twój styl pracy? Czy mimo tego, że pracujesz jako Product Owner, pracujesz w Scrumie, czy pracujesz w jakimś setupie, w jakiej konfiguracji obecnie pracujesz?
Marta Stopyra: Odpowiedziałabym Patrycja w takim, jak wymaga tego potrzeba, jak wymaga tego sytuacja. Ja bardzo nie lubię takich sztywnych określeń, że powiedzmy jestem PM-em tradycyjnym albo jestem typowo PM-em, który właśnie nie wiem jak tak naprawdę określiłabym siebie PM w Scrumie, bo to jest takie zaprzeczenie, nie mniej jednak też tak pracujemy, nie lubię zabierać stanowiska w ten sposób, uważam, że powinniśmy być elastyczni, że przede wszystkim liczy się pragmatyzm, liczy się common sense, taki zdrowy rozsądek I liczy się otwartość względem tego, co potrzebujemy. Ja w ten sposób staram się pracować, żeby obserwować, jak wygląda sytuacja I korzystać ze wszystkich swoich doświadczeń, ze całej swojej wiedzy. Rzeczywiście pracowałam i jako PM w takim bardziej tradycyjnym podejściu, sama też jestem certyfikowana przez PMA I posiadałam certyfikat PMP, znam też podejście IPMA, jeżeli kojarzycie, to jest właśnie International Project Management Association I oni również mają coś takiego jak Project Excellence Baseline, także jest dużo tych podejść, oczywiście już nie wspominając o tych podejściach zwinnych, ale nie byłabym w stanie określić się, że pracuję tylko w sposób tradycyjny albo tylko w sposób zwinny, to wszystko zależy od tego, jaki jest projekt, jaka jest sytuacja.
Basia: A czy zgodziłabyś się z takim stwierdzeniem, że właśnie nie ma problemu, żeby to miksować, czyli ten klasyczny Project Management, czy te podejścia klasyczne, ta grupa, tak właśnie nazywana, z agile’owymi w jakiś sposób?
Marta Stopyra: Basia, powiem tak, super by było gdyby wszyscy myśleli rzeczywiście tak, że nie ma problemu, natomiast są problemy natury ludzkiej, bo ktoś ci mówi, że no ale jak to, to powinnaś się opowiedzieć po którejś ze stron, albo nie możemy tak robić, bo tego nie ma zapisanego w scram guide, albo pracujemy w Scrumie, więc w zasadzie dlaczego dokładamy do tego jakieś dodatkowe narzędzia, nie jesteśmy czyści w cudzysłowie, jeżeli chodzi o daną metodykę. Także pojawiają się problemy takiej natury ludzkiej, natomiast z mojego doświadczenia I wewnętrznego przekonania oczywiście nie ma problemu, jeżeli mamy otwartą głowę, jeżeli myślimy I analizujemy I też w taki empiryczny sposób podchodzimy do tego wszystkiego, próbujemy, a nie wyznaczamy sobie wchodząc do projektu, że ok, ja będę w ten sposób pracować I będę się tylko I wyłącznie tego trzymać, nieważne co, będę iść pod prąd, bo często tak się okazuje później, jeżeli zadeklarujemy jedno rozwiązanie, no to wtedy problemy się pojawią, ale uważam, że można to robić, ja to robię, myślę, że z sukcesem.
Patrycja: Super to słyszysz, że same sukcesy. Kolejny na Twoim koncie. My tutaj się zastanawiamy właśnie, jak to łączysz, to w takim razie, czy jest jakieś rozgraniczenie, kiedy, nie wiem, ubierasz różne czapki I mówisz, no teraz jestem bardziej klasycznym PM-em, teraz bardziej agile PM-em, jak to w praktyce wygląda, żeby dać naszym słuchaczom taki obraz tego, czy są jakieś rozgraniczenia, czy nie wiem, jako ten bardziej klasyczny PM, są jakieś raporty, które przygotowujesz, a bardziej jako ten zwinny znowu niekoniecznie.
Marta Stopyra: Jak to w praktyce wygląda, to jaki twój typowy dzień pracy może? Na wstępie zaznaczę, że ja jako Project Manager pracowałam przez wiele lat, obecnie nie pracuję jako Project Manager, pracuję jako Product Owner, także trochę w inny sposób współpracuję z zespołami w tym momencie, natomiast odniosę się do tego czasu, kiedy pracowałam jako Project Manager. To już był czas, kiedy w zasadzie była moda na Agile, była moda na Agile równa się Scrum. O tym rozmawiałyśmy jeszcze przed nagraniem, że często ludzie kojarzyli, że jeżeli jesteśmy z winni to jesteśmy tylko I wyłącznie pracujemy w Scrumie. No I rzeczywiście był taki czas, gdzie pracowałam jako Project Manager I Scrum Master jednocześnie z jednym zespołem. To była sytuacja, której Z jednej strony nie polecam nikomu, ponieważ uważam, że bardzo ciężko łączyć te dwie role, role Scrum Mastera I role Project Managera. Z jednej strony jako Scrum Master mamy taki trochę inny mindset, mamy też wspierać oddolnie tutaj nasz zespół, to jest też taki lider służebny, to jest też takie nastawienie na ulepszanie wielu różnych rzeczy, na wspomaganie zespołu właśnie we wzroście, tak żeby w końcu ten Scrum Master nie był zespołowi potrzebny, żeby 10 zespół rzeczywiście był samowystarczalny. Z drugiej strony jako Project Manager zarządzamy budżetem, często prowadzimy negocjacje z klientami, często są jakieś trudne sytuacje, też czasami stresujące, bierzemy odpowiedzialność za całość, no I to wewnętrznie u mnie się, jak mam być szczera, trochę kłóciło, te dwa podejście. Także takiej konfiguracji nie polecam, natomiast odniosę się teraz do Twojego pytania, do jego ostatniej części, Patrycja, pytałaś o to, jak łączyć to oblicze takiego tradycyjnego PM-a z PM-em bardziej zwinnym, agile’owym. Więc ja uważam, że jako Project Manager tak naprawdę pracujemy na granicy wielu światów. Jeden świat to jest świat klienta, to jest świat budżetu, no bo skądś trzeba mieć też kasę na to, żeby dowodzić ten projekt, żeby w ogóle realizować dane zadania. To jest też świat, gdzie staramy się w profesjonalny sposób tego klienta prowadzić, ale również oczywiście nie robić tego za darmo. Więc tutaj wchodzą I negocjacje I różnego rodzaju pilnowania, chociażby change requestów, które to jest dla mnie mit też, że w Scrum, w Agile nie ma czegoś takiego jak change request I można nieskończoność robić tą samą rzecz. Jeżeli jest określony scope, albo nawet nie ma określonego scope, ale jest budżet określony, to dla mnie to jest też change request. Jeżeli rozmawiamy o jakimś rozwiązaniu, że powiedzmy na takim poziomie raczej ogólnym, dostarczymy jakieś rozwiązanie, wiadomo, że też zwinność nam pozwoli doklaryfikować te dane funkcjonalności, ale nie dojdziemy do w ogóle trzeciej funkcjonalności, bo będziemy cały czas przepisywać pierwszą, to dla mnie to są też część requestu, bo na koniec ten klient zapyta mnie, że tutaj obiecywaliście, że dostarczycie tą aplikację, a dostarczyliście tylko, no nie wiem, splash screen, tak? Bo cały czas był przepisywany. Więc dla mnie to jest ta część, za którą odpowiadam P.M. Z drugiej strony jest zespół, jest kontakt z tym zespołem, są też, I tutaj też zaznaczę, że ja nie miałam, ciężko mi to dokładnie określić, ale Wprost z roli Project Managera w moich doświadczeniach nie wynikało, że byłam odpowiedzialna liniowo za tych ludzi, czyli za ich rozwój, oczywiście rozwój jako PM byłam odpowiedzialna, ale za ich podwyżki, za ich wynagrodzenia. Natomiast Czasami zdarzało się, że byłam również menadżerem liniowym dla niektórych osób, natomiast ten kontakt z zespołem to jest ten drugi świat. I tutaj rozmawiamy o tym czynniku ludzkim, o emocjach. Nie można tego moim zdaniem ubrać tylko w takie cyferki I zapisać to jako jakieś określone ramy I tyle, bo to są ludzie, a ludzie też mają różne sytuacje I musimy tutaj podejść indywidualnie. Mam też indywidualizację w Galupie wysoko, więc ja mocno też na to stawiam. Także to jest ten drugi obszar. No I tak naprawdę, jakbyśmy się dobrze zastanowili, mamy jeszcze trzeci obszar, obszar organizacji, w której działamy jako PM. Często jest tak, że ludzie chcieliby robić dobrą robotę, chcieliby pracować, ale ta organizacja im rzuca kłody pod nogi. No I wtedy moim zdaniem to też jest rola PMA tutaj, żeby w jakiś sposób odfiltrowywać ten wpływ tych utrudnień, a z drugiej strony pokazywać, jak fajny sposób zespół może współpracować z tą organizacją I też transferować w jakiś sposób feedback z zespołu do organizacji, żeby to nie były dwa osobne światy, tylko żeby to była tak naprawdę jedna całość. No I teraz, które z tych światów, z tych trzech, które wymieniłam, czyli z jednej strony organizacja, z drugiej strony zespół, z trzeciej strony klient, będą zwinne, a które prowadzone klasycznie, ja bym powiedziała, że w każdym z nich będzie pewnie mix, bo zarówno u ludzi pewnie będzie mocno zwinnie, ale te osoby też coś was kosztują w tym waszym zespole, mają jakieś stawki, więc też będzie trochę tam to wchodzić. Klient, chcielibyśmy być, jesteśmy bardzo zwinni, mamy takie podejście bardzo empiryczne do wprowadzenia zmian I różnych takich rzeczy, ale też mamy jakieś procesy tej współpracy, więc taki proces też będzie pewnie bardziej klasyczny. No I podobnie będzie z organizacją, szczególnie jeżeli mówimy też o współpracy z PMO, być może, I tutaj to też zależy jak jest w danej firmie, czy pracujemy w software house, czy może w jakiejś większej organizacji, czasami jest nawet wypracowany jakiś określony model pracy jako Project Manager, czasami jest jakiś framework wewnętrzny, którego należy przestrzegać, który też chcemy realizować. Ja w moich doświadczeniach też często raportowałam do różnego rodzaju market unitów, czyli jakichś przedstawicieli sprzedaży, salesów odpowiedzialnych za za całego klienta, ale od strony sprzedażowej. To wszystko będzie zależało, gdzie się znajdziemy, ale na pewno będą jakieś raporty. Chcielibyśmy, żeby to były raporty, które mają sens. Bo czasami są to raporty, które tego sensu nie mają, a musimy mimo wszystko je robić.
Basia: Si, dokładnie. Wszystko co robimy powinno mieć sens I tego sobie życzymy. Ja się Marta zahaczę o to co powiedziałaś właśnie, że łączyłaś rolę PMa I Scrum Mastera. Trochę odejdę od samego łączenia, bo chciałabym się dowiedzieć co myślisz o tym co za chwilę przedstawię. Miałam taką sytuację kiedyś w firmie, że w zasadzie właśnie Project Management I tam te wszystkie budżety, planowanie I tak dalej, koordynacja bym tak powiedziała, była na poziomie strategicznym. Czyli to był taki poziom, na którym Project Manager był przedstawicielem projektu, całego tego procesu, do na przykład właśnie komitetu sterującego, czy zarządu, czy interesaruszy, którzy byli zaangażowani, w cudzysłowie sponsorowali to, co się dzieje w taki czy inny sposób. Natomiast na poziomie wykonawczym był właśnie zespół Scrumowy I był też Scram Master. Czyli w zasadzie mieliśmy Project Managera w osobie A I Scrum Mastera w osobie B. I te osoby ze sobą współpracowały. Trochę mi się to składa w to, co powiedziałaś, że mamy te różne światy. Moim zdaniem w tym setupie bardzo fajnie to funkcjonowało, bo Scrum Master pokrywał jeden świat I to był też poziom wykonawczy, a Project manager był obecny w życiu tego zespołu, ale właśnie w innej roli, czyli przedstawiał ten drugi świat klientów, ten bardziej wysokopoziomowy, strategiczny. Co myślisz o czymś takim? Czy takie połączenie według ciebie to byłaby jakaś recepta na tego typu duże projekty, przedsięwzięcia I pracę w tym wszystkim zwinną?
Marta Stopyra: Tak, myślę, że jak najbardziej wtedy działałoby to dużo lepiej. W zasadzie, wiecie, ja tak naprawdę robiłam te dwie role, tak, więc jakoś to funkcjonowało, natomiast ciężko w moim przekonaniu było je połączyć tak osobiście w jednej osobie. Także, tak jak Basia mówi, że jeżeli byśmy je rozdzieli, myślę, że to by miałoby też większy sens, bo ten Scrum Master byłby bardziej umocowany przez zespolę I on też byłby w stanie zbudować większe zaufanie, też relacje takie na poziomie właśnie Scrum Master Zespół. Oczywiście, że ja dalej wierzę w to, że pomiędzy moimi zespołami to zaufanie zawsze było, chyba że ktoś mnie wyprowadzi z błędu, to też śmiało przychodźcie z tą informacją, ja się zawsze chętnie dowiaduję takich feedbacków. Natomiast wiadomo, jest to trochę inaczej, w momencie kiedy mamy tę rolę project managera, jeszcze być może decydujemy jako manager liniowy o podwyżce danej osoby I jeszcze jesteśmy Scrum Masterem, tak? To jest takie combo, które, no, ja bym jednak wolała czegoś takiego unikać.
Patrycja: Super, dzięki, że się tym podzieliłaś. Zobaczymy, czy ktoś Cię wyprowadzi z błędu, to na pewno nie będziemy my. Ja bym nawiązała troszeczkę do tego, co wcześniej mówiłaś. Mówiłaś o tym, że z jednej strony zajmowałaś się budżetem, bo przecież ktoś za te projekty musi płacić, a z drugiej strony są też takie rzeczy jak deadline’y. I tutaj zastanawiam się właśnie jak Ty to łączysz, jakby negocjacje tych budżetów plus to, że w takim zwinnym środowisku agile’owym gdzieś jest utarte coś takiego, że deadline’y nie są sztywne. Jak to wygląda z Twojego praktycznego doświadczenia?
Marta Stopyra: Dzięki Patrycja za to pytanie, bo tak naprawdę mam wrażenie, że otwieramy taką puszkę pandory, bo macie takie wrażenie, że jak chodzimy na jakieś szkolenia, chodziłyśmy, w zasadzie Wasze szkolenie jest inne też z tymi praktycznymi przykładami, ale często są takie szkolenia pudełkowe, gdzie po prostu idziemy, mamy samą teorię, wszystko na papierze, pięknie wygląda, no I później nagle zaczyna się życie I okazuje się, że to wcale nie jest takie proste, bo nasi słuchacze, wasi słuchacze mogliby odnieść wrażenie, że da się to tutaj wszystko połączyć, no ale właśnie teraz wam powiem, że to nie jest takie proste, bo tak klient I tutaj musimy go zrozumieć w pełni, on chce od nas jakiegoś zobowiązania. Wiadomo, że też to zwinne podejście sprawdza się lepiej w momencie, kiedy nie mamy jeszcze pewności co do dokładnego kształtu, zresztą praktycznie bardzo rzadko zdarza się tak, że my dosłownie jesteśmy pewni wszystkich wymagań I jeszcze 1 się nie zmienią po drodze, to jest bardzo rzadka sytuacja, także on od nas też oczekuje pewnych deklaracji, a z drugiej strony chcemy właśnie podchodzić do wszystkiego zwinnie. Ja zawsze staram się pracować również nad mindsetem klienta. Spotkałam się bardzo często z tym, że klienci mieli doświadczenia z pracy w klasycznych projektach, po czym nagle gdzieś przeczytali, dowiedzieli się o Agile, o Scrumie I stwierdzili, że oni koniecznie chcą być Scrumowi, Agilowi, bo wtedy nie będą musieli się też za bardzo deklarować co do wymagań. No bo przecież jesteśmy z winni, więc zawsze mogę zmienić zdanie. A z drugiej strony, oczywiście będą wymagać, żeby w danym budżecie dostarczyć im jakąś aplikację. I słuchajcie, ja zawsze pierwsze co robię, to rozmawiam z nimi, że Agile Scrum to nie jest chaos. To nie może być tak, że po prostu nie będziemy w stanie w żadnym punkcie trwania projektu podjąć jakiejś decyzji wiążącej, no bo przecież na podstawie jakichś tam wymagań takich podstawowych nawet, później wyznaczamy wymagania też, chociażby NFR-y, wymagania niefunkcjonalne, chociażby jakieś rozwiązania techniczne są wybierane jednak, bo wiemy, że idziemy bardziej w jednym kierunku, a nie w innym. Także tutaj podam Wam też taki przykład, pracowałam kiedyś dla branży biotechnologicznej, realizowaliśmy taki projekt, który polegał na dostarczaniu software’u do urządzenia medycznego. I ta firma, prawdopodobnie ja też wtedy nie miałam aż tyle doświadczenia, więc to też trochę inaczej wyglądało, nie miałam też odwagi zawetować tego wszystkiego w odpowiednim momencie, bardzo chciała być zwinna, bardzo chciała być agile. I zgodziliśmy się na to, żeby rzeczywiście tak pracować. No I oni właśnie mieli takie przekonanie, że w takim razie skoro są zwinni, to oni nie muszą w ogóle za bardzo podejmować żadnych decyzji, przez co robiliśmy wiele takich, mieliśmy sytuacje, gdzie trzeba było coś przypisać, bo nagle się okazało, że pojawiało się jakieś wymaganie, które jest na tyle ważnym constraintem, że zmienia też rozwiązanie techniczne w innym miejscu. A po drugie, najciekawsza sprawa to była w ogóle jak doszliśmy do pierwszego release, bo nagle ci wszyscy stakeholderzy, a było ich bodajże dziesięciu albo nawet kilkunastu, co też było trudnością, żeby zgodzić się w takim gremium co do wymagań, chcieli wszystkie funkcjonalności, o których z nami rozmawiali, wrzucić do tego pierwszego releasu. Ja tak naprawdę nie rozumiałam, dlaczego to tak jest. Dlaczego w ogóle oni chcą być zwinni, a z drugiej strony co, wszystko naraz, nie ma żadnej iteracyjności w tym wszystkim. No I w końcu odkryłam dlaczego tak jest, okazało się, że takie urządzenie I też software medyczne, żeby zostać dopuszczone na rynek, potrzebuje około 9 miesięcy procesu akredytacyjnego. Więc oni byli święcie przekonani, że w momencie kiedy oni nie wrzucą tego wszystkiego teraz, to już w ogóle będą musieli czekać na swoją funkcjonalność 2 lata. No I W tym momencie, dla mnie jest oczywiste, że to podejście z winy nie było dobre w tym przypadku, natomiast życzyłabym sobie tej odwagi wtedy, żeby rzeczywiście jako początkujący PM I Scrum Master podnieść rękę I powiedzieć, że coś jest nie tak. Szczególnie, to też może być dodatkowy wniosek z mojej strony, ja pracowałam wtedy też u boku doświadczonego seniora, on tego nie widział, co ja dostrzegałam, czułam wewnętrznie, ale bałam się tak naprawdę w ogóle cokolwiek zrobić, powiedzieć. Jak w końcu się odważyłam, to już było dosyć późno. Także to też taki wniosek z tego doświadczenia.
Basia: Bardzo ciekawe to, co mówisz. I tak pomyślałam sobie, że chyba trzeba powiedzieć na głos, że w zwinnym podejściu, niezależnie od tego w jakim frameworku pracujemy, planowanie jest też ważne, że nie powinniśmy na głęboką wodę skakać I tam powiedzmy Scrum Master nie powinien z tarczą, mieczykiem lecieć na wojnę z Project Managerem w tym kontekście. Więc myślę, że to świetnie pokazało, co nam opowiedziałaś, że gdyby to było zaplanowane, to zupełnie byłaby inna sytuacja. I ja właśnie widzę tak też rolę projekt managera w tych dużych projektach czy organizacjach, żeby właśnie trochę też reprezentował biznes, bo często to właśnie jest bardzo duże gremium itd. A taki projekt manager jest w stanie to poukładać I razem właśnie we współpracy z Scrum Masterem czy z całym zespołem są w stanie też jakiś taki plan czy nawet taką road mapę zaplanować w sposób sensowny I zgodny z wymaganiami. Bo też myślę sobie, że jeśli Project Manager pojawia się w takim projekcie, to to jest jednak coś większego niż, I też może być może ad hocowego, rozwojowego do produktu, o tak może to jest lepsze, niż taka praca na co dzień nad produktem, więc to są inne kategorie działania.
Marta Stopyra: Jeżeli mogę skomentuję jeszcze tutaj, bo w zasadzie może warto by było też powiedzieć, że wtedy takie planowanie nie wygląda dokładnie tak jak planowanie klasyczne, że wszystko się zgadza, jeżeli chodzi o dni na przykład robocze osób, ale na przykład możemy podejść do tego w formie koszulek, gdzie tak mniej więcej już jesteśmy w stanie oszacować daną funkcjonalność I wtedy dla Project Managera jest to pomocne, no bo już mamy jakiś tam mniej więcej plan, że to wszystko nam się zmieści, a z drugiej strony jesteśmy też dosyć elastyczni w np. Wymienianiu tych funkcjonalności albo być może jakoś też porównywaniu ich tak mniej więcej, bez takiego zakotwiczenia, że to było 20 mendejsów I to musi być rzeczywiście tyle. Także to też myślę, żeby było tutaj istotne. I jeszcze wrzucę takie drugie rzecz, bo powiedziałyście o tym poziomie strategicznym I o roli Project Managera. To też moim zdaniem będzie się zmieniać, ponieważ w wielu organizacjach obecnie obserwuje coś takiego jak wprowadzenie podejścia product-led growth, gdzie właśnie produktowców zaprasza się do stołu właśnie na tym szczeblu już strategicznym, żeby właśnie te decyzje nie były podejmowane właśnie odnośnie rozwoju firmy, odnośnie rozwoju produktów bez ich udziału. Bo często tak było, że Project Manager sobie podejmował jakąś decyzję, a Product Owner albo o Product Manager, czy w ogóle te osoby, które rozwijają produkt, to one miały sobie rozwijać ten produkt, ale przecież to wszystko koniec końców musi się jakoś łączyć, jakoś finalnie się spinać. I właśnie ten trend też obserwuję, to chciałam jeszcze tutaj dodać.
Basia: Dzięki bardzo. Myślę, że to nas bardzo cieszy, że tutaj też to widzisz, bo jednak podejście produktowe jest nam bliższe serca, ale też wiadomo, podejście produktowe częściej będzie tym, czego firmy potrzebują, choćby nawet tego nie wiedzą, bo rozwijają przecież te produkty, to nie jest tylko wdrożenie projektu I koniec. Ten produkt później żyje I zostaje. Tak powolutku już konkludując, myślę sobie, że z tego też co powiedziałaś, można by wywnioskować, że łączenie roli APM-a I Scrum Mastera, a jednocześnie klasycznego podejścia do zarządzania projektami ze zwiętym podejściem, wcale nie jest takie łatwe, wcale nie jest też takie prostolinijne. Można by nawet ująć to w naszym ulubionym stwierdzeniu, to zależy, to zależy od tego jak się tam nam wszystko pod spodem w organizacji układa, jak to wygląda, ale też jest możliwe I wręcz nawet pożądane, w wielu przypadkach da nam to ogromne benefity, czy to rozdzielenie właśnie PM-a od Scrum Mastera pozwoli na łatwiejsze zarządzanie obszarami, które wymieniłaś, będą to lepsze efekty. Czy zgodzisz się właśnie z takim stwierdzeniem?
Marta Stopyra: Tak, Tak jak powiedziałam wcześniej, myślę, że tak. Natomiast dodałabym do tego też to, o czym rozmawiałyśmy w którymś z poprzednich razów, że bardzo istotne jest też to, żeby mieć otwarty umysł I niekoniecznie trzymać się takiej roli, że jak jestem Scrum Masterem to muszę robić tylko Scruma, a jak jestem PM-em to w zasadzie tylko konkretną metodykę zarządzania projektami będę realizować. Czyli Scrum Master to dobrze by było, żeby był otwarty na jakieś inne techniki, czy zwinnościowe, czy w ogóle obserwacje tego, co jest potrzebne pod względem zespołowi, właśnie pod względem zwinności, no I podobnie PM. Bo myślę, że jeżeli byśmy tutaj Basia powiedziały, że OK, jest Scrum Master, a on będzie tylko w Scrumie pracować, a PM będzie tylko I wyłącznie realizować jeden określony framework zarządzania projektami, to będzie to ciężka współpraca, bo jednak wymaga to dużej adaptacyjności, tak jak w ogóle czasy, w których obecnie nam przychodzi działać. No i ważna jest właśnie ta elastyczność.
Patrycja: Elastyczność myślę, że ważna jest niezależnie od tego jaką tutaj rolę czy odpowiedzialność pełnimy. Ale tak jeszcze też na zakończenie trochę pod włos. Co jest dla ciebie najtrudniejsze w byciu dobrym PM-em?
Marta Stopyra: O, to jest dobre pytanie. Dzięki też za to Patrycja. Co jest dla mnie najtrudniejsze? Wiecie co, w sumie powiem dwie rzeczy. Jedna rzecz jest związana z tym, że jako PM działasz zawsze, chyba że prowadzisz swoją firmę, ale często działasz z ramienia organizacji określonej firmy software house’u, który też ma określone procesy I zasady. Będą sytuacje, I tu nie oszukujmy się, że takich rzeczy nie będzie, gdzie wewnętrznie nie będziesz się zgadzała z tym, że tak należałoby postąpić, natomiast pewne ustalenia będą takie I też twoją rolą jest w profesjonalny sposób przeprowadzić daną zmianę czy dany aspekt. Więc to zawsze było dla mnie trudne, gdzie wewnętrznie może nie jesteś w tym zgodny, autentyczność jest dla mnie bardzo ważna w pracy, ale musisz pewne rzeczy też zrobić, czasami nie możesz sobie pozwolić na całkowitą szczerość, bo wiadomo, że są też rzeczy, które są w jakiś sposób poufne, więc to jest na pewno coś, co jest trudne. Czasami trudne też jest, to znaczy na pewno, nawet nie czasami, ale zawsze, ten taki feedback, tutaj nie wiem jakiego słowa użyć, bo na pewno nie negatywny, nie korygujący, feedback, który jest rozwojowy dla danej osoby, ma jej pomóc się rozwinąć, ale nie jest przyjmowany, bo ta osoba nie docenia tego, że poświęciliśmy czas, żeby zastanowić się nad jej przypadkiem I jej podpowiedzieć, co mogłaby robić lepiej. To jest też trudne dla project managera, jeżeli ta osoba tego nie docenia, pojawiają się trudne emocje. I na pewno również to, I tutaj wykorzystam jeszcze tą ostatnią chwilę, żeby o tym powiedzieć, żeby mieć odwagę brać odpowiedzialność za całość. To znaczy, często spotykam się na mentoringu z taką sytuacją, że ktoś przychodzi I mówi, Marta, Ja w zasadzie mógłbym pracować bardzo dobrze, ale 10 mój szef to on w ogóle nie ogarnia I to on mi rzuca same kłody pod nogi I to przez niego to wszystko nie działa. Ja zawsze mówię, zresztą jest bardzo fajna książka, z którą polecam, jak ekstremalne przywództwo, techniki Navy SEALs, gdzie też w doskonały sposób jest to pokazane, że bierzesz odpowiedzialność za całość, czyli bierzesz odpowiedzialność za swój zespół, za swoje zachowanie, swoje emocje I za zachowanie swojego szefa. Czyli jeżeli twój szef nie performuje, to to jest twoja wina, wiem, że to brzmi brutalnie, ale uważam, że w większości przypadków tak jest, bo ty nie zrobiłeś wszystkiego, żeby mu pomóc lepiej performować. I takie używanie tych stwierdzeń, które zabierają nam sprawczość, że to przez niego, przez nią I ja nic nie mogę zrobić, uważam za niewłaściwe, bo w ten sposób zabieramy sobie pole manewru, pole wpływu. W zasadzie jak ja stwierdzę, że to jest wszystko wina mojej szefowej czy szefa, albo systemu, albo organizacji, czasami jest, owszem, Zgadza się, ale w większości przypadków jednak da się coś zrobić. Jeżeli tak stwierdzę, to już w zasadzie nic nie jestem w stanie zmienić.
Patrycja: Trzeba to zrozumieć, jaka jest wizja I cel tej zmiany, którą dziś jesteśmy odgórnie proszeni. Mi tutaj serduszko mocno zrezygnowało, bo Extreme Ownership, Jacko to jedna z moich ulubionych książek o leadership. Ale już tak lądując, bardzo dziękujemy Ci Marta za tę całą rozmowę I że nakreśliłaś właśnie jak ta Karola PM może się kształtować w zależności od tego w jakim środowisku pracujemy, co może być najtrudniejsze, jak sobie radzić z budżetami I z deadline’ami, jak to wszystko może wyglądać. Ale tak na koniec jeszcze dając Ci czas na taką autoreklamę, gdzie Cię można znaleźć w sieci, może jakbyś powiedziała jeszcze dwa zdania, więcej na ten temat.
Marta Stopyra: Ok, więc ja zapraszam Was na mojego bloga digitallyher.pl. Tam znajdziecie dużo ciekawych materiałów. Oprócz tego działam też prowadząc podcast Product Space, który też znajdziecie na Spotify, m.in. No I robimy też wiele różnych szkoleń. To są, tak jak powiedziały tutaj już wcześniej dziewczyny, szkolenia dla osób nietechnicznych, ale też szkolenia z leadershipów IT, szkolenia z zarządzania produktem. I ostatnio też bardzo mocno oddaje się transformacji cyfrowej w połączeniu właśnie ze sztuczną inteligencją. Zachęcam Was do zapisania się na najnowszy newsletter, gdzie dzielę się właśnie z postrzeżeniami na ten temat. Uważam, że każdy kto jest osobą zwinną, nie wiem czy jest jakieś polskie słowo na ludzi agilnych, może w ten sposób powiem, powinien też się zainteresować tymi zmianami, bo to wpłynie na nas, ale dobrze, żebyśmy też wzięli tutaj właśnie ten ownership I wykorzystali te nowe możliwości do tego, żeby pracować jeszcze lepiej. Także do tego też zachęcam.
Basia: My również zachęcamy, a przede wszystkim do tego, by odwiedzić stronę digitallyher.pl, bo treści są naprawdę inspirujące. Nawet jeśli jesteście osobami, które coś tam o IT wiedzą to na 100% wyciągniecie coś dla siebie. Marta ma świetne flow więc jeśli lubicie nasze podcasty to także zapraszamy do podcastu Marty Product Space, który na pewno porusza tematy bardziej produktowe. Myślę, że to fajne uzupełnienie też naszej rozmowy, jak sobie gdzieś tam zawędrujecie właśnie. Tymczasem Marta, bardzo Ci dziękujemy za odczarowanie trochę roli Project Managera Scrum Mastera I łączenie klasycznego zarządzania projektami ze zwinnością. A gdyby ktoś z naszych słuchaczy był zainteresowany pogłębieniem tematu lub mentoringiem, to Marta będzie najlepszą osobą, żeby przeprowadzić przez ten proces. Dzięki Marta raz jeszcze I do usłyszenia. Dziękuję bardzo. Do usłyszenia. Hej, hej.