Kierownik projektu dla wielu się wydaje superbohaterem: najlepszy przyjaciel zespołu, wierny doradca klienta, od urodzenia zna angielski, umie przekazywać informacje za pomocą gestów, błyskawicznie dodaje zadania do trackera zadań i gasi pożary na projekcie gołymi rękami. Ale czy powinien mieć dodatkowo doświadczenie programistyczne?
Diabeł w szczegółach
Zadania kierownika projektu są dalekie od pisania kodu, ale aby zdobyć szacunek zespołu i doprowadzić projekt do logicznego zakończenia, manager musi nie tylko działać jako gołąb pocztowy, przenoszący wiadomości od klientów do zespołu, ale wziąć pełną kontrolę nad rozwojem.
Problem polega na tym, że musisz się w to zagłębić. Znam kilka sytuacji, w których kierownik projektu popełnił błąd właśnie przez luki w części technicznej, a karę poniósł cały zespół.
Przykład pierwszy. Nie wybronił interesów zespołu
PM wybrał zły system kontroli wersji. Dokładniej, nie pomógł wybrać właściwego.
Czym właściwie jest system kontroli wersji? Jeśli przeprowadzimy analogię z grami komputerowymi, to jest to możliwość zapisania w dowolnym momencie, a jeśli coś nie wyszło, ponownie przejść przez poziom z punktu kontrolnego.
Nasz klient miał w przeszłości doświadczenie programistyczne (jak się później okazało miał gdzieś ponad 50 lat) i bazując na swoim doświadczeniu, z dwóch opcji systemów kontroli wersji (konserwatywnego SVN i nowoczesnego GIT), wybrał SVN, argumentując, że czasami będzie przychodził i sprawdzał, jak idzie praca. To znacznie spowalniało rozwój i psuło nastrój zespołu, ponieważ bardziej wyrafinowany GIT jest dziesiątki razy wygodniejszy i lepiej opanowany. Czy muszę mówić, że prosiliśmy PM-a o wpłynięcie na opinię klienta?
Po zakończeniu etapu planowania i rozpoczęciu aktywnej pracy okazało się, że sprawa nie została poruszona. Myślę, że gdyby kierownik projektu rozumiał znaczenie odpowiedniego systemu kontroli wersji, nie zignorowałby naszej prośby.
Przykład drugi. Straciliśmy majątek
Równie ciekawym przypadkiem była sytuacja, gdy PM podjął się szeregu zadań związanych z odtwarzaczem audio na stronie internetowej. Jednym z kryteriów akceptacji było to, że muzyka powinna być odtwarzana na stronie przez cały czas (bez zatrzymywania), a strona została pierwotnie zaprojektowana w taki sposób, stworzenie tej funkcjonalności było drogą przez mękę.
Czy ten odtwarzacz audio był wart czasu i sił, które nad nim poświęcono, pozostało tajemnicą. Być może, gdyby kierownik projektu wyjaśnił klientowi wszystko od samego początku, zmieniłby zdanie i wybrał prostszą opcję wdrożenia, ale tak się nie stało i rozwój musiał kosztować majątek.
Przykład trzeci. Brak dostępu — brak pracy
Stały klient zespołu potrzebował w weekend małej poprawki na serwerze. Relacje z klientem były tak dobre, że developer nie miał nic przeciwko spędzeniu kilku godzin w pracy w dzień wolny. Wyglądało na to, że wszyscy się zgodzili, po czym kierownik projektu miał uzyskać dostęp do serwera i przekazać go programiście.
Jednak nie zdając sobie sprawy z ważności zadania, PM po prostu o tym zapomniał. Nie otrzymawszy danych, programista uznał, że zadanie jest nieaktualne i spędził weekend bez pracy.
Poniedziałkowy poranek okazał się niezręczny, bo gdy manager przyszedł po wynik, nastąpiła długa cisza. Jaki może być wynik, jeśli developer nie otrzymał niezbędnych dostępów?
Co więc powinien wiedzieć kierownik projektu
W zasadzie PM to osoba, która potrafi wszystkiego po trochu, ale przede wszystkim musi być efektywnym komunikatorem.
Co potrzebujesz żeby być dobrym PM:
- umiejętność szybkiego i efektywnego zrozumienia tematyki projektu;
- zrozumienie cyklu życia wytwarzania oprogramowania;
- znajomość metodyk budowania procesu wytwarzania oprogramowania;
- umiejętność analizy potrzeb klienta i jego biznesu;
- umiejętność planowania czasu własnego i innych;
- umiejętność stawiania na swoim i promowania interesów klienta lub zespołu;
- umiejętność motywowania pracowników;
- umiejętności zarządzania czasem;
- umiejętności zarządzania finansami w projekcie;
- umiejętności zarządzania zespołem;
- umiejętności zarządzania komunikacją wewnętrzną i zewnętrzną.
Ta lista dopiero się zaczyna, ponieważ aby zbudować skuteczną komunikację, musisz zrozumieć tych, którzy piszą „rozszerzalny i łatwy w utrzymaniu kod” oraz rozumieć podstawowe pojęcia.
Co zdaniem programistów dobry PM powinien wiedzieć i umieć:
- wiedzieć, jak dane są przechowywane w projekcie;
- jaka jest różnica między frontendem a backendem;
- czym języki programowania różnią się od siebie;
- jak projekt jest wdrażany (przynajmniej gdzie);
- zrozumieć, co to jest HTTP i JSON;
- znać główne etapy tworzenia aplikacji w zależności od dziedziny;
- być w stanie wygooglować.
Umiejętności te pomogą managerowi być bliżej zespołu i zminimalizować sytuacje braku dostępu do serwera i repozytoriów, obiecywania naprawić problemy w godzinę (jeśli faktycznie pracy jest na cały tydzień), zmniejszyć liczbę błędnych oszacowań, a także – uświadomić zespołowi, że ich PM to nie tylko listonosz, ale taka sama osoba z działu IT, co oni.
Jak dokręcić część techniczną
Podsumowując, chcę powiedzieć, że wiedza techniczna jest ważna dla PM-a. Jednak brak doświadczenia w rozwoju produktu nie jest wyrokiem. Osoby z innych dziedzin, wykazujące ciekawość i zapał, mogą zostać doskonałymi managerami w dziedzinie IT.
Aby mówić tym samym językiem z programistami, musisz wykazać chęć zrozumienia ich zawodu. Dobrą praktyką jest uczęszczanie na kursy (możesz nauczyć się podstaw języka programowania lub od razu wziąć udział w kursie wiedzy technicznej dla osób nie będących technikami). Przyda się czytanie książek o podejściach architektonicznych, udział w wydarzeniach tematycznych i hackathonach.
Nie krępuj się zadawać pytania swojemu zespołowi, ponieważ lepiej zapytać trzy razy, niż raz pomylić się z terminem i płatnością. Pamiętaj, Twoim głównym zadaniem jest praca ramię w ramię ze swoim zespołem i osiągnięcie maksymalnego zrozumienia w każdej sytuacji!
