Quasi tutto il team di sviluppo di Skyeng, composto da oltre 100 persone, lavora in remoto e le richieste nei confronti dei professionisti sono sempre state elevate: cercavamo senior, sviluppatori fullstack e mid-level. Ma all'inizio del 2019 abbiamo assunto per la prima volta tre junior. Questo è stato fatto per diversi motivi: assumere solo super-specialisti non risolve tutti i problemi e per creare un'atmosfera sana nello sviluppo sono necessarie persone di diversi livelli di professionalità.
Quando lavori in remoto, è estremamente importante che una persona arrivi al progetto e inizi subito a portare valore, senza lunghi processi di formazione e acclimatamento. Con i junior questo non è possibile, inoltre, oltre alla formazione, è necessaria anche una corretta integrazione del neofita nel team, dato che è tutto nuovo per lui. E questa è già una sfida specifica per il team leader. Pertanto, ci siamo concentrati sulla ricerca e assunzione di sviluppatori più esperti e già affermati. Ma col tempo si è scoperto che nei team composti solo da senior e sviluppatori fullstack ci sono i propri problemi. Ad esempio, chi si occuperà delle attività routinarie, ma necessarie, che non richiedono super-qualificazioni o conoscenze particolari?
In passato, anziché assumere junior, ci occupavamo di freelance.
Finché ci sono state poche attività, i nostri senior hanno affrontato a denti stretti queste mansioni poco interessanti per loro, poiché lo sviluppo deve andare avanti. Ma non poteva continuare a lungo in questo modo: i progetti crescevano e il numero di semplici attività routinarie aumentava. La situazione cominciava sempre più a somigliare a una barzelletta, in cui i chiodi vengono infissi con un microscopio anziché con un martello. Per chiarezza, possiamo considerare l'aritmetica: se assumi una persona il cui tasso orario è di 50$/ora per lavorare a compiti che possono essere svolti da un dipendente con un tasso di 10$/ora, hai un problema.
La cosa più importante che abbiamo imparato da questa situazione è che l'attuale paradigma di assunzione di soli esperti non risolve i nostri problemi con i compiti di routine. Abbiamo bisogno di qualcuno pronto a fare il lavoro che i senior esperti considerano una punizione e che è semplicemente inefficace affidare a loro. Ad esempio, scrivere bot per le chat Slack dei nostri insegnanti e creatori di corsi o occuparsi di piccoli progetti di miglioramento per esigenze interne, per i quali gli sviluppatori non hanno mai tempo, ma la cui presenza renderebbe la vita molto più piacevole.
In quel momento è stata elaborata una soluzione intermedia. Abbiamo iniziato a coinvolgere freelancer nei nostri progetti. Le attività semplici e non urgenti sono state esternalizzate: modifiche qui e là, verifiche, riscrivere qualcosa. Il nostro ramo freelance è cresciuto abbastanza attivamente. Uno dei nostri project manager raccoglieva compiti da diversi progetti e li distribuiva ai freelancer, basandosi su una banca di artisti disponibile. All'epoca ci sembrava una buona soluzione: alleggerimmo il carico sui senior e potevano tornare a creare a pieno ritmo, invece di districarsi con questioni banali. Certo, esistevano compiti che non potevano essere affidati a esperti esterni a causa della riservatezza commerciale, ma tali casi erano notevolmente inferiori rispetto al numero di compiti affidati al freelance.
Ma questo non poteva durare per sempre. L'azienda ha affrontato il fatto che il dipartimento freelance si era trasformato in un mostro ingombrante. Il numero di compiti semplici e di routine è aumentato insieme ai progetti e a un certo punto erano diventati troppi per essere gestiti in modo efficace da esperti esterni. Inoltre, il freelancer non è immerso nella specificità dei progetti, il che comporta sempre una perdita di tempo per l'onboarding. È evidente che quando nel tuo team ci sono più di 100 sviluppatori professionisti, non puoi assumere nemmeno una cinquantina di freelancer e gestire efficacemente le loro attività. Inoltre, interagire con freelancer comporta sempre alcuni rischi di ritardi e altri problemi organizzativi.
È importante sottolineare che un lavoratore remoto e un freelance sono due entità diverse. Il lavoratore remoto è formalmente assunto dall'azienda, ha orari di lavoro definiti, un team, un capo e così via. Il freelance, invece, lavora su progetti che sono regolati principalmente solo dalle scadenze. A differenza del lavoratore remoto, il freelance è per lo più autonomo e interagisce poco con il team. Da qui derivano i potenziali rischi nell'interazione con questi professionisti.
Come siamo arrivati alla creazione del "dipartimento dei compiti semplici" e cosa abbiamo ottenuto
Analizzando la situazione, siamo arrivati alla conclusione che abbiamo bisogno di personale di qualifica inferiore. Non avevamo illusioni sul fatto che da tutti i junior avremmo creato delle future superstar, o che assumere un certo numero di junior ci sarebbe costato molto poco. In effetti, la situazione con i junior è la seguente:
- A breve termine, assumerli non è economicamente conveniente. Invece di cinque-dieci junior "proprio ora", è meglio prendere un senior e pagargli milioni per un lavoro di qualità, piuttosto che spendere budget per i novizi.
- I junior hanno un lungo periodo di inserimento nel progetto e di apprendimento.
- Nel momento in cui un junior impara qualcosa e dovrebbe iniziare a "ripagare" gli investimenti fatti in lui nei primi sei mesi di lavoro, deve essere promosso a mid-level, altrimenti lascia per quella posizione in un'altra azienda. Pertanto, assumere junior è adatto solo a organizzazioni mature che sono pronte a investire in loro senza garanzie di profitto a breve termine.
Ma siamo cresciuti a tal punto che non possiamo fare a meno dei junior nel team: il numero di compiti routinari aumenta, e spendere ore lavorative di professionisti esperti per farli è semplicemente un crimine. È per questo che abbiamo creato un dipartimento dedicato in particolare agli sviluppatori junior.
Il periodo di lavoro nel dipartimento dei compiti semplici è limitato a tre mesi, cioè è il termine di prova standard. Dopo tre mesi di lavoro retribuito, il neofita viene inserito nel team che lo ha voluto come junior developer, oppure ci congediamo.
A capo del reparto da noi creato c'è un esperto PM, responsabile della distribuzione dei task tra i junior e delle loro interazioni con altri team. Il junior riceve un task, lo esegue e riceve feedback sia dal team che dal proprio manager. Nella fase del lavoro nel reparto, non assegnamo compiti semplici ai principianti in specifici team e progetti: hanno accesso a tutto il pool di task in base alle loro competenze (attualmente stiamo assumendo front-end developer con AngularJS, back-end developer con PHP o stiamo cercando candidati per la posizione di sviluppatore web con entrambi i linguaggi) e possono lavorare immediatamente su diversi progetti.
Ma l'assunzione di junior non si limita a questo: è necessario creare anche condizioni di lavoro adeguate, e questo è già un compito di un piano completamente diverso.
La prima cosa su cui ci siamo concentrati è stata la mentorship volontaria in misura ragionevole. Cioè, oltre al fatto che non abbiamo costretto nessuno a diventare mentore tra i professionisti esistenti, è stato chiaramente stabilito che la formazione del nuovo membro non deve sostituire il lavoro principale. Niente "50% del tempo lavoriamo, 50% insegnamo al junior". Per avere un'idea chiara di quanto tempo occorresse per la mentorship, è stato stilato un piccolo "piano di studi": un elenco di compiti che ogni mentore doveva far completare al proprio protetto. La stessa cosa è stata fatta per il project manager dei junior, e alla fine abbiamo ottenuto uno scenario di preparazione dei nuovi membri molto fluido e comprensibile e il loro ingresso nel lavoro.
Abbiamo previsto i seguenti aspetti: verifica delle conoscenze teoriche, preparato un insieme di materiali da utilizzare se il junior ha bisogno di approfondire, e confermato un principio unico per la conduzione del code review per i mentori. In ogni fase, i leader forniscono feedback al nuovo membro, il che è estremamente importante per quest'ultimo. Il giovane dipendente comprende in quali aspetti è forte e in quali deve prestare maggiore attenzione. Per semplificare il processo di formazione per i junior e gli sviluppatori esperti, è stato creato un chat comune su Slack, così che anche altri membri del team possano unirsi al processo di apprendimento e rispondere a domande al posto del mentore. Tutto ciò rende il lavoro con i junior un processo piuttosto prevedibile e, ciò che è importante, controllabile.
Al termine del periodo di prova di tre mesi, il mentore conduce un colloquio tecnico finale con il junior, al termine del quale si decide se il junior può passare a un lavoro permanente in uno dei team oppure no.
Totale
A prima vista, il nostro dipartimento per i junior sembra un incubatore o una sorta di sandbox creata appositamente. Ma in realtà è un vero dipartimento con tutte le caratteristiche di un team operativo, che affronta compiti reali e non solo esercizi.
Ma la cosa più importante è che diamo alle persone un orizzonte concreto. Il dipartimento dei compiti semplici non è un limbo infinito in cui si può rimanere bloccati per sempre. C'è una chiara scadenza di tre mesi, entro i quali il junior risolve compiti semplici sui progetti, ma può anche dimostrare il suo valore e passare in un altro team. I nuovi assunti sanno che avranno un project manager, un mentore tra i senior (e forse anche più di uno) e la possibilità di integrarsi completamente nel gruppo, dove saranno accolti e attesi.
Dall'inizio dell'anno, nel dipartimento dei compiti semplici sono stati assunti 12 junior, solo due non hanno superato il periodo di prova. Un altro ragazzo non si è adattato al gruppo, ma poiché era molto capace nel suo lavoro, è stato reintegrato nel dipartimento dei compiti semplici per un nuovo periodo, durante il quale, speriamo, troverà un nuovo team. Il lavoro con i junior ha avuto un effetto positivo anche sui nostri sviluppatori più esperti. Alcuni di loro, dopo il periodo di mentoring, hanno scoperto in loro stessi la forza e il desiderio di provare a diventare team leader, mentre altri, osservando i junior, hanno migliorato le proprie conoscenze e sono passati da una posizione di middle a quella di senior.
Espanderemo solo la nostra pratica di assunzione di giovani sviluppatori, poiché ciò offre numerosi vantaggi al team. I giovanissimi hanno così l'opportunità di impiego remoto completo, indipendentemente dalla propria zona di residenza: i membri dei nostri team di sviluppo vivono da Riga a Vladivostok e gestiscono perfettamente la differenza di fuso orario grazie a processi ben organizzati all'interno dell'azienda. Tutto ciò apre la strada a persone talentuose che vivono in piccole città e borghi. E non si tratta solo di neolaureati e studenti, ma anche di persone che hanno deciso di cambiare carriera per qualche motivo. Il nostro junior può avere con successo sia 18 che 35 anni, perché junior significa esperienza e competenze, non età.
Siamo convinti che il nostro approccio possa essere tranquillamente applicato anche ad altre aziende che utilizzano un modello di sviluppo remoto. Questo permette di assumere in modo mirato talentuosi junior da qualsiasi parte della Russia o della CIS, e al contempo migliorare le competenze di mentoring degli sviluppatori esperti. Dal punto di vista finanziario, questa situazione è estremamente conveniente, quindi tutti ne traggono vantaggio: l'azienda, i nostri sviluppatori e, naturalmente, i junior, che non devono trasferirsi nelle grandi città o capitali per diventare parte di un team esperto e lavorare su progetti interessanti.
Fonte: habr.com
