Jak CTO powinien zarządzać współpracą B2B?

W software house'ach i firmach produktowych ryzyko reklasyfikacji B2B rzadko zaczyna się od jednego wadliwego zdania w kontrakcie. Zwykle powstaje w codziennych decyzjach operacyjnych: obowiązkowej dostępności od 9 do 17, zatwierdzaniu urlopu przez managera, rozliczaniu czasu jak etatu czy wydawaniu szczegółowych poleceń co do sposobu pracy. Jak CTO powinien zarządzać współpracą B2B? Przede wszystkim traktować ją jako model współpracy wymagający spójności między umową, procesami zespołu i rzeczywistą praktyką.

Dla CTO to nie jest wyłącznie temat HR lub działu prawnego. Osoba odpowiedzialna za technologię często ustala sposób organizacji pracy, narzędzia, rytm spotkań, podział zadań i zasady dostępności. To właśnie na tym poziomie relacja biznesowa może niepostrzeżenie zacząć przypominać stosunek pracy w rozumieniu art. 22 §1 Kodeksu pracy.

Jak CTO powinien zarządzać współpracą B2B w praktyce

Punktem wyjścia jest rozróżnienie między zarządzaniem rezultatem a kierowaniem pracą konkretnej osoby. CTO ma pełne prawo określić, co zespół ma dostarczyć: zakres modułu, standard jakości, wymagania bezpieczeństwa, termin odbioru, kryteria akceptacji czy sposób integracji z produktem. Inaczej wygląda jednak narzucanie wykonawcy bieżącego sposobu wykonywania obowiązków, stałego miejsca pracy i sztywnego rozkładu dnia.

W relacji B2B naturalne jest oczekiwanie efektu i rozliczanie realizacji ustalonego zakresu. Ryzykowne staje się budowanie modelu, w którym kontraktor działa jak etatowy członek zespołu, a firma sprawuje nad nim stałe, osobiste kierownictwo. Granica nie zawsze jest oczywista. Codzienny stand-up sam w sobie nie przesądza o charakterze współpracy, szczególnie w projekcie wymagającym koordynacji. Znaczenie ma jego funkcja: czy służy synchronizacji prac nad produktem, czy jest narzędziem codziennego rozliczania obecności i wydawania poleceń.

CTO powinien zatem projektować procesy tak, aby były uzasadnione potrzebami projektu, a nie kopiowały mechanicznie modelu etatowego. W praktyce oznacza to nacisk na backlog, cele sprintu, kamienie milowe i kryteria odbioru, zamiast na ewidencję każdej godziny dostępności.

Kontrakt B2B i praktyka zespołu muszą mówić tym samym językiem

Dobrze przygotowana umowa jest potrzebna, ale nie zabezpieczy firmy, jeśli operacyjnie obowiązują zasady z nią sprzeczne. Jeśli kontrakt wskazuje na samodzielność wykonawcy, a manager codziennie zatwierdza mu nieobecności, kontroluje godziny rozpoczęcia pracy i określa sposób realizacji każdego zadania, dokument przestaje odzwierciedlać faktyczną relację.

CTO nie musi sam redagować zapisów prawnych. Powinien jednak umieć wskazać osobom odpowiedzialnym za kontrakty, jak współpraca rzeczywiście wygląda w zespole. Bez tej informacji łatwo wprowadzić formalne postanowienia, których później nikt nie stosuje.

Szczególnej uwagi wymagają zapisy oraz ustalenia dotyczące podporządkowania, czasu i miejsca świadczenia usług, zastępstwa, wynagrodzenia, sprzętu oraz nieobecności. Każdy z tych obszarów należy oceniać w kontekście całej relacji, a nie jako samodzielny test. Na przykład firmowy laptop może być uzasadniony wymaganiami bezpieczeństwa, dostępem do środowiska lub ochroną kodu. Problem pojawia się wtedy, gdy towarzyszy mu pełny zestaw cech typowych dla etatu, bez biznesowego uzasadnienia i bez przestrzeni na samodzielność wykonawcy.

Dostępność nie powinna automatycznie oznaczać czasu pracy

W IT zespoły potrzebują wspólnych okien komunikacyjnych. Wdrożenie, obsługa incydentu albo praca przy systemie krytycznym dla klienta mogą wymagać konkretnej dostępności. To realna potrzeba biznesowa, której nie należy udawać, że nie ma.

Warto jednak odróżnić uzgodnione okno współpracy od sztywnego harmonogramu pracy kontrolowanego jak w stosunku pracy. CTO może wskazać, że podczas wdrożenia wykonawca powinien być osiągalny w określonym przedziale, aby koordynować działania z zespołem. Nie musi to oznaczać codziennego rozliczania każdej minuty, obowiązku składania wniosków o wolne czy traktowania nieobecności jak urlopu pracowniczego.

Tam, gdzie projekt wymaga dyżurów lub reakcji na awarie, zasady powinny być opisane jasno: zakres odpowiedzialności, czas reakcji, sposób zgłaszania niedostępności i model rozliczenia. Precyzja ogranicza zarówno ryzyko operacyjne, jak i ryzyko pozornego podporządkowania.

Managerowie techniczni potrzebują prostych reguł

Najwięcej niespójności powstaje nie w zarządzie, lecz na poziomie team leaderów, engineering managerów i project managerów. To oni zapraszają do kanałów komunikacyjnych, ustalają rytuały zespołowe, przekazują zadania i reagują na nieobecności. Jeśli nie znają granic modelu B2B, będą zarządzać kontraktorami tak samo jak pracownikami - zwykle z przyzwyczajenia, nie ze złej woli.

Przydatna jest krótka procedura dla osób prowadzących zespoły. Powinna wyjaśniać, że komunikujemy oczekiwany rezultat, priorytety i ograniczenia projektowe, ale unikamy języka poleceń pracowniczych. Nie zatwierdzamy „urlopów” kontraktorów, lecz ustalamy wpływ ich planowanej niedostępności na harmonogram. Nie wymagamy stałej obecności bez uzasadnienia, a gdy takie uzasadnienie istnieje, dokumentujemy je w regułach współpracy.

Nie chodzi o sztuczną zmianę słownictwa ani o tworzenie fikcji. Zmiana nazwy „urlopu” na „przerwę w świadczeniu usług” nie rozwiąże problemu, jeśli firma nadal kontroluje wykonawcę jak pracownika. Procedura ma porządkować faktyczne zachowania, nie maskować ich.

Kontrola ryzyka B2B powinna być cykliczna

Współpraca z kontraktorem zmienia się w czasie. Osoba początkowo realizująca wyodrębniony projekt może po kilku miesiącach przejąć stałe obowiązki, pracować wyłącznie dla jednej firmy i zostać włączona w wszystkie rytuały zespołu. Dlatego przegląd kontraktu tylko przy podpisaniu umowy nie wystarcza.

Dobrym momentem na ponowną ocenę jest zmiana roli, przedłużenie współpracy, wejście do nowego produktu, przejęcie dyżurów albo wprowadzenie stałych godzin dostępności. CTO może połączyć taki przegląd z procesem zmian organizacyjnych: zanim manager zmieni model działania zespołu, sprawdza, czy konsekwencje dla kontraktorów są zgodne z umową i charakterem B2B.

W praktyce warto utrzymywać prosty rejestr współprac B2B. Nie musi zawierać nadmiaru danych. Wystarczy, aby wskazywał rolę, zakres usług, model rozliczenia, osobę odpowiedzialną po stronie firmy, kluczowe wymagania projektowe oraz datę ostatniego przeglądu. Dzięki temu CTO i HR widzą, gdzie relacja zmieniła się najbardziej i które kontrakty wymagają pierwszej analizy.

Jak sprawdzić umowę przed zmianą procesu

Przed wprowadzeniem nowych zasad współpracy należy zestawić trzy elementy: treść kontraktu, realny sposób pracy oraz planowaną zmianę. Pytanie nie brzmi wyłącznie: „czy zapis jest poprawny?”. Należy zapytać także, czy zespół będzie w stanie działać zgodnie z tym zapisem po wdrożeniu nowego procesu.

Przykładowo, jeśli firma chce wprowadzić obowiązkowe dyżury, stałe uczestnictwo w określonych spotkaniach i codzienny raport aktywności, należy ocenić cały pakiet zmian. Część wymagań może być uzasadniona charakterem usługi, ale ich łączne oddziaływanie może zwiększać ryzyko podporządkowania. W takiej sytuacji warto najpierw rozważyć alternatywę: rozliczanie za obsługę dyżuru, jasno określone SLA, rotacyjny harmonogram i raport z wykonanych działań zamiast kontroli samej obecności.

PipCheck może służyć jako pierwszy, uporządkowany etap takiej weryfikacji. Analiza umowy według 14 kryteriów pozwala szybko zidentyfikować zapisy wymagające uwagi, zobaczyć cytaty z dokumentu i ustalić, które obszary trzeba skonfrontować z praktyką zespołu. Raport nie zastępuje indywidualnej porady prawnej w sprawie złożonego stanu faktycznego, ale pomaga skierować uwagę tam, gdzie ryzyko jest najbardziej konkretne.

CTO nie ograniczy ryzyka B2B jednym szablonem ani jednorazowym szkoleniem. Najlepszym zabezpieczeniem jest świadomy model operacyjny: kontraktor zna zakres odpowiedzialności, firma rozlicza rezultat, managerowie wiedzą, jak komunikować wymagania, a umowa opisuje relację, która rzeczywiście istnieje. Gdy procesy zmieniają się razem z produktem i zespołem, warto równie regularnie sprawdzać, czy nie zmienił się także charakter współpracy.