Jak współpracować ze specjalistami IT: umowa o pracę, B2B czy kontrakt?

Najpierw model pracy, później dokument

Wybór formy współpracy powinien wynikać z realnego sposobu wykonywania zadań. Zgodnie z Kodeksem pracy podstawowe znaczenie ma to, czy praca określonego rodzaju jest wykonywana na rzecz pracodawcy, pod jego kierownictwem oraz w miejscu i czasie przez niego wyznaczonym, za wynagrodzeniem.

Samodzielność specjalisty, ryzyko gospodarcze i sposób rozliczania rezultatów pomagają ocenić całokształt relacji, ale nie zastępują analizy ustawowych cech stosunku pracy. Samo wpisanie do dokumentu określenia „B2B” nie zmieni relacji, która w praktyce spełnia te cechy. Z drugiej strony nie każdy długoterminowy kontrakt automatycznie jest umową o pracę.

Trzy warstwy ryzyka

Decyzja powinna objąć co najmniej trzy powiązane obszary.

• charakter relacji i sposób kierowania pracą
• rozliczenia, odpowiedzialność oraz ryzyka podatkowe i ubezpieczeniowe
• własność intelektualną, poufność i bezpieczeństwo informacji

Prawa do kodu trzeba zaprojektować świadomie

Prawa majątkowe do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy co do zasady przysługują pracodawcy, chyba że umowa stanowi inaczej. W relacji B2B lub innej umowie cywilnoprawnej sama zapłata za kod nie powoduje automatycznego przejścia autorskich praw majątkowych.

Kontrakt powinien określać, czy prawa są przenoszone, czy udzielana jest licencja, oraz wyraźnie wskazywać pola eksploatacji. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności.

Oprócz kodu trzeba osobno przeanalizować dokumentację, projekty, bazy danych, materiały graficzne, know-how, komponenty open source i rezultaty podwykonawców. Szczególna reguła dotycząca pracowniczych programów komputerowych nie rozstrzyga automatycznie praw do wszystkich tych elementów.

Dokument powinien odpowiadać cyklowi współpracy

Bezpieczny model obejmuje nie tylko podpisanie umowy, lecz także zmianę roli i zakończenie współpracy.

• onboarding i nadawanie dostępów
• zasady pracy na sprzęcie i danych
• akceptację rezultatów i dokumentowanie praw
• poufność i ewentualny zakaz konkurencji
• offboarding, zwrot sprzętu, odebranie dostępów i przekazanie wiedzy

Jedna rekomendacja nie pasuje do każdego zespołu

Model odpowiedni dla niezależnego eksperta realizującego projekt nie musi pasować do osoby pracującej pod stałym kierownictwem w strukturze firmy. Warto analizować role grupami i zachować spójność pomiędzy umową, procesem HR oraz praktyką menedżerską.

Ocena powinna uwzględniać również skutki podatkowe i ubezpieczeniowe, które wymagają odrębnej analizy właściwej dla sytuacji stron.