Problemy z estymatami projektów IT

Estymata projektów IT, to próba określenia, jakie funkcjonalności powinien zawierać produkt, aby dostarczyć wartość użytkownikom i spełnić oczekiwaniami klienta, jaki jest poziom skomplikowania poszczególnych funkcjonalności i ile może zająć ich implementacja, a co za tym idzie, jaki jest prognozowany koszt realizacji projektu. Estymata projektów IT jest trudne. Jednocześnie szacowanie jest niezbędne, by móc podjąć strategiczne decyzje biznesowe dla danego przedsięwzięcia. Pozwala określić, czy dany projekt jest wart realizacji, czy trafi do użytkowników w odpowiednim oknie rynkowym i czy jest najlepszym rozwiązaniem danego problemu. 

Estymata – najczęstsze problemy

1. Problem z uzyskaniem dokładnej oceny na etapie pierwszej estymaty

Wiedza o projekcie i wiedza o produkcie rosną w trakcie realizacji projektu. Zakładając, że projekt jest realizowany w oparciu o metodyki zwinne, każdy sprint dostarcza nam nowych informacji o produkcie i projekcie. O projekcie, czyli o zespole, o wspópracy, o mocnych i słabych stronach zespołu, itp. Na początku ta wiedza jest niewielka, a co za tym idzie, niepewność jest duża.

Już na początku lat 80. ubiegłego wieku stworzono pierwszą wersję tego, co pod koniec lat 90. zostało nazwane “stożkiem niepewności”. Pokazuje on, że na etapie pierwszej estymaty ocena zwykle waha się między 60 a 160%. Z mojego dotychczasowego doświadczenia wynika, że częściej to jest bliżej 160% niż 60%. PMI sugeruje nawet, że zakresy powinny być następujące: 75% – 175%. Stożek ten zwęża się wraz z postępem realizacji projektu. Po kilku sprintach, kiedy nasza wiedza o projekcie i produkcie jest większa, pierwotne szacunki powinny być reestymowane. Dzięki ciągłej inspekcji i adaptacji interesariusze projektu mają transparenty obraz sytuacji. To wpływa na jakość relacji, jaką budujemy z nimi i na wzrost zaufania z ich strony. Unikamy tego, że po kilku miesiącach pracy będą zaskoczeni tym, ile jeszcze zostało do zrobienia, a więc jaki jest potrzebny dodatkowy czas na realizację projektu i dodatkowe środki finansowe. 

Dla przykładu, jeśli na tym etapie uzyskamy estymatę 25 tygodni, to ze stożka niepowności można przyjąć, że prace potrwają między 15 a 40 tygodni.

2. Estymata jako konkretna wartość, nie jako zakres

Punkt ten wiąże się dość ściśle z pierwszym. Bardzo często zdarza się, że do uzyskanej estymaty, np. metodą ekspercką dodawana jest konkretna wartość, np. 20%, jako bufor. Klient wówczas otrzymuje informację, że realizacja danego projektu zajmie około X roboczodni. Podanie jednej konkretnej wartości może u klienta rodzić przekonanie, że jest to nasze zobowiązanie, ponieważ podajemy konkretną liczbę. 

Zobaczmy to na przykładzie. Estymata ekspercka wynosi 100 roboczodni (MD), rodzaj rozliczenia to time & material. Dodano do niej bufor 20%, więc estymata przekazana klientowi wynosi 120 MD. Po 130 MD okazuje, że nadal jeszcze potrzebny jest dodatkowy czas na dokończenie kilku zadań w projekcie. Szacuje się, że będzie to minimum 10 MD. Zapewne klient jest mocno zirytowany tym faktem, ponieważ spodziewał się, że projekt zamknie się w 120 MD. Tymczasem okazuje się, że już spalono 130 MD i jeszcze potrzebne są kolejne. Ile finalnie? Tego do końca nie wiadomo. Podejmując decyzję o realizacji tego projektu, nie miał jasnej informacji nt tego, ile pierwotna estymata może odbiegać od finalnej ilości MD koniecznych na zrealizowanie tego projektu. Prawdopodobnie swoją decyzję oparł o estymatę 120 MD i założył, że taki budżet może przeznaczyć na to przedsięwzięcie.

Jak wyglądałaby sytuacja, gdyby skorzystano tutaj ze stożka niepewności? Pierwotnie estymowane 100MD zostałoby przedstawione w przedziale 60 MD – 160 MD. Klient otrzymałby informację, że biorąc pod uwagę niepewność i obecną fazę, w której estymata jest dokonywana, projekt może kosztować nawet 160 MD. Znając graniczne wartości zakresu, może bardziej świadomie podjąć decyzję. Możliwe jest również wówczas opracowanie rozwiązania, które byłoby satysfakcjonujące dla klienta. Np. zrewidowanie zakresu, skorzystanie z bufora funckcjonalności, itp.

3. Estymata – jak ją komunikować

To, jak jest zakomunikowana estymata, ma ogromne znaczenie. Szczególnie duże dla klienta, który nie ma wiele wspólnego z branżą IT i może nie rozumieć, czym jest wycena projektu IT i jakie elementy na nią wpływają. Estymatę można porównać bardziej do prognozy pogody niż cennika u fryzjera. Sprawdzamy prognozę pogody – nawet tę długoterminową i robimy na jej podstawie plany, podejmujemy decyzję. Wiemy jednak, że prognoza nie daje nam gwarancji, że dokładnie taka pogoda będzie i nasz plan uda nam się zrealizować. To inaczej niż, kiedy idziemy do fryzjera i z góry znamy cenę, jaką będziemy musieli zapłacić za usługę. Nic nas tutaj nie zaskoczy na koniec – może poza efektem, czasami. Bardzo cenię transparentność, dlatego jasne przedstawienie klientowi estymaty jest dla mnie bardzo istotne. Klient powinien wiedzieć, że estymata to prognoza, a nie nasze zobowiązanie i znać zakres tej prognozy. 

4. Duży poziom niepewności

Wykonywanie szacunku projektu na samym jego początku jest trudne, ponieważ poziom niepewności jest bardzo wysoki. Niepewność, nie ograniczna się jedynie do tego, czego nie wiemy o aplikacji, którą chce robić klient. Oczywistym jest, że nie poznamy każdego jej detalu na tym etapie, a czasem taki detal ma duży wpływ na estymatę. Niepewność też indukują szybko zmieniające się rynki. Może się okazać, że wyceniany dziś element aplikacji, w momencie implementacji będzie wymagał przedefiniowania z uwagi na nowe okoliczności rynkowe. Przed ryzykiem niepowności można zabezpieczyć estymatę stosując np. bufor funkcjonalności i harmonogramu (więcej tutaj). Doskonale opisał je Mike Cohn w swojej książce “Agile estimating and planning”.

Nie bez znaczenia są tutaj 3 filary framworku scrum, a jednocześnie dość uniwersalne mechanizmy wykorzystywane w pracy w zmiennym środowisku: transparentność, ciagła inspekcja i adaptacja. Jeśli przyłożymy je w praktyce do estymat, będzie to oznaczało:

1. Weryfikowanie, wraz z postępem projektu i wzrostem wiedzy produktowej i projektowej, czy i w jaki sposób pierwotna estymata się zmienia względem nowo posiadanej wiedzy.
2. Jasne komunikowanie powyższego klientowi.
3. Szukanie najlepszego rozwiązania w odniesieniu do tego, co wykazała inspekcja.

Przegląd estymaty

Jak mogłoby to wyglądać w praktyce? Po dwóch – trzech pierwszych sprintach, kiedy już zyskamy nieco wiedzy o projekcie i zaczynamy lepiej rozumieć produkt, dokonujemy przeglądu pierwotnej estymaty. Jeśli okaże się, że np. funkcjonalność X i Y będzie wymagała większego nakładu pracy, niż założyliśmy pierwotnie, a tempo naszej pracy, na tym etapie, jest niższe niż zakładaliśmy, aktualizujemy odpowiednio wycenę. Zaktualizowaną wycenę jasno i klarownie przedstawiamy klientowi. Wspólnie z nim omawiamy, co można zrobić, by nadal móc osiągnąć cel i spełnić warunki satysfakcji projektu. Być może dla klienta nie będzie problemem zwiększenie finansowania projektu. Może konieczne będzie poszerzenie buforu opcjonalnych funkcjonalności, a być może niektóre funkcjonalności można np. uprościć.  Takie podejście pozwala nam sprawnie zarządzać ryzykiem projektowym i – co więcej – szybko je identyfikować i wdrażać środki zaradcze. Takie podejście również buduje zaufanie klienta do nas.

Przedstawione powyżej problemy zapewne nie wyczerpują tego tematu. Warto jednak w tym obszarze poszukiwać dobrych i sprawdzonych schematów postępowania. Odpowiednie podejście do estymat i odpowiednie zakomunikowanie ich klientowi, wpływa później na realizację projektu, nasze stosunki z klientem, a być może nawet naszą reputację jako firmy. 

Zachęcam Cię również do zajrzenia na stronę wpisu o buforze harmonogramu. Jest to bardzo ciekawe narzędzie wykorzystywane do opracowania niepewności w estymatach. Bufor harmonogramu opisuje w swojej książce “Agile estimating and planning” Mike Cohn.

Praktycznik
Jest to temat mocno “techniczny” i “branżowy”, jednak jestem pewna, że mechanizmy transparentości, ciągłe inspekcji i adaptacji, możesz wykorzystać w wielu dziedzinach życia. Możesz skorzystać z nich planując swoją ścieżkę kariery, czy rozwoju, ale także budując realacje z partnerem, czy dziećmi, a nawet próbująć zrzucić zbędne kilogramy, czy znaleźć najszybszy sposób na dotarcie do pracy! Zachęcam do eksperymentowania 🙂