Junior Project Manager to jedno z najbardziej kontrowersyjnych stanowisk w IT. Uważa się, że jeśli stawiasz osobę na czele projektu, to musi to być doświadczony menedżer, który wspiął się po drabinie z Middle do Senior Developera i doskonale orientuje się w technicznych osobliwościach. Tyle, że programiści to częściej introwertycy niż ekstrawertycy, a gdy w zespole jest ich 10, ktoś musi wysłuchać wszystkich i podjąć rozsądną decyzję. No i do tego programiści wolą awansować na teamleaderów i CTO niż PMów.
Co do wiedzy technicznej — tu się zgadzamy, mamy nawet osobny kurs, który został wymyślony po to, żeby PM mógł się porozumieć z programistą bez dodatkowych pytań wyjaśniających, ale poza tym zakładanie, że osoba bez doświadczenia w IT nie może zostać menedżerem jest błędne. Po prostu zawsze na nowicjuszy czekają błędy i tak jest w każdym zawodzie.
Na nasz kurs DAO PM przychodzą osoby z różnym backgroundem, a potem znajdują swoja pierwszą pracę… Popełniają błędy i się na nich uczą. Na potrzeby tego artykułu poprosiliśmy przyjaciół z IAMPM, obecnie menedżerów projektów z doświadczeniem, aby opowiedzieli nam o swoich pomyłkach na stanowisku Junior PM.
Najodważniejsi PM nie krępowali się otworzyć przed nami swojej szafy z trupami. A my posegregowaliśmy ich kości i skategoryzowaliśmy je, aby były ciekawe i pouczające. Od razu ostrzegamy: wpadki nie zawsze są czymś zabawnym, ale nie jesteśmy tu tylko dla zabawy.
Część 1. Wpadki przy pracy z klientami
Klienci — też ludzie, bez względu na to, co ktoś o nich mówi. A ludzie są różni: ufni i podejrzliwi, sprawiedliwi i stronniczy, hojni i nie do końca. No i są też klienci o specyficznych wymaganiach, które przekraczają granicę dobra i zła. To właśnie taka postać otwiera naszą listę wyzwań dla Junior PM-a.
Historia 1. Kiedy nic nie zależy od PM-a
Teraz nasza bohaterka od dawna z powodzeniem pracuje w IT, ale na samym początku swojej kariery zetknęła się z wyjątkowym klientem, który odmówił współpracy nie dlatego, że nie miała wystarczającego doświadczenia w zarządzaniu projektami, ale po prostu dlatego, że była dziewczyną. I tu można by powiedzieć, że to wszystko wina mężczyzn, gdyby nie jeden mały niuans: sama klientka była panią z Singapuru.
Wniosek: jeśli chodzi o rynek IT, ageizm i dyskryminacja ze względu na płeć mają miejsce (niezależnie od tego, jak bardzo wszyscy mówią o tolerancji). Daj sobie z tym spokój.
Z drugiej strony, lepiej od razu postawić krzyżyk na współpracy niż pracować z klientem z kolejnej historii.
Historia 2. Pouczająca
Za czasów Junior PM jeden z naszych znajomych zgubił maila z zapewnieniem klienta, że trzeba zrobić miesięczną przeróbkę. Klient okazał się twardym biznesmenem, więc po miesiącu pracy nad projektem zaczął wszystko odrzucać.
Wniosek: zapisujcie wszelkie westchnienia klienta, które dotyczą strony finansowej, a także zmiany i uściślenia wymagań. Czasami warto prowadzić pokładowy dziennik projektu, w którym można szybko znaleźć informacje o ważnych zmianach, a także dołączyć zrzuty ekranu z korespondencji lub linki. Przy okazji dyktafon i nagrywanie rozmów wideo to również świetne narzędzia w walce o sprawiedliwość. Tylko uprzedź klienta, że robisz to z wyprzedzeniem, a nie po fakcie.
Nie wszyscy klienci są źli. Czasami po prostu nie potrafią wyartykułować swoich myśli na temat wizji produktu końcowego. O tym właśnie mówi nam trzecie studium przypadku.
Historia 3. Kiedy PM musi pełnić rolę analityka biznesowego
Ta historia opowiada o dzielnym PM, który poprowadził zespół programistów w ich chwalebnej walce o zaprojektowanie serwisu finansowego. Klient chciał, aby produkt miał wszystko (lub prawie wszystko). W tym celu, w miarę realizacji funkcjonalności, wymyślał ulepszenia i prosił o ich wdrożenie.
— A może dodamy moduł księgowy? — klient wygenerował nowy pomysł.
— Pewnie! — PM zaczął już rozkładać zadanie na kamienie milowe.
Gdy tylko dodano moduł księgowy, klient pospieszył z nową prośbą:
— Chcę mieć moduł do obliczania KPI dla pracowników firmy!
— Wiem, komu to powierzyć! — odważnemu PM spodobało się takie podejście, zrozumiałe zadania, wszystko jasne i do rzeczy.
Z modułu na moduł obaj rozumieli się coraz lepiej, aż pewnego dnia klient uznał, że świat jest gotowy, aby zobaczyć jego małe arcydzieło ze świata produktów finansowych. W tym właśnie momencie projekt zetknął się z realiami rynku: nikt nie chciał kupić takiego rozwiązania. Produkt robił wiele, ale nie rozwiązywał problemów potencjalnych użytkowników. W efekcie rozwiązanie umarło, nie zyskując nawet stu klientów.
Wniosek: Oczywiście PM nie zawsze musi wykonywać obowiązki menedżera. Czasem nawet dobrze dla outsourcingu, że klient robi coś ważnego i płaci systematycznie. Kasa się zgadza. Ale jak to wpłynie na reputację menedżera lub firmy? Odpowiedź jest oczywista.
Dlatego lepiej nie dopuszczać do rozwoju dla samego rozwoju. Określ główny cel, po osiągnięciu którego projekt zostanie uznany za udany. Swojego rodzaju acceptance criteria, ale nie dla funkcji, a dla całego projektu. Następnie, wykonując kamienie milowe, będzie można dostosować działania do celu końcowego. Lepiej jest zawalić plan i zrobić nowy, niż zawalić projekt i pogrzebać go całkowicie.
Historia 4. Trudności w komunikacji
Wystarczy ponownie przeczytać to, co się napisało. Przynajmniej raz na jakiś czas.
PM porozmawiał sam ze sobą i nie pozostawił szansy dla klienta.
Wniosek: Lepiej jest zadać 1 pytanie i uzyskać odpowiedź, niż mieszać opis sytuacji z listą uściśleń, dezorientując tym samym człowieka. Odpowiadając na taką wiadomość, klient może przeoczyć niektóre pytania i trzeba je zadać ponownie, niepotrzebnie denerwując klienta.
Jeśli w trakcie korespondencji klient zgodzi się na inne rozwiązanie, powinieneś zapisać wszystkie jego zgody, ponieważ zdarzają się sytuacje, w których nawet fakt posiadania zatwierdzonego ZT może nie zostać odebrany jako argument na korzyść zespołu deweloperskiego.
O tym właśnie jest kolejna opowieść.
Historia 5. Histeryczny klient
Tym razem nasz przyjaciel miał szczęście: sympatyczny klient z małym projektem, który szybko zaakceptował ZT i design, nie zwlekał z płatnościami i terminowo przesłał kontent do pracy. Po 3 miesiącach zespół dostarczył projekt na czas, a aplikacja trafiła do Google Play. Wydawało się, że to happy end, ale nie. Dokładnie 2 godziny po premierze klient bombardował telefon i lamentował, że na Xiaomi jego babci z 2005 roku aplikacja się nie uruchamia.
Klient był pewien, że oprogramowanie będzie działało na każdym urządzeniu i po prostu zignorował argument, że w ZT była określona minimalna obsługiwana wersja OS. Histeria trwała przez 3-4 miesiące i naprawdę psuła nastrój, zarówno kierownictwu, jak i menedżerowi projektu. Niby wszystko było zrobione dobrze, ale nie do końca.
Wniosek: Zawsze szczegółowo omawiaj z klientem, na jakim sprzęcie i oprogramowaniu będzie działał produkt. Szczególnie ważne jest omówienie oczekiwanego wsparcia dla wersji oprogramowania. Klient nie jest specjalistą od programowania i może nie znać szczegółów. Walorem zespołu jest powiedzenie mu, jakie trudności i ograniczenia mogą się pojawić.
Historia 6. A co, jeśli klient uzna mnie za irytującego?
Wszyscy zarządzający outsourcingiem znają sytuację, w której nie chce się pisać do klienta w drobnych sprawach. Jednocześnie, jeśli od ich odpowiedzi zależy realizacja produktu — trzeba się pozbierać i napisać / zadzwonić / wyciągnąć biedaka spod morza ważnych zadań i innych pingów.
Czy to nie dziwne? Brak odpowiedzi. Może dlatego, że PM napisał do klienta tydzień temu?
Wniosek: jeśli klient nie odpowiada — spróbuj go odnaleźć na wszelkie możliwe sposoby, ale nie po tygodniu. Użyj też wtyczki takiej jak mailtrack — pomoże ci ona śledzić, kiedy mail został otwarty. W takim wypadku, będziesz mógł udowodnić klientowi, że nie tylko widział maila, ale także otworzył go kilka razy.
To w razie, gdy z jakiegoś powodu operacyjnym kanałem komunikacji pozostała poczta. Oczywiście lepiej jest zatwierdzić z klientem scenariusz, który określa kolejność działania zespołu, jeśli nie może on kontynuować pracy bez odpowiedzi na szereg pytań.
Na przykład:
- Zespół przerywa projekt i przerzuca się na inny do czasu wyjaśnienia okoliczności.
- Decyzję pozostawia się asystentowi klienta (dane kontaktowe) lub PM i nie należy jej potem kwestionować.
Taki scenariusz pozwala firmie zabezpieczyć się przed nieprzewidzianymi przestojami.
Część 2. Wpadki przy pracy z zespołem
Aby artykuł nie był jednostronny, zapytaliśmy członków zespołu deweloperskiego o ich opinię na temat zadań PM-a, których realizacja wywołuje u nich totalną rozpacz i zgrzytanie zębów.
Ból 1. Nadgodziny
Jest 15:45, dokładnie 15 minut do meetingu z zarządem firmy. PM dostaje wiadomość na Telegramie od klienta: «Słuchajcie, musicie naprawić te błędy już dziś, bo jutro rano pokazuję produkt inwestorom». PM na pierwszy rzut oka decyduje, że naprawienie tych błędów zajmie najwyżej 2 godziny, więc pisze do klienta «ok» i idzie na spotkanie. Na spotkaniu PM dowiaduje się o nowych celach i KPI, więc w ciągu godziny całkowicie zapomina o obiecanych zmianach, aż do kolejnej wiadomości od klienta.
O godzinie 20.00 klient przypomina o sobie: «I jak tam, można już testować?» PM łapie się za głowę (nikt nawet nic nie zaczął), przeprasza klienta i mówi, że wszystko jest się robi, ale zadanie okazało się bardziej skomplikowane niż się na początku wydawało.
Następnie cały zespół spędza cały wieczór na poprawianiu błędów. Do tego menedżer mówi zespołowi, że klient i jego zmiany dopiero co się pojawiły i nie zapłaci im, jeśli nie naprawią bugów.
Wniosek: ustaw alarm, przyklej naklejkę na laptopie, stwórz zadanie z godzinnym deadline’em składające się z 2 słów, ale nie zmuszaj zespołu do wieczornych nadgodzin, jeśli jest najmniejsza możliwość, aby tego uniknąć. A tak poza tym, nie kłam. Ta historia nie została opowiedziana przez PM, ale przez programistę, który przypadkiem dowiedział się prawdy o tym, kiedy faktycznie pojawiło się zadanie, podczas rozmowy z klientem.
Ból 2. A może by tak wziąć na siebie trochę odpowiedzialności?
Kolejna smutna historia przydarzyła się PM, który ewidentnie dopiero zaczynał wnikać w szczegóły projektu i nie do końca rozumiał, co się wokół niego dzieje.
Wniosek: Jeśli PM pracuje nad projektem — niech o tym pamięta… i niech nie zapomni odebrać projektu.
W zespole każdy ma swoją rolę i każdy oczekuje od siebie odpowiedniego zachowania. Jeśli jednak kierownictwo postanowiło nie angażować PM w procesy firmowe, a on sam jest zbyt młody i nieśmiały, by zadawać zbędne pytania, to może dojść do sytuacji opisanej powyżej. Kilka takich korespondencji może pomóc PM przyzwyczaić się do nowego projektu, ale lepiej, żeby wcześniej był świadomy swoich obowiązków.
Ból 3. Kiedy PM żyje w swoim wymyślonym świecie
Zespół będzie bardziej lojalny wobec PM, który nazywa rzeczy po imieniu: stadion to stadion, mockup to mockup. W przeciwnym razie normą mogą stać się komunikaty o następującym charakterze:
Wniosek: lepiej nadawać z zespołem na tych samych falach, dzięki temu zadania są bardziej zrozumiałe, a informacja zwrotna bardziej treściwa. Sprzedawać mockup jako design — to zupełnie inna specjalizacja (na przykład działu sprzedaży), ale nie o tym chcemy dziś mówić.
Część 3. Jak nigdy nie popełnić błędu
Nijak. Nawet jeśli pochłoniesz doświadczenie wszystkich menedżerów projektów na świecie, okaże się, że właśnie dziś trafił ci się klient z unikalnymi, dotychczas niewidzianymi kruczkami. Z drugiej strony, czerpiąc z doświadczeń innych, można wyrobić sobie ogólne pojęcie o tym, czym jest zarządzanie projektami i czy odpowiada osobom, które chcą «wejść do IT».
Menedżerowie, pamiętajcie, nie jesteście sami!
