Czy ja pracuje w normalnej firmie? pytanie do frontów i managerow

4

Wiem że nie, ale nie wiem na ile to są częste przypadki. To już moja czwarta firma, ale tylko tutaj są dziwne dla mnie praktyki.

Aplikacja(green field) dosyć spora, ale tylko 1 front i 1backend + uczący się grafik + kilka osób które mają mówić co ma być w apce i jak działać(nie wiedzą).

Okazuje się, że grafik nie ogarnia praktycznie nic, nigdy nie mialem doświadczenia z uczącym się grafikiem, zawsze dostawałem elegancki UI do zakodowania. Jednak "grafik" to spoko gość, więc jakoś się dotarliśmy.

Nikt nie chce klepnąć widoków do zakodowania, chcą to już mieć zakodowane i wtedy decydować czy to fajne. W ten sposób napisałem chyba 3 razy te samą aplikację, i to nie były drobne zmiany, tylko cały template do wymiany. W ten sposób straciliśmy mnóstwo czasu.

Po kilku miesiącach okazuje się, że jesteśmy w dupie z czasem i trzeba szybko coś pokazać "górze" - robimy na sztywno jakieś pierdoły, które potem wywalamy...
Takich prezentacji ze stratą czasu na przygotowanie czegoś niedziałającego było ze 3 w ciągu roku - każde przygotowanie takiego gówna zajmowało ok. 5dni, więc 3 tyg robocze do kosza.

Mimo że nie mamy czasu i zamiast skupić się na działającej apce, "architekci" od apki zastanawiają się, czy button powinien być bardziej w prawo, czy w lewo etc. - znowu tracimy czas.

Po drodze przesuwanie terminu oddania apki, która nigdy nie miała żadnej estymacji. - terminy z d**y nierealne, ale już się liczy, że było przesuwane kilka razy :)

Wszystko jest robione na szybko + ciągle zmiany + dopiero po roku wiadomo jak finalnie powinna wyglądać apka i jakie funkcjonalności ma mieć.

Na urlopie dowiedziałem się, że apka już jest po oficjalnej premierze i szukają klientów. Oszukują klientów i wywierają presje na mnie i backendzie, chcą usłyszeć szybką estymacje, dla porównania z kolegami z innych firm jak im dałem do wyceny taski to było 2-3msc, a u nas chcieli maks w tydzień.

Próbowałem wyjaśnić ile takie zadania trwają, jednak "co to jest zakodować takie bloczki, kopiuj wklej i to łatwe ogólnie jest." - niestety nie umiem chyba rozmawiać z osobą która się nie ma pojęcia, ale wypowiada jako spec i ciągle wywiera presje na szybką estymację. Ewentualnie masz minute żeby wyjaśnić jak działa świat frontu, a on i tak skwituje, że to łatwe... Prywatnie taką osobę bym wyśmiał i powiedział co myśle, ale chce zachować profesjonalizm i chce uniknąć kłótni.

Bonusy:

  • programista na L4/Urlopie? Co tam, piszemy do niego bo trzeba coś zrobić pilnie.
  • dwa razy upominałem się o wypłatę (ostatecznie hajs po terminie).
4

Jak kasa po terminie, to pierwszy sygnał żeby pisać CV. Drugi to presja na terminy. Chyba że zarabiasz dużo, wtedy można jeszcze trochę pociągnąć, i aby tylko nie dać się wrobić w nadgodziny i pracę w czasie wolnym. Tu trzeba pouczyć kolegów, żeby nikt się nie wyrywał, bo np. backend będzie do przodu, a front w tyle.

Co do pytania, to nie jest normalna firma, co nie zmienia faktu, że dużo firm zobowiązuję się do nierealnych terminów i potem starają się zagiąć czasoprzestrzeń.

58

Nie jest to normalne. Brzmi jak typowy janusz soft. Skoro tłumaczenia nic nie dają to po prostu rób swoim tempem i każda zaczepkę skwituj, że nie da się szybciej. W międzyczasie wysyłaj CV.

1
LubieApap napisał(a):

Wiem że nie, ale nie wiem na ile to są częste przypadki. To już moja czwarta firma, ale tylko tutaj są dziwne dla mnie praktyki.

Aplikacja(green field) dosyć spora,

Jak spora, to już nie greenfield. Niestety firmy mają tendencję do nazywania greenfieldami każdego w miarę młodego projektu. Tym niemniej ludzie w kilka miesięcy potrafią narąbać mocne spaghetti albo nakłaść masy wzorców projektowych przeinżynierując całe rozwiązanie. Na tym etapie przestaje być to greenfieldem, co najwyżej jest to tak sprzedawane na rozmowach o pracę, żeby skusić kandydata.

Nikt nie chce klepnąć widoków do zakodowania, chcą to już mieć zakodowane i wtedy decydować czy to fajne. W ten sposób napisałem chyba 3 razy te samą aplikację, i to nie były drobne zmiany, tylko cały template do wymiany. W ten sposób straciliśmy mnóstwo czasu.

Po kilku miesiącach okazuje się, że jesteśmy w dupie z czasem i trzeba szybko coś pokazać "górze" - robimy na sztywno jakieś pierdoły, które potem wywalamy...

Tutaj można by się zastanowić, w jaki sposób zrobić tak, żeby nie wywalać całego kodu. Co się zmienia ciągle, a co zostaje takie samo?

I tam gdzie się zmienia to trudno, będziesz pisać, a potem wyrzucać, smuteczek. Tym niemniej jakaś podstawowa architektura raczej nie musi się tak szybko zmienić. Jakieś helpery, które napiszesz przy okazji pisania czegoś też mogą być potem używane ponownie.

Czyli stabilny core + niestabilne eksperymenty. To nie musi być wcale złe, o ile faktycznie core będzie rozwijany sensownie.

Na urlopie dowiedziałem się, że apka już jest po oficjalnej premierze i szukają klientów. Oszukują klientów

Czyli patologia. O ile faktycznie oszukują. Bo apka już jest po oficjalnej premierze i szukają klientów to brzmi trochę jak MVP/przedsprzedaż, czyli normalna praktyka w startupach, że się sprzedaje coś niezrobione do końca, żeby sprawdzić czy ktoś to w ogóle kupi i jest sens robić dalej. I żeby zebrać kasę potrzebną na robienie.

i wywierają presje na mnie i backendzie, chcą usłyszeć szybką estymacje, dla porównania z kolegami z innych firm jak im dałem do wyceny taski to było 2-3msc, a u nas chcieli maks w tydzień.

Kolejna patologia. Jak chcą w tydzień, to niech sami robią. Po to zatrudniają specjalistów, żeby specjalista się wypowiedział, ile to zajmie. W Clean Coder coś o tym było.

Próbowałem wyjaśnić ile takie zadania trwają, jednak "co to jest zakodować takie bloczki, kopiuj wklej i to łatwe ogólnie jest."

To tylko klikanie w komputer XD Osoba, która takie rzeczy wygaduje, nie ma pojęcia o niczym i nie szanuje swoich współpracowników. Za samo słuchanie takich idiotycznych tekstów powinna się należeć dodatkowa premia.

  • niestety nie umiem chyba rozmawiać z osobą która się nie ma pojęcia, ale wypowiada jako spec i ciągle wywiera presje na szybką estymację. Ewentualnie masz minute żeby wyjaśnić jak działa świat frontu, a on i tak skwituje, że to łatwe... Prywatnie taką osobę bym wyśmiał i powiedział co myśle, ale chce zachować profesjonalizm i chce uniknąć kłótni.

No ty chcesz zachować profesjonalizm, a ta druga osoba go nie zachowuje. Ogólnie toksyczna atmosfera.

  • dwa razy upominałem się o wypłatę (ostatecznie hajs po terminie).

Opóźnienia w wypłatach to co najmniej żółta lampka, o ile nie czerwona (zależy jak wielkie opóźnienie, jak często, w jaki sposób to jest komunikowane. Że coś raz przyszło kilka dni później, to nie robiłbym afery, ale jak nagminnie są duże opóźnienia i trzeba się samemu upominać o kasę, bo firma gra na zwłokę, to już czerwona lampka).

Czyli ogólnie ja bym składał już CV gdzie indziej, bo masz tam toksyczną atmosferę i kretynów, którym nawet nie powiesz, że są kretynami, bo nie wypada.

1
LubieApap napisał(a):

Wszystko jest robione na szybko + ciągle zmiany + dopiero po roku wiadomo jak finalnie powinna wyglądać apka i jakie funkcjonalności ma mieć.

LubieApap napisał(a):

terminy z d**y nierealne, ale już się liczy, że było przesuwane kilka razy

Pracuję jako Java Developer w korporacjach już od paru dobrych lat i dla mnie to już norma, nawet uczę się przestawać na to zwracać uwagę, po prostu robić swoim tempem, te 8h na zdalnej i zamykać laptopa. Wiem już teraz że w styczniu czeka mnie tzw. "crunch" ponieważ aplikacja nad którą pracuję miała deadline do końca tego roku a jeszcze nie jest ukończona.

Staram się do tego podchodzić w ten sposób, że to co się dzieje u mnie, a mam podobnie do Ciebie to po prostu pieniądze mi to wynagradzają i staram się tak gdzieś do 40 stki popracować, coś odłożyć i zacząć robić coś innego, ponieważ nie wyobrażam sobie robić na spinie do 60tki w Scrumie pod batem.

1
LubieApap napisał(a):

Wiem że nie, ale nie wiem na ile to są częste przypadki. To już moja czwarta firma, ale tylko tutaj są dziwne dla mnie praktyki.

Aplikacja(green field) dosyć spora, ale tylko 1 front i 1backend + uczący się grafik + kilka osób które mają mówić co ma być w apce i jak działać(nie wiedzą).

a bazę danych kto robi? (jeśli jest)
te kilka osób co nie wiedzą to jest patola
niestety częsta

10

A zimno u was w kiblu? Bo jak tak to może pracowaliśmy w tej samej firmie xD

Generalnie patologia, uciekaj stamtąd

4

Jak kasa po terminie to uciekac -> chyba ze jest wazniejszy powod by zostac. No chyba ze to np. stawka rynkowa x2.

Co do estymat to dajesz tyle ile Ci sie wydaje, a jak sie komus nie podoba to mu powiedz ze moze sobie wyestymowac na 1 story point, ale nie zrobisz tego szybciej niz np. 2 tygodnie.

To przychodzi z wiekiem, ale w Scrumie trzeba estymowac z gorka. Wtedy masz czas na cala poboczna prace, pomoc innym, poprawienie dokumentacji, testy, automatyzacje czy improvementy, wlaczenie sie w opracowanie grubszych tematow, roadmapy zespolu itp.

0
WhiteLightning napisał(a):

To przychodzi z wiekiem, ale w Scrumie trzeba estymowac z gorka. Wtedy masz czas na cala poboczna prace, pomoc innym, poprawienie dokumentacji, testy, automatyzacje czy improvementy, wlaczenie sie w opracowanie grubszych tematow, roadmapy zespolu itp.

U nas jest taka toksyczna atmosfera w zespole że manager (który dawniej był programistą) zbija nam często estymaty i się na to godzimy, tworzy to potem atmosferę presji i nieraz robienia po godzinach by coś dociągnąć za darmo. Dodatkowo zauważyłem, że potem wśród programistów w moim zespole wytworzyło się "licytowanie" i boję się dawać mniej.

No i co wtedy zrobisz? Dalej uparcie będziesz stał przy swoim?

5
fastis napisał(a):

U nas jest taka toksyczna atmosfera w zespole że manager (który dawniej był programistą) zbija nam często estymaty i się na to godzimy, tworzy to potem atmosferę presji i nieraz robienia po godzinach by coś dociągnąć za darmo. Dodatkowo zauważyłem, że potem wśród programistów w moim zespole wytworzyło się "licytowanie" i boję się dawać mniej.

No i co wtedy zrobisz? Dalej uparcie będziesz stał przy swoim?

Dlaczego ludzie się na to godzą? Serio. Bo problem się powtarza. Wydaje mi się, że jeśli ktoś się na to godzi, to pewnie należy do którejś z grup:

  • jest juniorem i nie ma innej opcji. Jak rzuci pracę, to wróci na kasę albo na bezrobocie.
  • pomimo długiego stażu nic nie umie i żadna firma go nie zatrudni, więc znowu. Jak odejdzie z pracy, to bezrobocie.
  • dają o wiele większą kasę niż inne firmy. Za 50-100 tysięcy miesięcznie jeszcze zrozumiałbym, że ktoś się godzi na takie coś, bo przynajmniej ma coś w zamian, czego inne firmy mu nie dadzą. No bo jak ktoś zarabia w miarę rynkowe stawki, to po co się męczyć, jak w innej pracy będzie miał podobną kasę, a mniej patologii (chociaż w każdej firmie jakaś patologia będzie)
  • ma problemy z asertywnością i pewnością siebie

Czy jeszcze może być jakiś inny powód?

0
LukeJL napisał(a):
fastis napisał(a):

U nas jest taka toksyczna atmosfera w zespole że manager (który dawniej był programistą) zbija nam często estymaty i się na to godzimy, tworzy to potem atmosferę presji i nieraz robienia po godzinach by coś dociągnąć za darmo. Dodatkowo zauważyłem, że potem wśród programistów w moim zespole wytworzyło się "licytowanie" i boję się dawać mniej.

No i co wtedy zrobisz? Dalej uparcie będziesz stał przy swoim?

Dlaczego ludzie się na to godzą? Serio. Bo problem się powtarza. Wydaje mi się, że jeśli ktoś się na to godzi, to pewnie należy do którejś z grup:

  • jest juniorem i nie ma innej opcji. Jak rzuci pracę, to wróci na kasę albo na bezrobocie.
  • pomimo długiego stażu nic nie umie i żadna firma go nie zatrudni, więc znowu. Jak odejdzie z pracy, to bezrobocie.
  • dają o wiele większą kasę niż inne firmy. Za 50-100 tysięcy miesięcznie jeszcze zrozumiałbym, że ktoś się godzi na takie coś, bo przynajmniej ma coś w zamian, czego inne firmy mu nie dadzą. No bo jak ktoś zarabia w miarę rynkowe stawki, to po co się męczyć, jak w innej pracy będzie miał podobną kasę, a mniej patologii (chociaż w każdej firmie jakaś patologia będzie)
  • ma problemy z asertywnością i pewnością siebie

Czy jeszcze może być jakiś inny powód?

Jak jesteś początkującym i projekt jest taki w którym możesz się czegoś nauczyć to warto posiedzieć. W wielu miejscach nie dostaniesz możliwości pracy nad wielowątkowością, np poprawiania jakiegoś buga, albo klepania od zera. Z reguły takie taski są dla starszych programistów zarezerwowane i trzeba o nie walczyć.

7

Po pierwsze to nie wiem o co pytasz, to są jakieś zwierzenia czy pamiętnik?

"W ten sposób straciliśmy mnóstwo czasu."

Yyy, jak to straciliśmy? O ile nie jesteś udziałowcem w tej spółce tylko pracownikiem to nic nie straciłeś tylko miałeś robotę... płatną.

Jak się robota nie podoba to zmieniasz.

1

@fastis: tak, jesli uwazam ze task zajmie mi 3-4 dni to nie zgodze sie by ktos mi to kazal zrobic w jeden dzien, chyba ze powie jasno ze to ma byc np. ledwo dzialajaca proteza albo ktos inny bedzie taska robil. Poza tym skoro macie religie scrumowa powiedz na retro ze cos jest nie tak z estymatami. Jak siedzicie za darmo po godzinach to sztucznie nakrecacie velocity zespolu i pozniej to coraz mocniej sie na zespole odbija. Do tego doswiadczenie mowi ze robota i tak swoje zajmie, nawet jesli sie wyestymuje taska na mniej.

Nie pewno nie bede robil darmowych nadgodzin bo ktos wywiera na mnie presje. Owszem zdarzalo mi sie siedziec za darmo po godzinach, ale wtedy zawsze chcialem, bylo drugie dno, typu robilem cos waznego/ciekawego i chcialem to dowiezc za wszelka cene, albo zmienialem calkowicie role i chcialem wejsc na obroty w nowej i co najwazniejsze bylo to chwilowe.

Poza tym polece kolege z forum TL;DR estymata jest szacunkiem :

3
WhiteLightning napisał(a):

Owszem zdarzalo mi sie siedziec za darmo po godzinach, ale wtedy zawsze chcialem, bylo drugie dno, typu robilem cos waznego/ciekawego i chcialem to dowiezc za wszelka cene

Czasami ważne rzeczy są ważne tylko dlatego, że ktoś z góry nam to tak przedstawił. Oby "ważne" nie stało się regularne, bo ważna jest tutaj świadomość sytuacji. Nie mówie o Tobie, ale ogólnie o tego typu sytuacjach.

5

Chyba nie było tygodnia, żebym w robocie nie słyszał "to jest bardzo ważne" i w 99% przypadków nie było xD

2
LukeJL napisał(a):

Dlaczego ludzie się na to godzą? Serio. Bo problem się powtarza. Wydaje mi się, że jeśli ktoś się na to godzi, to pewnie należy do którejś z grup:

Nie znam odpowiedzi na to pytanie, tak jak nie znam odpowiedzi na pytanie dlaczego bite żony zostają z mężem. Podejrzewam jedynie, że zbiory możliwych odpowiedzi mocno się na siebie nakładają.

Crowstorm napisał(a):

Chyba nie było tygodnia, żebym w robocie nie słyszał "to jest bardzo ważne" i w 99% przypadków nie było xD

I jeszcze przez 3 miesiące leżało sobie w jakiejś projektowej zamrażarce, aż dojrzało do stanu " O św. Janie Pawle, to MUSI być na wczoraj".

2
piotrpo napisał(a):

I jeszcze przez 3 miesiące leżało sobie w jakiejś projektowej zamrażarce, aż dojrzało do stanu " O św. Janie Pawle, to MUSI być na wczoraj".

A na koniec okazało się, że to nie to co chciał klient bo po co zrobić dokładną dokumentację tylko lepiej 2-3 strony ogólnego opisu i to jeszcze nie zawsze potem potwierdzonego przez klienta ayy

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