5 rzeczy które pomijasz tworząc harmonogram projektu

Zauważam, że często mylimy harmonogram projektu z wyceną pracochłonności zadań. Wiele osób (błędnie) myśli, że mając pracochłonność projektu (liczbę RBH potrzebną na wykonanie zadań) dzieli to przez 8h myśląc, że otrzymała liczbę dni potrzebną do ukończenia projektu. To tak nie działa.

Jeśli podejdziesz do tego w ten sposób to masz gotowy przepis na opóźnienia. Bo nie masz szans na dowiezienie projektu na czas – kiedy Twój plan jest z założenia błędny bo nie uwzględnia kluczowych elementów.

Dziś postaram się zwrócić Twoją uwagę na elementy, które są w harmonogramie istotne, a być może je pomijasz.

1. Nikt nie pracuje 8h dziennie

Większość pracowników jest zakontraktowana na tzw. „full time” – 8h dziennie (ok. 168h / miesiąc).

Otrzymując wycenę od programistów , np. zadanie #1 – 8 RBH. Nie znaczy to, że wykonanie zajmie jeden dzień.

Dzieje się tak, że w ciągu dnia pracy (8h) mamy faktycznej pracy dużo mniej. Bardziej produktywne osoby pewnie bliżej 6.5h – 7h, ci mniej produktywni pewnie bliżej 4 h dziennie. Nazywam to współczynnikiem produktywności, który dla każdego jest indywidualny.

Zarządzając zespołem programistów zazwyczaj uogólniam ten współczynnik do zespołu projektowego wyliczając jedną liczbę ile jest pracy w dniu pracy. Szacuję to zastanawiając się ile faktycznie mogą „klepać kod” w ciągu dnia.

Należy uwzględnić wszystkie spotkania cykliczne, przerwy na lunch (+ różne small talki o niczym). W zależności jak dużo jest dystraktorów u Ciebie w organizacji dobierz współczynnik produktywności dla swojego zespołu.

FYI: Na pewno nie wyniesie 100% (8h). Bezpieczenie jest jeśli założysz np 75% (6h).

2. Wąskie gardło etapu

Oprócz wyliczenia współczynniku produktywności należy wyliczyć dostępność danego członka zespołu. W wielkim skrócie – należy uwzględnić urlop jaki dany pracownik ma zaplanowany + prognozy ile urlopu wykorzysta podczas trwania projektu.

„Ile urlopu weźmie pracownik” można wyliczyć prosto (bo i tak plany urlopowe są dużą niewiadomą). Nie przewidzimy tego w 100%, wszystko jest naszymi szacunkami.

W skrócie: należy liczbę dni urlopu podzielić przez dostępne dni pracujące w roku. Wynik to liczba urlopu jaka średnio odchodzi nam „każdego dnia” z dostępności. Ważna wskazówka aby uwzględnić, że rok aktualnie trwa – więc urlop należy podzielić przez czas pozostały do zakończenia roku. Łącząc to z współczynnikiem produktywności mamy bardziej realną dostępność danego zasobu.

Należy oczywiście wyliczyć dostępność czasową jaką ma dany zasób w projekcie. Jeśli ktoś ma na głowie np. dwa projekty równoległe musisz to odpowiednio uwzględnić w swoich wyliczeniach.

Częstym problemem w wyliczaniu dostępności jest to, że dostosowujemy cały harmonogram pod zasoby programistyczne. Podobnie jak z wyliczaniem ścieżki krytycznej, każdy etap projektu powinien być dostosowany do wąskiego gardła. Czyli do zasobu, który ogranicza przerób.

Harmonogramując każdy etap projektu w dostosowaniu pod programistów często jest błędnym podejściem. Nie zawsze programista jest wąskim gardłem. Zdarzało mi się wielokrotnie, że w etapie testów i poprawek to testerzy byli wąskim gardłem.

Działo się tak dlatego, że projekty do testów się nakładały i zamiast dostępności 6h – byli dostępni dla konkretnego projektu przez 1.5h. To znacząco wydłuża etap testów bo „nie ma komu klikać i szukać błędów”. Nie przeskoczysz tego. Jeśli dostosujesz w takiej sytuacji etap testów i poprawek pod programistę to otrzymasz zakrzywiony obraz rzeczywistości.

Gdy harmonogramujesz pamiętaj proszę aby każdy z testów dostosować do wąskiego gardła.

3. Równoległe wykonanie zadań

Podstawą do ułożenia harmonogramu jest zaprojektowanie diagramu sieciowego projektu (aka. PERT). Na jego podstawie jesteśmy w stanie wyliczyć ścieżkę krytyczną projektu. Ścieżka krytyczna Jest to najdłuższy ciąg zadań, który wyznacza najkrótszy termin ukończenia projektu.

W wielu projektach (np. aplikacji webowych) etap układania diagramu sieciowego jest całkowicie pomijany. Kierownik projektu zakłada, ze wszystkie zadania będą wykonywane sekwencyjnie.

PM robią to prawdopodobnie z przyzwyczajenia, bo większość prostych projektów ma właśnie 100% zadań wykonywanych sekwencyjnie. Jednak projektując diagram sieciowy, często da się znaleźć elementy, które mogą być wykonane równolegle.

Dzięki temu można skrócić czas trwania projektu (jeśli masz odpowiednią liczbę zasobów). Często zdarza się, że w projektach, gdzie zadania mogą być realizowane równolegle (a nie są) – jest nadmuchany harmonogram. Te „rezerwy” są często marnotrawione – pisałem o tym we wpisie o buforach projektowych (trzy części).

Diagram sieciowy projektu może wyglądać jak poniższy.

4. Prace rozgrzewkowe przed startem

Dostając wycenę zadań od programistów, jest to czas „samej pracy”. Programiści wyceniają dokładnie to, co jest opisane w zadaniu – np. zrobienie feature XYZ.

Niestety na tym etapie projektu, często w opisie nie ma rzeczy, które trzeba wykonać PRZED rozpoczęciem danego zadania. Siłą rzeczy, jeśli nie ma tego w opisie to programista tego nie wycenia.

Później niestety budzimy się nad „rozlanym mlekiem” – bo do zadania trzeba wykonać jeszcze np. procedury testowe (lub inne rzeczy), a my nie uwzględniliśmy tego w harmonogramie.

Dlatego wskazówką ode mnie jest abyś zrobił dwie rzeczy:

a) przed rozpoczęciem projektu zastanowił się, czy trzeba zrobić zadania przygotowujące do pracy.

Na przykład:

• konfiguracja środowisk do pracy;
• czytanie dokumentacji przez zespół (jeśli jest obszerna);
• call „wprowadzające w założenia projektu”
• przygotowanie scenariuszów testowych itp.

b) przeanalizować każde z zadań – czy elementy przygotowawcze nie są potrzebne przed konkretnymi zadaniami. Może się zdarzyć, że jakieś konkretne zadanie będzie wymagało specyficznego przygotowania przed jego realizacją.

Te elementy należy uwzględnić w harmonogramie jako dodatkowy czas.

5. Czerwona kartka

Błąd bardzo prosty do uniknięcia. Chodzi o zaplanowanie w harmonogramie tzw. „czerwonych kartek z kalendarza”. Są to wszelkiego rodzaju święta/dni wolne. Pamiętaj, że jeśli dana czerwona kartka wypada w sobotę, to pracownicy w oparciu umowy o pracę mogą odebrać ten dzień jako wolny w trakcie dni pracujących.

Należy takie rzeczy uwzględniać. Często przy długich projektach mamy wrażenie, że takie święta nie mają znaczenia, ale jak się sumuje te dni to wychodzi czasami dodatkowy tydzień lub nawet dwa niedostępności.

Uwzględnij to, abyś nie musiał odzyskiwać ten czas naginając ludzi 🙂

Podsumowanie

Harmonogram projektu to Twój plan wykonania. Jeśli zrobisz go nieprawidłowo to nie ma szans aby dowieźć projekt na czas.

Zawsze mogą zaskoczyć nas elementy nieprzewidziane (prawa Murphy’ego) – wykorzystaj do tego bufor projektowy. Natomiast wszystkie rzeczy, które możesz przewidzieć (m.in. wymienione w tym wpisie) uwzględnij w harmonogramie.