Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

Marek_Skalski 01 Lut 2019 23:00 2586 33
  • #1 01 Lut 2019 23:00
    Marek_Skalski
    Moderator Projektowanie

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

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


    Dręczy mnie to już kilka dni. Ale zacznijmy od początku.
    Minęły cztery lata od czasu zamknięcia projektu „AQ570”. To miał być przełom. Nowa jakość, ponad 2x większa wydajność, 3x większa dokładność, a do tego wszystko przemyślane i sprawdzone, aby nigdy więcej serwis nie musiał się wstydzić za konstruktorów. Duży projekt, w którym ponad 500 ludzi walczyło o lepsze jutro. Ale klienci wycofali się z zamówień i cały projekt trafił na półkę. Część ludzi zwolniono, część została przechodząc do innych projektów. Taka piękna katastrofa.

    Minęły 2 lata od czasu zamknięcia projektu „ST3085”. To też miał być przełom. Wykorzystano wszystko co tylko było możliwe z „AQ570”. Tym razem bez wielkiej pompy, bez wielkich oczekiwań – ot, kolejna generacja maszyn, które są kluczowe w produkcji. Wszystkie moduły precyzyjnie określone, zaprojektowane z dbałością o szczegóły, dokumentacja przygotowana porządnie, sprawdzona i zaakceptowana przez dostawców.
    Pierwszy prototyp został dokładnie przebadany i okazało się, że jest zgodny ze specyfikacją. Dobra robota wykonana przez ~300 ludzi. Dlatego część ludzi zwolniono, a część została przechodząc do innych projektów.
    Dlaczego?
    Ponieważ żaden z dotychczasowych klientów nie jest zainteresowany zakupem maszyn z linii "ST3085". Nikt nie potrzebuje takiej dokładności czy wydajności.

    Minęły 3 miesiące od czasu uruchomienia projektu "ST6830". Tym razem decyzję oparto na wynikach szczegółowych rozmów z klientami. Wiemy czego chcą i dokładnie to dostarczymy. Wszystko było prawie gotowe, ponieważ wykorzystaliśmy wcześniejszy system - "ST3085". Potrzebny był tylko dobry, zgrany zespół do wprowadzenia poprawek, zamknięcia testów i dokumentacji. Najlepiej ten, który to opracował.
    Niestety oni nie wrócą, ponieważ zwolniliśmy większość z nich za dobrze wykonaną pracę. Ktoś zaproponował, aby dopuścić świeżej krwi zatrudniając inżynierów uciekających z kraju podlegającego dynamicznym zmianom politycznym. Wiecie, taki azjatycki kraj na południu Europy, który ma dużo ludzi, dużo inżynierów i dobrze rozwinięty przemysł. Przyjechali i przywieźli swoją kulturę. Trochę inną od naszej. I pojawił się problem...

    Niechętnie z nami współpracują, niechętnie dzielą się informacjami. Każdy z nich jest specjalistą w swojej dziedzinie i jest dumny z tego powodu. Nawet nie rozmawiają ze sobą. Każdy z nich pracuje sam nad tematem. Dopiero jak minie termin, informują o opóźnieniach. Nikt nie wie na jakim etapie realizacji są ich zadania.

    Trzy tygodnie temu nie wytrzymałem i zapytałem dlaczego wcale nie informują o problemach, o zagrożeniach, o tym co robią.
    Na nic zdały się tłumaczenia, że przecież jesteśmy zespołem, możemy i powinniśmy sobie pomagać, a podstawą jest efektywna i spójna komunikacja. Wtedy zaczęli szeptać w swoim języku i w końcu jeden z nich wypalił:
    Ja wiem jak to zrobić i nikt mi nie będzie mówił co i jak! Jak skończę, to powiem! I co mi zrobicie?!

    Nic mu nie zrobiliśmy – nawet wizy nie przedłużyliśmy. Jest wolnym człowiekiem. ;)



    Czy trafiliście na podobne sytuacje, jakie jest Wasze zdanie w poniższych tematach?
    Czy my potrafimy pracować w zespołach, potrafimy ze sobą rozmawiać, ufać w swoje umiejętności i wspólnie rozwiązywać problemy, wykorzystując posiadaną wiedzę z różnych dziedzin?

    A może jesteśmy indywidualistami, którzy specjalizują się w wąskiej dziedzinie i preferują pracę w pojedynkę i nie lubimy "oddawać" naszej wiedzy?

    Czy to kwestia wychowania, doświadczeń, poziomu bezpieczeństwa, dumy?

    Co sprawia, że zmieniamy swoje nastawienie, otwieramy się lub zamykamy na współpracę?

    Jakie jest Wasze spojrzenie oraz doświadczenia w kwestii pracy zespołowej?

    Zajrzyjcie do tematu gdzie można w praktyce wziąć udział w zespołowym projekcie: Projekt DSO na elektroda.pl

  • #2 02 Lut 2019 04:50
    pawelr98
    Poziom 36  

    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.

  • #3 02 Lut 2019 06:04
    wacek.wacek
    Poziom 15  

    Wylaliście specjalistów za dobra robotę. Czego teraz sie spodziewacie?

  • #4 02 Lut 2019 09:30
    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 02 Lut 2019 09:49
    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 02 Lut 2019 12:40
    _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 02 Lut 2019 23:53
    Marek_Skalski
    Moderator Projektowanie

    @pawelr98 Myślę, że życie akademickie jest bardzo daleko od realiów przemysłowych. Szczególnie wskazuje na to Twoje stwierdzenie dotyczące kasowania i pisania od nowa. Niechęć do analizy i forsowanie swoich rozwiązań, aby przejść do fazy realizacji, to właśnie jest brak umiejętności pracy w zespole. Zgaduję, że jesteś wyjątkowym indywidualistą. A co zrobisz jak trafisz na twardszego od siebie - obrazisz się i odmówisz współpracy? Zmienisz pracę?
    @wacek.wacek Dodałem rys historyczny, ponieważ zastanawia mnie dlaczego stary zespół złożony z raczej przypadkowych ludzi, do którego należałem, potrafił opracować skomplikowany system w relatywnie krótkim czasie, a nowy zespół zbudowany ze starannie wybranych specjalistów jest znacznie mniej efektywny.
    Zastanawia mnie dlaczego w starym zespole, można było pogadać przy automacie z kawą na każdy temat i wszyscy znaliśmy się nie tylko na gruncie zawodowym, a w nowym zespole nie występuje coś takiego jak integracja. Zamiast zespołu, jest grupa pracujących (lub też przeszkadzających sobie) specjalistów, którzy nie rozmawiają ze sobą.
    Nie jestem w żaden sposób odpowiedzialny za wyniki, więc mógłbym uznać, że to nie mój problem, ale na dłuższą metę praca w takim stylu jest męcząca. A ja nie lubię jak praca mnie męczy, dlatego szukam przyczyn i możliwości wyjścia z tego impasu. Ludzie nie są przecież źli. Ich zachowanie musi z czegoś wynikać. Masz jakiś pomysł?
    @gdL Zgadzam się z Tobą. Dobry szef projektu zna bardzo dobrze temat, a nie tylko techniki zarządzania. Żelazny trójkąt działa zawsze. Czasu cofnąć nie można, więc trzeba ograniczać ryzyko w projekcie. Stąd właśnie podział na alfa, beta i proto. Nie rzuca się 100% zasobów od pierwszego dnia i nie trzyma się 100% zasobów do ostatniego dnia projektu. Zadania powinny być możliwe do wykonania w sensownym czasie, a rezultaty powinny nadawać się do "sprzedaży"; na zewnątrz lub wewnątrz organizacji. Dobry kierownik projektu wie, że to inwestycja, która ma się zwrócić. Ciekawe czy uda się zrealizować takie podejście w projekcie DSO?
    @And! Tak, właśnie o to chodzi, aby specjaliści posiadający wiedzę z różnych dziedzin, wspólnie coś opracowali. Coś, czego jeden człowiek nie zrealizuje, choćby poświęcił na to całe swoje życie. Więcej, chodzi o to, aby wiedza zdobyta podczas tych prac została usystematyzowana i zarchiwizowana. Największą wartością konstrukcji jest jej dokumentacja. To dzięki dokumentacji wiadomo co i jak funkcjonuje, dlaczego podjęto konkretne decyzje projektowe, gdzie jest ryzyko i co można poprawić. Inżynieria to proces, który się nie kończy. Są tylko kolejne wersje. Moim zdaniem, to co zasadniczo odróżnia profesjonalistę od hobbysty to umiejętność projektowania w oparciu o wymagania, tworzenia kompletnej dokumentacji oraz świadomość, że produkt będzie rozwijany w przyszłości.
    @_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ć?

  • #8 03 Lut 2019 06:57
    wacek.wacek
    Poziom 15  

    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 03 Lut 2019 10:32
    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 03 Lut 2019 11:37
    _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 03 Lut 2019 14:43
    Marek_Skalski
    Moderator Projektowanie

    W ostatnich trzech latach zatrudnienie w firmie wzrosło z 14000 do 23000 ludzi. I zatrudniają kolejnych. Przyjęło się, że przez pierwsze 6 miesięcy pracownik jest bezproduktywny. Zanim zrobi wszystkie szkolenia, zanim nauczy się zasad pracy, zanim odnajdzie się w środowisku i strukturze trzeba minimum 6 miesięcy. W drugim półroczu coś już może generować, ale wydajność jest oceniana na poziomie 30% max. W drugim roku zaczyna sensownie pracować i jeżeli jest dobrze prowadzony, to sprawnie porusza się w strukturze i tworzy wartość dodaną. Nikt nikogo nie zamierza zwalniać, a ci nowi nawet nie wiedzą co było 4 czy 5 lat temu.
    Jeszcze ważniejsze w tym wszystkim, że tu nie chodzi o programistów. Mówimy o projekcie, w którym potrzebna jest współpraca między specjalistami z wielu dziedzin techniki: mechanika precyzyjna, mechanika płynów, dynamika, termodynamika, elektronika w.cz., elektronika komponentów, projektowanie PCB flex-rigid, sensory światła, interferometry dyfrakcyjne, analizy FEM, analizy pola magnetycznego, transmisja ogromnych ilości danych oraz synchronizacja modułów i zarządzanie czasem, programowanie FPGA oraz procesorów, współpraca z dostawcami i setki innych rzeczy. I tylko w jednej grupie mechaników brak komunikacji. Zastanawiam się czy nie zmienić kierownika zespołu, który patrzy, ale nie widzi.

    Patrząc na to z drugiej strony, zastanawiam się co sprawia, że ludzie otwierają się na współpracę i zaczynają sobie ufać? Obserwując moich kolegów doszedłem do tego, że na pewno nie są introwertykami, nie są zamknięci w sobie i rozmawiają o wszystkim, tylko nie o pracy. Czy to może być kwestia dumy? 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?
    A może to kwestia wiary w swoje umiejętności? Przecież jesteśmy profesjonalistami, ekspertami, więc na pewno damy radę. A jak się nie uda w tym tygodniu, to może w następnym... Ale walczymy, nie poddajemy się i nie raportujemy porażki.
    Jak często czuliście się jak Anderson?
    Expert-zlecenie
    A jak często występujecie w roli Scott'a?
    Expert-wykonanie

  • #12 03 Lut 2019 15:00
    _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 03 Lut 2019 15:38
    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 03 Lut 2019 15:38
    ICL7660
    Poziom 15  

    Weź pod uwagę, że spora część kadry w takiej sytuacji zwali winę na "młodego" wybielając się przy tym przed swoimi zwierzchnikami. A ci na ogół nie mając wiedzy przyjmą do wiadomości opinię eksperta.

  • #15 03 Lut 2019 15:47
    _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 03 Lut 2019 16:11
    Marek_Skalski
    Moderator Projektowanie

    @tzok Regularne spotkania to dla mnie standard. Przynajmniej raz w tygodniu wszyscy muszą usiąść razem. Każdy powinien mieć swoje 5 minut. Niektórzy rozliczają przeszłość (której nie zmienimy), inni określają cele na najbliższy tydzień. Jak widzę zagrożenie (opóźnienie, brak informacji, brak komponentów do testów), to o tym mówię, nie ukrywam. Jestem ekspertem w swojej dziedzinie i nie uważam takich spotkań za stratę czasu.
    @ICL7660 Nikt nie szuka winnego. Jeżeli jest problem, to szuka się rozwiązania, dokumentuje przyczyny i sposoby analizy, aby w przyszłości problem nie wystąpił albo był szybko rozpoznany i zneutralizowany.
    Autorytetów nie unikniemy. Ktoś, kto potrafi załatwić sprawę szybko i sprawnie, zawsze będzie postrzegany inaczej niż gawędziarz, który ma tysiące opowieści, ale żadnych efektów. Kiedy pracowałem w Polsce, to mój szef zażyczył sobie, abym potrafił zaimponować młodym inżynierom ;) Zapytałem go czy na pewno chodzi o zaimponowanie, czy może o zainspirowanie? Głupio mu się zrobiło i coś tam wystękał o zachęcaniu do pracy, ale to były zupełnie inne realia. Brak motywacji, brak morale, brak przywództwa w firmie. Dlatego spędziłem tam aż 3 miesiące.

    Właśnie, system review. Lepiej wyrzucić ryzę papieru niż tonę części. Bardzo rozbudowany, nie można czegoś "przepchnąć na siłę" czy zrobić "w tajemnicy", ponieważ inżynier wiodący, architekt, TL, PL, specjalista od zarządzania dokumentacją (EC) i jeszcze kilka innych osób musi zatwierdzić każdą zmianę, każdy rysunek, każdą porcję kodu. Prędzej czy później błędy wychodzą. Ukrywanie czegoś nie ma sensu. Praca w pojedynkę nie ma sensu. Przeciąganie raportów nie ma sensu.

    Ponawiam pytanie: Jak myślicie, co sprawia, że potrafimy się otworzyć na współpracę, a co wywołuje skutek zupełnie odwrotny? Czy to kwestia wynagrodzenia, czy kompetencji, czy odpowiedzialności, czy przedmiotu projektu?

  • #17 03 Lut 2019 16:21
    krisRaba
    Poziom 26  

    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 03 Lut 2019 17:03
    Marek_Skalski
    Moderator Projektowanie

    Bardzo mi się podoba to co tutaj wypunktowałeś. Spotkania bez sensownego planu i związku z naszymi zadaniami omijamy. Strata czasu.
    W zespole pracujemy wspólnie. Jak coś robimy, to kredyty idą na konto wszystkich zaangażowanych osób, a nie tylko ja, ja i ja...
    Właśnie zdałem sobie sprawę, że w moim zespole brakuje pochwał za dobrze wykonane zadania. Nie bardzo mam ochotę wchodzić w buty kierownika zespołu, ponieważ to zawsze oznacza konflikt na tle kompetencji, ale przypomniałeś mi o nagradzaniu. Ma to szczególnie duże znaczenie w młodym zespole, który nie może się jeszcze pochwalić spektakularnymi sukcesami. Dziękuję! :)

  • #19 03 Lut 2019 17:07
    ICL7660
    Poziom 15  

    Czyli słabo zarządzana firma to duża rotacja pracowników?
    Jeszcze mi się przypomniała jedna przykra praktyka kierownictwa niższego szczebla. W systemie premiowania uznaniowego kierownik potrafił zapomnieć wyznaczyć premiowane zadania pracownikowi lub dodawał je w taki sposób, że pracownik miał mało czasu na ich wykonanie lub o zadaniu tylko słyszał, bez potwierdzenia na piśmie. To przy kwartalnym systemie rozliczania z zadań powodowało, że pracownik mógł o czymś zapomnieć i miał to potrącane z premii.
    Bez zadań nie było premii.

  • #20 03 Lut 2019 17:21
    Marek_Skalski
    Moderator Projektowanie

    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. Coś ustalasz, zaczynasz realizację, chcesz zatwierdzić, a ten człowiek już nie pracuje. I tak co chwilę. Finalnie i Ty nie wytrzymujesz i odchodzisz. Powodów może być cała masa - finansowe, lokalizacyjne, mobbing, konieczność ciągłych podróży, delegacji, czy po prostu głupie kierownictwo.

    Jeżeli firma jest dobrze zarządzana, to rośnie i ludzie przychodzą. Jak jest wzrost na poziomie 10%-20% rocznie, to jeszcze jest do przyjęcia. Jak jest 30%, to trudno to opanować. Czas jaki spędzasz z nowymi pracownikami na wdrożeniu, to jest czas, którego nie możesz użyć na działania w swoich tematach. Ostatnio 2 dni w tygodniu (średnio) spędzamy z nowymi pracownikami. Ale jeżeli tego nie zrobimy, to tylko opóźnimy ich start i późniejsze wsparcie z ich strony. Najlepsza opcja to zatrudniać doświadczonych z tego samego obszaru. Ale takich ludzi już nie ma na rynku, więc szkolimy nowe pokolenie lub ludzi pracujących do tej pory w branżach pokrewnych.

  • #21 03 Lut 2019 18:14
    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 03 Lut 2019 22:41
    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 03 Lut 2019 23:00
    Marek_Skalski
    Moderator Projektowanie

    @timo66 Tu nie chodzi o klepanie po plecach czy uścisk spoconej dłoni prezesa ;)
    Nie będziemy się przecież zachwycać wykonywaniem obowiązków. Chodzi o zwykłe podkreślenie dobrych działań, wyjścia z inicjatywą, poprawy czegoś lub opracowania lepszej metody na coś. Piszę trochę ogólnikowo, ale nie mogę się odwołać do konkretów z pracy ze względu na ochronę wartości intelektualnych.
    Wiem jakie to uczucie jak poświęcasz na coś ~800h, często po pracy, zrobiłeś coś fajnego, a na poważnym spotkaniu mój kierownik stwierdził, że dzięki jego wsparciu i ciężkiej pracy opracowano tę właśnie rzecz. Radość moja była wielka, a z natury jestem cholerykiem ;) Rozstaliśmy się i ani trochę nie żałowałem. W dużej firmie jest dużo możliwości.
    Dzięki za nową metodę. Do tej pory najwięcej korzystałem z Belbina i kolorów. Działało.

    @tzok Kierowników to ja mam przynajmniej trzech. Jeden to szef mojej grupy (GL), który ma stado specjalistów z odpowiedniej dziedziny. Drugi to kierownik projektu (PL), który koordynuje pracę zespołów, przydziela pieniądze, ustala priorytety i cele dla każdego zespołu. Poważny gość. Trzeci to mój kierownik zespołu (TL), który ustala priorytety zadań, rozdziela pracę w grupie, pilnuje terminów, itd... I to chyba jest najsłabsze ogniwo.
    Ale przecież nie chodzi o moją pracę, tylko o całokształt.

    W temacie dotyczącym DSO widać wymianę poglądów na temat parametrów, ale nikt nie garnie się do udziału w projekcie. Ale czasu jeszcze jest sporo, więc możemy zaczekać na deklaracje.

  • #24 04 Lut 2019 09:19
    OldSkull
    Poziom 27  

    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 05 Lut 2019 01:51
    Marek_Skalski
    Moderator Projektowanie

    Są takie firmy w przynajmniej kilku miejscach. W Eindhoven jest kilka, w Kopenhadze też coś się znajdzie. Reklamował na forum nie będę. ;)
    Rotacja 2% oznacza, że 2 pracowników na 100 w danym roku kalendarzowym odchodzi. Zwolnieni w to nie wchodzą, ponieważ zwolnienie to definitywna strata - jest najgorszym rozwiązaniem, którego się unika. Już lepiej przesunąć delikwenta na zaszczytne stanowisko ambasadora w Mongolii, gdzie nic nie może i nic nie zepsuje. ;)
    I może trudno w to uwierzyć, firma ma 35 lat, ale są ludzie od czasów jak kończyli studia i ani myślą szukać innej pracy. Przychodzili w różnych latach i fakt, nie jest ich dużo, ale to są ci najlepsi, z którymi najłatwiej się pracuje. No właśnie, z tymi pracuje się łatwo, ponieważ znają temat, potrafią szybko ocenić szanse realizacji pomysłów, znają i pamiętają błędy z przeszłości, a przy tym nie zadzierają nosa.
    Trochę gorzej jest jak ktoś nie ma doświadczenia, nie ma racji, ale lubi wszystko kwestionować i ma bardzo duże ego. Może to właśnie jest klucz do współpracy? Wzajemny szacunek, zrozumienie, umiejętność słuchania i trochę pokory?

  • #26 05 Lut 2019 12:07
    OldSkull
    Poziom 27  

    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 05 Lut 2019 13:09
    _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 06 Lut 2019 19:00
    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 06 Lut 2019 21:56
    ICL7660
    Poziom 15  

    c.) ma w nosie niewiedzącego i mu nie pomoże. A jak trzeba to jeszcze doniesie do kierownictwa, że kolega jakiś nie taki, bo nie wie i najlepiej pozbyć się go. A sam ekspert zjadł wszystkie rozumy i zna się na wszystkim najlepiej.

  • #30 06 Lut 2019 22:51
    Marek_Skalski
    Moderator Projektowanie

    Ja też kiedyś miałem przejścia z HR. Chcieli mnie zatrudnić na stałe w firmie, dla której pracowałem jako wolny strzelec, ale nie chcieli dobrze zapłacić. Zażądali ode mnie zeznania podatkowego za ostatni rok, abym "usprawiedliwił swoje żądania płacowe". Po długich negocjacjach w końcu udostępniłem zeznanie podatkowe, jedyny dokument blokujący podpisanie umowy, a wtedy usłyszałem, że moje kwalifikacje nie są wystarczające. (Pracowałem już dla nich przez jakiś czas.) HR zrealizował swój cel. Zaoszczędzili ileś tysięcy w skali roku. Ale stracili znacznie więcej, ponieważ czekało na mnie 14 osób, którym płacili godziny postojowe przez 3 miesiące. Finalnie gość z HR wyleciał z pracy, a ja podpisałem kontrakt, ale z kimś innym. :)

    Trochę smutny obraz pojawia się między wierszami. Czy myślicie, że nawet dzisiaj, kiedy pracy jest więcej niż chętnych i nie trzeba o nią zabiegać, zazdrość i zawiść nadal gra tak duża rolę w działaniach ludzi? Nie wszystkich, ale czasami tych całkiem istotnych dla firmy?