Jak poradzić sobie w nowej pracy, gdy wszyscy mnie ignorują?

6

Trzy tygodnie temu zacząłem pracę w małej firmie w Warszawie jako młodszy programista. Zostałem przydzielony do pewnego projektu, nad którym pracują od dawna cztery osoby. Mój problem jest taki, że czuję się nieprzydatny w zespole. Nikt nawet nie próbował wytłumaczyć mi działania aplikacji, ani nawet ani razu nie usłyszałem słów "gdy będziesz czegoś potrzebował, to pytaj", a gdy próbowałem pytać o różne sprawy i o jakieś zadania dla mnie, to usłyszałem, że jest za dużo roboty i nikt na razie nie ma czasu na zajęcie się mną. Poświęcam dużo czasu na poznanie projektu (nawet w domu) i nie mam problemu z brakiem wiedzy na temat używanych technologii, bo projekt idealnie się wpasował w moje zainteresowania i umiejętności. W poprzedniej firmie zajmowałem się wieloma sprawami sam i wszystkim to pasowało, bo wiedzieli, że pewne sprawy będą zrobione w poprawny sposób i nie będę angażował do tego zbyt wielu osób. A w tej firmie jest całkiem inaczej.

Co najlepiej zrobić w takiej sytuacji? Bardzo nie lubię się narzucać i jeśli ktoś nie ma dla mnie czasu, to mu nie przeszkadzam, a z drugiej strony nie chciałbym się mieszać i robić zmian samodzielnie, bo nie znam ich planów, preferencji itp. Wszyscy są dla mnie mili, na przerwach rozmawiamy normalnie, nie czuję jakiejś niechęci do mnie z ich strony. Przeszkadza mi to, że ktoś może mnie uznać za niepotrzebnego nieroba i po umowie próbnej nie będą mnie już chcieli. Pociesza mnie tylko to, że w każdej sytuacji w życiu wydaje mi się, że jest dużo gorzej, niż jest w rzeczywistości, a potem się okazuje, że jednak jest całkiem ok i przesadzałem z negatywnym myśleniem na mój temat.

Mógłby ktoś doradzić, jak poradzić sobie w tej sytuacji? Nie wiem, czy to jest normalne, bo nie mam dużego doświadczenia w firmach programistycznych, wcześniej pracowałem w korporacji i system pracy był inny.

12

No, wychodzi na to, że nowi koledzy z pracy nie mają doświadczenia w pracy w zespole...

Jak nie ruszysz swojego zadania, to pracodawca/klient płaci Ci za bezczynność. Pracodawca/zespół nie powinien do czegoś takiego dopuścić. Najlepiej przedstawić sprawę kolegom i jeśli wciąż będą olewać, to idź do szefa.

0

Zazwyczaj (imho) powinno być odwrotnie. W sprawach formalnych zespół powinien zapewniać pomoc, a już jeśli chodzi o luźne gadki/przerwę, to tutaj z czasem następuje "asymilacja". Skoro normalnie rozmawiają na przerwach i jest flow, to tym bardziej niezrozumiały wydaje się brak pomocy podczas pracy. Kierownik zespołu też nie widzi, co się dzieje i w żaden sposób nie reaguje?

1
Spine napisał(a):

No, wychodzi na to, że nowi koledzy z pracy nie mają doświadczenia w pracy w zespole...

Przecież napisał, że zaczął pracę w małej firmie. Pewnie to jeszcze jakiś web service.

0

Ja w ogóle nie zamierzam pracować w żadnej firmie stacjonarnej. Do emerytury będę robił zdalnie, a mam niecałe 2 lata expa w web apps.
Takie dylematy jak ignorowanie, to miekkie pierdoły i w ogóle nie nalezy sie przejmować. Robic swoje zadania, wywiązywac sie w terminach. Wszystko inne to sprawy bez znaczenia.

7

Byłam w takiej sytuacji. Wszyscy mili w przerwie na kawę, ale nikogo nie obchodziło, żeby realnie zaangażować mnie w projekt, a był on mocno zagmatwany. Starałam się rozmawiać z przełożonym. To był błąd, powinnam po miesiącu zacząć szukać nowej pracy. Jeśli zespół nie chce żebyś się wdrożył w pracę, to nic z tym nie zrobisz. W IT jest dużo ludzi, którzy niechętnie współpracują z innymi, najczęściej gdy trzeba komuś na początku trochę pomóc. Szczególnie, że nowa i mało doświadczona osoba głównie coś psuje i przeszkadza. Jak nie ma w firmie dobrego zarządzania, atmosfery współpracy i dzielenia się wiedza to właśnie tak to wygląda.

Edit: ja dostawałam na odczepnego"niby task", na 4 godziny roboty i to niby było moje zadanie na dwutygodniowy sprint.

29

jest za dużo roboty i nikt na razie nie ma czasu na zajęcie się mną

To jest jak w tym kawale że gość po budowie biega z pustą taczką, zatrzymuje go kierownik i pyta "czemu biegasz z pustą taczką?" a on odpowiada "taki zapierdol że nie ma kiedy naładować!". :D

Moja rada: szukaj normalnej roboty. Bo taka sytuacja normalna nie jest.

2

Mój problem jest taki, że czuję się nieprzydatny w zespole. Nikt nawet nie próbował
wytłumaczyć mi działania aplikacji, ani nawet ani razu nie usłyszałem słów
"gdy będziesz czegoś potrzebował, to pytaj", a gdy próbowałem pytać o różne sprawy
i o jakieś zadania dla mnie, to usłyszałem, że jest za dużo roboty i nikt na razie nie ma czasu na zajęcie się mną.

No to "rób wolno dla szkopa" ;) Nie śpiesz się, jeśli i tak nie masz wiele do zrobienia, rób swoje jakieś tam taski (ale nie w domu, bo to głupota), i czekaj aż sami dojdą do wniosku, że trzeba się tobą zająć (albo jak uznają, że zatrudnili cię niepotrzebnie i cię zwolnią). No i możesz zawsze oglądać zdjęcia śmiesznych kotów, albo pouczyć się jakichś tutoriali o programowaniu w czasie pracy.

Przeszkadza mi to, że ktoś może mnie uznać za niepotrzebnego nieroba i po umowie próbnej nie będą mnie już chcieli.

Co ma piernik do wiatraka? ;) Możliwe, że ci nie przedłużą umowy, ale to nie dlatego, że jesteś nierobem, tylko dlatego, że niepotrzebnie w ogóle cię zatrudniali - skoro firma dobrze sobie radzi bez ciebie, to ten, kto cię zatrudniał popełnił błąd, że w ogóle zatrudnilł dodatkowego programistę do projektu, który sobie doskonale radzi z tą liczbą programistów, która już jest i ten nowy programista to tylko piąte koło u wozu.

Ale możliwe, że masz zespół-patologię, wtedy lepiej nie czekać tylko samemu się zwolnić (bo jeśli zespół jest patologiczny, to jeszcze potem będą pretensje do ciebie mieć wielkie, że nic nie robisz, nawet jeśli nie wiadomo co jest do zrobienia i jak).

2

Lider powinien zadbać o wdrożenie nowego pracowinka lub osoba wskazana przez niego.

10

nie wiem czy to normalne (pewnie nie) ale w wiekszosci projektow bylam zdana glownie na siebie i nauczylam sie to lubic :)
pare rad:

  • czytaj kod zrodlowy i dostepne (zwykle strzepki) dokumentacji, szukaj referencji do tematu nad ktorym pracujesz, nie zakladaj niczego na 100% bo pewne rzeczy beda stare lub po prostu bledne ;)
  • poprawiajac buga staraj sie za wszelka cene zrozumiec dlaczego wystepuje i jak to sie stalo ze zostal przeoczony zamiast zaklepac byle co zeby dzialalo
  • zaprzyjaznij sie z debuggerem, zidentyfikuj glowne procesy i ich cykl zycia
  • pisz testy (ale takie ratujace dupe, nie dla statystyk), nawet jesli reszta teamu to olewa
  • upraszczaj i usuwaj kod
  • gdy masz za duzo czasu to przypomnij sobie ze kazdy kawalek kodu da sie napisac lepiej, jesli sie nie da - powieksz kawalek (t.j. ogarnij jego otoczenie itp)
  • kazdy wiekszy projekt ma pierdyliard problemow niefunkcjonalnych, wkurzajacych niedorobek w funkcjonalnosci czy manualnych procesow czekajacych na automatyzacje - tu mozesz blysnac
  • przeznacz czesc czasu na szukanie lepszych alternatyw i je stopniowo wdrazaj
  • jesli mimo wszystko nie umiesz tak zyc ;) to realizacja powyzszych punktow da ci solidne podstawy do zmiany pracy na lepsza
5

Ja bym zaczął ostentacyjnie sikać ludziom do herbaty, na pewno wtedy przestaną ignorować.

6

Kilka lat temu byłam w podobnej sytuacji. Trafiłam do zespołu mocno męskiego i starszego ode mnie.
Mam wrażenie, ze na początku cały team myślał, ze zostałam zatrudniona do poprawy statystyk (kobieta w dziele IT), lub jako ozdoba- generalnie nikt nie chciał mi pomoc się wdrożyć, jakby szkoda było na mnie czasu. Było to jeszcze bardziej irytujące, bo razem ze mna do zespołu dołączył inny facet, z którym przechodzili kod niemal linijka po linijce.
Nawet jeśli szef próbował interweniować, żeby najbardziej zawalony robota kolega dał mi jakiś task, ten oburzony wychodził z pokoju bo przecież on jest tak zarobiony, ze nie ma czasu na takie pi*rdoly.
W końcu jakiś task dostałam, całkiem poważny, który sama rozwiązałam, rozgrywając przy okazji jak wszystko działa. Koledzy zobaczyli, ze jednak ogarniam i sytuacja się zmieniła.
Ale ogólnie- takie podejście znaczy, ze zespół jest ch*jowy.

0

Hej,

jeśli macie team leada to może poproś o rozmowę f2f i powiedz o swoich obawach i obserwacji. Z mojego doświadczenia wiem, że bardzo często to brak doświadczenia i umiejętności we wdrażaniu mniej doświadczonych osób. Najgorsze to możesz zrobić to zostawić tą sprawę "samej sobie" i czekać co się wydarzy. :)
Komunikuj, że co coś Ci nie odpowiada skoro atmosfera w firmie i kontakty z innymi są ok.
Kiedyś znajomy, który bł w takiej sytuacji podczas kuchenny pogaduszek z częścią zespołu pół żartem wtrącił, kiedy w końcu dostanie robotę ;) Pomogło, potem na spotkaniu z TL wrócił do tematu, że to pytanie na serio ;)

0

Jestem w podobnej sytuacji. Od września zacząłem nową pracę i jak dotychczas dostałem dwa banalne zadania. Oczywiście jak sam o nie poprosiłem kilkukrotnie. I jeszcze wielkie zdziwienie, że nie notuje. W mojej poprzedniej było łatwiej. Na początku dostawałeś mentora i on Cię wprowadzał, ewentualnie poprawiał to co zjeb***. Każdy był mocno zainteresowany aby przerzucić na nowego najbardziej żmudne i nudne zadania aby mieć więcej czasu na fejsa.

0

U mnie jest problem całkowitego ignorowania, patrzenie z góry, pracuje ze starszymi ode mnie osobami które w tym miejscu pracują już od lat. Gdy przyszedłem tam bardziej czułem jakbym był zagrożeniem niż kimś do pomocy, jeśli chodzi o kontakt słowny kończy się unikaniem i ignorowaniem, jak to skomentujecie mieliście coś podobnego?

0
archer89 napisał(a):

U mnie jest problem całkowitego ignorowania, patrzenie z góry, pracuje ze starszymi ode mnie osobami które w tym miejscu pracują już od lat. Gdy przyszedłem tam bardziej czułem jakbym był zagrożeniem niż kimś do pomocy, jeśli chodzi o kontakt słowny kończy się unikaniem i ignorowaniem, jak to skomentujecie mieliście coś podobnego?

Ja tak miałem. Po kilku latach stałem się samodzielny i nie potrzebowałem pomocy.
Ale atmosfera pracy niezależnie od tego czy jesteś juniorem czy team leadem jest ważna.
Nie myśl tylko że moc miłości do bliźniego coś zmieni. Betonu nie przebijesz dobrym słowem.

0

Nie myśl tylko że moc miłości do bliźniego coś zmieni. Betonu nie przebijesz dobrym słowem.

Co przez to rozumiesz?

0

Osoby, z którymi pracuję, okazały się być w porządku. Nadal nie chcą udzielać rad, robić code review, interesować się moim kodem, ale dostaję coraz bardziej ambitne zadania z różnych dziedzin i zdobywam doświadczenie, a poza tym zaczynam mieć swoje własne specjalności, z którymi związane zadania domyślnie trafiają do mnie (może dlatego, że nikt inny nie chce tego robić albo są zbyt ryzykowne, ale ja dobrze sobie z nimi radzę). Jeśli nic niespodziewanego się nie wydarzy, to mam zamiar zostać w tej pracy przez kolejne kilka lat, bo nie zajmuję się tylko "klepaniem formatek", tak jak niektórzy opisujący na forum swoją pracę. Myślę, że doświadczenie zdobyte w tej pracy razem z nauką w domu da mi duże możliwości znalezienia fajnej pracy w przyszłości.

Dziękuję za rady, część z nich była pomocna.

0

Julian_, pewnie masz rację, ale ja pracę traktuję poważnię i gdyby sytuacja w obecnej pracy nie zmieniła się po kilku miesiącach, to zacząłbym szukać nowej. Praca mi pasuje, zarobki się zwiększyły, a poza tym nie chcę być skoczkiem. Prawdę mówiąc boję się też, że trafię na coś gorszego i będę żałował, jak to się już zdarzyło w przeszłości. Wolę szukać, gdy będę pewny, że jestem na to gotowy, i że jest mała szansa na to, że coś się nie uda.

0

Miałem bardzo podobną sytuację w 2 firmach.

W pierwszej najpierw jeden typ coś tam niezdarnie może i próbował mnie wprowadzić w temat, ale nijak mu nie szło (koleś był studentem, najmłodszym w zespole).
Najstarszy koleś w zespole miał na temat głęboko wyjechane.
Ogólnie atmosfera w pokoju była tragiczna i de facto nikt ze sobą prawie nie rozmawiał...

Zmieniłem zespół - było już nieco lepiej, ale ogólnie okazało się że dziwna atmosfera jest specyfiką owego projektu.
Z perspektywy czasu powiem, że chyba najmądrzej w takich sytuacjach jest zmienić zespół albo dalej rozsyłać CV, jeśli nie zależy Ci na tym, by mieć w CV wpis, że po 3 miesiącach nastąpiło rozstanie.
Najważniejsze to próbować zrobić coś względnie szybko, bo jak utkniesz w takiej sytuacji to może być psychicznie do d**y.
Jest to sytuacja mega demotywująca po prostu...

1

I właśnie żeby przeciwdziałać takim problemom wymyślono daily stand-up i retrospektywę. A potem setki pytań na forum: "po co to w ogóle jest?"

2

I właśnie żeby przeciwdziałać takim problemom wymyślono daily stand-up i retrospektywę.

niby tak, ale nie jestem przekonany, czy koleś z nastawieniem widocznym poniżej będzie miał na tyle "odwagi", żeby taki (jednak - trochę niewygodny i rodzący niemiłe sytuacje) problem poruszyć na forum. Skoro w jego ocenie pytanie/domaganie się zainteresowania oraz przydzielenie jakichś sensownych zadań jest narzucaniem się, to poruszenie tego na większym forum pewnie w ogóle będzie niedopuszczalnym donosicielstwem.

Bardzo nie lubię się narzucać i jeśli ktoś nie ma dla mnie czasu, to mu nie przeszkadzam

0

Jak masz marnego przełożonego / managera i ogólnie projekt jest słabo zarządzany, to nawet poruszenie tematu może nie dać żadnego sensownego efektu.
Stand-upy i retrospektywy nie zawsze są tu remedium, bo zależy jak w danej firmie są realizowane - czy odpowiada np. jeden przedstawiciel zespołu, czy ktoś w ogóle próbuje coś zmienić z "miękkimi" problemami po retrospektywie, jak często są retrospektywy etc...

Ja osobiście po 2 tygodniach pracy stwierdziłem że jest syf i mój manager dostał kawę na ławę... I co? I NIC się nie zmieniło przez parę miesięcy poza zwiększoną dawką bullshitu.

Wprowadzenie pracownika to nie jest łatwy temat, a jak zespół ma to w dupie, to świadczy to o zespole.
Start często rzutuje na dalszą perspektywę w pracy / nastawienie / motywację / efekty.

Problem uważam wynika również często z tego, że często na przełożonych awansowane są osoby, którym brak umiejętności miękkich i ich wiedza o zarządzaniu zespołem / rozwijaniu współpracy między ludźmi jest książkowa, albo co jeszcze częstsze zerowa.
Taki manager traktuje podwładnych jak dobrodziejstwo inwentarza, które dostał komplecie ze stanowiskiem i najlepiej jakby temat się sam ogarniał, bo on ma ważniejsze sprawy.

0
cerrato napisał(a):

niby tak, ale nie jestem przekonany, czy koleś z nastawieniem widocznym poniżej będzie miał na tyle "odwagi", żeby taki (jednak - trochę niewygodny i rodzący niemiłe sytuacje) problem poruszyć na forum. Skoro w jego ocenie pytanie/domaganie się zainteresowania oraz przydzielenie jakichś sensownych zadań jest narzucaniem się, to poruszenie tego na większym forum pewnie w ogóle będzie niedopuszczalnym donosicielstwem.

Żeby mówić o donosicielstwie to trzeba donosić komuś. A retro i stand-upy to przecież załatwianie spraw we własnym gronie. Zwłaszcza retrospektywy, z których to Product Ownerzy i kierownicy bywaja wypraszani, gdy się przez przypadek zapędzą, więc jest to właśnie zaprzeczenie donosicielstwa.

Trzeźwy Lew napisał(a):

Jak masz marnego przełożonego / managera i ogólnie projekt jest słabo zarządzany, to nawet poruszenie tematu może nie dać żadnego sensownego efektu.
Stand-upy i retrospektywy nie zawsze są tu remedium, bo zależy jak w danej firmie są realizowane - czy odpowiada np. jeden przedstawiciel zespołu, czy ktoś w ogóle próbuje coś zmienić z "miękkimi" problemami po retrospektywie, jak często są retrospektywy etc...

Zgadza się. Dlatego jest hierarchia załatwiania takich problemów.
Etap 1. Załatwianie wewnętrzne. Poruszasz temat na stand-upach i retro, czyli w obrębie zespołu.
Etap 2. Agile w firmie nie działa, retro nie ma, albo etap 1 jest nieskuteczny, wtedy idzie się do kierownika, ale nie donosić, tylko z prośbą: "daj mi jakiegoś mentora, bo czuję, że mógłbym robić więcej". Przy okazji można zasugerować wprowadzenie lepszych praktyk Agilowych.
Etap 3. Prośba kierownika o przydzielenie innych zadań. Czyli dyplomatyczna forma rozstania się z zespołem, z którym najwyraźniej nam się dobrze nie pracuje.
Etap 3.1. Jeśli ani kierownikowi ani zespołowi nie zależy, można jeszcze pogadać z przełożonym kierownika albo HRem.
Etap 4. Zmiana pracy.

0
GutekSan napisał(a):

I właśnie żeby przeciwdziałać takim problemom wymyślono daily stand-up i retrospektywę. A potem setki pytań na forum: "po co to w ogóle jest?"

No tak, bo standupy, retro i cały ten cyrk ze wszystkimi klownami na pewno sprawią, że patola zacznie zachowywać się normalnie i przestać ignorować ludzi w zespole. :)

2

Retro to trochę jak godzina wychowawcza w podstawówce/gimnazjum i myślenie, że jak się pogada o czymś przez 45 minut to patola zacznie zachowywać się normalnie.

A retro i stand-upy to przecież załatwianie spraw we własnym gronie.
Zwłaszcza retrospektywy, z których to Product Ownerzy i kierownicy bywaja wypraszani,
gdy się przez przypadek zapędzą, więc jest to właśnie zaprzeczenie donosicielstwa.

No tak, ale żeby to miało jakikolwiek sens w likwidowaniu patoli to zespół powinien mieć władzę odwoływania Product Ownera albo wyrzucania członków zespołu (ew. członek zespołu mógłby opuścić zespół i przenieść się do innego, o ile by drugi zespół go przegłosował za przyjęciem). Bo inaczej co z tego, że zespół sobie pogada, jeśli dalej będzie to, co będzie?

Czyli z jednej strony mamy jakieś retrospekcje i standupy, mamy iluzję demokracji (tj. samodzielności zespołu, pewnej autonomii), a w rzeczywistości, tak jak @GutekSan napisał:

jest hierarchia załatwiania takich problemów.

I dalej wypunktowane do którego gościa należy pójść na dywanik, w którym momencie.

Czyli demokracja w IT (w tym choćby Scrum) jest po to, żeby mydlić oczy programistom, i w rezultacie tylko przedłużać patologię. Bo pewnych problemów nie załatwi się koleżeńską pogadanką, tylko decyzją kogoś na odpowiednim szczeblu, kto ma realną władzę w firmie. Programistom wmawia się, że jest demokracja, autonomia zespołów, a w rzeczywistości te zespoły nawet nie są w stanie się często zorganizować na tyle, żeby działać sprawnie bez interwencji z góry:

Trzeźwy Lew:
W pierwszej najpierw jeden typ coś tam niezdarnie może i próbował mnie wprowadzić w temat,
ale nijak mu nie szło (koleś był studentem, najmłodszym w zespole).
Najstarszy koleś w zespole miał na temat głęboko wyjechane.

0
LukeJL napisał(a):

No tak, ale żeby to miało jakikolwiek sens w likwidowaniu patoli to

Tak jak napisałem wcześniej. Nie mówimy tu o "patolach" tylko o nieporozumieniach, konfliktach itp, a na ich rozwiązywanie istnieją sposoby, tylko trzeba się ich nauczyć.

zespół powinien mieć władzę odwoływania Product Ownera albo wyrzucania członków zespołu (ew. członek zespołu mógłby opuścić zespół i przenieść się do innego, o ile by drugi zespół go przegłosował za przyjęciem). Bo inaczej co z tego, że zespół sobie pogada, jeśli dalej będzie to, co będzie?

Znowu przeceniasz rolę programistów, jakby to oni byli pępkiem świata i powinni mieć decydujący wpływ na organizację pracy co jest bzdurą. Z jakiej racji zespół ma odwoływać PO? Bo się nie dogadują? A może to zespół trzeba odwołać? Poza tym odwoływanie ludzi to jest środek ostateczny, a retro ma prowadzić do rozwiązywania problemów wewnątrz zespołu bez potrzeby uciekania się do tego. Od odwoływania jest kierownik liniowy, ale to jest sąd wyższej instancji.

Czyli demokracja w IT (w tym choćby Scrum) jest po to, żeby mydlić oczy programistom, i w rezultacie tylko przedłużać patologię.

Nie. Demokracja jest po to by Cię wysłuchać. W większości przypadków konflikty nie wynikają ze złej woli tylko właśnie niewiedzy, a to jest metoda by tą niewiedzę zmniejszyć.

Bo pewnych problemów nie załatwi się koleżeńską pogadanką, tylko decyzją kogoś na odpowiednim szczeblu, kto ma realną władzę w firmie.

Oczywiście. Ale pewne problemy można tak załatwić. A te, których nie można, załatwia się przez kierownika.

Programistom wmawia się, że jest demokracja, autonomia zespołów, a w rzeczywistości te zespoły nawet nie są w stanie się często zorganizować na tyle, żeby działać sprawnie bez interwencji z góry:

No i od tego są m.in. Agile Coache (zwani przez was "klaunami"), żeby zespoły nauczyć samoorganizacji.

1

Zarzuć dropa bazy na produkcji. Polecam ten styl zwracania na siebie uwagi. Będziesz na ustach kolegów przez następne kilka lat, nawet jeśli już nie będziesz tam pracować.

2

Znowu przeceniasz rolę programistów, jakby to oni byli pępkiem świata i powinni mieć decydujący wpływ na organizację pracy co jest bzdurą.

Nie muszą, ale jest taki trend wmawiania programistom, że liczy się samoorganizujący się zespół, że scrum masterzy czuwają nad procesem, że jest wielki empowerment, że już zły wilk managementu/biznesu/polityk firmowych nie zaszkodzi programistom przy pracy, bo programiści mają swój proces, swoje sprinty, swoje retro....

...a potem i tak rozbija się wszystko o polityki firmowe i gry o władzę (nawet w zespole, na poziomie programista kontra inny programista), czy po prostu o czyjąś dobrą wolę (że komuś się "zachce" coś robić)

Nie mówię, że demokracja jest lepsza(ani gorsza), ale bardziej uczciwie (tj. bez hipokryzji) byłoby cut the bullshit i wprowadzić ścisłą hierarchię w firmach i ścisły podział obowiązków, tak żeby każdy wiedział co ma robić, a jeśli nie wiedział, co ma robić, to spytałby się przełożonego (albo niekoniecznie przełożonego, a po prostu osoby odpowiedzialnej za coś). W ten sposób nie byłoby sytuacji takich, jak ta:

W pierwszej najpierw jeden typ coś tam niezdarnie może i próbował mnie wprowadzić w temat, ale nijak mu nie szło
(koleś był studentem, najmłodszym w zespole). Najstarszy koleś w zespole miał na temat głęboko wyjechane.

Ktoś musiał przyjmować polecenia od juniora, bo senior miał "głęboko wyjechane".

Władza to też odpowiedzialność, a często się o tym zapomina.

Nie sądzę, żeby retro pomogłoby by w takiej sytuacji, ponieważ to kwestia całej organizacji pracy, która jest zwalona, plus kwestia słabej etyki pracy (czytaj: tumiwisizm).

0
somekind napisał(a):

No dla mnie jeśli ludzie ignorują innego człowieka w ich otoczeniu to jest to właśnie patologia. Normalni ludzie tak nie robią.

Oczywiście, że robią. I Ty to pewnie robisz, i ja czasem też. To wynika z różnic w ocenie tego, ile uwagi potrzeba poświęcić danej osobie. Tobie, dajmy na to, wydaje się, że wystarczy że podasz komuś adres strony na Confluence z opisanym procesem, linkami do narzędzi i ewentualnie przez pół godziny opowiesz mu o wewnętrznych praktykach to wystarczy. A ten ktoś potrzebuje by go przez miesiąc prowadzić za rączkę, i jeśli tego nie zrobisz to on będzie się czuł ignorowany. Albo ktoś ignoruje, bo nie dostrzega problemu, bo myśli, że skoro ktoś mu jasno nie nakazał, by nie ignorować, nie przydzielił mu roli mentora nowego członka zespołu, to może się spokojnie zajmować swoimi zadaniami. I dopiero gdy pewne problemy zostaną wyłożone na stół do ludzi zaczyna docierać. Ale to jeszcze nie jest patologia.

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