Psychologia estymacji - dlaczego się mylimy

Podstawą rozwoju cywilizacji człowieka rozumnego są pomyłki - to na ich podstawie wyciągnął odpowiednie wnioski i dzięki temu jesteśmy w miejscu, w jakim jesteśmy.

Ale czy zastanawiałeś się kiedyś, dlaczego operujemy szacunkami? Co za tym stoi i jak zagadnienia psychologiczne wpływają na nasze podejście do estymacji?

Fakt, że człowiek woli szacować niż podawać konkretne liczby, znany jest od długiego czasu, szczególnie w psychologii. Ludzki mózg przetwarza ogromne ilości danych w tym samym momencie [1], więc segreguje informacje oraz optymalizuje proces ich przetwarzania. Szacowanie to dla mózgu sposób na uproszczenie zadania - mózg nie musi przeliczać ani dokładnie pamiętać danych liczbowych. Dzięki tej optymalizacji nie musi pracować na wysokich obrotach w codziennym życiu, ponieważ nasza percepcja czasu, odległości czy ilości działa głównie w sposób przybliżony, np. dużo, daleko, mniej więcej pół godziny.

W świetny sposób można to sprawdzić, prosząc dziecko o podanie rozmiaru kilku piłek. Dziecko będzie miało problem, żeby to określić i prawdopodobnie ucieknie się do mówienia o różnicach w ich rozmiarze. Natomiast gdy poprosisz dziecko, by ułożyło piłki od najmniejszej do największej - nie powinno mieć z tym żadnego problemu [2].

W branży IT tendencja do szacowania jest szczególnie wyraźna, a developerzy zazwyczaj omijają estymacje w godzinach, ponieważ:

• wiąże się to z ryzykiem pomyłki (a człowiek szacuje również z powodu uniknięcia stresu decyzyjnego [3]),

• środowisko nieustannie się zmienia,

• ułatwia zarządzanie ryzykiem interpersonalnym na linii zespół-klient,

• developerzy, podświadomie stosując fizjologię ANS (Approximate Number System), są w stanie na oko ocenić złożoność/rozmiar, np. w story pointach [4].

Wydawać by się mogło, że trzeba z tym walczyć. Otóż nic bardziej mylnego - okazuje się, że lepiej jest wykorzystać fizjologię niż z nią walczyć. Choć Agile (w tym SCRUM) nie został bezpośrednio oparty na psychologii poznawczej, w praktyce odpowiada na zjawiska opisane przez Janisa i Manna, takie jak unikanie stresu decyzyjnego czy wykorzystanie ANS [3]. Ramy Agile redukują presję na precyzję, promując przybliżenia i adaptacyjne podejście.

Wpływ autorytetu na szacowanie w zespole

Jednym z najczęstszych problemów w szacowaniu w grupie (podstawa SCRUM) jest niepodważalna decyzja osoby, która jest autorytetem/przywódcą grupy [2]. Może to być zarówno najlepszy programista, osoba z najdłuższym stażem, jak i osoba, która przejawia interpersonalne predyspozycje przywódcze czy autorytarne. Jeśli według tej osoby dane zadanie zajmie godzinę, mimo że każdy z pozostałych członków zespołu spędziłby nad nim dwa dni, to nikt nie sprzeciwi się na forum grupy, ponieważ reszta członków tłumi własne wątpliwości w celu konformizmu (groupthinking). Rezultatem tego będzie, zapisanie "godziny" przez SCRUM Mastera, co może być ewidentnym błędem estymacji już na samym jej początku. Jest to kolejne ciekawe zagadnienie psychologiczne, u którego podstaw leży słynny już eksperyment Milgrama [5].

Szczególnie jest to zauważalne, gdy w spotkaniach bierze udział przełożony, kierownik działu bądź szef. Członkowie grupy automatycznie dostosowują swoje odpowiedzi do jego opinii - nawet gdy jest ona błędna. Efektem zjawiska "Authority bias" jest brak szczerej dyskusji i presja zgodności z oczekiwaniami przełożonego [6]. Dodatkowo członkowie zespołu mogą mieć problemy z przeciwstawieniem się bądź powiedzeniem: "to będzie trudne" z powodu lęku zarówno przed negatywną oceną, jak i przed podważeniem kompetencji [7] [8].

Obecność przełożonego zwiększa również stres poznawczy, co pogarsza jakość osądów i decyzji oraz ogranicza working memory (wtedy zamiast rzetelnej analizy pojawia się reakcja: "co mam powiedzieć, żeby było dobrze?"). To z kolei skutkuje brakiem bezpieczeństwa w wyrażaniu niepewności, utratą przestrzeni do zadawania pytań i ujawniania wątpliwości [9] oraz - co najważniejsze - zaniżaniem estymat w obawie przed wyjściem na wolnego czy niekompetentnego.

To właśnie z tych powodów Agile/SCRUM jest jednym z najpopularniejszych modeli prowadzenia zespołów, ponieważ bazuje na psychologicznych aspektach. W SCRUMie promowane są estymacje prowadzone przez zespół developerski bez udziału osób decyzyjnych. PM może jedynie przedstawić kontekst, ale nie powinien sugerować konkretnych liczb.

Czym jest złudzenie planowania (planning fallacy)?

Planning fallacy to systematyczna tendencja ludzi do zaniżania czasu, kosztu i zasobów potrzebnych do wykonania zadania, nawet jeśli mają wcześniejsze doświadczenia, które przeczą tym optymistycznym szacunkom. Jest szczególnie zauważalna w mobile developmencie z powodu dynamicznie zmieniających się środowisk, trudnych do przewidzenia zależności (unknown unknowns) czy też presji szybkiego dostarczenia ficzerów/aplikacji.

Kilka przykładów:

• "Działa u mnie, więc pewnie działa wszędzie" - a potem zderzenie z różnymi wersjami Android/iOS, urządzeniami i edge case'ami na realnych urządzeniach.
• "Biblioteka to załatwi" - a potem niekompatybilność wersji, błędy runtime.
• "Wystarczy to zmienić tylko na backendzie" - a potem rozsypane hooki, przebudowa cachingu i ogólne problemy z offline mode.
• "Robiliśmy już coś takiego ostatnim razem, to teraz pójdzie szybciej" - ignorowanie historycznych danych; mimo napotkanych opóźnień zespół wierzy, że tym razem się uda.

Skoro wiemy o tym zjawisku, dlaczego nadaj ono występuje w IT?

Z perspektywy developera widzę kilka powodów, dla których w IT nadal występuje planning fallacy. Jednym z głównych jest nadmierna wiara w to, że wszystko pójdzie idealnie, co prowadzi do ignorowania niejawnych zależności oraz historycznych danych, tworzy iluzję optymizmu i nie uwzględnia buforów bezpieczeństwa pozwalających na reakcję. Stworzyłem od zera już kilka komercyjnych projektów, w kilku innych byłem developerem odpowiedzialnym za utrzymanie i rozwój. Uwierzcie mi - nigdy nic nie jest idealnie, co nie znaczy, że nie staramy się, żeby tak było.

Kolejnym powodem, który dość często zauważam, jest złudna motywacyjna mgła, która dopada często młodych developerów, ale nie tylko. Wychodzimy z założenia, że powiedzenie, że to jest proste i zajmie mniej czasu, pokaże, że jesteśmy dobrymi developerami, a nas zmotywuje do produktywniejszej pracy (bo trzeba to zrobić w tym czasie). W efekcie, podczas gdy estymata się nie spełnia, spadają morale, narasta stres, developer przechodzi w tryb intuicyjny i robi "na szybko", aby tylko skończyć jak najszybciej. To skutkuje często nieprzetestowanym rozwiązaniem, które prędzej czy później i tak trzeba będzie naprawić i jeśli już stawia developera w jakimś świetle - to raczej negatywnym.

Bardzo duży wpływ na planning fallacy, w mojej ocenie, ma również wpływ efektu Dunninga-Krugera.

Efekt Dunninga-Krugera – błąd poznawczy polegający na tym, że osoby niewykwalifikowane w jakiejś dziedzinie życia mają tendencję do przeceniania swoich umiejętności w tej dziedzinie, podczas gdy osoby wysoko wykwalifikowane mają tendencję do zaniżania oceny swoich umiejętności [10].

W naszym developerskim świecie oznacza to ni mniej, ni więcej, że juniorzy uważają, że potrafią bardzo dużo, a seniorzy wiedzą, ile nie wiedzą - przez co ci pierwsi zaniżają estymaty, a ci drudzy je wydłużają. Działa to z powodu dwóch kluczowych elementów: brak umiejętności skutkuje brakiem zdolności do rzetelnej samooceny, a rosnąca kompetencja skutkuje większą świadomością i krytycyzmem wobec siebie.

Jak deadline wpływa na jakość estymacji

Choć psychologicznie i procesowo jest to absurdalne, możesz spotkać się z deadlinem na estymację. Z definicji estymacja ma być oszacowaniem niepewności oraz czymś, co wymaga refleksji, analizy i rozmowy zespołu. Wprowadzanie ograniczeń czasowych wprowadza presję, która znacząco pogarsza jakość estymacji, sprzyja efektom wymienionym w poprzednich punktach (planning fallacy, groupthinking, efekt autorytetu, strach przed oceną) oraz zaburza samo założenie Agile.

Z perspektywy developera bądź zespołu postawionego przed takim oczekiwaniem to nic innego jak zgadywanie tego, co chce usłyszeć biznes - w znakomitej większości przypadków ma to potwierdzić własne założenia. W efekcie doprowadzamy do sytuacji: "daj mi liczbę, która zmieści się w narracji", a nie "daj mi realistyczne ryzyko projektu". Na koniec zawsze każdy na tym traci. Developerzy pod presją czasową przełączają się w tryb "szybko i na skróty", a nie "dokładnie i dobrze" [11]. Zwiększa się poziom stresu, co z kolei skutkuje zawężonym polem uwagi, obniżką zdolności do rozpoznania ryzyk i zależności oraz pojawieniem się efektu uproszczeń [12]. Zespół boi się przesadzić z dużą estymacją, tak by nie wyjść na wolnych i niewydajnych, o czym pisałem wyżej. W efekcie powstaje estymacja z zaniżonym kosztem czasu i zasobów, z niewykrytymi ukrytymi zależnościami i edge case'ami, która ma rażący wpływ na samego klienta i projekt.

Zamiast tego warto zacząć od ustalenia tego, jak estymujemy (bez udawania, że szybkie jest precyzyjne), robić eksploracje oraz operować na zakresach, a nie konkretnych datach i godzinach.

Podsumowanie

Szacowanie w IT to nie tylko planowanie, ale przede wszystkim psychologia. Nasze mózgi działają na przybliżeniach, a nie precyzyjnych wartościach - i to jest jak najbardziej normalne. Problemem jest nacisk na dokładność zespołu w niepewnym środowisku, pod presją czasu i autorytetów. Dobre estymowanie nie polega na podaniu konkretnej liczby - zakres lepiej uwzględnia zmienność, ryzyko i nieprzewidywalność. Nie można traktować tego jako słabość, tylko jako realizm.

Naukowo udowodniono, że wpływ osób decyzyjnych może nieświadomie zaniżać estymaty przez efekty autorytetu, groupthink czy strach przed oceną kompetencji.

Stworzenie warunków do eksploracji i szczerej rozmowy to najlepsze, co możemy zrobić. Estymaty powinny wynikać z refleksji i doświadczenia, a nie oczekiwań. Tylko wtedy mają realną wartość i mogą służyć zarówno zespołowi, jak i projektowi.

Literatura:

• Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review.
• Kaczor, Ł. (2020). Scrum i nie tylko. Teoria i praktyka w metodach Agile. Warszawa: PWN.
• Janis, I. L., & Mann, L. (1977). Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment.
• Dehaene, S. (2011). The Number Sense: How the Mind Creates Mathematics (Rev. and Expanded ed.). Oxford University Press.
• Wikipedia. (2024, June 26). Milgram experiment. https://en.wikipedia.org/wiki/Milgram_experiment. Accessed: July 28, 2025.
• Janis, I. L. (1972). Groupthink. Houghton Mifflin.
• Milgram, S. (1974). Obedience to Authority: An Experimental View. Harper & Row.
• Rosenberg, M. J. (1965). Cognitive structure and attitudinal affect.
• Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly.
• Wikipedia. (2024, July 17). Dunning-Kruger effect. https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect. Accessed: July 28, 2025.
• Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux.
• Hockey, A. (1993). Cognitive-energetical control under pressure. In A. Baddeley &
• L. Weiskrantz (Eds.), Attention: Selection, awareness, and control (pp. 328–345). Oxford: Clarendon Press.