Czas na kolejną, drugą część artykułu w ramach serii dotyczącej procesu estymacji. W poprzednim artykule opisałem czym jest proces estymacji i jak się przekłada na harmonogram prac. W tym weźmiemy pod lupę techniki estymacji. Ich znajomość pomoże Ci wybrać tę, która najbardziej pasuje do potrzeb Twojego projektu i przede wszystkim momentu, z którego startujesz. Większość project managerów pewnie zgodzi się ze mną, że konieczność oszacowania czasu trwania projektu pojawia się szybciej niż szczegółowe wymagania do niego.
Techniki estymacji wg PMBOK
W momencie przystępowania do estymowania czasu project manager powinien posiadać dane wejściowe, które pozwolą mu zdecydować, w jaki sposób podejść do estymowania. Umiejętność wykorzystania właściwej techniki estymacji w konkretnym przypadku może mieć duży wpływ na ocenę czasu trwania projektu. Mowa tu o technikach takich jak:
- Metoda ekspercka (ang. Expert Judgement),
- Estymowanie przez analogię (ang. Analogous Estimating),
- Estymacja parametryczna (ang. Parametric Estimating),
- Trzy-punktowa estymacja (ang. Three Point Estimating),
- Estymowanie od dołu do góry (ang. Bottom-up Estimating).
Zaczynamy! :)
Metoda ekspercka
Jest jedną z najprostszych metod wykorzystywanych do estymowania. W procesie szacowania biorą udział eksperci z danej dziedziny (ang. SME – Subject Matter Experts). W projekcie informatycznym mogą to być doświadczeni programiści, architekci lub liderzy techniczni. Osoby te, bazując na swoim doświadczeniu i wiedzy, szacują (wspólnie lub indywidualnie) przybliżony czas trwania projektu lub poszczególnych zadań. Zwykle ocena eksperta wymaga wiedzy specjalistycznej, która nie jest obecna w zespole projektowym, dlatego też grupa zewnętrzna lub osoba z określonymi umiejętnościami i doświadczeniem jest często proszona o konsultację.
Musimy najpierw zdefiniować zakres prac podlegających szacowaniu, następnie powinniśmy zidentyfikować ekspertów, np. doświadczonych programistów w organizacji, którzy mieli możliwość napisania podobnej usługi. Warto stworzyć dla nich pomocniczą listę pytań i założeń, która zwróci ich uwagę na konkretne zagadnienia. Po zapoznaniu się z dokumentacja i przeanalizowaniu aktualnego kodu aplikacji, eksperci przedstawiają orientacyjną estymację czasu trwania projektu. Mogą to robić wspólnie lub analogicznie do poker planningu – każdy z nich może przestawić własne szacunki (częściowe lub całościowe), które potem są wspólnie dyskutowane, co daje wiele korzyści, np. wychwycenie ewentualnych braków w wymaganiach czy rozstrzygnięcie niejasnych kwestii już na poziomie estymowania.
Przykład: wirtualizacja sieci bezprzewodowej w technologii telekomunikacyjnej 5G.
Musimy dokonać estymacji projektu, który został zlecony ze strony biznesu. Wyłaniamy ekspertów z naszej firmy. Każdy z nich w oparciu o ten sam zestaw wymagań podjął się estymacji indywidualnie. Po otrzymaniu końcowych szacunków, konfrontujemy je ze sobą. I tak kolejno:
- Ekspert A oszacował, że czas realizacji projektu wyniesie 122 dni roboczych;
- Ekspert B twierdzi, że projekt wymagać będzie 250 dni roboczych;
- Ekspert C jest najbardziej optymistyczny i ocenił, że projekt zakończymy w 100 dni roboczych.
Jak widzicie, rozbieżności mogą być duże i wierzcie mi – takie się zdarzają. Eksperci spotkali się wspólnie, aby omówić założenia jakie stoją za ich estymacjami. W toku dyskusji udało im się wspólnie “uszczelnić” zakres prac i przyjąć te same założenia. Ostateczna estymacja to 180 dni.
Zalety:
- jest szybką metodą przedstawiania wstępnych estymacji projektowych,
- metoda może być wykorzystana, gdy wiedza na temat projektu jest niepełna,
- pozwala szybko ocenić czy dany projekt może zostać zaimplementowany w danej aplikacji – dać zielone światło do dalszych działań;
- pozwala skonfrontować kilka różnych podejść w implementowania danego projektu;
- daje możliwość przygotowania innowacyjnego podejścia do implementacji projektu;
- pozwala uniknąć tzw. “odkrywania koła na nowo”.
Wady:
- wymaga posiadania doświadczonych ekspertów pracujących w danej domenie;
- w momencie złego prowadzenia spotkania technika ta może być bardzo czasochłonna;
- eksperci mogą mieć tendencje do niedoszacowania/przeszacowania danego zakresu prac.
Czujecie się przekonani do tej techniki estymacji? Bardzo podoba mi się spojrzenie na wpół eksperymentalne i na wpół naukowe na tę technikę, które znajdziecie w artykule firmy Octigo: “Mity na temat metody eksperckiej” oraz jego drugiej części.
Estymacja przez analogię
Podejście to, zwane również szacowaniem odgórnym (ang. Top-down Estimating) lub porównawczym, polega na porównaniu planowanego projektu z podobnym projektem zakończonym w przeszłości. Organizacja, podchodząc do estymacji przez analogię, powinna zebrać dane z analogicznych projektów, nad którymi pracowała. Im więcej wyestymowanych projektów posiada, tym lepiej dokonać można porównania i oszacować czas trwania nowego projektu. Ważne przy tym jest, aby podobieństwo do działań, które szacujemy, było rzeczywiste, a nie pozorne.
Przykład: migracja 30 GB danych ze starej bazy do nowej, umieszczonej w chmurze.
Przyjmijmy, że miesiąc temu zespół programistyczny zajmował się przenoszeniem 20 GB danych tylko pomiędzy fizycznymi bazami i zajęło im to tydzień. Tym razem dochodzi jeszcze niepewność związana ze środowiskiem w chmurze (przyjmijmy, że zespół nie ma z nim doświadczenia) oraz większa ilość danych – czas kopiowania danych będzie dłuższy. Zespół zakłada więc, że praca może zająć 1,5 x więcej czasu, a więc 1,5 tygodnia.
Do dokonania estymacji potrzebne nam były:
- specyfika obydwu projektów,
- ich podobieństwa i różnice,
- informacje na temat nakładu pracy.
Przy pomocy estymacji przez analogię możemy oszacować również koszt i budżet projektu.
Zalety:
- estymacja przez analogię jest najszybszą i najłatwiejszą metodą do przedstawienia zgrubnej estymacji – jak zauważyliście podczas wykorzystanie tej techniki estymacji nie wchodzi się w szczegóły implementacyjne;
- może być zastosowane w momencie, gdy nasza wiedza na temat projektu jest bardzo ogólna – dokonujemy porównania “na oko”;
- pozwala na spojrzenie na projekt jako całość.
Wady:
- brak możliwości zastosowania w całkowicie nowych projektach – musimy mieć możliwość odniesienia estymowanego projektu do podobnego w przeszłości;
- podobieństwo różnych projektów na pierwszy rzut oka może być mylne, co powoduje przekłamanie estymowanych wartości;
- opiera się na bardzo ogólnych danych, nie skupia się na detalach, które zasadniczo mogą wpłynąć na ostateczną estymację;
- musimy posiadać duży wachlarz projektów, aby można było łatwo dokonywać porównań pomiędzy nimi.
Estymacja parametryczna
To przykład podejścia, które bazuje na danych historycznych i zmiennych parametrach projektu. Podobnie, jak estymowanie przez analogię, pozwala szacować czas, koszt i budżet projektu.
Obydwie techniki estymacji wydają się na pierwszy rzut oka podobne, jednak parametryczna estymacja opiera się na znalezieniu wspólnej miary np. kosztu lub czasu trwania i możliwości ich skalowania; poszczególne obszary prac mogą być porównywane na podstawie wielokrotności jednostki.
Przykład: napisanie portalu umożliwiającego wynajem samochodów, z czterema podstronami, z wykorzystaniem bazy danych z funkcją udostępnienia jej dla innych użytkowników.
Zespół, który na co dzień zajmuje się tworzeniem stron, powinien mieć dobrze wyestymowane poszczególne aktywności i na podstawie ich oszacować przyszły zakres prac. Przykładowa lista zadań, która była potrzebna do wykonania podobnego zadania:
- konfiguracja bazy danych – 2 dni
- przygotowanie grafiki dla jednej podstrony – 3 dni
- wystawienie strony do użytku publicznego – 1 dzień
Sumując poszczególne aktywności zespół programistyczny może przewidzieć, że oddanie takiej strony internetowej będzie możliwe w terminie 15 dni:
- konfiguracja bazy danych – 2 dni
- przygotowanie grafiki – 4 podstrony x 3 dni = 12 dni
- wystawienie strony do użytku publicznego – 1 dzień
Zalety:
- estymacja parametryczna jest dokładniejsza niż estymowanie przez analogię;
- modele oparte na wcześniejszych doświadczeniach są łatwe do wykorzystania w podobnych projektach;
- łatwy do przewidzenia wynik estymacji, bazując na znanym modelu i danych wejściowych;
- estymacja oparta na modelu matematycznym zawsze przedstawi konkretny wynik.
Wady:
- metoda nie przewiduje niemierzalnych różnic pomiędzy projektami np. różnice kulturowe czy organizacyjne;
- nie można zmierzyć ilościowo każdego kosztu czy wydarzenia projektowego;
- brak elastyczności przy wyliczaniu poszczególnych obszarów prac.
Trzy-punktowa estymacja
Jest to technika, która wywodzi się z metody PERT (ang. Program Evaluation and Review Technique) i łączy podejście optymisty, pesymisty i realisty. Dokonujemy wyliczenia estymacji zadania, bazując na trzech wartościach: optymistycznej, pesymistycznej i najbardziej prawdopodobnej. Istnieją dwie formuły do szacowania trzy-punktowej estymacji:
1) Rozkład trójkątny (ang. Triangular Distribution) – jest najprostszym podejściem do estymowania, polegającym na wyliczeniu średniej z trzech wartości: pesymistycznej, optymistycznej i tej najbardziej prawdopodobnej. Podejście to powinno być zastosowane w przypadku, gdy zaczynamy projekt, który w przeszłości miał kilka podobnych inicjatyw z różnym czasem trwania. Szacowanie z rozmieszczeniem trójkątnym jest podstawowym podejściem do estymowania w technice trzy-punktowej.
E = (o + a + p) / 3
E – wyestymowany koszt
o – optymistyczna estymacja
a – najbardziej prawdopodobna estymacja
p – pesymistyczna estymacja
Przykład: Aktualny system e-commerce posiada wsparcie dla płatności online przy użyciu PayPal, a aktualne wymagania przychodzące z biznesu wymagają dodania wsparcia dla płatności przy użyciu Apple Pay. Dobrze się składa, ponieważ w departamencie obok znajduje się zespół, który już pracował nad implementacją Apple Pay i project manager z tego zespołu może zaoferować nam konsultacje w tym temacie oraz pomoc w estymacji przy użyciu trzy-punktowego szacowania. Z doświadczenia wiemy, że wszystkie trzy warianty mogą się wydarzyć z podobnym prawdopodobieństwem. A więc:
o – 5 dni
a – 7 dni
p – 14 dni
E = (5+7+14)/3 = 9 dni
2) Rozkład beta lub rozkład logarytmiczno-normalny (ang. Beta Distribution) – polega na wyliczeniu estymacji, bazując głównie na największym prawdopodobieństwie. Metoda ta jest preferowana w przypadkach, gdy mamy dużo danych historycznych i jest bardziej przydatna dla podobnych typów projektów. Do szacowania bierzemy pod uwagę projekty zakończone w przeszłości, z których większość miała zbliżony czas trwania (dla nas ten najbardziej prawdopodobny), a tylko część z nich odbiega od niego (wynik zarówno pesymistyczny, jak i optymistyczny). Jest to średnia ważona. Największą wagę kładzie się się na wartość najbardziej prawdopodobną, stąd 4a w równaniu.
Jeśli robimy projekt po raz pierwszy i nie ma wcześniejszej historii podobnych projektów, warto zastosować rozkład trójkątny, ponieważ nie ma podstaw do nadania większej wagi konkretnemu oszacowaniu.
E = (o + 4a + p) / 6
E – wyestymowany koszt
o – optymistyczna estymacja
a – najbardziej prawdopodobna estymacja
p – pesymistyczna estymacja
Przykład: wracamy do wcześniejszego przykładu z Apple Pay, z tym, że w tym przypadku wiemy, że większość projektów, które zostały zrealizowane do tej pory, zakończyły się w tym podobnym czasie. Właśnie dlatego wykorzystamy rozmieszczenie beta:
o – 5 dni
a – 7 dni
p – 14 dni
E = (5+4*7+14)/6 = 8 dni
Zalety:
- trzy-punktowa estymacja wspiera zarządzanie ryzykiem – jest to szacowanie przedziałowe, a nie punktowe;
- przedstawia najbardziej wiarygodne estymacje.
Wady:
- podejście wymaga dodatkowych informacji w celu określenia ryzyka, które w początkowych fazach projektu mogą być trudne do zdobycia;
- wymaga więcej czasu, aby zagłębić się dokładnie w estymowane zagadnienia.
Estymowanie od dołu do góry
Estymowanie od dołu do góry (ang. Bottom-up Estimating) to technika angażująca pracowników, którzy bezpośrednio będą pracować w danym projekcie. Zespół w tym podejściu pracuje wraz z project managerem w celu dokonania struktury podziału prac (ang. Work Breakdown Structure, w skrócie WBS). Jest to dekompozycja zakresu do poziomu pojedynczych zadań.
Szacowanie następuje tu na poziomie zadań, a następnie poszczególne estymacje są sumowane według struktury od dołu do góry aż dojdziemy finalnie do estymacji na poziomie całego projektu.
Przykład: przytoczony na początku artykuły – migracja 30 GB danych ze starej bazy do nowej, umieszczonej w chmurze.
Zespół dokonuje podziału prac, a w celu jej lepszej wizualizacji można przedstawić go w postaci prostego diagramu WBS (rys. 1). Każde zadanie najniższego poziomu posiada swoją estymację dokonaną przez zespół, np. utworzenie kopii zapasowej – 0,5 dnia. Sumujemy zadania do zadań grupujących, a te do zadań wyższego poziomu, w naszym wypadku już do poziomu najwyższego – do poziomu projektu. Dla naszego przykładu czas trwania projektu estymowany od dołu do góry wynosi 7,5 dnia.
Rys. 1. Struktura podziału prac
Zalety:
- zespół ma bezpośredni wpływ na estymację pracy, która będzie wykorzystywana do mierzenia ich postępów;
- końcowa wartość wyestymowanego projektu jest bardzo dokładna;
- wiedza wstępna dotycząca zakresu prac jest ustrukturyzowana i zrozumiana przez cały zespół.
Wady:
- wymaga dużego nakładu czasu;
- angażuje cały zespół projektowy w początkowych fazach projektu.
Podczas estymowania od dołu do góry project manager powinien pamiętać, żeby nie wywierać presji na zespole. Grupa, z obawy przed niedostarczeniem zadania w terminie, może celowo zawyżać czas trwania poszczególnych zadań, tworząc sobie tzw. bufor. Pod presją zespół może też nieświadomie pominąć kluczowe elementy w projekcie lub przyjąć niepoprawne założenia, co finalnie przełoży się na nierealną estymację czasu trwania projektu. Otwarta komunikacja w procesie estymacji jest kluczowa i pozwala na stworzenie dobrego planu działania, który w późniejszym czasie może być modyfikowany.
Podsumowanie
Techniki estymacji i ich znajomość są ważnym elementem podczas planowania czasu trwania projektu. Umiejętność dokonania właściwego doboru stanowi o doświadczeniu project managerów. Posiadanie wiedzy teoretycznej jest niewystarczające, dlatego warto praktykować, próbować nowych metod i unikać dobierania tej samej techniki estymacji do wszystkich projektów. Ze swojej strony zachęcam Cię do eksperymentowania i podzielenia się swoimi wnioskami.
W kolejnym artykule opiszę najczęstsze pułapki, w które może wpaść project manager podczas estymowania. Jeżeli masz jakieś pytania do przedstawionych wyżej przykładów, daj znać w komentarzu lub napisz w grupie “Zarządzam Projektami” na Facebook’u.
