Dopiero co zmiłem firmę dwa lata temu i już jestem wyciśnięty jak cytrynka

2 lata temu zminiłem firmę, nowy projekt który niedawno wdróżyliśmy na produkcję.

Pracujemy w zespole interdyscyplinarnym tj w kulturze DevOps, tj. że zespół programistów jest w całości odpowiedzialny za cały "lifecycle" aplikacji i jest odpowiedzialny za wszystko. W praktyce wygląda to tak, że jest nas 5 programistów + jeden Manager/Scrum Master + jeden Product Owner. Od dwóch lat robię infrastrukturę + zbieranie wymagań i ich analizę na Confluence + programowanie + pisanie automatów + testy manualne. Zdarza mi się rozpisywać taski i tak dalej.

Problemem jest to, że po dwóch latach jestem wyciśnięty jak cytrynka, w sensie mam za dużo rzeczy aktualnie na głowie po wdrożeniu na produkcję którą mieliśmy w maju. Dokładane są mi coraz to nowe obowiązki. Przez pierwszy rok "pro bono" dokształcałem się z Clouda/Azure którego mamy w pracy jako samorozwój w weekendy, bo myślałem że to jest przyczyną, że mało wiem, czy tam jestem słąby.

W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy i wygląda to tak, że jak obniżę estymatę, a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy. Pracuję w firmie produktowej jak coś.

Coraz częściej myślę nad zmianą pracy, ale to już druga firma z kolei gdzie atmosfera jest podobna i natłok obowiązków. Mam coraz częściej myśli, że ten zawód nie jest dla mnie - czuję się wypalony. Mam 6 lat doświadczenia. Przechodził ktoś podobne problemy jak ja?

Dopiero co zmiłem firmę dwa lata temu

To sie zdecyduj? Dopiero co czy dwa lata temu? Bo IMHO 2 lata to strasznie duzo jest. Zwlaszcza ze nie wolno miec 3 lat na UoP bo biedziesz miec wtedy 3 miesiace wypowiedzenia

SylwesterW napisał(a):

W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy i wygląda to tak, że jak obniżę estymatę, a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy. Pracuję w firmie produktowej jak coś.

Macie odgórną presję, żeby wszystko zawsze dowozić? Jeżeli góra nie widzi, że macie za mało programistów w zespole, to bym się ewakuował z tej firmy. Gadaliście o tym na retro?

Tak to działa w wielu firmach niestety - cokolwiek mówią media o tym zawodzie to programista to wciąż lepiej płatny wyrobnik - nawał pracy zależy dla kogo pracuje.

Im większy będzie kryzys tym bardziej będą dociskać śrubę - ci którzy są młodzi w branży nawet niewiedza co może ich niedługo czekać w tej branży... lub poza nią.

Idź do dużego korpo to odpoczniesz, a za 2 lata napiszesz na forum że się nie rozwijasz...

SylwesterW napisał(a):

W praktyce wygląda to tak, że jest nas 5 programistów + jeden Manager/Scrum Master + jeden Product Owner. Od dwóch lat robię infrastrukturę + zbieranie wymagań i ich analizę na Confluence + programowanie + pisanie automatów + testy manualne. Zdarza mi się rozpisywać taski i tak dalej.

Płacą CI chociaż sensownie za taką robotę? Jakie masz widełki?

Szukaj czegoś nowego, aby doszło trochę świeżości i najlepiej projekt z ludźmi odpowiedzialnymi za poszczególne czynności, a nie każdy jest takim one man army.

@SylwesterW:

i wygląda to tak, że jak obniżę estymatę, a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy.

ale czekaj, ktoś Ci każe siedzieć, czy sam z siebie siedzisz?

"W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy". No ja też rzadko kiedy robię zadania które już robiłem, ciągle raczej robię coś nowego. A skoro "zmuszają" was, to estymujcie na => od 13 w gore (zgonie z tym co tu widze https://app.storypoint.poker, to max to 100).

Ale tak ogólnie to po Twoim płaczu jak dziecko, widać że nie jesteś asertywny i nie masz odwagi powiedzieć stop patologii. A patologię sami na siebie wrzuciliście zgadzając się na to wszystko co opisałeś. Sam jesteś sobie winny.

Jeszcze dorzucę analizę psychologiczną z kategorii "amateur" (w sensie, że ta analiza to amatorka)

• zakładam że masz mniej niż 5 lat expa [edit], doczytalem ze masz 6 lat expa, bylem blisko
• możesz pochodzić z małego miasta
• studia robiłeś w jakiejś pipidówie, zaocznie albo nie masz ich wcale
• w Twoim otoczeniu jest mało programistów, przez co mogło Ci się wydawać przez jakiś czas że jesteś elitą, więc dokładałeś sobie obowiązków
• w Twoim otoczeniu jest sporo programistów, którzy się przechwalają i nie chcesz być gorszy
• starasz się być ambitny i uważasz, że jeśli nie dowieziesz na czas, to będzie wielka skaza w Twoim CV
• łączą Cie koleżeńskie więzy z szefostwem
• masz niskie poczucie własnej wartości
• wierzysz w to, że jak wszystko dowieziesz na czas to będą fanfary i peany na Twoją część, ew. te legendarne podwyżki

Nie piszę tego złośliwie, po prostu sam większość tego przerobiłem na własnej skórze.
Daj znać czy trafiłem chociaż 50/50 :)

U mnie trafiłeś

SylwesterW napisał(a):

Przez pierwszy rok "pro bono" dokształcałem się z Clouda/Azure którego mamy w pracy jako samorozwój w weekendy, bo myślałem że to jest przyczyną, że mało wiem, czy tam jestem słąby.

Czyli imposter syndrome i nadganianie w wolnym czasie, bo zdaje ci się, że nie jesteś prawdziwym programistą. To najprostsza droga do wypalenia.

W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy i wygląda to tak, że jak obniżę estymatę,

To nie obniżaj. Scrum Poker to sposób w jaki menedżment robi w jajo programistów, żeby sami na siebie presję nakładali i sami się kłócili o jak najmniejszą estymatę, żeby pokazać, że są tak dobrymi programistami, że coś dla nich jest tylko 3 punkty i kiedy dla ciebie coś jest 8 punktów to boisz się opinii innych, że jesteś taki słaby i dajesz za wygraną i obniżasz estymatę tylko dlatego, że cię wkręcili. Czyż nie jest tak?

a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy.

To się nazywa brak asertywności. Popatrz sobie po wątkach na tym forum, to typowa pułapka.

Pracuję w firmie produktowej jak coś.

Brzmi jak JanuszSoft.

SylwesterW napisał(a):

W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy i wygląda to tak, że jak obniżę estymatę, a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy. Pracuję w firmie produktowej jak coś.

Coraz częściej myślę nad zmianą pracy, ale to już druga firma z kolei gdzie atmosfera jest podobna i natłok obowiązków. Mam coraz częściej myśli, że ten zawód nie jest dla mnie

Bo to nie z zawodem czy z firmą jest problem tylko z Tobą. Przestań zaniżać estymaty a twoje problemy znikną. Doświadczenie w tym zawodzie z grubsza sprowadza się do tego że estymujesz task i mnożysz to razy dwa
Jak poprawnie estymować taski?

obscurity napisał(a):

Bo to nie z zawodem czy z firmą jest problem tylko z Tobą. Przestań zaniżać estymaty a twoje problemy znikną. Doświadczenie w tym zawodzie z grubsza sprowadza się do tego że estymujesz task i mnożysz to razy dwa
Jak poprawnie estymować taski?

O to to! Jedyna z nie wielu rzeczy jaka po studiach została mi w głowie to gdy wykładowca mówił, jak estymował swój pierwszy projekt gdy bym PMem. Obliczał, wyliczał, kalkulował myślał i poszedł zadowolony z tymi wyliczeniami do swojego przełożonego. Szef popatrzył, podrapał się w głowę. Wziął ten wynik pomnożył razy dwa, dodał jeszcze 20%. Na koniec okazało się, że ta przeszacowana estymacja była na styk.

Mi raz menago mówił, że mam mu OD RAZU podać ile dni roboczych zejdzie na Change Request. Bez czytania powiedziałem mu, że między 1 a 1000 dni roboczych. Odwalił się. Po przeczytaniu wymagań wyceniłem na 30 dni roboczych a zrobiliśmy wszystko w 10.

Tylko przy tym trzeba umieć gadać i nawijać makaron na uszy. Od początku mówisz, że będzie dużo roboty i nastawiasz rozmówcę na to, że mogą po drodze być problemy. Jak są problemy to druga strona jest już przygotowana mentalnie bo przecież mówiłeś. A jak zrobisz wcześniej to się wszyscy cieszą, że się udało szybciej. Naturalnie, trzeba w tym wszystkim mieć umiar by nie przesadzać w żadną stronę.

PS. W życiu masz tyle na ile się godzisz. Jak dajesz sobie wciskać co raz więcej roboty to jest Twój problem.

tefu napisał(a):

O to to! Jedyna z nie wielu rzeczy jaka po studiach została mi w głowie to gdy wykładowca mówił, jak estymował swój pierwszy projekt gdy bym PMem. Obliczał, wyliczał, kalkulował myślał i poszedł zadowolony z tymi wyliczeniami do swojego przełożonego. Szef popatrzył, podrapał się w głowę. Wziął ten wynik pomnożył razy dwa, dodał jeszcze 20%. Na koniec okazało się, że ta przeszacowana estymacja była na styk.

Żeby lepiej estymować można zrobić kilka rzeczy:

• bazować na doświadczeniu / historycznych danych (podobna rzecz zajęła tyle czasu, to ta też podobnie zajmie). Problem w tym, że jak się robi coś nowego, to niekoniecznie się da.
• likwidować niepewność (jeżeli są niejasności, to je redukować. Np. "nie wiem jak zrobić X"? To można zrobić nowego taska "spike solution", w którym zrobi się PoC tego X).
• dzielić taski na mniejsze, bo mniejsze rzeczy łatwiej estymować
• zrezygnować z estymacji grupowej - dla gościa, który zna projekt i jest dobry technicznie ten sam task będzie łatwiejszy/mniej wymagający niż dla gościa, który wszedł do projektu/jest gorszy technicznie. Czemu więc upierać się przy estymacji grupowej, która wiadomo, że będzie zakłamana?

Tylko przy tym trzeba umieć gadać i nawijać makaron na uszy.

I to są te osławione "soft skills". Bo praca programisty to nie tylko programowanie.
Z drugiej strony trochę przykro, że o soft skills zwykle gadają pluszowe misie i lukrują zamiast walić prawdę z mostu. Pewnych rzeczy mówić nie wypada.

Od początku mówisz, że będzie dużo roboty i nastawiasz rozmówcę na to, że mogą po drodze być problemy. Jak są problemy to druga strona jest już przygotowana mentalnie bo przecież mówiłeś. A jak zrobisz wcześniej to się wszyscy cieszą, że się udało szybciej.

underpromise & overdeliver.
Niestety wiele ludzi robi odwrotnie.

LukeJL napisał(a):

Tylko przy tym trzeba umieć gadać i nawijać makaron na uszy.

I to są te osławione "soft skills". Bo praca programisty to nie tylko programowanie.
Z drugiej strony trochę przykro, że o soft skills zwykle gadają pluszowe misie i lukrują zamiast walić prawdę z mostu. Pewnych rzeczy mówić nie wypada.

Dla wyjaśnienia, pisząc o nawijaniu makaronu na uszy, nie miałem na myśli kłamania i umyślnego wprowadzania w błąd. Chodziło mi o umiejętność przedstawienia sytuacji, zadania w takim świetle by było to korzystne dla nas samych, żeby później nie musieć się tłumaczyć.

To wszystko też zależy z kim się pracuje i jakie konkretnie są zadania. Gdy masz mocny zespół i dobrego technicznego lidera czy post-technicznego PMa to sprawa wygląda inaczej gdy twoi przełożeni to osoby nietechniczne nie mające za bardzo pojęcia o tym co robisz w pracy. Do tego dochodzi czy zespół jest zgrany i chętny do współpracy, wsparcia czy też pracujesz z jakimiś piwniczakami, gburami co mają o wszystko pretensje.

W każdym miejscu trzeba się umieć wpasować. Chyba, że miejsce jest wyraźnie patologiczne, wówczas trzeba zmienić miejsce :-)
Umiejętność rozmowy i prezentacji samego siebie wymaga odpowiednio wysokiej pewności siebie. Natomiast OP ma w tej materii raczej spore braki.

tefu napisał(a):

Dla wyjaśnienia, pisząc o nawijaniu makaronu na uszy, nie miałem na myśli kłamania i umyślnego wprowadzania w błąd. Chodziło mi o umiejętność przedstawienia sytuacji, zadania w takim świetle by było to korzystne dla nas samych, żeby później nie musieć się tłumaczyć.

Takie coś ma swoją nazwę: manipulacja ;)

Wygląda na to, że ktoś w twojej firmie robi fuszerkę. Najgorsza możliwa sytuacją jest trafienie do projektu, gdzie taski są opisane na odwal. Jedno zdanie, brak wyjaśnienia co znaczą enigmatyczne skróty. Za to odpowiada PM. Dlaczego spada odpowiedzialność na ciebie? Ty jesteś programistą, a nie analitykiem biznesowym.

Nie dostarczysz rozwiązania, jeśli nie wiesz co masz zrobić na 100%, bo na późniejszych etapach, na CR okazuje się, że wszystko jest do kosza, tester wykrywa błędy. Etap analizy wymagań jest kluczowy. W przypadku, gdy masz strzępki informacji, musisz obdzwaniać 10 osób, żeby uzyskać informacje, to jest patologia. Może to są tzw. umiejętności miękkie twojego PM, który zrzuca na ciebie robotę? Niestety w niektórych firmach wprost w zakres obowiązków programisty wchodzi ustalanie wymagań. Task ma 1 zdanie opisu, żadnego screena z błędem. Odwalasz kilka dni roboty za PM na zebranie wymagań, bo jego pseudobiznesowe "analityczne" opisy g**no mówią.

Dla mnie idealny PM to osoba która ma wykształcenie techniczne, zna programowanie i opisuje taski w taki sposób, że potrafi odpalić debuggera i wskazać linijkę w kodzie gdzie wywala błąd. Programista może wtedy od razu przystąpić do roboty. Często PM to osoby po psychologiach, socjologiach, które nawet nie umieją taska opisać ze szczegółami technicznymi lub wkelejają jakiś słowotok z ChataGPT.

Odnośnie Scrum Pokera, Story pointów w żadnym innym zawodzie nie spotkasz się z tą patologią. Co to znaczy task na 3 SP? Ja nie znam takiej jednostki miary. Mogę powiedzieć że coś zajmie w przybliżeniu 5h , 2 dni. Story pointy, WTF?

adamKowal napisał(a):

Dla mnie idealny PM to osoba która ma wykształcenie techniczne, zna programowanie i opisuje taski w taki sposób, że potrafi odpalić debuggera i wskazać linijkę w kodzie gdzie wywala błąd. Programista może wtedy od razu przystąpić do roboty.

W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy i wygląda to tak, że jak obniżę estymatę, a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy. Pracuję w firmie produktowej jak coś.

Hello, alternatywnie można powiedzieć "słuchajcie, wyniknęły niespodziewane komplikacje X, Y, Z w związku z czym taska nie dam rady dowieźć w tym sprincie" i tyle.
Serio ludzie skąd u Was taka postawa chłopa pańszczyźnianego?
Co rusz podobne żale na tym forum można przeczytać i serio nie mogę się nadziwić, że dorośli ludzie, nienarzekający na brak ofert pracy (lepszą czy gorszą / za mniejszą czy większą kasę oferta zawsze się znajdzie) dają się sprowadzić do roli ofiary i robią darmowe nadgodziny (czyli w skali miesiąca Wasz "boss" okrada Was na setki/tysiące złotych)...

Serio robicie w gacie na samą myśl, że Wasz PO zrobi kwaśną minę jak usłyszy, że zadanie nie dojedzie czy o co chodzi?
Pomóżcie mi zrozumieć bo chyba jestem za głupi...

Ps. pomijam kompletnie fakt, że skoro celowo zaniżacie estymaty (żeby jakiś burn down chart ładnie wyglądał) by PO/scrum master byli zadowoleni i to jeszcze zadań których w życiu nie robiliście (nowe technologie jak mniemam) to kompletnie nie umiecie w edżajl/scrum/odpowiedzialną pracę whatever...

Tu nie ma się co śmiać. OP potrzebuje, jeśli nie psychologa, to długiej i żmudnej pracy nad swoim charakterem w inny sposób. Wiem coś o tym, bo znam identyczną sytuację u znajomej. Takim osobom rady w stylu "weź się ogarnij i po prostu powiedz że nie ma szans tego dowieźć" są na nic. Nic do nich nie trafia. Te rady tylko pogarszają sytuację i zwiększają poczucie winy. A przy następnej sytuacji konfliktowej i tak pękną, i skończy się na "tak szefie, zrobię co w mojej mocy" i potem siedzi taka osoba znowu w weekend nad pracą za darmo.

Oczywiście, że wszyscy tutaj macie rację. Ale takiej negatywnej postawy nie da się wyprostować pojedynczymi radami.

RequiredNickname napisał(a):

Serio robicie w gacie na samą myśl, że Wasz PO zrobi kwaśną minę jak usłyszy, że zadanie nie dojedzie czy o co chodzi?
Pomóżcie mi zrozumieć bo chyba jestem za głupi...

No zależy od firmy ale w paru w jakich pracowałem scrum to świętość. Lepiej powiedzieć że się dowiezie mniej niż nie dowieźć taska. Dwa razy taka wpadka i sytuacja jest eskalowana na poziom wyżej, gdzie trzeba ustalić "action itemy", tłumaczyć się i potem z nich rozliczać, a jak nie to program naprawczy i do widzenia a w najlepszym razie brak bonusu miesięcznego / kwartalnego.

Jak dla mnie debilizm bo doprowadza to do sytuacji że ludzie boją się dobierać taki do sprintu i biorą pewniaki (takie które są najczęściej już zaimplementowane na boku) i marnują połowę czasu sprintu

SylwesterW napisał(a):

W estymatach w Scrum Pokerze jesteśmy zmuszani do estymowania często zadań których nigdy nie robiliśmy i wygląda to tak, że jak obniżę estymatę, a w zadaniu wyjdzie coś skomplikowanego, to by dowieźć wszystko muszę siedzieć nadgodziny za darmo, tj. "crunchować". Zdarzyło mi się to już wiele razy. Pracuję w firmie produktowej jak coś.

Możesz mi wyjaśnić w jaki sposób jesteś zmuszany przy złych estymatach, np, pierwszy raz masz zadanie albo sporo unknowns i estymujesz na 2, a okazało się, że 5? Wtedy takie rzeczy się omawia na retro i trudno, nie dowozi się, bo macie pewne Velocity i źle wyestymowaliście, poza tym 3 + 2 + 3 + 2 to nie to samo co 5 + 5 taski.

"Dziadku, to nie tu się wpisuje"

Odnośnie fullstackowania próbowałeś pogadać z zespołem i kimś wyżej o tym, że przydaliby się oddzielni testerzy, devops itp?

Autor wpadł się wyżalić po czym zawstydziło go, że ludzie nie rozumieją jak można mieć taką mentalność niewolnika po czym nigdy nie wrócił.

Można się rozejść...