Z tego podcastu dowiesz się:
- Jakie są najczęściej popełniane błędy w zarządzaniu projektem
- Dlaczego niedoświadczony PM może pogrzebać świetny projekt
- Czy nowicjusz ma szansę poprowadzić zespół do sukcesu
- Dlaczego odpowiednie kompetencje w zespole są ważne
- Co się dzieje, gdy project manager maluje trawę na zielono
- Jak krytyczna dla powodzenia projektu jest właściwa komunikacja
- Do czego może doprowadzić brak jasno określonego celu
- W czym może ci pomóc tzw. Karta Projektu
- Co sprawia, że wymagania biznesowe są źle zebrane
- Po czym poznasz nierealistyczny deadline
- Które błędy PMów spowalniają pracę developerów
- Jaka jest różnica pomiędzy zarządzaniem a mikrozarządzaniem
Podcastu wysłuchasz także na:
Transkrypcja podcastu
Kilka lat temu Quentin Tarantino zrealizował taki „Nienawistna Ósemka”, a u mnie dziś parszywa trzynastka. Jedziemy. „Być jak manager”, podcast epizod 15.
Dzień dobry. Witam się jak zawsze, serdecznie. Kłaniam się nisko tobie, drogi słuchaczu i dziękuję pięknie, że uruchomiłeś ten podcast, że masz mnie na słuchawkach. Ja zwyczajowo przypomnę tylko, że treści na tym podcaście kieruję przede wszystkim do ludzi, którzy już są albo dopiero będą pracować w szeroko pojętej branży IT. W kadrze managerskiej. Czy to są, czy wkrótce będą scrum masterami, product ownerami, product managerami albo project managerami. Dzielę się wiedzą, którą zdobywałem przez ostatnie lata. Staram się dać jakieś praktyczne, przydatne wskazówki. Więc jeżeli w jakikolwiek sposób uznasz, słuchaczu, że to, co mówię, jest w jakimś procencie wartościowe, to będę niezmiernie wdzięczny, jeżeli powiesz mi o tym albo na mediach społecznościowych, albo wyślesz prywatną wiadomość, jeżeli uważasz, że coś mówiąc kolokwialnie spieprzyłem, to będę podwójnie wdzięczny, jeśli mi o tym powiesz. Dziś temat, który już był tyle razy wałkowany, ale wciąż widzę pewną potrzebę przypominania o pewnych artefaktach kierowniczych, o artefaktach, które odróżniają tych dobrych od tych mniej doświadczonych, tych złych. Nie bójmy się tego słowa – project managerów i dzisiaj będzie temat bardzo project managerski. Zaraz wskoczymy w detale, ale właśnie sobie uświadomiłem, że nie zachęciłem cię, drogi słuchaczu do tego, żeby jeżeli tylko masz chęć być na bieżąco z tym, co tworzę, to cholernie zachęcam, serdecznie zapraszam do zapisania się na mój newsletter, na stronie, na blogu – Być jak manager.pl. Ja nie wykorzystuję niczyich danych osobowych, imienia oraz adresu mailowego do niecnych celów. Zawsze trzymam te wszystkie dane u siebie na potrójnie, czy tam poczwórnie zabezpieczonych serwerach i wysyłam tylko i wyłącznie newslettery, gdy opublikuję nowy podcast. Albo mam jakieś fajne, praktyczne rzeczy do podzielenia się właśnie z moją audiencją. Dziś temat, który roboczo nazwałem „Parszywa trzynastka”. 13 błędów, których należy, a nawet trzeba unikać w zarządzaniu projektem. Nierzadko, to taka ogólna opinia, nierzadko za niepowodzenia w projekcie, bo wiele projektów nie odnosi sukcesów. Powiedzmy to sobie szczerze. Pomimo dużego potencjału samego zespołu i samego produktu, nad którym ten zespół pracuje. Wiele projektów nie zostaje dowiezionych do końca i bardzo często za niepowodzenia wini się właśnie project managerów, tych projektów, które nie wyszły. I ja muszę przyznać bez bicia, choć wywodzę się z tej branży, że nierzadko w tym obarczaniu winą project managerów, jest niestety wiele racji, chyba że project menedżer jest decyzyjny tylko w teorii, a w rzeczywistości ma związane ręce przez na przykład swojego szefa albo właściciela firmy, w której pracuje. I dzisiaj to, co chcę zrobić, to chcę z tobą przejść przez najczęściej spotykane oraz najbardziej krytyczne błędy, przez które wysypał się niejeden projekt. Wspólnie przejdziemy przez te błędy. Ja opowiem też, dlaczego powinniśmy unikać tych błędów. Jeżeli zależy nam jako project managerom na sukcesie i powodzeniu projektu, a dla osób, które chciałyby ze mną bezpośrednio się już poza podcastem skontaktować i pogłębić jakiś temat, niekoniecznie projekt managerski, to zapraszam do zakładki konsultacje, na moim blogu. Tam jest możliwość wykupienia dla siebie na wyłączność skromnego kawałka mojego czasu. Żebym mógł się przyjrzeć indywidualnej kwestii albo jakiemuś problemowi do rozwiązania. Jedźmy z tym.
Błąd numer jeden. To niewłaściwa osoba, która jest przypisana do prowadzenia projektu. Niby banalne, niby oczywiste, ale wyobraźmy sobie, że firma, która powierza prowadzenie projektu niedoświadczonemu PM-owi, myślę, że może spokojnie spodziewać się porażki. I tutaj chcę wyjaśnić. Chociaż nowicjusz może być mega łebski, może się szybko uczyć, to ten sam proces uczenia się różnych tricków, różnych standardów zarządzania i właściwego właśnie zarządzania projektów. Ten czas, który potrzebuje Nowicjusz, żeby się naumieć pewnych tematów, może powodować wykolejenia w projekcie. Bo nie w każdym projekcie jest czas i przestrzeń na naukę, zwłaszcza jeśli mówimy o osobie, która prowadzi ten projekt. I najlepszym możliwym posunięciem w tym przypadku, żeby uniknąć jakby tego błędu, to jest zatrudnianie najbardziej wykwalifikowanej osoby do prowadzenia projektu, jaką uda nam się pozyskać albo jaką już mamy na pokładzie. I za słowem, za terminem „wykwalifikowana osoba”, kryją się zarówno umiejętności twarde, jak też miękkie. I tych miękkich, które korelują z naszym charakterem nauczyć się najtrudniej, pozwól, że wypunktuje. Otóż niedoświadczony PM, co robi? Otóż często obarcza winą za niepowodzenia, jakby w projekcie, zespół techniczny. Rzadko przypisuje winę sobie. Forsuje pewne pomysły na siłę pomimo sprzeciwu programistów. To jest częsta cecha niedoświadczonych PM-ów, albo takich, którzy mają problemy ze swoim ego. Co jeszcze robi niedoświadczony PM? Zaniża ogólną motywację zespołu, sam nie potrafiąc siebie zmotywować do pracy. Być może już się z takim czymś spotkałeś. I ostatnia rzecz, którą sobie wypisałem w moim notatniku, raczej kapowniku to to, że niedoświadczony PM przejawia wady spowodowane małym doświadczeniem, które bezpośrednio spowalniają albo mówiąc wprost – rozpieprzają projekt. Jakieś problemy relacyjne ma ze sobą, z otoczeniem, przynosi problemy z życia prywatnego do pracy. Tego jest sporo i nie tylko osoba przypisana do projektu może pogrzebać projekt. To sobie powiedzmy szczerze. Wielu właścicieli i prezesów firm najczęściej, uwierz mi, najczęściej, w startupach ma problem z własnym ego. Słyszałeś takie powiedzenie, że ryba psuje się od głowy? No to właściciele firm są tego najfajniejszym, najbardziej podręcznikowym przykładem. Jeśli prezes lub właściciel firmy jest nawiedzony, zakochany w swoim zdaniu bardziej niż w zdaniu swoich współpracowników. Jeśli prezes firmy jest głuchy na pomysły i krytykę zespołu, także krytykę samego PM, to nawet najlepszy project manager, nie wyciągnie w górę projektu, ponieważ jego przełożony nie pozwoli mu normalnie pracować. Ja sam kilka razy doświadczyłem pracy dla idiotów, to też jest mocne słowo, ale właściwe. Sam kilka razy pracowałem dla takich typów i tak naprawdę jedyne co można zrobić, to ty możesz zrobić jako projekt manager, to jak najszybciej spakować się i uciekać z tak toksycznego miejsca pracy. Czasem te wydawałoby się najtrudniejsze, najbardziej bolesne kroki, są jedynymi, które powinniśmy podjąć. Jeśli chcemy wprowadzić jakieś zmiany na lepsze w naszym życiu zawodowym. Podsumowując, ten punkt 1, ten błąd 1, to manager jest zawsze krytyczną rolą w zespole projektowym.
Błąd numer 2. Brak odpowiedniej liczby osób oraz kompetencji w zespole. Co mam na myśli? Otóż nie adekwatne zasoby potrzebne do zrealizowania projektu mogą być powodem porażki. Niech mi wszyscy HR-owcy, jeżeli będą tego słuchać, wybaczą teraz, że mówię zasoby, bo to już podobno niemodne i brzydki termin. Sięganie po termin zasoby zamiast ludzie, ja nie ukrywam, że to jest jeden z takich moich grzechów, które popełniam świadomie, żeby przypadkiem nikt mnie nie wysłał do nieba po mojej śmierci. Także pozwólcie mi grzeszyć tak jak chce, czasem będąc na przykład niegrzecznym. Otóż chodzi mi w tym podpunkcie o sytuację, gdy masz odpowiednią liczbę osób w zespole, ale tak naprawdę jak się bliżej przyjrzysz, to żadna z nich nie posiada skillów, których naprawdę potrzebujecie. Może to być na przykład specyficzna technologia, której żaden z dostępnych programistów nie zna, a powinien. Może to być jakieś konkretne narzędzie, którego obsługa wymaga pewnych kompetencji. Jeśli nie ma tych kompetencji w zespole projektowym, to w pewnym momencie dojdziecie do ściany i trzeba będzie tę lukę kompetencyjną po prostu wypełnić. I żeby uniknąć tego błędu i takich sytuacji, upewnij się jako project manager, jeszcze przed wystartowaniem projektu, że do jego zakończenia masz na pokładzie wszystkie niezbędne kompetencje. Taka dygresja dzisiaj jak nagrywam, to popijam sobie w międzyczasie sok z czerwonych pomarańczy, świeżo wyciskany. No może tak nie świeżo wyciskany, ale polecam serdecznie.
Błąd numer 3. Niewłaściwa komunikacja lub jej brak. Otóż komunikacja to jest klucz do sukcesu. Wierz mi lub nie, jeśli jeszcze się o tym nie przekonałeś, drogi słuchaczu, będzie taki moment, że na pewno ta świadomość tego, jak ważna jest komunikacja, gdzieś w tobie się obudzi. Otóż razem z otwartością czy pewną transparentnością, komunikacja stanowi filar zwinnego zarządzania projektem. Mówię tutaj o komunikacji ze stakeholderami, z inwestorami, z klientami. Ta komunikacja powinna być przede wszystkim stała, a nie sporadyczna oraz otwarta i szczera, i teraz częstym błędem PM-ów jest tak zwane malowanie trawy na zielono i opowiadanie o projekcie w samych superlatywach. Potem coś jest niedowiezione, a project manager, który tak pięknie malował trawę na zielono, zrzuca całą odpowiedzialność na zespół techniczny. Także drodzy PM-owie, co robimy? Nie pudrujemy problemów technicznych, nie pudrujemy błędów i blokerów, jakie napotkaliśmy po drodze realizując projekt, mówimy o nich otwarcie szczerze, rozmawiając ze stakeholderami. Komunikacja, skoro już jesteśmy przy tym temacie z zespołem technicznym, powinna być także szczera, także otwarta. Ale również oparta na wzajemnym zaufaniu. I to jest pewien fundament. Chodzi tutaj o komunikację w 2 strony. PM powinien dzielić się wymaganiami biznesowymi jasno i bez owijania w bawełnę, natomiast zespół techniczny powinien jasno przedstawiać status prac nad rozwiązaniem, nad którym obecnie wszyscy pracują. Jeśli w 2 strony ta komunikacja będzie w porządku, to redukujemy ryzyko potencjalnego fuck-upu. Podam przykład takiej niewłaściwej komunikacji, żeby to jakoś osadzić w kontekście. Otóż jest pewna funkcjonalność, którą wdraża zespół projektowy i ta funkcjonalność wdrażana jest na 3 platformy, iOS, Android oraz na Weba. I poszczególni deweloperzy mogą napotkać po drodze problemy i rozwiązywać je na swój własny sposób. Programiści z każdej z tych domen, z tych platform. I te problemy będą rozwiązywać na swój sposób. W swojej bazie danych. Ale nie poinformują o napotkanych problemach pozostałych członków zespołu, product ownera lub PM. Nie poinformują o tym, jakie błędy popełnili i jak sobie z nimi poradzili. I co się dzieje, jeśli brak tej komunikacji zajdzie? Otóż w ten sposób na przykład deweloper webowy, może napotkać podobny problem na swojej platformie jak deweloper innej platformy, na przykład Androida i będzie się z nim boksował w nieświadomości, że jego kolega z platformy androidowej już sobie z tym problemem poradził. I tak naprawdę zna potencjalne rozwiązanie. No i co, zespół traci czas. Jeden deweloper ownuje się z problemem. Inny ten problem już dawno rozwiązał, ale ten pierwszy nie wie, że już był taki problem, który został rozwiązany. Już się robi powolutku bałagan komunikacyjny i żeby zapobiegać takim sytuacjom i utrzymywać dobrą komunikację w zespole, to przede wszystkim zwinne metodyki, większość zwinnych metodyk daje nam wiele skutecznych narzędzi takich jak artefakty scrumowe, chociażby. Typu retrospektywa lub daily scrum. Posiadając takie narzędzia, wiedząc o nich, należy pielęgnować tę dobrą formę komunikacji, otwartą, szczerą, transparentną. I ostatni błąd już komunikacyjny to wysyłanie zaproszeń na spotkania bez podanej agendy lub wpisanego celu spotkania. Bardzo często spotykane w korporacjach. Nie w jednej, a w wielu. Takie praktyki powodują, że członkowie zespołu przepalają później godziny, siedząc na bezproduktywnych spotkaniach lub na takich, gdzie ich obecność w ogóle nie jest potrzebna. Trzymajmy się pewnych standardów komunikacji, także tej mailowej, także wtedy, gdy tworzymy event w kalendarzu, spotkanie, na które zapraszamy różnych członków zespołu. Agenda, cel spotkania, kto jest wymagany na tym spotkaniu, a kto może pojawić się opcjonalnie. To są absolutne podstawy.
Błąd numer 4 PM-owy. To brak jasno określonego celu oraz tego tak naprawdę co chcemy osiągnąć. Kiepskie planowanie kończy się zazwyczaj kiepsko zdefiniowanym celem, który powinien świadczyć o sukcesie naszym, o sukcesie naszego projektu. Jednym z grzechów project managementu jest właśnie nieumiejętność tworzenia takich celów, które są łatwo rozumiane, rozumiane przez wszystkich, żeby w późniejszej fazie ustalić jakieś konkretne metryki, jakimi będziemy mierzyć nasz sukces albo porażkę. Jak nam się nie uda. To tak naprawdę cały zespół musi od początku jednakowo rozumieć, dokąd zmierzamy. Widzieć ten cel, widzieć te światełko w tunelu, interpretować je tak samo. Rozumieć definicje naszego celu tak samo. Niekoniecznie tak samo docierać do tego celu, jak wszyscy. Bo żeby dotrzeć do celu, można to zrobić na wiele sposobów, ale wszyscy powinni tak samo rozumieć po co biegniemy, w jakim celu, gdzie, dlaczego. I brak takiego ogólnego poczucia celu, takiej konkretnej misji, pewnej pielgrzymki, w czasie której przejdziemy z punktu A do punktu B, może powodować kraksę. Każdy uczestnik projektu powinien wiedzieć, gdzie i po co zmierzamy. To po pierwsze. Już się powtarzam, ale chcę, żeby to wybrzmiało. Powinniśmy się co do tego upewnić. Jeszcze zanim rozpoczniemy pracę nad projektem. Czyli jako project manager, upewnij się wcześniej, że istnieje pewna wizja, że ta wizja jest jasna, klarowna, że możesz ją w sposób prosty i zrozumiały zakomunikować dalej, zanim jeszcze zaczniecie pracę. Upewnij się co do celu i misji, w której macie wziąć udział. Otóż zdefiniowanie celu jest tak samo krytyczne jak zdefiniowanie odpowiednich metryk, ponieważ to metryki powiedzą nam, czy dany cel został osiągnięty.
Błąd numer 5. Biegnę dziś, ale tych błędów jest aż 13, więc nie chcę wchodzić za bardzo w szczegóły. Błąd numer 5, to nietrzymanie się procesu lub jego brak. Mój ulubiony błąd. W sensie taki, który uwielbiam wypominać, moim młodszym albo starszym kolegom po fachu. Ja akurat jestem ogromnym fanem dobrze poukładanego procesu i jestem też fanem pewnej zwinności w zarządzaniu, ale jednak w oparciu o silny, spisany w jednym miejscu i wdrożony do działania proces. I zważ na moje słowa, drogi słuchaczu, to co teraz powiem. Nawet najgorszy proces będzie zawsze lepszy niż brak procesu. Brak procesu kończy się sromotnym bałaganem w projekcie. Nie wnikając teraz w żadną z metodyk zarządzania czy to scrum, kanban i tak dalej. Jest kilka rzeczy, które należy ustalić niezależnie od tego, czy będziemy działać właśnie w srcumie, czy w jakiejś innej metodologii. I polecałbym stworzyć prosty dokument, coś w rodzaju tak zwanej karty projektu, do której wpiszemy następujące ustalenia : jaki jest skład zespołu projektowego i kto za co odpowiada? Kto jest menedżerem projektu, a kto właścicielem backlogu produktu, ilu mamy stake holderów lub biznes ownerów? I kto podejmuje ostateczne decyzje produktowe? Jaki jest w końcu zakres prac? Jaki jest deadline? W jakiej metodyce zarządzania będziemy pracować? Kto jest team liderem technicznym, a kto team liderem, na przykład testerów? Jeśli to jest jakiś większy zespół testerski. Aż w końcu jakie chcemy osiągnąć kamienie milowe lub jakie OKR-y albo KPI, chcemy wypracować? Prosty dokument. Wszystko spisane w jednym miejscu. Biblia projektu. Tak, żeby nie było później wątpliwości, co zostało ustalone i nie chodzi tutaj o robienie dupochronu przed zarządem, że coś z nimi ustaliliśmy. Chodzi o to, żeby wszyscy mogli zawsze zajrzeć w jedno miejsce albo osoby, które zostaną zatrudnione w trakcie realizacji projektu, żeby taki dokument był źródłem prawdy o tym co robimy i dlaczego. I również w trakcie trwania prac, gdy rzekomo działamy w oparciu o proces. Także popełniane są błędy. Załóżmy, że działamy w scrumie. Jakie błędy związane z procesem możemy popełnić? Przykładowo, zmiana charakteru spotkań, zwłaszcza artefaktów scrumowych, takich jak codzienna ceremonia scrumowa. Ja często byłem świadkiem jak codzienne stand-upy zamieniały się w 30, nawet 40 minutowe spotkania statusowe. Nie o to chodzi. Daily powinno trwać 10, maksymalnie 15 minut. Innym błędem w czasie pracy projektowych to brak regularnych retrospektyw i wyciągania wniosków. I to jest poważny błąd, jeśli mówimy o procesie. Inną rzeczą związaną z procesem, to estymacje prac, które powinny dotyczyć nie tylko programistów, ale także testerów. Wyceniamy jakąś funkcjonalność i nieraz byłem świadkiem, że deweloperzy mówią, Ok, to dochodzą do jakiegoś tam konsensusu i ustalają obiektywnie, że coś nam zajmie 3 tygodnie, ale nie wiedzieć, czemu pomijano wyceny testerów. Przecież testerzy muszą dorzucić swoją cegiełkę do tych wycen. Też muszą coś przetestować. Też trzeba założyć pewien narzut, że jakieś błędy jeszcze na produkcji czy na środowisku testerskim zostaną wyłapane i trzeba będzie je dosztukować. Nie pomijaj my innych członków zespołu projektowego przy wycenianiu funkcjonalności. I jeszcze jeden taki przytyk w stronę błędów popełnianych w czasie procesu, to to, że iteracje są nieregularne. Raz wdrażamy coś, co drugi tydzień, raz idziemy na produkcję co 3 tygodnie, raz co miesiąc. Powiedzmy to sobie wprost, należy trzymać iteracyjność, jeśli już się na nią zgodziliśmy. Brak iteracyjności świadczy po prostu o słabym planowaniu.
Błąd 6 project managementu, to źle zebrane wymagania biznesowe. To nie do końca w sumie jest obszar stricte project managementu albo nie tylko project managementu, bo zbieranie, analizowanie, definiowanie wymagań biznesowych, to robota bardziej product managera. Jednakże gdy występuje taka sytuacja, że deweloperzy skarżą się na niejasne, niezrozumiałe wymagania biznesowe. To ty jako project manager powinieneś szybko reagować. Źle zebrane wymagania, to jakie? Otóż to takie, które mogą być niekompletne. Często mamy wielu różnych interesariuszy, wielu różnych użytkowników, co przekłada się na wiele różnych wymagań, jakie spływają do project managera lub bezpośrednio do zespołu projektowego. Wszystkie wymagania powinny być zawsze zbierane, no nie można niczego pominąć tak naprawdę, a jeśli wymagań jest dużo, to oczywiście należy je jakoś agregować, a następnie priorytetyzować, tak żeby żaden stake holder albo użytkownik nie poczuł się, mówiąc kolokwialnie, olany. Źle zebrane wymagania to także takie, które są niejasno opisane. Im bardziej skomplikowany opis wymagań, tym trudniejsze będzie jego zrozumienie. To tego oczekują interesariusze lub użytkownicy, powinno być wyłożone bardzo prostym, schludnym językiem. Oczywiście angielskim. I taka mała dygresja, wciąż fascynują mnie polskie firmy, które mają spisane wymagania po polsku, całą Gire prowadzą w języku polskim. Ale z drugiej strony, PR-owo, te same firmy mówią wszem i wobec, że chcą atakować globalny rynek. No to jeśli mamy globalne ambicje, to zachowujmy się i działajmy w globalnym standardzie. Z czasem firma zaczyna zatrudniać obcokrajowców i łapie się za głowę, bo cała dotychczasowa dokumentacja została stworzona po polsku. Coś tu się nie klei. Aż w końcu, źle zebrane wymagania, to takie, które zostały porozrzucane po różnych repozytoriach. Wyobraź sobie taką sytuację, że część wymagań, project manager umieścił w Excelu, na share point-cie. Część wrzucił do confluence girowego. Część spisał w tak zwanych epikach w Gire. A część zakomunikował zespołowi na Slack-u albo Teamsach. Ciśnie mi się na język, żeby powiedzieć, że niechlujstwo w dokumentacji produktowej czy projektowej, powoduje niechlujstwo w projekcie. I co jest bardzo ważne w tym kontekście to to, że zespół deweloperski lub zespół projektowy, musi zawsze wiedzieć, gdzie znajduje się jedno, właściwe źródło prawdy z wymaganiami biznesowymi. Oczywiście wymagania wysoko poziomowe, zebrane na samym początku, są potem rozczłonkowane na mniejsze, bardziej techniczne. Ale i to nie przeszkadza nam, żeby mniejsze zadania deweloperskie podlinkować w jednym dokumencie, który dedykujemy danej funkcjonalności. I teraz taki praktyczny pro tip, też z życia wzięty. Ja zachęcam do tego, żeby niezależnie od tego, jak zebraliśmy wymagania, jaką formę one przyjęły, umieścić wszystko w jednym repozytorium. Na przykład na confluence, jeśli organizacja korzysta z confluence. Dokument w conflu możesz stale edytować. Możesz poprawiać, rozbudowywać o nowe wymagania do danego tematu. Możesz tam linkować zadania deweloperskie, które zostały stworzone przez zespół techniczny. Możesz nawet podlinkować rode mapę, jeśli takową stworzyłeś ty lub jakiś produkt manager. Dobrze zebrane i spisane wymagania, to jest solidny fundament do dalszych prac operacyjnych. Dobra lećmy dalej, bo dziś to, dzisiaj się nakręcam równo.
Błąd numer 7. Źle przygotowany backlog. Bez wchodzenia w szczegóły, jak poprawnie przygotować backlog, bo to jest temat rzeka na zupełnie osobny podcast. 3 krytyczne błędy związane z backlogiem, po których poznasz niedoświadczonego albo po prostu słabego PM-a. Pierwszy krytyczny błąd dotyczący tego naszego dużego błędu związanego z backlogiem. Brak priorytetów dla poszczególnych zadań. Tak jak nie ma identycznych projektów w biznesie, podobnie nie ma zadań, które miałyby identyczny stopień ważności, identyczny wydźwięk. Część zadań, które muszą zostać ukończone przed deadlinem, powinny dostać większy priorytet. Niby jasne. A pozostałe, mniej pilne rzeczy, mogą dostać niższy priorytet. No to jest chyba proste. Jeśli nie nadasz priorytetów zadaniom albo funkcjonalnościom, to masz spore szanse, że twój zespół projektowy nie dowiezie na czas tego, co jest najbardziej krytyczne. Backlog bez priorytetów to jest zły backlog. To jest martwy backlog. Brak odpowiedniej granulacji, w tym na tym backlogu. Co mam na myśli mówiąc o granulacji? Otóż większe tematy, tudzież wymagania biznesowe, powinny zostać logicznie i sensownie podzielone na mniejsze części. Dzięki temu późniejsze omawianie pod kątem technicznym, estymowanie, aż w końcu wdrażanie tych tematów w interakcjach, tych funkcjonalności, będzie przebiegało sprawniej. Bez granulacji dużych ficzerów na mniejsze obszary, grożą ci tak naprawdę 3 rzeczy. Pierwsza to jest paraliż projektowy, ponieważ nie będzie wiadomo, jak poskładać dalsze prace i się za nie zabrać. Drugie ryzyko to są przekłamane estymacje. Lepiej podzielić ficzer i wyceniać osobno mniejsze rzeczy, a potem to sumować aniżeli wyceniać coś górnolotnie, zbyt ogólnie bazując na ogólnym opisie funkcjonalności, bez omówionych technikaliów, chociażby w podstawowym zakresie. I trzecie ryzyko to poślizgi w developmencie. Nie dowiezienie tematów, ponieważ w trakcie implementacji będą pojawiać się rzeczy, których nie umówiliście wcześniej i trzeba będzie robić krok w tył, zastanowić się nad poprawną logiką działania jeszcze raz, doprecyzować wymagania i dopiero potem wrócić znów do implementacji. Zobacz, ile czasu przez to tracisz, nie? Lećmy dalej, bo robi się naprawdę ciekawie.
Błąd 8 project managementu to nie realistyczny deadline. Project managerowie najczęściej chcą, aby ich przełożeni oraz klienci byli zawsze szczęśliwi i to jest w sumie słuszne podejście, bo od czego my menedżerowie jesteśmy. My mamy, mówiąc brzydko, zrobić laskę wszystkim. Jeśli klient będzie szczęśliwy, użytkownik będzie szczęśliwy, zarząd będzie szczęśliwy, to na pewno my po otrzymaniu kolejnej premii też będziemy szczęśliwi. Niestety, to jest duże niestety, sposób, w jaki niekiedy PM-owie uszczęśliwiają tych klientów, uszczęśliwiają kadrę zarządzającą, jest niewłaściwy. PM-owie sprzedają bowiem, zainteresowanym stronom, zbyt optymistyczne daty co do wdrożenia nowych funkcjonalności. W Polsce powiedzielibyśmy, że obiecują im gruszki na wierzbie. Terminy, którymi ty jako PM szachujesz w trakcie rozmów z klientami albo z zarządem, nie mogą być nierealne. Pamiętaj, to nie mogą być jakieś wyssane z palca daty. To do ciebie, jako project managera, należy zastopowanie w pewnym momencie zapędów klientów albo zarządu. Jeśli chcą ci wrzucić na timeline jakiś wyssany z palca, kompletnie nierealny termin. I pamiętaj, że jeśli zaakceptujesz zbyt krótki deadline, potem będziesz się srogo z tego tłumaczył, bo nie dowieziecie tego po prostu z zespołem. Albo zespół będzie orał przez ciebie nadgodziny, tylko po to, żebyście wyrobili się na czas. To mogą być naprawdę bardzo słabe konsekwencje twojej nieroztropności, w czasie prowadzenia konsultacji z biznesem. Co warto zrobić? Otóż zarządzaj świadomie i rozsądnie linią czasową projektu. Zawsze dodawaj pewien bufor czasowy do już wyestymowanych prac przez zespół tak, żeby w razie czego mieć jakiś margines, jakiś interwał czasowy, na nieprzewidziane rzeczy, albo różne zmieniające się okoliczności. I taka uwaga miękka do tego błędu z niej realistycznym deadlinem. Wywieranie zbyt dużej presji czasowej na zespół projektowy, skończy się brakiem zaufania zespołu do ciebie, dlatego negocjuj rozsądne terminy. Kropka.
Błąd 9. Zbliżamy się powoli do finału tego pięknego maratonu, przez który biegniemy, przyglądając się błędom project managerskim. Otóż błąd numer 9, to praca nad kilkoma projektami jednocześnie. Menedżerowie często popełniają błąd, kiedy myślą, że jak członkowie zespołu pracują nad kilkoma projektami albo rzeczami jednocześnie, to zostanie tym samym więcej zrobione, w tym samym czasie. No magia. W rzeczywistości jest kompletnie na odwrót, ponieważ tak zwany multitasking spowalnia człowieka, a nie przyśpiesza czyjąś pracę. Jakość prac projektowych spada, a opóźnienia powodują wąskie gardła później. Tak, że tu i tam zaczynają pojawiać się kolejne blokery w projekcie. I sytuacja, w której członkowie zespołu pracują w kilku projektach jednocześnie, to jest tak zwane, o tym się mówi dzielenie zasobów. Kiedy na przykład programista backend-owy pracuje jednocześnie na backendzie zespołu odpowiedzialnego za jakiś panel administracyjny oraz ten sam programista pracuje na backendzie w zespole rozwijającym jakąś nową aplikację mobilną. I wspomniany programista musi dzielić swój czas 50 na 50, w trakcie dnia. Uczestniczyć w spotkaniach obydwu zespołów. Musi planować swoje zadania dla obydwu zespołów. Musi dowozić zadania dla obydwu zespołów i to w miarę jednakowo, a nie że na zmianę. Jego produktywność wciąż może być oczywiście wysoka, ale gdy wyobrazimy sobie, jakby było bez tego multitaskingu, to ta produktywność byłaby jeszcze wyższa. Ponadto komfort pracy. Przecież to także bardzo ważny aspekt naszej codzienności. Komfort pracy jest wyższy, gdy nie przeskakujemy między zadaniami lub projektami. Nie jestem i nigdy nie byłem fanem dzielenia rąk do pracy na różne projekty jednocześnie. I to by było numer 9.
Błąd numer 10. Robi się ciekawie, klasyka gatunku, moi drodzy. Klasyka większa niż cała filmografia Woody’ego Allena albo Tarantino, już wspomnianego na początku. Błąd numer 10. Jako project manager robisz wszystko sam. I to jest klasyka gatunku, bo tu chodzi o problemy z czyimś ego. Nie ma to jak PM, który uważa że on sam robi i rozumie wszystko najlepiej. I żyjąc w takim przekonaniu, taki project manager, uwaga wyliczam : rzadko deleguje zadania innym, nie słucha sugestii zespołu, gdy na przykład zespół chce oflagować jakiś problem, jako potencjalnie krytyczny. PM może taki problem zbagatelizować. Przekłamuje estymacje, ponieważ sam wycenia, ile coś powinno zająć. Przecież wie wszystko sam najlepiej. Oraz zaklina rzeczywistość twierdzeniami, że zespół deweloperski jest najczęściej w błędzie. I nikt nie powinien podważać, a nie krytykować decyzji managamentu. Kiedy unikniesz tego błędu? Otóż unikniesz tego błędu, gdy przede wszystkim otworzysz się na pomysły zespołu, gdy obdarzysz ludzi zaufaniem i będziesz im delegował zadania. Pozwolisz innym popełniać błędy i wyciągać z nich naukę na przyszłość. Przecież ja najbardziej ceniłem i cenię sobie takie współprace, gdzie ktoś daje mi przestrzeń do tego, żeby mógł popełnić błąd, jakiego jeszcze nie popełniłem. Wyciągnąć z niego wnioski, przeprosić za niego, naprawić go i nie popełnić go po raz drugi. Ale ja potrzebuję takiej przestrzeni, bo wiem, że każdy człowiek popełnia błędy, po prostu bądźmy ludźmi dla ludzi. Oraz trzeci podpunkt. Unikniesz tego błędu, gdy będziesz częściej słuchał niż mówił, to akurat wiem z doświadczenia. Wiem, że nie jestem teraz wiarygodny mówiąc to, bo jako podcaster i taki nowoczesny ekspresyjny gaduła, raczej lubię mówić. Natomiast jest bardzo wiele sytuacji, zwłaszcza, gdy opowiadamy sobie nawzajem albo negocjujemy różne rozwiązania techniczne z zespołem projektowym, jest wiele sytuacji, gdy warto jest milczeć i słuchać, co mają do powiedzenia inni niż zmuszać innych do słuchania tego, co my sami mamy do powiedzenia.
Błąd 11, to zbyt częste zmiany w wymaganiach i zakresie prac. O co chodzi? Za każdym razem, gdy zespół deweloperski ruszy z implementacją, zakres wcześniej ustalonych prac nie powinien się zmieniać. Oczywiście wymagania biznesowe powinny być wcześniej pieczołowicie opisane i dogłębnie omówione, a jeśli coś ma się jednak zmienić w trakcie dewelopmentu, to musi za tym stać naprawdę ważny powód. Jako project manager, to co polecam, to wypracuj sobie z klientami i stakeholderami procedurę obsługiwania tak zwanych wrzutek. Co to jest wrzutka? Bardzo znane słowo, zwłaszcza w branży IT. Wrzutka to jest taka popularna nazwa zadań. Oczywiście nieoficjalna. Które menedżerowie dorzucają do zakresu prac już w trakcie trwania developmentu. Dorzucają – takie wrzutki. I najczęściej są to zadania, które nie zostały zaplanowane ani zaakceptowane wcześniej przez zespół projektowy. I takie coś, takie wrzutki rodzą frustracje, a czasem wręcz, nie bójmy się tego słowa, wkurwienie wśród członków zespołu i to po prostu obniża komfort pracy. Nie możesz, jako PM dorzucać deweloperom zadań do sprintu, ani zmieniać zakresu prac, chyba że masz na to absolutnie solidne argumenty, ponieważ coś naprawdę nieoczekiwanego pojawiło się po drodze. Nie chcę też za bardzo idealizować poprawnego zarządzania. Nie o to chodzi. Małe zmiany, powiedzmy to sobie szczerze, dodatkowe ustalenia czy doprecyzowanie wymagań biznesowych, często bywają nieodłącznym elementem developmentu. Jeśli jednak jakakolwiek zmiana jest na tyle duża, że wpływa negatywnie na pierwotne estymacje lub na inne obszary pracy programistów, no to powinniśmy tę zmianę przeparkować na później lub przerwać sprint, w najbardziej ekstremalnym przypadku.
Błąd 12, The last but not least. Zespół nie uczy się na własnych błędach. Sięgnę po najczęściej spotykany przykład ze świata metodyk zwinnych. Wyobraź sobie, że mamy zespół scrumowy, który otwiera dwutygodniowy sprint. Sprint kończy się po 2 tygodniach, a zespół, tak wyszło, nie dowozi wszystkich rzeczy, które zostały zaplanowane. Niedowiezione rzeczy przechodzą więc na kolejny sprint i zespół może je dokończyć, nic prostszego. Ale przez zbliżający się deadline i przez dużą presję czasu zdecydowałaś wspólnie z zespołem, że tym razem pominiecie tak zwaną retrospektywę, którą według scruma robi się na koniec każdego sprintu. Retrospektywa, chociaż podejrzewam, że już wiesz czym jest, to ja jednak przypomnę. To jest arcy ważny artefakt srcumowy, dzięki któremu zespół może omówić, co poszło dobrze, a co poszło źle, w trakcie ostatniego sprintu. I ten zespół może wyciągnąć wnioski, ucząc się na własnych błędach, po to, żeby uniknąć podobnych błędów w przyszłości. I tutaj jako, że zespół w naszym przykładzie, nie dowiózł wszystkich zaplanowanych rzeczy w 2 tygodnie, to aż prosi się o zrobienie retrospektywy. Natomiast przeskakiwanie retro, ponieważ zespół chce nadgonić dług techniczny i chce wygrzebać się z tego długu, długu sprintowego, to jest błędne koło. Ty jako project manager lub jeśli mówimy o scrumie, jako product owner, powinieneś zawsze dbać o to, aby z każdą iteracją zespół miał możliwość przyjrzeć się własnej pracy, omówić własne błędy i wyciągnąć z nich własne, odpowiednie wnioski.
I doszliśmy do końca naszego peletonu, dobiegliśmy do końca maratonu, zjedliśmy wszystkie wspaniałe posiłki związane z project managamentem, które dziś dla ciebie ugotowałem, aż dotarliśmy do ostatniego posiłku, do deseru, do wisienki na torcie, no bo najlepsze zawsze zostawiamy na deser.
Błąd 13, kończący naszą parszywą trzynastkę, najczęściej popełnianych, najbardziej karygodnych błędów project managamentu, to mikro managament, mikro zarządzanie. Jeśli nie ufasz ludziom i chcesz ich kontrolować na każdym kroku, ponieważ w przeszłości tobie także nie ufano i także cię kontrolowano, to czas najwyższy albo zmienić te złe nawyki, albo zmienić zawód, na taki, gdzie sam sobie jesteś i szefem, i pracownikiem. Najlepiej zostać sprzedawcą lodów. Czym innym jest mieć poczucie kontroli nad projektem, nad tym, co się dzieje, a czym innym poczucie kontroli nad ludźmi, ich obowiązkami czy zadaniami. Świeżaki w zarządzaniu, jak zwykłem ich nazywać, bardzo często zachowują się jak policjanci, którzy chodzą i kontrolują członków zespołu. Tacy niebieskie smerfy z Projektowej Dochodzeniówki. Zamiast niańczyć zespół w ten sposób, ustaw w kalendarzu regularne spotkania, na których zespół krótko cię zbreefuje z postępu prac i też opowie, jaki jest status poszczególnych zadań. Nie musisz ludziom męczyć buły ciągłym pingowaniem na Slacku albo na Teamsach. Co robią? Dlaczego? Na kiedy? Po co? Przestań męczyć bułę i być wrzodem na czyimś projektowym tyłku. I tym pozytywnym mikro-managamentowym akcentem kończymy parszywą trzynastkę. Never’a. To była moja parszywa trzynastka, bardzo subiektywna. 13 błędów w zarządzaniu projektami, których należy się wystrzegać pod groźbą wykolejenia projektu. Wielkie dzięki, jeśli wciąż tu jesteś. W kolejnym podcaście, prawdopodobnie jeśli nic się nie zmieni, porozmawiamy sobie nieco więcej o kondycji rynku IT w Polsce, ale nie tylko w Polsce. Jeśli jest coś, czego chcesz się dowiedzieć w kontekście poszukiwania pracy, jako PM, product owner, srcum master, czy analityk, to możesz zostawić swoje pytania w sekcji komentarzy pod tym podcastem, na moim blogu – Być jak menedżer pl. Zachęcam raz jeszcze do zapisania się na newsletter, jeśli chcesz być na bieżąco. Z newslettera można się w każdej chwili wypisać, także nic nie tracisz, a zyskujesz okazję, żeby otrzymać ode mnie osobisty, intymny list, prosto na swoją skrzyneczkę. Dobra, gadam głupoty. Dziękuję ci bardzo z tego miejsca, ale dziękuję też osobom, które zaufały mi na tyle, że wykupiły dla siebie konsultacje 1 na 1 ze mną. Za pośrednictwem specjalnego modułu na moim blogu, w zakładce konsultacje. Fajnie jest wiedzieć, że nie tylko ja się rozwijam jako podcaster i pewien coach managerów, ale także, że ty się rozwijasz dzięki tej mojej wariackiej podróży po krainie zarządzania w IT. Życzę samych najlepszości, dbaj o siebie i innych cześć.
KONIEC
Źródła
https://www.simplilearn.com/common-project-management-mistakes-article
https://www.liquidplanner.com/blog/top-10-mistakes-project-managers-make/
https://www.pmi.org/learning/library/common-rookie-pm-mistakes-avoid-6290
https://www.nutcache.com/blog/10-common-project-management-mistakes-avoid/
