Menedżerowie projektów są potrzebni, bez nich praca byłaby trudna, a często wręcz niemożliwa. Jednak i negatywnych przykładów, o których dziś opowiemy, są dość dużo.
„Antybohaterzy” tego artykułu to nie konkretne osoby, ale zbiorowe obrazy, ucieleśnienia destrukcyjnych wzorców zachowań niektórych Project Managerów. Możliwe, że nawet kilku antybohaterów z tego artykułu przypomni ci twojego PM-a, a jeśli masz szczęście, usłyszysz o tym po raz pierwszy. Oczywiście, wszystkie postacie są fikcyjne, a zbiegi okoliczności są przypadkowe.
1. Meeting-man
Wysłałem Ci zaproszenie na meeting dziś o 16, jutro o 17 i w piątek po obiedzie!
Meeting-man — menedżer, życie którego kręci się wokół meetingów. Kiedyś przeczytał on, że spotkania pomagają zespołowi pracować bardziej efektywnie i uczynił
z tego zalecenia absolutną konieczność.
Z takim menedżerem po prostu nie ma czasu na pracę. Codziennie co najmniej kilka godzin spędza się na różnego rodzaju meetingach, w których uczestniczy cały zespół, choć tak naprawdę potrzebne są 1-2 osoby. Meeting-man uważa, że jego obowiązkiem jest wysłanie zaproszeń do wszystkich członków zespołu, zebranie ich w sali konferencyjnej i rozpoczęcie rozmowy z każdym z osobna.
Pracowałem kiedyś z taką osobą i powody do spotkań były czasem po prostu absurdalne.
Zbieramy się rano, omawiamy przy stoliku zadania na dany dzień, pijemy kawę, rozmawiamy, siadamy do pracy, a godzinę lub dwie później dostajemy zaproszenie na meeting. Na meetingu pytają: „No i co udało Ci zrobić? A co przeszkadzało Ci zrobić więcej? Może potrzebujesz czegoś od swoich kolegów?” W takim przypadku chce się powiedzieć: „No jak będzie trzeba, to podejdę do kogoś i poproszę!” Jeśli zespół liczy 5+ osób i każdej z nich zadaje takie pytania, to już zabiera półtorej godziny czasu, który można byłoby poświęcić na programowanie i rozpracowanie.
Zdarza się, że ktoś pracuje zdalnie ze względu na stan zdrowia. Nawet gdyby
w tej chwili nie było żadnych pytań do kolegi i jego obecność na meetingu byłaby niepotrzebna, taki menedżer i tak zadzwoniłby do tej osoby, prosiłby wejść na Skype’a
i włączyć kamerę: „Żebyśmy mogli Cię zobaczyć!”. Wydaje się to nieco dziwne, ale to jest cechą Meeting-mana – martwego z grobu dostanie i doda go do call’a.
Jeszcze jeden wyjątkowy talent Meeting-mana — nie przerywa dialogu dwóch programistów, którzy postanowili zagłębić się w swoje problemy podczas spotkania zespołu. Kolejne wydłużenie meetingu – hurra! Więcej meetingów, więcej!
2. Incognito
Wystarczy trochę przeczekać i problemy rozwiążą się same.
Szczerze mówiąc, menedżer nie zawsze jest szczególnie zaangażowany w procesy. Czasem komunikacja odbywa się bezpośrednio według schematu „programista-klient”. Incognito pojawia się dopiero wtedy, gdy powstałe problemy zostaną rozwiązane bez jego udziału, bo nie uczestniczył w projekcie lub ping trwał wiecznie.
Pracowałem nad projektami, w których menedżer pojawiał się i znikał. Zwykle wygląda to tak: przedstawiają Cię klientowi i menedżerowi, pokazują wszystkie narzędzia, dają dostęp, wszystko jest w porządku. Po rozpoczęciu pracy zdajesz sobie sprawę, że klient zazwyczaj pisze bezpośrednio do Ciebie. Jeśli musisz o coś zapytać, zwracasz się do klienta, bo PM obowiązkowo zapada się pod ziemię na trzy godziny, a kiedy się pojawia, kwestia już jest rozwiązana, bo omówiłeś wszystko z klientem.
Fenomen takiego menedżera ujawnia się dopiero wtedy, gdy coś nie idzie zgodnie z planem – często z powodu jego własnej bezczynności. W tym przypadku Incognito zastanawia się również, dlaczego nikt wcześniej nie zasięgnął jego opinii. “Może dlatego, że praca stoi, z Tobą nie można się skontaktować, a coś trzeba robić!” Kiedy pozna się takich menedżerów jak Incognito, pojawia się pytanie: po co w ogóle są potrzebni, skoro można wyznaczyć lidera i wszystko poszłoby sprawniej?
3. Wielki-niewiedzący
A co to takiego Acceptance Criteria? Już nawet formularza logowania nie możesz zrobić?
Jest to menedżer, który nie wie, jak prawidłowo formułować zadania i jakie są kryteria ich oceny. Przez sformułowanie zadania rozumiemy utworzenie zadania w systemie Jira (lub innym systemie kontroli zadań) i odpowiednie go opisanie.
Prawie każdy programista spotkał się z zadaniem, które składa się z jednej frazy,
np. „implement login”. Patrzycie na tę frazę i nie rozumiecie, co w ogóle trzeba zrobić! Czy menedżer miał na myśli frontend, backend czy ogólnie design? Praca nad takimi zadaniami to wróżenie z kryształowej kuli.
Niestety, Wielcy-niewiedzący są dość powszechni. Aby programiści nie wpadali w osłupienie, gdy widzą zadanie, istnieją sprawdzone metody, takie jak definiowanie Acceptance Criteria i Definition of Done.
Można powiedzieć, że DoD to ogólne wymagania jakościowe, a nie obowiązek menedżera, ale mimo to PM powinien zadbać o to, aby lista DoD była przynajmniej dołączona do zadania i sformalizowana, a programista po prostu o niej nie zapomniał. Jeśli listy DoD nie ma, PM powinien zająć się jej organizacją lub przynajmniej wyznaczyć doświadczonego programistę, aby to zrobił. Tak czy inaczej, DoD musi być częścią projektu, w przeciwnym przypadku trudno będzie pracować.
4. Nerd-man
Tak będzie, bo tak jest napisane w przewodniku!
Ten tytuł przypada menedżerom, dla których metodyka jest całym światem i traktują ją jak religię. Najlepszym sposobem na zrozumienie, kim jest Nerd-man, jest wysłuchanie prawdziwej historii moich kolegów.
Jest pewien projekt, dość duża aplikacja mobilna (liczba użytkowników liczona
w setkach tysięcy). Rozpracowanie odbywa się zgodnie z zasadami Scrum: standardowe dwutygodniowe sprinty, planowanie, szacowanie – wszystko tak, jak powinno być..
Nagle, w środku sprintu, psuje się login. Klient przybiega do menedżera: „Mam 100K użytkowników i nikt nie może się zalogować, co mam zrobić? Błagam, chłopaki, naprawcie to!”. Menedżer: „Ale my mamy scrum! Wszystko jest zaplanowane, nie możemy tak po prostu naprawić logowania! Jeśli chcesz, żebyśmy to naprawili, usiądźmy najpierw, przejrzyjmy backlog, wybierzmy zadanie do usunięcia z tego sprintu, a na jego miejsce wprowadźmy zadanie związane z naprawą loginu”
Klient jest zszokowany, ponieważ nie rozumie, dlaczego zamiast usiąść teraz
i rozwiązać problem, który powoduje, że firma traci pieniądze, ma tracić czas na zabawę ze Scrum’em.
Wniosek: nie należy bezdyskusyjnie i rygorystycznie przestrzegać wszystkich założeń jednej metodyki jako reguł (zwłaszcza jeśli rozumie się je zbyt dosłownie). Każda metodyka powinna uwzględniać sytuacje, w których coś pójdzie nie tak i trzeba będzie podjąć szybką decyzję.
5. Estimate-man
A oceniłeś ten task? A ten? A jeśli znajdę task bez oceny?
Rodzaj Nerd-mana. Taki menedżer prosi o oszacowanie każdego kichnięcia i bardzo boleśnie reaguje na wszelkie odchylenia od pierwotnych szacunków.
Najczęściej spotyka się ich przy projektach o sztywnych stawkach godzinowych, gdzie każdy ruch musi być oceniony, ponieważ za ten czas jest później wystawiane rozliczenie. Problem polega jednak na tym, że proces rozpracowania projektu (zwłaszcza dużego i złożonego) jest trudny do przewidzenia, gdy w każdym zespole jest N programistów (co najmniej pięciu frontendowców, pięciu backendowców i kilku designerów).
Aby programista mógł odpowiednio ocenić zadanie, musi dobrze znać projekt, a także mieć doświadczenie we wdrażaniu podobnej funkcjonalności w przeszłości, a nawet
w takiej sytuacji trudno jest uwzględnić np. aktualizację bibliotek czy problemy
z integracją API.
Jeśli znajdziesz się w sytuacji, w której terminy gonią, a deploy jest przerwany – często zamiast stosować techniki, metody i podejścia, po prostu musisz działać. Kiedy w takiej sytuacji Estimate-man zaczyna naciskać, żądając konkretnej estymacji, na tym gruncie powstają konflikty.
Co należy zrobić: podać widełki minimum-maksimum. Jeśli chodzi o mniej lub bardziej obszerne zadanie, można przydzielić podzadanie do researchu. Zazwyczaj czas
i pieniądze przeznacza się na research, gdy planuje się realizację jakiejś nowej, nietrywialnej funkcjonalności i trzeba zrozumieć, jakie narzędzia już się posiada, co do nich pasuje, a co nie. Możliwe, że nic nie będzie Ci odpowiadać i będziesz musiał napisać własne narzędzie od podstaw.
6. A zróbmy tak-man
Słuchaj się PM-a, on prawdę Ci powie!
Programiści to dumne istoty. Nikt nie lubi, gdy im się mówi, co i jak mają robić, a tym bardziej, jakich technologii i frameworków używać. Programista może wysłuchać opinii innego, bardziej doświadczonego kolegi, ale nie menedżera projektu, który sam nie wie, o czym mówi.
Na własnej skórze doświadczyłem przyjemności pracy z taką osobą. Byłem wtedy nowy w zespole i wykonywałem jeden z moich pierwszych tasków. Menedżer przyszedł do mnie
i poprosił, żebym pokazał konkretnie w kodzie, co zrobiłem. Pokazałem kod
i wyjaśniłem, że muszę stworzyć kolejną tabelę w bazie danych, aby przechowywać tę nową encję. On zapytał: „A dlaczego zrobiłeś nową tabelę? Przecież mamy inną”. Odpowiedziałem, że ta tabela nie pasuje, bo te dane się różnią. Menedżer upierał się, że są to te same modele. Kłóciliśmy się przez pół godziny, aż w końcu przekonałem go, że jest inaczej. Dlaczego zmarnowałem czas na tę kłótnię? – to pozostaje tajemnicą.
Mój znajomy miał sytuację, w której przez sześć miesięcy pisał CRM w Angularze,
a w projekcie pojawiły się pewne problemy, które menedżer planował rozwiązać, przepisując cały projekt na Vue po sześciu miesiącach rozpracowania! Jak to miało rozwiązać problem — nie wiadomo, ale zespół był „zachwycony”.
Menedżer ma prawo polecić stack technologiczny na podstawie swoich wcześniejszych doświadczeń, ale nie należy zapominać, że jego głos powinien być przemyślany,
a ostateczną decyzję o tym, jakich technologii użyć, pozostawia się zespołowi. Można tu wprowadzić drobną poprawkę, jeśli w zespole są sami juniorzy, a PM ma dobre doświadczenie techniczne – w takim przypadku zespół powinien słuchać opinii menedżera.
Moi koledzy mieli doświadczenie z takim menedżerem. Programiści stanęli przed wyborem, w jaki sposób rozwijać projekt napisany w starym Angularze. Przyszedł nowy PM, który miał wcześniejsze doświadczenie w pracy z zespołem używającym Vue, więc zaproponował: „Słuchajcie, w naszym ostatnim zespole Vue działał całkiem dobrze. Może my też spróbujemy?”. Komunikacja odbywała się w sposób przyjazny, nie narzucał swojego zdania. Programiści zastanowili się nad tym, wypróbowali to rozwiązanie
i zdecydowali się kontynuować projekt w Vue.
7. Nieudolny jira-man
Zrobię Wam pajęczynę z tasków, ale bez dependencies.
Prawie w każdym projekcie używa się jakiegoś trackera tasków (Jira, Trello), który pozwala budować flow programowania, testowania i rozliczania zadań.
Tracker Jira-mana to jedna wielka księga zadań do zrobienia. Nie są one poukładane: nie ma filtrów, kategorii — nic. Po prostu próbujesz się do czegoś dokopać w tej górze… tasków.
Menedżer po prostu komplikuje pracę programistów i swoimi nieudolnymi działaniami opóźnia datę wdrożenia. Problem ten można rozwiązać, rozumiejąc zasady działania task-trackera i rozmawiając z zespołem o formacie, w jakim wygodniej byłoby im odbierać zadania, tak aby nie poświęcali dodatkowego czasu na ich interpretację
i rozszyfrowywanie.
8. Tak, oczywiście-man
A na co komu zdrowy rozsądek? Mój zespół pracuje tylko w imię klienta!
Myślę, że każdy przynajmniej raz w życiu zetknął się z menedżerem, który zawsze staje po stronie klienta. Zgadza się na każdą prośbę bez konsultacji z programistami na temat tego, na ile prośba jest adekwatna, czy może być zrealizowana i jak pracochłonna jest jej realizacja.
Prędzej czy później klient steruje nim jak marionetką. Jeśli traficie na takiego menedżera – szukajcie innego projektu. Problem ten można rozwiązać, planując zadania z jak największą liczbą szczegółów.
9. Task-man
Nie wiem, o jakich 3 miesiącach mówili nasi konkurenci, ale mój zespół zrobi wszystko w 2 tygodnie!
Menedżer, który nie potrafi oszacować złożoności zadania i czasu potrzebnego do jego wykonania, a dodatkowo nierównomiernie rozdziela zadania w zespole.
W idealnym świecie w estymacje powinni być zaangażowani zarówno menedżerowie, jak i programiści. Są jednak tacy PM, którzy uważają się za wystarczająco kompetentnych, aby samodzielnie wykonywać szacunki. Do tej kategorii należą osoby, które już wcześniej były programistami, być może przez bardzo krótki czas, ale są przekonane, że wiedzą już ile czasu zajmie im każde zadanie. Z jednej strony dziękujemy – żaden programista nie chce estymować, a kiedy menedżer naprawdę rozumie temat i podejmuje to zadanie, jesteśmy mu bardzo wdzięczni.
Jeśli jednak menedżer nie jest takim ekspertem, jak mu się wydaje i szacuje zadanie zbyt optymistycznie, zespół może mieć problemy. Inną wadą błędnej oceny zadań jest ich nierównomierny podział w zespole. W rezultacie jedna część grupy nie wyrabia,
a druga wychodzi z pracy dwie godziny wcześniej.
10. Dodo-man
Ale jak to, na stanowisku PM-a trzeba jeszcze coś robić? Myślałem, że wszystko robią programiści.
Pracowałem kiedyś w firmie, która prowadziła własną działalność offline, powiedzmy
w firmie produkującej pantofle. W pewnym momencie postanawiają stworzyć dział IT. Skoro jest już dział — potrzebny też PM. Dyrekcja drapie się po głowie i postanawia mianować na to stanowisko Andrzeja, który wcześniej był szefem firmy Sp. z o.o. „Rogi i kopyta”.
Andrzej o kierowaniu projektu nie ma zielonego pojęcia. Nie dlatego, że jest złym człowiekiem, ale dlatego, że nie zna się na IT i nie wie jak sobie z tym radzić. I tak „pracowaliśmy” aż do momentu, kiedy miałem dość tego, że ten człowiek nie rozumie, gdzie jest, co tu robi i właściwie przeszkadza nam w pracy. Wypisałem na kartce listę punktów, na podstawie których przyjmujemy zadania, położyłem ją na biurku Andrzeja
i wyszedłem. Następnie przeprowadziliśmy z nim krótką rozmowę, aby wyjaśnić zawartość naszego liściku. Na szczęście Andrzej zrozumiał, że nie zna się na programowaniu i po rozmowie zdecydował się skorzystać z listy. Jednak tacy „menedżerowie” są bardzo demotywujący… chociaż motywują do odejścia z pracy.
11. Excel-man
Niech żyje bezpośrednia komunikacja! Podchodźcie i meldujcie o każdym zadaniu osobiście!
Historię tę opowiedział mi mój znajomy, który pracował w dość dużej firmie z własnym wewnętrznym działem IT. Programiści tworzyli sklep internetowy dla firmy, wewnętrzne CRM-ki i inne oprogramowania ułatwiające sprzedaż i dystrybucję towarów.
W ich zespole był PM, który z powodu pewnych przekonań nie mógł korzystać z Jiry, Trello i innych task-trackerów. Stworzył plik Excel z harmonogramem zadań
i wykonawców. Zamiast przenieść zadanie do kolumny „In Progress” w Jirze, trzeba było iść do menedżera i poprosić go o wprowadzenie zmian w tabeli.
Jak pewnie rozumiecie, taki proces był wygodny jedynie dla menedżera, który tylko rzucił okiem na Excel, aby zrozumieć sytuację w projekcie. Z punktu widzenia zespołu było to niezwykle frustrujące.
12. Kopiuj wklej-man
Po prostu chcę, żebyście nadawali z klientem na tych samych falach.
Menedżer nie zawraca sobie głowy opisem story/tasków. Po prostu kopiuje tekst od klienta z wiadomości e-mail/messengera i wkleja go do opisu w Jirze. Przecież programiści sami sobie z tym poradzą.
Jedną z ról menedżera jest wysłuchanie klienta i przetłumaczenie tego co usłyszał na język zrozumiały dla programistów, a menedżer ten nie sprawdza tekstu pod kątem jasności, wykonalności i sensowności. Również w tym przypadku brak jakichkolwiek Acceptance Criteria.
13. Control freak
Chcę wiedzieć o każdej minucie twojego życia w firmie!
W przeciwieństwie do Estimate-mana, ten ma obsesje na punkcie tego, ile czasu marnuje programista.
Spotkałem się kiedyś z menedżerem, który poprosił o rejestrowanie czasu poświęconego na przegląd kodu w osobnym zadaniu. Z jednej strony jest to jasne. Z drugiej strony nie chcę mi się śledzić, ile czasu poświęciłem na przegląd kodu i na samo zadanie, i umieszczać tego wszystkiego w różnych ticketach. Nie jest to wcale zachęcające.
Innym „super” przykładem jest sytuacja, kiedy zespół pracował przez tydzień, a w piątek trackowali cztery godziny czasu pracy w specjalnej zakładce, która tak właśnie się nazywała: „Tracking”.
Oczywiście, menedżer powinien kontrolować pracę nad projektem, ale nie trzeba być wielkim władcą. Wyjaśnij zespołowi przyczyny, przez które musisz rozliczać się z klientem z każdej sekundy pracy nad projektem (po to przecież zatrudniasz ludzi, prawda?),
i wspólnie wypracujcie odpowiednie rozwiązanie, z którego wszyscy będą zadowoleni.
14. Bo tak-man
Po co wyjaśniać zespołowi, dlaczego zatrudniliśmy akurat tego pracownika?
Sytuacja, w której po rozmowie kwalifikacyjnej i uzyskaniu informacji zwrotnej menedżer odrzuca kandydata, który jest mniej odpowiedni na dane stanowisko, ponieważ…, bo tak.
Realny case: firma przeprowadziła rozmowy kwalifikacyjne z siedmiu kandydatami. W rezultacie programiści przedstawiają swojego kandydata, który ich zdaniem najlepiej nadaje się na to stanowisko. W pewnym momencie kierownik z niewiadomego powodu (budżet/dialog z klientem/intuicja) sugeruje, żeby wybrać kogoś innego. Dlaczego? Bo tak!
Pozostaje pytanie – “Czym kierował się menedżer, podejmując taką decyzję?”. Koniec końców kandydat PM-a poniósł porażkę, ponieważ po prostu nie był w stanie podołać takiemu poziomowi zadań. Musieliśmy szukać dalej.
Jeśli istnieją obiektywne powody: „Mamy ograniczony budżet, musimy wziąć kogokolwiek” – to w porządku. “Co przeszkadza w powiedzeniu tego zespołowi? – oto jest pytanie.
Spotkałem się też z inną, bardzo specyficzną sytuacją, gdy główny programista odchodził z projektu i bardzo długo nie mogli znaleźć nikogo na zastępstwo. Kiedy głównemu programistu pozostało kilka dni pracy, pojawił się kandydat, który generalnie pasował do tej roli. Nie był idealny, ale pasował i nie było innych. Menedżer miał bardzo napięty grafik, do zrealizowania było wiele funkcji, a nie mógł sobie pozwolić na to, by siedzieć bez programisty. W tym przypadku menedżer słusznie nalegał na zastępstwo
i wszyscy go zrozumieli.
Podsumowując
Profesjonalizm bardzo się ceni: zarówno ze strony programistów (pozdrawiam nieudolne estymaty, po których za overtime dostajesz bezcenne doświadczenie zamiast pieniędzy za nadgodziny), jak i po stronie kierownictwa. Na każdego dobrego specjalistę przypada kilku antybohaterów, którzy „poświęcili swoje życie scrum guide’owi” i wydaje im się, że wszystko robią dobrze… W rzeczywistości jednak okazują się oni globalną katastrofą dla zespołu. Ten artykuł jest próbą pokazania, jak programiści czują się
w obliczu niektórych dziwnych decyzji menedżera. Zachęcamy do konstruktywnego dialogu w komentarzach.
Autor artykułu:
Mary Rotar, Co-fouder IAMPM