Po co mi Project Manager w projekcie IT? Wywiad z Senior PMem w mobitouch.

Co decyduje o sukcesie aplikacji? Jak uniknąć przekroczenia budżetu i na czym nie warto oszczędzać? Na te i wiele innych pytań odpowiada Gracjan Walczak, Senior Project Manager w mobitouch, który od lat skutecznie zarządza projektami IT. W tym wywiadzie dzieli się swoim doświadczeniem, pokazuje kulisy pracy PM-a i podpowiada, jak sprawnie prowadzić projekt od startu aż do wdrożenia.

O Gracjanie: Senior Project Manager, swobodnie poruszający się między klasycznymi metodologiami (Waterfall, Prince2, PMBOK) a podejściem Agile (Scrum, Kanban, SAFe). Gracjan ma bogate doświadczenie zarówno we współpracy z międzynarodowymi korporacjami, jak i w prowadzeniu dynamicznych projektów startupowych. Jak sam mówi, Project Management to dla niego nie tylko praca, ale prawdziwa pasja, która napędza go do ciągłego rozwoju.

Kasia Sitarz: Co by się stało, gdyby zespół pracował bez PMa?

Gracjan Walczak: Nastąpiłby totalny chaos. Zespół miałby problem z określeniem która osoba jest odpowiedzialna za które zadanie, ile czasu można na nie przeznaczyć, kto i w jaki sposób ma komunikować się z klientem. Project Manager to osoba, która patrzy na projekt “z góry”, to znaczy całościowo. Oznacza to, że jest w stanie zauważyć wszelkie potencjalne problemy, które mogą spowodować, że pojawi się ryzyko przekroczenia harmonogramu lub budżetu. Praca PMa to nie tylko “rozdzielanie tasków” zespołowi developerów.

Bez PMa zespół mógłby stracić z oczu szerszy kontekst projektu. Developerzy, choć świetni w swojej dziedzinie, często skupiają się na technicznych aspektach, a nie na strategicznych celach biznesowych. PM jest tym, który łączy te dwa światy – techniczny i biznesowy – dbając o to, aby projekt nie tylko działał, ale także przynosił wartość dla klienta.

Dodatkowo, PM pełni rolę bufora między klientem a zespołem. Gdy klient ma zmieniające się wymagania lub oczekiwania, to PM jest osobą, która ocenia, jak te zmiany wpłyną na harmonogram i budżet, oraz przekazuje je zespołowi w sposób, który minimalizuje zakłócenia. Bez PMa takie sytuacje mogłyby prowadzić do nieporozumień, frustracji a w konsekwencji – do opóźnień i dodatkowych kosztów.

Czym właściwie zajmuje się Project Manager?

Moim zadaniem jest rozpisanie epików, user stories i przypisanie ich zespołowi. Moja rola polega na tym, by upewniać się, że czas i budżet są rozsądnie wykorzystywane i nie przekraczane. Przede wszystkim dbam o to, aby zespół realizował poszczególne zadania w określonym czasie.

Dodatkowo dbam o płynną komunikację między interesariuszami, usuwam przeszkody, które mogą blokować postęp prac oraz monitoruję ryzyka związane z projektem. Ważnym aspektem mojej pracy jest również dbanie o jakość dostarczanych rozwiązań i wspieranie zespołu w osiąganiu celów biznesowych. Współpracuję z Product Ownerem oraz deweloperami, aby zapewnić skuteczne zarządzanie priorytetami i dostarczenie wartości dla klienta.

Na co dzień też regularnie organizuję spotkania statusowe, takie jak daily stand-upy czy retrospektywy, aby utrzymać ciągłość procesu oraz umożliwić zespołowi dzielenie się postępami, wyzwaniami i pomysłami na ulepszenia. Kluczowym elementem mojej pracy jest także analiza wyników projektu po jego zakończeniu w celu wyciągania wniosków, które pozwolą na ciągłe doskonalenie procesów zarządzania projektami.

Czy zespół nie może zorganizować się sam?

Może – ale to wymaga odpowiednich umiejętności oraz dodatkowego czasu i energii, które mogłyby zostać poświęcone na samo programowanie. Ostatecznie warto się zastanowić, czy nie lepiej, aby developerzy skupili się na pisaniu kodu, a kwestie organizacyjne powierzyć komuś, kto zajmuje się tym zawodowo. Istnieją projekty, w których próbuje się stosować turkusowe podejście, czyli takie, w którym wszyscy są „równi” i nie ma jednej osoby zarządzającej. Ale w praktyce to rzadko się sprawdza. Ważne jest, aby była jedna osoba, która ma jasno wyznaczoną odpowiedzialność i decyzyjność, czego brakuje przy podejściu turkusowym brakuje.

Wyobraźmy sobie taką sytuację. Jestem founderem startupu. Chcę stworzyć aplikację. Dokładnie wiem jakie są jej wymagania. Jestem w stanie śledzić postępy lub rozpisywać zadania. Na tym etapie to, czego mi brakuje to fundusze. Wydaje mi się, że zaoszczędzę, jeśli to ja będę zarządzać swoim własnym projektem zamiast opłacać pracę PMa. Czy to dobry pomysł?

Zawsze doceniam to, że klient jest zaangażowany w projekt, lecz nie polecam, aby klient pełnił rolę Project Managera. Przede wszystkim klient nie zna zespołu ani umiejętności poszczególnych osób. Poza tym zespół developerski często będzie miał opór, aby przyznać przed klientem, że pojawił się jakiś problem lub wątpliwość. Z jednej strony klient, jako osoba mocno zaangażowana w swój projekt, naturalnie chce zobaczyć efekty jak najszybciej. Zespół developerski z kolei skupia się na dostarczeniu najlepszego możliwego rozwiązania, co czasem wymaga dodatkowego czasu niż pierwotnie zakładano lub przemyślenia alternatywnych podejść. Mogą powstawać napięcia między oczekiwaniami klienta a możliwościami ich wykonania. Project Manager jest pewnego rodzaju buforem między klientem a zespołem.

Zatrudnienie Project Managera pozwala founderowi skupić się na rozwoju produktu, sprzedaży i marketingu, podczas gdy PM zapewnia płynne zarządzanie projektem. Jego obecność pomoże uniknąć problemów z budżetem, terminami oraz zapewni lepszą komunikację między zespołem a interesariuszami.

Czy można powiedzieć, że Project Manager pełni funkcję podobną do “trenera” sportowego? 

Można pokusić się o taką metaforę. Mi osobiście podoba się porównanie do dyrygenta, który dba o to, by ukierunkować zespół na dobre tory lub coacha drużyny NBA, która ma cele do zrealizowania w bardzo krótkim czasie. Musimy sobie podawać piłkę, żeby wygrać “mecz” lub “rozgrywki”. Każdy w drużynie jest specjalistą w swojej dziedzinie, ma swoją ważna funkcję, a zadaniem PMa jest synchronizowanie ich wspólnej “gry”, jednocześnie mając na uwadze szeroki kontekst, “boisko”, reagowanie na zmiany, dostrzeganie ryzyka, łagodzenie napięć, motywowanie zespołu..

Dlaczego zarządzanie projektem wymaga tak wielu spotkań i raportów?

Spotkania i raporty to niezbędne narzędzia, które zapewniają kontrolę nad postępami projektu oraz budżetem. Pomagają uniknąć nieprzewidzianych problemów, dając jasny obraz czasu, kosztów i pozostałych zadań. Dzięki nim możemy przewidywać ewentualne wyzwania i podejmować działania, zanim wpłyną one na harmonogram lub budżet.

Częstotliwość spotkań zależy od specyfiki projektu i preferencji klienta. Dla niektórych firm częste spotkania to wartość dodana, gwarantująca pełną transparentność, dla innych – może to być dodatkowy obowiązek. Wiele spotkań odbywa się na prośbę klienta, zwłaszcza jeśli w projekcie biorą udział nie tylko osoby bezpośrednio zaangażowane, ale także sponsorzy czy inwestorzy, którzy chcą mieć regularne informacje o postępach.

Jakie są najczęstsze problemy i wyzwania podczas tworzenia aplikacji, które prowadzą do nieuzasadnionych przekroczeń budżetu?

Gracjan: Pod względem organizacyjnym, najczęstszy problem to błędne założenia. Wyobraźmy sobie, że zespół otrzymuje wymagania funkcjonalne dla danego modułu, realizuje je, a następnie okazuje się, że podejście to było błędne, ponieważ nie jest możliwa integracja tak wykonanego modułu z obecnym systemem klienta. W efekcie poświęcimy wiele godzin na coś, co finalnie wymaga poprawek lub całkowitej zmiany.

Co można zrobić, aby tego uniknąć? 

Przede wszystkim jasna i przejrzysta dokumentacja projektowa oraz uwzględnienie wszystkich integracji z zewnętrznymi systemami na tym etapie. Warto podsumowywać ustalenia po każdym spotkaniu i mieć jedno miejsce, w którym wszyscy mogą je sprawdzić – na przykład w narzędziach typu Jira, DevOps czy Confluence.

Czyli czym dokładniej umówimy prace, tym lepiej dla projektu?

Tak, ale bez popadania w drugą skrajność. Z jednej strony nie można pozwolić na niedomówienia, ale z drugiej – nadmierna komunikacja również może być problemem. Jeśli zamiast podejmować decyzje, zbyt długo rozważamy alternatywy, projekt może utknąć w miejscu. Zdarza się też, że klient wysyła PMowi lub zespołowi liczne wiadomości z drobnymi pytaniami. Tu z kolei ważna jest efektywna komunikacja – dobrze jest ustalić rytm spotkań i kanały wymiany informacji, tak aby każdy mógł pracować bez ciągłych przerw na odpowiedzi. Warto zadawać sobie pytanie: „Czy ta decyzja jest konieczna na tym etapie? Czy pozwala nam ruszyć do przodu?”. W ten sposób unika się blokad i zapewnia płynność pracy.

Masz bogate doświadczenie w pracy ze startupami oraz z klientami korporacyjnymi. Co doradziłbyś founderowi, który chce stworzyć swoją pierwszą aplikację?

Przede wszystkim, zanim przejdziemy do fazy developmentu, warto poświęcić czas na dobrze przemyślany research. Mam na myśli zarówno analizę rynku, jak i doprecyzowanie misji i wizji projektu.

Zacznijmy od analizy rynku. Często widzę sytuacje, w których founderzy zaczynają działać intuicyjnie, zakładając, że sam pomysł wystarczy. W rzeczywistości zdecydowana większość startupów upada, ponieważ ich produkt nie znajduje odpowiedniego market fitu – czyli nie odpowiada realnym potrzebom rynku. I tutaj bardzo ważne wyjście z naszej “bańki”.

Jak to zrobić?

Zderzyć swój pomysł z jak największą liczbą osób: zarówno z grupą docelową aplikacji, jak i z osobami, które mają doświadczenie jako founderzy. Być może nasi znajomi budują startupy i mogą dać nam wskazówki co zadziałało, a co nie. Warto również porozmawiać z przedstawicielami funduszy VC. Takie osoby widziały już dziesiątki projektów i może się okazać, że nasz pomysł wcale nie jest unikatowy, że podobna aplikacja do tej, którą chcemy zbudować, już wcześniej powstała i jej droga niestety nie zakończyła się sukcesem. Na pewno nie jest to informacja, którą chcielibyśmy dostać, ponieważ już na tym etapie włożyliśmy w swój pomysł dużo wysiłku i planowania. Natomiast dzięki takiej rozmowie możemy dowiedzieć się jakie wnioski wtedy wyciągnięto. Są to bardzo cenne informacje, dzięki którym nie będziemy musieli popełniać tych samych błędów. 

A jednak często founderzy tego nie robią. Jak myślisz, dlaczego?

Być może chodzi o obawę przed tym, że ktoś ukradnie nam pomysł na startup, lub zwyczajnie boimy się bycia ocenianym, boimy się negatywnej informacji zwrotnej. Lub wręcz uważamy, że nie warto zainwestować w konsulting, ponieważ myślimy, że wszystko mamy świetnie przemyślane. A okazuje się często, że takie rozmowy otwierają oczy na aspekty, o których wcześniej się nie pomyślało, lub wręcz o których istnieniu nawet nie wiedzieliśmy. 

A co z finansowaniem?

Finansowanie to kwestia, o której należy pomyśleć od samego początku, przed kontaktem z software housem. Często chwali się podejście “bias for action”, czyli gdzie należy jak najszybciej zacząć działać, nawet jeśli nie przeanalizowaliśmy naszego pomysłu lub strategii zbyt szczegółowo. Powiedziałbym, że jest to amerykańskie podejście, które ma swoje uzasadnienie na tamtejszym rynku – dużym, bardziej przychylnym nowym pomysłom, gdzie możliwości finansowania są łatwiejsze, ekosystem startupowy jest bardziej rozwinięty. W Europie trudniej jest zdobyć finansowanie. Oglądany jest każdy grosz. Dla przykładu, jeden z bardziej rozpoznawalnych polskich startupów zdobył finansowanie dopiero w USA. Ale tutaj mówimy o produkcie dojrzalszym, który już udowodnił swoje uzasadnienie biznesowe. Widziałem za to projekty, które dobrze rokują, ale zbyt optymistyczne podejście do finansowania sprawiło, że kończyły się w połowie drogi.

Co mógłbyś doradzić jeśli chodzi o analizę misji i wizji projektu?

Jeśli już oceniliśmy, że nasz docelowy rynek ma potrzebę na naszą usługę lub produkt, pora na analizę tego w jaki sposób ta potrzeba będzie realizowana. Mowa tutaj o planowaniu funkcji aplikacji, możliwości jakie daje ona użytkownikowi, ale również możliwości od strony technicznej. To najczęściej na tym etapie przyszły founder kontaktuje się z wykonawcą – przykładowo software housem. Agencje tego typu również doradzają i pomagają pomysłodawcy zaplanować zakres aplikacji, biorąc pod uwagę możliwości danej technologii i budżet projektowy. Natomiast zanim skontaktujemy się z software housem, musimy już mieć spójną wizję naszego produktu.

Porozmawiajmy teraz o klientach korporacyjnych, ze znacznie większymi budżetami i bardziej skomplikowanymi wymaganiami. Wyobraźmy sobie, że taka firma potrzebuje stworzyć nowy system lub zmodyfikować istniejący. Jakich błędów można łatwo uniknąć przed rozpoczęciem współpracy z software housem?

Jeden z największych błędów, jakie widzę – i tutaj znów się powtórzę – to zbyt powierzchowne podejście do analizy przed rozpoczęciem developmentu. Wiele firm uważa, że analiza to coś, na czym można zaoszczędzić, ale brak precyzyjnych założeń szybko odbija się na projekcie. Różnica między startupem, a klientem korporacyjnym jest taka, że ten drugi najczęściej będzie potrzebował rozwiązania, które będzie częścią istniejącego systemu lub będzie się z nim integrowało. Trzeba przeznaczyć czas, aby wdrożyć się w system, zaplanować sposób tej integracji, zaprojektować architekturę czy bazę danych. Niekiedy systemy korporacyjne mogą być starsze, co jest dodatkowym wyzwaniem programistycznym. Może istnieć wiele zależności, które w znaczący sposób wpłyną na wymagania projektowe. Software house pomoże w doprecyzowaniu tych wymagań, ale jeśli klient nie jest gotów poświęcić czasu i funduszy na to na początku, mogą pojawić się błędne założenia, które wygenerują dodatkowe koszty i wydłużają czas realizacji. Nie wszystko zawsze da się przewidzieć na starcie, ale im lepiej przygotujemy się przed rozpoczęciem developmentu, tym mniejsze ryzyko niespodzianek.

Co jeszcze ułatwi współpracę między klientem korporacyjnym a software housem z perspektywy PMa?

Warto pamiętać, że współpraca to proces dwustronny – to nie jest tak, że klient „zleca” projekt i czeka na gotowe oprogramowanie. Bardzo istotne jest to, by po stronie firmy był stały zespół odpowiedzialny za projekt – osoby, które są dostępne na spotkania, mają wiedzę o wizji projektu, a więc mogą sprawnie udzielać odpowiedzi na pytania wykonawcy, nawet jeśli nie od razu. Jeśli w trakcie projektu zmienia się główny kontakt po stronie klienta lub nie ma osoby, która może na bieżąco odpowiadać na pytania zespołu IT, to może dojść do tak zwanego impasu decyzyjnego, który zablokuje dalsze prace.

Dodatkowo, warto wyznaczyć jedną osobę, która będzie liderem projektu po stronie klienta – możemy ją również nazwać Product Ownerem lub Architektem, w zależności od charakteru projektu. Często zdarza się, że po stronie klienta decyzje są podejmowane przez kilka osób, co wydłuża czas i wprowadza zamieszanie. Jeśli jedna osoba jest odpowiedzialna za zbieranie feedbacku i przekazywanie go zespołowi IT wykonawcy systemu, cały proces przebiega płynniej.

Nie warto oszczędzać na…?

Bez dwóch zdań – na testach jakości (QA). Można mieć świetnie zaprojektowaną aplikację, ale jeśli użytkownicy trafią na błędy, cała wartość produktu szybko się rozmywa. Testowanie to nie tylko szukanie błędów, ale też zapewnienie, że aplikacja działa intuicyjnie i stabilnie. I mówię tutaj zarówno o startupach, jak i klientach korporacyjnych.

Dziękuję za rozmowę.

Podsumowując: obecność Project Managera w projekcie to inwestycja, która zapewnia płynność pracy, lepsze wykorzystanie budżetu i sprawną realizację celów, niezależnie od tego, czy projekt realizuje startup, czy korporacja. W mobitouch łączymy doświadczenie w zarządzaniu projektami z ekspertyzą technologiczną, aby dostarczać rozwiązania dopasowane do Twoich potrzeb.