We creëren een afdeling van junioren ter ondersteuning van de belangrijkste teams, met alleen Slack, Jira en blauwe tape.

Het merendeel van het ontwikkelingsteam van Skyeng, dat uit meer dan 100 personen bestaat, werkt op afstand en de eisen aan specialisten waren altijd hoog: we zochten senioren, fullstack-developers en mediors. Maar begin 2019 hebben we voor het eerst drie juniors aangenomen. Dit was om verschillende redenen: alleen super-specialisten aannemen lost niet alle problemen op, en voor een gezonde sfeer in de ontwikkeling zijn mensen van verschillende niveaus van professionaliteit nodig.

Wanneer je op afstand werkt, is het van cruciaal belang dat iemand het project binnenkomt en meteen waarde toevoegt, zonder lange leertijd en inwerktijden. Met juniors lukt dit niet, bovendien is naast training ook een goede integratie van de nieuwkomer in het team nodig, aangezien alles nieuw voor hem is. Dit is al een aparte taak voor de teamleider. Daarom waren we gefocust op het zoeken en aannemen van meer ervaren en gevestigde developers. Maar na verloop van tijd bleek dat teams die alleen uit senioren en fullstack-ontwikkelaars bestaan ook hun problemen hebben. Bijvoorbeeld, wie zorgt voor de routinetaken die weliswaar noodzakelijk zijn maar geen super kwalificaties of speciale kennis vereisen?

Vroeger stelden we het aannemen van juniors uit en werkten we met freelancers.

In de periode dat er nog maar een paar taken waren, hebben onze seniors met de tanden op elkaar die saaie taken aangepakt, want ontwikkeling moet vooruitgaan. Maar dit kon niet lang zo doorgaan: de projecten groeiden, het aantal routinetaken nam toe. De situatie ging steeds meer op een grap lijken, waarbij spijkers met een microscoop in plaats van met een hamer werden ingeslagen. Ter illustratie kunnen we naar de rekenkunde kijken: als je een persoon met een tarief van zeg $50/uur voor taken inschakelt die een werknemer met een tarief van $10/uur kan uitvoeren, dan heb je problemen.

Het belangrijkste dat we uit deze situatie hebben geleerd, is dat de huidige paradigma van het inhuren van alleen de beste specialisten onze problemen met routinetaken niet oplost. We hebben iemand nodig die bereid is het werk te doen dat ervaren senioren als een straf beschouwen en dat hen simpelweg ondoeltreffend is om aan te besteden. Bijvoorbeeld, het schrijven van bots voor de Slack-chats van onze docenten en cursusontwerpers, of het doen van kleine verbeterprojecten voor interne behoeften, waar ontwikkelaars altijd geen tijd voor hebben, maar waarvan het leven veel aangenamer zou worden.

Op dat moment werd er een tussenoplossing ontwikkeld. We begonnen freelancers in te schakelen voor onze projecten. Precies voor dit soort uitbesteding gingen eenvoudige en niet-dringende taken verloren: ergens iets corrigeren, ergens controleren, iets herschrijven. Onze freelance-afdeling groeide vrij actief. Een van onze projectmanagers verzamelde taken van verschillende projecten en verdeelde ze onder de freelancers, gebaseerd op de bestaande database van uitvoerders. Toen leek ons dit een goede oplossing: we verlichtten de druk op de senioren en zij konden weer volop creëren, in plaats van zich met elementaire zaken bezig te houden. Natuurlijk waren er taken die door commerciële geheimen niet aan externe uitvoerders konden worden overgedragen, maar die vragen waren vele malen minder in vergelijking met de massa taken die naar freelancers gingen.

Maar dit kon niet eeuwig doorgaan. Het bedrijf werd geconfronteerd met het feit dat de freelance-afdeling een log monster was geworden. Het aantal routinetaken groeit samen met de projecten en op een gegeven moment waren ze te veel om effectief te verdelen over externe uitvoerders. Bovendien raakt een freelancer niet vertrouwd met de specificiteit van de projecten, wat constante tijdsverspilling op onboarding met zich meebrengt. Het is duidelijk dat wanneer je 100+ professionele ontwikkelaars in je team hebt, je zelfs niet een halve eeuw aan freelancers kunt inhuren om hen te helpen en hun activiteiten effectief kunt beheren. Bovendien zijn er altijd risico's verbonden aan samenwerken met freelancers, zoals het mislopen van deadlines en andere organisatorische problemen.

Het is belangrijk om te benadrukken dat een remote medewerker en een freelancer twee verschillende entiteiten zijn. Een remote werknemer is volledig in dienst bij het bedrijf, heeft een gedefinieerde werktijd, een team, leidinggevenden, enzovoort. Een freelancer werkt projectmatig en wordt voornamelijk alleen gereguleerd door deadlines. In tegenstelling tot een remote werknemer staat een freelancer meestal op zichzelf en heeft hij weinig interactie met het team. Hieruit volgen de potentiële risico's van samenwerking met dergelijke uitvoerders.

Hoe we zijn gekomen tot het creëren van de 'afdeling eenvoudige taken' en wat we hebben bereikt

Na een analyse van de huidige situatie kwamen we tot de conclusie dat we medewerkers van een lagere kwalificatie nodig hebben. We hebben geen illusies gehad over het idee dat we uit alle junioren toekomstige supersterren zouden kunnen laten groeien, of dat het inhuren van een dozijn junioren ons een schijntje zou kosten. De realiteit met betrekking tot junioren is als volgt:

1. Op korte termijn is het economisch onvoordelig om hen in te huren. In plaats van vijf tot tien junioren 'nu meteen' is het beter om één senior aan te nemen en hem miljoenen te betalen voor kwalitatief werk dan om budgetten te besteden aan beginners.
2. Junioren hebben een langdurige inwerktijd en training nodig.
3. Op het moment dat een junior iets heeft geleerd en eigenlijk moet beginnen met het 'terugverdienen' van de investeringen in zichzelf na de eerste zes maanden werk, moet hij worden gepromoveerd tot mid-level, of hij vertrekt naar een andere organisatie. Dus het inhuren van junioren is alleen geschikt voor volwassen organisaties die bereid zijn in hen te investeren zonder garanties voor korte termijn winst.

Maar we zijn gegroeid tot een omvang waarin we niet meer zonder junioren in het team kunnen: het aantal eenvoudige taken groeit, en het is gewoon crimineel om ervaren professionals hier uren aan te laten besteden. Daarom hebben we een afdeling speciaal voor junior-ontwikkelaars opgericht.

De periode van werk in de afdeling eenvoudige taken is beperkt tot drie maanden - dat is de standaard proeftijd. Na drie maanden betaald werk gaat de nieuwkomer ofwel naar het team dat hem als junior-ontwikkelaar wil verwelkomen, of we gaan uit elkaar.

Aan het hoofd van onze opgezet afdeling staat een ervaren PM, die verantwoordelijk is voor de verdeling van werkopdrachten onder de junioren en hun interactie met andere teams. De junior ontvangt een taak, voert deze uit en krijgt feedback, zowel van het team als van zijn manager. In de fase van het werken binnen de afdeling wijzen we beginners niet aan specifieke teams en projecten toe — ze hebben toegang tot de volledige pool van taken op basis van hun vaardigheden (momenteel werven we front-end ontwikkelaars met AngularJS, back-end ontwikkelaars met PHP of zoeken we kandidaten voor de functie van webontwikkelaar met beide talen) en kunnen tegelijkertijd aan meerdere projecten werken.

Maar het werven van junioren is niet alles — het is ook noodzakelijk om voor hen acceptabele arbeidsomstandigheden te creëren, en dat is al een taak van een heel andere orde.

Het eerste waar we ons over hebben uitgesproken, is vrijwillige mentoring in gezonde hoeveelheden. Dit betekent dat we niemand verplichten tot mentoring door bestaande specialisten, en het was duidelijk aangegeven dat de opleiding van de nieuwkomer geen vervanging voor het hoofdwerk mag zijn. Geen "50% van de tijd werken, 50% leren aan de junior". Om een duidelijk idee te hebben van hoe veel tijd de mentoring zou kosten, is er een klein 'onderwijsplan' opgesteld: een lijst met taken die elke mentor moest voltooien met zijn protegé. Hetzelfde is gedaan voor de projectmanager van de junioren, en uiteindelijk hebben we een zeer soepel en duidelijk scenario voor de opleiding van de nieuwkomers en hun integratie in het werk gekregen.

We hebben de volgende punten overwogen: controle van theoretische kennis, we hebben een set materialen voorbereid voor het geval de junior iets moet bijleren, en we hebben een uniforme aanpak voor het uitvoeren van code-reviews voor mentoren vastgesteld. Op elk niveau geven de leidinggevenden feedback aan de nieuwkomer, wat cruciaal is voor de laatste. De jonge medewerker begrijpt in welke aspecten hij sterk is en waar hij aandachtiger moet zijn. Om het leerproces voor junioren en ervaren ontwikkelaars te vereenvoudigen, is er een gezamenlijke chat in Slack aangemaakt, zodat ook andere leden van het team kunnen deelnemen aan het leerproces en een vraag kunnen beantwoorden in plaats van de mentor. Dit alles maakt het werken met junioren een voorspelbaar en, wat belangrijk is, beheersbaar proces.

Na het afronden van de drie maanden durende proefperiode voert de mentor een finale technische interview met de junior, op basis waarvan wordt beslist of de junior permanent kan doorgaan naar een van de teams of niet.

Total

Op het eerste gezicht lijkt onze afdeling voor junioren op een broedplaats of een speciaal ontworpen zandbak. Maar in werkelijkheid is het een echte afdeling met alle kenmerken van een volwaardige operationele team dat echte, en geen trainingstaken oplost.

Maar het belangrijkste is dat we mensen een duidelijk perspectief bieden. De afdeling voor eenvoudige taken is geen eindeloos limbo waar je voor altijd vast kunt komen te zitten. Er is een duidelijke termijn van drie maanden waarin de junior eenvoudige taken op projecten uitvoert, maar tegelijkertijd de kans krijgt om zich te bewijzen en naar een team te gaan. De nieuwelingen die we aannemen, weten dat ze een projectmanager, een mentor van senioren (en misschien meerdere) zullen hebben en de mogelijkheid om volledig in de teamcultuur te integreren, waar ze welkom zijn en verwacht worden.

Sinds het begin van het jaar zijn er 12 junioren aangenomen in de afdeling voor eenvoudige taken, waarvan slechts twee de proefperiode niet hebben doorstaan. Nog een jongen paste niet in het team, maar omdat hij op het werk zeer capabel is, is hij teruggebracht naar de afdeling voor eenvoudige taken voor een nieuwe termijn, waarvoor we hopen dat hij een nieuw team zal vinden. De samenwerking met junioren heeft ook een positieve invloed gehad op onze ervaren ontwikkelaars. Sommigen van hen hebben, na een periode van mentorschap, de kracht en de wens ontdekt om de rol van teamleider uit te proberen, terwijl anderen, kijkend naar de junioren, hun eigen kennis hebben verbeterd en zijn overgestapt van de middenpositie naar de seniorpositie.

Wij zullen onze praktijk van het aannemen van jonge ontwikkelaars alleen maar verder uitbreiden, omdat dit tal van voordelen voor het team biedt. Junioren hebben de mogelijkheid tot volwaardig remote werk, ongeacht hun woonregio: de leden van onze ontwikkelingsteams wonen van Riga tot Vladivostok en kunnen goed omgaan met het tijdsverschil dankzij de gestroomlijnde processen binnen het bedrijf. Dit opent de deur voor getalenteerde mensen die in afgelegen steden en dorpen wonen. Het gaat hierbij niet alleen om net-afgestudeerden en studenten, maar ook om mensen die om de een of andere reden van carrière willen veranderen. Onze junior kan net zo goed 18 als 35 jaar oud zijn, want junior gaat over ervaring en vaardigheden, niet over leeftijd.

Wij zijn ervan overtuigd dat onze aanpak ook rustig kan worden toegepast op andere bedrijven die het model van remote ontwikkeling gebruiken. Het stelt ons in staat om gericht getalenteerde junioren vanuit elke uithoek van Rusland of de GOS aan te nemen, terwijl ervaren ontwikkelaars hun mentorvaardigheden verder ontwikkelen. Financieel gezien is dit verhaal uiterst goedkoop, waardoor iedereen profiteert: het bedrijf, onze ontwikkelaars en natuurlijk de junioren, die niet naar grote steden of hoofdplaatsen hoeven te verhuizen om deel uit te maken van een ervaren team en te werken aan interessante projecten.

Bron: habr.com