Umowa B2B dla software house i ryzyko PIP
Umowa B2B dla software house jest bezpieczna wtedy, gdy programista dostarcza rezultat (moduł, integrację, etap projektu), a nie czas pracy pod kierownictwem lidera. Zespoły IT często łączą B2B z daily, sprintami i code review w narzędziach firmy, a to elementy, które inspektor pracy ocenia jako sygnały etatu.
Krótka odpowiedź
Software house może rozliczać programistów na B2B, jeśli umowa opisuje rezultat i zakres, a codzienna praktyka go nie podważa. Najlepiej chronią firmę: stawka za etap lub abonament za określony pakiet funkcji, brak stałych godzin i obowiązkowych spotkań, prawo do pracy dla innych klientów oraz możliwość wskazania zastępcy.
Ryzyko rośnie, gdy programista pracuje w jednym zespole od lat w pełnym wymiarze, ma firmową skrzynkę, zgłasza urlopy i dostaje zadania z tablicy sprintu jak pracownik.
Dlaczego firmy IT są narażone
Branża IT jest jedną z najczęściej rozliczanych na B2B. Programista, tester czy DevOps pracuje na własnej firmie, bo to wygodne podatkowo i elastyczne dla obu stron. Problem zaczyna się, gdy projekt zamienia się w stałe stanowisko: ten sam człowiek, ten sam zespół, te same godziny przez kilka lat.
W takiej sytuacji zadanie z backlogu staje się poleceniem, a code review nadzorem nad sposobem pracy. Nikt tego nie planował, ale w ticketach, kalendarzu i korespondencji wygląda to jak stosunek pracy.
Nie chodzi o rezygnację z kontraktorów. Chodzi o to, żeby umowa i praktyka opowiadały tę samą historię o usłudze. Szerszy opis przypadku znajdziesz we wpisie umowa B2B z programistą i ryzyko PIP.
- stała liczba godzin w tygodniu zapisana w umowie lub widoczna w praktyce
- obowiązkowe daily o stałej porze i raportowanie czasu pracy
- zadania przydzielane przez lidera zespołu jak polecenia służbowe
- firmowa skrzynka e-mail, podpis w stopce i wizytówki jak dla pracownika
- wyłączność wobec innych klientów bez osobnej rekompensaty
- zgłaszanie urlopów i nieobecności do project managera
Co powinno być w umowie B2B z programistą
- opis rezultatu: moduł, etap projektu lub abonament za zdefiniowany zakres, a nie „wykonywanie poleceń”
- stawka za etap, sprint lub abonament z jasnym terminem płatności, zamiast stałej kwoty niezależnej od efektu
- kryteria odbioru i limit poprawek w cenie, żeby code review nie zamieniało się w nadzór nad sposobem pracy
- swoboda w organizacji czasu, miejsca i narzędzi oraz prawo do wskazania zastępcy
- prawo do pracy dla innych klientów, z rozsądnym zakazem konkurencji
- przeniesienie autorskich praw majątkowych do kodu i zasady korzystania z bibliotek open source
- okres i zasady wypowiedzenia umowy B2B
Kod, poufność i dostęp do repozytoriów
W firmie IT umowa B2B to nie tylko kwestia PIP. Kod, który programista pisze dla klienta software house, musi trafić do firmy, a przez nią do zamawiającego. Potrzebne jest przeniesienie autorskich praw majątkowych z wymienionymi polami eksploatacji oraz zgoda na modyfikacje. Brak tych zapisów to częsty powód sporu z klientem końcowym.
Programista ma też dostęp do repozytoriów, danych klientów i środowisk produkcyjnych. Zasady poufności warto wydzielić do osobnej umowy NDA, a ograniczenia po zakończeniu współpracy ułożyć w zakazie konkurencji B2B tak, żeby nie blokował kontraktora całkowicie.
Zmianę stawki, zakresu lub terminu zapisz w aneksie do umowy B2B, a nie w wiadomości na komunikatorze.
Jak sprawdzić umowy kontraktorów IT
- Wklej umowę do oceny. Dostajesz listę zapisów, które przypominają etat, z wyjaśnieniem, dlaczego.
- Zestaw umowę z praktyką. Zaznacz, czy programista ma stałe godziny, obowiązkowe daily i firmowe narzędzia, bo to zmienia wynik oceny.
- Popraw wskazane miejsca. Zamień polecenia na opis rezultatu, ustal stawkę za etap i dopisz prawo do zastępstwa.
- Prowadź rejestr. Przy każdym współpracowniku widać poziom ryzyka, aneksy i terminy, a przypomnienia pilnują przedłużeń.
Firma z kilkunastoma stałymi kontraktorami zyskuje jedno miejsce, w którym widać, kto jest najbardziej narażony, zanim zrobi to kontrola. Kontekst prawny opisuje artykuł reforma PIP a umowy B2B, a skutki finansowe wpis kara PIP za B2B uznane za etat. Podobny przypadek zawodowy to umowa B2B dla agencji marketingowej.
Najczęstsze pytania
Czy software house może zatrudniać programistów na B2B?
Tak, to częsty model. Bezpieczny jest wtedy, gdy programista odpowiada za rezultat, sam organizuje pracę i może wskazać zastępcę. Samo słowo B2B w umowie nie chroni, gdy w praktyce pracuje jak członek zespołu pod kierownictwem lidera.
Czy daily i sprinty to sygnał etatu u programisty B2B?
Nie same w sobie. Ryzyko pojawia się, gdy obecność na daily jest obowiązkowa o stałej porze, razem z rozliczaniem godzin i zgłaszaniem urlopów. Lepiej opisać w umowie kamienie milowe i terminy dostarczenia, a udział w spotkaniach ograniczyć do potrzeb projektu.
Jak rozliczać programistę B2B, żeby nie wyglądało to jak pensja?
Najbezpieczniej za rezultat: stawka za moduł, etap projektu albo abonament za zdefiniowany zakres. Stała kwota miesięczna bez opisu rezultatu, połączona z kontrolą godzin, przypomina wynagrodzenie pracownika.
Czy mogę dać programiście B2B firmowy laptop i konto e-mail?
Sprzęt i dostęp do repozytorium zwykle są konieczne ze względów bezpieczeństwa. Ryzyko rośnie, gdy dochodzą firmowa skrzynka z podpisem zespołu, wizytówki i stałe miejsce w biurze. Zapisz świadomie, co jest narzędziem projektu, a co wygląda jak wyposażenie pracownika.
Czy mogę sprawdzić umowę z programistą przed podpisaniem?
Tak, wklej tekst umowy do demo na stronie głównej i zobacz, które zapisy przypominają etat. To lista kontrolna oparta na przepisach, a nie porada prawna.
Sprawdź umowy programistów przed podpisem
Wklej umowę do demo, zobacz, które zapisy zwiększają ryzyko, a następnie załóż konto i przygotuj poprawioną wersję.
- Sprawdź ryzyko wklejonej umowy w demo, a potem przygotuj dokument w koncie.