Onboarding, który działa

Ten sam developer, dwa różne wyniki

Kilka miesięcy temu rozmawialiśmy z dwoma firmami, które w tym samym tygodniu zatrudniły developerów o niemal identycznym profilu. Ten sam poziom, podobny stack, porównywalne doświadczenie.
W jednej firmie po dwóch tygodniach nowa osoba wysyłała kod na produkcję. W drugiej po trzech miesiącach wciąż pytała, gdzie jest dokumentacja do API i kto się zajmuje płatnościami.
Różnica nie leżała w developerze. Leżała w procesie, który miał go wprowadzić do zespołu.

Dlaczego to kosztuje więcej niż się wydaje

Nowa osoba w zespole to nie koszt, który znika po podpisaniu umowy. To koszt, który rośnie każdego dnia, w którym ta osoba nie tworzy wartości. Pensja idzie, czas seniorów przeznaczony na tłumaczenie idzie, a produkt stoi w miejscu.
Jest jeszcze drugi, cichszy koszt. Nowi ludzie decydują, czy zostają na dłużej, właśnie w pierwszych tygodniach. Jeśli te tygodnie wyglądają jak błądzenie po ciemku, część z nich zaczyna rozglądać się za czymś innym, zanim ktokolwiek zdąży zobaczyć ich pełny potencjał.

Nowi ludzie decydują, czy zostają na dłużej, w pierwszych tygodniach, nie po pierwszym roku.

Co robią zespoły, które robią to dobrze

• Pierwszy dzień jest zaplanowany, nie improwizowany
  Dostępy, konta, środowisko developerskie działają, zanim nowa osoba usiądzie przy biurku. Żadnego czekania pół dnia, aż ktoś znajdzie chwilę, żeby nadać uprawnienia do repo.
• Kod trafia do repo w pierwszym tygodniu, nie w pierwszym miesiącu
  Zespoły, które wdrażają szybko, mają gotową listę małych, dobrze opisanych, niskiego ryzyka zadań na start. Pierwszy pull request w pierwszym tygodniu daje coś, czego żadna prezentacja onboardingowa nie da: poczucie, że się umie i że się przydaje.
• Jest jedna konkretna osoba odpowiedzialna, nie cały zespół
  "Pytaj kogokolwiek" w praktyce oznacza, że nikt nie czuje się odpowiedzialny. Jeden opiekun z realnym czasem zarezerwowanym w kalendarzu to różnica między "ktoś mi kiedyś odpowie" a "wiem, do kogo pójść teraz".
• Dokumentacja jest aktualna, nie tylko obszerna
  Dokumentacja opisująca system sprzed roku jest gorsza niż jej brak, bo daje fałszywe poczucie pewności. Dobre zespoły traktują ją jak kod: ktoś ją utrzymuje, nieaktualne fragmenty się usuwa.
• Feedback idzie w obie strony i szybko
  Krótkie, nieformalne "jak Ci idzie" co tydzień wyłapuje problemy, zanim urosną. Czekanie na pierwszą ocenę okresową po trzech miesiącach oznacza, że naprawiasz coś, co już zdążyło zaboleć.

Ile to naprawdę kosztuje, jeśli tego nie zrobisz

Trudno to policzyć co do złotówki, ale kierunek jest jasny. Jeśli senior spędza godzinę dziennie na tłumaczeniu tego samego rzeczy nowej osobie przez trzy miesiące zamiast przez trzy tygodnie, to dziesiątki godzin pracy najdroższej osoby w zespole, które nie idą w rozwój produktu.
Do tego dochodzi koszt rotacji. Rekrutacja, wdrożenie, utracona wiedza, ponowna rekrutacja – to zawsze droższe niż uporządkowanie procesu, który sprawił, że ktoś odszedł w pierwszych miesiącach.
Dobrze zaprojektowany onboarding to nie inwestycja w miły gest powitalny. To inwestycja operacyjna, która zwraca się w tygodniach, nie latach.

Co powinien zawierać dobry plan onboardingu

Dobry plan onboardingu nie jest listą szkoleń do odbycia. Jest zestawem konkretnych punktów kontrolnych z jasno określonym czasem: pierwszy dzień z gotowym środowiskiem, pierwszy tydzień z pierwszym pull requestem, pierwszy miesiąc z samodzielną funkcją, drugi miesiąc z pierwszym dyżurem pod opieką kogoś bardziej doświadczonego.
Każdy punkt powinien mieć właściciela i sposób sprawdzenia, czy się wydarzył. Bez tego onboarding zamienia się w listę życzeń, którą nikt nie ma czasu realizować.

Jedno zdanie na koniec

Twój zespół prawdopodobnie już wie, gdzie nowi ludzie się gubią, tylko nikt jeszcze nie usiadł, żeby to spisać i naprawić.