Trzeba przyznać, że stara "wodospadowa" metoda tworzenia oprogramowania pozostawia wiele do życzenia. Tradycyjny PM opierał się na fazach takich jak określanie wymagań, planowanie, projektowanie, budowanie, testowanie i dostarczanie. Z kolei metodologia Agile to skoncentrowane na ludziach i wynikach podejście do tworzenia oprogramowania: elastyczne, szybkie i mające na celu ciągłe podnoszenie jakości przy użyciu narzędzi takich jak Scrum. Jest łatwa do nauczenia i wdrożenia; widzimy postępy studentów na kursie Zarządzanie Projektami w IT w Beetroot Academy. W ciągu czterech miesięcy zdobyli wystarczającą wiedzę, aby przystąpić do testu i otrzymać międzynarodowy certyfikat Scrum Master na Scrum.org.
PM współpracuje z klientem, zespołem DevOps oraz firmą outsourcingową. Każdy z nich inaczej postrzega swoje role i role innych. To problem do rozwiązania.
Jak firma technologiczna zazwyczaj postrzega programistów? Są jak maratończycy: ciężko pracują, aby " dobiec do mety" z najlepszymi wynikami.
Jak firma postrzega kierownika projektu? Jako osobę, która relaksuje się przez 80% czasu i marnuje pieniądze firmy.
Jak deweloperzy czują się wewnątrz firmy? Jakby nikt nie doceniał ich ciężkiej pracy.
Kierownik projektu rozumie percepcję wszystkich trzech podmiotów i może reprezentować każdy punkt widzenia podczas negocjacji. Kierownik projektu to osoba, która potrafi wyjaśnić, co każdy robi, wnieść swoją wartość w najbardziej efektywny sposób i znaleźć wspólny język z firmą, zespołem i klientem.
W ten sposób oceniamy, czy projekt zakończył się sukcesem, czy nie. Istnieją pewne sztuczki, aby spełnić te kryteria i nawiązać właściwą relację z klientem. Lepiej skończyć projekt 2 dni przed terminem, wykonać jedno dodatkowe zadanie, a nawet zaoszczędzić pieniądze klienta. Zaplanuj te sztuczki, a przyniesie to wartość dodaną do Twojej pracy.
Globalnym celem PM jest zapewnienie wszystkim tego, czego chcą. Zazwyczaj klient chce otrzymać projekt za najniższą cenę i przy użyciu najtańszych technologii. Najtańsze technologie oznaczają, że łatwo jest wspierać i utrzymywać ten projekt. Czego chce zespół? Zawsze chce czegoś interesującego, nowych funkcji i nowych technologii, które są obecnie najbardziej popularne i kosztują więcej. Dość trudno jest balansować między nową technologią za najwyższą i najniższą stawkę oraz między nową i starą technologią, próbując znaleźć rozwiązanie, które zadowoli wszystkich. Najważniejszą rzeczą, którą kierownicy projektów, jako prawdziwi liderzy, powinni wypracować od samego początku, jest mówienie prawdy klientom i zespołowi. Empatia jest kluczem do sukcesu.
Codzienną rutyną, którą zwykle będziesz wykonywać w swoim miejscu pracy, będzie sytuacja, w której przychodzisz do programisty i prosisz go o dodanie/zmienienie czegoś, naprawienie błędów lub wykonanie dodatkowej pracy. W większości przypadków otrzymasz odpowiedź NIE. Musisz nauczyć się pracować z odmowami i konfliktami. Przede wszystkim powinieneś dowiedzieć się, jakie są rzeczywiste obiekcje i rozwiązać problem. Może on/ona boi się czegoś, jest introwertykiem lub osobą, która nie chce spędzać więcej czasu w pracy i chce iść do pubu z przyjaciółmi.
Ważne jest również, aby upewnić się, że pracownicy komunikują się ze sobą odważnie, aby pracować z ryzykiem. Czasami deweloperzy przeceniają lub nie doceniają siebie. Świetnie jest zobaczyć rezultat przed upływem terminu! A kiedy nie wszystko jest zrobione na chwilę przed deadlinem, wszyscy zaczynają się denerwować.
Jedną z najtrudniejszych rzeczy, gdy coś idzie nie tak, jest odwrócenie uwagi klienta, kierownictwa od obwiniania programistów lub gdy DevOps obwinia QA. Dlatego PM powinien pozostać skupiony i szukać rozwiązania zamiast obwiniać kogoś. Szukanie winnego jest zawsze porażką, podczas gdy szukanie rozwiązania pokazuje odpowiedzialność i chęć osiągnięcia celu.
Zawsze pojawia się pytanie o to, kto jest lepszym kierownikiem projektu: czy jest to osoba z wykształceniem technicznym, czy bez niego? Od czasu do czasu techniczni kierownicy projektów mogą pisać kod, naprawiać błędy, a nawet zastępować programistów. Nietechniczni kierownicy projektów, scrum masterzy, account managerowie nie wiedzą nic o programowaniu, ale znają psychologię, potrafią zarządzać zespołami i ustalać procesy. Obaj mają takie same szanse na pracę w firmach z branży technologicznej, wyzwaniem do zaakceptowania jest bycie swego rodzaju tłumaczem z języka nietechnicznego na techniczny i odwrotnie.
Kurs zarządzania projektami w Beetroot Academy pomoże Ci nauczyć się jak organizować zespoły, budować złożone procesy, pracować z zasadami agile i być tym tłumaczem z języka technicznego na "normalny".
PM zbiera wymagania, szacuje i ocenia zadania, pisze dokumentację, ustala zadania, przeprowadza kontrolę jakości, monitoruje terminy i prezentuje produkt klientowi. Ale... dość często PM zajmuje się sprzedażą i omawia cenę z klientem, lub zapewnieniem jakości, który testuje projekt, aby upewnić się, że wszystko działa poprawnie, lub jest trochę specjalistą od marketingu i projektantem. Często zdarza się, że żona, syn lub córka klienta są projektantami lub specjalistami od marketingu i wiedzą "lepiej", co robić. PM bywa również analitykiem biznesowym, który oblicza zyski, a nawet osobą z działu HR, aby upewnić się, że kandydat będzie pasował do zespołu.
Tak więc... poznajmy idealnego PM - to Superman. Jest jednocześnie komunikatorem (tłumaczem), psychologiem, negocjatorem, liderem, menedżerem czasu i specjalistą od technologii.
Tak wygląda PM w praktyce, a nie w teorii. To wymagająca, ale ekscytująca praca. Jeśli przeczytałeś ten tekst i zainspirowałeś się, a nie przestraszyłeś, wykonaj szybki test, aby upewnić się, że bycie PM to Twoja niedaleka przyszłość.
Jeśli uznasz, że tak - zapisz się na kurs Zarządzanie Projektami w IT w Beetroot Academy!