B2B versus etat w IT - jak ocenić ryzyko

Programista pracujący wyłącznie dla jednego klienta, codziennie na jego komunikatorze, w godzinach wyznaczonych przez managera i pod jego bieżącym nadzorem to częsty obraz współpracy w branży technologicznej. Właśnie dlatego temat B2B versus etat w IT nie kończy się na nazwie umowy ani na fakcie wystawiania faktur. Decyduje przede wszystkim to, jak strony ułożyły i realizują współpracę.

Dla software house'u, firmy produktowej, działu HR i kontraktora stawką jest ograniczenie ryzyka uznania relacji cywilnoprawnej za stosunek pracy. Pierwszym krokiem nie powinno być jednak przepisywanie całej umowy w ciemno. Warto ustalić, które zapisy i praktyki faktycznie zbliżają model B2B do etatu.

B2B versus etat w IT - co jest punktem odniesienia

Punktem odniesienia jest art. 22 §1 Kodeksu pracy. Przepis opisuje zatrudnienie polegające na wykonywaniu pracy określonego rodzaju na rzecz pracodawcy, pod jego kierownictwem oraz w miejscu i czasie przez niego wyznaczonym, za wynagrodzeniem. Jeżeli relacja spełnia te cechy, jej nazwa nie przesądza o charakterze współpracy.

W realiach IT żadna pojedyncza okoliczność zwykle nie daje pełnej odpowiedzi. Sam dostęp do firmowego repozytorium, udział w daily czy konieczność przestrzegania zasad bezpieczeństwa nie oznaczają automatycznie etatu. Są to często uzasadnione elementy realizacji projektu. Ryzyko rośnie wtedy, gdy wiele elementów układa się w stałą zależność organizacyjną i osobistą, typową dla pracownika.

W praktyce analiza powinna obejmować dwa poziomy. Pierwszy to tekst kontraktu, załączników i regulaminów. Drugi to rzeczywisty sposób wykonywania usług. Umowa może deklarować samodzielność wykonawcy, ale taki zapis będzie mało przekonujący, jeśli codzienna praktyka opiera się na poleceniach, sztywnych godzinach i stałym nadzorze.

Czym różni się współpraca B2B od etatu

W modelu B2B wykonawca działa jako niezależny przedsiębiorca. Odpowiada za organizację własnej pracy, co do zasady sam wybiera sposób wykonania usługi i ponosi ryzyko gospodarcze związane z działalnością. Klient może określić oczekiwany rezultat, standard jakości, termin, zasady odbioru czy wymagania bezpieczeństwa. Nie powinien jednak przejmować codziennego kierowania pracą w sposób charakterystyczny dla relacji pracowniczej.

Etat opiera się natomiast na podporządkowaniu. Pracodawca organizuje pracę, wyznacza jej ramy i na bieżąco kieruje pracownikiem. W zamian ponosi obowiązki właściwe dla zatrudnienia pracowniczego. W IT granica bywa trudna do uchwycenia, ponieważ praca projektowa wymaga koordynacji zespołu, wspólnych narzędzi i regularnej komunikacji.

Kluczowe jest więc pytanie nie o to, czy klient komunikuje się z kontraktorem, lecz o zakres kontroli. Ustalenie priorytetów sprintu może być elementem zarządzania projektem. Ryzykowne staje się natomiast szczegółowe decydowanie każdego dnia, kiedy, skąd i w jakiej kolejności wykonawca ma pracować, połączone z brakiem realnej swobody działania.

Miejsce i czas wykonywania usług

Zapis o dostępności w określonym przedziale godzin nie zawsze jest wadliwy. Współpraca zespołowa może wymagać kilku godzin wspólnej dostępności, zwłaszcza przy obsłudze systemów krytycznych lub pracy z klientem zagranicznym. Problem pojawia się, gdy umowa ustanawia pełny, sztywny harmonogram pracy, obowiązkową obecność przez osiem godzin dziennie oraz kontrolę spóźnień, bez związku z zakresem usług albo rezultatem.

Bezpieczniej opisywać uzasadnione okna komunikacyjne, terminy realizacji i zasady reagowania na incydenty niż kopiować konstrukcje właściwe dla regulaminu pracy. Taki zapis powinien odpowiadać rzeczywistej potrzebie operacyjnej, a nie tylko zmieniać nazwy etatowych obowiązków.

Kierownictwo i bieżące polecenia

Klient ma prawo oczekiwać wykonania usług zgodnie z umową. Może zgłaszać błędy, zmieniać priorytety biznesowe, akceptować rezultaty i przekazywać wymagania projektowe. To nie jest samo w sobie kierownictwo pracodawcy.

Ryzyko zwiększają sformułowania zobowiązujące wykonawcę do wykonywania wszelkich poleceń przełożonych, podporządkowania regulaminowi pracy albo raportowania obecności. Warto też zweryfikować, czy role takie jak team leader lub project manager występują w umowie jako osoby koordynujące projekt, czy jako przełożeni wydający wiążące dyspozycje dotyczące każdego aspektu pracy.

Osobiste świadczenie usług

W relacji pracowniczej osobiste wykonywanie pracy jest zasadą. W B2B możliwość posłużenia się zastępcą lub współpracownikiem może wspierać obraz niezależności, ale nie jest mechanizmem, który wystarczy wpisać do umowy. Zastępstwo musi być skonstruowane rozsądnie, z uwzględnieniem poufności, kompetencji, dostępu do systemów i bezpieczeństwa projektu.

Całkowity zakaz zastępstwa połączony z silnym nadzorem nad konkretną osobą może podnosić ryzyko. Z drugiej strony pozorna klauzula zastępstwa, której strony nigdy nie mogłyby zastosować w praktyce, nie rozwiązuje problemu. Liczy się spójność kontraktu z organizacją współpracy.

Zapisy, które wymagają szczególnej kontroli

W umowach IT warto sprawdzać nie tylko główną treść kontraktu, ale też załączniki, polityki klienta i wzory komunikacji operacyjnej. Często to właśnie tam znajdują się sformułowania, które przesuwają relację w stronę etatu.

Szczególnej uwagi wymagają między innymi obowiązek pracy w ściśle określonych godzinach, konieczność uzyskiwania zgody na każdą nieobecność, odniesienia do urlopu, nakaz wykonywania poleceń służbowych czy przypisanie wykonawcy do stanowiska w strukturze organizacyjnej klienta. Ryzykowne może być także rozliczanie wyłącznie czasu obecności, jeśli umowa nie opisuje zakresu usług, odpowiedzialności, rezultatów ani samodzielności wykonawcy.

Nie oznacza to, że każda z tych klauzul przesądza o reklasyfikacji. Na przykład ewidencja godzin może służyć rozliczeniu usługi lub wymaganiom projektu. Istotne jest jej znaczenie w całym modelu współpracy. Czy stanowi jedynie podstawę faktury, czy jest narzędziem kontroli pracownika? Czy wykonawca ma swobodę organizacji, czy musi uzasadniać każdą przerwę jak osoba zatrudniona na etacie?

Warto też odróżnić regulacje konieczne od pozornie wygodnych. Obowiązki dotyczące ochrony danych, poufności, bezpieczeństwa informacji i procedur dostępu do środowisk klienta są w IT naturalne. Nie powinny być automatycznie traktowane jako cecha podporządkowania. Trzeba natomiast uważać, aby pod ich nazwą nie wprowadzać pełnego systemu zarządzania codzienną pracą kontraktora.

Jak przeprowadzić uporządkowaną ocenę umowy

Najskuteczniejsza analiza nie polega na szukaniu jednego „zakazanego” zdania. Wymaga oceny zestawu kryteriów oraz cytatów osadzonych w konkretnym kontrakcie. Praktyczny proces można podzielić na cztery etapy:

• zgromadzenie aktualnej umowy, aneksów oraz dokumentów, do których kontrakt odsyła;
• identyfikację zapisów dotyczących czasu, miejsca, nadzoru, osobistego świadczenia, wynagrodzenia i organizacji pracy;
• porównanie tych zapisów z realnym modelem współpracy zespołu;
• ustalenie, które punkty wymagają korekty, doprecyzowania albo zmiany praktyki operacyjnej.

W firmie zatrudniającej wielu kontraktorów warto analizować nie tylko pojedyncze umowy. Takiego samego przeglądu wymagają wzory kontraktów, procedury onboardingu, sposób raportowania i komunikaty wysyłane przez managerów. Dobrze skonstruowana umowa nie ograniczy ryzyka, jeżeli onboarding informuje kontraktora o godzinach pracy, zasadach „wnioskowania o urlop” i obowiązkowej dyspozycyjności identycznej jak w przypadku pracowników.

PipCheck może przyspieszyć pierwszy etap selekcji problemów. Narzędzie analizuje PDF umowy pod kątem 14 kryteriów związanych z ryzykiem reklasyfikacji, wskazuje cytaty i porządkuje obszary wymagające uwagi. Darmowy screening pozwala ocenić, czy dokument wymaga głębszego przeglądu, a pełny raport daje materiał do dalszych decyzji kontraktowych lub konsultacji prawnej.

Korekta umowy nie może być wyłącznie redakcyjna

Najczęstszym błędem jest zastępowanie słowa „pracownik” słowem „wykonawca” bez zmiany pozostałych mechanizmów. Równie nieskuteczne jest dodanie ogólnej deklaracji, że strony nie zamierzają zawrzeć umowy o pracę. Taka deklaracja może mieć znaczenie interpretacyjne, ale nie usuwa cech stosunku pracy, jeśli wynikają one z pozostałych postanowień i praktyki.

Korekta powinna odpowiadać realnemu modelowi usług. Jeżeli projekt rzeczywiście wymaga dyżurów, warto opisać ich zakres, cel i sposób rozliczenia. Jeżeli dostępność w określonych godzinach jest konieczna dla współpracy z zespołem, lepiej określić ją jako uzgodnione okno komunikacyjne niż jako harmonogram pracy. Jeżeli klient potrzebuje kontroli jakości, umowa powinna mówić o kryteriach odbioru i odpowiedzialności za rezultat, a nie o codziennym nadzorowaniu aktywności.

Nie każda współpraca B2B da się ukształtować identycznie. Inaczej wygląda kontrakt specjalisty DevOps obsługującego incydenty, inaczej współpraca UX designera realizującego określony zakres, a jeszcze inaczej długoterminowe wsparcie zespołu produktowego. Celem nie jest tworzenie sztucznej niezależności na papierze, lecz rzetelne dopasowanie zapisów do tego, jak usługa jest świadczona.

Dobra umowa B2B w IT nie udaje etatu pod inną nazwą. Jasno opisuje usługę, odpowiedzialność, zasady współpracy i granice organizacyjne klienta. Im wcześniej firma wychwyci zapisy niespójne z tym modelem, tym łatwiej skoryguje kontrakt oraz codzienną praktykę, zanim staną się przedmiotem kontroli.