Kiedy zaczynałam swoją przygodę z zarządzaniem projektami, byłam przekonana, że wystarczy opanować jedną metodykę, kilka narzędzi i resztę życia zawodowego spędzić na spokojnym dowożeniu projektów według sprawdzonego schematu. Szybko rzeczywistość zweryfikowała te plany.
Pracowałam w bankach, fintechach, medtechu, e-commerce. W korporacjach z rozbudowanym PMO i w startupach, gdzie PM to jednocześnie analityk, scrum master i czasem też tester. W każdym z tych miejsc rola project managera wyglądała zupełnie inaczej. To była lekcja.
Największy błąd jaki widzę u początkujących PM-ów oraz u siebie sprzed lat, to szukanie jednej, słusznej definicji tej roli. Tymczasem project manager w korporacji z procesem stage-gate, zatwierdzonymi szablonami i komitetem sterującym to zupełnie inny zawód niż PM w 20-osobowym startupie, gdzie dokumentacja projektowa to jeden plik w Chmurze i sprint review przy kawie.
Oboje są project managerami. Oboje robią swoją robotę dobrze. Po prostu w innych warunkach.
Dlatego pierwsza rada jest prosta: zanim zaczniesz w nowym miejscu, zanim otworzysz JIRĘ i zaczniesz tworzyć tablicę kanban - zrozum organizację. Jak tu się podejmuje decyzje? Kto naprawdę ma władzę, a kto tylko tytuł? Gdzie są nieformalne kanały komunikacji? Odpowiedzi na te pytania są ważniejsze niż wybór metodyki.
Przez lata obserwowałam organizacje, które wdrażały Agile jak religię. Codzienne stand-upy, retrospektywy, velocity, story pointy, wszystko zgodnie z podręcznikiem. I projekty nadal się sypały, tylko teraz robiły to w dwutygodniowych sprintach zamiast w kwartalnych milestone'ach.
Metodyka to narzędzie. Tak jak młotek jest narzędziem i świetnie wbija się nim gwoździe i jest fatalny do przykręcania śrub. Agile doskonale sprawdza się przy projektach gdzie wymagania są niepewne, produkt ewoluuje i potrzebujesz szybkiej pętli feedbacku. Waterfall ma sens przy wdrożeniach regulowanych, gdzie zakres jest sztywny, a zmiana kosztuje dużo. Hybryda, najczęściej gdy rzeczywistość jest bardziej skomplikowana niż każde z tych podejść osobno.
Każdy projekt ma interesariuszy którzy chcą różnych rzeczy, mówią różnymi językami i mają różne wyobrażenia o sukcesie. Twoją robotą jest to przekładać, nie udawać że wszyscy są zgodni.
Kilka rzeczy które mi pomogły:
Rozmawiaj z ludźmi zanim cokolwiek wyślesz mailem. Trudna rozmowa w 15 minut jest lepsza niż tygodniowa wymiana maili która nic nie rozwiązuje i wszystkich irytuje.
Naucz się rozmawiać z zarządem inaczej niż z zespołem technicznym. Zarząd nie chce wiedzieć że masz 47 otwartych ticketów. Chce wiedzieć czy projekt dowiezie cel biznesowy, na kiedy i ile będzie kosztować. Dostosuj komunikat do odbiorcy.
Złe wieści podawaj wcześnie. Opóźnienie o którym powiesz trzy tygodnie przed deadline'em to kryzys. To samo opóźnienie zgłoszone dwa miesiące wcześniej to zarządzanie ryzykiem.
PM nie jest od tego, żeby wiedzieć wszystko. Jest od tego, żeby wiedzieć kto wie i jak to połączyć w całość.
Pracowałam z deweloperami którzy znali system lepiej ode mnie. Z analitykami którzy rozumieli domenę biznesową głębiej niż jakikolwiek manager. Z kierownikami którzy widzieli ryzyka których ja nie zauważyłam. Każdy z nich był zasobem, pod warunkiem że umiałam ich słuchać, a nie tylko delegować.
Ego jest najdroższym kosztem w projekcie. Nie ma go w budżecie, ale zawsze widać go w harmonogramie.
Każda nowa organizacja to nowy kontekst, nowe wyzwania, nowy układ sił. PM który pracował tylko w jednym miejscu, jedną metodą, z jednym typem projektu - jest dobry w tym jednym miejscu. PM który przeszedł przez kilka kontekstów jest lepszy wszędzie.
Dlatego jeśli czujesz że utknęłaś/utknąłeś - zmiana jest inwestycją, nie ucieczką. Nowe środowisko uczy rzeczy których żaden kurs nie nauczy: elastyczności, czytania organizacji, adaptacji pod presją.
Moje projekty w medtechu nauczyły mnie precyzji i zarządzania ryzykiem w środowisku regulowanym. Fintech nauczył mnie szybkości i priorytetyzacji w chaosie. E-commerce nauczył mnie myślenia produktowego. Każde z tych doświadczeń jest teraz częścią tego jak pracuję - bez względu na to w jakiej organizacji akurat jestem.
Nie musisz znać odpowiedzi na każde pytanie - musisz wiedzieć jak ją znaleźć.
Certyfikat otwiera drzwi, ale nie zastąpi zdrowego rozsądku i umiejętności rozmowy z ludźmi.
Najlepsze projekty które prowadziłam miały jedno wspólne - zaufanie między zespołem a PM-em. Buduj je od pierwszego dnia, bo nie da się go kupić ani wpisać do harmonogramu.
I ostatnie: projekt który się nie udał nauczy Cię więcej niż dziesięć które poszły gładko. Pod warunkiem że wyciągniesz wnioski, a nie tylko kogoś obwinisz.