Prawie cały zespół programistów Skyeng, który liczy ponad 100 osób, pracuje zdalnie, a wymagania stawiane specjalistom zawsze były wysokie: szukaliśmy seniorów, fullstack developerów i midstaków. Ale na początku 2019 roku po raz pierwszy zatrudniliśmy trzech juniorów. Stało się tak z kilku powodów: zatrudnienie samych superspecjalistów nie rozwiązuje wszystkich problemów, a do stworzenia zdrowej atmosfery w rozwoju potrzebni są ludzie o różnym poziomie profesjonalizmu.
Kiedy pracujesz zdalnie, niezwykle ważne jest, aby osoba przychodziła do projektu i od razu zaczęła przynosić korzyści, bez długich procesów uczenia się i budowania. Z juniorami tak nie jest, poza treningiem potrzebna jest też umiejętna integracja początkującego z drużyną, bo wszystko jest dla niego nowe. A to osobne zadanie dla lidera zespołu. Dlatego skupiliśmy się na znalezieniu i zatrudnieniu bardziej doświadczonych i ugruntowanych programistów. Jednak z czasem okazało się, że zespoły składające się wyłącznie z seniorów i fullstack developerów mają swoje własne problemy. Na przykład, kto będzie zaangażowany w rutynowe, ale obowiązkowe zadania, które nie wymagają super kwalifikacji i specjalnej wiedzy?
Wcześniej, zamiast zatrudniać juniorów, zadzieraliśmy z freelancerami
Choć zadań było mało, to nasi seniorzy jakoś zacisnęli zęby i wzięli na siebie te nieciekawe zadania, bo rozwój powinien iść do przodu. Ale to nie mogło trwać długo: projekty rosły, liczba rutynowych prostych zadań rosła. Sytuacja zaczęła coraz bardziej przypominać żart, gdy zamiast młotka wbija się gwoździe mikroskopem. Dla jasności możesz odwołać się do arytmetyki: jeśli przyciągniesz osobę, której stawka warunkowa wynosi 50 USD za godzinę, do pracy, którą może obsłużyć pracownik ze stawką 10 USD za godzinę, to masz problemy.
Najważniejszą rzeczą, jakiej nauczyliśmy się z tej sytuacji, jest to, że obecny paradygmat zatrudniania tylko fajnych specjalistów nie rozwiązuje naszych problemów rutynowymi zadaniami. Potrzebujemy kogoś, kto będzie gotowy do pracy, którą doświadczeni seniorzy postrzegają jako karę, a powierzenie im jej jest banalnie nieefektywne. Na przykład pisanie botów do czatów Slack naszych nauczycieli i autorów kursów lub wykonywanie małych wewnętrznych projektów usprawniających, na które programiści ciągle nie mają czasu, a które uczyniłyby życie o wiele przyjemniejszym.
W tym momencie wypracowano rozwiązanie pośrednie. Zaczęliśmy angażować freelancerów w nasze projekty. To właśnie do takiego outsourcingu zaczęły iść proste i niepilne zadania: gdzieś coś poprawić, gdzieś sprawdzić, coś przepisać. Nasze niezależne skrzydło rozwijało się dość aktywnie. Jeden z naszych kierowników projektów zbierał zadania z różnych projektów i rozdzielał je wśród freelancerów, kierując się istniejącą bazą danych wykonawców. Wtedy wydało nam się to dobrą decyzją: odciążyliśmy seniorów i znów mogli tworzyć z pełnym potencjałem, zamiast majstrować przy czymś elementarnym. Oczywiście były zadania, których ze względu na tajemnice handlowe nie można było przekazać wykonawcom zewnętrznym, ale takich spraw było wielokrotnie mniej w porównaniu do masy zadań, które trafiały do freelancerów.
Ale to nie mogło trwać wiecznie. Firma stanęła w obliczu faktu, że niezależny dział stał się niezdarnym potworem. Wraz z projektami rosła liczba rutynowych, prostych zadań, których w pewnym momencie było zbyt dużo, aby skutecznie rozdysponować je zewnętrznym wykonawcom. Ponadto freelancer nie jest zanurzony w specyfice projektów, co jest ciągłą stratą czasu na onboarding. Oczywiście, gdy masz w swoim zespole ponad 100 profesjonalnych programistów, nie możesz zatrudnić nawet pięćdziesięciu freelancerów do pomocy i efektywnego zarządzania ich działaniami. Ponadto interakcja z freelancerami zawsze wiąże się z pewnym ryzykiem niedotrzymania terminów i innych problemów organizacyjnych.
W tym miejscu należy zauważyć, że pracownik zdalny i freelancer to dwa różne podmioty. Pracownik zdalny jest w pełni zarejestrowany w firmie, ma wyznaczone godziny pracy, zespół, przełożonych itd. Freelancer to praca projektowa, którą regulują głównie terminy. Freelancer, w przeciwieństwie do pracownika zdalnego, jest w większości pozostawiony sam sobie i słabo współpracuje z zespołem. Stąd potencjalne ryzyko interakcji z takimi wykonawcami.
Jak doszliśmy do stworzenia „działu prostych zadań” i co uzyskaliśmy
Po przeanalizowaniu obecnej sytuacji doszliśmy do wniosku, że potrzebujemy pracowników o niższych kwalifikacjach. Nie budowaliśmy złudzeń, że spośród wszystkich juniorów wyrośniemy na przyszłe supergwiazdy, ani że zatrudnienie tuzina juniorów będzie nas kosztować trzy kopiejki. Ogólnie biorąc pod uwagę sytuację z juniorami, rzeczywistość wygląda następująco:
- Wynajem ich na krótkie odległości jest ekonomicznie nieopłacalny. Zamiast od pięciu do dziesięciu junów „od zaraz”, lepiej wziąć jednego sygnatariusza i zapłacić mu miliony pieniędzy za wysokiej jakości pracę, niż wydawać budżety na nowicjuszy.
- Juniorzy mają długi okres wejścia w projekt i szkolenia.
- W momencie, gdy June czegoś się nauczyła i wydaje się, że musi zacząć „odpracowywać” inwestycje w siebie przez pierwsze pół roku pracy, musi awansować na średni lub odchodzi na to stanowisko do innej firmy. Dlatego zatrudnianie juniorów jest odpowiednie tylko dla dojrzałych organizacji, które chcą w nich inwestować bez gwarancji zysku w krótkim okresie.
Ale dojrzeliśmy do tego stopnia, że bez juniorów w drużynie nie ma mowy: rośnie liczba zwykłych zadań, a poświęcanie na nie roboczogodzin zatwardziałych fachowców to po prostu zbrodnia. Dlatego stworzyliśmy dział specjalnie dla młodszych programistów.
Okres pracy w dziale prostych zadań jest ograniczony do trzech miesięcy – czyli jest to standardowy okres próbny. Po trzech miesiącach pełnoetatowej płatnej pracy debiutant albo trafia do zespołu, który chce go widzieć w swoich szeregach jako junior developer, albo się z nim rozstajemy.
Na czele utworzonego przez nas działu stoi doświadczony PM, który odpowiada za podział zadań pracy wśród juniorów oraz ich interakcję z innymi zespołami. June otrzymuje zadanie, wykonuje je, otrzymuje informację zwrotną zarówno od zespołu, jak i swojego przełożonego. Na etapie pracy w dziale zadań prostych nie przydzielamy początkujących do konkretnych zespołów i projektów - mają oni dostęp do całej puli zadań zgodnie ze swoimi umiejętnościami (teraz zatrudniamy front-endowców AngularJS, backendowców PHP, czy szukających dla kandydatów na stanowisko web developera ze znajomością obu języków) i może pracować nad wieloma projektami jednocześnie.
Ale wszystko nie ogranicza się do zatrudniania juniorów - muszą stworzyć akceptowalne warunki pracy, a to jest zadanie z zupełnie innego planu.
Pierwszą rzeczą, na którą się zdecydowaliśmy, był dobrowolny mentoring w rozsądnych ilościach. Oznacza to, że oprócz tego, że żadnego z dotychczasowych specjalistów nie zmuszaliśmy do bycia mentorem, wyraźnie wskazano, że szkolenie początkującego nie powinno stać się substytutem głównej pracy. Nie „50% czasu pracujemy, 50% uczymy juniorów”. Aby mieć jasne wyobrażenie o tym, jak długo potrwa mentoring, sporządzono mały „program nauczania”: listę zadań, które każdy mentor musiał wykonać ze swoim podopiecznym. To samo zrobiono z kierownikiem projektu juniorów, w wyniku czego otrzymaliśmy bardzo płynny i zrozumiały scenariusz przygotowania nowicjuszy i ich wejścia do pracy.
Przewidziliśmy następujące punkty: sprawdzanie wiedzy teoretycznej, przygotowaliśmy zestaw materiałów, jeśli junior musi czegoś dokończyć, zatwierdziliśmy jedną zasadę przeprowadzania code review dla mentorów. Na każdym etapie liderzy udzielają nowicjuszowi informacji zwrotnej, co jest dla niego niezwykle ważne. Młody pracownik rozumie, w których aspektach jest mocny, a w których musi być bardziej ostrożny. Aby uprościć proces nauki juniorom i doświadczonym programistom, stworzono wspólny czat w Slacku, dzięki czemu inni członkowie zespołu mogą włączyć się do procesu nauki i zamiast mentora odpowiedzieć na pytanie. Wszystko to sprawia, że praca z juniorami jest procesem całkowicie przewidywalnym i, co ważne, możliwym do kontrolowania.
Na koniec trzymiesięcznego okresu próbnego mentor przeprowadza z juniorem końcową rozmowę techniczną, na podstawie której podejmuje się decyzję, czy junior może przejść do stałej pracy w którymś z zespołów, czy też nie.
Razem
Na pierwszy rzut oka nasz młodszy dział wygląda jak inkubator lub jakaś specjalnie stworzona piaskownica. Ale w rzeczywistości jest to prawdziwy dział ze wszystkimi atrybutami pełnoprawnego zespołu bojowego, który rozwiązuje rzeczywiste, a nie szkoleniowe zadania.
Ale najważniejsze jest to, że dajemy ludziom konkretny horyzont. Dział łatwych zadań to nie niekończąca się otchłań, w której można utknąć na zawsze. Jest wyraźny termin trzech miesięcy, w ciągu których junior rozwiązuje proste zadania na projektach, ale jednocześnie może się sprawdzić i przenieść do jakiegoś zespołu. Zatrudnieni przez nas nowicjusze wiedzą, że będą mieli własnego kierownika projektu, mentora ze strony seniorów (a może kilku) oraz możliwość pełnej integracji z zespołem, w którym będą szczęśliwi i na niego czekali.
Od początku roku w dziale zadań prostych zatrudniono 12 juniorów, tylko dwóch nie przeszło okresu próbnego. Kolejny facet nie zakorzenił się w zespole, ale ponieważ jest bardzo zdolny do pracy, wrócił do działu prostych zadań na nową kadencję, w trakcie której, mamy nadzieję, odnajdzie się w nowym zespole. Praca z juniorami pozytywnie wpłynęła również na naszych doświadczonych programistów. Część z nich po okresie mentoringu odkryła w sobie siłę i chęć spróbowania roli liderów zespołów, ktoś patrząc na juniorów doskonalił swoją wiedzę i przechodził z pozycji średniej na pozycję seniora.
Będziemy tylko rozszerzać naszą praktykę zatrudniania młodych programistów, ponieważ przynosi to zespołowi wiele korzyści. Czerwcy otrzymują pełnowartościowe zatrudnienie zdalne, niezależnie od regionu zamieszkania: członkowie naszych zespołów programistycznych mieszkają od Rygi po Władywostok i dobrze radzą sobie z różnicami czasowymi dzięki usprawnionym procesom w firmie. Wszystko to otwiera drogę utalentowanym ludziom mieszkającym w odległych miastach i wsiach. I mówimy nie tylko o wczorajszych uczniach i studentach, ale także o ludziach, którzy z jakiegoś powodu postanowili zmienić zawód. Nasz junior z takim samym sukcesem może mieć zarówno 18 jak i 35 lat, bo w juniorze liczy się doświadczenie i umiejętności, a nie wiek.
Jesteśmy przekonani, że nasze podejście można łatwo rozszerzyć na inne firmy korzystające z modelu zdalnego rozwoju. Jednocześnie pozwala selektywnie zatrudniać utalentowanych juniorów z dowolnego miejsca w Rosji lub WNP, a jednocześnie podnosić umiejętności mentorskie doświadczonych programistów. Finansowo ta historia jest wyjątkowo tania, więc wszyscy wygrywają: firma, nasi programiści i oczywiście juniorzy, którzy nie muszą przenosić się do dużych miast czy stolic, by stać się częścią doświadczonego zespołu i pracować nad ciekawymi projektami .
Źródło: www.habr.com