Body Leasing w Software House, czyli jak „wypożyczać” programistów i nie stracić ich na rzecz klienta?

Artykuł dedykowany dla: Właścicieli Software House’ów, CEO agencji IT oraz Managerów sprzedaży usług B2B.

Model Body Leasingu (lub modniej: Team Augmentation) to dla wielu firm IT żyła złota. Wypożyczasz kluczowe kompetencje, klient zarządza projektem, a faktura za godziny (w formule Time & Material) jest płacona co miesiąc. Układ idealny? Tak, dopóki Twój klient nie stwierdzi: „Po co mam płacić marżę pośrednikowi, skoro świetnie dogaduję się z tym developerem bezpośrednio?”. Jeśli zarządzasz Software Housem, ten tekst jest dla Ciebie. Opowiem Ci, jak skonstruować umowę, by Twoi najlepsi ludzie nie uciekli do Twoich klientów.

Z mojej praktyki obsługi firm IT wynika, że umowy o Body Leasing są często traktowane po macoszemu. Wiele firm bierze prosty wzór umowy o świadczenie usług, zmienia nagłówek i myśli, że jest bezpieczna. Tymczasem „wypożyczanie ludzi” to specyficzny biznes, w którym największym aktywem jest człowiek – i to o niego toczy się gra w umowie.

Przeanalizowałam dziesiątki kontraktów wdrożeniowych i leasingowych. Oto 4 obszary, które musisz zabezpieczyć, jeśli prowadzisz Software House.

1. Non-Solicitation to za mało. Wprowadź mechanizm „Buy-out” (wykupu)

Standardowy zapis o zakazie konkurencji (Non-solicitation) mówi: „Klient nie może zatrudnić Twojego pracownika”. Brzmi świetnie, ale w praktyce biznesowej bywa martwy. Dlaczego? Bo jeśli Klient (często duża korporacja z USA czy Europy Zachodniej) zakocha się w kompetencjach Twojego Senior Developera, a Developer będzie chciał przejść do Klienta – znajdą sposób.

Rozwiązanie- zamiast walczyć z wiatrakami, ureguluj to biznesowo. Zamiast bezwzględnego zakazu, który rodzi konflikty, wprowadź do umowy Klauzulę Wykupu (Transfer Fee / Buy-out Fee).

Jak to działa?

• Zastrzegasz, że przejęcie pracownika jest możliwe, ale za zgodą Software House’u i po opłaceniu "opłaty rekrutacyjnej".

• Wysokość tej opłaty powinna być odstraszająca lub... satysfakcjonująca. Często stosuje się x-krotność miesięcznego wynagrodzenia dewelopera lub procent od jego rocznego zarobku brutto.

Dzięki temu zamieniasz ryzyko utraty pracownika w transakcję biznesową. Ty otrzymujesz rekompensatę za utratę zasobu i koszty rekrutacji nowego człowieka, a Klient ma czystą sytuację prawną.

2. Kto odpowiada za błędy w kodzie? Pułapka „rezultatu”

W klasycznym wdrożeniu IT (Fixed Price) odpowiadasz za to, że system działa. W Body Leasingu jest inaczej – Ty dostarczasz kompetencje i czas specjalisty, ale to Klient (jego Project Manager/CTO) mówi mu, co ma robić.

Błąd- Wiele Software House'ów godzi się na zapisy, w których ponoszą pełną odpowiedzialność za efekt końcowy prac wypożyczonego konsultanta.

Ryzyko- Klient źle zarządzi projektem, architektura "siądzie", a winą (i karami) obarczy Twojego programistę.

Jak to zapisać bezpiecznie? Musisz wyraźnie rozdzielić odpowiedzialność. W modelu Team Augmentation / Body Leasing Twoja firma powinna odpowiadać za:

• Należytą staranność przy doborze specjalistów (że mają deklarowane w CV umiejętności).

• Ich dostępność w umówionych godzinach.

• Ewentualnie za rażące błędy wynikające z niedbalstwa.

Nie powinieneś jednak odpowiadać za sukces biznesowy projektu ani za błędy koncepcyjne, jeśli programista działał pod ścisłym kierownictwem Klienta. W umowie musi znaleźć się zapis wyłączający odpowiedzialność za decyzje podejmowane przez kadrę zarządzającą Klienta.

3. Zastępstwo i „znikanie” developera

Ludzie chorują, zmieniają pracę, wypalają się. To naturalne ryzyko, ale w modelu leasingowym staje się Twoim problemem nr 1. Klient płaci za ciągłość.

Co musi być w umowie? Procedura wymiany konsultanta (Replacement Clause).

• Unikaj zapisów o „natychmiastowym” zastępstwie. Rekrutacja w IT trwa. Zapewnij sobie realny czas (np. 14–30 dni) na przedstawienie nowego kandydata o zbliżonym profilu.

• Zastrzeż, że Klient ma prawo zaakceptować lub odrzucić nowego kandydata, ale nie może robić tego bezzasadnie.

• Ustal, co dzieje się z wynagrodzeniem w okresie „luki” (zazwyczaj – nie jest naliczane, co jest fair, ale chroni Cię przed karami za przestój).

4. Łańcuszek Praw Autorskich (IP Chain)

To techniczny, ale krytyczny aspekt. W Body Leasingu kod powstaje „na bieżąco” i trafia do repozytorium Klienta. Ścieżka praw wygląda tak: Twój Programista -> Twój Software House -> Twój Klient.

Jeśli w Twojej umowie z programistą (B2B/UoP) jest luka w przeniesieniu praw, to nie możesz przenieść ich skutecznie na Klienta. A jeśli Klient to odkryje (np. przy audycie inwestorskim), będziesz mieć ogromny problem.

Wskazówka- W umowie leasingowej warto zastrzec, że prawa autorskie przechodzą na Klienta z chwilą zapłaty wynagrodzenia za dany okres rozliczeniowy. To Twoja najlepsza polisa ubezpieczeniowa na wypadek braku płatności. Klient nie płaci = nie ma praw do kodu, którego używa. To bardzo motywuje działy księgowości kontrahentów.

Podsumowanie

Body Leasing to relacja zaufania, ale...

...umowa jest na czasy, gdy tego zaufania zabraknie. Dobrze skonstruowany kontrakt Body Leasingowy to taki, który pozwala Ci skalować biznes i wysyłać ludzi do ciekawych projektów, bez strachu, że Twoja firma stanie się tylko darmową agencją rekrutacyjną dla zagranicznych korporacji.

Planujesz wdrożyć usługę Team Leasingu lub dostałeś propozycję takiej współpracy od kontrahenta? Nie kopiuj wzorów z Internetu, bo one rzadko uwzględniają specyfikę „podkradania” pracowników. Prześlij mi swój draft – sprawdzę, czy Twoje interesy są bezpieczne.

kancelaria@mecenasbogna.com