Charyzma to nie wszystko: 6 obowiązkowych kompetencji twardych PM’a

28 października 2022

  • Autor: Anna Lavrova

  • Złożoność: normalna

  • Czas: 7 min

Cześć, nazywam się Anna Ławrowa, obecnie jestem Agile Coach w Wemanity Belgium, a w 2018 roku pracowałam jako PM w Dubaju, zarządzając programem projektów dotyczącym cyfrowej transformacji firmy. Dość szybko było wiadome, że wszystkie 9 projektów będziemy zlecać innym organizacjom.

Miałam doświadczenie w zarządzaniu projektami w IT i wydawało mi się, że łatwo będzie współpracować z PM-ami po stronie dostawców, bo “mówimy tym samym językiem”.

Myliłam się: komunikacja okazała się trudna, a wszyscy PM potykali się na tych samych rzeczach. Trudności pojawiły się z powodu braku konkretnych kompetencji twardych.

Czym się różnią kompetencje twarde (hard) od miękkich (soft)? W przypadku wzrostu pionowego, gdy specjalista przechodzi do zarządzania, dużą rolę odgrywają kompetencje miękkie. Natomiast nabywanie umiejętności twardych pomaga rozwijać się horyzontalnie, buduje kompetencje.

W tym artykule opowiem, jakich umiejętności brakowało PM-om w moim przypadku i jakie techniki musisz opanować, aby rozwijać się zawodowo.

Praca z wymaganiami

W Dubaju niewiele słyszeliśmy o agile: projekty prowadzone są według metodyk „wagi ciężkiej”, a my musieliśmy pisać setki stron wymagań. Kiedy więc przychodziliśmy do sprzedawców z dokumentami, to nie były to mgliste pomysły, ale konkretne opisy tego, co trzeba opracować.

Jednak PM, z którymi rozmawiałam, nie potrafili czytać wymagań, tzn. patrzyli na nie tylko z jednej strony. Z iteracji na iterację musiałam dodawać różne opisy, aby wymagania były bardziej zrozumiałe: rysowałam customer journey, pokazywałam personę user i opisywałam use case-y.

Prawie wszyscy PM patrzyli na wymagania z perspektywy tego, co tworzyliśmy, nie biorąc pod uwagę warunków i kontekstów, w jakich produkt będzie używany. Takie jednostronne podejście utrudniało pracę, bo oprócz wymagań samego rozwiązania zawsze są jeszcze życzenia biznesu i interesariuszy.

Umiejętność spojrzenia na potrzeby z różnych stron jest ważną kompetencją dla PM. 

Hard skill 1. Techniki formułowania wymagań

1

Potrzeby interesariuszy należy zidentyfikować już na starcie, ponieważ to one będą wyznaczonymi celami i kryteriami akceptacji projektu. PM będzie potrzebował znajomości podstawowych technik formułowania wymagań:

●      Kwestionariusz — jest najprostszą metodą. Taki kwestionariusz wypełnią przedstawiciele klientów lub określona grupa fokusowa.

●      Wywiad. Może być ustrukturyzowany – ten sam zestaw pytań dla wszystkich uczestników, lub nieustrukturyzowany — pytania wynikają z tego, na co decyduje się rozmówca. W tym temacie proponuję doskonałą książkę o wywiadach z użytkownikami: Steve Gary Blank „The Four Steps to the Epiphany”. 

●      Autorejestracja — PM otrzymuje od klienta gotowe wymagania. W moim przypadku tworzyłam dokumenty z zalecanymi wymaganiami dla PM-ów dostawców. Jako klient oczekiwałam, że PM-owie będą czytać dokumenty i dopiero wtedy będziemy się komunikować.

●      Gemba Walk — koncepcja opracowana przez Toyotę w ramach technologii lean manufacturing. Technika ta zbudowana jest na zobaczeniu na własne oczy, jak działają procesy dla przyszłych użytkowników danego produktu. Na przykład, trzeba pojechać do konkretnego magazynu i zobaczyć jak pracują tam ludzie. Gemba Walk jest używany, gdy trzeba stworzyć rozwiązanie dla organizacji nieinformatycznych, na przykład pomóc sieci supermarketów w wyborze strategii rabatowych.

● Burza mózgów  — jedna z najpopularniejszych technik technik radzenia sobie z wymaganiami. Spotkanie odbywa się w formacie grupowym, a uczestnicy wspólnie tworzą lub naświetlają główne części wymagań.

●  Use Case — z reguły piszą je analitycy biznesowi, ale gdy nie ma BA i trzeba napisać wymagania, umiejętność tworzenia use cases przyda się PM-om.

Szacowanie

Kiedy klient na etapie planowania pyta, ile pieniędzy będzie potrzebował, trudno jest odpowiedzieć. Jako kierownik programu, mówiąc o szacowaniu projektu, oczekiwałam odpowiedzi na trzy pytania:

  1. Czas: Kiedy będzie gotowy lub jaki jest harmonogram (kamienie milowe)? 
  2. Koszt: Ile pieniędzy będzie potrzebnych i na co dokładnie?
  3. Jakość: Jaka jest kolejność prac i co musi się wydarzyć, abyś mógł mi je przekazać?

Kierownik projektu będzie w stanie odpowiedzieć na wszystkie trzy pytania, jeśli zna i umie stosować określone metody ewaluacji.

Hard skill 2. Techniki szacowania

2

●      Planning poker pomaga oszacować złożoność pracy lub zrozumieć zakres zadań.

●      Doprecyzowanie szacowania ma miejsce, gdy wstępna dokumentacja wymagań jest aktualizowana i wykorzystywana w trakcie życia projektu. Na przykład najpierw mamy 30% pewności, że zrobimy to w takiej ilości czasu i pieniędzy. Następnie doprecyzowujemy według stożka niepewności: im dalej jesteśmy, tym procent pewności się zwiększa.

●      Szacowanie odgórne (Top Down Estimate) — technika, która jest również nazywana oceną ekspercką. Technika ta pomaga dostrzec koszty we wczesnych fazach, kiedy informacje o projekcie są niepełne lub ograniczone. Wycena dokonywana jest w sposób ogólny, a koszt w zasadzie wyliczany jest z jednego ze wskaźników.

●  Szacowanie według analogii. Metoda ta opiera się na założeniu, że projekty są podobne, więc koszt można wyliczyć na podstawie projektów, które PM lub jego koledzy robili wcześniej. 

Planowanie

Kiedy poprosiłam PM-ów z naszego programu projektów o zaplanowanie jakiegoś etapu życia projektu lub pokazanie Project Planu, zobaczyłam, że są tam warunkowe workstreams podzielone na części składowe. Oczywiście nie było jasne, w jaki sposób podejść do tych workstreams.

Zawsze powinien być jakiś plan i nie chodzi tu o napisanie ogromnego dokumentu. Ważne jest to, że plan odpowiada na pytania:

●      Co robimy?

●      Kiedy oddamy każdą część pracy?

●      Ile potrzeba czasu i pieniędzy?

●      Co możemy zredukować?

●  Gdzie jesteśmy w danym momencie?

Udane planowanie zawsze przebiega przez pewne etapy.

Hard skill 3. Podstawowe etapy planowania

3
  1. Treść pracy. PM musi analizować pracę zarówno dla projektu, jak i dla produktu. Scope of works produktu mówi o tym, co tworzysz. Scope of works проекта — dotyczy prac, które dzieją się wokół produktu.
  2. Work Breakdown Structure, WBS, czyli hierarchiczna dekompozycja pracy. Ważne jest, aby kierownik rozumiał, które pakiety należy wypełnić, aby zamknąć funkcję lub spełnić pośrednie cele projektu.
  3. Estimates (Szacowanie pracy) i jej dokładności. Umiejętność podawania szacunków oznacza szacowanie kosztów pracy ludzkiej i czasu trwania wszystkich działań w WBS.
  4. Harmonogram (Schedule). Zbudowana WBS (struktura pracy) jest przekształcana w harmonogram projektu. Wynik jest analizowany: intuicyjnie na podstawie dotychczasowych doświadczeń lub z wykorzystaniem diagramu sieci i ścieżki krytycznej jako narzędzi.
  5. Diagram sieciowy — najlepszy sposób na wizualizację kolejności i równoległości niektórych czynności. Schemat może być nawet tworzony ręcznie na fizycznej tablicy. Ścieżka krytyczna — minimalna liczba czynności, których nie można pominąć, aby przejść przez cały diagram sieciowy.
  6. Techniki skrócenia harmonogramu. Istnieją różne techniki i podejścia, takie jak zwiększenie liczby uczestników w zespole lub dekompozycja zadań blokujących na mniejsze.
  7. Prognozowanie — techniki takie jak Burn down/up Chart, Velocity, EVM pokazują, gdzie będziemy w danym momencie. Te podejścia nie mierzą wydajności, ale wskazują, gdzie jesteśmy teraz i pomagają przewidzieć rozwój sytuacji.

Śledzenie postępów

PM nie może prowadzić projektu i nie mierzyć wydajności. Dobrze jest, gdy menedżer robi retrospektywy, analizuje, co doprowadziło do jakiegoś zdarzenia, zadaje właściwe pytania i usprawnia spotkania. Ale poza tym potrzebujesz liczb, aby śledzić wydajność: konkretne wskaźniki.

Hard skill 4. Wskaźniki efektywności

4

Istnieją różne rodzaje metryk do mierzenia postępu, ale 2 podstawowe czynniki, które zawsze powinieneś śledzić to ruch w dążeniu do celu i wyniki.

Cel projektu nie może brzmieć: „wykonać wszystkie zadania” lub „zadowolić klienta”. Jeśli mówisz o konkretnych potrzebach biznesowych, to potrzebujesz mierzalnego wyniku i sposobu dojścia do wymagań.

Cele projektu są formułowane przy użyciu techniki Impact Mapping, a następnie PM decyduje, jak śledzić, czy zespół zmierza w kierunku celów, czy się od nich oddala.

Wynik (Deliverable) jest tym, co dajesz swojemu klientowi. Wynikiem może być raport, wniosek, aktualizacja, dokument, link do InVision. Istnieją różne wersje Deliverable: procesowe, organizacyjne, rozwojowe, inżynierskie – wszystkie z nich PM musi umieć wygenerować i śledzić.

PMHS

Ryzyko

W projektach pojawiają się ryzyka związane nie z ludźmi czy procesami projektowymi, ale z technologią. Na przykład, podczas tworzenia produktu dla banku, możesz nie być w stanie przetestować czegoś end-to-end. Możesz być w stanie śledzić, co dzieje się w obrębie banku klienta, ale gdy płatność trafi do innego banku, będziesz mógł zobaczyć, jak wszystko działa tylko w produkcji. To jest ryzyko.

Jako klient oczekuję, że PM starannie zaplanuje ryzyko i że ja również będę w nie zaangażowana. Gdy klient i zespół są poinformowani, możliwe jest włączenie do planu na czas zadań związanych z łagodzeniem zagrożeń.

Hard skills 5. Zarządzanie ryzykiem

5

●      Zidentyfikuj i przeprowadź analizę ryzyka na początku projektu.

●      Planuj nie tylko zagrożenia, ale także szanse.

●      Uwzględniaj ryzyka podczas przygotowywania budżetu.

●      Przygotuj z wyprzedzeniem plan reagowania.

●  Monitoruj i zapobiegaj ryzyku w trakcie trwania projektu.

Wiedza o tym, jak radzić sobie z ryzykiem, pomaga PM-owi reagować na zagrożenia w odpowiednim czasie, aby dostarczyć określone cele w ramach budżetu i z odpowiednią jakością.

Oddanie projektu

Przed rozpoczęciem projektu menedżer musi zaplanować nie tylko jego uruchomienie, ale także dostarczenie. Jednak w mojej roli klienta musiałam dosłownie „wyciągnąć” z PM-ów: „Co będzie dalej?” Ani jeden PM ze strony sprzedawcy nie napisał na samym początku, jak widzi zakończenie i co da ono klientowi.

Odpowiedzieć na pytanie: „Co dalej?” pomoże Transition Plan — opis tego, jak i komu przekażesz wszystko, co stworzyłeś. 

Hard skill 6. Transition plan

6

Pytania pomagają sformułować wymagania dotyczące przejścia i przekazania projektu:

●      Co trzeba zrobić, aby zakończyć projekt?

●      Co i komu oddasz?

●      Jak zbierzesz całą wiedzę zdobytą w projekcie?

●  Jakich wskazówek będzie potrzebował nowy PM podczas przekazywania projektu? (np. Kiedy będziesz mieć urlop).

Kiedy PM sformułuje swoje odpowiedzi, można rozpocząć opracowywanie Transition Plan:

●      Zbierz dokumenty zawarte w oryginalnej propozycji, upewnij się, że wyraźnie zaznaczasz, który z nich jest podpisaną kopią (jest to ważne, aby zrozumieć początkowe, komercyjne oczekiwania).

●      Zbierz wszystkie żądania zmian (numer, opis i czas dla każdej kopii). Sformułowania mogą być krótkie, ważne, że wszystko pasuje. 

●      Zaproponuj kolejne kroki i daj rekomendacje dla nowego PM.

●      Wskaż, komu co oddać.

●      Ustal jasny termin realizacji projektu.

●      Opracuj plan komunikacji.

●      Zaplanuj zaangażowanie grupy docelowej tak wcześnie, jak to możliwe, włączając do zespołu projektowego kogoś, kto działa również jako agent zmiany.

●  Opracuj odpowiednie szkolenie dla grupy docelowej.

Podsumowując

Aby zostać profesjonalistą, potrzebna jest nie tylko ciężka praca i charyzma, ale także konkretne umiejętności:

  1. Techniki formułowania wymagań.
  2. Techniki szacowania projektu.
  3. Etapy planowania.
  4. Śledzenie wydajności.
  5. Zarządzanie ryzykiem.
  6. Planowanie przejścia i przekazania projektu.

Umiejętności te można nabyć w trakcie realizacji projektów, popełniając wpadki i ucząc się na własnych błędach. Albo wybierz bardziej systematyczne podejście — i przejdź przez program rozwijający odpowiednie umiejętności.

Anna Lavrova

Agile Coach w Wemanity Belgium. Ponad 9 lat doświadczenia w zarządzaniu projektami. W tym czasie pracowała na stanowisku PM w Outsource, Outstaff, Product, Startup. Uczestniczyła w projektach rządowych USA i uruchomiła kilka startupów. Obecnie mieszka w Brukseli i pracuje z korporacjami, które aspirują do bycia Agile.