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

3

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.

2

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
1
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/

2

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 ;)
  1. 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).

1 użytkowników online, w tym zalogowanych: 0, gości: 1