Finture Heroes: Tomasz Pudelewicz​

Jak widać, twoja rola na przestrzeni lat mocno się zmieniała. Lubisz to, gdzie jesteś teraz?

Lubię odpowiedzialność związaną z rolą Business Unit Directora, lubię też pracę z ludźmi. Dobrze odnajduję się w większości aspektów kojarzonych z tą rolą. Ale też – wiedziałem, że chcę to robić. Jak wcześniej wspomniałem, to wynik konsekwentnie realizowanego planu.

Wspomniałeś, że pracowałeś m.in. dla Deloitte. Jakie różnice widzisz pomiędzy pracą w dużych korporacjach a miejscem takim jak Finture?

Mamy mniej procedur i większą odwagę kadry zarządzającej, żeby procedury obchodzić, kiedy nie są nam na rękę i projekt może bezpiecznie zyskać na rezygnacji z nich. Mniej nadgodzin – to też istotna różnica działająca na korzyść Finture. Z kolei Deloitte z racji międzynarodowej renomy ma mocno ułatwione zadanie pozyskiwania nowych klientów. I sprzedawania tych samych usług z większą marżą.

Masz swój ulubiony projekt na pokładzie Finture?

Bardzo dobrze wspominam swój pierwszy projekt tutaj. On wciąż trwa – realizujemy go dla PKO Leasing. W momencie, w którym go przejąłem, istniał już od roku.

Nie mogę tu nie podziękować klientowi, który obdarzył mnie bardzo dużym zaufaniem i zgodził się na realizację wszystkich moich pomysłów na zmianę organizacji pracy i wprowadzenie usprawnień w sposobie pracy blisko dwudziestoosobowego zespołu. A zespół składa się nie tylko z pracowników Finture, ale też pracowników klienta i osób które dostarczają inni dostawcy.

Odbiór tych zmian, zarówno wśród członków zespołu jak i przedstawicieli klienta był bardzo pozytywny. A co ważniejsze – pozwoliły one na rozwiązanie wielu problemów, z którymi się wcześniej borykali.

Przykładowo – jednym z wprowadzonych rozwiązań był podział zespołu na 3 mniejsze, co poskutkowało bardziej sprawną współpracą i krótszymi spotkaniami zespołowymi. Z kolei oddzielenie spotkań zespołowych od spotkań z biznesem i zaplanowanie większej liczby krótkich spotkań (z uczestnikami ograniczonymi do niezbędnego minimum) pozwoliło na zdecydowanie lepsze wykorzystywanie czasu każdego członka zespołu.

W Twojej pracy sporo zależy od współpracy z klientem. Co jest dla Ciebie najważniejsze w kontakcie z nim?

Partnerskie podejście, transparentność, nastawienie na współpracę. Jestem za likwidowaniem podziałów na „my i oni” i do tego dążę. Zawsze, gdy organizuję projekt, staram się całemu teamowi przekazać podejście partnerskie do klienta i w miarę możliwości zbudować zespół, w którym klient pełni istotną rolę. Uświadomienie wszystkim, że gramy do jednej bramki, pozwala na uniknięcie wielu problemów, które z innym podejściem zawsze, prędzej czy później, się pojawią.

Wiele osób podkreśla Twoje umiejętności w zarządzaniu projektami. Jaki jest Twój przepis na udany projekt informatyczny?

Bardzo miło mi to słyszeć. Poza wspomnianymi wcześniej transparentnością i partnerskim podejściem do klienta, bardzo ważne jest słuchanie potrzeb członków zespołu. Mówi się, że manager jest tak dobry jak jego zespół. Uważam, że to w dużej mierze prawda. Nasi programiści, architekci, analitycy, testerzy – zawsze mają bardzo dużo spostrzeżeń i zwracają uwagę na rzeczy istotne dla projektu.

Moim zadaniem jest wysłuchanie tych potrzeb i próba wytworzenia mechanizmów współpracy, dzięki którym można wyeliminować lub zminimalizować problematyczne kwestie. A jeśli danego problemu rozwiązać się nie da – zadbać, by wszyscy wiedzieli, jaki jest tego racjonalny powód.

Podczas pracy w Finture wielokrotnie zdarzyło mi się przejmować odpowiedzialność za działający już projekt. W takim wypadku bardzo istotne jest niepodejmowanie pochopnych decyzji. Każda propozycja zmiany powinna być odzwierciedleniem wnikliwych obserwacji tego, jak projekt działał dotychczas oraz rozmów – z członkami zespołu oraz przedstawicielami klienta. Wprowadzanie zmian na zasadzie „bo tak mi dobrze działało w poprzednim projekcie” uważam za nieodpowiedzialne. Dlatego w przejmowanych projektach nigdy nie wprowadzam ich wcześniej niż po miesiącu pracy z zespołem.

Inną rzeczą, której nigdy nie należy robić pochopnie – to oceniać ludzi, członków zespołu. Staram się też nie korzystać z opinii przekazywanych mi przez innych. Wielokrotnie zdarzyło mi się, że po zacieśnieniu współpracy z daną osobą okazywało się, że pierwsze wrażenie czy opinia przekazana przez kogoś – nie miały wiele wspólnego z rzeczywistością.

Ostatnia – ale zdecydowanie nie najmniej ważna rzecz – to unikanie micro-managementu. Uważam, że wręcz należy dążyć zupełnie przeciwnej sytuacji: najlepszy projekt to taki, który prowadzi się sam.

W takim razie – co jest najtrudniejszym elementem w zarządzaniu projektami, w pracy z zespołem i klientem?

Psychologia. Prowadząc wieloosobowe zespoły, często możemy spotkać się z syndromem wypalenia, obniżeniem motywacji. Wielokrotnie wpływ na taki stan rzeczy mają tematy pozapracowe, prywatne. Rozwiązywanie tego typu problemów wymaga wiele wyczucia i bardzo indywidualnego, personalnego podejścia. Nie jest to łatwe. A jednocześnie wiąże się z bardzo dużą odpowiedzialnością.

Tak. Nie da się ukryć, że to zawsze wysoka stawka. W Twojej pracy teraz jest dużo zarządzania, planowania – tego, co, jak i kiedy programować będą inni. A Ty sam – programujesz jeszcze czasem, choćby „dla funu”?

Zdarza mi się tworzyć jakieś szybkie automatyzacje w VBA. Na poziomie zawodowym – paręnaście lat temu udało mi się nawiązać współpracę z dużym graczem operującym na rynku tytoniowym (choć sam w życiu nie wypaliłem nawet jednego papierosa). Ta współpraca zawsze układała się dobrze. Na tyle dobrze, że trwa do dzisiaj  – zdarza mi się, od czasu do czasu, realizować małe zmiany programistyczne w oprogramowaniu dostarczonym temu klientowi wiele lat temu.

A w czym programowałeś na różnych etapach swojej ścieżki zawodowej?

Programować uczyłem się na studiach. Miałem przyjemność studiować na wydziale MIM na UW, tam podejście do nauki programowania polegało na przekazaniu pryncypiów każdego sposobu programowania. Dlatego używaliśmy bardzo egzotycznych języków. Parę przykładów:

Smalltalk – do nauki programowania obiektowego,

Ocaml – programowanie funkcyjne,

Prolog – programowanie w logice,

C – programowanie imperatywne, korzystając z tego języka przeprowadzaliśmy nawet eksperymenty z modyfikacjami jądra linuksa.

Programowaliśmy też niskopoziomowo w asemblerze.

Na studiach kładziono też bardzo duży nacisk na algorytmy i struktury danych.

Pojawiła się też java, .net. Do tej pory uważam, że wybór takich a nie innych języków był bardzo dobrze przemyślanym zabiegiem. Po poznaniu tych języków każdy inny to już była tylko nauka składni i sposobu działania ważniejszych bibliotek.

Zawodowo do repertuaru dodałem języki bazodanowe – jak T-SQL i PL/SQL.

Co wśród osób profesjonalnie zajmujących się programowaniem może być odebrane jako „obciachowe” – uwielbiam VBA i jego prostotę. Jak wspomniałem – zdarzyło mi się w oparciu o ten język dostarczyć rozwiązania komercyjne. Stosunkowo niedawno nauczyłem się też uiPath’a, ale nie wiem czy to można nazwać językiem programowania.