Czy/Czemu nie stosuje się estymacji czasu przez pracowników w innych zawodach

Czemu programiści muszą estymować czas swojej pracy (często pod czyjąś presją na zmniejszenie tego czasu), a w innych branżach się o tym nie słyszy? Nie słyszałem, żeby kuriera pytali się ile mu zajmie rozwiezienie paczek. Jak ktoś robi za wolno według jakichś ustalonych standardów to po prostu jest upominany/zwalniany

Jak zatrudniasz malarze albo mechanika to nie pytasz się ile mu to zajmie? Ja swojego mechanika pytałem sie:

• ile to może kosztować
• na kiedy będzie samochód do odbioru

W ASO otrzymywałem za to precyzyjną odpowiedź przy małych rzeczach, np 3h. Przy dużych to już wiadmo różnie, szyba do Skody podobno trzy razy szła z Czech bo się tłukła. No ale to już jak czekanie na inny team aż dostarczy API. Jak szyba jest na miejscu i mechanik ma wolne moce przerobowe to raczej wie ile mu to zajmie

Tzn dla mnie to jest trochę dziwne i na pewnym momencie może się przerodzić w toksyczne zjawisko.

Tutaj dla kontekstu można przeczytać o tym jak ekspetyment Asha
https://pl.wikipedia.org/wiki/Eksperyment_Ascha

1. Case
   Masz 4 dobrych developerów w zespole --> podrzucasz jednego, dwóch podstawionych developerów (wyższych rangą na przykład) którym za zadanie mają "zbijać" estymaty zawsze. Wtedy tych 4 developerów zacznie myśleć po jakimś czasie że albo są słabi albo wolno robią :D Są managerowie co stosują takie techniki w zespołach.

2. Case
   Masz Team Leadera, Managera który nie widzi świata poza pracą i będzie "zbijał" estymaty developerów. Wtedy po jakimś czasie Ci developerzy zaczną myśleć że są słabi albo wolno robią, w efekcie czego zaczną robić szybciej.

3. Case
   Wystarczy że na pracy zdalnej masz dwóch developerów którzy robią nadgodziny na pracy zdalnej. Bardzo łatwo im wtedy zaburzyć Velocity w zespole i Story Pointy po miesiącu, dwóch nie mają żadnego znaczenia xD a ze Scruma robi się Kanban

4. Case
   Idąc idealistycznym tokiem myślenia jak ktoś narzuca Ci tempo pracy, w tym przypadku estymuje Ci czas jaki powinieneś mieć na zadanie godzi w Twoją osobowość jako odrębnej jednostki, z racji tego że każdy jest inny, ma inne predyspozycje w danym tygodniu, dniu, niektórzy dłużej robią zadania.

KamilAdam napisał(a):

Jak zatrudniasz malarze albo mechanika to nie pytasz się ile mu to zajmie? Ja swojego mechanika pytałem sie:

Dlaczego wywierałeś na nich presję? Czy to nie jest już "passive aggressive"? Pewnie potem jeszcze wymagałeś dotrzymana zadeklarowane go terminy?

S4t napisał(a):

Czy to nie jest już "passive aggressive"

Jak nie wiesz co to passive aggressive to sprawdź sobie definicję na wikipedii. Mała podpowiedź - to coś zupełnie innego niż ludzie normalnie nazywają, BTW to na co ludzie mówią passive aggressive to często zwykła wredność :P

KamilAdam napisał(a):

Jak zatrudniasz malarze albo mechanika to nie pytasz się ile mu to zajmie? Ja swojego mechanika pytałem sie:

• ile to może kosztować
• na kiedy będzie samochód do odbioru

W ASO otrzymywałem za to precyzyjną odpowiedź przy małych rzeczan, np 3h. Przy dużych to już wiadmo różnie, szyba do Skody podobno trzy razy szła z Czech bo się tłukła. No ale to już jak czekanie na inny team aż dostarczy API. Jak szyba jest na miejscu i mechanik ma wolne moce przerobowe to raczej wie ile mu to zajmie

Z ASO to jest bardzo dobra analogia.

Masz do naprawy prostą rzecz, którą robiłeś już 100 razy. (przegląd serwisowy, wymiana amortyzatora, wymiana rozrządu itp.)
Masz w miarę nowy samochód, który nie dostał strzała, nic nie jest zapieczone, urwane, zardzewiałe.
Masz najczęściej instrukcję jak to zrobić (w ASO robią ponoć jak małpy, odkręć śrubkę 1, zdejmij osłonę 2)

Jesteś w stanie wycenić to co do godziny i wycenić co do złotówki.

Teraz inna sytuacja - przyjeżdża Ci typ, który ma do naprawy wahacz w starym samochodzie, nie wiadomo co tam wcześniej wsadzili i jak, czy zgodnie ze sztuką czy na klej i gumę, do tego dawno nie robiłeś tego egzotycznego samochodu, bo panie kto to kupuje, to nie wiesz kompletnie nic i możesz jedynie przybliżyć ten czas i koszt.
W trakcie naprawy wyjdzie, że typ ma skorodowany do czerwoności amortyzator i Ty jak wyciągniesz wahacz to się wysypie cały amorek, dzwonisz do gościa "co robimy". Wahacz masz, ale na amortyzator trzeba czekać do jutra. Do tego urwałeś śrubę.

Gdybym na akord stawiał np. codziennie nowe środowiska pod development, dopisywał drugi endpoint w nowym systemie, albo każdy projekt byłby prowadzony identycznie (np. jakiś software house który robi kopiuj wklej projekty i lekko customizuje) i robiłbym to samo dzień w dzień to też bym Ci określił ile czasu i pieniędzy będzie to kosztowało.

A tak dostajesz legacy g**no, w połowie albo zanim w ogólę zaczniesz musisz dopytywać o wszystko, przy okazji trzeba zmienić połowę istniejącego kodu bo ktoś zrobił kupę to jak chcesz określić złożoność tej roboty?

Nie słyszałem, żeby kuriera pytali się ile mu zajmie rozwiezienie paczek.

Ja też nie słyszałem, by ktoś po skończonym TAKIM SAMYM ZADANIU (albo nawet podobnym) powiedział mi "no, to zrobisz jeszcze raz to samo co robiłeś 1000 razy".

A co do kurierów to znam kuriera od zadań specjalnych, wozi na przypale i szybko. Bierze za to spore pieniądze, bo robi zawsze na CITO, wozi dziwne przesyłki, w dziwne miejsca i bierze na siebie odpowiedzialność. Ale każde zlecenie jest wycenione wzorem rodem wziętym z wycenami tutaj z innego tematu -> określ złożoność w roboczogodzinach, pomnóż x2 i dodaj jeszcze 50% (a jak klient bogaty to jeszcze kolejne 100%).

piotrevic napisał(a):

Czemu programiści muszą estymować czas swojej pracy (często pod czyjąś presją na zmniejszenie tego czasu), a w innych branżach się o tym nie słyszy? Nie słyszałem, żeby kuriera pytali się ile mu zajmie rozwiezienie paczek. Jak ktoś robi za wolno według jakichś ustalonych standardów to po prostu jest upominany/zwalniany

Czy kolega szanowny wychodzi czasem z domu?
Zdarzają się remonty, ulic, sklepów, klatek schodowych - wtedy zawsze jest podana data ponownego urochomienia
i jeśli by taki Lidl czy inna Biedra się opóźnili w otwarciu to dopiero by było, w programowaniu to jest bajka pod tym względem - co się stanie jeśli ficzer będzie sprint później, a co się stanie jeśli otwarcie sklepu będzie tydzień później

Kolega ma może samochód, albo coś naprawiał/remontował?

Kolega kiedykolwiek cokolwiek zamawiał - jeśli tak to może sobie przypomni, że podawany jest orientacyjny czas doręczenia przesyłki

Kolega ogląda telewizję/słucha radia? - tam jest coś takiego jak program, który bazuje na czasie, niech się coś obsunie, albo nie pyknie - to dopiero jest armagedon

Kolega jeździ komunikacją zbiorową, chodzi do kina, teatru? - co by nie powiedzieć tam czas się bardzo liczy

Kolega zdaje sobie sprawę, że sklep musi byś zatowarowany przed przyjściem klienta (przed otwarciem)

Przepraszam, za osąd, ale to chyba trzeba być bardzo zapatrzonym w siebie, żeby nie dostrzegać tego, ze wokoło nas taka zmienna jak czas jest wszechobecna i niemalże wszystko się na niej opiera
na kiedy będzie
kiedy dojadę
o której coś się zacznie/skończy
itp itd

pod presją czasu wszyscy zżyjemy

Co do w ogóle za durne pytanie. Nie rozumiem skąd hejt na estymację. Jak sobie wyobrażacie, że wasz menadżer zaplanuje robotę jak nie wie mniej więcej ile coś może zająć? Wiadome, że czasem coś zajmie dłużej a coś krócej ale mniej więcej musi wiedzieć i powinien brać to pod uwagę.

Wszędzie są estymacje i wszędzie coś może pójść nie tak i być opóźnione (otwarcie mostu, oddanie samochodu bo amortyzator też się zepsuł i trzeba czekać aż przyjedzie z Japonii...) ale zazwyczaj ta estymacja jest w miarę trafna.

Wiadome, że można pracować bez tego w wielu projektach ale zazwyczaj menadżerowie preferują wiedzieć jak mogą coś zaplanować

@piotrevic: może Cię zaskocze, ale estymacja jest jednym z podstawowych elementów zarządzania czymkolwiek.
Istnieje w zasadzie w każdym zawodzie.
Dla Twojej informacji, My mamy wersję Light.
Wesoło robi się jak estymujesz miliardowe projekty lub inwestycje, tam nie ma miejsca na "szybki fix w kodzie" jak dałeś filar o 50cm za daleko :D

Co do przykładu z kurierem, to oczywiście że tam jest estymacja.
Ktoś policzył co i jak i wyznaczył kurierom "strefy" za które odpowiada.
To trochę jak z programistą, piszesz kawałek kodu i nawet nie wiesz o 99 zewnętrznych systemach które na tym kawałku będą polegać bo zaplanowali to Ci bezużyteczni Architekci i Project/Program managerowie.

Ps. Estymacja zadań to ta łatwa część planowania :)

Myślę, że to wynika z tego, że zadania programisty są zróżnicowane i złożone jak w mało którym innym zawodzie. Jedno zadanie zajmuje 10 min, a inne tydzień albo jeszcze więcej i z punktu widzenia osoby nietechnicznej (czy juniora) właściwie niemożliwe jest określenie tego z góry. Gdyby to były zadania jednorazowe (np. idziesz do mechanika żeby naprawił ci auto), może jeszcze nie byłoby problemu, ale w typowym projekcie informatycznym, wykonanie projektu idzie w setki, tysiące zadań; stąd określanie czasu potrzebnego na każde z nich jest znacznie ważniejsze, bo ewentualne błędy w określeniu długości czasu się dodają. Wyobraź sobie, że określiłeś, że projekt składa się z 1000 zadań, a każde z nich może trwać od 10min to tygodnia. Otrzymujesz odpowiedź od 7 roboczodni do 20 roboczolat. :D

Druga sprawa jest taka, że ci lepsi programiści, którzy wyznaczają takie trendy, jak np. agile, zwykle rozumieją, że doświadczenie z zakresu programowania całkiem dobrze się przekłada na zarządzanie zadaniami w życiu. Stąd można oczekiwać bardziej wyrafinowanych metod zarządzania projektem.

elwis napisał(a):

Myślę, że to wynika z tego, że zadania programisty są zróżnicowane i złożone jak w mało którym innym zawodzie.

No tak, bo te ify i fory to za każdym razem są takie inne. Nie to, co operacja na otwartym sercu albo neurochirurgia.

@piotrevic - jedna uwaga odnośnie estymat
po co ma je robić robotnik gdy sprawa jest powtarzalna, jak np jest brygada sprawdzona to można to określić bez pytania wszystkich
gdy pojawia się problem (np robota taka sama, ale prowadzona w ruchu ulicznym, w jakimś dziwnym terenie itd) to uwierz mi że wtedy robotnik jest pytany, pewnie nie każdy, bo świeżaka nie będą pytać

Mój hejt wynika z tego, że wymuszoną estymacją wywiera się presję na programistę i dla mnie to jest stresujące.

życie ogólnie jest stresujące
myślisz że przy obsuwach np na budowach czy remontach to jest tak miło, tam to jest stres, bo to jest być albo nie być czasami i to dosłownie, jak i przy spedycji

opieprz zbieram ja, bo źle oceniłem czas pracy

Tu trochę Ciebie rozumiem
raz przeżyłem coś takiego
miałem przyjść do projektu, gdzie był niby przygotowywany od pół roku (kontraktornia), tylko siąść i robić, wszystko jasne, wszystko gotowe
okazało się, że te opowieści to pic na wodę i fotomontaż, a kto był winny - no programista. bo przecież każdy wiedział że wszystko jest gotowe (chodzi mi management) a jak nie ma postępów, to wina tego leni devów bo się opierdzielają i kop się z koniem, udowadniaj

co można powiedzieć, takie rzeczy się zdarzają, jakoś to przeżyłem i żyję dalej - to nie wina estymat tylko ludzi

@piotrevic:
A jesteś w stanie podać przykład zawodu, gdzie zadania są zróżnicowane i nie są wyceniane przez pracowników?
Przykład kuriera jest dość słaby, bo gość wyceniać nic nie musi. Wchodzisz w system (stworzony przez programistów pewnie :D) i widzisz, że kurier średnio dostarcza dziennie 400 przesyłek +/- 20 (wartość z kosmosu oczywiście) i jeśli Amazon szacuje, że będzie dziennie 2000 dostaw w danym mieście to trzeba zatrudnić 5 kurierów i tyle.
Estymacja jest przeprowadzona pewnie na okresie 5 lat wstecz na podstawie tysiąca próbek. Gdybyś znalazł zbiór jednakowej roboty robionej przez developera to też byś był w stanie to jakoś aproksymować.

Przykładami innych zawodów może być chirurg jak już ktoś wspomniał, budowy chyba też są skomplikowane skoro często mają obsuwy, przynajmniej w Polsce. Czas diagnostyki chorób, lub uszkodzeń sprzętu też jest skomplikowany. Zwykle szeregowy pracownik chyba tego nie musi robić i się kurczowo trzymać. Może mechanik samochodowy, ale tam estymaty też bywają dużo zawyżone. — @piotrevic 25 minut temu

Chirurg zawsze wycenia czas pracy - nigdy nie zdarzyło mi się, żeby nie powiedział, ile potrwa zabieg. Mniejszy czy większy, to bez różnicy, przecież nawet dostajesz znieczulenie na określony czas.
Jeśli chodzi o sprzęt, to kiedyś słyszałem, że goście w Intelu mają określony czas na diagnostykę i naprawę narzucona z góry - to chyba były 24h i mają obowiązek się w tym wyrobić (coś jak sprint? Tylko nikt nie bawi się w male taski, ma być do końca sprintu, a jak nie, to się tłumacz, coś w tym stylu), więc też je muszą między sobą estymowac, żeby zdążyć.

Mam też inny przykład z naprawą urządzeń, ale bardziej jako ciekawostka - jest firmą w pl, która jako jedna z niewielu naprawia drogi sprzęt pomiarowy (często z uczelni), która liczy sobie jakieś chore setki zł/h pracownika od jego wyjazdu z firmy (a mają jedną siedzibę i fajnie liczą $$ do dojazdu na drugi koniec pl), to sobie wyobraź co by było, gdyby nawet z grubsza ten pracownik nie estymowal

Kolejny wątek z serii "Dlaczego management nie pozwala mi siedzieć w piwnicy przez pół roku i dłubać sobie w kodzie?" albo "W pracy ludzie się do mnie odzywają i mnie to stresuje, czy w innych zawodach też tak jest?". W sumie dla mnie jest już jasne skąd takie rozbieżności w zarobkach w naszej branży. Chyba muszę iść po podwyżkę.

@piotrevic: problemem nie jest fakt, że ktoś od Ciebie wymaga estymat, problemem nie jest to, że potem próbuje je zbić ani problemem nie jest to nieuchwytne "zagrożenie". Problemem jesteś TY, a właściwie brak twojej asertywności - nie potrafisz powiedzieć NIE. Jeśli ktoś CIEBIE pyta o estymaty to ty podajesz SWOJE estymaty a jak te estymaty się nie podobają "górze" to niech sobie ustala własne. Chodzi o to, że jak powiesz 3 dni a PM/menager/ktokolwiek powie Ci, że nie, 3 to za dużo dajmy 2 to masz odpowiedzieć: "NIE, moja estymata to 3 dni i tyle potrzebuję, żeby to zrobić o ile po drodze nie pojawią się problemy o których dzisiaj nie wiem." i tyle - cała filozofia. A jak się komuś nie podoba to albo może estymatę zmienić (ale wtedy to nie jest TWOJA estymata) albo Cię zwolnić (zawsze też możesz pracę zmienić sam), co w tej sytuacji nie wydaje się takim złym rozwiązaniem.

Jak to w innych zawodach nie ma estymacji czasu pracy? W ostatnich latach pracowałem poza IT więcej niż w IT i w każdej firmie prywatnej/instytucji państwowej (branża prawnicza) musiałem się tłumaczyć, ile zajmie dane zadanie, nawet gdy było to nie do przewidzenia, a potem byłem z tego konkretnie rozliczany (czasem zależało od tego moje końcowe wynagrodzenie, bo to szło na fakturę do klienta). O podobnych standardach słyszałem również w sektorze bankowym, a także budowlanym. W IT jest to może bardziej usystematyzowane, ale na pewno nie jest to jedyna branża, gdzie to pracownik odpowiada za szacowanie czasu wykonania zadania.

Nie pamiętam gdzie o tym czytałem, ale sugestia jest taka, że estymacja to taki przedział prawdopodobieństwa na kiedy będzie gotowe i tak należy to przedstawiać.
Czyli zamiast mówić 3 dni to podajemy przedział 2 - góra 4 dni i cierpliwie tłumaczymy w razie potrzeby.

Jeśli ktoś uparcie naciska na mniejsze estymaty to można ewentualnie porozbijać na mniejsze zadania, ale nie można dać sobie wejść na głowę.
Grunt to dobry zespół w którym nikt nie wyrabia darmowych nadgodzin, każdy mniej więcej robi w tym samym tempie i wtedy te wszystkie velocity jakoś się układa, nikt się nie męczy.

Są zadania gdzie nic nie wiadomo, trzeba wejść po pas w g**no kod, ale wtedy polecam określać zakresy i robić time-box, wtedy po każdej takiej g**no sesji wyciągamy wnioski czy jest OK czy idziemy dalej.

Miskov1 napisał(a):

Tzn dla mnie to jest trochę dziwne i na pewnym momencie może się przerodzić w toksyczne zjawisko.

Tutaj dla kontekstu można przeczytać o tym jak ekspetyment Asha
https://pl.wikipedia.org/wiki/Eksperyment_Ascha

1. Case
   Masz 4 dobrych developerów w zespole --> podrzucasz jednego, dwóch podstawionych developerów (wyższych rangą na przykład) którym za zadanie mają "zbijać" estymaty zawsze. Wtedy tych 4 developerów zacznie myśleć po jakimś czasie że albo są słabi albo wolno robią :D Są managerowie co stosują takie techniki w zespołach.

2. Case
   Masz Team Leadera, Managera który nie widzi świata poza pracą i będzie "zbijał" estymaty developerów. Wtedy po jakimś czasie Ci developerzy zaczną myśleć że są słabi albo wolno robią, w efekcie czego zaczną robić szybciej.

3. Case
   Wystarczy że na pracy zdalnej masz dwóch developerów którzy robią nadgodziny na pracy zdalnej. Bardzo łatwo im wtedy zaburzyć Velocity w zespole i Story Pointy po miesiącu, dwóch nie mają żadnego znaczenia xD a ze Scruma robi się Kanban

4. Case
   Idąc idealistycznym tokiem myślenia jak ktoś narzuca Ci tempo pracy, w tym przypadku estymuje Ci czas jaki powinieneś mieć na zadanie godzi w Twoją osobowość jako odrębnej jednostki, z racji tego że każdy jest inny, ma inne predyspozycje w danym tygodniu, dniu, niektórzy dłużej robią zadania.

Prędkość wykonywania taska nie świadczy o tym czy ktoś jest słaby, raczej powiedziałbym, że słabym devem jest ten co mieści się w estymatach a dowozi g**no bez post-refactoru i kod niesamoopisujący się lub np test-cases, które są false-positive i nie mają żadnej wartości.

Już często coś takiego widziałem, dowiezione w czasie albo i przed, a potem moje i paru devów 10-20 komentarzy/uwag i nagle wielki płacz albo total ignore i merge anyway bo jakiś tam dev-kolega dał approve anyway i jest niezłym deklem co zawsze pisze "jak coś to zmieniłby tu to, ale wiesz w sumie nnie musiz, jak coś, nie obraź się, ok nie było sprawy, approve ode mnie" XDDDDD

Mnie o takie coś w pracy nie pytaja. Jak pytaja to cos jest nie tak i duza szansa ze jest to januszex

To raczej w IT nie ma estymacji czasu, przynajmniej nie na poziomie pracownika i jego zadań. W innych branżach - przynajmniej tych inżynierskich - estymacja jest dokonywana w jednostkach czasu.

Tzn trzeba estymowac jak wszyscy wczesniej powiedzili, ja rozumiem po co sa te estymacje. Jedynie mam dwa problemy z estymacjami:

1. Gdy nie masz totalnie zielonego pojecia ile ci to zajmie bo zadanie to jakis kosmos (nieznana domena, nieznana technologia, jakis research )
2. Estymujesz bezpiecznie a SM, PO, czy inny wybrany czlek mysli ze jedank to bedzie mniej zajmowac ;) wiec po co ja estymuje skoro on i tak wie lepiej

Akihito napisał(a):

Tzn trzeba estymowac jak wszyscy wczesniej powiedzili, ja rozumiem po co sa te estymacje. Jedynie mam dwa problemy z estymacjami:

1. Gdy nie masz totalnie zielonego pojecia ile ci to zajmie bo zadanie to jakis kosmos (nieznana domena, nieznana technologia, jakis research )
2. Estymujesz bezpiecznie a SM, PO, czy inny wybrany czlek mysli ze jedank to bedzie mniej zajmowac ;) wiec po co ja estymuje skoro on i tak wie lepiej

Wtedy się robi "spike" - mówisz, że potrzebujesz jednego dnia (lub więcej/mniej) na research technologii i rozwiązania, żeby być w stanie podać estymatę.
https://www.visual-paradigm.com/scrum/what-is-scrum-spike/

Z estymacjami to jest w moim doświadczeniu tak:

1. problemy są dlatego, że:

• do CRUDa architekt, tech lead, czy ogólnie osoba, która robi estymację wymyśla, że użyje 150 nowego frameworka / biblioteki / wibratora / etc., o którym nie ma pojęcia, ale słyszała, że jest "fajny" (nieznana technologia, ale WYBRANA nie narzucona)
• nie ma czegoś takiego jak standardy w naszej branży (analogicznie do innych branż inżynierskich) - mamy best practices, "de facto" standards, czy inne wzorce, ale to nie jest tak, że jak zrobisz inaczej to Cię wyproszą z gildii programistów i ostracyzm na 10 lat
• jeśli mamy w miarę wygrzany system to pewne zadania powinny być w miarę powtarzalne - np. wystawienie nowej usługi, która robi tyle, co poprzednie (np. wołanie systemu zewnętrznego, zapis do bazy, etc.) - jeśli nie ma na to prostej procedury (w sensie kroków postępowania) to za każdym razem jak przyjdzie nowy to odkrywa koło przez X miesięcy zanim się wdroży i jego praca będzie w miarę przewidywalna
• nie wiadomo do końca co jest do zrobienia (tu odkrycia nie ma ;)

2. Inną kwestią, która wprowadza zamieszanie jest sprawa zaufania jakie osoba, która korzysta z tych estymacji ma do osobnika estymującego. Jeśli estymacje, które otrzymuje są nieprzewidywalne (przestrzelone o 80%, albo mocno niedoszacowane) to wtedy "PM wie lepiej" i robi po swojemu, ale uwzględniając w jakimś procencie swojej decyzji wsad od takiej osoby. Mógłby pewnie zupełnie zignorować wkład od takiej osoby i pewnie wielu tak robi, ale to też nie jest najlepsze, bo się ten człowiek estymować nigdy nie nauczy (tutaj oczywiście musi być jakaś informacja zwrotna).

Co mi się osobiście sprawdzało, to ograniczanie liczby punktów swobody. Może to trochę naturalne, bo pisałem mnóstwo ofert pod klientów i tam, żeby ograniczyć ryzyko, trzeba było fantazję klienta wtłoczyć w jakieś ramy (jak się tego nie robiło, to "dół pleców" bolał od późniejszego nadmiaru "frywolności" projektowej).
Tak więc jak podajesz estymaty, to do tego czego nie wiesz przyjmij jakieś założenia i je opisz. Jak dawno temu uczyłem się zarządzać projektami bo nie było agile / scruma i innych cudów i to była podstawowa robota każdego PMa, to był prosty wzór na esytmację: (1 best case + 4 most likely + 1 worst case) / 6 (jakby ktoś się interesował to jest wartość oczekiwana w dystrybucji PERT).