Jak raportować stan projektu?

Udostępnij

Luźny wpis, w którym poruszę temat raportowania stanu projektu. Zachęcam do przeczytania wszystkich, którzy takie raporty piszą, a przede wszystkim tych, którzy je czytają :). Odpowiem dlaczego pytanie “ile procent projektu mamy ukończone?” może zakłamywać rzeczywistość i dawać złudne poczucie bezpieczeństwa. Pokażę również bardziej skuteczną metodę raportowania stanu projektu.

Gdy stawiałem pierwsze kroki jako PM, prowadziłem pewien projekt, w którym miałem przesyłać klientowi tygodniowe raporty. Raport ten miał odpowiadać na pytanie “ile procent projektu jest ukończone?”. Prowadziłem skrupulatnie wszystkie dane w excelu, analizowałem zadania z JIRY – więc nie sprawiało mi problemu, żeby przygotować taki raport w ~10-20m. Po kilku tygodniach opracowałem pewien wzór raportu, który składał się z wypisanych modułów, każdy z procentowym ukończeniem oraz średnią arytmetyczną punktów procentowych wszystkich modułów. Projekt był rozłożony na czynniki pierwsze, mój wykładowca ze statystyki byłby ze mnie dumny. Takiego samego sposobu raportowania oczekiwałem od swoich managerów modułów – zarządzali większymi modułami w tym projekcie i wysyłali mi statystyki, które ja agregowałem w jeden zbiorczy raport. Przez pierwszych kilka tygodni stopień zaawansowania w projekcie rósł – wykresy robiły się coraz bardziej zielone (stopień ukończenia powiększał się). Faktyczny postęp według mnie nie postępował tak szybko, byliśmy zgodnie z planem, mimo że statystyki pokazywały, że mamy pewną rezerwę czasową. Analizując tę historię dzisiaj, w tym momencie powinno włączyć mi się żółte światło ostrzegawcze. Z każdym tygodniem postęp ukończenia wzrastał o mniejszą ilość punktów procentowych, mimo, że zespół nie zwalniał tempa. Nie wiedziałem dlaczego tak się dzieje, byłem uśpiony złudnym poczuciem bezpieczeństwa, bo “przecież robimy progres, konsekwentnie do przodu”. Przyczyniło się to do tego, że o wiele za późno odkryłem “wąskie gardło” w projekcie, które powodowało brak znaczącego postępu (oprócz tego w statystykach).

Wiedziałem jak manipulować statystykami by były korzystniejsze lub przeciwnie. To nie było niezgodne z prawdą, to była różna interpretacja danych. Manipulację statystykami poprzez subiektywną interpretację zauważamy codziennie w różnego rodzaju sondażach i badaniach. To tak jakbym się zapytał swojej rodziny czy znają adres wojciszko.com, a następnie zinterpretował ten wynik: “100% Polaków zna adres wojciszko.com”. Mógłbym pójść dalej i powiedzieć o wszystkich ludziach na świecie. Czytający nie ma informacji, które są istotne do interpretacji – ile osób było ankietowanych i jakie to były osoby 🙂 Jaskrawy przykład, ale mam nadzieję, że widzisz analogię. Dokładnie to samo się dzieje w raportach, które opisywałem powyżej.

Z perspektywy czasu wiem, co było złe. Zła była skala pomiaru zaawansowania projektu. Mierzyliśmy stopień ukończenia na podstawie zamkniętych zadań. Zobrazuję to na przykładzie:

#1 task (1h)
#2 task (1h)
#3 task (4h)
#4 task (4h)

Gdy zamkniemy #1 task, #2 task, według statystyki będziemy mieć 50% ukończenia projektu, więksi realiści powiedzą, że to jest 20% (2h z 10h). Jeśli mamy wiedzę (którą nabyliśmy w trakcie trwania projektu), że #3 lub #4 task się opóźnią, faktyczny stan ukończenia projektu będzie nawet niższy niż 20%.

Projekt był mierzony według złej skali. Równie dobrze można by było podać liczbę napisanych linii kodu lub ilość kWh, jakie zużyły nasze komputery do pracy. To również był jaskrawy przykład. Skala pomiaru została narzucona na mnie, ja natomiast sukcesywnie narzuciłem ją w dół. Managerzy modułów podali ją dalej. W efekcie wszyscy chcieli zamknąć jak największą liczbę zadań (co nie jest równoznaczne z postępem w projekcie). Zamykane były krótkie proste zadania, dzięki którym statystyki rosły. Nikt nie skupiał się na robieniu faktycznego postępu, głównym celem był postęp “na papierze”. Błędne koło.

Pójdźmy dalej i zastanówmy się, dlaczego ludzie pytają “ile procent projektu mamy ukończone?” – dlaczego pytają akurat w ten sposób. Odpowiedzią jest ich założenie, które jest błędne: “to, że ukończyłem w 1h 50% oznacza, że całość ukończę w 2h”. Otóż nie. To jaką mieliśmy przeszłość, nie determinuje przyszłości. Pewnie znacie przykłady projektów, w których ostatnie 10% zakresu trwało 50% czasu projektu 🙂 – ja znam. Jeśli wygrasz w sobotę czwórkę w lotto, to nie znaczy, że tydzień później twoja wygrana się powtórzy – nie budżetuj tego 😉 Pewnie słyszałeś o prawach Murphy’ego i wiesz czym są. Murphy uderzy gdy się nie będziesz tego spodziewał, czyli w najmniej oczekiwanym momencie. Kluczowy zasób w projekcie zachoruje, gdy będzie miał najwięcej do zrobienia, będzie awaria elektryczności w biurze przez tydzień lub cokolwiek innego. Nie zakładaj pewności na niepewność, że Murphy nie zapuka do twojego projektu.

PS: do nas ostatnio zapukał Murphy w postaci ataku na naszego providera internetu. Skutek był taki, że do firewalla dostawcy internetu trafiły nasze adresy API, co uniemożliwiało pracę z biura.

Jak raportować stan projektu?

Goldratt, twierdził, że wszystkie rozwiązania problemów są tak naprawdę żenująco proste. Zgadzam się z tym, tak jest też w tej sytuacji. Wystarczy, że będziemy monitorować ilość dni, jaka została do ukończenia projektu. Pytanie więc powinno brzmieć “za ile dni ukończymy projekt?“. Co z tego, że mielibyśmy 90% projektu, jeśli kolejne 10% będziemy robić pół roku – to nic nie znaczy. Natomiast każdego interesuje kiedy ukończymy projekt i jak to ma się względem pierwotnie zaplanowanego deadline. Nie mówię, że to pytanie jest panaceum na idealne raportowanie, pamiętajmy, że Murphy może przyjść o każdej porze. Uważam, że takie pytanie nie wprowadza złej skali pomiaru zaawansowania projektu, więcej mówi o tym, gdzie tak naprawdę jesteśmy. Dla wszystkich, którzy lubią procenty możemy pytań “za ile dni będzie 100%?” 😉

Podczas luźnych dygresji (jednej z wielu 😉 ) dyskutowaliśmy w pracy nad raportowaniem stanu projektu przełożonym. Jedna z osób (pozdrawiam Pawła), opowiedziała jak w jego poprzedniej pracy wyglądały takie sprawozdania. Składały się z narysowanej na kartce jednej z trzech “minek” – 🙂 😐 :(. Minka uśmiechnięta znaczyła, że jest ok, a nawet lepiej, minka druga, że zgodnie z planem, minka smutna sygnalizowała opóźnienie. Na początku wydawało mi się to śmieszne, jednak po głębszym zastanowieniu uznałem, że taki sposób raportowania jest bardziej miarodajny niż statystyki, które opisywałem na początku wpisu. Wnioskiem jest to, że forma raportu jest mało istotna, natomiast ogromne znaczenie ma skala jaka mierzymy pomiar, nawet jeśli wyrażamy to w postaci minki :).

piesel

 


Na co dzień prowadzę fresh-apps.com.

Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze, LinkedIn lub subskrybuj mój kanał na YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).


Udostępnij

6 thoughts on “Jak raportować stan projektu?

  • 2 lutego 2016 at 08:28
    Permalink

    W późniejszych etapach projektu (kolejne wdrożenia) przydatnym narzędziem do raportowania jest SonarQube, zestawiający statystyki i mierzący jakość kodu.
    Do raportowania serii testów polecam SoapUI najlepiej połączonego z Jenkinsem, który posiada plugin do generowania raportów z sesji testowych lecących zaraz po buildzie.
    A jeżeli chodzi o postęp pracy to aktualnie używamy Sprintów w JIRA. Sprint trwa ok. 1-2 tygodni i podpięte są pod niego zadania wycenione wcześniej przez deweloperów. W razie opóźnień zadania są przepinane na kolejny Sprint, jednak lepiej jest ogarniać te z większym priorytetem oczywiście. Najgorsze w tym wszystkim jest (w zależności od wielkości teamu) znalezienie chętnego do naprawiania błędów 😉

    Reply
    • 2 lutego 2016 at 21:48
      Permalink

      dzięki za komentarz 🙂

      pewnie jako statystyki sprintu generujecie wykres burndown?
      jak estymujecie zadania? Po prostu czas czy wagi?

      Reply
  • 21 lutego 2016 at 12:28
    Permalink

    Panie Karolu, świetny wpis pokazujący pułapkę jaką jest procentowe przedstawianie stanu ukończenia projektu. O ile w projektach IT lub innych inżynieryjnych dość łatwo jest znaleźć wąskie gardło i zmienić sposób pomiaru – o ile oczywiście PM sobie to uświadomi – o tyle dużo trudniej wskazać takie elementy w projektach biznesowych. Tutaj zwyczajowo termin jest głównym determinantem, a nie estymacja poszczególnych zadań. Zgadzam się także w pełni z panem, że nie forma raportu jest ważna, a skala jaką stosujemy. Najlepszym rozwiązaniem jest prezentowanie w czasie rzeczywistym stanu wykonania pracy, komunikacji prowadzonej przez zespołu w kontekście zadań. Odpuśćmy sobie raporty – pokazujmy pracę!

    Reply
    • 21 lutego 2016 at 15:04
      Permalink

      Dziękuję za komentarz!
      Jeśli chodzi o prezentowanie postępu w czasie rzeczywistym, doskonale sprawdza się Kanban. Jednym rzutem oka można ocenić wiele czynników.
      Również nie jestem zwolennikiem tworzenia raportów, z których nic nie wynika i są tworzone na zasadzie “sztuka dla sztuki”. 🙂

      Reply
  • 20 kwietnia 2016 at 22:20
    Permalink

    Naprawdę jednym z kluczowych zagadnień w PM, jest mierzenie zawansowania projektu. Jak mawiał Ely Goldratt- powiedz jak będziesz mierzony a powiem ci jak bedziesz sie zachowywał. Blędne przyjecie miary (np, stopień juz wykonannych prac) często prowadzi na manowce, a w konsekwencji do porazki projektu. A wiemy ,że projekt jest po cos organizacji, więc “koszty” bedą dożo większe, ciekawy wpis, pozdrawiam

    Reply
    • 21 kwietnia 2016 at 09:10
      Permalink

      Dokładnie! To zjawisko według mnie możemy zaobserwować w szkołach i uczelniach. Studenci na egzaminie starają się wpasować w klucz odpowiedzi. Można dostać 5.0 z egzaminu znając materiał po łebkach, a nie rozumieć go i nie potrafić wykorzystać. Ludzie zupełnie tak samo postępują z zarządzaniem projektów. “Powiedz mi co będziesz sprawdzał, a będę na to zwracał uwagę”.

      Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *