Téměř celý vývojový tým Skyeng, který se skládá z více než 100 lidí, pracuje na dálku a požadavky na specialisty byly vždy vysoké: hledali jsme seniory, fullstack vývojáře a střední manažery. Ale na začátku roku 2019 jsme poprvé angažovali tři juniory. Stalo se tak z několika důvodů: najímání pouze superspecialistů nevyřeší všechny problémy a pro vytvoření zdravé atmosféry ve vývoji jsou zapotřebí lidé různé úrovně profesionality.
Když pracujete na dálku, je nesmírně důležité, aby člověk přišel do projektu a okamžitě začal poskytovat hodnotu, bez jakýchkoli dlouhých procesů učení nebo budování. To u juniorů nejde, navíc to kromě tréninku vyžaduje i kompetentní začlenění nováčka do týmu, protože je pro něj všechno nové. A to je samostatný úkol pro vedení týmu. Proto jsme se zaměřili na vyhledávání a najímání zkušenějších a zavedených vývojářů. Postupem času se ale ukázalo, že týmy tvořené pouze seniory a fullstackovými vývojáři mají své vlastní problémy. Kdo bude například dělat rutinní, ale povinné úkoly, které nevyžadují super kvalifikaci ani žádné speciální znalosti?
Dříve jsme místo najímání juniorů fušovali do freelancerů
Zatímco úkolů bylo málo, naši pánové tak nějak zatnuli zuby a ujali se těchto nezajímavých úkolů, protože vývoj musí jít dopředu. To však nemohlo pokračovat dlouho: projekty rostly, rostl počet rutinních jednoduchých úkolů. Situace se začala stále více podobat vtipu, kdy se místo kladiva zatloukají hřebíky mikroskopem. Pro upřesnění se můžete obrátit na aritmetiku: pokud přilákáte osobu, jejíž sazba je podmíněných 50 USD/hodinu, aby vykonal práci, kterou zvládne zaměstnanec se sazbou 10 USD/hodinu, pak máte problémy.
To nejdůležitější, co jsme si z této situace vzali, je, že současné paradigma najímání pouze špičkových specialistů neřeší naše problémy s rutinními úkoly. Potřebujeme někoho, kdo bude připraven dělat práci, kterou ostřílení pánové vnímají jako trest a kterou je prostě neefektivní jim svěřovat. Například psaní botů pro Slack chaty našich učitelů a tvůrců kurzů nebo řešení malých zlepšovacích projektů pro interní potřeby, na které vývojáři neustále nemají dostatek času, ale se kterými by se život stal mnohem příjemnějším.
V tomto okamžiku bylo vyvinuto provizorní řešení. Do práce na našich projektech jsme začali zapojovat freelancery. Do takového outsourcingu začaly chodit jednoduché a neurgentní úkoly: někde něco opravit, něco zkontrolovat, něco přepsat. Naše křídlo na volné noze se poměrně aktivně rozrůstá. Jeden z našich projektových manažerů sbíral úkoly z různých projektů a rozděloval je mezi freelancery, přičemž se řídil stávající základnou účinkujících. Pak se nám to zdálo jako dobré řešení: ubrali jsme seniorům zátěž a oni mohli zase tvořit naplno, místo toho, abychom si pohrávali s něčím základním. Samozřejmě existovaly úkoly, které kvůli obchodnímu tajemství nemohly být delegovány na externí umělce, ale takových záležitostí bylo několikanásobně méně ve srovnání s množstvím úkolů, které jdou na volné noze.
To ale nemohlo pokračovat donekonečna. Společnost se potýkala s tím, že se divize na volné noze proměnila v nemotorné monstrum. Počet rutinních jednoduchých úkolů rostl spolu s projekty a v určitém okamžiku jich bylo příliš mnoho na to, aby je bylo možné efektivně rozdělit mezi externí umělce. Navíc freelancer není ponořený do specifik projektů a to je neustálá ztráta času na onboardingu. Je zřejmé, že když má váš tým více než 100 profesionálních vývojářů, nemůžete si najmout ani padesát nezávislých pracovníků, aby jim pomohli a efektivně řídili jejich aktivity. Navíc interakce s nezávislými pracovníky vždy zahrnuje určitá rizika nedodržení termínů a dalších organizačních problémů.
Zde je důležité poznamenat, že vzdálený zaměstnanec a nezávislý pracovník jsou dvě různé entity. Vzdálený pracovník je plně registrován u společnosti, má určenou pracovní dobu, tým, nadřízené a tak dále. Freelancer je projektová práce, která je převážně regulována pouze termíny. Nezávislý pracovník, na rozdíl od vzdáleného zaměstnance, je většinou ponechán svému osudu a má malou interakci s týmem. Z toho plynou potenciální rizika při interakci s takovými umělci.
Jak jsme se dostali k vytvoření „oddělení jednoduchých úkolů“ a čeho jsme dosáhli
Po rozboru současné situace jsme došli k závěru, že potřebujeme zaměstnance nižší kvalifikace. Nedělali jsme si iluze, že ze všech juniorů vychováme budoucí superhvězdy, nebo že najmutí tuctu juniorů nás bude stát tři kopejky. Obecně platí, že pokud jde o situaci s juniory, realita je taková:
- Krátkodobě není ekonomicky výhodné je najímat. Místo pěti až deseti červnů „hned“ je lepší vzít jednoho seniora a zaplatit mu miliony peněz za kvalitní práci, než plýtvat rozpočty na nováčky.
- Junioři mají dlouhé období vstupu do projektu a tréninku.
- Ve chvíli, kdy se junior něco naučil a zdá se, že v prvních šesti měsících práce na sobě musí začít „odpracovávat“ investice, je třeba povýšit na střední, nebo odchází na tuto pozici do jiné firmy. Najímání juniorů je tedy vhodné pouze pro vyspělé organizace, které jsou připraveny do nich investovat peníze bez záruk zisku v krátkodobém horizontu.
Dospěli jsme ale do bodu, kdy nemůžeme mít v týmu juniory: počet běžných úkolů roste a trávit na nich člověkohodiny ostřílených profesionálů je prostě zločin. Proto jsme vytvořili oddělení speciálně pro junior vývojáře.
Doba práce na oddělení jednoduchých úkolů je omezena na tři měsíce – jedná se tedy o standardní zkušební dobu. Po třech měsících placené práce na plný úvazek jde nováček buď do týmu, který ho chtěl vidět ve svých řadách jako junior developera, nebo se s ním rozcházíme.
Námi vytvořené oddělení vede zkušený PM, který zodpovídá za rozdělování pracovních úkolů mezi juniory a jejich interakci s ostatními týmy. June dostane úkol, splní ho a dostane zpětnou vazbu od týmu i od svého manažera. Ve fázi práce v oddělení jednoduchých úkolů nepřiřazujeme nováčky do konkrétních týmů a projektů - mají přístup k celému fondu úkolů podle svých dovedností (aktuálně najímáme front-endry AngularJS, PHP backery nebo hledáme pro kandidáty na pozici webový vývojář s oběma jazyky) a může pracovat na více projektech najednou.
Vše se ale neomezuje jen na najímání juniorů – i ti potřebují vytvořit přijatelné pracovní podmínky, a to je úplně jiný úkol.
První věc, pro kterou jsme se rozhodli, byl dobrovolný mentoring v rozumné výši. Tedy kromě toho, že jsme nikoho ze stávajících specialistů nenutili mentorovat, bylo jasně řečeno, že zaškolení nováčka by se nemělo stát náhradou hlavního zaměstnání. Žádné „50 % času pracujeme, 50 % učíme juniory“. Abychom měli jasnou představu o tom, kolik času mentoring zabere, byl sestaven malý „kurikulum“: seznam úkolů, které musel každý mentor se svým svěřencem splnit. Totéž bylo provedeno pro juniorského projektového manažera a výsledkem byl velmi hladký a srozumitelný scénář pro přípravu nováčků a jejich uvedení do práce.
Zajistili jsme následující body: otestování teoretických znalostí, připravili sadu materiálů, pokud se junior potřebuje něco naučit, a schválili jednotný princip provádění code review pro mentory. V každé fázi dávají manažeři zpětnou vazbu nováčkovi, což je pro něj nesmírně důležité. Mladý zaměstnanec chápe, ve kterých aspektech je silný a ve kterých je třeba být opatrnější. Pro zjednodušení procesu učení pro juniory a zkušené vývojáře byl ve Slacku vytvořen společný chat, aby se ostatní členové týmu mohli zapojit do procesu učení a odpovědět na otázku místo mentora. To vše dělá z práce s juniory zcela předvídatelný a hlavně kontrolovaný proces.
Na konci tříměsíční zkušební doby vede mentor s juniorem závěrečný technický pohovor, na základě jehož výsledků se rozhodne, zda junior může přejít do stálého zaměstnání v některém z týmů či nikoliv.
Celkem
Naše juniorské oddělení na první pohled vypadá jako inkubátor nebo nějaké speciálně vytvořené pískoviště. Ale ve skutečnosti se jedná o skutečné oddělení se všemi atributy plnohodnotného bojového týmu, které řeší skutečné, nikoli výcvikové problémy.
Nejdůležitější ale je, abychom lidem poskytli konkrétní obzor. Oddělení jednoduchých úkolů není nekonečným limbem, ve kterém můžete uvíznout navždy. Je tam jasná lhůta tří měsíců, během kterých junior řeší jednoduché problémy na projektech, ale zároveň se může osvědčit a přejít do nějakého týmu. Nováčci, které najímáme, vědí, že budou mít vlastního projektového manažera, senior mentora (nebo možná několik) a možnost plně se zapojit do týmu, kde budou vítáni a vítáni.
Od začátku roku bylo na oddělení jednoduchých úkolů přijato 12 juniorů, pouze dva neprošli zkušební dobou. Další kluk se do kolektivu nevešel, ale jelikož je pracovně velmi schopný, byl vrácen na oddělení jednoduchých úkolů na nové období, během kterého, jak doufáme, najde nový tým. Práce s juniory měla pozitivní dopad i na naše zkušené vývojáře. Někteří z nich po období mentoringu objevili sílu a chuť vyzkoušet si roli týmových lídrů, někteří si při pohledu na juniory zdokonalili své znalosti a posunuli se z pozice střední na pozici seniora.
Naši praxi najímání mladých vývojářů budeme pouze rozšiřovat, protože to týmu přináší mnoho výhod. Junes má naopak možnost plnohodnotného zaměstnání na dálku bez ohledu na region svého bydliště: členové našich vývojových týmů žijí od Rigy po Vladivostok a dobře se vyrovnávají s časovým posunem díky zefektivnění procesů uvnitř společnosti. To vše otevírá cestu talentovaným lidem, kteří žijí v odlehlých městech a vesnicích. Navíc mluvíme nejen o včerejších školácích a studentech, ale také o lidech, kteří se z nějakého důvodu rozhodli změnit svou profesi. Našemu juniorovi by stejně klidně mohlo být buď 18 nebo 35 let, protože junior je o zkušenostech a dovednostech, ale ne o věku.
Jsme přesvědčeni, že náš přístup lze snadno rozšířit na další společnosti, které používají model vzdáleného vývoje. Zároveň vám umožňuje konkrétně najímat talentované juniory odkudkoli z Ruska nebo SNS a zároveň zlepšovat mentorské dovednosti zkušených vývojářů. Z finančního hlediska je tento příběh extrémně levný, takže vyhrává každý: společnost, naši vývojáři a samozřejmě junioři, kteří se nemusí stěhovat do velkých měst nebo hlavních měst, aby se stali součástí zkušeného týmu a pracovali na zajímavých projektech .
Zdroj: www.habr.com