Prawie cały zespół deweloperski Skyeng, składający się z ponad 100 osób, pracuje zdalnie, a wymagania wobec specjalistów zawsze były wysokie: szukaliśmy seniorów, deweloperów fullstack i midów. Jednak na początku 2019 roku po raz pierwszy zatrudniliśmy trzech juniorów. Zrobiliśmy to z kilku powodów: zatrudnianie tylko super-specjalistów nie rozwiązuje wszystkich problemów, a dla stworzenia zdrowej atmosfery w zespole potrzebni są ludzie o różnym poziomie profesjonalizmu.
Kiedy pracujesz zdalnie, niezwykle ważne jest, aby osoba przyszła do projektu i od razu zaczęła przynosić korzyści, bez długich procesów nauki i adaptacji. W przypadku juniorów tak się nie da, a oprócz nauki potrzebna jest również odpowiednia integracja nowego członka zespołu, ponieważ wszystko jest dla niego nowe. A to już jest osobne zadanie dla lidera zespołu. Dlatego skupiliśmy się na poszukiwaniu i zatrudnianiu bardziej doświadczonych i ustabilizowanych deweloperów. Ale z czasem okazało się, że w zespołach składających się wyłącznie z seniorów i deweloperów fullstack występują swoje problemy. Na przykład, kto zajmie się rutynowymi, ale niezbędnymi zadaniami, które nie wymagają super-kwalifikacji i jakiejś specjalnej wiedzy?
Kiedyś, zamiast zatrudniać juniorów, męczyliśmy się z freelancerami.
Dopóki zadań było niewiele, nasi seniorzy jakoś zgrzytając zębami podejmowali się tych nieinteresujących dla siebie zadań, bo rozwój musi postępować. Ale nie mogło to trwać długo: projekty rosły, a liczba rutynowych, prostych zadań zwiększała się. Sytuacja zaczęła coraz bardziej przypominać anegdotę, kiedy gwoździe wbija się mikroskopem zamiast młotkiem. Dla zobrazowania można odwołać się do arytmetyki: jeśli angażujesz osobę, której stawka wynosi 50$ za godzinę do prac, z którymi poradzi sobie pracownik z stawką 10$ za godzinę, to masz problem.
Najważniejsze, co wyniesiono z tej sytuacji, to fakt, że obecna paradygma zatrudniania tylko wybitnych specjalistów nie rozwiązuje naszych problemów z rutynowymi zadaniami. Potrzebujemy kogoś, kto będzie gotów wykonywać prace, które doświadczeni seniorzy postrzegają jako karę, a zlecanie ich im byłoby po prostu nieefektywne. Na przykład, pisanie botów do Slacka dla naszych nauczycieli i twórców kursów lub zajmowanie się drobnymi projektami-zmianami dla potrzeb wewnętrznych, na które programiści zawsze nie mają wystarczająco dużo czasu, ale które znacznie poprawiłoby komfort życia.
W tym momencie opracowano rozwiązanie tymczasowe. Zaczęliśmy angażować freelancerów do pracy nad naszymi projektami. To właśnie na taki outsourcing zaczęły przechodzić proste i nie pilne zadania: w niektórych miejscach coś poprawić, gdzie indziej sprawdzić, coś przepisać. Nasze skrzydło freelancerskie rosło dość aktywnie. Jeden z naszych menedżerów projektów zbierał zadania z różnych projektów i przydzielał je freelancerom, bazując na istniejącej bazie wykonawców. Wydawało nam się to wtedy dobrym rozwiązaniem: zdjęliśmy obciążenie z seniorów, którzy znów mogli twórczo działać, zamiast grzebać się w czymś elementarnym. Oczywiście były zadania, które z powodu tajemnicy handlowej nie mogły być przekazane zewnętrznym wykonawcom, ale takich kwestii było znacznie 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 tego, że dział freelancera stał się nieporadnym potworem. Liczba rutynowych, prostych zadań rosła wraz z projektami i w pewnym momencie stało się ich zbyt wiele, aby efektywnie przydzielać je zewnętrznym wykonawcom. Ponadto freelancer nie jest zanurzony w specyfikę projektów, co zawsze wiąże się z czasem poświęconym na onboardingu. Oczywiste jest, że kiedy w zespole jest ponad 100 profesjonalnych programistów, nie możesz zatrudnić dla nich nawet pół setki freelancerów i efektywnie zarządzać ich działalnością. Dodatkowo współpraca z freelancerami zawsze wiąże się z pewnym ryzykiem opóźnień i innymi problemami organizacyjnymi.
Ważne jest, aby zdefiniować, że pracownik zdalny i freelancer to dwie różne jednostki. Pracownik zdalny jest w pełni zatrudniony w firmie, ma określone godziny pracy, zespół, przełożonych itd. Freelancer to praca projektowa, która regulowana jest głównie przez terminy. Freelancer, w przeciwieństwie do pracownika zdalnego, jest zazwyczaj zdany na siebie i słabo współpracuje z zespołem. Stąd potencjalne ryzyka związane z współpracą z takimi wykonawcami.
Jak doszliśmy do stworzenia "działu prostych zadań" i co nam z tego wyszło
Analizując obecną sytuację, doszliśmy do wniosku, że potrzebujemy pracowników o niższych kwalifikacjach. Nie mieliśmy złudzeń na temat tego, że z wszystkich juniorów wyhodujemy przyszłe supergwiazdy, ani że zatrudnienie dziesięciu juniorów nie wiąże się z dużymi kosztami. W rzeczywistości dotyczącej juniorów sytuacja jest następująca:
- Na krótką metę ich zatrudnienie jest ekonomicznie nieopłacalne. Zamiast pięciu-dziesięciu juniorów "tu i teraz", lepiej zatrudnić jednego seniora i płacić mu miliony za wysokiej jakości pracę, niż marnować budżety na nowicjuszy.
- Juniorzy mają długi okres wdrażania się do projektu i nauki.
- W momencie, gdy junior nauczy się czegoś i teoretycznie powinien zacząć "odzyskiwać" zainwestowane w niego środki w ciągu pierwszych sześciu miesięcy pracy, musi być awansowany do midla, albo odchodzi na to stanowisko do innej firmy. Zatem zatrudnienie juniorów jest odpowiednie tylko dla dojrzałych organizacji, które są gotowe inwestować w nich pieniądze bez gwarancji uzyskania zysku w krótkim okresie.
Ale osiągnęliśmy taki rozmiar, że bez juniorów w zespole nie da się funkcjonować: liczba podstawowych zadań rośnie, a wydawanie na nie godzin pracy doświadczonych profesjonalistów to po prostu zbrodnia. Dlatego stworzyliśmy dział specjalnie dla junior developerów.
Okres pracy w dziale prostych zadań ogranicza się do trzech miesięcy — to znaczy, że to standardowy okres próbny. Po trzech miesiącach w pełni płatnej pracy nowicjusz trafia albo do zespołu, który chciał go mieć jako junior developera, albo się z nim rozstajemy.
Na czele utworzonego przez nas działu stoi doświadczony PM, który odpowiada za przydzielanie zadań juniorom oraz ich współpracę z innymi zespołami. Junior otrzymuje zadanie, wykonuje je, a następnie uzyskuje informacje zwrotne zarówno od zespołu, jak i od swojego menedżera. W etapie pracy w dziale prostych zadań nie przydzielamy nowicjuszy do konkretnych zespołów i projektów – mają oni dostęp do całego zestawu zadań zgodnie ze swoimi umiejętnościami (obecnie rekrutujemy front-endowców do AngularJS, back-endowców do PHP lub szukamy kandydatów na stanowisko dewelopera internetowego znającego oba języki) i mogą pracować od razu nad kilkoma projektami.
Jednak zatrudnianie juniorów to nie wszystko – musimy stworzyć również odpowiednie warunki do pracy, co już jest zupełnie innym wyzwaniem.
Pierwsze, co ustaliliśmy, to dobrowolne mentorskie wsparcie w rozsądnych ramach. To znaczy, że nikt z istniejących specjalistów nie był zmuszany do mentorskiej roli, a jasno określono, że nauka nowicjusza nie może zastępować głównej pracy. Żadne "50% czasu pracujemy, 50% uczymy juniora". Aby dokładnie oszacować, ile czasu zajmie mentorskie wsparcie, opracowano niewielki "plan nauczania": lista zadań, które każdy mentor miał zrealizować ze swoim podopiecznym. To samo zrobiono dla kierowników projektów juniorów, i w efekcie otrzymaliśmy bardzo płynny i zrozumiały scenariusz przygotowania nowicjuszy do pracy.
Zadbalismy o następujące kwestie: sprawdzenie wiedzy teoretycznej, przygotowanie zestawu materiałów, jeśli junior musi uzupełnić swoją wiedzę, oraz zatwierdzenie jednolitej zasady przeprowadzania przeglądów kodu dla mentorów. Na każdym etapie kierownicy udzielają nowicjuszowiu informacji zwrotnych, co jest niezwykle ważne dla ostatniego. Młodszy pracownik rozumie, w jakich aspektach jest silny, a które wymagają większej uwagi. Aby uprościć proces nauczania juniorów i doświadczonych programistów, stworzono wspólny czat w Slack, dzięki czemu uczestniczyć w procesie uczenia i odpowiadać na pytania zamiast mentora mogą również inni członkowie zespołu. Wszystko to sprawia, że praca z juniorami jest dość przewidywalnym i, co istotne, kontrolowanym procesem.
Po zakończeniu trzymiesięcznego okresu próbnego mentor przeprowadza z juniorem ostateczną rozmowę techniczną, na podstawie której decyduje się, czy junior może przejść na stałe do jednej z drużyn, czy nie.
Podsumowując
Na pierwszy rzut oka nasz dział dla juniorów przypomina inkubator lub specjalnie stworzoną piaskownicę. W rzeczywistości jest to prawdziwy dział ze wszystkimi atrybutami pełnoprawnego zespołu bojowego, który realizuje faktyczne, a nie treningowe zadania.
Ale najważniejsze jest to, że dajemy ludziom konkretny horyzont. Dział prostych zadań to nie nieskończony limbo, w którym można utknąć na zawsze. Jest wyraźny termin trzech miesięcy, w którym junior realizuje proste zadania w projektach, a jednocześnie ma możliwość wykazania się i przejścia do jakiejś drużyny. Nowi pracownicy, których zatrudniamy, wiedzą, że będą mieli swojego menedżera projektu, mentora z grona seniorów (a może nawet kilku) oraz szansę na pełne włączenie się do zespołu, gdzie będą mile widziani i oczekiwani.
Od początku roku do działu prostych zadań zatrudniono 12 juniorów, tylko dwie osoby nie przeszły okresu próbnego. Jeszcze jeden chłopak nie odnalazł się w zespole, ale ponieważ w pracy jest bardzo zdolny — został przywrócony do działu prostych zadań na nowy okres, w którym, jak mamy nadzieję, znajdzie nową drużynę. Pozytywnie wpływ na naszych doświadczonych programistów miała także praca z juniorami. Niektórzy z nich, po okresie mentorstwa, odkryli w sobie siłę i chęć spróbowania się na roli liderów zespołów, a inni, przyglądając się juniorom, podnieśli swoje umiejętności i przeszli z pozycji mid do pozycji senior.
Będziemy nadal rozwijać naszą praktykę w zatrudnianiu młodych programistów, ponieważ przynosi to wiele korzyści dla zespołu. Juniorzy mają możliwość pełnoprawnego zdalnego zatrudnienia niezależnie od miejsca zamieszkania: członkowie naszych zespołów deweloperskich żyją od Rygi po Władywostok i doskonale radzą sobie z różnicą czasową dzięki sprawnie działającym procesom w firmie. Wszystko to otwiera drzwi utalentowanym ludziom, którzy mieszkają w odległych miastach i wsiach. Mowa tutaj nie tylko o absolwentach czy studentach, ale także o osobach, które z różnych powodów postanowiły zmienić zawód. Nasz junior może mieć zarówno 18, jak i 35 lat, ponieważ junior to kwestia doświadczenia i umiejętności, a nie wieku.
Jesteśmy przekonani, że nasze podejście można śmiało zastosować również w innych firmach, które korzystają z modelu zdalnego programowania. Pozwala ono jednocześnie na precyzyjne zatrudnianie utalentowanych juniorów z dowolnego miejsca w Rosji czy WNP, a także rozwijanie umiejętności mentorskich doświadczonych programistów. W aspekcie finansowym ta historia jest bardzo niedroga, więc wszyscy odnoszą korzyści: firma, nasi programiści oraz, oczywiście, juniorzy, którzy nie muszą przeprowadzać się do dużych miast czy stolic, aby stać się częścią doświadczonego zespołu i pracować nad interesującymi projektami.
Źródło: habr.com
