Kim jest project manager w zespole IT

Transkrypcja

Dziś moim gościem jest Paulina Kuc. Paulina opowie nam o tym, kim jest Project Manager, jaką ma rolę w zespole IT i jak się takim Project Managerem zostaje. Paulino, dziękuję, że przyjęłaś moje zaproszenie na rozmowę. Proszę, powiedz nam coś więcej o sobie i co łączy Cię z branżą IT.

Jasne. Moja przygoda z IT rozpoczęła się w 2005 roku od infolinii technicznej Neostrady. Przez pierwszy rok rozwijałam swoje umiejętności jako konsultant, a w kolejnym roku byłam trenerem, czerpiąc pasję i energię z tego, że miałam okazję uczyć ludzi czegoś, co właściwie chcą robić.

Gdzieś na tamtym etapie mojej kariery zaczęłam szukać nowych wyzwań. Otrzymałam propozycję pracy jako Key Account Manager, jednak z uwagi na charakter sprzedażowy tego stanowiska po około roku zaczęłam rozglądać się za innymi rozwiązaniami. Wtedy pojawiła się propozycja objęcia roli młodszej kierowniczki projektu, którą pełniłam przez 5 lat. Z tą rolą jestem bardzo mocno związana do dnia dzisiejszego.

Ostatnie 5 lat mojego życia to jest głównie Project Management, zarządzanie produktem, wykorzystanie metodyk Agile’owych, Scrumowych i ogólnie zwinność, ale nie ograniczam się w tym momencie tylko do tego, ten zakres jest trochę większy.

Na pewnym etapie mojej kariery podjęłam decyzję o profesjonalizacji w zakresie bycia PM-em. Rozpoczęłam także edukację, ukończyłam studia podyplomowe z zarządzania projektami, zrobiłam też certyfikaty, jedne z trudniejszych jakie są w tym zawodzie, czyli PMP, PMI-ACP, oraz pomniejsze Agile’owe.

No dobrze, to chyba na początku trzeba odpowiedzieć na pytanie, kim jest Project Manager i czym zajmuje się na co dzień. Jak blisko jest programistów?

To jest bardzo dobre pytanie i też złożone, bo z jednej strony wydaje się, że rola PM-a wszędzie będzie taka sama. Dzięki mojemu 15-letniemu doświadczeniu wiem, że każdy projekt jest inny. W każdym zespole od PM-a wymaga się czegoś innego. Gdzieś jakieś podstawy są wspólne, natomiast on musi być trochę jak kameleon i dostosować się do tego, co się dzieje.

Tak że kim jest ten Project Manager? To osoba, która najprościej mówiąc, jest odpowiedzialna za projekt. Czym się zajmuje? Tym, żeby ten projekt dojechał na czas, w określonym budżecie, z ustalonym zakresem i zapewnił klientowi podstawową jakość, jakiej oczekuje.

To może bym się tylko tak wtrącił, bo wspomniałaś o tym budżecie, o czasie. To od razu sobie pomyślałem, czy jest to możliwe, żeby te dwie rzeczy faktycznie udało się utrzymać w ryzach. 

Do tego Project Manager powinien dążyć. Czy jest to możliwe? To zawsze zależy od projektu i od tego, jak dobrze zaczniemy. Im lepiej zaczniemy, im lepiej zrozumiemy zakres potrzeb klienta, tym bardziej jest to możliwe.

W związku z tym, że świat się zmienia, jest coraz większe zapotrzebowanie i zrozumienie tego, że zwinność jest również potrzebna w projektach. Dzięki niej dostarczamy produkty, które mają wartość. To w istocie jest bardziej sensowne niż dostarczenie na czas rozwiązania, którego klient finalnie nie wykorzysta.

No dobrze, to wróćmy sobie do tematu Project Managera, kim jest i czym się zajmuje na co dzień. 

Nawiążę tutaj do mojego wcześniejszego doświadczenia. Można być takim Project Managerem wewnętrznym, który zarządza dostawcą jakiegoś rozwiązania, najczęściej to są rozwiązania SaaS-owe. Można też być po drugiej stronie i być odpowiedzialnym właśnie za dostarczenie tego rozwiązania. 

Odpowiadając też na to Twoje pytanie, jak blisko tych developerów się pracuje. Kiedy jest się na zewnątrz i buduje się to rozwiązanie SaaS-owe, to ta współpraca to jest właściwie codzienność PM-a, żeby kontrolować swój zespół i żeby dowiózł to, co właściwie było określone w zakresie i spełniło wymagania. 

Natomiast gdy on jest z zewnątrz, to zdarzają się konsultacje, rozmowy z developerami, bo na pewnym etapie niektóre rzeczy trzeba lepiej zrozumieć i jest to konieczne. Wtedy częściej zespół projektowy składa się z takich ludzi jak analityk biznesowy, sponsor, są tu tzw. SME, czyli Subject Matter Experts, którzy dostarczają wiedzę umożliwiającą stworzenie dobrego jakościowo produktu.

Jak już wywołałaś temat analityka IT, może mogłabyś powiedzieć nam, jaka jest różnica między PM-em a analitykiem? 

Tutaj nawiążę do projektów kaskadowych, które są takimi klasycznymi projektami. W takich projektach biznes analityk jest prawą ręką PM-a. Jest osobą, która zgodnie ze strukturą, będzie finalnie raportowała do PM-a i wykonywała pracę dla tej osoby. 

Czym się różnią właściwie te dwie role? BA ma bardzo dużą wiedzę odnośnie zakresu, nie powinien on mieć przed nim żadnych tajemnic. Taka sytuacja nie musi dotyczyć PM-a, bo on skupia się na trójkącie projektowym, czyli na dowiezieniu projektu na czas, w budżecie, w zakresie i z określonym poziomem jakości, a BA ma w tym pomóc. Sam PM nie musi znać tego zakresu co do każdego szczegółu.

OK, czy chcesz jeszcze nam coś więcej powiedzieć na temat dnia codziennego Project Managera? 

Odniosłam się w sumie do takich projektów kaskadowych, a mamy jeszcze tą zwinność, która w tym momencie bardzo mocno wchodzi w rzeczywistość. Można byłoby przeskoczyć na chwilę do tej codzienności, gdzie wykorzystujemy na przykład Scruma, a w Scrumie nie ma takiej roli jak PM.

Natomiast tutaj pojawia się ten sens: w jaki sposób zbudować ten produkt, kto będzie to kontrolować? Osoby, które są takie stricte przypisane do zespołu Scrumowego – Product Owner, Scrum Master, zespół developerski, w tej trójce często trudno o taką jednostkę, która podniesie rękę i powie: jak też chcę być odpowiedzialna za pewne rzeczy. 

Odpowiedzialność ta powinna obejmować cały zespół. Zauważam, że zespoły stale się rozwijają, aby w końcu przejąć tę odpowiedzialność na siebie, a zwłaszcza przy budowie produktu, często do zespołów Scrumowych trafia Project Manager. I to też jest wtedy codzienność – organizacja wszystkich eventów Scrumowych, kontrola zespołu poprzez budowę rozwiązania iteracyjnie i działania w sprintach. 

Jeszcze tutaj dodałabym jedno słowo, bo faktycznie PM nie występuje w Scrumie, aczkolwiek są sposoby pracy – metodyka Agile PM, która pozwala połączyć model kaskadowy i model zwinny. Ten czas developmentu jest realizowany iteracyjnie w sprintach, dzięki temu właśnie Project Manager ma szansę na koniec dowieźć lepsze rozwiązanie.

OK, to w takim razie mamy wprowadzenie odnośnie do tego, kim jest i co robi Project Manager, ale czy musi on programować? Jakie umiejętności techniczne i miękkie są najważniejsze w tym zawodzie? 

Project Manager nie musi programować, to w żaden sposób nie jest jego zakres obowiązków. Trzeba głośno zacząć mówić, czym są te umiejętności techniczne PM-a, bo to nie jest wiedza techniczna, ale to, jak zbudować struktury projektu. Trzeba wiedzieć, co robimy na początku, co robimy w środku, co robimy po projekcie, jakie aktywności znajdą się na poszczególnych etapach projektu. Dobry PM z wiedzą techniczną, jak to zbudować, buduje fundamenty projektu. 

Zauważyłam, że bardzo często jest potrzeba po stronie zespołu developerskiego, żeby zrozumienie tej wiedzy technicznej po stronie PM-a było na bardzo wysokim poziomie. Natomiast trzeba to na pewno rozdzielić i powiedzieć sobie wprost, że PM, który ma wiedzę techniczną, jest bardziej wartościowy dla zespołu. Wtedy ta komunikacja po prostu jest łatwiejsza, ale sama wiedza techniczna PM-a to jest innego rodzaju umiejętność.

A jak byś mogła powiedzieć z perspektywy tej drugiej strony, bo mówisz, że te aspekty techniczne nie są tak ważne dla PM-a, to co zyskuje jak taki projekt, który ma właśnie PM-a? 

Osobę odpowiedzialną i to jest klucz właściwie w tym dowożeniu projektów, produktów. Weźmy sobie zespół developerów, którzy mają coś dostarczyć, to oni powiedzą: tak dostarczymy, wiemy. Natomiast tutaj trzeba też nadać temu pewne ramy: w jaki sposób to zrobimy, kiedy będziemy na przykład budowali, do kiedy będziemy zbierali wymagania, kiedy zaczną się testy, kiedy planujemy to oddać?

Gdy tego nie ma, znam takie przypadki, że projekt toczy się po prostu w nieskończoność, bo nie ma tam osoby, która mówi stop. Właśnie tę rolę pełni Project Manager, po to nadaje właśnie te ramy, po to mówi: do tego dnia zbieramy wymagania i je spisujemy.

Następnym etapem jest design tego, co w tych wymaganiach zebraliśmy. Gdy ustalamy, że to jest to, co chcieliśmy, idziemy do developmentu. Na starcie rozmawiamy z developerami, ile czasu na takie aktywności będziemy potrzebować. Dajmy na to, że zespół określa je od 3 do 6 miesięcy. I regularnie sprawdzamy, czy zespół pracuje, czy faktycznie ten progres jest i że w ciągu tych 3 do 6 miesięcy skończymy. Nie może to trwać 9 czy 12 miesięcy, a jeżeli tyle będzie trwało, to pytanie, kto wtedy za to zapłaci? 

No dobrze, to jeszcze pewnie do tego tematu wrócimy. Czas powiedzieć, jak zostaje się Project Managerem. Jakie są drogi do tego stanowiska? 

No to dróg powiedziałabym, że jest tyle, ile osób, które marzą o tym bądź dążą do tego, żeby zostać takim Project Managerem. Ja zostałam PM-em, pracując w sprzedaży. Znam osoby, które były w zespołach developerskich, technicznych i zdecydowały się tę swoją karierę zmienić. 

W tej chwili jesteśmy na etapie takim, że rynek pracy poza IT zorientował się, że fajnie byłoby w tym IT być, i są osoby również spoza branży, które chcą się przebranżowić i też szukają swoich sposobów. Także historia każdego z nas będzie inna. 

Natomiast jeśli miałabym powiedzieć o takich kluczowych aspektach, jak się zostaje tym PM-em, powiedziałabym, że tutaj chodzi o konsekwentne działania: zdobywanie umiejętności potrzebnych w roli PM-a, zdobywanie potrzebnej wiedzy. Mówimy tutaj o edukacji, certyfikatach, po prostu o uczestnictwie w różnego rodzaju eventach, gdzie mamy szansę obcować z innymi PM-ami, z innymi osobami, które zajmują się projektami i zdobywać od nich wiedzę, która na pewno też nam na pewnym etapie pomoże.

To może zapytam przewrotnie: jaka jest najkrótsza droga do zostania PM-em? 

W sumie bardzo dobre pytanie, tutaj odsyłam do swojego Instagrama, gdzie całkiem niedawno przygotowałam 10 postów: jak w 4 lata od zera dojść do poziomu seniora Project Managera. 

Zostanie PM-em jest również projektem, musimy pomyśleć, jaki jest nasz cel. Jeżeli celem jest faktycznie zostać PM-em, to muszę sobie rozpisać plan na to, co ja zrobię, żeby mój przyszły pracodawca się mną zainteresował. Więc jeżeli dzisiaj wykonuję jakiś zakres obowiązków, mogę dorzucić sobie coś, co będzie już pracować nad tymi umiejętnościami, które są potrzebne w Project Managemencie. Mogę się zastanowić i pójść na jakiś kurs. Może to być najtańszą drogą i można wykorzystać Udemy. Można pójść na jakieś szkolenia, które są organizowane przez firmy na rynku, a trzecia opcja to samodzielnie tej wiedzy szukać. Trzeba sukcesywnie podnosić swoje kompetencje.

Przygotowałam strategię i ona jest tam krok po kroku opisana, co trzeba zrobić. To nie jest proste, natomiast tylko i wyłącznie wysiłek, który się wkłada, finalnie pozwala nam tę rolę dostać.

Zapewne podlinkujemy Instagram Pauliny, więc będzie można skorzystać, ale miałem nadzieję, że odpowiesz w taki sposób, że często PM-em można zostać, przechodząc z jednego działu albo z innego stanowiska tej samej firmy. Wydaje mi się, że to jest najkrótsza droga. Czy zgodzisz się, że to może być fajna opcja, że jeżeli ktoś myśli, żeby zostać Project Managerem, to żeby zainteresować się, jakie umiejętności są potrzebne w tej konkretnej firmie, w której się pracuje? Czy możliwe, że ta droga będzie najkrótsza?

Być może tak. Może to jest też specyfika tego, że ja w tej chwili bardzo dużo pracuję z osobami, które są z zewnątrz i tego scenariusza nie wzięłam pod uwagę. Jeżeli ktoś jest w danej firmie, widzi te otwarte oferty pracy i pojawia się taki PM, to na pewno dla tej firmy to jest duża wartość, bo jest to osoba, która już jest wewnątrz, zna firmę, widać że chce się rozwijać. 

Tylko tutaj ja bym dołożyła do tego dodatkową cegiełkę, że trzeba jeszcze włożyć wysiłek, żeby zrozumieć tak na dobrą sprawę, z czym to się wiąże. Spróbować robić sobie takie projekty, nawet jakieś swoje, mniejsze i zobaczyć, czy się w tym dobrze czuje, żeby to faktycznie miało dla nas sens.

Wróćmy jeszcze do programistów, bo chciałbym się Ciebie dopytać, czego programista może oczekiwać od Project Managera. Jakie cechy ma dobry PM? 

Tutaj wrócę do jednego z naszych pierwszych pytań, czym PM się zajmuje. To też odpowiada na pytanie, czego programista może oczekiwać. Chodzi o to, że PM jest po to, żeby nadać projektowi pewne ramy. Na tym PM ma się skupić – nie ma mocno odbiegać od tych ról – i ma dać programiście cel, kierunek i widełki czasowe, kiedy będzie mógł nad konkretnymi zadaniami pracować i mieć świadomość, kiedy ma pewne rzeczy dostarczyć i co dokładnie jest wtedy od niego oczekiwane. 

To też w jakiś sposób buduje taką harmonię, bo ludzie, którzy są w zespole, są jednocześnie przygotowani na to, co ich czeka. Jak już jesteśmy w trakcie tego projektu, to PM jest odpowiedzialny także za to, żeby pomóc, usuwać pewne utrudnienia, które się pojawią. Wyobrażam sobie, że przy budowie różnych aplikacji trzeba komuś pomóc zdobyć odpowiednie dostępy do pewnych narzędzi, więc to nie jest rola programisty. Programista ma się skupić na kodowaniu, wtedy przynosi największą wartość organizacji i to jest jego głównym zakres obowiązków. A jeżeli chodzi o takie mniejsze zadania, np. ten dostęp do czegoś czy zakup jakiegoś nowego oprogramowania, licencji, to w takie rzeczy już nie powinien wchodzić.

Przyjmijmy, że realizujemy jakiś projekt, mamy wyznaczone ramy, ale jednak widać, że ten projekt trwa już jakiś dłuższy okres czasu. Programiści widzą, że dobrze byłoby poświęcić więcej czasu na jego refaktoryzację, więc potrzebują więcej czasu, a biznes naciska na to, żeby były dodatkowe funkcjonalności.

Czy PM stara się jakoś wynegocjować czas, czy raczej stara się naciskać na programistów, żeby jednak realizowali funkcjonalność, a refaktoryzację zrobi się później? Gdzie jest taka granica, jak zazwyczaj PM reaguje i czy w ogóle to jest jego działka? 

To jest kwestia tego, nad czym pracujemy, czy to jest rozwój produktu, czy budowa produktu. Powiedzmy, że trwa to już x czasu i wtedy faktycznie trzeba popracować nad tym kodem i sprawdzić, na jakim poziomie jakości on jest. 

To też jest właśnie taki punkt, w którym developer może przyjść do PM-a i powiedzieć: słuchaj, widzimy, że potrzebujemy czasu na tę refaktoryzację. Dobry PM zapyta w takim razie o złożoność tego, jak zespół developerski to rozumie, w jaki sposób chce to przeprowadzić, ile czasu na to potrzebuje, jaką wartość będzie miał z tego biznes. Wyciąga z zespołu developerskiego te informacje, spisuje je i podnosi ten temat z biznesem, z klientem, informując, dlaczego takie działania będą miały wartość. 

I zazwyczaj to nie jest tak, że takie rzeczy są akceptowane z dnia na dzień, bo jeżeli się umówiliśmy na jakiś zakres wcześniej, to ten zakres ma być dowieziony w konkretnym czasie i o to walczymy. Natomiast gdy jest potrzeba zrobić coś więcej, no to są kolejne miesiące pracy, kolejne kwartały, gdzie możemy taki punkt uwzględnić i po prostu go dodać.

Myślę, że wtedy biznes, który pozna wartość takich aktywności, inaczej podejdzie do tematu, niż na zasadzie: a słuchajcie, potrzebujemy jeszcze teraz 3 tygodnie, żeby przeprowadzić refaktoryzację i czy wy jesteście z tym OK? Jeżeli biznes czeka na coś innego, no to oczywiście powie, że nie, bo na coś innego się umawialiśmy, ale jak sobie to przygotujemy, zaplanujemy, to w odpowiednim czasie możemy to zrobić.

To może jeszcze raz zapytam o ten biznes. Na przykład dajemy odpowiedź: Potrzebujemy teraz 2 tygodnie na refaktoryzację, dzięki temu zaoszczędzimy potem te 2 tygodnie w przeciągu pół roku. Ponieważ kod będzie lepiej napisany, szybciej będziemy dostarczać inne funkcjonalności. Czy taki argument przemawia do biznesu, czy raczej nie? 

Każdy biznes jest inny, prawda? Pracą PM-a jest komunikacja i to nie może być tak, że ten PM bierze od developera informacje, że jeżeli ktoś chce zrobić refaktoryzację, to trwa 2 tygodnie. I ten PM idzie do biznesu i mówi: Słuchaj, chcemy robić refaktoryzację, trwa to 2 tygodnie. Zgadzasz się? No to wtedy ten biznes może powiedzieć: Nie, no po co? W 2 tygodnie to my sobie możemy zbudować kilka innych funkcjonalności, nie róbmy tego. 

Ale jeżeli będzie tak, jak Ty powiedziałeś, że on się przygotuje, zrozumie, czym jest ta refaktoryzacja, jaką wartość to będzie miało dla biznesu; że później pewne zadania będą robione być może sprawniej, może dzięki temu wyjdziemy z jakiegoś długu technicznego; i ten produkt, nad którym zespół pracuje, ma sens, jest strategiczny, firma chce z niego korzystać przez najbliższe np. 5 lat, to wtedy powiedzą: OK. 

Może być też taki scenariusz, że np. ktoś już z biznesu wie, że za pół roku czy rok ten produkt nie będzie dalej rozwijany, bo są już negocjacje i chce się przejść na inne rozwiązanie. Wtedy może paść decyzja: nie, dziękujemy, nie robimy tego. 

A wtedy PM dostaje takie informacje, czy on dostaje tylko po prostu: nie, bo nie i tyle? 

No to zależy, jak sobie układa tę komunikację. Można zapytać o uzasadnienie, np. dlaczego nie. To wszystko zależy od tego, na jakiej stopie relacji jesteśmy, w jaki sposób rozmawiamy z tym biznesem, jeżeli my się wzajemnie lubimy… Tutaj nie ma żadnego sekretu, nie wchodzimy nawet na żadne kwestie bezpieczeństwa. Po prostu nie decyduję się na to, bo np. uważam, że dzisiaj to nie ma wartości. I to też jest komunikat, który być może na jakichś etapach jest wystarczający.

Chciałbym też zapytać, czy biznes (ale pewnie biznesu to nie interesuje), bierze pod uwagę, że jeżeli w przeciągu najbliższych 3 czy 6 miesięcy zespół developerski poprosi kilka razy o refaktoryzację i jej nie otrzyma, to straci zespół? Parę osób się wykruszy, bo po prostu już nie chce się męczyć, mówiąc mocno kolokwialnie.

I właśnie to jest kwestia tej komunikacji, gdzie PM może takich rzeczy też nie być świadomy. Powiedzmy, że nawet doszło do takiego scenariusza, że trzy osoby zrezygnowały, przyszły nowe i też zaczynają się męczyć i mówią: halo, jeżeli my tutaj czegoś nie zrobimy, to za pół roku nas też tutaj nie będzie. I teraz jest pytanie: czy ten zespół pogada o tym transparentnie, wyciągnie to? Bo tutaj widzę, że wchodzimy w taki styl Scrumowy, gdzie coś pewnie iteracyjnie sobie budujemy. To jest szansa, żeby taki smrodek wyciągnąć i powiedzieć: nam to leży na sercu, że to nie działa tak, jak byśmy chcieli, chcielibyśmy nad tym popracować. 

I właściwa osoba zrozumie to, bo jesteśmy w świecie IT, gdzie też myśli się o tym, żeby usprawniać. I tu nie chodzi tylko o usprawnianie rozwiązań, ale też naszej pracy. A jeżeli ta refaktoryzacja usprawni naszą pracę, pomoże nam działać efektywniej, to powinno być zaplanowane i dodane w pewnym momencie albo do jakiegoś sprintu, albo właśnie do jakiegoś epica, żeby finalnie gdzieś na jakimś etapie zostało to wykonane. 

Znów się troszkę podpytałem i zeszliśmy z głównej drogi. Czy chcesz coś dodać do cech dla dobrego Project Managera? 

Na pewno chciałabym podkreślić to, że ten dobry PM to jest taki kapitan statku. Ma stać przy tym sterze i tym statkiem sterować, więc jak ma być dobry, to on musi patrzeć przed siebie i patrzeć, gdzie ten statek płynie i czy gdzieś tam nie skręca. Im bardziej zacznie się angażować w inne role, tym większe prawdopodobieństwo, że ten statek zboczy i wtedy zaczną się dodatkowe trudności. 

Tak jak wspomniałaś o tym kapitanie, to zastanawiam się, czy to też tak jest, że dobry PM rezygnuje z projektu ostatni? 

Tak, PM gasi światło ostatni. Dokładnie. I to jest jego odpowiedzialność, żeby zakończyć projekt, przeanalizować, czy dokumentacja jest, czy klient jest zadowolony, czy zespół się nie wykruszył w trakcie, czy był ten team building i czy wszyscy czują się jako zwycięzcy, bo dowieźli. Czy on gdzieś w trakcie wyparuje i go po prostu nie będzie, przyjdzie ktoś inny, kto wykona za niego tę pracę. 

Także ja w większości swoich projektów faktycznie dążę do tego, żeby to światło zgasić i uważam, że taka powinna być kolejność działań. 

Rozumiem.

No dobrze, to w takim razie pytamy o kolejnych uczestników projektu. Czy PM współpracuje z Team Leaderem? A jeśli tak, to w jakim zakresie? A może czasem sam PM jest Team Leaderem jako jedna osoba? Jak to jest? 

Miałam okazję doświadczyć właściwie chyba nie wszystkich, ale wielu scenariuszy. Trzeba sobie powiedzieć, że bardzo dużo zależy od organizacji, w jakiej się znajdujemy. Zespół projektowy bardzo często jest zbudowany z osób, które są przypisane do projektu. To nie są osoby, które się zazwyczaj znają, tylko po prostu trafiają na określony czas do realizacji projektu i tam mają się odnaleźć. 

Często te osoby właśnie mają tego Team Leada nad sobą i PM w jakiś sposób jest na jednej linii z tym Team Leadem, bo jak jest jakaś sytuacja, którą trzeba omówić z przełożonym swojego wykonawcy, no to idzie się do takiej osoby i faktycznie rozwiązuje się z nią jakiś scenariusze. 

Była kiedyś taka sytuacja, że miałam testerkę, która też w pewnym momencie wyraziła się, że analityk biznesowy angażuje ją do swoich zadań, a ona chciałaby się skupić na byciu testerem. No i faktycznie była sytuacja taka, że ten analityk biznesowy nie był najlepszy i potrzebował dodatkowej pomocy, a właśnie ta testerka takie skille już miała, zdobyła je gdzieś na poprzednich projektach. Poszła do swojego bezpośredniego przełożonego z taką informacją, że ona nie chce się tam angażować. No i wtedy pojawiła się dodatkowa dyskusja właśnie między mną a tym Team Leadem, jak to rozwiązać. Moim zadaniem jest dowieźć projekt i jeżeli widzę zasoby, które mają jakąś wiedzę, to moim zadaniem jest je wykorzystać tak, żeby faktycznie ten cel osiągnąć. 

Natomiast w tym wszystkim trzeba uwzględnić zespół. Ten zespół, jeżeli dbamy o niego, jest on zaangażowany, robi to, co lubi, to, co chce, to też inaczej pracuje niż jak wtedy, gdy się wciska ludziom pewne obowiązki. Trzeba znaleźć pewien kompromis i to sobie wypracować. Więc są takie sytuacje, gdzie Team Lead się pojawia i interweniuje.

Miałam przez jakiś czas okazję być Team Leadem zespołu developerskiego. Dzisiaj uważam, że to nie był najlepszy pomysł, bo ja nigdy developerem nie byłam. I widzę, jaką wartość ma, gdy jest nim osoba, która przeszła wcześniej poszczególne szczeble kariery w tej profesji i potrafi doradzić swoim pracownikom. A ja jako PM nie byłam w stanie nic powiedzieć swojemu zespołowi, gdy pytali mnie o kod i rozwój tego, bo to nie jest moja branża. Ja w to nigdy jakoś szczególnie wejść nie chciałam. No więc miałam taką okazję być nim przez kilka miesięcy, finalnie moja współpraca z tamtą firmą się skończyła. 

To też fajnie pokazuje, że tak naprawdę nazwa stanowiska to jest jedno, ale to, co się robi, to już jest inna sprawa, więc warto na to zwrócić uwagę. Tak jak wspomniałaś, Team Lead Team Leadowi nierówny i też jego zadania są całkiem inne. Mimo że stanowiska mogą się nazywać identycznie, to każdy może robić co innego.

Tak, to trzeba zrozumieć, że każda firma ma inną strukturę, inne potrzeby, jest na innym etapie. Firmy dążą do tego, żeby się profesjonalizować i żeby ludzie byli specjalistami w swoim zakresie, ale nie zawsze jest to możliwe, no i wtedy nasz zakres obowiązków jest większy i nie zawsze ludzie potrafią się w tym odnaleźć, nie do końca im to pasuje i takie rzeczy też trzeba zaakceptować.

Wróćmy może do tematu samego rozwoju projektu. Na jakim etapie wkracza PM? Może jeszcze na etapie rozmów z klientem?

Tutaj wracamy ponownie do bardzo podstawowych kwestii, takich jak to, w jakiej firmie się znajdujemy. PM ma możliwość zaangażowania się już na wczesnym etapie, nawet podczas zbierania wymagań i na etapie sprzedaży projektu. Kiedy pracowałam w mniejszym start-upie, byłam odpowiedzialna za przygotowanie oferty, która obejmowała cały zakres oczekiwań klienta i to, co miało dla niego zostać zbudowane.

Im większa firma, im bardziej mówimy o roli takiego profesjonalnego PM-a, to odchodzi się od tego, bo zbieranie wymagań staje się zbyt czasochłonne. PM-owie na pewnym etapie mają wyższe wynagrodzenia, co sprawia, że zazwyczaj nie są zaangażowani bezpośrednio w te prace. Zamiast tego firma zatrudnia pracowników, którzy mogą to zrobić taniej, co stanowi fundament dla późniejszej roli PM-a. W większości korporacji PM-owie są angażowani głównie na etapie developmentu, gdzie wchodzimy w budowę jakiegoś rozwiązania lub tego, co jest w zakresie.

Teraz powiedz nam, jakich narzędzi na co dzień używa Project Manager. Możesz też wspomnieć, do czego służą, bo pewnie nie wszyscy wiedzą, o co chodzi. 

Każda firma to inna historia, ale najbardziej popularne narzędzia na rynku to z pewnością Jira albo Azure DevOps. Najprościej mówiąc, to narzędzia do śledzenia tasków i monitorowania postępu. PM-owie bardzo często budują też plany projektów w programach, takich jak MS Project, chociaż czasami, gdy są to prostsze harmonogramy, używają Excela, ale to jest trudniejsze i bardziej czasochłonne.

Jednym z ważnych elementów jest także zadbanie o to, aby zespół miał narzędzie do komunikacji. Obecnie jednym z najbardziej popularnych narzędzi, z którymi się spotykam, są Teamsy. Do głowy przychodzą mi jeszcze narzędzia do budowy prezentacji, jak Canva, oraz wszelkie narzędzia office’owe. Z mojego doświadczenia wynika, że SharePoint to także ważne narzędzie, gdzie znajduje się cała dokumentacja i historia projektowa. Można powiedzieć, że to jest must have i występuje w większości przypadków.

Powiedz mi jeszcze, czy korzystasz z Miro? Jestem ciekaw, czy to narzędzie jest często używane, bo Business Analytic wspomniał o tym, że je wykorzystuje.

Ja osobiście z Miro nie korzystam, ale znam PM-ów, którzy to narzędzie wykorzystywali i ono na pewno ładnie pomaga wizualizować to, co chcemy zaprezentować. Jestem tego świadoma, że Miro faktycznie jest, ale ja jeszcze potrzebuję trochę czasu, żeby zrozumieć to narzędzie. Poza tym, że je widziałam i znam jego zastosowanie, to sama z niego nie korzystam.

Rozumiem.

No dobrze, to w zasadzie już trochę wspomnieliśmy na temat roli Project Managera w rozwoju produktu, ale może w jednym miejscu byśmy to wszystko zebrali w całość. Wiadomo, że programiści dbają o jakość kodu i tworzenie kolejnych funkcjonalności, lecz jaką wartość dla produktu przynosi Project Manager? 

W budowie produktu PM jest odpowiedzialny za jakość projektu. To jest bardzo szerokie w tym momencie, bo faktycznie programista ma kod i na tym się skupia. Ten kod ma finalnie stworzyć jakieś rozwiązanie. Natomiast PM ma w swoich rękach projekt, a ten projekt to jest zespół. Pojawiają się zmiany, pojawia się kwestia komunikacji. Jak zadbać o harmonię w projekcie, żeby ta komunikacja była miła, fajna, sprawna. Żeby ludzie chcieli ze sobą pracować, a nie tylko wykonać swoje zadania i po prostu zapomnieć o projekcie. 

To jest też kwestia terminów. PM jest odpowiedzialny za dostarczanie w pewnych widełkach czasowych tego, co zadeklarował. Do tego jednym z takich wyzwań jest zarządzanie interesariuszami, zarządzanie budżetem. Tak że ten pakiet jest naprawdę bardzo szeroki, a dobry PM skupia się na tym, żeby znaleźć czas na wszystko, co do tej pory wymieniłam. Powinien zadbać o to, żeby to działało jak dobrze naoliwiona maszyna i żeby było widać ten progres w projekcie.

To może teraz trochę z innej beczki. Czy Project Manager bierze udział w rekrutacji programistów? Jeśli tak, to co u kandydata jest dla niego najważniejsze? 

Czasami bierze, czasami nie. Co firma, to inna historia. Byłam w zespołach, gdzie miałam okazję rozmawiać z nowo rekrutowanymi programistami. PM bardziej sprawdza tutaj te kompetencje miękkie, to podejście developera, tą jego proaktywność i jego zaangażowanie, jakie wniesie.

Jeżeli chodzi o kwestie techniczne, to na etapie rekrutacji zazwyczaj po prostu angażuje się też jakiegoś senior developera, który ocenia wiedzę techniczną. Natomiast PM będzie współpracował z tą osobą. Ta osoba będzie dowoziła jemu część pracy, i ta współpraca musi się układać dobrze, żeby wszystkim nam było tak na dobrą sprawę miło.

Zdarza się – i to jest też ta trudność projektu – że bardzo często Project Managerowie trafiają do zespołu, gdzie ten zespół jest narzucony z góry i z takimi ludźmi trzeba zrealizować tę inicjatywę.

No dobrze, a jeżeli byś była na takiej rekrutacji i osoba techniczna wybrałaby kogoś innego, a Ty byś widziała lepsze umiejętności miękkie w kimś innym, to do kogo należy ostateczna decyzja? 

To jest tak na dobrą sprawę kwestia brutalnej analizy. Na co kładziemy większy nacisk? Jeżeli faktycznie widać braki, powiedzmy, komunikacyjne, ale człowiek jest bardzo mocno techniczny, to też można transparentnie z nim porozmawiać. Czy on będzie chętny gdzieś to swoje nastawienie zmienić? Być może będą osoby, które powiedzą, że nie, że ich styl bycia jest po prostu najlepszy, nie interesuje ich, nie szukają też zmiany pracy na siłę. Wtedy lepiej wziąć kogoś, kto tej wiedzy ma trochę mniej, ale ma większe zaangażowanie i chce też czegoś się nauczyć. To też nie jest rozwiązanie zawsze znaleźć najlepszych specjalistów do wszystkiego, bo w pewnym momencie ci najlepsi specjaliści też się kończą i trzeba dać miejsce tym, którzy się uczą.

A jeżeli musiałabyś powiedzieć tak jednoznacznie albo może z Twojego doświadczenia, to lepiej byłoby wziąć osobę, która może być troszkę słabsza technicznie, ale umiejętności miękkie ma na wyższym poziomie, czy wręcz odwrotnie? 

Ja jestem z tych, co cenią umiejętności komunikacyjne, bo uważam, że w dzisiejszym świecie wiedzę techniczną można znaleźć. Mam takie możliwości, że mogę pójść do jakichś seniorów, wysłać tam kogoś chociażby na mentoring, po jakąś kwestię pytań i dać temu człowiekowi możliwość konsultacji. Mając takie wsparcie z tyłu i widząc, że ktoś ma pewien poziom wiedzy i jednocześnie rozwinięte umiejętności miękkie, jest gotowy na komunikację z klientem i współpracę z zespołem, to stawiam na to. 

To jest też ten moment, gdzie te kompetencje miękkie zaczynają odgrywać dużą rolę, bo co mi po takim seniorze, który ma dobrą wiedzę, ale będzie co chwilę coś tam odburkiwał, będzie niezadowolony, bo on wie najlepiej, ale właściwie nikomu nie będzie chciał pomóc. Taka współpraca na pewnym etapie zacznie być trudna. A jak zacznie być trudna, to nie będzie już efektywna i będziemy się po prostu boksować. To za bardzo nie ma to sensu.

Teraz zostańmy trochę przy tym stanowisku developerskim, przy tym programiście, który pewnie ma umiejętności miękkie, potrafi się dobrze komunikować i chce zostać PM-em. Co byś mu doradziła? 

Przede wszystkim trzeba zrozumieć, że to są dwie zupełnie inne role. Od PM-a nie oczekuje się zazwyczaj umiejętności programowania, więc trzeba wyjść z butów programisty i wejść w rolę PM-a oraz wziąć odpowiedzialność za to stanowisko. 

Wskażę też takie bolączki: czasami ktoś, kto był programistą, a teraz został PM-em, widzi, że zespół sobie z czymś nie radzi, a on ma wiedzę i mógłby temu zespołowi pomóc. Tylko że wtedy, gdy będzie się angażował w nie swoje obowiązki, odejdzie od steru, nie będzie już kapitanem. Bierze na siebie ryzyko i odpowiedzialność, że angażując się w coś, może finalnie nie osiągnąć tego, co jest jego głównym celem. 

Jednak programiści, osoby które są w zespole projektowym, mają szansę obserwować takiego PM-a, mają szansę zastanowić się, czy to jest coś, co chcieliby robić. Spotykam się bardzo często z tym, że w życiu by nie chcieli, bo chodzi o wzięcie na siebie odpowiedzialności, mierzenie się z oczekiwaniami zarządu, sponsora, kogoś, kto za to płaci, i trzeba się tłumaczyć przed takimi osobami. Jak dbamy o tę komunikację, to są fajne rozmowy, ale jeśli ktoś weźmie na siebie za dużo, to będzie stresował się każdym wydarzeniem, co będzie miało negatywny wpływ. Od programisty takich rzeczy się nie oczekuje, od PM-a już jak najbardziej, więc trzeba sobie odpowiedzieć właśnie na to pytanie: czy z takimi nowymi wyzwaniami chcę się mierzyć i czy jestem gotowy odejść od developmentu.

A czy warto zadbać o jakieś certyfikaty? Bo jednak, jeśli chodzi o programistów, raczej „papierki” nie są istotne, liczą się umiejętności. Czy w świecie PM-ów certyfikaty mają znaczenie?

Większość z nich jest bardzo łatwa do zrobienia. To jest kwestia kilku dni pracy i tak na dobrą sprawę taki certyfikat jest zrobiony. Już tyle osób spoza branży te certyfikaty zrobiło, że ma je bardzo duża liczba ludzi. Natomiast certyfikacje na pewno warto robić, bo to pokazuje, że profesjonalizujemy się nie tylko doświadczeniem, ale też naszą wiedzą i dzięki temu my też rośniemy.

Ale to, co chciałam jeszcze powiedzieć: na pewnym etapie te papierki wręcz są potrzebne. I nie powiedziałabym, że zawsze na początku, ale jeżeli jest jakaś osoba, która myśli o tym, żeby zostać PM-em, to fajnie przeanalizować, jakie są te metodyki, jakie są frameworki, wybrać sobie jeden, który jest taki najbardziej zgodny z nami i zrobić sobie ten certyfikat, zrobić sobie to szkolenie i mieć jakąś taką już troszkę łatwiejszą ścieżkę działania.

OK, to teraz zapytam Cię o zarobki. Powiedzieliśmy tyle różnych rzeczy na temat tego, co powinien robić PM, jak powinno to wszystko wyglądać i że warto robić certyfikaty. To ile można na tym wszystkim zarobić? 

No to jest też kwestia właśnie naszego wysiłku. Dzisiaj widełki dla juniora wahają się między 5 a 7 tysięcy. To jest taka kwota, którą można dostać na rękę. 

Profesjonalizowanie się – tak jak wspomniałeś: robienie certyfikatów, zdobywanie doświadczenia czy bywanie na jakichś eventach, rozbudowa swojej wiedzy – podnosi nasze umiejętności i gdzieś już taki mid po roku czy dwóch ma prawo oczekiwać wynagrodzenia na poziomie od 10 do 16 tysięcy. Tu już bardziej wchodzimy w umowy B2B, przekraczamy też wtedy progi podatkowe i zdecydowanie lepiej pomyśleć o takiej formie zatrudnienia.

A dla seniorów jeszcze całkiem niedawno dość rzadko były takie oferty z wynagrodzeniem na poziomie 25-30 tysięcy, a w tej chwili już nawet pojawiają się i do 40 tysięcy. One są pojedyncze, ale faktycznie takie oferty też już na rynku polskim można znaleźć. 

Myślisz, że firmy bardziej doceniają PM-ów, może ich brakuje i kwota wynagrodzenia ma zachęcić, czy może są jakieś inne powody takiej sytuacji? 

Mówisz o takim wysokim wynagrodzeniu, tak? 

Tak.

To jest kwestia wyzwań, z jakimi przyjdzie się człowiekowi zmierzyć, bo tutaj im wyższe wynagrodzenie, tym do większego „bagienka” się trafia. To będzie sprawdzenie się, czy potrafisz wyjść nie tylko Ty z tego bagna, ale też wyciągnąć cały zespół, a czasami być może całą firmę. Zazwyczaj takie projekty są po prostu trudne. To nie są rzeczy, które łatwo przeprowadzić, zadbać o całość. Ludzie już widzą, że mierzą się z pewnymi wyzwaniami, gdzie umiejętności nie ma, brakuje też specjalistów z konkretnej dziedziny i tutaj mam chociażby na myśli np. jakieś projekty, które dotykają o SAP-a.

SAP jest złożoną aplikacją, nie dla wszystkich jest on łatwy, trzeba rozumieć pewne zależności. Osób z takimi umiejętnościami jest bardzo mało. Gdy się chce mieć kogoś, kto taką specjalizację ma, no to wtedy to wynagrodzenie automatycznie rośnie. 

Wspomniałaś wcześniej o smrodkach, teraz mamy bagienka, to chyba czas na pytanie, co według Ciebie stanowi największe wyzwania w pracy Project Managera.

Jeszcze raz powiem, że największym wyzwaniem w roli Project Managera jest wzięcie na siebie projektu, bo każdy projekt jest inny. Nawet jeżeli by wdrażało się u kolejnego klienta podobne rozwiązanie, to napotka się inne trudności.

Tak że wracam do tego core’u, jakim jest projekt. Gdy mówimy o wyzwaniach, no to przychodzi nam zarządzać zespołem, zarządzać ludźmi, których nie znamy, którzy mają różne oczekiwania. 

Dlatego też przypomnę, że warto budować na samym początku projektu tę strukturę, żeby każdy wiedział, gdzie jest jego miejsce, do kogo raportuje. W innym wypadku każdy sobie myśli: czego ten PM ode mnie chce, przecież on nie jest moim przełożonym. A właśnie w strukturze projektu ten PM jest nad tą konkretną osobą i ma prawo oczekiwać pewnych rzeczy. I jeżeli to nie zostanie dogadane, no to będzie wyzwaniem, będzie się ciągnęło. 

Jednym z wyzwań są ryzyka. Ryzyka to jest coś, czego w dużym stopniu nie jesteśmy w stanie przewidzieć. I tutaj odniosę się do tego, co się wydarzyło w ostatnich latach na świecie i co nas dotknęło jako Polskę. Nie mam na myśli pandemii, a wojnę. Rosja przez pewien czas dostarczała jakieś rozwiązania na nasz polski rynek bądź do aplikacji, które wykorzystywaliśmy. No i nagle, gdy jest tak zwany ban, że przestajemy korzystać z produktów rosyjskich, a mamy coś dowieźć na konkretny czas i właśnie budujemy rozwiązanie, które te komponenty wykorzystuje (tworzone przez programistów rosyjskich), no to mamy po prostu problem.

To jest konkretne ryzyko, którym trzeba zarządzić, na które trzeba znaleźć rozwiązanie i z tym rozwiązaniem trzeba pójść wyżej i zaproponować „górze”, która zarządza może już nie tyle projektem, co właśnie jest odpowiedzialna za podjęcie decyzji w takich sytuacjach.

To, co powiedziałaś, jest bardzo ciekawe. Sytuacja, która jest teraz na Ukrainie powoduje, że pewnie wiele firm w ogóle nie będzie chciało współpracować np. z programistami rosyjskimi, bo historia może się powtórzyć. Ty jako Project Manager i inne osoby latami nie będą chciały współpracować z programistami rosyjskimi, więc ta decyzja może mieć właśnie taki długofalowy wpływ, z którego ja nie zdawałem sobie sprawy.

Tak, ale to już dzisiaj wiemy, prawda? Na pewne rzeczy jesteśmy w stanie już dzisiaj sobie odpowiedzieć. Czy moja firma chce współpracować, mieć jakieś kontakty na przykład z Rosją czy z Ukrainą, czy z jakimś innym krajem? Jeżeli nie, no to jestem w stanie to dzisiaj przewidzieć i powiedzieć coś na ten temat.

Natomiast ja odniosę się też do takiej historii, którą znam, gdzie PM budował produkt, który zawierał komponenty tworzone przez Rosję – część software’u była rosyjska. Mówiliśmy o kliencie, który był z branży regulowanej, podlegał bardzo dużym restrykcjom. I co w takiej sytuacji zrobić? Gdy już kończymy projekt, kończymy produkt i nagle się pojawia: my dalej nie chcemy używać komponentów rosyjskich.

Właśnie na takim etapie jest bardzo ważny analityk biznesowy, o którym mówiłeś. Trzeba taką osobę zaangażować, trzeba poszukać innych rozwiązań, zobaczyć, czy to ma sens. A być może to, z czego korzystamy, wcale nie jest „aż tak bardzo rosyjskie”, jak myślimy, bo być może coś jest jeszcze tam zarejestrowane np. w Londynie albo w jakimś innym miejscu i nie stwarza dla nas zagrożenia.

Robi się wtedy bardzo szczegółową analizę i przygotowuje się tzw. mitygację, czyli jak będziemy rozwiązywali tę obecną sytuację. Ja bym powiedziała, że to jest codzienność. Niecodziennie wybucha pandemia czy wojna, natomiast PM musi być na takie sytuacje wyczulony, bo nawet w firmie może coś się wydarzyć. Może być jakiś incydent bezpieczeństwa, który też wpłynie na to, co on buduje i nagle się okaże, że ma zasoby przypisane na jakiś czas, a jest incydent, który trwa miesiąc i tych zasobów już za miesiąc miał nie mieć, a bez nich nie skończy. No i zaczyna się rozmowa, w jaki sposób działać dalej. 

Na takie sytuacje trzeba umieć odpowiednio zareagować, trzeba też przede wszystkim zachować wtedy spokój. Jeżeli czyta to ktoś, to chce być PM-em, jest na początku tej drogi i wyobraża sobie, że to jest właśnie tylko kwestia zebrania wymagań, budowy jakiegoś rozwiązania przez zespół developerski, oddania tego na czas i koniec, to tak nie jest. Tutaj jest właśnie ta złożoność, ta niewygodna część, która jest tymi ryzykami i tym, jak się na nie zareaguje, gdy one się pojawią.

Komunikacja też potrafi być bardzo dużym wyzwaniem i to szczególnie, gdy mówimy o pracy w projektach międzynarodowych. Tutaj zaczynają wchodzić zespoły, które są z Indii, Niemiec, Szwajcarii, Stanów Zjednoczonych, Chin czy Australii. Znam osobę, która prowadziła projekt, gdzie miała właśnie interesariuszy w Australii i w Stanach Zjednoczonych. To są tak różne strefy czasowe, że jest bardzo trudno spotkać się, a jeżeli wymaga się pewnego udziału od jednych i drugich, no to trzeba wtedy szukać rozwiązań. Jeszcze oni powiedzą, że nie są zainteresowani pracą po godzinie 17. Tak zaczynają się kolejne wyzwania i PM musi szukać odpowiedzi na to, co z takim trudnym przypadkiem zrobić.

Zarządzanie budżetem często też potrafi być wyzwaniem, bo bardzo często firmy decydują się na projekty fixed price’owe, żeby uniknąć sytuacji, że ze zmieniającym się zakresem nagle zacznie rosnąć cena. Ciągle pracuje się w tych Waterfallach, żeby tego pilnować, bo to rozciąganie i ten never-ending project, to nie jest scenariusz dla nikogo dobry. Wiem, że ludzie w takich projektach najczęściej po prostu się cieszą, że coś się skończyło.

Trzeba pamiętać, że ktoś też za to musi zapłacić i jeżeli coś się miało przeciągać zbyt długo i np. developerzy też byli w coś dłużej zaangażowania miesiąc czy dwa, a było ich na pokładzie czterech, każdy zarabiał, dajmy na to 25-30 tysięcy (niech to będą seniorzy), to są to olbrzymie pieniądze. Finalnie za takie wydłużanie ponosi odpowiedzialność Project Manager.

Wszystko zależy od tego, na jakim etapie jest człowiek i jak podchodzi do project managementu. Im to doświadczenie jest większe, im bardziej też oswajamy się z tymi trudnymi wyzwaniami, tym inaczej reagujemy. Jeżeli z tym sobie poradzimy, każde inne wyzwanie będzie czymś dodatkowym, do czego podejdziemy na zasadzie: OK, mam coś, muszę pomyśleć, co mam z tym zrobić, do kogo mam z tym pójść, jak ta osoba mi może w tym pomóc, jak to wpłynie. Jeżeli ten wpływ będzie taki, że coś się wydłuża, no to czy mamy na to pieniądze, ale jak nie mamy, no to być może trzeba wtedy ten zakres gdzieś tam o coś obciąć i czegoś po prostu nie robić. Zaczyna się wtedy ten element komunikacyjny, negocjacyjny i to są też bardzo ważne umiejętności, które każdy Project Manager powinien ćwiczyć, nabywać i docelowo mieć. 

Skoro mieliśmy wyzwania, to chyba czas powiedzieć o satysfakcji. Co przynosi największą satysfakcję, jeśli chodzi o pracę PM-a?

To jest właśnie ten dostarczony projekt, tak mówiąc w cudzysłowie, ta możliwość zgaszenia tego światła na sam koniec w projekcie. To jest bardzo przyjemny element, gdy można sobie powiedzieć: no, skończyłam.

Żeby ten sukces był i żeby można było mówić o satysfakcji, no to ja na swojej checkliście mam takie sprawdzenie: czy ten klient jest usatysfakcjonowany, czy czuję, że to, co zrobiliśmy, jest dobrą robotą.

Kolejny punkt to zespół. To jest też pewnego rodzaju umiejętność, żeby zespół chętnie ze sobą współpracował, żeby tam była energia, żeby tam była synergia. Miałam takie zespoły, gdzie w piątek spotykaliśmy się o 20 na piwie czy tam na jakimś drinku. I to było wszystko w czasie pandemii, więc my to robiliśmy patrząc się w swój komputer. Taka była motywacja ludzi, że chcieli się poznać, spędzić czas ze sobą, chcieli się o sobie czegoś dowiedzieć.

Zupełnie inaczej buduje się rozwiązania z takimi ludźmi niż z takimi, którzy są zamknięci 8-16, dziękuję i do widzenia. Jak mi tylko powiesz, że mam zrobić coś więcej, to będę niezadowolona. Więc jeżeli w trakcie projektu udało się taką atmosferę zbudować, no to jest to kolejny sukces i na pewno, można sobie powiedzieć: też zrobiłam dobrą pracę.

To może ja jeszcze zdradzę małą tajemnicę. Przed naszym nagraniem wspominałaś, że czekasz na potwierdzenie, czy prace zostały zakończone. Ciekawy jestem, czy już masz informację, że wszystko ruszyło, czy nadal czekasz?

No nie, mój dostawca aktualnie sprawia, że moja mina jest smutna, bo faktycznie o 17 miałam odświeżyć stronę i miała ona działać. Ja miałam mieć już maile z informacją, że te prace doszły do końca. Natomiast dochodzimy do godziny 17 i dalej tego nie mamy.

Czyli jednak weekend będzie pracujący, może nie dla Ciebie, ale dla wykonawcy chyba tak.

Wiesz co, tutaj też chodzi o takie zrozumienie, bo my żyjemy w świecie IT. I właśnie od PM-ów oczekuje się dostarczenie na czas, a od developerów określenia tego czasu. Tylko gdy robimy jakieś działania, to zakładamy pewną złożoność, określamy ten czas, w który celujemy. Ja jestem świadoma tego, że to jest w jakimś stopniu wróżenie z fusów.

Teraz jest kwestia tego, jak ja na to zareaguję, bo ja mogę, podejść do komputera i napisać: no sorry, od godziny nie informujecie, że to już jest skończone, czyli co, kolejny raz dajecie ciała. Ale jeżeli ja myślę o tym dostawcy jako o kimś, z kim moja firma chce jeszcze współpracować przez następne, powiedzmy 5 lat, to moim zadaniem jest zadbać o to, żeby ta komunikacja dalej była fajna, aby nam się razem dalej chciało współpracować. Bo jak pójdę i ich opieprzę, jeden, drugi, trzeci raz, to też ktoś powie: dobra, to ja już nie chcę, pójdę sobie gdzieś indziej. I tak traci się tych ludzi.

Podejrzewam taki scenariusz, że jak skończymy, to wyślę maila z pytaniem, na jakim etapie jesteśmy i tyle, chcąc uzyskać faktycznie obraz tego, co dzieje się po drugiej stronie, no bo tego nie jestem w stanie w żaden sposób samodzielnie sprawdzić. Podejrzewam, że wtedy ta odpowiedź przyjdzie.

To dajmy im jeszcze chwilę, może jak faktycznie skończymy nagrywać, to już będzie wszystko gotowe.

A ja Ciebie będę chciał zapytać o książkę, którą polecisz osobie, chcącej być dobrym Project Managerem.

To jest trudne, bo nie ma jednej książki, która pozwoli komuś być dobrym Project Managerem. Tych umiejętności do nauki jest tyle, projekty są na tyle złożoną inicjatywą, tam trzeba się ćwiczyć we wszystkim. W tej komunikacji, w zarządzaniu zespołem, ryzykami. Być może jest jakaś książka z Project Managementu, która to wszystko opisuje, ale nie szłabym w tę stronę.

Sugeruje pozycję, która jest trochę spoza branży i będzie to pozycja Być liderem Alexa Fergusona, który był trenerem piłkarskim klubu Manchester United. Osiągnął przy tym zespole olbrzymie rezultaty. Przez 30 lat pracował w tej profesji. I tu nie chodzi o nazwy, to chodzi o to, jakie umiejętności nabył, do czego zmotywował swoich ludzi. Jak podchodził do ludzi, którzy są młodzi i są juniorami. Jak podchodził do tych, którzy są seniorami. Jaką wartość widział w jednych i drugich. 

Bo ja też nie uważam, że projekt będzie dobry tylko wtedy, gdy będą sami senior developerzy, senior business analitycy, senior testerzy itd. To jest pewnego rodzaju łatwość, natomiast nie można się tak zamykać i pracować w ten sposób. Trzeba dać szansę nowym ludziom, żeby faktycznie się rozwijali i wnosili taką swoją świeżość. Jak się buduje rozwiązania w jakiś start-upach to jest to też bardzo potrzebne i trzeba szukać tego balansu, a nie zamykać się.

Dlatego ta pozycja Alexa Fergusona Być liderem pozwala spojrzeć trochę szerzej na profesję, o której dzisiaj rozmawialiśmy, a jednocześnie dać takie fajne punkciki, które można zmienić też u siebie i jednocześnie usprawnić swoją pracę.

Ciekawe jest też to, że Ty jako osoba, która (podejrzewam) nie interesuje się piłką nożną, sięgnęła po tę książkę i ją poleca. Ja już zamówiłem i zamierzam przeczytać, bo nie jesteś pierwszą osobą, która poleca tę pozycję.

Tak, bardzo mocno polecam przede wszystkim przez to, jaką głowę miał ten człowiek i jak zarządzał tymi ludźmi, jakie ma sugestie. Uważam, że ta pozycja jest szczególnie ważna w Polsce, gdzie ten system zarządzania jest ciągle taki micromanagementowy, a nie rozwojowy dla człowieka. Uważam, że w Polsce musimy zacząć wychodzić z tego micromanagementu, dawać ludziom odpowiedzialność. Dlatego bardzo lubię Scruma, tę odpowiedzialność, która jest w zespole. Jak ludzie to czują, budują fajniejsze rzeczy i naprawdę nie trzeba nad nikim stać i go gonić. 

To też od razu dodajmy, że Twoja perspektywa jest też taka, że teraz pracujesz dla firmy ze Szwajcarii i masz możliwość spojrzenia na tę działkę z innej perspektywy, nie tylko poletka polskiego, ale też zagranicznego.

Tak. My musimy patrzeć szerzej, musimy się uczyć od tych krajów, gdzie taki profesjonalny biznes jest budowany znacznie dłużej niż w Polsce od 1989 r. Dla tych, którzy myślą o project managemencie, wszystkie zasady wdrażane przez project management i tę amerykańską instytucję, są na pewno dobrym wzorem. Tego trzeba się uczyć, no i po prostu profesjonalizować się, tylko w ten sposób osiąga się dobre wyniki. 

To w takim razie, Paulino, powiedz nam, gdzie możemy Cię znaleźć w sieci.

Przede wszystkim jestem na Instagramie, gdzie buduję swoją markę osobistą i tam serdecznie zapraszam. Mój aktualny login to @paulina.twojprojekt. Gdy znajdziecie mnie na Instagramie, to myślę, że dużo łatwiej będzie znaleźć mnie też na LinkedInie, w bio jest podany bezpośrednio link do mnie. 

Na pewno podlinkujemy, więc wszyscy będą mogli się zainteresować Twoimi działaniami w sieci, a ja Tobie Paulino bardzo dziękuję za tę rozmowę i podzielenie się swoimi doświadczeniami.

Mateusz, bardzo dziękuję, było mi bardzo miło i wierzę, że ktoś tutaj znajdzie wartość dla siebie i dzięki temu będzie skuteczniej pracował.

Z całą pewnością tak. Dzięki jeszcze raz, do usłyszenia.

Dzięki, hej.