🥇Jak znaleźć pracę z dobrą umową

Cześć, użytkownicy Habr!

Ostatnio miałem okazję uczestniczyć w wielu rozmowach kwalifikacyjnych i nawet otrzymałem oferty od kilku znanych i mniej znanych europejskich firm, ale dzisiaj nie będę opowiadał, jak przygotować się do rozwiązywania skomplikowanych zadań programistycznych ani jak najlepiej prezentować umiejętności miękkie. Dziś porozmawiamy o open source i umowach o pracę, w jakim stopniu się one pokrywają i jakie mogą wystąpić pułapki. Nic nie jest smutniejsze niż zmuszony do rezygnacji po trzech etapach rozmów kwalifikacyjnych i tygodniowym zadaniu domowym, gdy uświadamiasz sobie, że nie podpiszesz tej umowy o pracę nawet pod pistoletem. Widziałem wiele umów o pracę i nauczyłem się rozróżniać bardzo złe od złych, złe od znośnych, a znośne od dobrych. Więcej szczegółów poniżej.

Dyspozycja: W tym artykule opiszę nie tylko moje doświadczenia, ale również doświadczenia moich znajomych. Z oczywistych powodów nie będę wymieniał firm z imienia.

Wyobraźcie sobie sytuację: przez tydzień wykonujecie zadanie próbne, przechodzicie trzy etapy rozmowy kwalifikacyjnej, otrzymujecie ofertę z relokacją do zachodniej Europy za stosunkowo dobre pieniądze, jesteście gotowi wszystko rzucić i już pakujecie walizki, ale coś was niepokoi, prosicie o trochę czasu do namysłu i pytacie o szkic umowy o pracę. Dokładnie studiujecie umowę, wnikacie we wszystkie szczegóły i rozumiecie, że to przykład bardzo złej umowy, w której warunkach:

Nie macie prawa do ujawniania czegokolwiek, zupełnie. W przeciwnym razie — grozi wam duża kara.
O swoich projektach możecie zapomnieć. W przeciwnym razie — grozi wam duża kara.
Jeśli istnieje jakakolwiek więź między tym, co zrobicie/wynajdziecie po długim czasie po zatrudnieniu a tym, nad czym pracowaliście lub nawet co poznaliście/uzyskaliście doświadczenie u danego pracodawcy, to wszystkie prawa musicie mu przekazać. Nawet jeśli wiąże się to z koniecznością wyjazdu do innego kraju i rejestracji patentów oraz cesji praw. W przeciwnym razie — grozi wam duża kara.
Czeka was nadgodziny bez dodatkowego wynagrodzenia.
Warunki umowy pracodawca może zmieniać jednostronnie.

I to nie wszystko. Generalnie sprawa jest jasna — całkowicie chybiona.

Zanim to się stało, intensywnie zastanawiałem się nad klauzulą własności intelektualnej lub Paragraf o prawach własności intelektualnej w umowach o pracę w branży IT i programistów w szczególności. Pisanie wysokiej jakości kodu to często jedyna umiejętność, którą mamy i którą szlifujemy przez lata z nadzieją, że sprzedamy ją drożej, ale w pewnym momencie przychodzi zrozumienie, że umiejętność można nie tylko sprzedawać, ale także inwestować w open source, który coraz częściej nazywa się ciemną materią branży oprogramowania, gdzie obowiązują własne „prawo grawitacji” i inne „ prawa fizyki”. Udział w otwartych projektach można traktować jako rozwój osobisty i nawiązywanie kontaktów z innymi programistami, ale często także po to, aby dostrzegli nas potencjalni pracodawcy. Profil na GitHubie często potrafi powiedzieć o programiście znacznie więcej niż profil na LinkedInie, a pisanie otwartego kodu, uczestnictwo w zbiorowym przeglądzie kodu, zgłaszanie błędów i pisanie dokumentacji dla projektów z otwartym kodem staje się częścią życia najbardziej aktywnych i zdeterminowanych programistów.

Podczas uczestnictwa w różnych konferencjach IT w Europie poznałem termin IP-friendly w odniesieniu do umów o pracę. Termin ten odnosi się do takich umów, które w żaden sposób nie ograniczają pracowników w zakresie kierowania swoimi intelektualnymi wysiłkami w wolnym czasie, lub wprowadzają rozsądne ograniczenia, aby chronić pracodawcę przed konkurencją. Na przykład, warunki umowy, które mówią, że „wszystko, co zostało zrobione na sprzęcie pracodawcy i na bezpośrednie zlecenie pracodawcy, należy do pracodawcy”, są bardziej przyjazne dla IP niż „wszystko, co zostało zrobione w czasie obowiązywania umowy o pracę, bezwarunkowo należy do pracodawcy”. Jak to mówią, poczuj różnicę!

Pierwsze, które zrozumiały znaczenie wspierania projektów open source przez programistów, to Google, który pozwolił swoim pracownikom poświęcać do 20% czasu pracy na otwarte projekty. Inne wiodące firmy podchwyciły ten trend i nie pozostają w tyle. Korzyści dla firm są oczywiste, to strategia win-win, ponieważ firma zyskuje reputację hubu dla najzdolniejszych programistów, co z kolei przyciąga jeszcze więcej utalentowanych profesjonalistów. Próg wejścia do takich firm jest bardzo wysoki i wybierają do nich najlepszych z najlepszych.

Większość mniejszych firm zna nowe trendy tylko ze słyszenia i stara się wprowadzić do umowy o pracę jak najwięcej ograniczeń. Spotkałem się z takimi, nie bójmy się użyć tego słowa, sformułowaniami jak „Pracodawca jest właścicielem wszystkiego, co stworzy pracownik”. Smutny fakt, ale wielu programistów zgadza się na takie warunki z powodu braku wiedzy na temat praw własności intelektualnej lub z powodu trudnej sytuacji życiowej (tutaj nie ma czasu na analizowanie ofert). Jak można poprawić sytuację? Moim zdaniem jest kilka sposobów:

Zwiększyć świadomość pracowników branży IT na temat praw własności intelektualnej.
Propagować idee kontraktów przyjaznych IP wśród pracodawców.
Nie tylko uczestniczyć w projektach open source, ale być ewangelistami otwartego kodu.
Wspierać programistów w ich sporze z korporacjami, dążyć do tego, aby opinia publiczna była po stronie programisty, jeśli korporacja próbuje „przejąć” projekt.

W rezultacie znalazłem pracę z o wiele lepszymi warunkami umowy. Najważniejsze, to nie rzucać się na pierwszą ofertę i nadal szukać. I przyczyniać się do open source, ponieważ kulturowe dziedzictwo programisty to jego kod, a jeśli cały kod pisze dla korporacji, to jego dziedzictwo, jego widoczny i namacalny ślad na cyfrowym krajobrazie jest równy null.

P.S. Jeśli spodobał Ci się ten artykuł, zostań moim subskrybentem na Habra — mam jeszcze wiele niezrealizowanych pomysłów, o których chcę napisać, więc dowiesz się o nich jako pierwszy.

P.P.S. Artykuł ma swoją kontynuację…

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.