Czy PM powinien posiadać doświadczenie programistyczne? Seniorzy odpowiadają (cz.4)
Zarządzanie zespołem, wdrażanie strategii rozwoju produktu i współpraca z biznesowym działem w firmie. To jedne z głównych zadań Project Managera, które znajdziemy w ofertach pracy. Tylko w części z nich znajdziemy za to wybitne umiejętności programistyczne. To chyba znaczy, że nie są one konieczne w pracy PMa. Co na ten temat myślą seniorzy? Oto zapytaliśmy ich w kolejnej części cyklu pt. Seniorzy odpowiadają.
Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox:
Wielu project managerów, z którymi dobrze mi się pracuje, ma dłuższy lub krótszy epizod w roli programisty lub kodowało po godzinach. Nie uważam jednak, że ma to jakiś fundamentalny wpływ na ich profesjonalizm. W mojej ocenie, dużo ważniejsze są umiejętności analityczne, skuteczność komunikacji, delegowania zadań, ale też empatia, zdolność dostrzeżenia potrzeb członków zespołu i pomoc w osiąganiu ich celów.
Zdaję sobie sprawę, że w niektórych zespołach programistów rola PMa jest jak pałeczka, którą przekazują sobie członkowie albo zaszczyt ten spada na najstarszego programistę. Jeżeli ktoś przejawia takie chęci to świetnie, gdy może się też w takiej roli realizować. Jestem jednak daleki od stwierdzenia, że taki PM jest skuteczniejszy od kogoś, kto skupia się na poznaniu różnych teorii zarządzania, myśli o projekcie strategicznie i wysokopoziomowo, a nie w kontekście wyzwań technicznych.
Odpowiada Damian Dziaduch, Freelancer, Senior Developer:
PM jako programista lub ex-programista? No pewnie! Rozważmy plusy:
- był / jest programistą, więc na pewno miał styczność z innymi PM, więc wie jakie błędy popełniają, tym samym może sam ich uniknąć,
- dużo lepiej doceni pracę deva / testera ponieważ sam nim jest / był, wie jak to jest,
- posiada dużą wiedzę technologiczną w przeciwieństwie do PM nie programisty, dzięki czemu może być na spotkaniach technicznych, tym samym dużo lepiej zintegrować się z całym zespołem,
- prościej będzie mu zrozumieć i pomóc w codziennych problemach trapiących jego zespół,
- kontakty z klientami lub osobami decyzyjnymi będą prostsze, nie będzie potrzebna pomoc devów, bo sam nim jest.
Teraz zastanówmy się nad minusami. Gdy myślałem o tym na początku nic mi do głowy nie przychodziło. Jednak jest jedna rzecz. Taki PM musi sobie zrobić rozwód z programowaniem, co wcale nie jest łatwe. A może wcale to nie jest konieczne?
Także jeśli szukasz dobrego PM warto rozejrzeć się wśród swoich programistów. Któryś z nich może się okazać naprawdę dobrym PMem.
Odpowiada Marcin Dryka, Tech Leader i Partner w Brainhub:
Ludzie mają tendencję do oceniania umiejętności innych poprzez wrażenie wysokiej lub niskiej oceny jednej, specyficznej umiejętności. Mówiąc inaczej, jeśli widzimy osobę ubraną w elegancki garnitur, uczesaną, schludną, bardzo szybko poddajemy się pokusie ocenienia tej osoby jako dobrego człowieka. Psychologia określa tę tendencję jako efekt aureoli. Podobnie ludzie podchodzą do wyboru osób na stanowiska kierownicze: jesteś świetnym programistą, zatem awansujemy Cię na kierownika projektu i będziemy oczekiwać, że będziesz w tym równie dobry”. To błąd poznawczy.
Umiejętności niezbędne do bycia dobrym programistą, to między innymi (choć nie ograniczone do):
- skrajnie analityczne i logiczne myślenie,
- chęć do ciągłego rozwoju własnej wiedzy,
- umiejętność zobaczenia elementów wspólnych w różnych modelach,
- samodzielność w rozwiązywaniu problemów,
- umiejętność przyznania się do niewiedzy,
- umiejętność myślenia nieszablonowego, podczas korzystania z utartych wzorców,
- dbałość o szczegóły.
Podczas gdy dobry PM to osoba charakteryzująca się:
- umiejętnością planowania i przewidywania,
- budowaniem zespołu i dobrej atmosfery w zespole,
- umiejętnością komunikacji na bardzo wysokim poziomie,
- charyzmą,
- umiejętnością negocjacji i rozwiązywania konfliktów,
- wzmacnianiem zaangażowania i zwiększaniem motywacji zespołu.
Wymieniłem tylko kilka z nich, bo z całą pewnością ta lista nie jest kompletna. Ktoś mógłby się nie zgodzić z którymiś punktami, jednak widać, że są to dwa oddzielne zbiory kompetencji. Dobry programista może być oczywiście dobrym kierownikiem projektów (jak i odwrotnie!). Mimo to dobrym kierownikiem nie staje się tylko poprzez bycie dobrym programistą.
Im kierownik wie mniej na temat programowania, tym mniej jest w stanie się wtrącać zespołowi programistów w ich kompetencje, tym bardziej może skupić się na wykonywaniu własnych obowiązków, tym bardziej musi zaufać im, jako specjalistom. W zespole projektowym ludzie powinni mieć do siebie bardzo wysoki poziom zaufania. Tylko brak zaufania do specjalistów może wymagać umiejętności programistycznych, jednak wtedy problem zespołu leży w zupełnie innym miejscu niż programowanie.
Odpowiada Jarek Miazga, Project Manager w Piwik PRO:
Mogłoby się wydawać, że w branży IT oręż umiejętności technicznych w rękach PM-a jest dużym atutem, jest pożądany i może tylko pomóc. W praktyce może to być brzemię, które niesie ze sobą szereg zagrożeń w pracy z zespołem, takich jak problemy z delegacją zadań, brak zaufania czy brak swobody w działaniach zespołu. W konsekwencji może to prowadzić do obniżenia motywacji, braku zaangażowania i samodzielności w tworzeniu oprogramowania.
Kluczem do budowania efektywnych zespołów jest empowerment, czyli oddanie władzy, angażowanie pracowników w ważne decyzje, za które biorą odpowiedzialność. Uważam więc, że PM nie musi być programistą. Może, pod warunkiem, że jest bardzo świadomym menedżerem i nie wchodzi w paradę zespołowi.
Odpowiada Paweł Wacławczyk, Technical Leader w Clearcode:
Myślę, że nie powinien być to wymóg. W zależności od człowieka może mieć to dwojaki efekt na pracę zespołu. Jeżeli wiedza programistyczna posłuży PM-owi do lepszego zrozumienia projektu i merytorycznego wkładu w dyskusję, jest ona jak najbardziej na plus. Niestety zdarza się, że PM, który pracował wcześniej jako programista, zbytnio ingeruje w proces tworzenia oprogramowania lub jest stronniczy. Nierzadko prowadzi to do konfliktów w zespole.
PM, bez takiego doświadczenia, też może mieć całkiem niezłe rozeznanie w świecie technologii. Brak umiejętności programowania może paradoksalnie ułatwić skupienie się na zadaniach związanych bezpośrednio z prowadzeniem projektu. Nie traktowałbym też przejścia do roli menedżera jako awansu, a raczej zmianę zawodu.
Odpowiada Paweł Papke, Tech Lead w Lizard Media:
Korzyści:
– Ewidentnie doświadczenie deweloperskie przyda się na początku ścieżki PMowania, gdy człowiek swoimi twardymi umiejętnościami jest w stanie nadrobić braki w innych obszarach. Łatwiej zrozumie problemy i wyzwania stojące przed zespołem. Jest w stanie prowadzić projekt otrzymując mniejszy feedback od zespołu. Z czasem te różnice się zacierają. Osoby nietechniczne o dobrych umiejętnościach miękkich, które potrafią słuchać i drążyć temat do końca, zdobywają wyczucie, wiedzę i swego rodzaju intuicje w kwestiach technicznych.
– W projektach stricte technicznych doświadczenie programistyczne jest bardzo pomocne. Ułatwia sprawne poruszanie się po twardych aspektach projektu, skuteczne komunikowanie się z zespołem, rozumienie zagrożeń i złożoności dziedziny. Na część z tych tematów zespół niekoniecznie chętnie może chcieć rozmawiać, uznając, że biznes i tak nie zrozumie całego obrazu, a próba wytłumaczenia jest tylko marnowaniem czasu, więc efektywniej będzie po prostu robić swoje. Zazwyczaj braki w komunikacji to początek poważnych problemów projektu.
Zagrożenia:
– Osoba z doświadczeniem programistycznym może za mocno skupić się obszarze technicznym. Jeżeli dodatkowo pracuje w dość stresującym środowisku, może wręcz uciekać w ten obszar, aby unikać niekomfortowych sytuacji, na które byłaby skazana w pozostałych obszarach pracy PMa.
– Może zaistnieć pokusa proponowania zespołowi rozwiązań, wtrącania się w ich kompetencję, naciskania na alternatywne ścieżki implementacji celem skrócenia czasochłonności. W przypadku osoby z wiedzą programistyczną jest to łatwiejsze do przeprowadzenia niż w przypadku osoby, która zna pracę programistów jedynie z boku.
Wchodząc na ścieżkę PMowania warto pamiętać, aby wycofać się ze spraw technicznych, zostawić tę działkę zespołowi. Oczywiście, warto pytać w jaki sposób dana funkcjonalność będzie implementowana, dlaczego tak, czy istnieją alternatywne metody implementacji, ale bez podawania rozwiązywania zespołowi, przysłowiowemu wchodzeniu zespołowi na głowę. Jako PM mamy dużo mniejsze rozeznanie w temacie niż zespół. Często nasze sugestie mogą być naiwne i tylko na pierwszy rzut oka dobre. Lepsze rezultaty mamy kierując się partnerstwem, niż usiłując narzucić swoją wolę.
Podsumowując, moim zdaniem, doświadczenie programistyczne nie jest konieczne, ale jest to plus. PMowi znającemu się na programowaniu zazwyczaj będzie łatwiej poruszać się w środowisku osób technicznych, meandrów technologicznych i wyzwań czy zagrożeń stojących przed projektami IT.