„Ile to zajmie?" - pytanie pada na drugim spotkaniu projektu rejestracji online dla MediFlow. Kierownik patrzy na zespół wyczekująco. Młody analityk, chcąc zrobić dobre wrażenie, rzuca: „Miesiąc, góra półtora". Wszyscy notują. Cztery miesiące później projekt wciąż się toczy, budżet pęknięty o 60%, a tamto „miesiąc, góra półtora" wisi nad zespołem jak wyrok. Nikt nie pamięta, że to był strzał z biodra rzucony bez analizy - pamiętają tylko liczbę.
Estymacja to jedna z najbardziej niedocenianych i najczęściej psutych kompetencji analityka. Nie chodzi o wróżenie z fusów ani o magiczny wzór, który da dokładną liczbę. Chodzi o świadome, uzasadnione szacowanie nakładu pracy z jawnym przyznaniem, ile w tym niepewności. W tym artykule pokażę Ci techniki, które realnie działają, pułapki poznawcze, które rozkładają nawet doświadczonych, i jak rozmawiać o estymacie tak, żeby nie stać się zakładnikiem własnej liczby.
Estymacja to nie obietnica. To najlepsze oszacowanie na podstawie tego, co wiesz dziś - a dziś wiesz najmniej w całym projekcie. Kto myli estymatę z deklaracją terminu, ten zawsze przegrywa.
Po co w ogóle estymować
Estymacja jest paliwem decyzji. Bez niej nie da się odpowiedzialnie zaplanować zasobów, ustalić budżetu, ułożyć harmonogramu ani ocenić, czy projekt w ogóle się opłaca. Gdy MediFlow rozważa, czy budować rejestrację online samodzielnie, czy kupić gotowe rozwiązanie, decyzja stoi i upada na estymacie kosztu i czasu obu wariantów.
Estymacja służy też do priorytetyzacji. Jeśli wiesz, że funkcja „przypomnienia SMS o wizycie" to dwa dni pracy, a „integracja z systemem NFZ" to trzy tygodnie, możesz świadomie zdecydować, co wchodzi do pierwszej wersji. Bez estymaty priorytety ustawia się na wyczucie - a wyczucie zwykle myli się o rząd wielkości.
Techniki estymacji - kiedy którą
Nie ma jednej najlepszej metody. Wybór zależy od tego, ile masz danych, ile czasu i jak duża jest stawka. Oto techniki, które warto mieć w arsenale.
Estymacja ekspercka
Najprostsza i najczęstsza: pytasz osobę z doświadczeniem, ile czegoś zajmie. Działa, gdy ekspert faktycznie zna podobne zadania. Architekt, który wdrażał już trzy systemy rejestracji, oszacuje integrację z kalendarzem lekarzy lepiej niż jakikolwiek wzór. Słabość: subiektywizm i ryzyko, że „ekspert" nie zna akurat tego obszaru, ale wstydzi się przyznać.
Estymacja analogiczna
Porównujesz nowe zadanie do podobnego z przeszłości. „Poprzednia integracja płatności zajęła nam pięć tygodni, ta jest podobna, ale prostsza - szacuję cztery". Wymaga danych historycznych, ale jest szybka i zaskakująco trafna, jeśli analogia jest rzetelna. Pułapka: powierzchowne podobieństwo. Dwa projekty „rejestracji" mogą różnić się dziesięciokrotnie złożonością.
Estymacja trójpunktowa (PERT)
Tu robi się ciekawie, bo ta technika wymusza myślenie o niepewności. Zamiast jednej liczby podajesz trzy: optymistyczną (O - wszystko idzie gładko), najbardziej prawdopodobną (M) i pesymistyczną (P - wszystko, co może pójść źle, idzie źle). Wynik to średnia ważona:
Estymata = (O + 4 × M + P) / 6Przykład z MediFlow - integracja z zewnętrznym systemem płatności:
- Optymistycznie (O): 2 dni - dokumentacja API jest dobra, wszystko działa za pierwszym razem
- Najbardziej prawdopodobnie (M): 5 dni - drobne problemy z testowym środowiskiem
- Pesymistycznie (P): 12 dni - API ma niedokumentowane ograniczenia, trzeba czekać na wsparcie dostawcy
Estymata = (2 + 4 × 5 + 12) / 6 = 34 / 6 ≈ 5,7 dniaSiła PERT nie tkwi w samym wyniku, tylko w pytaniu „co takiego musiałoby się stać, żeby zajęło to 12 dni?". To pytanie wyciąga na wierzch ryzyka, o których inaczej nikt by nie pomyślał - i właśnie te ryzyka są cenniejsze niż sama liczba.
Estymacja od dołu (bottom-up)
Rozbijasz duże zadanie na drobne, szacujesz każde z osobna i sumujesz. Najdokładniejsza metoda, ale wymaga dobrze rozpisanych wymagań i sporo czasu. Rejestracja online rozbita na: ekran wyboru terminu (3 dni), logika rezerwacji (5 dni), integracja kalendarza lekarzy (4 dni), powiadomienia (2 dni), panel recepcji (6 dni) - suma daje 20 dni z konkretnym uzasadnieniem każdej składowej.
Story points i planning poker (zwinne podejście)
W zespołach zwinnych często nie estymuje się w czasie, lecz w punktach historii (story points) - jednostce względnej złożoności, nie godzin. Zadanie „2 punkty" jest mniej więcej dwa razy prostsze niż „5 punktów". Zespół szacuje wspólnie metodą planning poker: każdy w tajemnicy wybiera wartość, potem wszyscy odsłaniają jednocześnie. Rozbieżność (ktoś dał 2, ktoś 13) to sygnał, że ludzie różnie rozumieją zadanie - i właśnie ta rozmowa jest celem, nie sama liczba. Story pointy świadomie unikają złudzenia precyzji, jakie daje podawanie godzin.
| Technika | Kiedy stosować | Mocna strona | Słaba strona |
|---|---|---|---|
| Ekspercka | Mało czasu, jest ekspert | Szybka | Subiektywna |
| Analogiczna | Są dane historyczne | Szybka i trafna | Ryzyko fałszywej analogii |
| PERT | Duża niepewność, ważne ryzyka | Wymusza analizę ryzyka | Wymaga trzech ocen |
| Bottom-up | Dobrze rozpisane wymagania | Najdokładniejsza | Czasochłonna |
| Story points | Zespoły zwinne | Unika fałszywej precyzji | Trudna na zewnątrz zespołu |
Stożek niepewności - dlaczego wczesne estymaty są z gumy
Jest jedno zjawisko, które tłumaczy połowę nieporozumień wokół estymacji: stożek niepewności (cone of uncertainty). Na początku projektu, gdy wiesz najmniej, Twoja estymata może być nietrafiona nawet czterokrotnie - w jedną lub drugą stronę. W miarę jak projekt postępuje i wiedza rośnie, ten rozrzut się zawęża, aż pod koniec estymata jest niemal pewna (bo prawie wszystko już zrobione).
Wniosek jest dwojaki. Po pierwsze, estymata z pierwszego spotkania ma prawo być zgrubna - i tak należy ją komunikować, podając szerokie widełki, a nie jeden konkret. Po drugie, estymaty trzeba odświeżać. Trzymanie się liczby rzuconej na starcie, gdy wiesz już dziesięć razy więcej, to nie konsekwencja, lecz upór. We wstępie „miesiąc, góra półtora" zostało wyryte w kamieniu - i właśnie dlatego stało się wyrokiem. Gdyby zespół jawnie re-estymował co dwa tygodnie, rozjazd z rzeczywistością wyszedłby na jaw wcześnie, gdy dało się jeszcze zareagować.
| Etap projektu | Typowy rozrzut estymaty | Jak komunikować |
|---|---|---|
| Pomysł / wstępna koncepcja | nawet ×4 / ÷4 | Bardzo szerokie widełki, rząd wielkości |
| Po doprecyzowaniu zakresu | ±50% | Widełki z jawnymi założeniami |
| Po rozbiciu na zadania | ±25% | Estymata bottom-up z buforem |
| W trakcie realizacji | maleje z każdym sprintem | Bieżąca re-estymacja na danych zespołu |
Velocity - jak zespół zwinny estymuje na danych, nie na nadziei
Warto rozwinąć wątek story pointów, bo kryje się za nimi mechanizm, który rozwiązuje problem „skąd wiemy, ile naprawdę zajmie". Otóż zespół zwinny po kilku sprintach zna swoją prędkość (velocity) - średnią liczbę punktów, którą faktycznie domyka w jednym sprincie. Jeśli rejestracja online to oszacowane 80 punktów, a zespół domyka średnio 20 punktów na dwutygodniowy sprint, to projekt zajmie około czterech sprintów, czyli osiem tygodni.
Piękno tego podejścia polega na tym, że opiera się na rzeczywistych danych zespołu, a nie na deklaracjach. Nikt nie pyta „ile zajmie", bo odpowiedź wynika z historii: tyle punktów / taka prędkość. Velocity samo wchłania całą „pracę niewidzialną" (testy, spotkania, poprawki), bo była ona obecna także w poprzednich sprintach, z których prędkość policzono. To jeden z najskuteczniejszych znanych mi sposobów na ucieczkę od planning fallacy - bo zamiast wyobrażać sobie przyszłość, opierasz się na zmierzonej przeszłości.
Pułapki estymacji - głównie w głowie
Największe zagrożenia estymacji nie są matematyczne, tylko psychologiczne. To błędy poznawcze, na które podatny jest każdy - łącznie ze mną i z Tobą.
- Optymizm i planning fallacy. Ludzie systematycznie niedoszacowują, bo wyobrażają sobie scenariusz, w którym wszystko idzie gładko. Prawie nic nigdy nie idzie całkiem gładko. Lekarstwo: zawsze myśl też o scenariuszu pesymistycznym (stąd siła PERT) i patrz na dane historyczne, nie na własne nadzieje.
- Efekt zakotwiczenia (anchoring). Pierwsza usłyszana liczba zniekształca wszystkie kolejne. Gdy klient mówi „inny dostawca wycenił to na 50 tysięcy", Twój mózg zaczyna kręcić się wokół tej kwoty, nawet jeśli jest błędna. Lekarstwo: estymuj zanim usłyszysz cudze liczby, i świadomie kwestionuj kotwicę.
- Pominięcie pracy „niewidzialnej". Estymuje się kodowanie, a zapomina o testach, poprawkach, spotkaniach, dokumentacji, integracjach i wdrożeniu. W projekcie MediFlow zespół oszacował samą logikę rezerwacji, gubiąc dwa tygodnie na integrację z istniejącym systemem kartotek - bo „to przecież oczywiste". Nic nie jest oczywiste, dopóki nie jest na liście.
- Presja na konkret. Gdy szef naciska „daj mi jedną liczbę", łatwo podać ją bez analizy, byle przestał pytać. To prosta droga do wyroku ze wstępu. Lekarstwo: zawsze podawaj estymatę z widełkami i poziomem pewności, nigdy jako gołą liczbę.
- Brak danych historycznych. Firma, która nie mierzy, ile faktycznie zajmują jej projekty, estymuje na ślepo. Lekarstwo: po każdym projekcie zapisuj estymatę i rzeczywisty czas - po kilku projektach masz bezcenny zbiór analogii.
- Estymowanie pod oczekiwany wynik. Czasem zespół „dostosowuje" estymatę do terminu, który i tak jest narzucony. To nie jest estymacja, to życzenie. Lepiej jawnie powiedzieć „realnie to 8 tygodni, a mamy 6 - co tniemy z zakresu?".
Mini-case: estymacja rejestracji online MediFlow
Pokażmy podejście, które działa. Zamiast strzelać „miesiąc", analityk rozbija rejestrację online metodą bottom-up, a dla najbardziej niepewnych elementów stosuje PERT.
| Element | Metoda | Estymata |
|---|---|---|
| Ekran wyboru terminu | Analogiczna (był podobny) | 3 dni |
| Logika rezerwacji + obsługa konfliktów | Bottom-up | 5 dni |
| Integracja z systemem płatności | PERT (duża niepewność) | ≈ 6 dni |
| Powiadomienia (e-mail/SMS) | Ekspercka | 2 dni |
| Panel recepcji dla 12 przychodni | Bottom-up | 6 dni |
| Testy, poprawki, wdrożenie (bufor) | +30% reszty | ≈ 7 dni |
| Razem | ≈ 29 dni roboczych |
Różnica względem „miesiąc, góra półtora" jest pozornie niewielka - ale tylko pozornie. Ta estymata ma uzasadnienie dla każdej składowej, jawny bufor na pracę niewidzialną i wskazane ryzyko (integracja płatności). Gdy kierownik pyta „dlaczego tyle?", analityk pokazuje tabelę zamiast wzruszać ramionami. A gdy płatności faktycznie się posypią, nikt nie jest zaskoczony - to było w estymacie od początku.
Jak komunikować estymatę, żeby nie stać się jej zakładnikiem
Najlepsza technika estymacji nie pomoże, jeśli źle podasz wynik. Trzy zasady:
- Podawaj widełki, nie punkt. „Między 25 a 35 dni roboczych" jest uczciwsze i bezpieczniejsze niż „30 dni". Punkt sugeruje precyzję, której nie masz.
- Dołącz poziom pewności i założenia. „Szacuję ~29 dni, zakładając, że dokumentacja API płatności jest aktualna i mamy dostęp do środowiska testowego do piątku". Gdy założenie upadnie, estymata się zmienia - i wszyscy to wiedzą z góry.
- Re-estymuj, gdy wiesz więcej. Estymata z drugiego spotkania ma prawo być inna niż ta po dwóch sprintach. To nie porażka, to dojrzałość. Zespoły zwinne robią to świadomie - wczesne estymaty są zgrubne, później zawężają się wraz z wiedzą.
Estymacja z góry i z dołu - konfrontuj dwa spojrzenia
Doświadczeni analitycy rzadko ufają jednej metodzie. Najsilniejsza estymacja powstaje, gdy zderzysz dwa niezależne spojrzenia: z góry (top-down) i z dołu (bottom-up). Estymata z góry to szybkie spojrzenie na całość - „podobne projekty zajmowały nam około sześciu tygodni". Estymata z dołu to suma rozbitych zadań - „3 + 5 + 6 + 2 + 6 + bufor = 29 dni roboczych, czyli prawie sześć tygodni".
Gdy obie zbiegają się w podobnym miejscu - masz mocny sygnał, że estymata jest rozsądna. Gdy rozjeżdżają się drastycznie - to bezcenna informacja, że coś przeoczyłeś. Może analogia była fałszywa (ten projekt jest trudniejszy, niż się wydawało), a może w rozbiciu zgubiłeś całe zadanie (np. migrację danych). Rozjazd między top-down a bottom-up to nie problem do zignorowania, lecz najtańszy sposób na wykrycie luki, zanim stanie się kosztowna.
W MediFlow estymata z góry dała „około miesiąca", bottom-up dał 29 dni - zbieżność potwierdziła kierunek. Ale gdyby bottom-up wyszedł na 45 dni, byłby to sygnał: albo rozbicie zawiera coś, czego analogia nie obejmowała, albo analogia była zbyt optymistyczna. W obu przypadkach lepiej dowiedzieć się tego na etapie estymacji niż w połowie projektu.
Estymacja to nie jednorazowy akt
Wracam do tego, bo to najczęściej ignorowana prawda: estymacja jest czynnością powtarzalną, nie jednorazowym wyrokiem. Każdy zamknięty etap dostarcza nowych danych, które pozwalają zawęzić stożek niepewności. Profesjonalny zespół re-estymuje świadomie i komunikuje aktualizacje - „pierwotnie szacowaliśmy 29 dni; po dwóch tygodniach widzimy, że integracja płatności pójdzie szybciej, ale panel recepcji jest bardziej złożony, więc korygujemy do 32 dni". To nie objaw niekompetencji. To dowód, że ktoś faktycznie kontroluje projekt, zamiast trzymać się liczby rzuconej, gdy wiedział najmniej.
FAQ - estymacja w analizie biznesowej
Czym różni się estymata od deklaracji terminu?
Estymata to oszacowanie nakładu pracy na podstawie obecnej wiedzy, z wbudowaną niepewnością. Deklaracja terminu to zobowiązanie. Mylenie ich to najczęstszy grzech - estymata „około miesiąca" zamienia się w głowach interesariuszy w obietnicę „dokładnie 30 dni", a potem w pretensje.
Czy story pointy można przeliczyć na godziny?
Technicznie tak, dzieląc liczbę punktów przez prędkość zespołu (velocity), ale celowo się tego unika na poziomie pojedynczego zadania. Story pointy mają oddawać względną złożoność i unikać fałszywej precyzji godzin. Przeliczanie ich z powrotem na godziny zwykle psuje sens metody.
Jak estymować, gdy wymagania są niejasne?
Jeśli wymagania są mgliste, każda estymata będzie zgadywaniem. Lepiej jawnie podać szerokie widełki z dużym pesymistycznym scenariuszem (PERT to ułatwia) albo poprosić o czas na doprecyzowanie zakresu przed estymacją. Estymata bez jasnych wymagań to estymata fikcji.
Ile bufora dodawać na nieprzewidziane?
Nie ma uniwersalnej liczby, ale 20-30% na testy, poprawki i pracę niewidzialną to rozsądny punkt wyjścia przy projektach o umiarkowanej niepewności. Im więcej ryzyk i im mniej danych historycznych, tym większy bufor. Najważniejsze, by bufor był jawny, a nie ukryty „na zapas" w poszczególnych zadaniach.
Podsumowanie
Dobra estymacja to nie talent do trafiania w liczby, tylko dyscyplina: rozbij zadanie, dobierz technikę do poziomu niepewności, świadomie uwzględnij pracę niewidzialną i błędy poznawcze, a wynik podaj jako widełki z założeniami - nie jako wyrok. Analityk, który tak estymuje, nie staje się zakładnikiem rzuconej w pośpiechu liczby. Buduje za to coś cenniejszego: zaufanie, że jego szacunki da się traktować poważnie.
Estymacja łączy się z innymi kompetencjami analityka. Żeby rozbić projekt na elementy, musisz mieć dobrze opisane wymagania - zobacz specyfikację wymagań i jak pisać user stories. A żeby zdecydować, co estymować w pierwszej kolejności, przyda się priorytetyzacja MoSCoW i WSJF. Chcesz przećwiczyć estymację na realnych projektach? Zajrzyj do szkoleń Analify.