Podobno wszyscy jesteśmy kiepscy w szacowaniu. I kiepski jestem również i ja. Mój kurs, który przygotowuję od kilku miesięcy ma kolejne opóźnienia (dokładne info wyślę wkrótce do tych co kupili go w przedsprzedaży) i postanowiłem z tej okazji przyjrzeć się bliżej temu zjawisku.

Dlaczego szacowanie jest trudne

Przyczyn jest wiele. Często przeszacowujemy naszą wiedzę i podobnie jak w przypadku efektu Dunninga-Krugera wygrywa nasza fałszywa pewność siebie przyprawiona dużą dawką optymizmu.
Szacowanie jest lepsze jeśli posiadamy więcej prawdziwych informacji. Tak jest w moim wypadku, gdyż nie miałem wystarczających informacji i przyjąłem tylko optymistyczne warianty bez uwzględnienia innych, czasem losowych czynników.

Co należy uwzględniać  przy szacowaniu

Głównie to czego nie wiemy i czego oszacować się nie da. Pewien mądry pan – Nassim Taleb – napisał o efekcie czarnego łabędzia i to doskonale pasuje do ostatnich wydarzeń, które wstrząsnęły naszym światem. Mówię tu o pandemii COVID-19 i wojnie w Ukrainie.
Takie rzeczy zdarzają się bardzo rzadko, ale tak jak awarie na naszych systemach prędzej czy później nastąpią. I wtedy nasze plany muszą być odpowiednio dostosowane.
W projektach jak mój warto wziąć pod uwagę przypadki losowe takie jak choroby czy też dołki i objawy wypalenia. Nie wiedziałem o tym przed, a teraz będzie to bardzo ważny składnik przy szacowaniu kolejnych prac.

Jak poprawić trafność estymacji

Nie mamy wpływu na zdarzenia losowe więc te niezależnie wpływają na nasze plany z pewnym prawdopodobieństwem ich wystąpienia (zależne od naszego stosunku do ryzyka).
To na co mamy wpływ to nasza wiedza. Im mamy jej więcej tym szacowania są dokładniejsze. W świecie IT to właśnie odróżnia ludzi na stanowiskach juniorskich od seniorskich. Ci pierwsi są nad wyraz optymistyczni i przeszacowuja swoją wiedzę. Seniorzy czy eksperci widzieli więcej i stąd ich wiedza pozwala im dokładniej określać ramy czasowe projektów. To często jest podważane przez niecierpliwych menedżerów projektów, ale często jest po prostu dokładniejszym określeniem trudnej rzeczywistości. Z resztą taki hurra optymizm może być katastrofalny w skutkach co pokazała ostatnia tragedia z batyskafem Titan.
Ja jestem jeszcze juniorem w szacowaniu tak rozległych prac na kursem i stąd od początku używam narzędzia (Toggl Track) do śledzenia każdej minuty poświęconej na prace. Dzięki temu wiem dokładnie ile zajmuje każdy aspekt prac, a dzięki temu przestanę być juniorem, bo będę miał doświadczenie poparte dokładnymi danymi. Brawo dla mnie 😅

Szacowanie dla aplikacji i systemów

W przypadku aplikacji jest trochę łatwiej. Tam projektujemy nieprzewidywalność w postaci wielu stopni redundancji (Design for failure). Jeśli robimy to dobrze i testujemy wywołując te awarie sztucznie przed ich prawdziwym wystąpieniem to możemy być całkiem nieźle przygotowani.
Co do planów dotyczących wydajności to mamy wspaniałe narzędzia do ogarniania tego. To wszelkiego rodzaju mechanizmy autoskalowania. I nie dotyczy to tylko kontenerów i Kubernetesa. U dostawców chmury bez problemu wyskalujemy się czy to na serverless czy na tradycyjnych maszynach wirtualnych.
Nasze systemy też się uczą poprzez gromadzenie danych z metryk. To również sprzyja lepszemu szacowaniu i przygotowaniu na zwiększone użycie usług. Połączenie danych i skalowania daje nam proaktywne podejście, które jest efektywniejsze i tańsze.
Bo wiadomo – z komputerami jest łatwiej. To my z reguły jesteśmy tym trudniejszym kawałkiem układanki.