Słabo opisane wymagania

0

Rozpocząłem swoją pierwszą pracę w pewnej firmie i pracuję już tu 1 rok 2 miesiące. Używam .NET Framework do pisania nowych modułów do starej aplikacji(ok. 10 lat). Firma ma nie stosuje dobrych praktyk. Większość czasu zajmuje mi zapoznanie się z opisem biznesowym projektu który jest bardzo zagmatwany i nieintuicyjny. Zanim dołączyłem do tej firmy uczyłem się .NET Core, a tą pracę zaakceptowałem żeby zdobyć pierwsze doświadczenie, jednak dzisiaj nie jestem zadowolony z tej firmy.

Pozostałe osoby z teamu pomagają mi, ale jak chcę się dowiedzieć czegoś, to tłumaczą w zagmatwany sposób nie zaczynają od opowiedzenia prostych rzeczy, od ogółu do szczegółu tylko, jak zaczynają coś tłumaczyć to omawiają co mam zrobić, mówią że mam dodać to i tamto, ale nie w taki sposób żebym zrozumiał problem całościowo, a skupiają się na tym małym fragmencie i jak staram się dopytywać to widać że są zirytowani, czasami nie odpowiadają nawet. Nie widzę chęci żeby im zależało na tym, czy to rozumiem, po prostu mam przypisane zadanie, którego opis ma czasami 1 zdanie i mam to pisać. Dostaję uwagi, że nie jestem samodzielny, bo za dużo pytam. Zawsze jak dostaję zadanie na początku, to nikt ze mną nie omawia co konkretnie ma być zrobione, wysyłają mi tylko zadanie, a opis często ma 1 zdanie. Praktycznie nigdy od nich nie wychodzi jakaś inicjatywa żeby coś wytłumaczyć i faktycznie głupio mi jest jak ciągle się o coś pytam, ale co ma zrobić jak nie mam wystarczająco informacji? Zdarzyło się że skończyłem zadanie, a okazało się że miało być inaczej, bo oni mieli inną wizję. Po skończeniu taska widzę całościowo, ze zadnia nie są trudne i mógłbym zrobić je szybciej gdyby informacje na temat wymagań były jasno przedstawione a nie ogólnikowo. Gdy jak wracam pamięcią do tego jak przedstawili mi tą funkcję do zaimplementowania na początku, to dziwię się jak można tak skomplikowanie opisać coś tak prostego...

Mimo że pracuję już tu dość sporo czasu, zarabiam nie za dużo, mimo że robię postępy i nauczyłem się niektórych technologii i narzędzi od zera. Ja zawszę słyszę że robię za wolno taski, a jak staram się tłumaczyć, że wymagania nie są przejrzyste to w odpowiedzi słyszę, że takie są wystarczające i żebym pytał product ownerów. Generalnie kończę zadania, na początku szło mi wolno i robiłem błędy jak to junior, ale teraz udaje mi sie kończyć szybciej i nie powtarzam błędów, ale oni tego nie zauwazaja i nigdy nie pochwalili mnie, ale ciągle wynajdują jakieś uwagi. Mam wrażenie że mają olewczy stosunek, do tego czy rozumiem i wiem co mam robić, może dlatego że myślą że tylko odpowiadam za opóźnienia. Widzę małe perspektywy rozwoju w tej firmie, bo technologie backendowe są stare, ale zaletą jest to że na froncie używam Angulara, którego się tutaj nauczyłem i mają duże pokrycie kodu testami. Same aplikacje też nie są ciekawe, ja implementuje zwykle CRUDa.

Czy to normalne, że praca juniora tak wygląda? Mam wrażenie ze reszta jest lepiej zorientowana w projekcie, ale dziwi mnie to, ze nie przekazuja mi wszystkich informacji i praktycznie ciągle trzeba się dopytywać żeby zrozumieć co mam zrobić.

Obawiam się że będzie trudno znaleźć pracę bo przez ten czas praktycznie nie miałem czasu na rozwój swoich projektów, a w .NET Core w tej pracy nie używałem.

Mimo że przepracowałem dość sporo, czuję że mało się nauczyłem (głównie .NET Framework, testowanie i złe praktyki programowania), bo dużą część czasu spędzałem nad czytaniem dokumentacji

Zastanawiam się nad dwiema opcjami zmiana pracy i rekrutacja na mida, ale nie wiem czy mnie przyjmą gdziekolwiek i czy uda mi się w ogóle przejść rekrutację, chyba że musiałbym przez miesiąc powtarzać .NET Core i zrobić jakiś projekt, a w dodatku wiele firm wymaga przynajmniej 2 lat doświadczenia, a gdyby gdzieś mnie przyjęli to mógłbym czuć się jak junior, bo nie mam komercyjnego doświadczenia z .net core. Druga możliwość to rekrutacja na juniora, ale to byłby dla mnie krok wstecz, zaczynać wszystko od początku.

Doradźcie mi co w takiej sytuacji zrobić.

2

Rekrutacja to coś co powinieneś robić cały czas niezależnie od tego czy chcesz zmienić pracę czy nie. Traktuj to jako ewaluację, którą robi ktoś z zewnątrz.

Co do Twoich problemów to proś seniorów o dokumentację, to jest Twoje prawo. Im masz większe seniority tym masz bardziej wywalone na opinie leszczy o to czy pytania są słabe czy nie. Ja np. przez kilka tygodni powtarzałem pytanie odnośnie słowniczka pojęć. I mój "scrum master" się z tego na początku śmiał. Ale przestał się z tego śmiać jak zacząłem te uwagi zgłaszać wyżej. Jako, że jesteś juniorem to nie polecam eskalować problemów poza zespół zanim nie zakomunikujesz ich wprost w zespole lub podczas retrospektyw. Z drugiej strony, kiedy takie komunikowanie w obrębie zespołu zawiedzie to spróbuj pogadać o tej sytuacji ze swoim managerem. Tylko nie próbuj skupiać się na narzekaniu. Skupiaj się na tym gdzie widzisz możliwą poprawę i co Cię blokuje przed rozwojem.

Widziałem też wielu "seniorów", którzy uważali, że są kozakami i nie zadawali pytań pomimo, że wielokrotnie miałem z nimi sesje wyrównawcze. Później musiałem z kilkoma osobami rozmawiać o brakach ich postępów, żeby ci seniorzy zaczęli w końcu zadawać pytania bo nie jestem wróżką i nie zidentyfikuję czego dokładnie nie wiedzą, mam wiele innych rzeczy na głowie.

3

Rozpocząłem swoją pierwszą pracę w pewnej firmie i pracuję już tu 1 rok 2 miesiące.

To, co opisujesz, bardziej przypomina sytuację, jakbyś się dopiero wdrażał w projekt.

tłumaczą w zagmatwany sposób nie zaczynają od opowiedzenia prostych rzeczy, od ogółu do szczegółu tylko, jak zaczynają coś tłumaczyć to omawiają co mam zrobić, mówią że mam dodać to i tamto, ale nie w taki sposób żebym zrozumiał problem całościowo,

Bo większość programistów nie umie się komunikować inaczej niż tylko slangiem zakładając, że odbiorca rozumie ten slang (a każdy projekt ma swój własny slang, więc jak wchodzisz do projektu, to dopiero ten slang poznajesz). Ogólnie trochę szkoda, że nie ma świadomości tego problemu, bo jego rozwiązanie (np. przez przeprowadzenia szkoleń z komunikacji wśród programistów) pomogłoby zaoszczędzić firmom gruby hajs (który jest przepalany właśnie na to, że trzeba ciągle wszystko precyzować), poza tym firmy robiące szkolenia też mogłyby zarobić.

Dostaję uwagi, że nie jestem samodzielny, bo za dużo pytam.

Z tym to ostrożnie, bo jak będziesz zbyt samodzielny, to też cię opieprzą, że nie umiesz pracować zespołowo.

wysyłają mi tylko zadanie, a opis często ma 1 zdanie

Tak jak mówię - to jest slang. I zakładanie, że odbiorca zna kontekst i napiszesz 1 zdanie i zrozumie.

Kiedyś jeden gość, z którym pracowałem, wytłumaczył, że to dlatego, że w firmie od dawna nie było nowych pracowników (więc programiści nie są przyzwyczajeni do wdrażania kogokolwiek). I to jest argument za tym, że firmy potrzebują rotacji pracowników po to, żeby usprawnić metody komunikacji (i może zadbać o dokumentację). Bo inaczej mamy zbyt niski bus factor, gdzie cała wiedza o projekcie jest skupiona w głowach kilku ludzi, którzy może łaskawie się nią podzielą. A jeśli się podzielą, to w najbardziej mglisty sposób, jaki się da.

faktycznie głupio mi jest jak ciągle się o coś pytam, ale co ma zrobić jak nie mam wystarczająco informacji? Zdarzyło się że skończyłem zadanie, a okazało się że miało być inaczej, bo oni mieli inną wizję

Jak potrzebujesz jakiejś informacji, to niestety musisz zapytać, nawet jak ci głupio. Czyli jednak też coś od siebie musisz dać, zrobić ten pierwszy krok, nawet jak oni nie zrobią. I teraz tak - normalni goście wtedy będą ci próbowali wytłumaczyć, zrobić calla z tobą itp. Mam wrażenie, że większość programistów chce dobrze, ale po prostu nie umie się komunikować.

widać że są zirytowani, czasami nie odpowiadają nawet.

Gorzej jeśli trafisz na burków, którzy po prostu nie są mili i nie wykazują dobrej woli. Wtedy to raczej już tylko pozostaje zmiana firmy bądź zespołu, żeby z takimi osobami nie pracować.

4
twoj_stary_pijany napisał(a):

Rekrutacja to coś co powinieneś robić cały czas niezależnie od tego czy chcesz zmienić pracę czy nie.

Bezsensowna strata czasu.

michaelDD napisał(a):

Firma ma nie stosuje dobrych praktyk.

Czyli czego twoim zdaniem.

Większość czasu zajmuje mi zapoznanie się z opisem biznesowym projektu który jest bardzo zagmatwany i nieintuicyjny. Zanim dołączyłem do tej firmy uczyłem się .NET Core, a tą pracę zaakceptowałem żeby zdobyć pierwsze doświadczenie, jednak dzisiaj nie jestem zadowolony z tej firmy.

To może trzeba się podszkolić z domeny biznesowej. Klepać kod to można po zawodówce. Żeby być programistą potrzeba czegoś więcej.
Ale musisz poszukać czegoś z prostszą domeną.

Pozostałe osoby z teamu pomagają mi, ale jak chcę się dowiedzieć czegoś, to tłumaczą w zagmatwany sposób nie zaczynają od opowiedzenia prostych rzeczy, od ogółu do szczegółu tylko, jak zaczynają coś tłumaczyć to omawiają co mam zrobić, mówią że mam dodać to i tamto, ale nie w taki sposób żebym zrozumiał problem całościowo, a skupiają się na tym małym fragmencie i jak staram się dopytywać to widać że są zirytowani, czasami nie odpowiadają nawet.

Ludzie mają swoją robotę i jak ci mają wytłumaczyć 10 lat pracy całego zespołu?

Rozpocząłem swoją pierwszą pracę w pewnej firmie i pracuję już tu 1 rok 2 miesiące.
Mimo że pracuję już tu dość sporo czasu, zarabiam nie za dużo,

To nie jest dużo czasu, a co do kasy to jak uwierzyłeś w to 15k dla każdego jesteś w błędzie, że tak jest.

Mimo że przepracowałem dość sporo, czuję że mało się nauczyłem (głównie .NET Framework, testowanie i złe praktyki programowania), bo dużą część czasu spędzałem nad czytaniem dokumentacji

:)

Zastanawiam się nad dwiema opcjami zmiana pracy i rekrutacja na mida, ale nie wiem czy mnie przyjmą gdziekolwiek

Z opisu wynika, że nie radzisz sobie na pozycji juniora to skąd ci przyszedł pomysł na mida?

Doradźcie mi co w takiej sytuacji zrobić.

Nie każdy musi być programistą.

LukeJL napisał(a):

Rozpocząłem swoją pierwszą pracę w pewnej firmie i pracuję już tu 1 rok 2 miesiące.
widać że są zirytowani, czasami nie odpowiadają nawet.

Gorzej jeśli trafisz na burków, którzy po prostu nie są mili i nie wykazują dobrej woli. Wtedy to raczej już tylko pozostaje zmiana firmy bądź zespołu, żeby z takimi osobami nie pracować.

W dwóch firmach odpowiadałem za wdrożenie (niańczenie nowych ludzi) i jak ktoś po roku dalej nie ogrania to znaczy, że jest coś nie tak i pewnie firma tylko na to czeka aż pójdzie wku. ludzi pracować gdzie indziej.

1
S4t napisał(a):

W dwóch firmach odpowiadałem za wdrożenie (niańczenie nowych ludzi) i jak ktoś po roku dalej nie ogrania to znaczy, że jest coś nie tak i pewnie firma tylko na to czeka aż pójdzie wku.. ludzi gdzie indziej.

To juz teraz przynajmnjej wiemy, z jakiego powodu musiales wylac swoje frustracje dla nas. Bardzo ci dziekujemy za ta garsc bezcennych informacji, w ktorych postanowiles sobie pocisnac na forum jakiegos juniorka, ulzylo ci?

@michaelDD: rok doswiadczenia to caly czas juniorskie stanowiska, nie widze tutaj zadnego cofania sie. Zreszta, przeciez te nazwy sa umowne i kazda firma robi po swojemu - jak sie $$ zgadzaja i firma fajna, to zadna roznica, co sobie tam wpisza. Szukaj czegos nowego i daj nam znac, jak rzucisz tego janusza

9

Ja mam ponad 6 lat doświadczenia i jak widzę zadanie z jednym zdaniem to też go nie rozumiem często i pytam osobę, która go założyła o doprecyzowanie mimo roku doświadczenia w firmie

3

Z opisu wynika, że nie radzisz sobie na pozycji juniora to skąd ci przyszedł pomysł na mida?

Ja to rozumiem raczej tak, że OP wszedł jako ktoś słabszy technicznie i mający mniejsze doświadczenie od innych programistów, więc początkowo zapewne mu pomagali, jednak przyklejona mu została łatka nieogara i teraz o cokolwiek zapyta, to inni programiści są zirytowani, czasami nie odpowiadają nawet.

To jest toksyczna sytuacja i nie wiadomo, czy OP faktycznie jest słaby, czy może to inni programiści mają słabe skille miękkie. Być może to i to. Niektórzy programiści po prostu nie lubią pomagać innym.

Jednak jak poszuka pracy gdzie indziej na stanowisku juniora, to może być to samo. Jak ktoś jest juniorem, to zawsze będzie traktowany jak junior (a niektórzy programiści wprost mówią, że nie lubią niańczyć juniorów). Trzeba więc samemu zdecydować, że się idzie dalej i stać się "midem" (w sensie bardziej samodzielnym i ogarniętym programistą). No ale to raczej będzie możliwe tylko w innej firmie. Oczywiście trzeba też coś umieć i wyciągać wnioski ze swoich niepowodzeń.

michaelDD napisał(a):

Mimo że pracuję już tu dość sporo czasu, zarabiam nie za dużo, mimo że robię postępy i nauczyłem się niektórych technologii i narzędzi od zera. Ja zawszę słyszę że robię za wolno taski,

Nauka technologii jest spoko i rozwój i w ogóle, ale czy pomyślałeś, że może przez to robisz za wolno taski, że musisz się dodatkowo uczyć technologii i narzędzi od zera?
Z drugiej strony w kolejnej firmie te narzędzia i technologie już będziesz znać.

4

Ja bym zmienił pracę. Bo inaczej nie dowiesz się, czy to problem u ciebie czy w teamie. Jak nie masz zróżnicowanego doświadczenia to ciężko wyłapać gdzie jest problem. Zgaduję, że problem jest w teamie, bo takie odpowiadanie na odczep nie jest profesjonalne i może pociągać za sobą inne problemy z komunikacją, czy problematycznością danych jednostek.

Co do nieogarniania po długim czasie: są projekty, których nie da się ogarnąć. W najgorszych przypadkach danego kodu nie da się ogarnąć, jeśli się go nie pisało, bo źle napisany kod nie zawiera w sobie kontekstu, który miał w głowie twórca

2

@slsy: Z mojego doświadczenia brak biznesowego kontekstu kodu który jest ściśle biznesowy (klient tak wymyślił i koniec) jest jednym z największych problemów w zrozumieniu systemu. Co z tego, że widzę że ktoś skleja sql, agreguje jakiś wynik jak wszystko jest w klasie technicznej GeneralRepository (czy inna świetna techniczna nazwa która nic nie mowi o zastosowaniu biznesowym) a metoda nazywa się GetResult() przyprawiona nazwami zmiennych sql, result, value, param. Potem masz poprawić bug bo coś się źle wylicza, ale już nikt nie powie co i po co się tam liczy. Programiści którzy ten kod napisali są oczywiście bardzo dumni i zirytowani durnymi pytaniami jakiegoś juniorka. Do czasu aż sami zmieniają pracę i wchodzą w podobny projekt oczywiście.

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