Związki zawodowe w IT

1

Polska ma jeszcze stosunkowo młodych programistów, a z młodością łączy się wiara w samodzielne zawojowanie świata i poradzenie sobie z różnymi problemami. W innych krajach, gdzie technologie IT istnieją nieco dłużej, programiści są bardziej zróżnicowani wiekiem, płcią, także przynależnością etniczną, a przez to mniej pewnie swojej sytuacji.

W korpo widzę programistów koło 60-tki i nie trzęsą portkami. Programistek w tym wieku nie widziałem, ale te np 30-letnie też nie żyją w stresie.

Udało im się wynegocjować dość korzystne warunki tych zwolnień, np wysokie odprawy, możliwość odejścia na wcześniejszą emeryturę dla starszych pracowników, płacenie pensji jeszcze przez kilka miesięcy po zwolnieniu.

Gdy Sabre masowo zwalniało to płaciło za cały okres wypowiedzenia (przy umowie na czas nieokreślony) bądź do końca trwania umowy. Ja niestety byłem jeszcze na okresie próbnym, który mi się w dodatku kończył, więc dostałem kasę za jeden miesiąc, ale niektórzy dostawali kasę np za 6 miesięcy i nie musieli już w ogóle przychodzić do Sabre pracować.

Samo masowe zwolnienie to nie problem, bo rynek jest nadal bardzo chłonny. Same płace w IT też są bardzo wysokie - gdyby poddać je publicznej dyskusji to pewnie demokratyczna większość stwierdziłaby, że programiści to burżuje zarabiający zbyt dużo. "Problem" mało zarabiających juniorów wynika z tego, iż typowy junior po prostu ma nikłe doświadczenie i zdolności do pracy w komercyjnym projekcie. Programista to nie lekarz czy prawnik, gdzie osiągnięcie uprawnień do wykonywania zawodu wiąże się z solidnymi przygotowaniami. Same skończenie studiów informatycznych niewiele daje w kwestii przygotowania do zawodu - większość przedmiotów na studiach ma się nijak do typowej pracy w korpo, przedmiotów nie trzeba zdawać na piątki (w rzeczywistości można lecieć na trójach, a czasami i na dwójach poprawianych na tróje - ja pewnego razu na UJ miałem średnią ocen poniżej 3.0), a jak ja studiowałem (około 10 lat temu) to praktyki nawet nie były obowiązkowe (i chyba do teraz nie wszędzie są, bo są tu na forum delikwenci którzy nie pracowali w ogóle na studiach, a potem się budzą z ręką w nocniku i płaczą, że nie wiedzą jak się wbić w rynek).

0
Wibowit napisał(a):

w rzeczywistości można lecieć na trójach, a czasami i na dwójach poprawianych na tróje - ja pewnego razu na UJ miałem średnią ocen poniżej 3.0

Z ciekawości: jak?? :o

a jak ja studiowałem (około 10 lat temu) to praktyki nawet nie były obowiązkowe (i chyba do teraz nie wszędzie są, bo są tu na forum delikwenci którzy nie pracowali w ogóle na studiach, a potem się budzą z ręką w nocniku i płaczą, że nie wiedzą jak się wbić w rynek).

Na UJ chyba nadal nie są, robiłem staż z gościem z informatyki UJ i mówił, że u nich niby nikt tego nie wymaga, ale wolał już coś pierwszego złapać.

Na AGH praktyki są obowiązkowe (choć tylko kilkutygodniowe), a i tak zdarzają się delikwenci, którym to nie pomaga... :)

0

A dla mnie pomysł związków zawodowych w IT nie jest obcy. Pracuje w korpo (programistycznym żeby nie było), za Odrą. W mojej firmie istnieje coś takiego jak, w tłumaczeniu na nasze, "rada zakładowa". Nie są to co prawda związki zawodowe 1:1, ale ma podobne zastosowania, i zasiadają w niej wyłącznie pracownicy, których celem jest utrzymywanie poprawnych relacji pomiędzy pracodawcą a pracobiorcą. Ma to swoje plusy i rzadziej minusy. Przykłady ich zastosowań to:

*Kiedy zatrudnia się cudzoziemiec, jego umowa jest sprawdzana pod kątem tego, czy nie zawiera jakiś dumpingowych stawek, i czy pasuje do widełek na dane stanowisko, jakie otrzymują pozostali pracownicy.

*Stanowią gremium odwoławcze w sporach na linii pracownik - pracodawca, i całe szczęśćie, mają większą siłę przebicia niż 1 szara myszka pracownik.

*Negocjują podwyżki z pracodawcą, i to całkeim skutecznie. W tym samym czasie oddziały hinduskie mojej firmy nie otrzymały bądź otrzymały prawie zerowe podwyżki, przy rekordowym roku firmy, jednocześnie oddział niemiecki po takiej propozycji, i półrocznym sporze szefostwa z ową właśnie radą zakładową, zatwierdził sowite podwyżki.

Temat jest jednak dość skomplikowany. W Polsce, gdzie IT to "eldorado" a super programiści otrzymują >5 krotność średniej krajowej, może taki dziki kapitalizm się sprawdza i nie ma rzeczywiśćie o co walczyć. Ale dla pracowników na zachodzie, który jest ciągle zagrożony przez tanią siłę roboczą (już nawet z Polski, ale z Ukrainy, Rosji, Indii itd), a pensja programisty to tak naprwadę pensja średniego inżyniera (i nic więcej), takie mechanizmy obronne dla siły roboczej mają jakiś tam sens.

0

*Negocjują podwyżki z pracodawcą, i to całkeim skutecznie. W tym samym czasie oddziały hinduskie mojej firmy nie otrzymały bądź otrzymały prawie zerowe podwyżki, przy rekordowym roku firmy, jednocześnie oddział niemiecki po takiej propozycji, i półrocznym sporze szefostwa z ową właśnie radą zakładową, zatwierdził sowite podwyżki.

Najskuteczniejszą metodą na osiągnięcie podwyżki jest zmiana pracy. Można też być kontraktorem i negocjować stawkę przy każdym odnowieniu kontraktu. Siedzenie na etacie w jednej firmie na jednym stanowisku to wygoda, która jak się można spodziewać, nie przynosi obfitych nagród.

Temat jest jednak dość skomplikowany. W Polsce, gdzie IT to "eldorado" a super programiści otrzymują >5 krotność średniej krajowej, może taki dziki kapitalizm się sprawdza i nie ma rzeczywiśćie o co walczyć. Ale dla pracowników na zachodzie, który jest ciągle zagrożony przez tanią siłę roboczą (już nawet z Polski, ale z Ukrainy, Rosji, Indii itd), a pensja programisty to tak naprwadę pensja średniego inżyniera (i nic więcej), takie mechanizmy obronne dla siły roboczej mają jakiś tam sens.

Jak już napisałem, w świecie IT przeniesienie projektu z kraju do kraju to często nie jest duży problem dla międzynarodowego korpo. Stąd garstka kolesi w uzwiązkowionym kraju będzie sobie walczyć o benefity, a tymczasem pracodawca będzie przenosił kolejne projekty do krajów, gdzie zatrudnianie programistów się mu bardziej opłaca.

1
Wibowit napisał(a):

Najskuteczniejszą metodą na osiągnięcie podwyżki jest zmiana pracy. Można też być kontraktorem i negocjować stawkę przy każdym odnowieniu kontraktu. Siedzenie na etacie w jednej firmie
na jednym stanowisku to wygoda, która jak się można spodziewać, nie przynosi obfitych nagród.

Zgadzam się w 100%, ale ja pisałęm o podwyżkach wewnątrz tej samej firmy. Nie wszyscy pracownicy ( z różnych przyczyn ) migrują z firmy do firmy co rok, dwa. A niestety słabo pijarowo wygląda, gdy firma chwali się rekordowym rokiem, a pracownicy mają z tego 0.

Jak już napisałem, w świecie IT przeniesienie projektu z kraju do kraju to często nie jest duży problem dla międzynarodowego korpo. Stąd garstka kolesi w uzwiązkowionym kraju będzie sobie walczyć o benefity, a tymczasem pracodawca będzie przenosił kolejne projekty do krajów, gdzie zatrudnianie programistów się mu bardziej opłaca.

Tak rzeczywiśćie było, ale zaczęło się mścić takie podejście "januszowo-kosztowe". Czasem jak za bardzo doisz tą twoją jedyną krowę, to zdechnie z wyczerpania. Przykład z mojej firmy jest mniej więcej taki - w latach 2000 do 2015 przenoszone było wszystko co się da do Indii. Dziś ta sama firma, zatrzymała zatrudnianie hindusów, i zatrudnia coraz więcej ludzi w Europie i Stanach. Również CEO firmy oficjalnie się wypowiedział, że taka będzie teraz polityka firmy na najbliższe lata, mimo, iż struktura kosztów dla UE i USA jest niekonkurencyjna w porównaniu do Indii. Czemu tak się dzieje?

  1. Jakość i różnice kulturowe. Ludzie w Indiach, pracujący na stanowiskach klepacza po ichniejszych bootcampach są nietrenowalni na cokolwiek innego, na jakiekolwiek "thinking outside the box".
  2. Coraz większy jest nacisk na kontakt z klientem. W Europie i USA są głównie architekci, analitycy i sprzedawcy, którzy jeżdzą po klientach, uczestniczą i prowadzą spotkania z biznesem. Niestety tego nie przeniesiesz do kraju, gdzie edukacja leży, gościu nie zna lokalnego języka projektu (lub nawet dobrego angielskiego), a różnice kulturowe i czasowe zniszczą relacje z klientem.
  3. Rozmiary projektów - aktualnie projekty są raczej mniejsze (osobowo) niż przed 15 laty. I o ile dla klienta przeniesienie 100 osobowego developmentu i supportu 10 letniego do Indii było ogromną oszczędnością, o tyle przeniesienie 5 osobowego teamu który ma zrobić działający prototyp i się płynnie dogadać w realtime, nie ma kopletnie sensu.
0

Pracuję w HSBC i polityka firmy jest taka, że (przynajmniej mam takie wrażenie) zatrudnianie programistów w UK mocno zwolniło, a w Polsce, Indiach, Chinach etc mocno przyspieszyło. Ja dla przykładu pracuję nad projektem, który jest wykorzystywany głównie przez klientów zewnętrznych (w tym głównie przez inne banki). Różnica zaledwie godziny w strefie czasowej między UK, a PL pozwala na sprawną komunikację między nami, a biznesem w UK.

0
Wibowit napisał(a):

Pracuję w HSBC i polityka firmy jest taka, że (przynajmniej mam takie wrażenie) zatrudnianie programistów w UK mocno zwolniło, a w Polsce, Indiach, Chinach etc mocno przyspieszyło. Ja dla przykładu pracuję nad projektem, który jest wykorzystywany głównie przez klientów zewnętrznych (w tym głównie przez inne banki). Różnica zaledwie godziny w strefie czasowej między UK, a PL pozwala na sprawną komunikację między nami, a biznesem w UK.

W twoim wypadku możę być tak jak mówisz, nie przeczę, praca jest dla klienta wewnętrznego. bank wyoffshorowal programistów i rozdziela po świecie. A Polska jako lokacja jest i tak perfekcyjna w porównaniu do Indii.
Ja pracuje w branży konsultingowej, i projekty wraz z klientami zmieniają się średnio co 0,5 roku, z czego programowania jest może miesiąc, dwa, albo wcale, a reszta to spotkania, prezentacje, przelewanie pustego w próźne i z powrotem. I rzeczywiśćie - statystycznie jakby popatrzeć, ról czysto programistycznych jest na miejscu bardzo niewiele. Tak jak już wpomniałem, Ci co się ostali to głównie jacyś high level architekci, analitycy ,menagerowie i sprzedażowcy albo pre-sales.

1
Wibowit napisał(a):

Najskuteczniejszą metodą na osiągnięcie podwyżki jest zmiana pracy. Można też być kontraktorem i negocjować stawkę przy każdym odnowieniu kontraktu. Siedzenie na etacie w jednej firmie na jednym stanowisku to wygoda, która jak się można spodziewać, nie przynosi obfitych nagród.

Może jak komuś wszystko jedno co robi to tak. Jeśli jednak interesuje go konkretna działka i chce się w niej rozwijać, to rynek nie jest aż tak płynny, by zawsze można było sobie znaleźć innego pracodawcę. Specyfika pracy w niektórych firmach powoduje, że im dłużej się pracuje, tym wzrasta świadomość tego co się robi, wzrasta pomysłowość i poczucie własnej efektywności, i czasem szkoda tego tracić by w nowej firmie znów od początku przechodzić przez fazę ignorancji za nieco lepsze pieniądze.

0
Wibowit napisał(a):

Najskuteczniejszą metodą na osiągnięcie podwyżki jest zmiana pracy.

W sumie to jest duża zaleta dla osób doświadczonych i duża wada dla osób wchodzących na rynek. Bo bezpieczniej i taniej 'kupić' gotowego pracownika, niż wyszkolić

4

Specyfika pracy w niektórych firmach powoduje, że im dłużej się pracuje, tym wzrasta świadomość tego co się robi, wzrasta pomysłowość i poczucie własnej efektywności

Pomysłowość jest największa właśnie w momencie przyjścia do nowej pracy. Nowy pracownik ma świeżą perspektywę oraz doświadczenie i umiejętności nabyte w poprzedniej pracy, które może zastosować w nowej. Starzy pracownicy są przyzwyczajeni do statusu quo. Dłubanie w czymś co się zna od dawna jest wygodniejsze niż np rozłupywanie monolitu.

czasem szkoda tego tracić by w nowej firmie znów od początku przechodzić przez fazę ignorancji za nieco lepsze pieniądze

Wdrożenie się w nowy projekt to kwestia kilku miesięcy. Z czasem zysk z tego wdrażania maleje, bo projekty mimo wszystko ewoluują i to co klepałem 3 lata temu dzisiaj powinno wyglądać mocno inaczej. No chyba, że projekt jest praktycznie martwy (w sensie nie ma już w nim zmian) - wtedy wdrażanie się sprzed 5 lat zaowocuje i dzisiaj.

Ogólnie zmiana firmy co kilka lat jest świetnym sposobem na wymianę doświadczeń i umiejętności. Może być też tak, że firma A skorzysta z doświadczenia firmy B. Pracownicy firmy B będą szkolić pracowników firmy A (tzn pracownicy firmy B będą tymczasowo pracować w projekcie firmy A). Analogicznie, w przypadku pracowników naukowych, dobrym sposobem na wymianę wiedzy akademickiej są staże na obcych uczelniach. Jakby nie patrzeć, okresowa zmiana środowiska sprawia, że wiedza skutecznie się rozprzestrzenia, z zyskiem dla wszystkich.

W sumie to jest duża zaleta dla osób doświadczonych i duża wada dla osób wchodzących na rynek. Bo bezpieczniej i taniej 'kupić' gotowego pracownika, niż wyszkolić

Tanio i łatwo jest też zatrudnić studenta i dać mu niewymagający projekt. Staż wakacyjny nie tylko liczy się jako komercyjne doświadczenie podczas szukania pierwszej pracy, ale także sam w sobie bardzo często skutkuje zatrudnieniem w firmie, która oferowała ten staż. Jak byłem studentem to nawet koledzy którzy stosunkowo kiepsko radzili sobie z programowaniem (w tamtym czasie) bez problemu dostawali się na staż (konkretnie mowa o Comarchu, ale tyczy się to też i innych korpo), a potem zostawali w firmie.

Aktualizacja - kontynuując rozmowę z komentarzy:
U nas problemem był brak czasu na transfer wiedzy, ale w wielu projektach problemem jest słaba jakość kodu, która skutkuje niską stabilnością. Czasami firma wynajmuje bardzo drogich kontraktorów (czy tam konsultantów, chociaż to słowo ma inne znaczenie u nas i w UK), by wyciągnąć takie projekty z bagna i przeszkolić kolejnych programistów (pracujących na etat za typowe stawki) z nowej architektury. To jest strategia kryzysowa, ale pokazuje, że umiejętności i doświadczenie są w cenie, a menedżerzy nie liczą naiwnie na to, że nagle same się pojawią we właściwym czasie.

0
Wibowit napisał(a):

Specyfika pracy w niektórych firmach powoduje, że im dłużej się pracuje, tym wzrasta świadomość tego co się robi, wzrasta pomysłowość i poczucie własnej efektywności

Pomysłowość jest największa właśnie w momencie przyjścia do nowej pracy. Nowy pracownik ma świeżą perspektywę oraz doświadczenie i umiejętności nabyte w poprzedniej pracy, które może zastosować w nowej. Starzy pracownicy są przyzwyczajeni do statusu quo.

Mam nieco inne doświadczenia i to nie tylko ze swojej perspektywy ale i obserwacji innych. Na początku nowy pracownik zawsze sam się więcej uczy, niż uczy innych, niezależnie od tego na jakim sam jest poziomie. Doświadczenie które wnosi może przydać się do rozwiązania jakichś drobniejszych problemów day-to-day, ale pomysły związane z rozwiązaniem problemów najistotniejszych pochodziły zawsze od właśnie tych starych pracowników ludzi z największym doświadczeniem w projekcie. Nie wiem, może to specyfika mojej branży, ale tu nawet po roku czy dwóch nie wie się wszystkiego o projekcie.

Dłubanie w czymś co się zna od dawna jest wygodniejsze niż np rozłupywanie monolitu.
Owszem, i skuteczniejsze. Jak dla mnie to jest właśnie argument za siedzeniem w projekcie.

czasem szkoda tego tracić by w nowej firmie znów od początku przechodzić przez fazę ignorancji za nieco lepsze pieniądze

Wdrożenie się w nowy projekt to kwestia kilku miesięcy.

Wdrożyć się do tego stopnia, by samodzielnie wykonywać pewne zadania - tak.
Wdrożyć się do tego stopnia, by proponować kierunki rozwoju projektu, samemu określać zadania (nie taski w jirze, tylko bardziej Epiki) - raczej nie.

1

Z mojego punktu widzenia ktoś kto długo siedzi w projekcie dobrze zna jego aktualne ograniczenia i problemy, ale nie oznacza to, że od razu nasuwają mu się prawidłowe rozwiązania. Załóżmy, że ktoś siedzi przez 5 lat w projekcie, gdzie nie ma testów automatycznych. Wie dobrze, że by się przydały, bo ma dość powtarzania ich ręcznie. Jednak przez 5 lat prawie w ogóle nie praktykował testowania automatycznego, więc słabo mu to idzie i nawet jeśli przekona pozostałych pracowników do tego, że testy automatyczne trzeba koniecznie wprowadzić, to pokrycie projektu testami zajmie dużo czasu. Zatrudnienie kogoś kto ma duże doświadczenie z testowaniem różnej jakości kodu sprawi, że proces pokrycia kodu testami przebiegnie znacznie szybciej. Osoba taka nie tylko sama będzie mieć od razu dużą wydajność w testowaniu, ale też może szybko i skutecznie wdrożyć w to innych.

U mnie w projekcie nie ma nikogo kto znałby cały system, w sensie znania słabych i mocnych stron każdego mikroserwisu (by wiedzieć co poprawić, a co zostawić jak jest). Z tego powodu, jeśli zastanawiamy się jak zmienić system to zbieramy się w pokoju i robimy burzę mózgów. Każdy może podać swój pomysł, a każdy inny może go skrytykować. Myślę, że to lepsze rozwiązanie niż powierzanie zmian w architekturze osobie która ma największy staż w projekcie.

Ktoś nowy kto przychodzi z nowymi (w sensie: mało powszechnymi w aktualnym składzie zespołu) doświadczeniami i umiejętnościami już je zna, więc nie musi się ich uczyć, a po prostu może od razu efektywnie je wdrażać. O tym już pisałem z resztą. Taki ktoś nie musi znać całego systemu wzdłuż i wszerz by wprowadzać w nim zmiany. Może wprowadzać zmiany w module/ mikroserwisie A, B i C nie znając dogłębnie modułów/ mikroserwisów D, E, F, G i H. Długi staż zresztą nie jest gwarancją poznania dogłębnie wszystkiego - ja jestem najdłużej w projekcie (z obecnego składu), ale znaczącą część systemu słabo znam, a w niektórych mikroserwisach w ogóle nie byłem (chociaż wiem co robią, bo są opisane na diagramach z architekturą systemu).

Oprócz zmian związanych wprost z biznesowymi założeniami projektu (czyli chodzi tu przede wszystkim o integrację z zewnętrznymi usługami, bądź dostarczonymi od współpracujących firm bibliotekami) bardzo dużo pracy jest związanych z infrastrukturą - automatyzacja tworzenia środowisk testowych, przeprowadzanie testów na nich, przyspieszenie release'ów (tzn jak największa automatyzacja i jak najmniejsze przestoje), przyspieszanie rollbacka, itd Może być też tak, że np ktoś chce wdrożyć Apache Spark, Apache Kafka, etc do swojego projektu i by przyspieszyć wdrożenie może poszukać przy następnej rekrutacji nowego programisty kandydata, który zna to oprogramowanie.

0

Na początku nowy pracownik zawsze sam się więcej uczy, niż uczy innych, niezależnie od tego na jakim sam jest poziomie.

Niby z tym się zgadzam - każdy jest juniorem, jak wchodzi do nowego projektu. Ale z drugiej strony:

pomysły związane z rozwiązaniem problemów najistotniejszych pochodziły zawsze od właśnie tych starych pracowników ludzi z największym doświadczeniem w projekcie.

Może dlatego, że starzy pracownicy o "problemach naistotniejszych" mówią zwykle slangiem? Jeśli na spotkaniach starzy pracownicy mówią coś w stylu "ale się porypało w DPO (gdzie DPO to jakiś wymyślony projektowy skrót), bo mieliśmy robić popping i locking w DynamicBuilder (gdzie Dynamic Builder to jakaś tam klasa w projekcie, której może już nawet nie być, bo została zmieniona na DynamicCreator, ale zespół i tak używa starej nazwy w rozmowach) bo Frajer pisał, że hobbici nie działają (gdzie Frajer to nazwisko gościa odpowiedzialnego za coś, a hobbici to jakaś kolejna funkcjonalność,".

Ja na takich spotkaniach po prostu się wyłączałem, bo nie miałem pojęcia o czym mówią. A ciężko się dopytywać o każde słowo "co to jest DPO?", "do czego służy klasa X o której mówicie?", "kto to jest Frajer?".

Jak dla mnie po wprowadzeniu nowego pracownika powinno się robić jakiś on boarding i przesiedzieć z nowym pracownikiem z pół dnia i wytłumaczyć cały najważniejszy projektowy slang (który często nie ma nic wspólnego z kodem! Bo tym slangiem może być nazwisko jakiegoś człowieka czy inne rzeczy, które zespół wie, a nowicjusz jeszcze nie), oraz wytłumaczyć najważniejsze aktualne problemy, którym zajmuje się aktualnie zespół i czemu akurat tymi się zajmuje (z czego wynika ich trudność).

Jakby robiono coś takiego, to może by się okazało, że osoba, która do tej pory była cicha, jednak ma coś do powiedzenia w kwestii projektu. Jeśli nie ma czegoś takiego, to pewnie, że łatwiej zrobić jakiś prosty refactor jednego z modułów (rozwiązania drobniejszych problemów day-to-day,) a niech starzy programiści gadają sobie tym wykluczającym nowicjuszy slangiem, niech rzucają imionami, nazwiskami, skrótami, źle dobranymi nazwami klas itp.

No i osoba, która wchodzi do projektu, nawet nie znając go za bardzo, może mieć pewien wgląd, inne podejście do sprawy i może dostrzec coś, czego nie dostrzegają inni, którzy się w projekcie zasiedzieli i nawet nie mają czasu ani ochoty myśleć nad szerszymi rozwiązaniami, tylko głębią dół głębiej. Ignorowanie takiej osoby ze świeżym podejściem (tylko dlatego, że nie zna slangu ani wszystkich szczegółów projektu) nie jest mądre.

No i to co @Wibowit napisał - ktoś z zewnątrz może mieć też swoje doświadczenia (choćby testowanie) i to, co jest dla zespołu trudne, dla nowicjusza będzie pestką.

0
LukeJL napisał(a):

pomysły związane z rozwiązaniem problemów najistotniejszych pochodziły zawsze od właśnie tych starych pracowników ludzi z największym doświadczeniem w projekcie.

Może dlatego, że starzy pracownicy o "problemach naistotniejszych" mówią zwykle slangiem? Jeśli na spotkaniach starzy pracownicy mówią coś w stylu "ale się porypało w DPO (gdzie DPO to jakiś wymyślony projektowy skrót), bo mieliśmy robić popping i locking w DynamicBuilder (gdzie Dynamic Builder to jakaś tam klasa w projekcie, której może już nawet nie być, bo została zmieniona na DynamicCreator, ale zespół i tak używa starej nazwy w rozmowach) bo Frajer pisał, że hobbici nie działają (gdzie Frajer to nazwisko gościa odpowiedzialnego za coś, a hobbici to jakaś kolejna funkcjonalność,".

To nie jest kwestia nieznajomości slangu, tylko rzeczywistego braku wiedzy. Oczywiście slang też co nieco utrudnia, ale nawet jeśli go poznać, to niewiele to zmieni. I zazwyczaj chodzi o problemy nie programistyczne, a inżynierskie, czyli nie jak coś zakodować, tylko jak zaprojektować by były spełnione wszystkie warunki, których nowicjusz nie jest nawet świadom. To są problemy w który abstrahuje się już od kodu, czy nawet języka programowania. W warstwie kodu problemy oczywiście też się pojawią i nowy może się czasem popisać rozwiązując je, ale nie zmienia to faktu że są drugorzędne.

Ja na takich spotkaniach po prostu się wyłączałem, bo nie miałem pojęcia o czym mówią. A ciężko się dopytywać o każde słowo "co to jest DPO?", "do czego służy klasa X o której mówicie?", "kto to jest Frajer?".

Jak dla mnie po wprowadzeniu nowego pracownika powinno się robić jakiś on boarding i przesiedzieć z nowym pracownikiem z pół dnia i wytłumaczyć cały najważniejszy projektowy slang (który często nie ma nic wspólnego z kodem!

Ależ robi się onboardingi, czasem kilkudniowe, i po takim odboardingu nowy jest co najwyżej gotów nie wybiec z płaczem z firmy i zaczyna zdawać sobie sprawę jak niewiele wie.

Ignorowanie takiej osoby ze świeżym podejściem (tylko dlatego, że nie zna slangu ani wszystkich szczegółów projektu) nie jest mądre.

To nie jest kwestia ignorowania. Takie osoby są nawet zachęcane do dzielenia się pomysłami, ale rzadko kiedy będą w stanie coś istotnego wnieść. To trochę tak jakbyś teraz pojechał do NASA, w 3 dni zrobiliby ci wykład ze slangu, a potem miałbyś ze swoim "świeżym podejściem" pomóc w rozwiązaniu problemu wyznaczania optymalnej trajektorii lotu rakiety.

1

To nie jest kwestia ignorowania. Takie osoby są nawet zachęcane do dzielenia się pomysłami, ale rzadko kiedy będą w stanie coś istotnego wnieść. To trochę tak jakbyś teraz pojechał do NASA, w 3 dni zrobiliby ci wykład ze slangu, a potem miałbyś ze swoim "świeżym podejściem" pomóc w rozwiązaniu problemu wyznaczania optymalnej trajektorii lotu rakiety.

Kto poradzi sobie lepiej w wyznaczaniu trajektorii lotu rakiety w NASA: ktoś kto robił to już 10x w poprzednich firmach czy ktoś kto siedział w NASA 10 lat, ale nie wyznaczył jeszcze żadnej trajektorii lotu?

0
Wibowit napisał(a):

Z mojego punktu widzenia ktoś kto długo siedzi w projekcie dobrze zna jego aktualne ograniczenia i problemy, ale nie oznacza to, że od razu nasuwają mu się prawidłowe rozwiązania. Załóżmy, że ktoś siedzi przez 5 lat w projekcie, gdzie nie ma testów automatycznych. Wie dobrze, że by się przydały, bo ma dość powtarzania ich ręcznie. Jednak przez 5 lat prawie w ogóle nie praktykował testowania automatycznego, więc słabo mu to idzie i nawet jeśli przekona pozostałych pracowników do tego, że testy automatyczne trzeba koniecznie wprowadzić, to pokrycie projektu testami zajmie dużo czasu. Zatrudnienie kogoś kto ma duże doświadczenie z testowaniem różnej jakości kodu sprawi, że proces pokrycia kodu testami przebiegnie znacznie szybciej. Osoba taka nie tylko sama będzie mieć od razu dużą wydajność w testowaniu, ale też może szybko i skutecznie wdrożyć w to innych.

Oczywiście, ale to dotyczy przypadków, gdy zna się swój mankament i wie dokładnie kogo potrzebuje. Moje zespoły też tak robiły, znajdowały gości "od czegoś", i ten gość uczył resztę zespołu. Ale o ile zostawał guru w kwestii A, to wciąż był świeżakiem w kwestiach B,C,D... powiedzmy H :). A tam już inni go przeskakiwali wiedzą o 3 długości.

U mnie w projekcie nie ma nikogo kto znałby cały system, w sensie znania słabych i mocnych stron każdego mikroserwisu (by wiedzieć co poprawić, a co zostawić jak jest). Z tego powodu, jeśli zastanawiamy się jak zmienić system to zbieramy się w pokoju i robimy burzę mózgów. Każdy może podać swój pomysł, a każdy inny może go skrytykować. Myślę, że to lepsze rozwiązanie niż powierzanie zmian w architekturze osobie która ma największy staż w projekcie.

No tak, i właśnie na podstawie takich sytuacji widzę, że najlepsze pomysły mają właśnie ci najbardziej doświadczeni.

0
Wibowit napisał(a):

To nie jest kwestia ignorowania. Takie osoby są nawet zachęcane do dzielenia się pomysłami, ale rzadko kiedy będą w stanie coś istotnego wnieść. To trochę tak jakbyś teraz pojechał do NASA, w 3 dni zrobiliby ci wykład ze slangu, a potem miałbyś ze swoim "świeżym podejściem" pomóc w rozwiązaniu problemu wyznaczania optymalnej trajektorii lotu rakiety.

Kto poradzi sobie lepiej w wyznaczaniu trajektorii lotu rakiety w NASA: ktoś kto robił to już 10x w poprzednich firmach czy ktoś kto siedział w NASA 10 lat, ale nie wyznaczył jeszcze żadnej trajektorii lotu?

Jeśli jest zespół od wyznaczania trajektorii lotu, i przyjmują nowego gościa to najczęściej jest tak, że większość ludzi w tym zespole zjadła zęby na wyznaczaniu trajektorii, a dla niego jest to nowina.

1

Myślę, że to jednak jest bardziej problem człowieka, a nie sytuacji w jakiej się znajduje. Jest typ ludzi co będzie zawsze kombinował co jakoś usprawnić, nie ważne czy siedzi w projekcie 10 lat czy 10 dni, a są ludzie którzy jak im powiesz zeby to robili to będą, nawet jeśli całkowicie nie ma to sensu.

0

Oczywiście, ale to dotyczy przypadków, gdy zna się swój mankament i wie dokładnie kogo potrzebuje. Moje zespoły też tak robiły, znajdowały gości "od czegoś", i ten gość uczył resztę zespołu. Ale o ile zostawał guru w kwestii A, to wciąż był świeżakiem w kwestiach B,C,D... powiedzmy H :). A tam już inni go przeskakiwali wiedzą o 3 długości.

W wymianie wiedzy i doświadczenia nie chodzi o wyłonienie guru od wszystkiego. Chodzi o to, że współpraca z człowiekiem który ma już doświadczenie z tematem jest bardziej efektywna niż nauka na własnych błędach.

No tak, i właśnie na podstawie takich sytuacji widzę, że najlepsze pomysły mają właśnie ci najbardziej doświadczeni.

Ja jakoś nie odczuwam, by ktoś mający pół roku doświadczenia w projekcie miał znacznie gorsze pomysły od kogoś kto siedzi 3 lata jeśli chodzi o wprowadzanie zupełnie nowych rzeczy do projektu. Nie wszystkie zmiany są powolną ewolucją.

Jeśli jest zespół od wyznaczania trajektorii lotu, i przyjmują nowego gościa to najczęściej jest tak, że większość ludzi w tym zespole zjadła zęby na wyznaczaniu trajektorii, a dla niego jest to nowina.

W takim razie chyba nie dotarło jeszcze do ciebie o czym mowa w wątku. Mowa jest nie o przyjmowaniu żółtodziobów, którzy na niczym się nie znają tylko o przyjmowaniu ludzi z doświadczeniem i umiejętnościami, których aktualnie brakuje w projekcie. Juniorem nie jest się całe życie. Ludzie mają różnorodne doświadczenie i warto się nim dzielić.

0
Wibowit napisał(a):

No tak, i właśnie na podstawie takich sytuacji widzę, że najlepsze pomysły mają właśnie ci najbardziej doświadczeni.

Ja jakoś nie odczuwam, by ktoś mający pół roku doświadczenia w projekcie miał znacznie gorsze pomysły od kogoś kto siedzi 3 lata jeśli chodzi o wprowadzanie zupełnie nowych rzeczy do projektu. Nie wszystkie zmiany są powolną ewolucją.

Czasem może mieć dobre pomysły, tak jak każdy inny. Problem z tym, że pomysł to dopiero 5% sukcesu, potem dochodzi jakieś 60% właściwego planu i reszta realizacji. Pomysł może mieć co najwyżej jakiś potencjał, ale dopiero plan daje jakieś szanse rozwiązania problemu.

Dam ci przykład. Jeszcze na rozmowie wstępnej do obecnego zespołu rzuciłem alternatywny pomysł na pozyskiwanie pewnych informacji z wysoką dokładnością, względem tego jak odbywało się to dotychczas. Szef, z którym rozmawiałem, człowiek o dużej wiedzy i doświadczeniu, wyjaśnił mi dlaczego ten pomysł się nie sprawdzi, podając konkretne argumenty, z którymi musiałem się zgodzić. Teraz, po ok 1.5 roku słyszę, że zastosowali ten pomysł i faktycznie przyniósł poprawę uzyskanych informacji. Czy zatem szef mylił się w swojej ocenie 1,5 roku temu? Nie, argumenty wciąż pozostawały w mocy, mój pomysł nie nadawałby się jako metoda mogąca zastąpić istniejącą, mógł natomiast przynieść korzyść w pewnych konkretnych sytuacjach, w połączeniu z innymi narzędziami, i dopiero po odkryciu że dotychczasowa metoda nie była w tych sytuacjach skuteczna. Nie przypuszczam też bym to ja nagle otworzył im oczy na taki pomysł, sądzę, że byli świadomi takiej możliwości, tylko że sukces wymagał właśnie grubszej analizy, której ja jako świeżak i tak bym nie przeprowadził.

Jeśli jest zespół od wyznaczania trajektorii lotu, i przyjmują nowego gościa to najczęściej jest tak, że większość ludzi w tym zespole zjadła zęby na wyznaczaniu trajektorii, a dla niego jest to nowina.

W takim razie chyba nie dotarło jeszcze do ciebie o czym mowa w wątku. Mowa jest nie o przyjmowaniu żółtodziobów, którzy na niczym się nie znają tylko o przyjmowaniu ludzi z doświadczeniem i umiejętnościami, których aktualnie brakuje w projekcie.

W wątku to akurat jest mowa o związkach zawodowych, a potem zaczęła być mowa o tym czy warto siedzieć dłużej w projekcie :) Ja nie mówię o przyjmowaniu żółtodziobów - do tego zespołu od trajektorii lotu rakiety mógł trafić gość z doświadczeniem w inżynierii lotniczej, ale akurat nigdy miał do czynienia ze specyfiką lotów kosmicznych - w próżni, bez typowej grawitacji, bez naziemnych systemów kontroli. I tak to zazwyczaj właśnie wygląda. Tymczasem ty dziwnie zakładasz, że zespół to banda ignorantów którzy nie wiedzą nic o swojej robocie, i dopiero ktoś z zewnątrz musi im ją pokazać.

0

Tymczasem ty dziwnie zakładasz, że zespół to banda ignorantów którzy nie wiedzą nic o swojej robocie, i dopiero ktoś z zewnątrz musi im ją pokazać.

O ignorancji to sam pisałeś i pewnie mierzysz mnie swoją miarą:

Specyfika pracy w niektórych firmach powoduje, że im dłużej się pracuje, tym wzrasta świadomość tego co się robi, wzrasta pomysłowość i poczucie własnej efektywności, i czasem szkoda tego tracić by w nowej firmie znów od początku przechodzić przez fazę ignorancji za nieco lepsze pieniądze.

.

Dam ci przykład. Jeszcze na rozmowie wstępnej do obecnego zespołu rzuciłem alternatywny pomysł na pozyskiwanie pewnych informacji z wysoką dokładnością, względem tego jak odbywało się to dotychczas. (...) Nie przypuszczam też bym to ja nagle otworzył im oczy na taki pomysł, sądzę, że byli świadomi takiej możliwości, tylko że sukces wymagał właśnie grubszej analizy, której ja jako świeżak i tak bym nie przeprowadził.

Czyli summa summarum, wszyscy wiedzieli o pomyśle od dawna, więc z tej opowieści nie wynika by starzy pracownicy wymyślili coś lepszego niż nowy, ani odwrotnie. O krytykowaniu pomysłów na zebraniach grupowych sam napisałem. Nowy człowiek ma nową perspektywę, ale przecież nie chodzi o to, by nowy człowiek narzucał innym rozwiązania.

To co chcę przekazać jest proste. Powiedzmy, że mamy zespół A mocny w aspekcie X, ale słaby w Y, zespół B mocny w Y, ale słaby w Z, zespół C mocny w Z, ale słaby w X. Teraz jeśli z zespołu A przejdzie jeden człowiek do zespołu C, z zespołu B jeden do A, a z zespołu C jeden do B to wszystkie zespoły szybko podreperują swoje słabe strony. To jest wymiana wiedzy i doświadczenia.

Z tego co rozumiem to chcesz przekazać, że każdy nowo-przychodzący programista jest tak samo bezużyteczny, tak? Może zlikwidujmy stopnie junior, regular, senior itd, bo i tak żaden z nich przy rekrutacji nie jest jeszcze wdrożony w projekt. Z każdą nową technologią czy podejściem do tworzenia oprogramowania eksperymentujmy samemu i uczmy się na własnych błędach, po co brać ludzi którzy mają z tym doświadczenie?

0
Wibowit napisał(a):

To co chcę przekazać jest proste. Powiedzmy, że mamy zespół A mocny w aspekcie X, ale słaby w Y, zespół B mocny w Y, ale słaby w Z, zespół C mocny w Z, ale słaby w X. Teraz jeśli z zespołu A przejdzie jeden człowiek do zespołu C, z zespołu B jeden do A, a z zespołu C jeden do B to wszystkie zespoły szybko podreperują swoje słabe strony. To jest wymiana wiedzy i doświadczenia.

Wymiany wiedzy nigdy nie kwestionowałem.

Z tego co rozumiem to chcesz przekazać, że każdy nowo-przychodzący programista jest tak samo bezużyteczny, tak?

To co chcę przekazać napisałem na samym początku: że wraz z czasem pracy w projekcie wzrasta efektywność w rozwiązywaniu problemów, a wraz z przejściem do innej firmy tą efektywność się traci. Jeśli to jest dla ciebie tożsame z tym co napisałeś powyżej, to się chyba nie dogadamy.

Może zlikwidujmy stopnie junior, regular, senior itd, bo i tak żaden z nich przy rekrutacji nie jest jeszcze wdrożony w projekt.

Nie ma co likwidować. Wystarczy przyjąć, że stopnie od danego w górę (seniora czy tam eksperta) nabywa się dopiero w danej firmie.

0
Wibowit napisał(a):

Tymczasem ty dziwnie zakładasz, że zespół to banda ignorantów którzy nie wiedzą nic o swojej robocie, i dopiero ktoś z zewnątrz musi im ją pokazać.

O ignorancji to sam pisałeś i pewnie mierzysz mnie swoją miarą:

Specyfika pracy w niektórych firmach powoduje, że im dłużej się pracuje, tym wzrasta świadomość tego co się robi, wzrasta pomysłowość i poczucie własnej efektywności, i czasem szkoda tego tracić by w nowej firmie znów od początku przechodzić przez fazę ignorancji za nieco lepsze pieniądze.

Tu pisałem o wzroście poziomu ignorancji/niewiedzy pojawiającym się przy zmianie pracy. Ty natomiast dałeś przykład sugerujący, że ludzie pracujący nad danym zagadnieniem mają poziom ignorancji wyższy w tym temacie, niż ten kto przychodzi z zewnątrz.

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