Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

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

Adam Kukołowicz CTO / Bulldogjob
Sprawdź, z którymi typami Project Managerów IT pracuje się najgorzej, z punktu widzenia programisty.
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 artykuł o typach 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, aby była ona 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. Zadbanie o to, żeby komunikacja w zespole była jak najlepsza i by było jak najmniej nieporozumień wewnętrznych. Zapewnienie, by każde zadanie było zrozumiałe dla przypisanej do niego osoby. Poza tym, PM 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ę!

Programmer vs Project Manager

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, żeby spotkanie nie miało określonej agendy. A nawet jeśli ma, to należy szybko o niej zapomnieć. Każdy oczywiście powinien wnieść valuable input, w taki sposób, aby ze spotkania wynikało jak najmniej.

Problem tu jest taki, że tego typu spotkania angażują dużą liczbę osób, są nieefektywne i rozbijają dzień ludziom, którzy mają coś do zrobienia, według 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. Gadanie dla gadania nie pomaga i daje fałszywe wrażenie zaadresowania problemu.

 

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

Czasem zdarza się, że trafimy na PM-a, 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 się przedłuża. Tego typu komplikacje powodują 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 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 PM-a 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 tego 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 stereotypowy taksiarz - 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 aby 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, jeśli 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, aby 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’u.

 

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 nie ma czasu” - a po zdefiniowaniu na koniec okazuje się, że niestety wymaga to sporych zmian w aplikacji.

Czy “jakoś to będzie” jest faktycznie problemem? 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 zupełnie wyjątkowe 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. Taka osoba 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.

Zobacz więcej na Bulldogjob

Masz coś do powiedzenia?

Podziel się tym z 80 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog