Techniczny kontra nietechniczny project manager – kogo woli rynek pracy?

Kiedy chcesz zostać project managerem, zadajesz sobie pytanie: czy muszę być techniczna / – y? Czy brak takiego doświadczenia dyskwalifikuje mnie z procesu rekrutacji? Czy kompetencje w zarządzaniu projektami, znajomość i umiejętność zastosowania metodyk, zdolności przywódcze i komunikacyjne nie wystarczą? Odpowiedź na te pytania często weryfikują ogłoszenia o pracę, w których kompetencje techniczne wymienione są jako te wymagane. Oto przykład jednego z nich:

• Doświadczenie w programowaniu Java (+4 lata) oraz w zarządzaniu projektami (+4 lata)
• Znajomość metodyki Scrum lub innych metodyk zwinnych, pożądany certyfikat Scrum Mastera
• Znajomość programowania obiektowego (OOP) oraz języków obiektowych (preferowana Java)
• Bardzo dobry angielski w mowie i w piśmie
• Umiejętności zarządzania
• Umiejętność pracy samodzielnie
• Zorientowanie na cel

Jak widać, nacisk położony na kompetencje techniczne jest podobny do tego, jaki położony jest na umiejetności związane z zarządzaniem projektami. Czego właściwie oczekuje obecny rynek pracy? Po co PM’owi kompetencje techniczne i czy naprawdę są potrzebne?

Na te i inne pytania odpowiadamy dzisiaj ja – reprezentant PM’ów nietechnicznych oraz Jakub Dudek – project manager z wieloletnim doświadczeniem programisty Java. Sceneria niemal jak z debaty politycznej, żeby nie powiedzieć z ringu ;) Każdy z nas jest gotów bronić swoich racji. Kto wygra ten pojedynek na argumenty? Zobaczcie!

Czy project manager powinien być techniczny? Czy, aby poradzić sobie z projektem trzeba mieć zaplecze techniczne?

KJ: Może, ale nie powiedziałabym, że powinien, a tym bardziej, że musi. Warto zauważyć, że żadna ze znanych metodyk zarządzania projektami tego nie wymaga, wydaje się, że wymaga tego rynek, a właściwie niektóre firmy, bo “rynek” to za dużo powiedziane. Wymaganie doświadczenia technicznego to w moim odczuciu często próba zrekompensowania braków w innych obszarach. Ciężko bowiem znaleźć połączenie kompetencji menedżerskich, metodycznych z tymi technicznymi i wcale nie jestem pewna czy byłoby to połączenie idealne.

JD: Daleko nie musisz szukać, siedzę przed Tobą (śmiech).

KJ: No właśnie, stąd wiem, że nie jest to połączenie idealne (śmiech). Wiedza techniczna jest dużo łatwiej weryfikowalna np. podczas rozmowy kwalifikacyjnej niż umiejętność zarządzania projektami i kompetencje miękkie – ich weryfikacja wymaga czasu, stąd dużo łatwiej pokusić się o project managera technicznego jako takiego, którego wiedzy możemy być pewni. Odpowiadając jednak na pytanie, brak zaplecza technicznego nigdy nie będzie w niczym ograniczał project manager’a, który posiada umiejętność czerpania z potencjału zespołu, z jego wiedzy i doświadczenia, ma umiejętność zadawania pytań, przetworzenia zebranych informacji, bierze odpowiedzialność za podejmowane decyzje, ma zaufanie do zespołu. Nietechniczny project manager ma naprawdę ogromną motywację, aby budować partnerskie relacje z zespołem – to ogromny atut już na starcie. Praca zbudowana na takich fundamentach jest dużo bardziej efektywna. Jest w niej przestrzeń na autonomię, inicjatywę i odpowiedzialność zespołu. PM techniczny zawsze będzie miał zakusy, aby narzucać swoje zdanie lub ingerować w decyzje zespołu.

JD: Choć wolę się z Tobą nie zgadzać, w tej kwestii przynaję Ci rację, ale nadal nie rozumiem dlaczego uważasz, że jest to wada.

KJ: Nie tyle wada, co ryzyko dla samodzielności, samoorganizacji i samostanowienia zespołu. Częstym argumentem stojącym za zatrudnieniem osoby technicznej jest też przeświadczenie, że będzie jej łatwiej porozumieć się z zespołem. Czy ta „łatwość porozumienia” na płaszczyźnie technicznej jest warunkiem niezbędnym lub chociaż istotnym dla powodzenia projektu? Przede wszystkim brak umiejętności komunikacyjnych sam w sobie może być przeszkodą i wspólny mianownik, jakim jest wiedza techniczna tego nie zmieni. Warto jeszcze podkreślić fakt, że techniczny project manager najczęściej wywodzi się z programisty, który nie ma doświadczenia w zarządzaniu projektami, to raczej pewien kierunek w jego rozwoju, jedna z dostępnych ścieżek. Skupienie na zarządzaniu projektami, efektywności zespołu, świadomość siebie jako lidera czy znajomość dobrych praktyk i warsztatu pracy PM’a są tu znacznie mniejsze, choć oczywiście możliwe do nadrobienia. Powiedziałabym zatem, że jest to coś za coś – wiedza techniczna kosztem tej praktycznej, międzyludzkiej i metodycznej, pytanie jednak czy nie o nią w zarządzaniu projektami tak naprawdę chodzi?

JD: Przede wszystkim zakładasz, że jedno wyklucza drugie, a ja się z tym nie zgadzam. Wiedza techniczna konieczna nie jest, ale bądźmy szczerzy – pomaga. I to pomaga bardzo. Komunikujemy się z zespołem (technicznym), komunikujemy się z klientem, który też może być techniczny, choć oczywiście nie musi. Wszystko tak naprawdę zależy od tego, czego pracodawca od project managera będzie oczekiwał. Jeśli oczekuje diagramów UML, wiedzy o architekturze oraz umiejętności podjęcia decyzji odnośnie tego, której technologii użyjemy, to nietechniczny project manager polegnie. Wyobraźmy sobie, że budujemy swój dom. Czy zatrudnisz na kierownika budowy kogoś kto nie ma pojęcia o budownictwie? No właśnie…

I tu pojawia się kolejne pytanie – czy kierownik projektu ma znać się na projekcie, czy na zarządzaniu?

KJ: Znajomość projektu nie musi opierać się na aspektach technicznych. To również wiedza merytoryczna, funkcjonalna. Odwołujac się do przykładu Kuby – czy kierownik budowy używa młotka lub wylewa zaprawę, czy zatrudnia wykwalifikowanych ludzi, którym ufa? No właśnie. Kierownik projektu powinien znać się na projekcie i na zarządzaniu, co wcale nie oznacza, że musi być techniczny :)

JD: I tak, i nie. Tak naprawdę to, czy kierownik projektu ma się znać na projekcie czy na zarządzaniu zależy tylko od tego, czego oczekuje od niego pracodawca.

A co z autorytetem? Jak myślisz, zespół woli, aby na jego czele stał techniczny czy nietechniczy project manager?

KJ: Nigdy nie byłam członkiem zespołu projektowego w takim rozumieniu, że nigdy nie miałam project managera. Mogę jedynie spróbować przyjąć optykę zespołu i z tej perspektywy wydaje mi się, że zespół potrzebuje charyzmatycznego lidera i jasno ustalonych zasad, a czy to wymaga bycia technicznym? Przecież nie. Autorytet nie pochodzi tylko z doświadczenia technicznego, choć wiem, że takie doświadczenie imponuje deweloperom, ale może być też źródłem niezgody lub rywalizacji. Na przestrzeni lat pracowałam z wieloma zespołami, cały czas pozostając osobą nietechniczną. Nigdy nie czułam, aby wpływało to negatywnie na relacje z zespołem, a wręcz przeciwnie – za każdym razem czułam, że tworzymy zgraną drużynę. Jeśli poprzez autorytet rozumiemy siłę oddziaływania czy wpływania na zespół, bycie technicznym nie ma tu nic do rzeczy. O wiele bardziej trwałym wydaje mi się autorytet zbudowany na wierze i przekonaniu zespołu, że project manager umiejętnie kieruje projektem, jak również realizującym go zespołem, a wynikać to może z cech charakteru czy doświadczenia w wielu innych obszarach, zwłaszcza takich, w których zespół nie czuje się kompetentny, jak np. konfrontacja z klientem czy interesariuszami projektu, asertywność przynosząca korzyści dla zespołu, szeroko rozumiana ochrona zespołu i stworzenie poczucia bezpieczeństwa, którego zespół sam sobie nie zapewni. W koncepcji relacji międzyludzkich autorytet wynika z faktu posiadania cech przywódczych, wysokiej inteligencji emocjonalnej oraz charyzmy, co znów podkreśla, że autorytet to sprawa bardziej osobowości i wysoko rozwiniętych kompetencji miękkich, a nie tych twardych umiejętności.

JD: Uwielbiam ten soft-skillowy bełkot (śmiech). Czy szef zespołu sprzedażowego powinien mieć pojęcie o sprzedaży? Czy lider zespołu grafików powinien wiedzieć co to jest design? Pamiętam jak wyglądała moja praca, kiedy przewodził jej nietechniczny project manager. Momentami droga przez mękę. Ale może to dlatego, że ten konkretny NIETECHNICZNY project manager po prostu był bardzo słaby również na innych frontach. Co nie zmienia faktu, że wysłałem maila do osoby technicznej po stronie klienta, gdzie ustalałem kolor elementu formatki webowej. W formacie szesnastkowym #RGB. A potem przez pół dnia przekonywałem własnego PM’a, że mój komunikat do klienta był dla niego czytelny i że nie ma potrzeby dalszego wyjaśniania co to jest postać szesnastkowa RGB. Swojego PM’a nie przekonałem, co spowodowało tylko niepotrzebną kaskadę maili. Ja PM’owi nie ufałem, mi PM jak widać również. Wracając do autorytetu, był po prostu zerowy. Na własne życzenia PM’a. Konkluzja jest taka, że project manager powinien mieć doświadczenie techniczne.

KJ: Kuba, ten autorytet nie był zerowy ze wzgledu na brak wiedzy technicznej! Oddzielmy złych PM’ów od nietechnicznych. Oczywiście zdarza się zbiór wspólny, ale nie jest to regułą.

A czy brak kompetencji technicznych można obronić na rozmowie kwalifikacyjnej? Czy ich brak oznacza dyskwalifikację?

KJ: Przede wszystkim wcale nie generalizowałabym, że większość stanowisk pracy wymaga wiedzy technicznej.

JD: Jesteś pewna?

KJ: Owszem, pojawiają się takie ogłoszenia, ale należy mieć świadomość, że nie każdy profil kompetencyjny będzie odpowiadał naszemu, niezależnie czy różnicę stanowią kompetencje techniczne czy nie. Równie dobrze w wymaganiach może znaleźć się metodyka, w której nie czujemy się mocni lub język obcy, którego nie znamy. Musimy mieć świadomość, że nie każda kandydatura odpowiada wszystkim stanowiskom. Kiedy widzę w ogłoszeniu wymagania techniczne, po prostu wiem, że to nie mój profil. Równie dobrze może to dotyczyć znajomości ITIL (ang. Information Technology Infrastructure Library) czy koncpecji Lean (ang. Lean Management), w których nie jestem ekspertem, choć nie są to wymagania techniczne. Zamykam takie ogłoszenie i idę dalej. Również podczas rozmowy z rekruterami zaznaczam fakt, że nie jestem osobą techniczną właśnie po to, aby uniknąć niepotrzebnych nieporozumień czy pytań technicznych podczas rozmowy kwalifikacyjnej. Nie chcę, żeby ktoś miał wobec mnie takie oczekiwania, stawiam sprawę jasno. Często okazuje się, że firmy są w stanie „przeskoczyć” ten brak wiedzy technicznej lub, że nie jest ona jednak tak ważna, jak wynikało z ogłoszenia. To kwestia postawienia technicznych i nietechnicznych PM’ów na szali i wyważenia potrzeb. Kiedy pracodawca zdecyduje się na rozmowę pomimo braku zaplecza technicznego, myślę, że nietechniczny project manager obroni się sam swoimi dotychczasowymi osiągnięciami, komunikatywnością, wrażeniem jakie robi jego doświadczenie, charyzmą, pewnością siebie. To działa!

JD: Jeśli od początku kandydat na PM’a zaznacza, że takiego doświadczenie nie ma, a pracodawca jest pomimo to zainteresowany, to brak wiedzy technicznej nie powinien stanowić problemu. Gorzej jak się to pominie w opisie roli, a podczas rozmowy to wyjdzie – będzie to pretekstem do odrzucenia takiego kandydata. Po prostu trzeba przeczytać wymagania. Wszędzie tam, gdzie pracodawca tego wymaga, jest to mało realne do obronienia i wymaga naprawdę mocnych pozostałych kompetencji managerskich. Ale to gdybanie. Zadajmy sobie pytanie czego wymaga rynek.

Słuszna uwaga. Czy obecny rynek IT wymaga PM’ów technicznych?

KJ: To pracodawcy generują tę potrzebę. Czy jest ona słuszna? Mogłabym się odwołać do odpowiedzi na pytanie powyżej. Widzę raczej odwrotny trend – widzę rosnącą świadomość i rolę kompetencji miękkich, zwłaszcza wszędzie tam, gdzie odbywa się jakiekolwiek zarządzanie, wszędzie tam, gdzie są ludzie i całe zespoły. Ich znaczenie rośnie, bo rosną wymagania pracowników wobec tego jak chcą być zarządzani. Zmieniają się koncepcje motywacji, to, co działało 10 lat temu przestaje działać teraz. Rynek IT rządzi się jeszcze odrębnymi prawami. Do tego dochodzi coraz większa potrzeba rozwoju i świadomość tego, że tryb nakazowy, autorytarny jest już passe. Jeśli ktoś tego nie rozumie, nie wróżę mu kariery. Dzisiaj świat należy do mądrych liderów, mądrych to znaczy takich, którzy kulturę TELL (nakazową właśnie) zamieniają z powiedzeniem na kulturę ASK, czyli taką, która angażuje ludzi do działania. Liderzy nie boją się tego, czego nie wiedzą, pod warunkiem, że umieją tę wiedzę wydobyć z zespołu. Odchodzi się również od jednoosobowej odpowiedzialności project managera za rezultat końcowy, stawiając na jej miejsce odpowiedzialność zespołową i to właśnie doświadczony project manager to poczucie odpowiedzialności buduje. Koncepcja czerpania z potencjału zespołu, dania im pewnej niezależności i stworzenia warunków do rozwoju, inaczej mówiąc stymulowania ich rozwoju poprzez wyzwania, a także zintegrowania z celem, stworzenia poczucia, że jest się ważną częścią większej całości bliska jest teorii motywacji 3.0*. Do tego dochodzi zarządzanie zmianą, tak ważne w dynamicznie zmieniającym się otoczeniu, rozwiązywanie konfliktów, które są bardzo kosztowne dla projektów i całych organizacji, proaktywna postawa, przewidywanie zdarzeń i reagowanie na nie – to są moim zdaniem wymagania obecnego rynku pracy wobec project managerów. Jeszcze raz podkreślę – rośnie znaczenie kompetencji miękkich, o czym wspominałam też we wpisie “Project Manager – Superman na rynku pracy”.

JD: Tylko raz na kilka miałem rozmowę na stanowisko PM’a, gdzie nie miałem pytań technicznych (poległem!). W większości przypadków takie wymagania są wobec mnie stawiane, zapewne z uwagi na moją techniczną przeszłość. W praktyce w takich procesach rekrutacji takie wymagania oznaczają rozmowę techniczną, która często traktowana jest jako osobny etap. Oczywiście etap ten nie jest czymś, co jako jedyne ma wpływ na decyzję, ale jest etapem, którego można nie przejść i w rezultacie polec na całości. Pracodawca wymaga, aby osoba na stanowisku project managera miała doświadczenie techniczne. Zrobiłem mały eksperyment, który niekoniecznie musi być miarodajny, ale wszedłem na gowork.pl, jako poszukiwaną rolę wpisałem „project manager” oraz zawęziłem branże do „IT, programowanie, E-commerce”. Dostałem 13 rezultatów które dokładnie przeanalizowałem pod kątem wymagań stawianych przed kandydatem. Przyjąłem następujące kryteria: jeśli w wymaganiach pojawiło się chociaż jedno z następujących:

• doświadczenie w programowaniu,
• ukończone studia o profilu IT,
• znajomość języka programowania lub dowolnej technologii,

wówczas uznawałem, że pracodawca preferuje osoby z wiedzą techniczną.

KJ: Wyrzuciłabym z tej listy studia. Coraz częściej przekonuję się o tym, że nie mają na nic wpływu i tak naprawdę istotne jest doświadczenie. Ja jestem zupełnie skrajnym, ale dobrym przykładem – dziennikarz z wykształcenia.

JD: Masz rację, jesteś skrajnym przykładem (śmiech). Wszystkie inne wymagania, na przykład:

• znajomość metodyk zarządzania projektem,
• znajomość SDLC,
• wiedza biznesowa z konkretnej dziedziny,
• doświadczenie w prowadzeniu projektów IT,
• doświadczenie w kierowaniu zespołem,
• doświadczenie w komunikacji biznesowej z klientem i negocjacje,
• podstawowa wiedza lub doświadczenie z zakresu zapewnienia jakości oprogramowania,

dają pole do popisu osobie nietechnicznej, ale… wśród 13 ogłoszeń, tylko 5 dotyczyło project managerów bez wiedzy technicznej (przyjmując powyższe kryteria). Pozostałych 8 ogłoszeń wymagało wiedzy technicznej. Moja konkluzja jest więc taka, że w większości ofert pracy na stanowisko project managera w branży IT wiedza technicza jest wymagana. Osobnym pytaniem jest dlaczego takie wymagania są stawiane i czy można by się bez tego obejść. Według mnie, znowu – to zależy od konkretnych wymagań stawianych przez pracodawcę, czyli finalnie od zakresu obowiązków i tego czy project manager będzie miał ten komfort, aby skupić się na rzeczach istotnych, takich jak zapewnienie dowiezienia projektu szczęśliwie do końca, na czas, w przewidzianym zakresie, w budżecie i o dobrej jakości, czy też ugrzęźnie w detalach technicznych, pełniąc rolę architekta/programisty/supportowca/testera/analityka czy dowolnej innej roli, dla której wiedza techniczna jest po prostu niezbędna.

KJ: Cieszę się, że za rzeczy istotne w pracy project managera uważasz dowiezienie projektu, a nie brnięcie w szczegóły techniczne. Nie myślałam, że doczekam tej chwili (śmiech). I chyba przegapiłeś fakt, że dzisiaj dowiezienie projektu w ramach trójkąta projektowego przestało być rozumiane jako sukces projektu. Dzisiaj stawia się na dowiezienie wartości biznesowej, ale to temat na osobną rozmowę albo na osobny artykuł.

Czy techniczny project manager może być dobry w zakresie kompetencji miękkich, społecznych, interpersonalnych? Stereotypowy wizerunek programisty temu zaprzecza :)

KJ: Oczywiście, że może! To nie zawód determinuje nasze EQ, choć poniekąd inteligencja emocjonalna determinuje to, co robimy w życiu. Niemniej jednak jak w każdym zawodzie, również w tym, mamy przekrój osobowości. Spotkałam na swojej drodze osoby bardzo mocne techniczne, dla których naturalnym kierunkiem rozwoju był właśnie zawód project managera i to z uwagi na posiadane kompetencje przywódcze, zorientowanie na ludzi, zainteresowanie metodykami i całym cyklem życia projektu. Myślę, że ten stereotyp bierze się trochę z kontekstu, w jakim pracuje programista – najbliższy kontakt ma z kodem, nieraz godzinami, w oderwaniu od reszty zespołu, pisze kolejne linie oprogramowania. Ten świat pomiędzy programistą a jego komputerem jest bardzo hermetyczny, praca na tym stanowisku nie wymaga wielu interakcji, a komunikacja sprowadza się do przekazania lub otrzymania informacji. Oczywiście jest to duże uproszczenie i wszystko zależy od naszych własnych predyspozycji. Ja akurat miałam przyjemność pracować z zespołami, które bardzo często komunikowały się ze sobą, wymieniały pomysłami, analizowały możliwe rozwiązania. Czasem nawet miałam wrażenie, że więcej tam wymiany zdań niż linii kodu (śmiech).

JD: Znam wielu dobrych managerów po uczelniach technicznych. Znam też fatalnych, którzy to studiów technicznych nie mają. Znam też takich, którzy są fantastycznymi project managerami, nie mając wiedzy technicznej. Stereotyp jest tylko stereotypem. Nie sądzę, aby była zależność w którąkolwiek stronę w zakresie posiadania umiejętności miękkich i bazowym wykształceniem –  technicznym czy nie. Nie sądzisz, że jest to raczej kwestia wrodzonych predyspozycji? A te raczej nie będą zależały od odbytych studiów na uczelni technicznej czy tytułu „inż.” przed nazwiskiem. Podkreślam „inż.”, nie „mgr”. Kompetencje miękkie, jak każde kompetencje podlegają również procesowi uczenia się. Naprawdę, nie róbmy z osób po uczelniach technicznych bytów aspołecznych :) Ja mam tytuł „mgr inż.”, przez wiele lat byłem inżynierem programistą i – mam nadzieję – ograniczony społecznie nie jestem. Karolina, powiedz coś!

KJ: Hahaha! No dobra, nie jesteś! W przeciwnym wypadku nie byłoby nas tu teraz!

A jak ważne w pracy z klientem jest doświadczenie techniczne?

KJ: Tak ważne, jak techniczny jest klient. Jeśli klient jest osobą techniczną, to rzeczywiście często oczekuje, że project manager po drugiej stronie będzie partnerem do rozmów na tym samym poziomie. Nawet jeśli nie jest to zasadne, to ciężko klientowi oprzeć się pokusie wchodzenia na takie tematy. Nietechniczny project manager może mieć przez to większe trudności, aby zbudować dobrą relację i wzbudzić respekt. Ważne jest wówczas jego umocowanie wynikające z naprawdę dużego doświadczenia i dużych kompetencji w zarządzaniu projektami. To chyba najbardziej jaskrawy obszar, w którym może nastąpić starcie kompetencji twardych z miękkimi, jednak nadal nie tyle wierzę, co wiem, że nietechniczny project manager może zyskać przychylność klienta i wyjść z tego starcia na tarczy. Prawdę jednak jest, że kompetencje miękkie wciąż pozostają w tyle za tymi twardymi. Tak jak wspomniałam, ich wartość i znaczenie rosną, jednak nadal lepiej opłacane są umiejętności twarde i nadal to one wzbudzają większe uznanie.

JD: Odzywają się kompleksy? (śmiech)

KJ: O kompleksach pogadamy za parę lat! Pamiętajmy jednak, że o ile programista musi być techniczny, to project manager niekoniecznie. Koncentrujmy się zatem na tych kompetencjach, które dla danego zawodu są naprawdę ważne. Ważne to znaczy przynoszą największą efektywność.

JD: Czyli doświadczenie techniczne! Ono jest kluczowe, jeśli osoba, z którą komunikujemy się po stronie klienta jest techniczna. Prędzej czy później pojawią się aspekty techniczne projektu, nad którym pracujemy. Jeśli nie mamy technicznego doświadczenia, szybko możemy przez klienta zostać potraktowani jako wzorzec projektowy Proxy. No i znów to zrobiłem. Użyłem terminologii technicznej. Ale mi z tym dobrze.

*  *  *

Czuję, że nie znaleźliśmy jednoznacznej odpowiedzi na postawione we wstępie pytanie: “czy project manager powinien być techniczny?”, bo po prostu nie ma jednej odpowiedzi. Zawsze znajdą się zwolennicy jednej i drugiej teorii – tacy, którzy hołdować będą wiedzy technicznej jako kluczowej w zarządzaniu projektami, jak również Ci, którzy udowadniają, że wcale nie jest ona niezbędna, aby sprawnie zarządzać projektem. Mamy różne kompetencje i różne poglądy, z całą pewnością mamy też różnych “odbiorców” i potencjalnych pracodawców. Na rynku pracy znajdzie się więc miejsce dla jednych i drugich. Niemniej jednak, jeśli chcesz zrozumieć naturę projektów informatycznych, zagadnienia techniczne oraz enigmatyczny świat programistów zapraszam Cię na szkolenie  techniczne “(Nie-)Techniczny PM” w “Twoje Drzwi do IT”.

* Daniel H. Pink, „Drive. The Surprising Truth About What Motivates Us”

Książki polecane do tego artykułu: