logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

I co mi zrobicie? Historia pewnego (zespołowego) projektu.

01 Lut 2019 23:00 4806 41
  • O autorze
    Konto nie istnieje
    Poziom 1  
    Konto nie istnieje napisał 0 postów. Jest z nami od 1978 roku.
  • #2 17748584
    pawelr98
    Poziom 39  
    Najprostszy przykład.
    Programowanie.

    Każdy zna chyba uczucie "zawirowania" kiedy zaczyna grzebać przy kodzie który napisał ktoś inny. Aż ma się chęć skasować i robić od zera.
    Każdy ma jakieś przyzwyczajenia albo "ulubione" rozwiązania. Konieczność współpracy powoduje tu kolizje.
    "Robienie po kimś" to moim zdaniem najgorsza rzecz w pracy zespołowej.

    Dlatego dużo wygodniej pracować jest na "wydzielonym" bloku gdzie nikt ci nie przeszkadza i możesz robić po swojemu.
    Wystarczy do tego zachować pewne wytyczne aby integracja całości przebiegła bez większego problemu(znów wracając do przykładu programowania można np. używać określonych typów danych w blokach funkcyjnych).

    Co innego komunikacja dotycząca postępów albo problemów.
    Tutaj wchodzi często "duma", niechęć do przyznania się do problemów.

    Obecnie jestem studentem 5 semestru (w sumie to już 6 bo 5 najprawdopodobniej skończony pomyślnie).
    Na dyskutowaniu o założeniach i rozwiązaniach można było stracić sporo czasu.

    Zazwyczaj w grupach laboratoryjnych wolałem szybko i skutecznie przeforsować swoje rozwiązania/założenia bo pozwalało od razu przejść do realizacji.

    Inny ciekawy przykład ze studiów to przygotowania do kolokwiów/egzaminów.
    Zadania z zeszłych lat, każdy robi które umie a całość jest umieszczona w jednym miejscu.
    W 1-2dni potrafi powstać istne Vademecum składające się z 40-50 zadań.
    Znów brak współpracy, jedynie pojawiają się ludzie którzy sprawdzają poprawność albo konfrontują ze swoimi rozwiązaniami.
  • #4 17748745
    gdL
    Poziom 27  
    Moim zdaniem problem częściowo rozwiązuje mądry kierownik projektu/moderator, który bierze na siebie decyzje projektowe - przy tym ucina niekończące się dyskusje o tym "dlaczego inaczej jest lepiej".
    Drugim elementem przy pracy w kodzie jest podział na moduły oraz oddanie odpowiedzialności w ręce konkretnych osób z dużym doświadczeniem.
    Trzecia część to bezpośrednie zaangażowanie osoby odpowiedzialnej za integrację modułów, osoba ta musi mieć wiele czasu i umiejętności, bo musi nie tylko pisać dobry kod, projektować hardware ale i mieć cierpliwość do rozmów z innymi osobami biorącymi czynny udział w projekcie.
    Fajnie by było, żeby osoby biorące udział w projekcie nie były anonimowe, a najlepiej, żeby znały się osobiście.

    Alternatywne podejście to rozpoczęcie na bazie skończonego projektu i jego udoskonalanie (projekt open source z netu?)

    Nie muszę mówić, że pierwszy projekt powinien byc jak najprostszy a nie jak najlepszy. Nawet w najprostszym znajdzie się bardzo wiele problemów, które na początku ciężko sobie wyobrazić. Wybranie projektu zbyt ambitnego pdp. skończy się jego nieukończeniem.

    Co myślicie?
  • #5 17748766
    And!
    Admin grupy Projektowanie
    Osoba kierująca projektem i zespołem, oraz podejście organizacji do projektu ma bardzo duży wpływ na działanie zespołu. W każdym zespole trafią się ludzie którym się trochę nie chce, albo projekt/zespół/przyjęte rozwiązanie/osoby w zespole - im się nie podobają,
    ale są też osoby zaangażowane, osoby specjalizujące się w określonych obszarach projektu. Właśnie to jest siła zespołu, że razem udaje się "dźwignąć" wielotematyczny i skomplikowany projekt, wymagający działań na wielu polach i posiadanie bardzo wielu kompetencji.

    Im więcej osób w zespole tym sprawniej musi być zapewniona komunikacja, aby nie tracić większości zasobów właśnie na komunikację zamiast działanie.

    Kolejna sprawa to że czasami jest miejsce na jednoosobowe działanie. To np. jest przygotowanie np. projektu (np. przez osobę z odpowiednimi uprawnieniami), następnie efekt takiej pracy trafia do zespołu, który ocenia projekt i wnioskuje o ew. zmiany. Taka jednoosobowa praca ma często związek z uregulowaniami prawnymi (np. budowlanka), lub z kosztami (np. outsorcing części projektu wymagającego posiadania np. drogiego oprogramowania lub maszyn).

    Kultura organizacji, metodyki projektowe, osoby decyzyjne, osoby kierujące, osoby w zespole, klient - to niektóre czynniki wpływające na sukces projektu.
  • #6 17749149
    _lazor_
    Moderator Projektowanie
    Pracowałem przez jakiś czas w projekcie embedded złożonego z prawie 100 osób rozsianych na całym świecie. A byliśmy tylko jednym elementem z o wiele większej układanki.
    Zawsze mnie to będzie fascynowało, że takie ilości ludzi jednak potrafią ze sobą współpracować i realizować ten projekt.

    Organizacja na poziomie projektu (tylko projektu, gdyż administracyjne elementy w tamtej firmie były bardzo słabe) była tak zrealizowana, że problemy rozwiązywano bardzo szybko, zatrudniono osoby z kompetencjami na stanowiskach menagerów oraz architektów. Obie grupy wywodziły się od "szeregowych" developerów co ułatwiało nam z nimi kontakt i nie mieli wyobrażeń wyssanych z palca.

    Oczywiście projekt borykał się z wieloma problemami, jednak nie doszukiwano się problemów u developerów (chociaż to oni szukają i naprawiają błędy ;) ) a doszukiwano się problemu w całym systemie, dlaczego doszło do możliwości popełnienia błędu i jak temu przeciwdziałać.

    Tam było widać, że umiejętności techniczne nie wystarczają by być dobrym developerem, ważne są również umiejętności miękkie. A może stwierdzenie, że zachowywaliśmy się bardziej jak dorosłe, dojrzałe osoby, które problemy rozwiązywały między sobą w zespole, nie eskalując czy rozwiązując je za pośrednictwem przełożonego jest bardziej odpowiednie.
    Nigdy nie dochodziło do sytuacji by ktoś powiedział "i co mi zrobicie?". To był projekt, gdzie faktycznie był zespół ludzi, który sobie nawzajem pomagał i nie bał się kontaktu między ludzkiego.
  • #7 17750559
    Konto nie istnieje
    Poziom 1  
  • #8 17750722
    wacek.wacek
    Poziom 29  
    To że nowa ekipa nie dogaduje się ze sobą to pokłosie starych decyzji. Mogą występować różnice np kulturowe . istnieje obawa też że ktoś może być pupilkiem szefa itp. Z twoich wypowiedzi wynika że kraj azjatycki na południu europy to Turków zatrudniliście? Pracowalem z lekarzem który jest muzulmaninemi syryjczykiem. Czlowiek całkowicie nie wspolpracujacy z otoczeniem . Wywalili go bo ani z pielegniarkami ani z lekarzami nie wspolpracowal. Przepraszam że to piszę ale podaje tylko przykład. Ogólnie reasumując ta sytuacja może miec korzenie w pamięci o poprzednikach może wynikać też z pochodzenia ludzi. Strach może nimi kieruje
  • #9 17750901
    tzok
    Moderator Samochody
    W mojej ocenie problem z ostatnim zespołem jest wielopłaszczyznowy. Pierwszym i podstawowym problemem, jest to, że wiedzą co stało się z poprzednim zespołem. Stąd właśnie słowa "i co mi zrobicie"... ten człowiek po prostu wiedział, że tak czy inaczej zostanie zwolniony.
    Druga sprawa to Wybitni Specjaliści. Praca w zespole wymaga trzymania się pewnych standardów, ogólnie zwanych wzorcami projektowymi. Problem w tym, że wzorce projektowe zostały stworzone z myślą o przeciętnych, by nie powiedzieć słabych, programistach (przez jakiegoś Wybitnego Specjalistę właśnie albo konsorcjum zrzeszające takich specjalistów). Kod pisany zgodnie z tymi wzorcami jest mało efektywny i bardzo ograniczony. Duża część tych wzorców służy jedynie temu, aby mało doświadczony programista nie zrobił czegoś źle. Dla Wybitnego Specjalisty takie normy są ograniczeniem, on ich nie tylko nie potrzebuje, ale one wręcz mu przeszkadzają w pracy. Nietypowe problemy wymagają wyjścia poza ramy norm i wzorców i właśnie dlatego wymagają Wybitnego Specjalisty. Każdy Wybitny Specjalista ma swoje zasady i z reguły jest indywidualistą. Jest też specjalistą, czyli specjalizuje się w pewnym zagadnieniu, lub grupie zagadnień, często nie dostrzegając innych problemów. Obecność kilku Wybitnych Specjalistów w jednym zespole to gwarantowane problemy. Zespołem musi kierować Wybitny Specjalista od... HR i często jest to jedyny Wybitny Specjalista jaki w ogóle jest potrzebny. Jeśli projekt tego wymaga można zatrudnić Wybitnych Specjalistów do rozwiązania jakiś konkretnych problemów w ramach projektu, ale to im przedziela się odrębne zespoły, którymi oni kierują i oni narzucają własne wzorce i standardy (chyba, że są w stanie pracować samodzielnie). Kod opracowany przez takiego Wybitnego Specjalistę lub jego zespół będzie czytelny tylko dla niego, co daje mu gwarancję pozostania w projekcie co najmniej do końca wsparcia dla tego projektu. Jego zespół można zwolnić po zakończeniu projektu, ale on musi zostać.
  • #10 17751035
    _lazor_
    Moderator Projektowanie
    Marek_Skalski napisał:
    @_lazor_ Opisujesz to, co ja też widzę i czego doświadczam. Kilkaset osób z różnych krajów i kontynentów pracuje razem nad jednym systemem i to działa. Są postępy, są konkretne osiągnięcia i odkrycia realizowane również jako publikacje naukowe. Ale nagle trafisz do zespołu, w którym od pierwszego dnia czujesz, że "coś nie gra", czegoś brakuje. I co teraz zrobić?

    Rozmawiam. Jako człowiek o bardzo mocnej postawie cholerycznej, jest to dla mnie trudne, bo często mam ochotę rzucić kilka zdań, których tutaj nie przytoczę, ale również wiem że takie postępowanie do niczego nie doprowadzi, no chyba że chce zdewastować zespół od środka.
    Więc jeśli czuję że "coś nie gra" to staram się nazwać to co nie gra i spróbować to przedyskutować z zespołem lub z konkretną osobą. W końcu jakby na to nie patrzeć, z zespołem spędzam 8h dziennie, jeśli będzie się wszystkim źle pracowało i ludzie będą to traktować jako niechciany obowiązek to ciężko będzie taką zbieraninę ludzi nazywać zespołem. Może wtedy trzeba przetasować ludzi?

    tzok napisał:
    Praca w zespole wymaga trzymania się pewnych standardów, ogólnie zwanych wzorcami projektowymi. Problem w tym, że wzorce projektowe zostały stworzone z myślą o przeciętnych, by nie powiedzieć słabych, programistach (przez jakiegoś Wybitnego Specjalistę właśnie albo konsorcjum zrzeszające takich specjalistów). Kod pisany zgodnie z tymi wzorcami jest mało efektywny i bardzo ograniczony. Duża część tych wzorców służy jedynie temu, aby mało doświadczony programista nie zrobił czegoś źle. Dla Wybitnego Specjalisty takie normy są ograniczeniem, on ich nie tylko nie potrzebuje, ale one wręcz mu przeszkadzają w pracy.


    @tzok
    W aktualnym projekcie miałem taką jednostkę, która wybijała się ponad przeciętnych programistów. Został architektem i wprowadził... własny guideline.
    Dlaczego? Gdyż podejście do problemu wymagało zastosowania niestandardowych mechanik, choćby by zaglądać do dokumentacji eabi i patrzeć jak realizowana jest dana mechanika języka na danej architekturze. Trzeba było choćby rozumieć jak wygląda mechanizm translacji języka na assembler, gdyż architektura była bardziej egzotyczna i dla przykładu pozwalała na optymalizację 10 argumentów do rejestrów, gdzie taki arm aarch32 pozwala na 4 argumenty, aarch64 na 8 argumentów. Niby małe nic, ale w kodzie gdzie primo performance (tak liczyliśmy cykle) miało to duże znaczenie.
  • #11 17751561
    Konto nie istnieje
    Poziom 1  
  • #12 17751609
    _lazor_
    Moderator Projektowanie
    No cóż, u mnie rozmawiało się głównie jednak o pracy lub pokrewnych. Może to jednak jakaś forma selekcji? Dzięki takim rozmowom luźnym ale jednak o tematyce technicznej poznawałem różne osoby i o ich zainteresowaniu i doświadczeniu. Łatwiej dzięki temu było kogoś przekierować lub samemu pójść o poradę.

    Dodatkowo te wszystkie magiczne systemy typu scrum, agile itp. Hmm jeśli ktoś je wprowadza na siłę to moim zdaniem jest to tragedia, jednak dobrze użyte elementy przynoszą faktyczne rezultaty. Choćby codzienne 10-15min spotkanie by każdy powiedział co aktualnie robi. Moim zdaniem super, gdyż jeśli ktoś ma problem z zadaniem to na takim spotkaniu to wyjdzie i można to skorygować. Kiedyś miałem sytuację gdy młodemu kazałem coś zrealizować, a sam robiłem swój kawałek. Gdy po tygodniu zapytałem jak idzie, a człowiek dalej był w malinach to trochę mnie poniosło. Jednak w ostateczności to nie był jego błąd, tylko mój bo nie dostał dostatecznego wsparcia, a takie codzienne spotkanie dobrze takie rzeczy koryguje (wniosek z późniejszych obserwacji).
  • #13 17751741
    tzok
    Moderator Samochody
    Regularne spotkania są dobre dla nowych i początkujących, Wybitny Specjalista nazwał by je stratą jego cennego czasu i z pewnością konieczność przychodzenia na nie by go drażniła.
  • #14 17751743
    Konto nie istnieje
    Poziom 1  
  • #15 17751759
    _lazor_
    Moderator Projektowanie
    Po to jest system review, aby nie dało się zwalić winy na młodego ;) W mniejszym projekcie trzeba było klepnięcia architekta, aby można było commitować, a w większym przynajmniej dwóch doświadczonych osób. Nie mówiąc jeszcze o naprawdę sporej ilości automatycznych testów integracyjnych.

    Po drodze powinno być dużo elementów aby nie dało się na młodego zwalić winny ;)

    I nasz żart w pracy "Unit testy? a po co to komu przecież wszyscy jesteśmy nieomylnym ekspertami co tworzą bezbłędny wspaniały kod".
  • #16 17751840
    Konto nie istnieje
    Poziom 1  
  • #17 17751870
    krisRaba
    Poziom 31  
    Spotkania muszą być zwięzłe, wtedy działają. A jak zauważy się problem w jakimś punkcie, to w tym punkcie działa się już indywidualnie poza spotkaniem.
    Mam doświadczenie zarówno takiego spotkania, trwającego 10-20minut, gdzie pada konkret co się dzieje, oraz różnych spotkań trwających pod 2 godziny, gdzie mnie dotyczy/interesuje średnio 5 minut.
    Jeżeli z moich 8 godzin 2 są zmarnowane na rzeczy, które mnie nie dotyczą, a których muszę słuchać, to narasta frustracja i przestaję mieć ochotę brać w tym udział.
    Natomiast te konstruktywne, szybkie spotkania bardzo sobie cenię i zyskuje się na nich ogląd całej sytuacji. Można też wyłapać moment, że coś skręciło w nieco inną stronę niż było dyskutowane od początku. I nie jest to złe, zmiana jest sensowna, ale warto o niej wiedzieć, po prostu komuś umknęło poinformować niektóre osoby, bo niby to nie ma aż takiego związku ;) Wtedy jest szansa dopytać.
    Jak ktoś sygnalizuje problem, to można z nim pogadać i spróbować lekko popchnąć w dobrym kierunku lub wzmocnić chwilowo przydzielając kogoś do pomocy.

    Jeśli chodzi o dzielenie się wiedzą lub nie... Wydaje mi się, że trochę związek to ma z osobowością, trochę ze startem w wyścigu szczurów albo w zespole (tutaj ważne jest docenianie i odpowiednie "rozgrywanie" w zespole), wzajemne relacje, by ktoś nie obawiał się, że inny wykorzysta jego wkład, by samemu się wybić itp.
    Znam przykładowo gościa, który opowiadając o jakimś sukcesie/osiągnięciu (zapytany lub z własnej inicjatywy) potrafił podkreślić wkład poszczególnych osób w to, że się udało, np. "Kamil przyszedł z takim pomysłem, to było przełomowe bo..., porozmawialiśmy jeszcze z Łukaszem i on zasugerował, że... co pozwoliło osiągnąć to, że..." itp. Słuchasz takiej rzeczowej wyliczanki i aż chce ci się z gościem współpracować, bo widzi twój wkład i nie przypisuje go sobie, mimo że odpowiada za całość.
    I znam gościa, gdy zapytany co słychać, mówi o sukcesie, wiesz że XX% to twój pot i łzy, a opowiadanie cię pomija i wszystko leci na konto zapytanego... Z jednej strony pracownik ma zapłacone za swoją robotę, więc w czym problem? Ale jednak problem jest i to na poziomie, którego potem pieniądze mogą nie zreperować.
    I takich niuansów jest mnóstwo. Swoją drogą ludzie odpowiedzialni w firmie czasami zapominają o banalnych, a bardzo ważnych sygnałach, typu: "Dobrze wykonujesz swoją robotę", "Jestem zadowolony z wyników twojej pracy", "Twój wkład w to i to jest bardzo ważny dla tego przedsięwzięcia" itp. Gdy projekt jest ambitny, czas leci, to przy ciszy w eterze nie wiesz, czy twój zwierzchnik już jest zniecierpliwiony, że tyle się z tym boksujesz? A może wie, że to ciężki temat i taki postęp prac w czasie jest nadal OK? No i powiedz jeszcze, że masz z czymś problem, jak masz wrażenie, że i tak już za długo to robisz ;) Kolejny raz komunikacja... po ludzku, nie z robotem ;)

    Co gorsze dla budujących zespół, to w danej osobie znajdziesz wynik jego doświadczeń z poprzednich lat, że ktoś się sparzył na tym i tamtym. Ponowne otwarcie może wymagać gimnastyki lidera, ale czasem jest do zrobienia.
    Innym razem trzeba po prostu zrobić tak, jak już koledzy pisali. Jak jest dobry, ale trudny do współpracy, to trzeba inaczej rozdzielić projekt, by nie zepsuł reszty zespołu i by sam czuł się dobrze.
  • #18 17751981
    Konto nie istnieje
    Poziom 1  
  • #19 17751992
    Konto nie istnieje
    Poziom 1  
  • #20 17752037
    Konto nie istnieje
    Poziom 1  
  • #21 17752200
    timo66
    Poziom 23  
    Szczerze powiedziawszy ciężko coś poradzić mając może 5% wglądu w sytuacje. Każdy człowiek jest inny × mnogość kultur i masz sytuację którą ciężko ogarnąć. Wspomniany system pochwał np. do mnie by kompletnie nie trafiał. Po prostu nie robię sobie dużo ze zdania innych. Potrafię w miarę trzeźwo ocenić mój wkład, co osiągnąłem i to jest moja frajda. Jak w czymś nie widzę sensu to można robić co się zechce, ale ja do tego ręki nie przyłożę.
    Co możesz zrobić, to wybadać jakich ludzi masz. Do każdego trafiasz inaczej, może masz przypadek, że ludzie do siebie kompletnie nie pasują.
    Poczytaj o osobowościach według Myers–Briggs Type Indicator https://en.wikipedia.org/wiki/Myers%E2%80%93Briggs_Type_Indicator
    W sieci są gotowe testy z pytaniami. Kosztuje to może 10-20minut, a masz jakieś podstawy dotarcia do ludzi.
  • #22 17753179
    tzok
    Moderator Samochody
    Marek_Skalski napisał:
    Czy to kwestia wynagrodzenia, czy kompetencji, czy odpowiedzialności, czy przedmiotu projektu?
    Według mnie to kwestia... kierownika, czy jak tam w korpo na niego wołają menedżera projektu.
  • #23 17753227
    Konto nie istnieje
    Poziom 1  
  • #24 17753625
    OldSkull
    Poziom 28  
    Marek_Skalski napisał:
    Z mojego doświadczenia wynika, że fraza "młody, dynamiczny zespół" oznacza poważne problemy firmy w utrzymaniu pracowników. W praktyce, co miesiąc ktoś odchodzi, ktoś przychodzi. Naturalna rotacja na poziomie 2% w skali roku jest ok. Jak jest 5% to już trzeba się zastanowić co jest źle. Jak jest 15%, to sytuacja jest tragiczna.

    Pracowałem w firmie, gdzie rotacja była na poziomie 30-35% wśród pracowników biurowych, a do tego kulało "review", wdrażanie trwało wieki i nie było odpowiedzialności za błędy (bo jak ktoś był młody to większość jego błędów nie zdążyła wyjść zanim zmienił robotę. To nie była tragedia, to był koszmar.

    Natomiast pytanie: gdzie są firmy technologiczne, gdzie rotacja jest 2%? Czy to jest kwestia wieku pracowników? 2% oznacza pracę od stażu w trakcie studiów aż do emerytury. Młodzi ludzie sami zwykle nie chcą tak długo pracować w jednej firmie. 5% oznacza średnio 20 lat stażu. Już bardziej realne jeśli założymy, że zatrudniamy ludzi około 40 lat, bo czasami odejścia są spowodowane kwestiami losowymi, a nie sytuacją w firmie. I pytanie czy to oznacza, że nie liczymy ludzi, którzy zostaną zwolnieni? Też liczą się do rotacji. Z moich doświadczeń wynika raczej, że 15% (6-7 lat średnio) to byłby dobry wynik, a projekty muszą być tak prowadzone, że w dowolnym momencie dowolna jedna osoba może odejść i to nie spowoduje katastrofy.
  • #25 17755789
    Konto nie istnieje
    Poziom 1  
  • #26 17756311
    OldSkull
    Poziom 28  
    Ciekawe z czego to wynika. Pracowałem dotychczas w firmach zachodnich, ale oddziałach polskich i niestety jest pewne zjawisko, które potwierdzają również znajomi z innych firm: po pierwszym roku ciężko o sensowną podwyżkę, jedynie inflacyjna. Chcąc zarabiać więcej trzeba awansować na kierownika (czyli najlepsze osoby techniczne po prostu się zwykle nie nadają lub też model w firmie jest taki, że choć nie koniecznie powinni, to muszą 90% czasu spędzać jako kierownik) - albo zmienić pracę.

    Pracodawcy narzekają na brak lojalności ze strony pracownika, ale sami nie są wobec pracowników w porządku.
    Efekt jest taki, że na stanowisku zostają ludzie, którym:
    1. wszystko jedno, więc z motywacją u ncih średnio, albo
    2. są słabymi specjalistami i ciężko im zmienić pracę, albo
    3. sytuacja osobista ich w jakiś sposób blokuje, albo
    4. mają na tyle słabe umiejętności miękkie, że trudno im wypaść dobrze na rozmowie kwalifikacyjnej, albo
    5. zależy im aby zmienić sytuację w firmie, aby było lepiej
    Do budowania zespołu nadają się 3 ostatnie grupy, ale "4" tylko do niektórych funkcji (chociaż tacy ludzie są często potrzebni), a "5" może w każdej chwili stracić cierpliwość i zmienić pracę. Podobnie "3" może poprawić swoją sytuację i też zapragnąć zmienić pracę. Przez to wszystko w zespołach są albo ludzie niedoświadczeni w firmie (nie znają historii problemów i produktów) albo słabi, albo przy projektach trwających kilka lat mogący odejść.
    Marek_Skalski napisał:
    Może to właśnie jest klucz do współpracy? Wzajemny szacunek, zrozumienie, umiejętność słuchania i trochę pokory?

    Najważniejsze jest chyba, aby dział HR oraz keirownicy projektów byli dobrzy. Muszą zrekrutować pod swoje zapotrzebowania odpowiednich ludzi. Są funkcje, gdzie nawet osoba problematyczna wykona swoją robotę, ale musi być dobrze prowadzona. Najważniejsze aby kierownik projektu ogarnął grupę ludzi i Ci go słuchali. Jeśli ktoś go nie słucha, oraz nie słucha jego rad i wprowadza zamęt, a dział HR nie potrafi mu pomóc, to taka osoba powinna niestety wylecieć.
  • #27 17756411
    _lazor_
    Moderator Projektowanie
    Historię o HR to ja mam dziką. Chciałem 3 razy się dostać do pewnej firmy 3 razy mnie olano, nawet nie było telefonu zwrotnego czy choćby maila, po prostu cisza. Na ironię zacząłem tam pracować jako pracownik outsourcingowy, po roku nawet chciałem dla nich pracować jako internal, ale znów problem z natury administracyjnej to się wkurzyłem i poszedłem gdzie indziej (nawet gdy magicznie problemy administracyjne znikły). A potem płacz, że ludzi do pracy znaleźć nie mogą.
  • #28 17759240
    nanab
    Poziom 27  
    Marek_Skalski napisał:
    Czy kiedy dostajemy zadanie trudne, zbyt trudne, to w żaden sposób nie chcemy się przyznać, że nie damy rady i szukamy rozwiązania dopóki mamy czas z nadzieją, że się uda?

    Jeśli w danej dziedzinie jestem ekspertem, a mój kierownik do którego raportuję już nie, to przyznanie się do problemów raczej nie pomaga. Zwykle daje to tylko stratę czasu na tłumaczenie kierownikowi zasady działania danego urządzenia, istoty problemu i omawianiu prób rozwiązania problemu które albo nie mają sensu, albo sprawdziliśmy je już na początku. Jeśli jest w zespole ekspert z tej samej dziedziny to też nie pomoże, bo:
    a.) jeśli ma niższy lvl to nie ma jak pomóc
    b.) jeśli ma wyższy lvl to zwracamy się do niego zamiast do kierownika.
  • #29 17759777
    Konto nie istnieje
    Poziom 1  
  • #30 17759939
    Konto nie istnieje
    Poziom 1  
REKLAMA