Poradnik dla software house B2B o ryzyku umów

Software house może mieć świetnie opisany proces delivery, dojrzały backlog i sprawne fakturowanie, a jednocześnie podpisywać umowy B2B, które w razie kontroli budzą pytania o faktyczny charakter współpracy. Ten poradnik dla software house B2B dotyczy właśnie tego punktu: nie nazwy dokumentu ani wpisu do CEIDG, lecz zapisów kontraktowych i codziennego modelu działania.

Ryzyko reklasyfikacji nie powstaje dlatego, że firma korzysta z kontraktorów. Model B2B jest legalny i potrzebny w branży IT. Problem zaczyna się wtedy, gdy relacja opisana jako usługa wygląda w praktyce jak zatrudnienie podporządkowanego pracownika - wykonywane osobiście, w miejscu i czasie wyznaczonym przez firmę, pod jej bieżącym kierownictwem. To obszar, który w kontekście art. 22 §1 Kodeksu pracy może być analizowany podczas kontroli PIP.

Zacznij od mapy współprac, nie od wzoru umowy

W wielu software house’ach obowiązuje jeden wzór kontraktu dla programistów, testerów, designerów i project managerów. To ułatwia administrację, ale nie zawsze odpowiada realiom współpracy. Inaczej działa niezależny ekspert realizujący rezultatowy zakres prac dla kilku klientów, a inaczej osoba włączona na stałe do jednego zespołu produktowego, dostępna codziennie w tych samych godzinach i raportująca do team leada.

Pierwszym krokiem powinno być uporządkowanie kontraktów według faktycznego sposobu wykonywania usług. Nie wystarczy podział na stanowiska. Warto uwzględnić długość współpracy, wyłączność lub jej brak, sposób rozliczenia, poziom samodzielności, udział w strukturze zespołu oraz zasady zastępstwa. Dzięki temu firma nie poprawia dokumentów przypadkowo, lecz ustala, które grupy kontraktów wymagają najpilniejszego przeglądu.

Szczególną uwagę wymagają współprace długoterminowe, prowadzone w pełnym wymiarze dostępności dla jednego klienta. Nie oznacza to automatycznie nieprawidłowości. Oznacza natomiast, że treść umowy i praktyka operacyjna muszą być ze sobą spójne oraz bardziej świadomie zarządzane.

Co w umowie B2B dla software house’u zwiększa ryzyko

Pojedynczy zapis rzadko przesądza o kwalifikacji relacji. Ocena opiera się na całokształcie okoliczności. Mimo to istnieją sformułowania, które często wymagają sprawdzenia, ponieważ mogą wzmacniać obraz podporządkowania charakterystycznego dla stosunku pracy.

Sztywne godziny i obowiązkowa obecność

Zapis nakazujący świadczenie usług od poniedziałku do piątku w konkretnych godzinach, w określonym biurze lub na stałym kanale komunikacyjnym, może być problematyczny. W IT dostępność bywa uzasadniona - sprint planning, kontakt z klientem, dyżury produkcyjne czy współpraca z zespołem wymagają koordynacji. Kluczowe jest jednak rozróżnienie między uzgodnioną dostępnością potrzebną do realizacji usługi a pełnym, stałym rozkładem czasu pracy narzuconym przez zamawiającego.

W praktyce warto opisywać cel organizacyjny, a nie tworzyć kalki regulaminu pracy. Jeżeli wykonawca ma uczestniczyć w konkretnych spotkaniach projektowych, lepiej wskazać tę potrzebę wprost niż zapisywać ogólny obowiązek pozostawania do dyspozycji firmy przez osiem godzin dziennie.

Bieżące polecenia zamiast ustalania zakresu usługi

W projektach agile zakres zadań naturalnie zmienia się w kolejnych sprintach. To nie oznacza, że umowa musi zawierać postanowienia o wykonywaniu każdego polecenia przełożonego. Takie słownictwo zbliża relację do modelu pracowniczego.

Bezpieczniejsza konstrukcja nie polega na unikaniu współpracy z liderem technicznym czy product ownerem. Polega na właściwym opisaniu roli: uzgadnianiu priorytetów, specyfikacji, rezultatów i zasad odbioru usług. Wykonawca może działać w ramach projektu, konsultować rozwiązania i raportować postęp, zachowując jednocześnie samodzielność co do sposobu realizacji powierzonego zakresu.

Osobiste świadczenie bez realnej możliwości zastępstwa

W branży IT klienci często oczekują pracy konkretnego specjalisty. Znajomość kodu, architektury i kontekstu biznesowego ma realną wartość. Całkowity zakaz korzystania z zastępcy może jednak być jednym z elementów analizowanych przy ocenie relacji.

Nie zawsze właściwą odpowiedzią będzie pełna, swobodna możliwość podmiany osoby bez wiedzy software house’u. To mogłoby kolidować z bezpieczeństwem, dostępami czy wymaganiami klienta końcowego. Rozwiązanie powinno uwzględniać warunki projektowe, na przykład możliwość zapewnienia zastępstwa po spełnieniu uzasadnionych wymogów kompetencyjnych i bezpieczeństwa. Chodzi o to, aby zapis odzwierciedlał relację gospodarczą, a nie bezwarunkowy obowiązek osobistego wykonywania pracy.

Urlopowy język w kontrakcie usługowym

Wnioski o urlop, zgody na nieobecność czy z góry określona płatna liczba dni wolnych to sformułowania, które warto przeanalizować. Kontraktor może oczywiście planować przerwy w dostępności i powinien koordynować je z zespołem, zwłaszcza przy krytycznych wdrożeniach. Nie musi to jednak być opisane językiem typowym dla zatrudnienia pracowniczego.

Istotne jest także rozliczenie. Miesięczny ryczałt nie stanowi sam w sobie dowodu stosunku pracy, podobnie jak rozliczenie godzinowe nie jest automatycznie błędne. Ryzyko może rosnąć, gdy stałej płatności towarzyszy pełna dyspozycyjność, kierownictwo operacyjne oraz brak odpowiedzialności za sposób realizacji usług.

Umowa to tylko połowa obrazu

Nawet najlepiej zredagowany kontrakt nie ochroni firmy, jeżeli codzienna organizacja przeczy jego treści. W kontroli znaczenie mogą mieć nie tylko dokumenty, ale również sposób komunikacji, zasady pracy w projekcie, ewidencja dostępności czy procedury zatwierdzania nieobecności.

Dlatego po przeglądzie umowy należy sprawdzić, czy praktyka zespołów jest z nią zgodna. Jeżeli kontraktorzy są formalnie samodzielni, ale manager codziennie rozdziela im pracę w trybie poleceń służbowych, wymaga obecności od 9:00 do 17:00 i zatwierdza każdą przerwę, sama korekta kilku paragrafów nie rozwiąże problemu.

To nie jest argument za rezygnacją z zarządzania projektem. Software house ma prawo oczekiwać jakości, terminowości, ochrony informacji i współpracy z zespołem. Należy jednak oddzielić zarządzanie rezultatem i koordynację kontraktową od zarządzania pracownikiem w ramach podporządkowania.

Poradnik dla software house B2B: proces przeglądu kontraktów

Najbardziej użyteczny przegląd nie polega na czytaniu umowy od deski do deski bez kryteriów. Lepiej przejść przez powtarzalny proces, który można stosować przy nowych wzorach i już trwających współpracach.

Najpierw zbierz aktualne wersje umów, aneksów oraz dokumentów, które faktycznie wpływają na zasady współpracy. Mogą to być regulaminy projektowe, procedury dostępów czy załączniki z zakresem usług. Następnie oceń, czy dokumenty regulują takie obszary jak czas i miejsce wykonywania usług, osobiste świadczenie, podporządkowanie, wynagrodzenie, nieobecności, odpowiedzialność oraz możliwość działania dla innych podmiotów.

Kolejny etap to zestawienie zapisów z praktyką. Warto zaangażować do tego nie tylko osobę administrującą kontraktami, ale też delivery managera lub osobę odpowiedzialną za HR. To oni zwykle wiedzą, jak naprawdę ustalane są godziny, kto wydaje instrukcje oraz jak wygląda dostępność kontraktorów w projekcie.

Dopiero potem ustal priorytety zmian. Nie każda umowa wymaga pełnej przebudowy. Czasem problemem jest jedno sformułowanie o poleceniach służbowych. W innym przypadku ryzyko wynika z sumy wielu elementów i potrzebna jest zmiana procedury współpracy, a nie tylko redakcja klauzuli.

Automatyczna analiza może przyspieszyć etap selekcji. PipCheck umożliwia wgranie PDF-a i wykonanie darmowego wstępnego screeningu, a pełny raport ocenia 14 kryteriów, pokazuje cytaty z umowy oraz wskazuje kierunki korekty. Taki raport nie zastępuje indywidualnej porady prawnej ani nie daje gwarancji wyniku kontroli. Pomaga natomiast ustalić, które fragmenty dokumentu warto potraktować priorytetowo, zanim firma zaangażuje dodatkowe zasoby.

Nie poprawiaj umowy pozornie

Najczęstszy błąd to kosmetyczna zmiana słów bez zmiany sensu. Zastąpienie „pracownika” „wykonawcą” nie zmienia charakteru relacji. Podobnie zapis o samodzielności będzie mało przekonujący, jeżeli w kolejnych paragrafach firma szczegółowo narzuca godziny, miejsce, polecenia i zasady nieobecności.

Drugim błędem jest kopiowanie rozwiązań z internetu lub umów innych firm. Kontrakt dla niezależnego konsultanta wdrożeniowego może nie pasować do osoby pracującej stale przy utrzymaniu produktu. Trzeci błąd to przerzucanie całego ryzyka na kontraktora poprzez deklaracje, które nie odpowiadają rzeczywistości. Dokument powinien opisywać rzeczywisty model biznesowy, a nie tworzyć pozorną ochronę.

Dobrze zarządzane B2B w software house’ie nie oznacza braku zasad. Oznacza zasady dopasowane do usługowej, niezależnej współpracy: jasno określony zakres, odpowiedzialność, mechanizm odbioru, uzasadnioną koordynację i spójność między kontraktem a projektem.

Najlepszym momentem na wykrycie ryzykownego zapisu jest chwila przed podpisaniem umowy, nie dzień kontroli. Warto potraktować przegląd kontraktów jak stały element jakości operacyjnej - tak samo praktyczny jak weryfikacja bezpieczeństwa dostępu czy porządek w dokumentacji projektu.