Sam sobie ustal co masz zrobić

7

Jestem programistą od kilku lat i z każdym kolejnym rokiem dopada mnie coraz większa niechęć do mojej pracy. Zmieniałem firmy kilkakrotnie, praktycznie wszędzie jest podobnie.

Ciągły wyścig na czas, niepokój, poganianie przez TL. Dotyka mnie poczucie bezsensu pracy - robię mało istotne rzeczy, które zajmują nieadekwatnie za dużo czasu. Czuję się jakbym był uczniakiem w szkole, któremu nauczyciel codziennie zadaje prace domowe do odrobienia.
Brak kontaktu z ludźmi, nudna monotonna praca, czytanie kodu, pisanie, testowanie. Siedzę wpatrzony w monitor po 8 godzin dzienne.

Ciągła presja na uczenie się nowych rzeczy. Nie chodzi o to, że szlifuję już zdobytą wiedzę czytając ciekawostki, nowości, ale muszę uczyć się technologii od A do Z, kompletnie od początku. Szczególnie jak zmieniam pracę, widzę że coraz więcej firm wpisuje więcej i więcej wymagań w ogłoszeniach. Zdarza się, że nie mam czasu prywatnego, bo w innej pracy używam innego stacka technologicznego, a po kilku latach zmieniają się trendy i trzeba się uczyć od nowa. Programista robi się takim człowiekiem od wszystkiego ma znać pierydliard języków programowania, AWSy, konfigurować pipeliny, być testerem i wiele innych. Jak się nauczysz nawet 10 frameworków na poziomie experta, w innej pracy będą uzywać innych, których będziesz musiał znowu uczyć się od nowa. W pracy nie licz na to, że koledzy cię nauczą. Każdy patrzy na czubek swojego nosa, bo im też nikt paluszkiem nie pokazywał.

Tickety w pracy nieopisane, wklepany tekst niczym Lorem Ipsum na odpieprz. Wielokrotnie spotykałem się z tym, że opis jest niekompletny i nikogo to nie obchodzi, bo "tak powinno być, nikt ci młody nie będzie podsuwał pod nos informacji, zapytaj tamtego, on ci wyjaśni". "Za mało czasu jest, żeby robić opisy zadań..., musisz się pytać, zapytaj kogoś, niech ci wytłumaczy". Nigdy chyba nie miałem sytuacji, że wiem dokładnie o co chodzi, zawsze są jakieś niedomówienia lub nieścisłości w tych opisach. Chciałbym po prostu żeby te opisy były jak w zadanych na matematyce, masz wszystkie niezbędne dane do zadania i możesz od razu pisać.

Według mnie po to są te tickety w jirze żeby wszystkie wymagania były sformalizowane. W kodowaniu nazwa każdej zmiennej jest istotna, a z tego co widzę w większości firm w których pracowałem wymagania są spisane jak w kiblu na drzwiach. Uważam że tą częścią powinna zająć się osoba techniczna, natomiast zazwyczaj robią to ludzie którzy gadają z biznesem i mają nikłe pojęcie o programowaniu, a ja muszę sobie i tak później wszystko tłumaczyć na język technologii, ustawiać calle z technicznymi osobami, żeby mi przetłumaczyły. Rozmawiałem z kilkoma osobami o tym i słyszę, że mam roszczeniowe podejście. Jakbym mówił do nich chińskm językiem. Czy ja jestem roszczeniowy? Czy inni dają sobie pomiatać? Chcę wiedzeć co dokładnie mam zrobić, to za dużo?

Jedna z największych patologii którą spotkałem w pracy: proszę o wyjaśnienia, to obrywam opieprz za to, że nie jestem samodzielny i zajmuje seniorom czas. Z drugiej strony chcę pracować samodzielnie, to nie potrafię ze względu na to, że opisy ticketów nic nie mówią lub brakuje jakichś istotnych informacji żeby móc je zrobić. Pracowałem w firmie gdzie w tickecie jest napisane, żeby dodać metodę wykonując X, w klasie o nazwie Y. Nikt tych wymagań w jirze nie aktualizował. Dostarczyłem rozwiązanie, manager na to: ojej, ale nie tak miało być, dlaczego zrobiłeś w tej klasie? Olaboga!!! tyle czasu zmarnowane. Trzeba będzie poprawiać, a mogłeś się zapytać i upewnić!!!
Ja powiedziałem, że tak było napisane w wymaganiach na jirze. "Dlaczego się nie pytałeś?, mogłeś się zapytać." Jest takie zrzucanie winy na mnie, niby ja mam jeszcze ustalać sobie co mam zrobić? Ja wyobrażam sobie, że na Jirze są opisane wymagania na tip top, bo to jest taki tekst formalny z ustaleniami.

Inny przykład: prawię kończę zadanie, dowiaduje się, że "ano bo ja miałem spotkanie z biznesem i teraz zmienili i chcą inaczej". Nie poinformowali wcześniej, a ja jak głupi męczyłem się nad czymś kilka godzin i kod jest do usnięcia. Ja jako programista nie mam takiej siły przebicia, żeby zrozumieli, że to co dotychczs zrobiłem, jest w jakimś stopniu w porządku i co jakby przekonać klienta, że mamy napisane trochę w innej formie i może przy niej pozostaniemy, ale nie, nie i już, takie są ustalenia i nie ma dyskusji.

W każdej firmie. w której dotychczas pracowałem zazwyczaj tak było. Ja nie wiem dlaczego nie ma takiej technicznej osoby, która by nad tym czuwała. Powsadzali te nietechniczne osoby, które napiszą ci historyjki "Lorem Ipsum", przeczytasz i masz może 30% informacji potrzebnych do rozwiązania, a resztę musisz wyciągać od innych osób.

Ręce mi opadają od takiej pracy jak w chlewie. Możecie teraz napisać że nie mam racji, bo praca programisty polega na dogadywaniu szczegółów.

Nie rozumiem tego kompletnie. Jest Jira jaki jest problem żeby wpisać najdokładniej wszystkie wymogi i aktualizować jeśli coś ulegnie zmianie?
Nie wiem czy ja miałem takiego pecha, czy w większości firm tak jest, że robienie rozwlekłych opis zadań jest traktowany jako strata czasu, a jak chcesz się dowiedzieć co znaczy enigmatyczny skrót, to masz obdzwaniać wszystkich i pytać się.

Czy to kolejny aspekt w pracy w pracy programisty gdzie ludzie daje sobą pomiatać? Czy programista ma być osobą od zbierania wymagań?

W wielu zawodach przychodzi klient z wymaganiami i mówi np. że "plakat ma być zrobiony w takim kolorze, ma mieć takie wymiary, etc". W IT wymagania są formie "Ma być plakat". A jaki dokładnie? Nie wiadomo. Zapytaj kogoś.

Obserwuję, że w IT spisywanie wymagań, ustalanie jest spychane na programistów - "sam sobie ustal co masz zrobić". A w firmach w których pracowałem były oddelegowane osoby od tego, ale jakoże byli netechniczni to ich opisy były bezwartościowe, gdyż dają może 30% zrozumienia co ma być zrobione a resztę trzeba dogadywać z kimś technicznym, kto zna projekt od tej strony.

Czy przesadzam? W waszych firmach też tak jest? Mam w ogóle wątpliwości czy IT jest dla mnie jeśli praca wszędzie tak wygląda.

10

Tak to już jest, że poza technicznymi to reszta pracuje jakby byli jakimiś dziećmi w przedszkolu.

5

bo ludzie nie potrafią pisać, normalnie pisać po polsku
jeżeli firma jest ą i ę i próbują wszystko pisać po angielsku to już w ogóle maskara

4

Zmień strategię. Pisz komentarz w tickecie, że brak pełnych wymagań, napisz czego brakuje odbij ticket do TL i elo. Będzie miał wonty to "tu jest czego mi brakuje do wykonania zadania" i kończysz temat. Jak tam bardzo Ci nie pasuje ta praca to nic nie stracisz.

U mnie jest podobnie, ale na spotkaniu gdzie ustalane są szczegóły są wszyscy zarówno biznes jak i programiści, więc wiemy co robić. Gorzej jak nie ma mnie na takim spotkaniu to muszę dopytywać i często to rodzi podobne frustracje biznesu, ale nic na to nie poradzę. Nie ma opisu, nie było mnie a task trafił do mnie to sorry ale albo odpowiedzą albo zrobię po swojemu i będzie źle. Na szczęście jest jeszcze QA który czesto też nie wie jak cos ma działać to ostatecznie jego odpowiedzialnością jest doprecyzowanie zadania i najwyżej zadanie wraca do mnie jako do poprawy

Inna sprawa, to jak to jest, że zadanie trafia do seniorów i nagle co, oni wiedzą co robić u Ciebie? Dziwne, prawda?

Może rozwiązaniem byłoby wejście do świata biznesu i jakoś chęć pomocy TLowi powiesz że chciałbyś uczestniczyć w ustaleniach zadań

0

a zapytam - jesteś po studiach około it, czy z zewnątrz ?

2

ja też w takiej sytuacji piszę komentarze i maile z pytaniami
szukając nowej roboty.
bo ten kto pokazuje że reszta się obija to łatwo w danej firmie mieć nie będzie, i wykolegują go w najmniej odpowiednim momencie

4

Po pierwsza w jakis magiczny sposob idealizujesz świat. Wszedzie indziej pewnie jest podobnie. Może zbyt czesto zmieniasz prace i nie ograniasz domeny i nie znasz ludzi? Może masz wygórowane oczekiwania. Może źle wybierasz firmy dla siebie i kierujesz się złymi kryteriami. A ciśnienie to jest na Oiomie a nie w IT. Chyba masz depresjie albo nie umiesz ogarnąć życia poza pracą która stała się twoim głównym aspektem życia.

0

No witaj wśród programistow. Nie przesadzaj że zmnieniasz frameworki co chwilę, to nie zmienia się aż tak często.

Poza tym - skoro się nie podoba to co zatrzymuje cię żeby zostać notariuszem albo chirurgiem plastycznym w prywatnej klinice? Tak myślałem. Ano właśnie, gdzie indziej nie jest tak łatwo stanąć przy korycie.

16

Piąteczek, idealne, doceniam

6
rejash napisał(a):.

Brak kontaktu z ludźmi, nudna monotonna praca, czytanie kodu, pisanie, testowanie. Siedzę wpatrzony w monitor po 8 godzin dzienne.

A czego wy się spodziewaliście? Pościgów jak w GTA? XD

3

Przypomniało mi się jak kiedyś zagraniczny klient nas pochwalił jak fajnie się z nami pracuje. Co prawda u Hindusów miałby to taniej, ale musiałby im napisać szczegółową specyfikację, żeby zrobili jak trzeba.

8

Byłem w zespole, gdzie jeden kolega narzekał, że ma zadania permanentie niedodefiniowane, bo chciałby oprócz wymagań mieć też projekt od architekta (co i w jakiej klasie dodać, jakie stworzyć).
W tym samym projekcie narzekałem, że analitycy tracą czas na wrzucanie niepotrzebnych szczegółów implementacyjnych do zadań (głównie związanych z security), bo i tak zwykle się te rzeczy zmieniały w trakcie wykonywania zadania. A jakby mi architekt pisał co i w jakiej klasie mam wkleić to zacząłbym palić.

1
szatkus1 napisał(a):
Miang napisał(a):

bo ludzie nie potrafią pisać, normalnie pisać po polsku
jeżeli firma jest ą i ę i próbują wszystko pisać po angielsku to już w ogóle maskara

A skąd Amerykanin czy Szwed ma znać polski?

tylko że tak się też wydurniają w polskich firmach gdzie pracują sami Polacy + ewentualnie ludzie ze Wschodu co lepiej rozumieją polski niż angielski

11

Trochę historii.

W dawnych latach królował Waterfall w którym każde wymaganie było rozpisane szczegółowo przez analityków, często ubarwione UML-em w postaci diagramu klas i sekwencji, który programista musiał w zasadzie przepisać na używany język programowania bez zastanawiania się czy to co wypluł analityk czasem architekt ma sens z biznesowego punktu widzenia czy nie. Jest szczegółowa specyfikacja każdego wymagania to piszemy. Potem testerzy skrupulatnie testują i w zależności od wyniku implementacja ląduje na produkcji albo wraca do analityka lub programisty w celu poprawy wykrytych błędów. Ten cykl może trwać tygodniami zanim użytkownik dostanie kawałek działającego software'u.

Po latach takiego pisania kodu okazało się że Waterfall nie nadaje się do tworzenia aplikacji w nowoczesnym dynamicznym środowisku biznesowym, gdzie pomysł czy strategia biznesowa może się zmienić w ciągu kilku godzin i musimy (jako programiści) być gotowi taką zmianę wprowadzić niemalże z marszu. Nie ma czasu na to by analityk siedział cały dzień gadając z biznesem. Potem siedział kolejne dwa dni przekładając to co się dowiedział na UML i tabelę przypadków użycia z rozpisanym każdym edge case'em a potem jeszcze trzeba czekać aż programista to zaimplementuje a testerzy przetestują i napiszą obszerny raport z testów dając tym samym zielone światło do wdrożenia na produkcję, co z kolei wymaga dogłebnego planowania i analizy bo okazuje się że nasza zmiana jest niekompatybilną z inną aplikacją która pobiera od nas dane i trzeba czekać na zespół od tej aplikacji, aż się dostosują i zsynchronizować wdrożenie.

W rezultacie powstały techniki zwinne wytwarzania oprogramowania jak Rational Unified Process, Extreme Programming, Scrum, które miały za zadanie skrócić czas od pomysłu do dostarczenia działającej aplikacji użytkownikom z pominięciem tego czasochłonnego procesu analizy, dokumentacji i testowania, przerzucając część obowiązków z analityków czy architektów na programistów.

Niestety jak się trafi do dynamicznego projektu (często to można zaobserwować w startupach), gdzie liczy się time to market czyli dostarczyć rozwiązanie nad rynek przed tym jak zrobi to konkurencja to niestety ale nie ma możliwości by tracić dziesiątki roboczogodzin na analizy i trzeba iść na żywioł i eksperymentować.

Specyfika pracy wynika w dużej mierze z dynamiczności rynku. Albo dostarczasz szybko i wygrywasz, albo dostarczasz wolno i jesteś w tyle za konkurencją.

1

Macie coś takiego jak pielęgnacje backlogu? :D Czy zespół analizuje zadania do podjęcia? Pielęgnacja, chociaż nudna, to dobry moment żeby zadawać pytania i zbierać szczegóły, nawet jeśli część zespołu ma to gdzieś, Tobie może coś się przyda :) Czy raczej ktoś wrzuca zadania w czasie sprintu na pałę - "masz mało to weź jeszcze trochę"?

Mi też się kiedyś trafiały zadania mające tylko tytuł. Ludzie się do tego przyzwyczajają, żyją w bałaganie i nie wiedzą, że może być inaczej. Niestety dobrego wyjścia nie ma, jeżeli będziesz chciał coś ulepszać, zostaniesz zaraz kierownikiem całego "ulepszania". Możesz też szukać innej pracy, ale nikt nie da Ci gwarancji, że będzie lepiej :)

0
markone_dev napisał(a):

ja podejrzewam że chodzi o to żeby nie dawać projektu do ręki w czasach kiedy klepacz jest outsourcingiem

1

"trzeba się wyluzować" (c)

0
markone_dev napisał(a):

Trochę historii.

W dawnych latach królował Waterfall w którym każde wymaganie było rozpisane szczegółowo przez analityków, często ubarwione UML-em w postaci diagramu klas i sekwencji, który programista musiał w zasadzie przepisać na używany język programowania bez zastanawiania się czy to co wypluł analityk czasem architekt ma sens z biznesowego punktu widzenia czy nie. Jest szczegółowa specyfikacja każdego wymagania to piszemy. Potem testerzy skrupulatnie testują i w zależności od wyniku implementacja ląduje na produkcji albo wraca do analityka lub programisty w celu poprawy wykrytych błędów. Ten cykl może trwać tygodniami zanim użytkownik dostanie kawałek działającego software'u.

O jak dawnych czasach piszesz?

1
Miang napisał(a):
markone_dev napisał(a):

ja podejrzewam że chodzi o to żeby nie dawać projektu do ręki w czasach kiedy klepacz jest outsourcingiem

A to zależy. Pracowałem z ludźmi z outsourcingu i było ok. Nie wiem skąd to przeświadczenie że nie da się nawiązać dobrych relacji z kontraktorami. Miałem przypadki ludzi zatrudnionych bezpośrednio którzy mieli wywalone jajca na projekt, za to kontraktorzy się angażowali.

Za bardzo generalizujesz moim zdaniem.

0

chodzi mi o to ze tzw. zachód traktuje nas jak trzecie świat, już się przejechali na tym że za dużo zdradzili Chińczykom zlecając im produkcje

0
jarekr000000 napisał(a):
markone_dev napisał(a):

Trochę historii.

W dawnych latach królował Waterfall w którym każde wymaganie było rozpisane szczegółowo przez analityków, często ubarwione UML-em w postaci diagramu klas i sekwencji, który programista musiał w zasadzie przepisać na używany język programowania bez zastanawiania się czy to co wypluł analityk czasem architekt ma sens z biznesowego punktu widzenia czy nie. Jest szczegółowa specyfikacja każdego wymagania to piszemy. Potem testerzy skrupulatnie testują i w zależności od wyniku implementacja ląduje na produkcji albo wraca do analityka lub programisty w celu poprawy wykrytych błędów. Ten cykl może trwać tygodniami zanim użytkownik dostanie kawałek działającego software'u.

O jak dawnych czasach piszesz?

Wiem do czego zmierzasz. Tak, wciąż się tak wytwarza soft. Tak, pracuje w takim projekcie -> farmacja, gxp, każda zmiana (change request) musi być przeanalizowana (risk assesment) udokumentowana (IRS, IDS), przetestowana, zwalidowana, do każdej zmiany powstaje obszerny raport, po wdrożeniu przychodzi audytor z zewnętrznej firmy i robi audyt, itd

1
markone_dev napisał(a):

Wiem do czego zmierzasz. Tak, wciąż się tak wytwarza soft. Tak, pracuje w takim projekcie -> farmacja, gxp, każda zmiana (change request) musi być przeanalizowana (risk assesment) udokumentowana (IRS, IDS), przetestowana, zwalidowana, do każdej zmiany powstaje obszerny raport, po wdrożeniu przychodzi audytor z zewnętrznej firmy i robi audyt, itd

To nieźle, bo nawet w latach 90tych robiliśmy te UMLe, ale na ogół na pół godziny przez kodowaniem :-) (gwoli ścisłości to pierwszy niejanuszex u mnie to dopiero 2002 - więc wcześniejsze czasym, w bardziej poważnych firmach, to raczej znam z opowieści znajomych po fachu)
A jak już byłem (na chwile zwykle) w poważniejszym projekcie, gdzie był w teorii ciężki proces - to okazywało się, że cały proces nie dotyczy bugfixów - więc wszystko co się spieszyło było bugfixem.

0
Miang napisał(a):

chodzi mi o to ze tzw. zachód traktuje nas jak trzecie świat, już się przejechali na tym że za dużo zdradzili Chińczykom zlecając im produkcje

Ja tego nie odczuwam mimo że jestem takim zasobem. Niby zatrudnionym bezpośrednio ale jednak zasób z tzw CoE (Center of Excelence) przypisany do konkretnego projektu. Może dlatego że korpo i wszyscy mają obsesję na punkcie by nie generalizowac i kogoś nie urazić, równe traktowanie, itd

0
jarekr000000 napisał(a):
markone_dev napisał(a):

Wiem do czego zmierzasz. Tak, wciąż się tak wytwarza soft. Tak, pracuje w takim projekcie -> farmacja, gxp, każda zmiana (change request) musi być przeanalizowana (risk assesment) udokumentowana (IRS, IDS), przetestowana, zwalidowana, do każdej zmiany powstaje obszerny raport, po wdrożeniu przychodzi audytor z zewnętrznej firmy i robi audyt, itd

To nieźle, bo nawet w latach 90tych robiliśmy te UMLe, ale na ogół na pół godziny przez kodowaniem :-)
A jak już byłem (na chwile zwykle) w poważniejszym projekcie, gdzie był w teorii ciężki proces - to okazywało się, że cały proces nie dotyczy bugfixów - więc wszystko co się spieszyło było bugfixem.

My UML-a nie używamy za to cenie sobie C4 Model od Simona Browna. Pozwala fajnie przejść od ogółu do szczegółu (ofc bez 4 warstwy czyli diagramu klas) I co raz więcej kolegów udaje mi się przekonać do używania go. Ale jak to w takich firmach nie może być prosto i ostatnio kupili licencję dla wszystkich na narzędzie Enterprise Architect od Sparx, mimo że to samo można zrobić w draw.io.

Swoją drogą praca w środowisku mocno regulowanym jakim jest farmacja (HIPPA, GxP) a w szczególności badania kliniczne i wszystko co się z tym wiąże próbując bym jednocześnie Agile w dużym korpo jest ciekawym doświadczeniem.

2
markone_dev napisał(a):

My UML-a nie używamy za to cenie sobie C4 Model od Simona Browna. Pozwala fajnie przejść od ogółu do szczegółu (ofc bez 4 warstwy czyli diagramu klas) I co raz więcej kolegów udaje mi się przekonać do używania go. Ale jak to w takich firmach nie może być prosto i ostatnio kupili licencję dla wszystkich na narzędzie Enterprise Architect od Sparx, mimo że to samo można zrobić w draw.io.

Ło panie, nawet miałem tego Enterprise Architecta w jakichs firmach (ale już wyparłem z pamięci)

Swoją drogą praca w środowisku mocno regulowanym jakim jest farmacja (HIPPA, GxP) a w szczególności badania kliniczne i wszystko co się z tym wiąże próbując bym jednocześnie Agile w dużym korpo jest ciekawym doświadczeniem.

Więc raczej masz typowy pato agile, nic to z Waterfallem nie ma wspólnego, anie też z Agile - raczej model spiralny, który tym się różni od Agile, że w Agile wytwarza się ficzery w cyklach od 7 do 30 dni, a w modelu spiralnym od tygodnia do miesiąca. Plus oczywiście lokalne patologie (stany d**y i inne ceremonie).

0
jarekr000000 napisał(a):
markone_dev napisał(a):

Swoją drogą praca w środowisku mocno regulowanym jakim jest farmacja (HIPPA, GxP) a w szczególności badania kliniczne i wszystko co się z tym wiąże próbując bym jednocześnie Agile w dużym korpo jest ciekawym doświadczeniem.

Więc raczej masz typowy pato agile, nic to z Waterfallem nie ma wspólnego, anie też z Agile - raczej model spiralny, który tym się różni od Agile, że w Agile wytwarza się ficzery w cyklach od 7 do 30 dni, a w modelu spiralnym od tygodnia do miesiąca. Plus oczywiście lokalne patologie.

Właśnie nie. Przynajmniej nie w taki sposób jak sobie wiele osób to wyobraża. W fazie developmentu jesteśmy mocno zwinni. Przykładowo zaprojektowaliśmy ficzer w sposób A po czym okazuje się że musimy to zrobić w sposób B więc następuje szybką reorganizacja backloga i zmiana zostaję zaprojektowana i zaimplementowana na środowisku dev i ten ficzer sobie czeka na wdrożenie w odpowiednim czasie. Tutaj jest brak zwinnosci -> czekamy na koniukcje planet by wdrożyć nowe ficzery. Ofc żartuje bo to standardowa praktyka. Wiadomo są firmy gdzie nowe ficzery ładują od razu na produkcji ale większość firm (w tym oferujących SaaS) ma swój release cycle. Nie inaczej jest w przypadku rozwiązań regulowanych.

W przypadku hotfixow jest inaczej. Procedury pozwalaja wdrożyć poprawkę w ciągu kilkunastu minut/godzin od zgłoszenia krytycznego błędu, ale potem trzeba zadbać o uzupełnienie dokumentacji i przeprowadzenie RCA (Root Cause Analysis).

3

IMO pracujesz w toksycznej firmie i masz dużo racji, chociaż też nie do końca realistyczne podejście.

mam roszczeniowe podejście. Jakbym mówił do nich chińskm językiem. Czy ja jestem roszczeniowy?

Myślę, że tak, mimo że masz rację. Tj. twoja roszczeniowość polega na tym, że próbujesz zmienić beton, zamiast zaakceptować to, że pracujesz z idiotami (ew. zmienić pracę, ale w innej pracy może nie być wcale lepiej).

"tak powinno być, nikt ci młody nie będzie podsuwał pod nos informacji, zapytaj tamtego, on ci wyjaśni". "Za mało czasu jest, żeby robić opisy zadań..., musisz się pytać, zapytaj kogoś, niech ci wytłumaczy".

Klasyka. Czyli pierwszy odsyła cię do drugiego, a drugi nic nie wie, nie pamięta, jest seniorem.

"Dlaczego się nie pytałeś?, mogłeś się zapytać."

To akurat cenna rada.

Jest takie zrzucanie winy na mnie,

Nie winy, tylko odpowiedzialności. Pracujesz z mało odpowiedzialnymi ludźmi, więc przynajmniej ty powinieneś być odpowiedzialny.
Najlepiej o wszystko dopytywać. Nic nie traktować za pewnik. Bo kretyni nie potrafią nic jasno napisać i za nic nie czują się odpowiedzialni.

Inny przykład: prawię kończę zadanie, dowiaduje się, że "ano bo ja miałem spotkanie z biznesem i teraz zmienili i chcą inaczej". Nie poinformowali wcześniej, a ja jak głupi męczyłem się nad czymś kilka godzin i kod jest do usnięcia

Kod do usunięcia, ale czegoś się nauczyłeś pisząc. Poza tym zapłacą ci, więc stratny nie będziesz.

Ja jako programista

Twoim błędem jest, że identyfikujesz się jako programista. Pracując w zespole musisz być jednocześnie kimś w rodzaju analityka biznesowego czy menedżera (nie musisz mieć władzy nad nikim, ale masz zadanie do zrobienia i zarządzasz jego zrobieniem przez samego siebie, jednak z pomocą innych ludzi).

Powiedzmy, że ktoś ci nie chce udzielić informacji albo udziela błędnej. Jak źle zrobisz, to ty ponosisz odpowiedzialność, więc potrzebujesz bardziej naciskać na to, żeby udzielono ci potrzebnych informacji.

natomiast zazwyczaj robią to ludzie którzy gadają z biznesem i mają nikłe pojęcie o programowaniu, a ja muszę sobie i tak później wszystko tłumaczyć na język technologii

A tutaj ładnie jest pokazane, jak dałeś się wyrzucić poza obieg informacji. Jeśli gadanie z biznesem jest takie ważne, to albo też powinieneś to robić, albo mocniej współpracować z osobami, które to robią w twoim imieniu.

Możesz też zainteresować się całym kontekstem tego, co jest robione (całą wizją produktu, a nie tylko taskiem numer #2137), bo myśląc tylko w kategoriach swoich tasków, ciężko złapać kontekst i sens tego, co się robi i to jak to, co robisz, wiąże się z całościowym celem. I że może rzecz X, która tobie wydawała się ważna, okazuje się mało ważna, a tego nie wiedziałeś, bo w tasku tego nie opisali. Za to opisali gdzie indziej.

1
rejash napisał(a):

Inny przykład: prawię kończę zadanie, dowiaduje się, że "ano bo ja miałem spotkanie z biznesem i teraz zmienili i chcą inaczej". Nie poinformowali wcześniej, a ja jak głupi męczyłem się nad czymś kilka godzin i kod jest do usnięcia. Ja jako programista nie mam takiej siły przebicia, żeby zrozumieli, że to co dotychczs zrobiłem, jest w jakimś stopniu w porządku i co jakby przekonać klienta, że mamy napisane trochę w innej formie i może przy niej pozostaniemy, ale nie, nie i już, takie są ustalenia i nie ma dyskusji.

Przecież nie będziesz robił tego od nowa w ramach darmowych nadgodzin. Mówisz, że skoro tak to obecna implementacja musi zostać wykonana od nowa i zajmie to kolejny dzień pracy. Niestety przekonywanie managera, żeby pisał do klienta "mamy to troche w innej formie, zostawmy tak" nie przejdzie, bo sam manager będzie bał się o swoją dupe, że nie wykonuje właściwie swojej roboty.

3

Najlepszy fragment:

rejash napisał(a):

to co dotychczs zrobiłem, jest w jakimś stopniu w porządku i co jakby przekonać klienta, że mamy napisane trochę w innej formie i może przy niej pozostaniemy

  • Dzień Dobry, poproszę 20 deka wołowiny
  • Oj, ukroiło mi się 4 kg. Może być, prawda?
0

jak cena ta sama a mam dostać więcej...

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