Darmowe nadgodziny kolegów z pracy

@jarekr000000: uważam że masz rację
był jeden Tech\TeamLead, chyba najlepszy jakiego dane mi było poznać, Spoko koleś i ogarnięty bardzo.
Była to osoba, która próbowała przeforsować SP jako oznaczenie skomplikowania zadania, a nie jego czasochłonność. Ale i on poległ w walce z managierami, którzy koniecznie chcieli wiedzieć ile SP to jeden dzień roboczy.
W końcu dał sobie spokój
w innych projektach z góry było założone ze 1 czy 2 SP to 1 MD.
I tak się żyło w tym scrumie czy jak to się zwie :)

SP to dla mnie podobny poziom co TDD. Najczęściej o TDD pytano na rekrutacji opowiadano jakie to ważne i jak w zespole się przykłada do tego wagę, a potem osobiście nie widziałem projektu, czy funkcjonalności, gdzie by zaczynano od pisania testów, ale TDD było bo w Definition Of Done był punkt o testach :)

Podniósłbym tak normę że nikt by się nie wyrabiał, a później się zwolnił.

Myślę, że w klimacie

Trzeba tylko pamiętać, by po wyścigu się dobrze zabawić :)

Dzięki panowie za odpowiedź wszystkim, bardzo mnie podbudowaliście na duchu i daliście spojrzenie z innej perspektywy. To, że dwie osoby w zespole robią darmowe nadgodziny (wolontariat) wpływa negatywnie na zespół i ludzi którzy cenią work-life-balance. Tak samo z tym estymowaniem SP, że były źle oszacowane, ale to wynikało z tego, że TL tak nauczył Biznes Analityków że zrobi wszystko na tzw. "teraz" kosztem życia prywatnego. Tak jak ktoś wcześniej zauważył, to faktycznie młode chłopaki 24, 27 lat, którzy jeszcze nie wyszli z tzw. pułpaki samorozwoju. Będę szukać normalnej pracy, a z tej się zwolnię.
Korzystając z okazji czy macie jakieś tipy jak na rozmowie rekrutacyjnej wyczuć czy w zespole jest tzw. taśma Sprintowa i wydawanie featerów co dwa tygodnie? Jak wyczuć w zespole tą normalną, w miarę spokojną, bez pośpiechu atmosferę? BTW dzięki za odpowiedzi i życzę miłego tygodnia!! :))

@Marcys32:

Marcys32 napisał(a):

Korzystając z okazji czy macie jakieś tipy jak na rozmowie rekrutacyjnej wyczuć czy w zespole jest tzw. taśma Sprintowa i wydawanie featerów co dwa tygodnie? Jak wyczuć w zespole tą normalną, w miarę spokojną, bez pośpiechu atmosferę? BTW dzięki za odpowiedzi i życzę miłego tygodnia!! :))

Powiedz, że chcesz zmienić pracę/odszedłeś z pracy, bo była tam taśma sprintowa, parcie na nadgoidziny i cierpiało na tym Twoje życie prywatne.
Jak szukają przodownika pracy to Cię sami odrzucą.

Już na etapie rekrutacji telefonicznej zapytaj niby przypadkiem - w trakcie zbierania info o firmie - czy jest może (jak to się czasem zdarza) w budynku albo obok, PRZEDSZKOLE

Żart żartem, ale w Warszawie to nie takie dziwne, że jest przedszkole i firma o tym informuje "jako pozytyw pracy u nas"

twoj_stary_pijany napisał(a):

@urke @somekind Czyli po prostu managerowie są niekompetentni i nie rozumieją czym są story pointy i może powinniście dokładnie przedyskutować to w jaki sposób mierzony jest performance zespołu. Jeżeli przeliczacie performance programistów na man days to macie wyścig szczurów. Właśnie przypomniałeś mi jaką patologię miałem w jednym startupie w którym kiedyś pracowałem. Moi koledzy ze zespołu estymowali taski po man day i jeden gość estymował coś na dwa tygodnie i robił coś 3 tygodnie i dalej były błędy. Ja wyestymowałem jedną rzecz na 3 tygodnie i zdeployowałem ją działającą w dwa tygodnie. Ja dostałem zjebę, że daję zbyt wysokie estymaty. Po tym jak powiedziałem, że dostarczyłem swoją rzecz na czas, a nie po czasie jak inni i czy miałem zamiast tego kłamać dostałem odpowiedź, że może powinienem. Nie muszę chyba mówić oczywistości, że kolega, który niedoszacowywał historyjki był wielkim przeciwnikiem wszelkiego rodzaju groomingów, retrospektyw i innych podobnych narzędzi.

@twoj_stary_pijany: nie rozumiem, czemu zakładasz, że mój manager jest niekompetentny. Nie rozumiem, czemu w ogóle zakładasz, że mam jakiegoś managera. Odnosiłem się do tego, co opisał autor wątku, a co jest dobrze mi znanym problemem z dyskusji z dziesiątkami osób, a także własnego doświadczenia sprzed lat i pewnego typu firm.
No i o ile dobrze rozumiem dalszą część wywodu, to Ty też masz jakieś doświadczenia z ludźmi, którzy nie do końca ogarniają do czego służą estymacje.

Marcys32 napisał(a):

Korzystając z okazji czy macie jakieś tipy jak na rozmowie rekrutacyjnej wyczuć czy w zespole jest tzw. taśma Sprintowa i wydawanie featerów co dwa tygodnie? Jak wyczuć w zespole tą normalną, w miarę spokojną, bez pośpiechu atmosferę? BTW dzięki za odpowiedzi i życzę miłego tygodnia!! :))

Scrum jest zasadniczo metodologią paraliżowania pracy, aby programiści się nie przemęczali, a managierowie mieli stabilne przewidywania co do wydajności zespołu.
Jak uniknać antyscruma, w którym pracujesz obecnie?
Widzę trzy sposoby:

1. iść do pracy tam, gdzie masz znajomego, któremu ufasz, i który zaświadczy, że nie ma zapieprzu;
2. unikać polskich software house'ów - bo to ten rodzaj firm, którym udało się przekształcić scrum w coś, co służy do ciemiężenia zamiast czilałtu;
3. unikać scruma.

2. unikać polskich software house'ów - bo to ten rodzaj firm, którym udało się przekształcić scrum w coś, co służy do ciemiężenia zamiast czilałtu;

Najbardziej wypaczony Scrum to widziałem w niemczech. Łącznie z niemieckimi programistami i architektamy robiącymi po 12 dupogodzin dziennie. Ale bez Scruma też tak bywało - wiele zależy od kultury firmy i landu. Byłem też w firmie niemieckiej gdzie miałem wrażenie, że pracowano (nieoficjalnie) po 4-5 godzin dziennie (a ja, głupi narzekałem).

Stary! Moim zdaniem kompletnie nie pasujesz do tej ekipy.

Ludzie tam pracują z zaangażowaniem i czystą radością, tak, że w ogóle nie zauważają upływającego czasu.

A ty co? A ty męczysz się i odliczasz godziny do 16.

Marcys32 napisał(a):

Pracuję aktualnie w projekcie, gdzie Team-Leader pracuje miesięcznie po 200-250 godzin miesięcznie. Oczywiście za darmo, w tej firmie nie ma nadgodzin, a jak są ale w wyjątkowych sytuacjach. Gość po prostu robi to dobrowolnie. Do tego doszedł jeszcze jeden chłopak który także robi nadgodziny za darmo. Rozmawiałem z jednym i powiedział mi, że Java to jego pasja i że sprawia mu to przyjemność, więc robi za darmo. Wszystko spoko, firma zadowolona, bo chłopaki robią za darmo ale w zespole wytworzyła się presja nieświadomie i toksyczna atmosfera wyścigu kto więcej zrobi, kto jest bardziej pro aktywny itd. Tzw. wyścig szczurów. Wycenianie tasków na jak najmniejszą ilość story-pointów, a potem oczywiście niewyrabianie się i siedzenie po 12 godzin dziennie. Sytuacja dotyka także mnie, ponieważ w zespole wytworzył się kult "zapier..." i spotykam się z tym, że Team-Leader pyta się mnie czemu tak długo taski robię, (task wyceniony na 2 SP robiłem 4 dni, od razu zostałem poinformowany że robię dłużej niż była wycena).

Czy takie sytuacje w zespołach programistów często się zdarzają? Jak sobie poradzić w takich sytuacjach?

Tępić, tępić i jeszcze raz tępić. Pracowałem z takim delikwentem. Technicznie był bardzo mocny, ale z gatunku "noł-lajfa".

Sama firma zachowała się mądrze, bo mu tego kodowania po nocach zakazała. Darmowe nadgodziny wywołują coś, co można by nazwać inflacją oczekiwań u klienta. "Rozpieszczony" odbiorca szybko przestanie doceniać rezultaty - za to będzie się później dziwił, czemu ma płacić tyle samo za niższe tempo prac.

Poza tym spada jakość pracy. Choćbyś pod względem technicznym był nie wiem jakim kocurem, na dłuższą metę zderzysz się z pewnymi ludzkimi granicami, gdy chodzi o zdolność koncentracji i wydolność umysłową. Jak widziałem kod wypchnięty o czwartej nad ranem, to już wiedziałem, że pod spodem dymią zwały przeinżynierowanego gówna.

Czytelnością te dokonania też specjalnie nie imponowały. Obiegowy żart głosił, że kto potrafi z marszu zrozumieć kod naszego stachanowca, ten może oglądać kodowane mecze bez dekodera. Był też pomysł, aby z miejsca polecać taką osobę do programu SETI, żeby rozszyfrowywała potencjalne komunikaty od kosmitów.

Kluczowe zdanie w mojej odpowiedzi to "sama firma zachowała się mądrze". Firma, która traktuje takiego świra jak wygraną na loterii, nie postępuje mądrze. A w każdym razie zachowuje się krótkowzrocznie.

Nie zgadzam się więc kompletnie z @Adam Boduch (ani licznie plusującymi tę opinię), który uważa, że "największym wygranym w tym przypadku jest firma". Firma nie jest żadnym wygranym. Prędzej czy później będzie mieć wypalonego pracownika o zmarnowanym potencjale, zdemoralizowany zespół, prawdopodobnie dług techniczny i inne problemy.

V-2 napisał(a):

Nie zgadzam się więc kompletnie z @Adam Boduch (ani licznie plusującymi tę opinię), który uważa, że "największym wygranym w tym przypadku jest firma". Firma nie jest żadnym wygranym. Prędzej czy później będzie mieć wypalonego pracownika o zmarnowanym potencjale

Z tym jednym się nie zgadzam.
Nawet po ankietach na forum i dyskusjach jak mają wyglądać tematy widać, że jest pewna liczba ludzi którzy będą w siódmym niebie w takiej firmie dla no-lifów.

Wystarczy ich tylko ściągnąć kusząc buzz-hyper-nerd-bajerami i będą zasuwać aż do wypalenia.
A jak się wypalą to się pod buzz-hyper-nerd-bajer ściągnie do firmy następnych,* napalonych i jeszcze nie wypalonych*.

PS
Czy na przykład w game-dev taki styl działania firm to nie jest reguła?

BraVolt napisał(a):

Nawet po ankietach na forum i dyskusjach jak mają wyglądać tematy widać, że jest pewna liczba ludzi którzy będą w siódmym niebie w takiej firmie dla no-lifów.

Wystarczy ich tylko ściągnąć kusząc buzz-hyper-nerd-bajerami i będą zasuwać aż do wypalenia.
A jak się wypalą to się pod buzz-hyper-nerd-bajer ściągnie do firmy następnych,* napalonych i jeszcze nie wypalonych*.

Gdyby to było takie proste, to czemu nawet "zwykłym" firmom brakuje sensownych ludzi.
Zasoby frajerów-pracoholików tym bardziej nie są niewyczerpane.
A konieczność polowania akurat na takich ludzi trudno uznać za przewagę konkurencyjną.

Czy na przykład w game-dev taki styl działania firm to nie jest reguła?

Na tym sektorze się nie znam i nie przesądzam sprawy. Nie wiem, na ile stereotypy odpowiadają prawdzie.
Na pewno mogą sobie pozwolić na więcej, bo łatwiej znaleźć freaków, dla których sama możliwość pisania gier to jak złapać Boga za nogi.
Apki biznesowe nigdy raczej nie wzbudzą w wykonawcach porównywalnego entuzjazmu.

@V-2:
https://www.wirtualnemedia.pl/artykul/cyberpunk-2077-gra-premiera-19-listopada-w-cd-projekt-red-dodatkowy-dzien-pracy
https://businessinsider.com.pl/gielda/wiadomosci/cyberpunk-2077-wymaga-pracy-w-trybie-kryzysowym-6-dniowy-tydzien-pracy/z8k9vwf
https://antyweb.pl/cdpr-wizerunek-cyberunk-2077/

Tytuł w Wyborczej:
CD Projekt wydłuża tydzień pracy do 6 dni. "Myślą, że pracują przy czymś wielkim, a są trybikiem za 3,5 tys. zł"
https://wyborcza.pl/7,156282,26359631,cd-projekt-wydluza-tydzien-pracy-do-6-dni-mysla-ze-pracuja.html

Jeśli kolega woli Javę za darmo po godzinach to znaczy że jeszcze nie odkrył 4p. Nie bądź świnią - masz szansę uratować kolejne istnienie dla IT.

Jak byłby planning to bym powiedział w prost, że nie każdy pracuje na darmowe nadgodziny i w związku z tym tamtym członkom zespołu proponowalbym specjalną estymate taskow, albo stworzyć dla nich osobny zespół. Jeżeli reszta kolegów to widzi to cię poprze.
Ty szacuj sobie taski dla siebie a na dodatek możesz się z nich śmiać, że tracą życie na korpo.

No i możesz między czasie szukać czegoś nowego. U mnie w poprzedniej firmie źle management patrzył na nadgodziny i dobrze. Sam manager powinien o to zadbać.

Wszyscy piszą, żeby zwrócić uwagę, a to znowu nie jest takie łatwe - na początku można się bać być oskarżonym o to, że się broni swojego lenistwa. Ale to nic - trzeba twardo, asertywnie odmówić, kiedy ktoś się niby "kulturalnie" pyta na kiedy to będzie? czy dzisiaj to dowieziesz? - np fajna odpowiedź wtedy to zobaczę, aktualnie piszę testy do tego, chcę przetestować edge casy, albo zastanawiam się czy zrobić to na poziomie modelu czy w jakimś osobnym utilu

Ta odpowiedź jest jak świnka morska - ani fajna ani asertywna. Trzeba po prostu powiedzieć że będzie na za 2-3 dni i tyle.

Pinek napisał(a):

kiedy ktoś się niby "kulturalnie" pyta na kiedy to będzie?

To są dwa RÓŻNE pytania. Na powyższe po prostu należało by odpowiedzieć zgodnie z prawdą kiedy się można spodziewać rezultatu. Tylko tyle i aż tyle. Potem można dyskutować czemu tak długo/krótko itd.

dzisiaj to dowieziesz?

Natomiast tutaj zależy od tego czy estymacja była na dzisiaj albo było w jakikolwiek inny sposób zakomunikowane, że będzie dzisiaj to wtedy powinno być dzisiaj i takie pytanie jest jak najbardziej na miejscu. Jeśli jednak estymacja była na za dwa dni a ktoś pyta czy będzie dzisiaj to (o ile nie masz tego już zrobionego) to odpowiedź jest bardzo prosta - nie

Może po prostu estymujący i nadzorujący nie zgrali się w strefach czasowych? Dość typowy problem dzisiaj.

Szacowanie (czyli estymacja) a zobowiązanie (czyli commitment) to są dwie różne rzeczy.

Mogę szacować, że coś skończę w dwa dni. To znaczy, że taki termin uważam za najbardziej prawdopodobny, tzn. o szansach powodzenia na poziomie np. 60%. To jest środek rozkładu prawdopodobieństwa.

Zobowiązanie się na jakiś termin to co innego. W tym wypadku ręczę, do kiedy zrobię coś na 99% (teoretycznie rzecz jasna 100%, no ale ludzkie zdolności przewidywania mają swoje granice).

Niby oczywiste, ale nie takie oczywiste, bo szacowanie często jest mylone ze zobowiązaniem, i trzeba o tej różnicy przypominać.