7 typów PM-ów, z którymi nie chcesz pracować

Project Manager to osoba, która może sprawić, że projekt będzie przyjemny lub będzie drogą przez mękę. Lubię sobie czasem ponarzekać, więc to będzie lista typów PM-ów, z którymi pracuje się najgorzej z punktu widzenia programisty. Ostrzegam, że pomieszałem tutaj trochę klasyczną rolę PM-a z Product Ownerem i Analitykiem Biznesowym, a to z tego powodu, że o ile projekt czy wykonująca go firma nie jest duża, to często spotkamy się z przenikaniem tych ról i rzadko to będą inne osoby.

W założeniu Project Manager to osoba, która planuje pracę zespołu tak by była jak najbardziej efektywna. Składa się na to zaplanowanie zadań w taki sposób aby “zasoby” (programiści, designerzy, testerzy, admini) mieli jak najmniej przestojów. Dba o to, żeby komunikacja w zespole była jak najlepsza i by było jak najmniej nieporozumień wewnętrznych. Zapewnia by każde zadanie było zrozumiałe dla przypisanej do niego osoby. Poza tym pełni rolę pośrednika między teamem a klientem. Dzięki temu osoby, które rozwijają rozwiązanie nie muszą “co 5 minut” czytać i odpisywać na maile. A w praktyce? Różnie bywa. Tyle tytułem wstępu, zaczynam wyliczankę!

 

1. Zróbmy spotkanie!

Ok, czegoś nie wiadomo. Jakie są możliwości zdobycia wiedzy? Dla tego typu PM-a jest tylko jeden sposób - zróbmy spotkanie. Najlepiej angażujące cały team, albo też klienta. Ważne jest też, żeby spotkanie nie miało określonej agendy. A nawet jeśli ma, to ważne, żeby szybko o niej zapomnieć. Każdy oczywiście powinien wnieść “valuable input”, tak, aby ze spotkania wynikało jak najmniej.

Problem tu jest taki, że takie spotkania angażujące dużą liczbę osób są nieefektywne i rozbijają dzień ludziom, którzy mają coś do zrobienia wg wyznaczonego wcześniej terminarza. Chyba każdy z nas przeżył w swojej karierze kilkugodzinne spotkanie, po którym był zmęczony jak po dwóch dniach pracy. Dodatkowo u PMów, którzy nie widzą w czczej paplaninie nic złego codzienne standupy mogą się przerodzić w długie dyskusje, które nie powinny absorbować całego teamu. Wszystko jest kwestią priorytetów - gadanie dla gadania, dające fałszywe wrażenie zaadresowania problemu jest dużo mniej ważne od jego rozwiązania.

 

2. Źle robisz, weź tu zrób o tak

Czasem zdarza się, że trafimy na PMa, który myśli, że wie lepiej. Wie lepiej - bo uważa, że kariera programisty, którą zakończył kilka lat temu daje mu silne podstawy do “architektowania” i proponowania rozwiązań w obecnym projekcie; bo ogólnie jest inteligentny i tak dalej. Takie podejście szczególnie denerwuje, jeżeli mierzymy się z trudnymi problemami, w których rozwiązanie mocno się wciągamy. Tego typu komplikacje generują coś czego nie lubi żaden PM - obsuwy w projekcie. Nic więc dziwnego, że dobry PM stara się pomóc. Dlatego po pobieżnym zapoznaniu się problemem przychodzi do nas i objawia nam super rozwiązanie... które w tym przypadku nie zadziała.

Taka postawa może być przejawem ignorancji - mimo, że pewne podstawy są, to wiedza domenowa o konkretnym przypadku najczęściej jest niewystarczająca. PM może nawet nie wiedzieć czego nie wie (brzmi to mega dziwnie, ale w linku jest wyjaśnienie tego konceptu, polecam) o swoim projekcie, szczególnie, jeżeli ma wysokie mniemanie o swoich umiejętnościach technicznych. Cała sztuka polega w takich przypadkach na zręcznym dowiedzeniu się na czym polega problem i jak jest powiązany z resztą systemu. I przyznaję tutaj, że nie jest to łatwe. Czasami wystarczy, że stanie się gumową kaczką, czasami będzie musiał zadziałać bardziej proaktywnie.

 

3. No nie wiem, ale klienta też nie zapytam, bo trochę się boję

Project Manager powinien mieć odpowiedni zestaw cech do swojej pracy. Na ich liście jest komunikatywność jak i inicjatywa. Osoba, która jest na stanowisku PMa i panikuje w obliczu kontaktu ze zleceniodawcą może uprzykrzyć projekt. Najgorzej gdy jest to połączone ze strachem przed tym “co klient sobie pomyśli o moim pytaniu”. Trudno, jeżeli to co mamy zrobić nie jest jasne, to innego sposobu nie ma. Czasem trzeba zadać głupie pytanie.

Jeszcze pół biedy, jeżeli taka osoba jest kreatywna i stara się znaleźć obejścia na taką sytuację. Wtedy najwyżej jakieś zadanie poleży sobie w kolumnie “blocked” przez parę dni. Gorzej jak pomimo obejść nadal nie ma jasności i implementuje się rozwiązanie na podstawie niepełnych danych. Klient może przecież powiedzieć, że nie o to mu chodziło.

 

4. Jestem ekspertem, więc się wypowiem...

… na każdy temat. Mimo, że jest to zupełnie zbędne. I nikt tego nie lubi. I jest to szkodliwe, bo marnuje kupę czasu innych osób. Taki PM to mniej więcej jak stereotypowy taksiarz, co wie jak świat powinien działać i w każdej dziedzinie jest profesorem.

Dla projektu oznacza to przepalanie czasu na słuchanie managera i dłuższe spotkania. Być może także konflikty, jeżeli trafi się w zespole ktoś, kto nie lubi tego typu gadki. W ekstremalnych przypadkach dochodzi do tego, że PM poucza klienta jak powinno być. To kolejny przejaw ignorancji i nie świadczy dobrze o osobie, która tak funkcjonuje. Co zamiast tego? Rozmawianie z teamem tak by odnaleźć w nim osoby, które faktycznie znają się na danej dziedzinie. Dzięki temu gdy przyjdzie konieczność na poznanie zdania eksperta, to łatwiej będzie go znaleźć lub przyznać, że nie ma się w zespole takiej wiedzy.

 

5. Agile lekiem na całe zło

Co jeżeli projekt nie idzie dobrze? Prawdopodobnie jest za mało agile. Będzie dużo lepiej jak zrobimy spotkanie z planning pokerem, będą daily scrum meetingi, potem oczywiście demo i retro. Tylko kurcze jakoś tak wyszło, że na demo było średnio co pokazać, na retro te same przeszkody co w poprzednim sprincie i burndown chart też jakoś super okazale nie wygląda.

Oczywiście, że stosowanie metodyk agile może pomóc! O ile tylko ma się zrozumienie jak i dlaczego one mają działać, jakie warunki muszą być spełnione, żeby działały dobrze. Zostały one stworzone by wspomóc proces rozwoju projektu, a nie po to by team mógł sobie pochodzić na jakieś spotkania z wymyślnymi nazwami. To dokładnie ten przypadek, o którym mowa w Piśmie Świętym: “To szabat został ustanowiony dla człowieka, a nie człowiek dla szabatu.”. W naszym przypadku też trudno się nie zgodzić, że to agile jest dla teamu a nie team dla agile’a.

 

6. Jakoś to będzie

“Dobra… trochę działa, trochę nie, ale spoko. Zostawmy to na później, bo jakoś to będzie” - po czym temat umyka, ląduje na produkcji i wraca jako bug po paru miesiącach.

“No w tym tasku to nie wiemy, ale lecimy z założeniem, że to będzie o tak o… jakoś to będzie” - nie trudno zgadnąć, potem jest trooochę inaczej.

“Tam potem będą jeszcze jakieś tematy, ale to sobie je zdefiniujemy na sam koniec, bo teraz to mi się nie chce” - a po zdefiniowaniu na koniec okazuje się, że niestety wymaga to sporych zmian w aplikacji.

Czy “jakoś to będzie” jest faktycznie problemem? Tak, jeżeli wynika ze szczegółów. Nie będzie raczej problemem, jeżeli brany jest pod uwagę tzw. “big picture”. Tak więc jeżeli coś jest kluczowe dla projektu, to musi być dopięte na ostatni guzik, jeżeli nie jest, to faktycznie można czasem powiedzieć, że jakoś to będzie - szczególnie pod presją czasu. O ile w krótkim okresie czasu wyluzowane podejście będzie ok, to przy dłuższym developmencie może sprawić, że te same problemy będą powracać wielokrotnie. A tego nie lubię, wrr.

 

7. Ma być ASAP as possible!!!1111jeden

“Słuchaj X właśnie gadałem z klientem, w zasadzie nie określił na 100% czego konkretnie chce, ale chce tego bardzo, tak więc rzucaj cokolwiek robisz i jedziemy z tematem. No i wiesz - najlepiej jak będą już jakieś efekty jak zadzwoni drugi raz. BTW... masz jakieś plany na wieczór?”

Jeżeli wszystko ma najwyższy priorytet to nic nie jest bardzo ważne. Jeżeli wszystko ma być “na wczoraj” to pewnie nigdy nie zostanie zrobione tak jak trzeba. Tak właśnie wygląda praca z “człowiekiem asapem” - wcale nie tak bardzo ważne tematy, które trzeba zrobić jak najszybciej w zasadzie nie wiadomo po co. Od znajomego słyszałem o firmie, gdzie bardzo wielu PM-ów tak funkcjonuje. Ciągle wymyślają zadania “o najwyższym priorytecie”, bardzo często wpychając się do wcześniej ustalonego sprintu (taki agile, ha!). Najśmieszniejsze w tej zabawie jest to, że naprawdę często programista dobrze zrobi, jeżeli zupełnie zignoruje takie żądanie. Po paru dniach na omówieniu sprintu okazuje się, że albo ten task zupełnie nie był potrzebny, albo - co jeszcze bardziej kuriozalne - PM-ASAP nie kojarzy o co tak naprawdę chodziło. Tak więc ASAP może lepiej zachować na sytuacje bardzo nietypowe (produkcja leży albo jakaś bardzo dobra okazja do zrobienia biznesu) i sumiennie pracować, by było ich jak najmniej.

 

Na zakończenie chciałem powiedzieć, że sam cieszę się, że mamy Project Managerów. Komunikacja z klientem to coś co by przerosło bardzo wiele technicznych osób. Znajomi, którzy pracowali jako programiści bezpośrednio ze zleceniodawcą nie chwalą tego rozwiązania. Bycie dobrym PM-em, który nie zalicza wpadek jak te opisane powyżej jest trudne. Wymaga doświadczenia, rozsądku, komunikatywności i empatii, nie mówiąc już o rozeznaniu technicznym, które też jest bardzo ważne. Musi rozważnie balansować między wspomaganiem swojego teamu, a wymaganiem od jego członków. Stąd nie dziwi, że dobry PM jest na wagę złota.