Rozliczanie estymacji w pracy

Czy u Was w firmach rozlicza się devów/QA’ów z ich estymacji? Zlicza co do godziny ile ktoś poświęcił czasu na dany temat, robi statystyki, a w przypadku przekroczenia czasu np. ucina bonusy? Nie chodzi mi o to, żeby w ogóle nie wyceniać tasków, ale czy kładzie się na to, aż taki nacisk?

Nie, praca w takiej firmie to niewolnictwo. Mocny reżim może mieć sens w przypadku firm gdzie robisz rzeczy powtarzalne np. kontrola jakości na taśmie. W przypadku programowania/testowania, gdzie dev sam wymyśla jak coś zrobić i w międzyczasie zajmuje się pierdyliardem innych spraw to zwykłe wykorzystywanie i przyciskanie śruby

Nie, ale czasami PM czy inny sram master potrafił się do tego przyczepić.

Jak ktoś chce rozliczać dev/QA z estymat to jak rozumiem analityk/jakiś product owner też jest rozliczany i jeśli podczas implementacji pojawiają się nieprzewidziane scenariusze to mają ucinane bonusy?

twoj_stary napisał(a):

Czy u Was w firmach rozlicza się devów/QA’ów z ich estymacji? Zlicza co do godziny ile ktoś poświęcił czasu na dany temat, robi statystyki, a w przypadku przekroczenia czasu np. ucina bonusy? Nie chodzi mi o to, żeby w ogóle nie wyceniać tasków, ale czy kładzie się na to, aż taki nacisk?

Nie. Brzmi to co najmniej absurdalnie.

a) kto w takiej firmie pracuje :o Nawet jakbym sie spotkał z czyms takim to bym zaraz palil wrotki
b) rob estymaty x3. Jak zrobisz przed czasem to zbijaj baki skoro za robienie estymat na oko tyle ile to zajmie jest kara. Pewnie nawet biznes szczesliwy bedzie ze zgodnie z estymatyami idzie

Nie, absolutnie nie - to byłoby absurdalne.

Ale w jednej firmie godziny z estymacji i użyte godziny były kiedyś sprawdzane pod kątem współczynnika do estymacji - on tam wychodził w zależności od projektu x2 do x4. Przy tym nikt kompletnie nie rozliczał nikogo i liczone było to w skali całego projektu.

Estymacja to nie deklaracja. A jesli firma to tak traktuje i nie chcemy zmieniac pracy to po prostu trzeba estymowac z zapasem, biorac rowniez pod uwage przypadki brzegowe, dokumentacje, poprawki, testy itp. Jak sie szybciej wyrobie to w backlogu zawsze cos czeka :)

czyli zwiększamy estymaty i pyk pora na csa i bonusik wpada

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

Trafiłem do takiego projektu w grudniu, opuściłem go po 3 miesiącach, jak już mi się już znudziło na te głupoty patrzeć.
Ale rozliczanie estymacji to akurat była najmniejsza tam patologia, dużo gorsze było rozliczenie czasu spędzonego na przeglądaniu PRów, i to zarówno przez reviewera jak i autora kodu. :D

Aż tak duży nacisk nie był kładziony, jak jeszcze pracowałem w IT. Byłoby to co najmniej problematyczne, ponieważ doprowadziłoby to ustalenia, że na 1 SP syna kolegi prezesa zarządu (najczęściej i tak przeszacowany, żeby była jakakolwiek podkładka na jego obecność w teamie) przypada co najmniej 10 SP deva, który został zwolniony po wykonaniu za niego jego tasków. A w normalnej firmie te narzędzia mają chyba służyć usprawnieniu pracy zespołu, a nie rozliczaniu pracowników finansowo. Kiedyś pracowałem w systemie godzinowego rozliczenia, ale wtedy to miało o tyle sens, że zalogowane przeze mnie taski i czas służyły do fakturowania. No i przede wszystkim ja się wtedy świadomie na taki system zgodziłem (raz i nigdy więcej).

Zlicza co do godziny ile ktoś poświęcił czasu na dany temat

W pierwszej firmie mieliśmy wpisywać ile h spędziliśmy nad taskiem w jirze, ale to była raczej formalność.
Natomiast w tej samej firmie był jeden zespół, który robił projekt dla polskiego klienta, który należał do spółki skarbu panstwa i tam bardzo tego pilnowano. Do tego stopnia, że zliczało się godziny tylko wtedy kiedy siedziałeś przed kompem i pisałeś kod xDDD. Testowanie, spotkania, myślenie nie mogło wchodzić w tą estymate. Pojebane, ale historia jest prawdziwa.

a w przypadku przekroczenia czasu np. ucina bonusy?

Z czymś takim to się nigdy nie spotkałem.