Niedokładne szacunki są jednym z najpopularniejszych wyzwań związanych z zarządzaniem projektami. Rozpoczynając nowy projekt IT, chcesz wiedzieć dwie rzeczy: jak długo to potrwa i ile będzie kosztować. Aby odpowiedzieć na te pytania, musisz oszacować projekty, które zamierzasz uruchomić. Nie ma magicznej reguły, która mówi, że projekt X trwa 12 tygodni i kosztuje $150,000. Lub strona internetowa podobna do Y zajmuje 10 tygodni i kosztuje $100,000.
Czego dowiesz się z tego artykułu:
- Jak kierownicy projektów przygotowują się do szacowania kosztów w zarządzaniu projektami?
- Które techniki szacowania są przydatne do szacowania projektów?
- Jak wygląda planowanie, aby przygotować się do szacowania kosztów za pomocą formuł?
Nie można ocenić harmonogramu lub kosztów projektu bez dokładnego oszacowania, nawet jeśli zakres projektu jest bardzo podobny do tego, co robiłeś wcześniej. Ale jest jeszcze gorzej: szacowanie nigdy nie da ci dokładnej odpowiedzi na te pytania. Dlaczego więc szacujemy? Ponieważ jest to jedyny sposób na przyjęcie założeń dotyczących harmonogramu i budżetu projektu, obciążenia pracą i zasobów potrzebnych do jego realizacji.
Szacując projekt, możesz również zaplanować pracowników z odpowiednim doświadczeniem i umiejętnościami. To, co możesz z tym zrobić, to użyć metodologii i technik, które pozwolą Ci oszacować z maksymalną możliwą dokładnością. Oto jak wykorzystać metodologię Agile i technikę Planning Poker do tworzenia znaczących szacunków projektu.
James Grenning opracował w 2002 r. sesję pokera planistycznego znaną jako Scrum poker. Jego metoda szacowania, Wide band Delphi, była zbyt czasochłonna i miała inne ograniczenia. W przypadku Grenninga, plan pokera pierwotnie dotyczył rozwiązania problemu, w którym gracze byli zbyt podekscytowani i nadmiernie skupieni, aby wygrać. Mike Cohn, założyciel Agile Alliances i Scrum Alliances, wykorzystał później tę technikę w artykule zatytułowanym Agile Estimation and Planning.
Rozpoczęcie udanego projektu zależy głównie od tego, jak dobrze rozumiesz, o co w nim chodzi. Obejmuje to:
- Zrozumienie oczekiwań klienta
- Zrozumienie założeń projektu i jego głównego celu
- Tworzenie listy wymaganych funkcji
Po zapoznaniu się z briefem klienta i uzyskaniu jak największej ilości informacji na temat wymagań projektu, możesz wymienić wszystkie funkcje i przekazać je swojemu zespołowi.
Aby to zrobić, utwórz rejestr produktu, który składa się ze wszystkich funkcji do zrobienia. Następnie możesz nadać im priorytety, ocenić ich złożoność i oszacować, ile czasu zajmie ich ukończenie. Prawidłowy backlog produktu powinien składać się z:
- Historyjki użytkownika - opisują działania, które użytkownicy mogą podjąć na każdym etapie korzystania z produktu.
- Kryteria akceptacji - lista elementów wymaganych do ukończenia wątku.
- Punkty fabularne - oszacowanie ilości pracy, ryzyka i złożoności we względnej wartości punktowej.
- Zadania dla historyjek użytkownika - lista zadań, które należy wykonać w celu dostarczenia historyjki użytkownika.
Kluczowe jest zaangażowanie zespołu programistów w tworzenie i ustalanie priorytetów zaległości produktowych, aby zapewnić dokładne i realistyczne oceny.
Mając gotową listę funkcji, przypisz priorytet do każdej z nich. Możesz użyć metody analizy MoSCoW, aby posortować je jako:
- Musi posiadać
- Powinien mieć
- Mógł mieć
- Nie będzie
Rozwijając projekt, skup się na rzeczach, które musisz dostarczyć w pierwszej kolejności. Zbudowanie MVP daje możliwość przetestowania hipotez dotyczących pomysłu przed ukończeniem całego projektu, pokazania go interesariuszom lub użytkownikom wersji beta i zebrania opinii ważnych dla dalszego rozwoju pozostałych funkcji.
Przypisanie priorytetu może również pomóc w oszacowaniu projektu. Skupiając się na głównych funkcjach i tych, które należy wykonać w pierwszej kolejności, można przyjąć dokładniejsze założenia dotyczące ich szacowanego ukończenia. W przypadku funkcji, które "można mieć", można zacząć od szacunków, ponieważ są one na dalszym etapie procesu rozwoju i wiele może się zmienić, zanim zespół do nich dotrze (i jeśli zespół do nich dotrze, ponieważ po zebraniu opinii na temat MVP można zmienić i nie uwzględniać wszystkich początkowo planowanych funkcji).
Ważne jest jednak, aby oszacować wszystkie funkcje, niezależnie od ich priorytetu (oczywiście z wyjątkiem tych, które "nie będą miały"), ponieważ chcesz uzyskać przegląd całego projektu na raz. W miarę przechodzenia do kolejnych etapów projektu można ponownie ocenić zakres prac, aby upewnić się, że szacunki pozostają dokładne.
Teraz, gdy masz już ukończony backlog produktu, nadszedł czas, aby oszacować każdy z jego elementów. Aby to zrobić, używamy story points. Są to jednostki używane przez zespoły Agile do oceny pracy potrzebnej do ukończenia każdego elementu z zaległości. Story points pomagają przypisać względną wartość do elementów zaległości produktowych. Nie są one związane z czasem i mogą mieć różną wartość dla różnych zespołów, więc nie mają wartości emocjonalnej. W związku z tym istnieje szansa, że członkowie zespołu nie będą zawyżać szacunków tylko po to, by być bezpiecznym. Planowanie Pokera pomaga zespołom programistycznym planować przepływy pracy i poprawiać wskaźniki realizacji projektów.
Korzystając z punktów fabularnych, zespół może oszacować:
Planning Session to jedna z technik szacowania na poziomie brutto, wykorzystująca zmodyfikowaną wersję sekwencji Fibonacciego: 1, 2, 3, 5, 8, 13, 20, 40, 100. Aby oszacować pozycje z zaległości produktowych, członkowie zespołu otrzymują te same zestawy kart do pokera z numerami. Następnie, po krótkim wprowadzeniu elementu zaległości produktowych przez Właściciela Produktu (który nie głosuje) i dyskusji, prywatnie wybierają kartę z liczbą punktów historii, które uważają za istotne dla ilości pracy wymaganej do ukończenia tego elementu i ujawniają je w tym samym czasie.
Jeśli liczby się różnią, członkowie zespołu dyskutują, dlaczego wybrali taką liczbę punktów historyjki, a następnie głosują ponownie. Jest to część procesu planowania pokera, metody szacowania opartej na konsensusie stosowanej w Agile do szacowania wysiłku dla historyjek użytkownika. Robią to, dopóki nie osiągną konsensusu, a następnie przechodzą do następnego elementu z zaległości produktu. A jeśli uzgodniona liczba jest wysoka, powiedzmy 20, 40 lub więcej, oznacza to, że historia może wymagać zbyt wiele pracy na jeden sprint i może wymagać podziału na mniejsze zadania. W idealnej sytuacji prezentacja elementu, dyskusja i głosowanie powinny zająć około dwóch minut, co pozwoli na oszacowanie całego backlogu w krótkim czasie. Ponieważ jednak chodzi tutaj o oszacowanie całego backlogu naraz, nie spiesz się i nie martw się, gdy ocena niektórych historyjek zajmie trochę więcej czasu.
Prędkość zespołu pokazuje, jakie jest tempo rozwoju projektu. Pomaga zrozumieć dwie rzeczy:
- Ile pracy zespół jest w stanie wykonać w jednym sprincie?
- Jaka jest przewidywana data ukończenia całego zakresu, zakładając, że jest on ustalony?
Prędkość jest inna dla każdego zespołu. Można ją ocenić po początkowych iteracjach, gdy zespół pracował już nad niektórymi funkcjami. Na przykład, jeśli w pierwszej iteracji uwzględniono cztery elementy rejestru produktowego o łącznej liczbie 20 punktów historii, a zespół ukończył trzy z nich, co daje 15 punktów historii, jest to aktualna prędkość zespołu. Pamiętaj, że liczą się tylko ukończone elementy. Nawet jeśli udało im się rozpocząć czwarty element, ale go nie ukończyli, to się nie liczy.
Scrum Master odgrywa kluczową rolę w ułatwianiu procesu szacowania i zapewnianiu dokładnych ocen podczas tych sesji.
Po wynegocjowaniu story pointów i ocenie tempa pracy zespołu można określić harmonogram projektu. Aby to zrobić, zsumuj prędkość zespołu z ostatnich trzech iteracji i podziel ją przez trzy. Na przykład, jeśli prędkość z tych iteracji wynosiła 20, 23 i 17, średnia prędkość wynosiłaby około 20 punktów. Jeśli całkowita ilość pracy została oszacowana na 100 punktów fabularnych, to przy średniej prędkości wynoszącej 20 punktów ukończenie projektu zajęłoby 5 iteracji. Zakładając, że jedna iteracja trwa dwa tygodnie, projekt powinien zostać ukończony w ciągu 10 tygodni.
Aby określić budżet projektu, można użyć tego podstawowego wzoru: (całkowita liczba Story Points / Velocity * godziny pracy zespołu na sprint) + koszty pozapracowe = szacowany budżet. Mając całkowitą liczbę story points podzieloną przez średnią prędkość, pomnóż liczbę sprintów przez 40 godzin tygodniowo na członka zespołu, aby uzyskać koszt pracy. Następnie dodaj koszty pozapracowe, takie jak koszty kapitałowe, koszty sprzętu, koszty utrzymania, koszty szkoleń itp. Na przykład, mamy projekt szacowany na 100 story points, a średnia prędkość naszego zespołu wynosi 20. Przypisując 5-osobowy zespół do projektu ze stawkami godzinowymi $50, godziny pracy zespołu na sprint są warte $20,000 i $100,000 dla 5 sprintów. Przy hipotetycznych kosztach innych niż robocizna w wysokości $50,000, szacowany budżet naszego projektu wyniósłby $150,000. Biorąc pod uwagę przedziały ufności na przykładowych poziomach 80-120%, raportowany zakres naszego budżetu wynosi teraz od $120,000 do $180,000.
Pamiętaj, że żadne oszacowanie nie jest dokładne w 100%. Najlepiej jest ponownie oszacować swój projekt co kilka iteracji, ponieważ rzeczy, takie jak dostępność zasobów, tempo pracy zespołu lub zakres projektu, mogą się zmieniać w czasie. Ponownie szacując, upewniasz się, że szacunki są aktualne. Korzystanie z oprogramowania do śledzenia czasu i planowania zasobów pomoże również zarządzać dostępnością zespołu i w razie potrzeby ponownie przydzielić go do pracy. Dzięki odpowiednim technikom i narzędziom możesz sprawić, że Twoje szacunki będą bardziej wiarygodne i lepiej zaplanować następny projekt.
Dokładne oszacowanie projektu ma kluczowe znaczenie dla skutecznego zarządzania projektem. Rozumiejąc oczekiwania i cele, tworząc szczegółowy rejestr produktu, ustalając priorytety funkcji i stosując techniki takie jak story points i Planning Poker, można poprawić dokładność szacunków. Regularne ponowne szacowanie i korzystanie z narzędzi do śledzenia czasu i zarządzania zasobami dodatkowo zwiększa wiarygodność harmonogramów i budżetów projektów. Postępując zgodnie z tymi praktykami, można przezwyciężyć wyzwania związane z niedokładnymi szacunkami i zapewnić lepsze wyniki projektu.
Z łatwością korzystaj z techniki szacowania Planning Poker
Sprawdź, dlaczego nasze oprogramowanie do zarządzania zasobami jest wybierane przez kierowników projektów z Hill-Knowlton czy Stormind Games
Kalendarz zasobów (lub kalendarz zarządzania projektem, lub kalendarz planowania projektu, oprogramowanie do planowania zasobów) pozwala planować i zarządzać zasobami oraz przydzielać je bardziej efektywnie i wydajnie - zwłaszcza jeśli Microsoft Excel odgrywał wiodącą rolę w...
Jaki jest ostateczny cel kierowników projektów? Pomyślna realizacja projektów. Sami kierownicy projektów przyznają, że nie zdarza się to zbyt często: zgodnie z najnowszym badaniem Pulse of the Profession, mniej niż 60% projektów zostaje ukończonych ...
Zarządzanie zdolnościami produkcyjnymi to strategia wykorzystywana przez firmy w celu jak najlepszego wykorzystania wydajności produkcji w odniesieniu do popytu na usługę lub produkt. Ostatecznym celem zarządzania zdolnościami produkcyjnymi jest: Identyfikacja i...