Techniki estymacji – jak to zrobić dobrze #2

Techniki estymowania

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 (ang. Bottom-up Estimating) – jest techniką 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.

WBS

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.

Więcej wpisów autora: Maciej Bieniasz

Współpraca vs. autonomia – jak zapewnić właściwy balans w rozproszonych zespołach?

Ostatnio w pracy miałem okazję przygotować prezentację pt. “Współpraca vs autonomia – Jak...
Czytaj dalej

Dodaj komentarz

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