Offboarding specjalisty kontraktowego: jak przejąć wiedzę, dostępy i kod przed ostatnim dniem

Piątek, godzina 16:40. Specjalista, który przez czternaście miesięcy rozwijał moduł rozliczeń, wysyła na kanał zespołu pożegnalną wiadomość z linkiem do dokumentu „Przekazanie wiedzy – moduł billing”. Dokument ma jedenaście stron, zrzuty ekranu i listę „znanych problemów”. Wszyscy dziękują, ktoś dodaje emotkę z pucharem. W poniedziałek o 9:15 nocny proces naliczania faktur kończy się błędem, którego nie ma na liście. Okazuje się, że skrypt, który go „naprawiał” raz w miesiącu, uruchamiany był ręcznie z laptopa, który właśnie wrócił do dostawcy. Token, którym skrypt łączył się z bazą, nadal działa, bo nikt nie wiedział, że istnieje.

Ten scenariusz jest zmyślony, ale każdy jego element zna każdy, kto prowadził zespół z udziałem specjalistów zewnętrznych. Ten artykuł jest dla tech leadów, engineering managerów i HR Partnerów, którzy odpowiadają za zakończenie współpracy z kontraktorem w modelu body leasingu lub staff augmentation. Teza jest taka: offboarding kontraktora nie jest zadaniem na okres wypowiedzenia, tylko dowodem, który zbiera się przez cały kontrakt. Dokument przekazania pisany w ostatnim tygodniu jest najsłabszą formą przejęcia wiedzy, jaką znamy. Jedynym wiarygodnym sprawdzianem jest to, że zespół wykonuje pracę odchodzącej osoby, zanim ta osoba odejdzie, a ostatni dzień jest nudny.

Wiele firm uważa odwrotnie: że porządny offboarding to porządna checklista i dobrze napisany dokument. Checklista jest potrzebna, ale odpowiada na pytanie „czy wykonaliśmy czynności”, a nie „czy umiemy bez tej osoby”. To drugie pytanie jest tym, które zada Ci produkcja w pierwszy poniedziałek.

Dlaczego ostatni dzień kontraktora jest najdroższym dniem współpracy?

Bo tego dnia wiedza, która była „u kogoś”, przestaje być dostępna, a koszt jej odtworzenia ponosi ktoś inny. Panopto w raporcie Workplace Knowledge and Productivity Report z 2018 roku, opartym na badaniu YouGov przeprowadzonym wśród ponad tysiąca pracowników w USA, oszacował, że 42% wiedzy instytucjonalnej to wiedza unikalna dla konkretnej osoby, niedzielona ze współpracownikami. Badanie dotyczyło pracowników biurowych ogólnie, nie tylko IT, ale w zespołach programistycznych mechanizm jest ten sam, a często silniejszy, bo wiedza o systemie żyje w kodzie, konfiguracji i głowach, w tej kolejności malejącej czytelności.

W zespole z udziałem kontraktorów dochodzi drugi czynnik: zewnętrznych specjalistów często angażuje się właśnie do obszarów, na które zespół wewnętrzny nie ma kompetencji albo czasu. Integracja z nowym systemem płatności, migracja do chmury, automatyzacja testów, wydajność bazy danych. To obszary, w których specjalista z definicji wie więcej niż reszta zespołu. Gdy odchodzi, odchodzi z najbardziej skoncentrowaną wiedzą, jaką zespół posiadał.

Ile to kosztuje? Nie ma jednego badania, które podałoby wiarygodną liczbę dla polskich zespołów IT, więc lepiej policzyć to samemu. Szacunek ilustracyjny: jeśli następca potrzebuje sześciu tygodni zamiast dwóch, żeby samodzielnie wprowadzać zmiany w przejętym obszarze, to cztery dodatkowe tygodnie pracy seniora przy stawce z przedziału 180–260 zł netto za godzinę (skala z benchmarku ARDURA na 2026 rok) oznaczają około 29–42 tysięcy złotych netto samego czasu następcy. Do tego dochodzi czas zespołu, który odpowiada na jego pytania, i ryzyko incydentu w obszarze, którego nikt nie rozumie. Czynniki, od których zależy wynik: wielkość obszaru, jakość testów automatycznych, liczba integracji i to, czy ktokolwiek w zespole pracował z tym kodem wcześniej.

Ostatni dzień jest też najdroższy z perspektywy bezpieczeństwa. Konta, tokeny i sekrety, o których zespół nie wie, nie wygasają same. Verizon w Data Breach Investigations Report 2025 wskazał, że udział stron trzecich w naruszeniach podwoił się rok do roku, z 15% do 30%. Specjalista zewnętrzny nie jest „stroną trzecią” w sensie tego raportu, ale jego dostępy żyją na styku dwóch organizacji, a takie miejsca są najsłabiej pilnowane.

Czym offboarding kontraktora różni się od odejścia pracownika etatowego?

Na pierwszy rzut oka niczym: ktoś odchodzi, trzeba odebrać sprzęt, wyłączyć konta, przekazać obowiązki. W praktyce różnic jest co najmniej pięć i każda z nich zmienia plan.

Jest dostawca w środku. W body leasingu umowę masz z firmą, nie ze specjalistą. Wypowiedzenie, zastępstwo, zwrot sprzętu dostawcy, rozliczenie ostatniego miesiąca i potwierdzenie przeniesienia praw idą przez dostawcę. Jeśli dostawca nie wie, że Twój offboarding ma konkretny plan, nie zsynchronizuje z nim swoich działań. Standard NIST SP 800-53 (rewizja 5) ma na to osobną kontrolę, PS-7 External Personnel Security, która wymaga, żeby dostawcy zewnętrzni powiadamiali organizację o zakończeniu współpracy ich personelu, właśnie po to, by odebrać uprawnienia na czas.

Prawa do kodu nie przechodzą z mocy prawa. Pracodawca nabywa prawa do programu stworzonego przez pracownika w ramach obowiązków na podstawie art. 74 ust. 3 ustawy o prawie autorskim. Przy umowie B2B tego automatu nie ma. O tym niżej, w osobnej sekcji, bo to sprawa, którą trzeba zamknąć przed ostatnim dniem, a nie po nim.

Okres wypowiedzenia jest krótszy i wynika z umowy handlowej. Przy etacie okres wypowiedzenia określa kodeks pracy i zależy od stażu. W body leasingu zależy od umowy z dostawcą. W ARDURA wszystkie umowy można rozwiązać z 30-dniowym wypowiedzeniem, bez kar umownych. To dla klienta zaleta, bo pozwala elastycznie zmniejszać zespół, ale oznacza też, że cały offboarding musi się zmieścić w miesiącu. Warto przeczytać, co dokładnie mówi umowa; w słowniku omawiamy okres wypowiedzenia w body leasingu szerzej.

Kontraktor ma zwykle szersze uprawnienia techniczne niż równorzędny pracownik. Paradoksalnie, bo z zewnątrz wygląda to odwrotnie. Specjalista ściągnięty do „ogarnięcia infrastruktury” dostaje uprawnienia administracyjne w chmurze, bo inaczej nie da się pracować, a pracownik na tym samym stanowisku dostałby je przez lata stopniowo. Im szybciej ktoś dostał dostęp, tym gorzej ten dostęp jest udokumentowany.

Motywacja na koniec jest inna. Pracownik etatowy, który odchodzi, często zostaje w tej samej branży i mieście, i zależy mu na referencjach. Kontraktor zwykle przechodzi do kolejnego projektu u tego samego dostawcy, co działa na korzyść klienta: dostawcy zależy na tym, żeby rozstanie było czyste. To argument, żeby offboarding planować razem z dostawcą, a nie obok niego.

Kiedy naprawdę zaczyna się offboarding?

W dniu onboardingu. To nie jest metafora. Trzy rzeczy, które ustawisz w pierwszym tygodniu współpracy, decydują o tym, czy okres wypowiedzenia będzie spokojny.

Pierwsza to rejestr dostępów. Każdy dostęp nadany specjaliście zewnętrznemu powinien trafić do jednego miejsca: system, rola, kto zatwierdził, data. Nie chodzi o biurokrację, tylko o to, żeby w dniu wypowiedzenia lista do odebrania już istniała. Bez rejestru odbieranie dostępów polega na przypominaniu sobie, a pamięć zawodzi akurat przy narzędziach używanych raz w miesiącu. Jeśli prowadzicie onboarding według checklisty, a o onboardingu specjalistów zewnętrznych pisaliśmy osobno, to dopisz do niej rubrykę „wpis do rejestru” przy każdym nadawanym dostępie.

Druga to zasada drugiej osoby. Każdy obszar, nad którym pracuje kontraktor, ma w zespole wewnętrznym osobę, która przegląda jego zmiany, uczestniczy w kluczowych decyzjach i w razie potrzeby przejmie pracę. Badacze Guilherme Avelino, Leonardo Passos, Andre Hora i Marco Tulio Valente przeanalizowali w 2016 roku 133 popularne projekty na GitHubie i stwierdzili, że w 65% z nich tak zwany truck factor, czyli liczba osób, których odejście zatrzymuje projekt, wynosi 2 lub mniej. To projekty otwarte, często z setkami kontrybutorów. W zamkniętym projekcie komercyjnym, gdzie dany moduł rozwija jeden specjalista zewnętrzny, truck factor tego modułu wynosi zwykle dokładnie 1, chyba że ktoś świadomie go podnosi. Code review przez drugą osobę i programowanie w parach w krytycznych momentach to najtańsze sposoby, żeby to zrobić.

Trzecia to dokumentowanie decyzji w momencie ich podejmowania. Krótkie zapisy decyzji architektonicznych (ADR), opisy pull requestów wyjaśniające „dlaczego”, a nie tylko „co”, runbooki pisane przy pierwszym incydencie, a nie po ostatnim. Dokumentacja pisana na bieżąco kosztuje minuty, dokumentacja odtwarzana na koniec kosztuje dni i jest gorsza, bo autor nie pamięta już kontekstu.

Jeśli te trzy rzeczy działały od początku, okres wypowiedzenia służy weryfikacji, a nie ratowaniu. Jeśli nie działały, a właśnie dostałeś informację o zakończeniu współpracy, nie panikuj: reszta artykułu opisuje, jak nadrobić to w 30 dni. Ale potraktuj to jako sygnał, żeby przy kolejnym specjaliście zacząć od rejestru.

Co dokładnie trzeba przejąć: wiedzę, dostępy, kod czy coś jeszcze?

Pięć rzeczy, a nie trzy. Wiedza, dostępy i kod to oczywiste kategorie, ale dwie pozostałe gubią się najczęściej.

Kod. Wszystko, co specjalista napisał, musi być w repozytorium organizacji, scalone albo jawnie porzucone. Do tego skrypty pomocnicze, konfiguracje lokalne, notatniki z analizami danych, zapytania SQL, które odpalał ręcznie, pliki infrastruktury jako kodu, które testował u siebie. Kod „poza repozytorium” to największe źródło niespodzianek.

Wiedza. Dwa rodzaje. Wiedza jawna, którą da się spisać: jak działa moduł, jakie ma zależności, jakie są znane problemy. I wiedza ukryta, której autor często nie jest świadomy: dlaczego pewien parametr ma akurat taką wartość, który alert można zignorować w poniedziałek rano, do kogo w dziale finansów zadzwonić, gdy liczby się nie zgadzają. Ta druga jest cenniejsza i nie przechodzi przez dokumenty.

Dostępy i sekrety. Konta imienne to połowa sprawy. Druga połowa to sekrety, które specjalista znał albo utworzył: klucze API, hasła kont technicznych, tokeny w pipeline’ach, klucze SSH dodane na serwerach, urządzenia MFA przypisane do kont współdzielonych.

Artefakty i zobowiązania. Otwarte zadania, obietnice złożone innym zespołom („dorzucę wam ten endpoint w przyszłym sprincie”), zaplanowane zadania cykliczne, subskrypcje i licencje założone na jego adres e-mail, rezerwacje zasobów w chmurze, które utworzył do testów i które dalej generują koszt.

Relacje. Ludzie, z którymi specjalista miał kontakt i którzy przyzwyczaili się pisać do niego bezpośrednio: inne zespoły, dostawcy zewnętrzni, osoby biznesowe. Jeśli nikt im nie powie, do kogo pisać teraz, przez dwa tygodnie ich wiadomości będą trafiać w próżnię.

Ta piątka jest ramą dla reszty artykułu. Plan offboardingu to w gruncie rzeczy pięć list, każda z właścicielem po stronie zespołu wewnętrznego.

Jak zaplanować 30 dni wypowiedzenia tydzień po tygodniu?

Typowy błąd to traktowanie okresu wypowiedzenia jak zwykłego miesiąca pracy z dopiskiem „i przekaż wiedzę na koniec”. Specjalista realizuje zadania z backlogu do ostatniego tygodnia, a w ostatnim tygodniu pisze dokument. Efekt: najwięcej nowego, nieprzekazanego kodu powstaje dokładnie wtedy, gdy powinno go powstawać najmniej.

Lepszy podział odwraca proporcje. Pierwszy tydzień to inwentaryzacja i plan, drugi to domykanie i spisywanie, trzeci i czwarty to praca zespołu pod obserwacją. Poniższa tabela pokazuje plan dla okresu 30 dni; jeśli umowa przewiduje inny okres, przeskaluj go, zachowując zasadę, że co najmniej ostatnia trzecia część okresu to praca zespołu, a nie odchodzącego specjalisty.

Tydzień	Cel	Główne działania	Kto prowadzi	Dowód, że etap jest zamknięty
1	Inwentaryzacja	Lista obszarów, dostępów, sekretów, zadań cyklicznych i otwartych zobowiązań; wskazanie przejmującego dla każdego obszaru; ustalenia z dostawcą	Tech lead + specjalista	Pięć list z właścicielami, zatwierdzone przez tech leada
2	Domykanie	Scalenie lub porzucenie otwartych gałęzi; przeniesienie skryptów do repozytorium; zapis decyzji i runbooków; stop dla nowych zadań w obszarze	Specjalista	Zero otwartych gałęzi autorstwa specjalisty bez decyzji; runbooki przetestowane przez kogoś innego
3	Odwrócony shadowing	Przejmujący wykonują zadania z obszaru; specjalista obserwuje i odpowiada na pytania; lista luk	Przejmujący	Lista luk z terminem zamknięcia; co najmniej jedno wdrożenie przeprowadzone bez rąk specjalisty
4	Test nieobecności i odcięcie	Dni, w których specjalista jest dostępny tylko na pytania; stopniowe ograniczanie uprawnień; rotacja sekretów; formalności	Tech lead + HR Partner + dostawca	Rejestr dostępów pusty dla specjalisty; sekrety zrotowane; protokół odbioru podpisany

Dwie uwagi praktyczne. Po pierwsze, w drugim tygodniu zablokuj nowe zadania w obszarze odchodzącego specjalisty, zwłaszcza duże. Każda funkcja zaczęta w tym tygodniu zostanie skończona w pośpiechu albo przekazana w połowie, co jest gorsze niż przekazanie gotowej. Po drugie, zaplanuj okres tak, żeby ostatni dzień nie był piątkiem przed długim weekendem ani dniem wdrożenia. Ostatni dzień powinien być nudny, a nudę trzeba zaplanować.

Rola HR Partnera w tym planie jest większa, niż się wydaje. To on najczęściej pierwszy dowiaduje się o zakończeniu współpracy (od dostawcy albo od zarządu), to on pilnuje terminów formalnych i to on może zadbać o to, żeby informacja o odejściu trafiła do wszystkich, którzy z kontraktorem współpracowali. Tech lead odpowiada za merytorykę, HR Partner za to, żeby nic nie wypadło między krzesłami.

Dlaczego dokument przekazania napisany w ostatnim tygodniu prawie nic nie daje?

To najbardziej kontrowersyjna część tego artykułu, więc warto ją uzasadnić. Dokument przekazania nie jest bezwartościowy. Jest po prostu najsłabszym narzędziem z dostępnych, a w wielu zespołach jest jedynym.

Pierwszy powód: dokument opisuje to, co autor uważa za ważne, a nie to, czego czytelnik nie wie. Autor zna system tak dobrze, że nie widzi miejsc, w których ktoś inny się potknie. Pisze o architekturze, bo architektura wydaje mu się istotna, a pomija to, że certyfikat w środowisku testowym trzeba odnawiać ręcznie co 90 dni, bo dla niego to oczywistość. Luki w dokumencie są dokładnie tam, gdzie wiedza jest najbardziej ukryta.

Drugi powód: dokument jest pisany pod presją czasu przez osobę, której motywacja maleje. Nie chodzi o złą wolę. Specjalista myśli już o kolejnym projekcie, ma ostatnie zadania do skończenia i dokument pisze wieczorem w czwartek. Jedenaście stron ze zrzutami ekranu wygląda solidnie, ale nikt ich nie przetestował.

Trzeci powód: nikt nie sprawdza dokumentu, zanim autor odejdzie. Dokument jest czytany po raz pierwszy wtedy, gdy coś się psuje. Wtedy okazuje się, że kroki są nieaktualne, linki prowadzą do usuniętych stron, a „znany problem numer 4” jest opisany jednym zdaniem, które miało sens tylko dla autora.

Czwarty powód: wiedza ukryta z definicji nie daje się spisać na zamówienie. Można ją wydobyć tylko przez sytuacje, w których jest potrzebna: wdrożenie, incydent, nietypowe zgłoszenie od klienta. Dlatego najlepszym sposobem jej przeniesienia jest wspólna praca nad prawdziwymi zadaniami, a nie sesje „opowiedz nam o module”.

Co zamiast tego? Dokument nadal powstaje, ale jego rola się zmienia. To nie jest „przekazanie wiedzy”, tylko indeks: lista obszarów, linki do runbooków, decyzji i repozytoriów, lista kontaktów. Krótki, aktualny i przetestowany przez osobę przejmującą. Właściwe przekazanie wiedzy odbywa się w trzecim i czwartym tygodniu, przez pracę, a dokument jest jej produktem ubocznym: każde pytanie zadane podczas odwróconego shadowingu i jego odpowiedź trafiają do runbooka.

Ktoś zapyta: a co, jeśli kontraktor odchodzi z dnia na dzień, z powodu choroby czy sytuacji losowej? Wtedy nie ma ani dokumentu, ani shadowingu, i jedyne, co zostaje, to to, co zbudowaliście wcześniej: rejestr dostępów, druga osoba w obszarze, decyzje zapisane na bieżąco. To kolejny argument za tezą, że offboarding zbiera się przez cały kontrakt.

Jak sprawdzić, że wiedza naprawdę przeszła do zespołu?

Przez odwrócony shadowing i test nieobecności. Obie techniki są proste, ale wymagają dyscypliny, bo kuszą skróty.

Odwrócony shadowing to odwrócenie zwykłego wdrażania. W onboardingu nowa osoba obserwuje doświadczoną. W offboardingu osoba przejmująca wykonuje pracę, a odchodzący specjalista obserwuje i odzywa się tylko wtedy, gdy przejmujący utknie albo idzie w złą stronę. Kluczowe zasady: przejmujący ma ręce na klawiaturze, specjalista nie „pokazuje szybciej”, a każde pytanie, którego przejmujący nie potrafił rozwiązać sam, jest zapisywane jako luka.

Jakie zadania wybrać do shadowingu? Te, które w obszarze zdarzają się najczęściej, i te, które są najbardziej ryzykowne. Typowy zestaw dla modułu aplikacji: wdrożenie zmiany na produkcję, analiza i naprawa zgłoszonego błędu, obsługa alertu z monitoringu, zmiana konfiguracji, odpowiedź na pytanie biznesu o dane. Dla obszaru infrastruktury: dodanie środowiska, odnowienie certyfikatu, przywrócenie z kopii zapasowej, skalowanie usługi. Jeśli przejmujący przejdzie przez te scenariusze z małą liczbą pytań, wiedza przeszła. Jeśli nie, wiesz dokładnie, czego brakuje.

Test nieobecności to ostatnie dni przed odejściem, w których specjalista jest formalnie w pracy, ale nie bierze udziału w codziennych zadaniach. Odpowiada tylko na pytania zadane pisemnie na wspólnym kanale, a każde takie pytanie wraz z odpowiedzią trafia do runbooka. Test pokazuje, ile pytań zespół ma, gdy specjalisty „nie ma”, a jednocześnie daje bezpiecznik, bo specjalista jeszcze jest.

Jak ocenić wynik? Proste kryteria wystarczą. Czy przejmujący przeprowadził samodzielnie co najmniej jedno wdrożenie w obszarze? Czy każdy runbook został wykonany przez kogoś innego niż autor? Czy liczba pytań w teście nieobecności spada z dnia na dzień? Czy lista luk z shadowingu jest zamknięta albo ma właściciela i termin? Jeśli odpowiedź na którekolwiek pytanie brzmi „nie”, to sygnał do decyzji: zawęzić zakres przejmowanego obszaru, poprosić dostawcę o krótkie przedłużenie albo zaplanować dodatkowe godziny konsultacji po zakończeniu kontraktu.

Uczciwie trzeba dodać, że odwrócony shadowing kosztuje. Przez dwa tygodnie płacisz za specjalistę, który nie dostarcza nowych funkcji, i zajmujesz czas osoby przejmującej. Kto to kwestionuje, powinien porównać ten koszt z szacunkiem z pierwszej sekcji: kilka tygodni wolniejszej pracy następcy plus ryzyko incydentu w obszarze, którego nikt nie rozumie. Dwa tygodnie shadowingu są niemal zawsze tańsze.

Jak odebrać kod, żeby nic nie zostało na jednym laptopie?

Zasada brzmi: w ostatnim dniu nie ma ani jednej linii kodu, skryptu czy konfiguracji, która istnieje tylko u odchodzącego specjalisty. Brzmi oczywiście, ale w praktyce wymaga przejścia przez kilka miejsc, o których łatwo zapomnieć.

Gałęzie w repozytorium. Wylistuj wszystkie gałęzie, których autorem jest specjalista, i dla każdej podejmij decyzję: scalamy, przekazujemy konkretnej osobie albo usuwamy z opisem, dlaczego. Gałąź „na później” bez właściciela jest długiem, którego nikt nie spłaci.

Pull requesty w toku. Otwarte PR-y muszą zostać zamknięte albo przekazane. Przejęcie cudzego PR-a w połowie przeglądu to jedno z najbardziej frustrujących zadań w zespole, więc lepiej, żeby w drugim tygodniu specjalista doprowadził je do końca.

Skrypty i narzędzia lokalne. Zapytaj wprost: co uruchamiasz u siebie, a nie w pipeline? Skrypty do migracji danych, generatory raportów, narzędzia do diagnostyki, zapytania SQL zapisane w kliencie bazy danych. Wszystko, co jest używane więcej niż raz, trafia do repozytorium z instrukcją uruchomienia. Wszystko, co jest uruchamiane cyklicznie, trafia do harmonogramu w infrastrukturze organizacji, nie do crona na czyimś komputerze.

Konfiguracja i środowiska. Pliki konfiguracyjne, zmienne środowiskowe, ustawienia IDE potrzebne do zbudowania projektu. Prosty test: osoba przejmująca klonuje repozytorium na czystej maszynie i buduje projekt według README. Jeśli się nie da, coś zostało u specjalisty.

Infrastruktura. Zasoby w chmurze utworzone ręcznie, a nie z kodu. Jeśli specjalista budował infrastrukturę, poproś o listę zasobów utworzonych poza narzędziami typu infrastruktura jako kod i zdecyduj, które z nich trzeba przenieść do kodu, a które usunąć.

Jedna rzecz, której nie da się zrobić technicznie: odebrać kopii lokalnych. Dokumentacja GitHuba mówi wprost, że usunięcie współpracownika z prywatnego repozytorium odbiera mu dostęp i usuwa jego forki w serwisie, ale były współpracownik zachowuje lokalne klony. To nie jest powód do paniki, bo specjalista związany jest umową i zobowiązaniem do poufności, ale to powód, żeby w protokole zakończenia współpracy znalazło się oświadczenie o usunięciu kopii kodu i danych z urządzeń, a zwłaszcza danych osobowych, jeśli specjalista miał do nich dostęp.

Które dostępy i sekrety trzeba odebrać, a które zrotować?

Tu jest najważniejsze rozróżnienie w całym offboardingu: wyłączenie konta nie unieważnia sekretu. Jeśli specjalista znał hasło do konta serwisowego bazy danych, wyłączenie jego konta w SSO nie zmienia tego hasła. Jeśli wygenerował klucz API do systemu płatności i wpisał go do pipeline’u, klucz działa dalej, niezależnie od tego, czy jego autor ma jeszcze dostęp do czegokolwiek.

Skala problemu jest mierzalna. GitGuardian w raporcie State of Secrets Sprawl 2025 policzył około 23,8 miliona nowych sekretów, które w 2024 roku trafiły do publicznych repozytoriów na GitHubie, a 70% sekretów wykrytych w 2022 roku było nadal aktywnych w 2024. To dane o repozytoriach publicznych, nie o Twoim zespole, ale pokazują mechanizm: sekrety żyją znacznie dłużej niż potrzeba, bo nikt ich nie rotuje. O tym, jak ułożyć zarządzanie sekretami w pipeline’ach, żeby rotacja była rutyną, a nie projektem, pisaliśmy w artykule o secrets management w CI/CD.

Praktyczny podział na trzy kategorie:

Odebrać: konta imienne. Poczta i kalendarz w domenie organizacji, konto SSO i wszystko, co z niego wynika, repozytoria, chmura (konta IAM, role, grupy), narzędzia do zarządzania pracą, komunikatory, VPN, systemy monitoringu, narzędzia SaaS z kontami imiennymi, które nie są podpięte pod SSO. Ostatnia kategoria jest najczęściej pomijana, bo nie wyłącza się automatycznie razem z SSO.

Zrotować: sekrety współdzielone i utworzone przez specjalistę. Hasła kont technicznych i serwisowych, które znał. Klucze API i tokeny, które wygenerował, także te zapisane w pipeline’ach i menedżerach sekretów. Klucze SSH dodane do serwerów (sprawdź pliki authorized_keys, a nie tylko konto). Hasła do kont współdzielonych, np. konta administracyjnego w systemie zewnętrznego dostawcy. Urządzenia MFA przypisane do kont współdzielonych.

Przepiąć: zasoby i subskrypcje. Konta w usługach zewnętrznych założone na adres specjalisty, licencje przypisane imiennie, alerty i powiadomienia wysyłane do niego, zaplanowane zadania uruchamiane z jego uprawnieniami. Te rzeczy po wyłączeniu konta przestaną działać albo przestaną kogokolwiek powiadamiać, co czasem jest gorsze.

Kiedy to robić? Tu kolejna teza, z którą nie wszyscy się zgodzą: nie odcinaj wszystkiego w ostatniej godzinie, ograniczaj uprawnienia stopniowo w ostatnich dwóch tygodniach. W trzecim tygodniu, gdy zespół przejmuje pracę, specjalista nie potrzebuje już uprawnień do wdrażania na produkcję. Zabierz je, zostaw dostęp do odczytu. Jeśli coś przestanie działać, dowiesz się o tym, gdy specjalista jeszcze jest i może pomóc, a nie w poniedziałek po jego odejściu. W ostatnim dniu zostaje do wyłączenia tylko kilka kont podstawowych, co można zrobić szybko i sprawdzić. ISO/IEC 27001:2022 w zabezpieczeniu A.5.18 (prawa dostępu) wymaga, żeby uprawnienia były przeglądane i odbierane, gdy przestają być potrzebne; stopniowe ograniczanie to po prostu konsekwentne zastosowanie tej zasady w okresie wypowiedzenia.

Rotacja sekretów powinna nastąpić po ostatnim dniu, nie przed nim, bo specjalista do końca może potrzebować działającego środowiska. W praktyce: lista sekretów do rotacji jest gotowa w pierwszym tygodniu, rotacja następuje w pierwszym dniu roboczym po odejściu, a jej wykonanie potwierdza osoba inna niż ta, która ją przeprowadziła. Szerszy kontekst bezpieczeństwa, w tym zarządzanie tożsamością w całej organizacji, opisujemy w przewodniku po bezpieczeństwie IT w firmie.

Co musi być załatwione w umowie, zanim specjalista odejdzie?

Trzy sprawy formalne, które po ostatnim dniu załatwia się dużo trudniej niż przed nim.

Prawa autorskie do kodu. Jak wspomnieliśmy, przy umowie B2B prawa nie przechodzą na klienta z mocy art. 74 ust. 3 ustawy o prawie autorskim i prawach pokrewnych, bo ten przepis dotyczy pracowników. Przeniesienie autorskich praw majątkowych wymaga umowy w formie pisemnej pod rygorem nieważności (art. 53), a umowa obejmuje tylko pola eksploatacji w niej wyraźnie wymienione (art. 41 ust. 2). W body leasingu łańcuch wygląda zwykle tak: specjalista przenosi prawa na dostawcę, dostawca na klienta. Przed ostatnim dniem warto sprawdzić, czy oba ogniwa istnieją, czy obejmują wszystkie potrzebne pola eksploatacji i czy moment przeniesienia jest określony (np. z chwilą zapłaty za fakturę za dany okres). Jeśli moment przeniesienia jest powiązany z zapłatą, to za kod z ostatniego miesiąca prawa przejdą dopiero po zapłacie ostatniej faktury. To normalne, ale trzeba o tym wiedzieć. Szczegółowo opisaliśmy to w artykule kto jest właścicielem kodu w body leasingu.

Zobowiązania trwające po zakończeniu współpracy. Poufność, zakaz wykorzystania danych klienta, ewentualny zakaz konkurencji i zakaz podkupywania. ISO/IEC 27001:2022 ma na to osobne zabezpieczenie A.6.5 (odpowiedzialności po zakończeniu lub zmianie zatrudnienia), które wymaga, żeby obowiązki bezpieczeństwa ważne po odejściu były określone, zakomunikowane i egzekwowane, także wobec wykonawców. W praktyce: przypomnij specjaliście w ostatnim tygodniu, jakie zobowiązania go dalej wiążą, i upewnij się, że dostawca ma je w swojej umowie ze specjalistą.

Zwrot zasobów i protokół zakończenia. ISO/IEC 27001:2022 w zabezpieczeniu A.5.11 wymaga zwrotu zasobów organizacji przy zmianie lub zakończeniu zatrudnienia, umowy lub porozumienia. Zasoby to nie tylko laptop, jeśli go wydaliście, ale też klucze sprzętowe, karty dostępu, dokumenty papierowe i dane. Dobrze jest zakończyć współpracę krótkim protokołem podpisanym przez tech leada, specjalistę i dostawcę: zwrócone zasoby, odebrane dostępy, oświadczenie o usunięciu kopii danych i kodu z prywatnych urządzeń, potwierdzenie przekazania praw. To jedna strona, którą za rok ktoś będzie mógł pokazać audytorowi albo prawnikowi.

Jeśli Twoja firma jest podmiotem finansowym, dochodzi jeszcze jeden kontekst. Rozporządzenie DORA, stosowane od 17 stycznia 2025 roku, w art. 28 ust. 8 wymaga od podmiotów finansowych strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub istotne, z planami wyjścia, które są udokumentowane, testowane i okresowo przeglądane. Przepis dotyczy relacji z dostawcą usług ICT, a nie pojedynczego specjalisty, ale offboarding kluczowego kontraktora jest dokładnie tym rodzajem zdarzenia, które taki plan powinien przewidywać.

Jaka jest rola dostawcy body leasingu w offboardingu?

Większa, niż zakłada większość klientów, i warto z niej korzystać. Dostawca ma trzy zasoby, których klient nie ma: relację umowną ze specjalistą, możliwość dostarczenia następcy i doświadczenie z wieloma rozstaniami.

Relacja umowna. To dostawca może wyegzekwować od specjalisty zwrot sprzętu, podpisanie oświadczeń i dotrzymanie zobowiązań po zakończeniu współpracy. Klient może o to prosić, dostawca może tego wymagać. Dlatego plan offboardingu warto przesłać dostawcy w pierwszym tygodniu okresu wypowiedzenia, z prośbą o potwierdzenie, które punkty dostawca bierze na siebie.

Następca i nakładka. Jeśli obszar, który zostawia specjalista, nadal wymaga pracy, najlepszym rozwiązaniem jest nakładka: następca zaczyna przed odejściem poprzednika i przechodzi przez odwrócony shadowing razem z zespołem wewnętrznym. W ARDURA, jeśli specjalista odchodzi w trakcie współpracy, gwarantujemy zastępstwo w ciągu 5 dni roboczych, a każda nowa współpraca startuje z dwutygodniową gwarancją wymiany. Jeśli zastępca dołącza w pierwszym tygodniu okresu wypowiedzenia, zostaje kilka tygodni wspólnej pracy, czyli dokładnie tyle, ile potrzeba na plan opisany wyżej. Warunki body leasingu w ARDURA opisujemy na stronie usługi.

Doświadczenie. Dostawca, który prowadzi wiele współprac, wie, co zwykle się gubi. Warto zapytać wprost: co najczęściej wychodzi na jaw po odejściu specjalisty u innych klientów? Jaki macie standard przekazania? Kto po waszej stronie odpowiada za to, żeby specjalista zostawił porządek? Dobry dostawca ma na te pytania konkretne odpowiedzi.

Jednej rzeczy dostawca za klienta nie zrobi: nie przejmie wiedzy. Wiedza musi trafić do zespołu klienta, bo to on będzie utrzymywał system. Dostawca może dostarczyć następcę, ale jeśli cały obszar przechodzi z jednego kontraktora na drugiego, a nikt w zespole wewnętrznym go nie rozumie, truck factor obszaru dalej wynosi 1. Dlatego zasada drugiej osoby po stronie klienta obowiązuje także przy wymianie specjalisty, a nie tylko przy zakończeniu współpracy. Zbiorczo te zasady opisuje też hasło offboarding w naszym słowniku.

Jak mierzyć, czy offboarding się udał?

Offboarding kończy się formalnie w ostatnim dniu, ale jego wynik widać dopiero po kilku tygodniach. Warto mierzyć go tak samo jak inne procesy w zespole, bo inaczej każdy kolejny offboarding będzie wyglądał tak samo.

Pięć prostych wskaźników, które da się zebrać bez specjalnych narzędzi:

Czas od odejścia do pierwszej samodzielnej zmiany w obszarze. Ile dni minęło, zanim ktoś z zespołu wdrożył zmianę w przejętym obszarze bez pomocy z zewnątrz? Jeśli odwrócony shadowing zadziałał, ta zmiana miała miejsce jeszcze przed odejściem, więc wynik wynosi zero.

Liczba pytań do byłego specjalisty. Ile razy w ciągu 30, 60 i 90 dni ktoś musiał skontaktować się z odchodzącym specjalistą (przez dostawcę albo bezpośrednio)? Każde takie pytanie to luka, której nie wykryliście w okresie wypowiedzenia.

Incydenty w przejętym obszarze. Liczba i czas rozwiązania incydentów w obszarze w ciągu 90 dni po odejściu, w porównaniu z 90 dniami przed. Wzrost nie musi oznaczać złego offboardingu, ale wzrost czasu rozwiązania zwykle oznacza.

Czas wyłączenia dostępów. Ile godzin minęło od końca ostatniego dnia do wyłączenia ostatniego konta imiennego? Ile sekretów z listy zostało zrotowanych w pierwszym dniu roboczym po odejściu? Audytor zapyta dokładnie o to.

Znaleziska po fakcie. Konto, którego nie było w rejestrze. Skrypt, którego nie było w repozytorium. Subskrypcja na adres specjalisty. Każde znalezisko to wpis do checklisty na następny raz.

Te wskaźniki warto zebrać na krótkim spotkaniu 30 dni po odejściu, z udziałem tech leada, HR Partnera i osoby przejmującej. Pół godziny wystarczy, żeby zaktualizować checklistę i rejestr dostępów pod kolejne współprace. Jeśli współpracujecie z jednym dostawcą wielokrotnie, podzielcie się wynikami także z nim.

Checklista na ostatni tydzień

Checklista nie zastępuje tezy tego artykułu, ale jest potrzebna, żeby zamknąć sprawy, które nie wymagają myślenia. Poniżej wersja, którą można skopiować do narzędzia do zarządzania pracą i przypisać właścicieli.

Kod i artefakty (właściciel: tech lead). Wszystkie gałęzie specjalisty scalone lub zamknięte z decyzją. Brak otwartych PR-ów jego autorstwa. Skrypty lokalne przeniesione do repozytorium. Zadania cykliczne przeniesione do infrastruktury organizacji. Projekt zbudowany od zera na czystej maszynie przez osobę przejmującą. Zasoby testowe w chmurze usunięte lub przypisane nowemu właścicielowi.

Wiedza (właściciel: osoba przejmująca). Indeks wiedzy zaktualizowany. Każdy runbook wykonany przez kogoś innego niż autor. Lista luk z odwróconego shadowingu zamknięta albo z właścicielem i terminem. Decyzje architektoniczne zapisane. Kontakty zewnętrzne poinformowane, do kogo pisać.

Dostępy (właściciel: tech lead + administrator). Uprawnienia produkcyjne odebrane w trzecim tygodniu. Konta imienne wyłączone w ostatnim dniu, łącznie z narzędziami SaaS spoza SSO. Lista sekretów do rotacji gotowa, rotacja zaplanowana na pierwszy dzień roboczy po odejściu. Klucze SSH usunięte z serwerów. Alerty i powiadomienia przepięte.

Formalności (właściciel: HR Partner). Potwierdzenie z dostawcą łańcucha przeniesienia praw autorskich. Przypomnienie o zobowiązaniach po zakończeniu współpracy. Zwrot zasobów. Protokół zakończenia podpisany przez trzy strony. Termin spotkania podsumowującego po 30 dniach.

Jeśli którykolwiek z tych punktów jest dla Ciebie nowy, przeczytaj ponownie sekcję o tym, kiedy zaczyna się offboarding. Większość z nich jest łatwa do wykonania w ostatnim tygodniu tylko wtedy, gdy przygotowania zaczęły się dużo wcześniej.

Jakie są kluczowe wnioski dla tech leada i HR Partnera?

Offboarding specjalisty kontraktowego nie jest uprzejmością na pożegnanie ani formalnością dla audytora. To moment, w którym okazuje się, czy zespół zbudował wiedzę, czy tylko ją wynajmował. Dobra wiadomość jest taka, że prawie wszystko, co decyduje o wyniku, da się zaplanować.

Zapamiętaj sześć rzeczy. Po pierwsze, zacznij offboarding w dniu onboardingu: rejestr dostępów, druga osoba w każdym obszarze i decyzje zapisywane na bieżąco. Po drugie, w okresie wypowiedzenia odwróć proporcje: tydzień inwentaryzacji, tydzień domykania, dwa tygodnie pracy zespołu pod obserwacją specjalisty. Po trzecie, nie ufaj dokumentowi przekazania, dopóki ktoś inny niż autor nie wykonał opisanych w nim kroków. Po czwarte, pamiętaj, że wyłączenie konta nie unieważnia sekretu, i zrotuj wszystko, co specjalista znał lub utworzył. Po piąte, zamknij formalności przed ostatnim dniem: łańcuch praw autorskich, zobowiązania po zakończeniu współpracy, protokół zwrotu zasobów. Po szóste, zmierz wynik po 30, 60 i 90 dniach i popraw checklistę na następny raz.

Jeśli planujesz zmiany w składzie zespołu albo chcesz, żeby następca przejął obszar od odchodzącego specjalisty z nakładką, zobacz, jak działa body leasing w ARDURA: umowy rozwiązujemy z 30-dniowym wypowiedzeniem, a gdy specjalista odchodzi w trakcie współpracy, zastępstwo zapewniamy w ciągu 5 dni roboczych. Umów rozmowę, jeśli chcesz omówić plan przejęcia konkretnego obszaru.