Quasi tutto il team di sviluppo di Skyeng, composto da oltre 100 persone, lavora in remoto e le richieste per gli specialisti 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 diverse ragioni: assumere solo super-specialisti non risolve tutti i problemi, e per creare un'atmosfera sana nello sviluppo sono necessarie persone di vari livelli di professionalità.
Quando lavori da remoto, è fondamentale che una persona possa entrare nel progetto e iniziare a dare il proprio contributo immediatamente, senza lunghe fasi di apprendimento e ambientamento. Con i junior non è possibile, e oltre alla formazione è necessaria anche una corretta integrazione del nuovo nel team, dato che tutto è nuovo per lui. Questo è già un compito a parte per il team leader. Perciò ci siamo concentrati sulla ricerca e assunzione di sviluppatori più esperti e già affermati. Tuttavia, col tempo è emerso che nei team composti esclusivamente da senior e sviluppatori fullstack ci sono delle problematiche. Ad esempio, chi si occuperà delle attività routinarie, ma necessarie, che non richiedono super qualifiche o conoscenze particolari?
In passato, invece di assumere junior, abbiamo lavorato con freelance.
Fino a poco fa, i nostri senior si sobbarcavano con fastidio queste noiose attività, poiché lo sviluppo doveva andare avanti. Ma non poteva continuare così a lungo: i progetti crescevano e le mansioni routinarie e semplici aumentavano. La situazione cominciava a somigliare sempre di più a una barzelletta, quando i chiodi vengono piantati con un microscopio invece che con un martello. Per chiarezza, possiamo usare un semplice calcolo: se coinvolgi una persona il cui tasso orario è di 50$ e la fai lavorare su compiti per i quali basterebbe una persona che guadagna 10$ all'ora, allora hai un problema.
La cosa più importante che abbiamo appreso da questa situazione è che l'attuale paradigma di assumere solo specialisti di alto livello non risolve i nostri problemi con le mansioni routine. Abbiamo bisogno di qualcuno disposto a svolgere compiti che i senior esperti percepiscono come una punizione e che delegarli a loro risulta semplicemente inefficace. Ad esempio, scrivere bot per le chat Slack dei nostri insegnanti e autori di corsi o far fronte a piccoli progetti di miglioramento per esigenze interne, per i quali i programmatori non hanno mai tempo, ma di cui la vita sarebbe molto più piacevole.
In questo momento è stata trovata una soluzione provvisoria. Abbiamo iniziato a coinvolgere dei freelance nei nostri progetti. Le attività semplici e non urgenti venivano affidate all'esterno: sistemare qualcosa, controllare, riscrivere. Il nostro team di freelance cresceva con notevole rapidità. Uno dei nostri project manager raccoglieva compiti da diversi progetti e li assegnava ai freelance, utilizzando la sua base di dati di esecutori. All'epoca ci sembrava una buona soluzione: abbiamo alleggerito il carico sui senior, che potevano tornare a esprimere la loro creatività a pieno ritmo, anziché dedicarsi a compiti elementari. Ovviamente, c'erano progetti che non potevano essere affidati a esecutori esterni a causa della riservatezza commerciale, ma tali casi erano di gran lunga inferiori rispetto al numero di task che venivano delegati ai freelance.
Ma proseguire così per sempre non era possibile. L'azienda si è trovata a fronteggiare il fatto che la divisione freelance si era trasformata in un mostro ingombrante. Il numero di compiti routinari e semplici è aumentato insieme ai progetti e, a un certo punto, sono diventati troppi per poterli gestire in modo efficace attraverso i collaboratori esterni. Inoltre, i freelance non sono immersi nelle specifiche dei progetti, il che comporta una costante perdita di tempo per l'onboarding. È evidente che, quando nella tua squadra ci sono oltre 100 sviluppatori professionisti, non puoi assumere nemmeno una cinquantina di freelancer per aiutarli e gestire efficacemente le loro attività. Inoltre, collaborare con i freelance comporta sempre alcuni rischi riguardo il rispetto delle scadenze e altri problemi organizzativi.
È importante sottolineare che un lavoratore remoto e un freelance sono due entità diverse. Il lavoratore remoto è regolarmente assunto dall'azienda, ha orari di lavoro stabiliti, un team, un supervisore e così via. Un freelance, invece, lavora su progetti e le sue attività sono principalmente regolamentate dalle scadenze. A differenza del lavoratore remoto, il freelance è in gran parte autonomo e interagisce poco con il team. Da qui derivano anche i potenziali rischi nell'interazione con tali esecutori.
Come siamo arrivati a creare il 'reparto delle attività semplici' e cosa abbiamo realizzato
Analizzando la situazione attuale, siamo giunti alla conclusione che avevamo bisogno di dipendenti di qualifiche più basse. Non abbiamo mai nutrito illusioni sul fatto che da tutti i junior avremmo formato futuri supereroi, o che assumere una decina di junior ci sarebbe costato poco. In realtà, la situazione con i junior è questa:
- A breve termine, assumerli non è economicamente vantaggioso. Invece di cinque-dieci junior 'subito', è meglio prendere un senior e pagargli milioni per un lavoro di qualità, piuttosto che sprecare budget con i novizi.
- Per i junior, c'è un lungo periodo di integratione nel progetto e di formazione.
- Nel momento in cui un junior ha appreso qualcosa e sembra dover iniziare a «restituire» gli investimenti fatti su di lui nei primi sei mesi di lavoro, deve essere promosso a mid-level, oppure lascia per quella posizione in un'altra azienda. Pertanto, l'assunzione di junior è adatta 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 ordinari cresce, e spendere ore uomo di esperti professionisti per svolgerli è semplicemente un crimine. È proprio per questo motivo che abbiamo creato un reparto specifico per gli sviluppatori junior.
Il periodo di lavoro nel reparto delle attività semplici è limitato a tre mesi, ovvero è il periodo standard di prova. Dopo tre mesi di lavoro retribuito, il neofita viene o assegnato a un team che ha voluto vederlo tra le proprie fila come sviluppatore junior, oppure ci separiamo.
Alla guida del nostro dipartimento c'è un esperto PM, responsabile della distribuzione dei compiti ai junior e della loro interazione con gli altri team. Il junior riceve un compito, lo svolge e riceve feedback sia dal team che dal suo manager. Nella fase di lavoro nel dipartimento, non assegniamo compiti semplici a specifici team e progetti per i neofiti — hanno accesso all'intero pool di compiti in base alle loro capacità (attualmente stiamo assumendo front-end developer su AngularJS, back-end developer su PHP o stiamo cercando candidati per la posizione di sviluppatore web con entrambe le lingue) e possono lavorare contemporaneamente su più progetti.
Ma l'assunzione di junior non è tutto — è necessario creare anche condizioni di lavoro adeguate, e questo è già un compito di natura completamente diversa.
La prima cosa su cui abbiamo concordato è il mentoring volontario in volumi sostenibili. In altre parole, oltre a non costringere nessuno a intraprendere il mentoring con esperti esistenti, abbiamo chiarito che la formazione di un neofita non deve sostituire il lavoro principale. Niente di «lavoriamo 50% del tempo, 50% insegniamo ai junior». Per avere un'idea chiara di quanto tempo sarà dedicato al mentoring, è stato elaborato un piccolo «piano di studi»: un elenco di compiti che ogni mentore doveva completare con il proprio protetto. Lo stesso è stato fatto per il project manager dei junior, e alla fine abbiamo ottenuto uno scenario di preparazione dei neofiti e del loro ingresso nel lavoro molto fluido e comprensibile.
Abbiamo previsto i seguenti aspetti: verifica delle conoscenze teoriche, preparazione di un insieme di materiali, nel caso in cui il junior necessiti di ulteriori chiarimenti, abbiamo stabilito un principio uniforme per lo svolgimento delle revisioni del codice per i mentori. In ogni fase, i responsabili forniscono feedback al neofita, il che è estremamente importante. Il giovane professionista comprende in quali aree è forte e in quali deve prestare maggiore attenzione. Per semplificare il processo di apprendimento per i junior e gli sviluppatori esperti, è stato creato un canale comune su Slack, così altri membri del team possono intervenire per rispondere a domande al posto del mentore. Tutto ciò rende il lavoro con i junior un processo piuttosto prevedibile e, cosa fondamentale, controllabile.
Al termine del periodo di prova di tre mesi, il mentore svolge un colloquio tecnico finale con il junior, i cui risultati determinano se il junior può passare a un contratto a tempo indeterminato in uno dei team o meno.
Totale
A prima vista, il nostro reparto per junior sembra un incubatore o una sorta di sandbox appositamente creata. Ma in realtà è un vero dipartimento con tutte le caratteristiche di un team operativo completo, che affronta problemi reali e non solo esercizi.
Ma la cosa più importante è che offriamo alle persone un orizzonte concreto. Il reparto dei compiti semplici non è un limbo infinito in cui si può rimanere bloccati per sempre. C'è una scadenza chiara di tre mesi, entro i quali il junior affronta compiti semplici nei progetti, ma nel frattempo ha la possibilità di dimostrare il proprio valore e di passare a un altro team. I neolaureati che assumiamo sanno che avranno un project manager dedicato, un mentore senior (o magari più di uno) e l'opportunità di integrarsi pienamente in un gruppo accogliente che li aspetta.
Dall'inizio dell'anno, nel reparto delle semplici attività sono stati assunti 12 giovani talenti; solo due non hanno superato il periodo di prova. Un altro ragazzo non si è integrato nel gruppo, ma poiché dal punto di vista lavorativo è molto capace, è stato reintegrato nel reparto delle semplici attività per un nuovo periodo, durante il quale speriamo possa trovare un nuovo team. Il lavoro con i junior ha avuto un impatto positivo anche sui nostri sviluppatori più esperti. Alcuni di loro, dopo un periodo di mentoring, hanno scoperto dentro di sé la forza e la voglia di provare a ricoprire il ruolo di team leader, mentre altri, osservando i junior, hanno aggiornato le proprie conoscenze e sono passati da una posizione di middle a quella di senior.
Continueremo a espandere la nostra pratica di assunzione di giovani sviluppatori, poiché questo offre numerosi vantaggi per il team. I junior hanno l'opportunità di un'occupazione remota completa, indipendentemente dalla loro regione di residenza: i membri dei nostri team di sviluppo vivono da Riga a Vladivostok e gestiscono brillantemente le differenze di fuso orario grazie a processi ben collaudati all'interno dell'azienda. Tutto ciò apre la strada a persone talentuose che vivono in città e paesi remoti. Si tratta non solo di neolaureati e studenti, ma anche di persone che hanno deciso di cambiare professione per qualche motivo. Il nostro junior può avere ugualmente 18 o 35 anni, poiché il junior riguarda l'esperienza e le competenze, ma non l'età.
Siamo certi che il nostro approccio possa essere tranquillamente applicato anche ad altre aziende che utilizzano il modello di sviluppo remoto. Permette infatti di assumere talentuosi junior da qualsiasi parte della Russia o della CSI, mentre si sviluppano anche le competenze di mentoring dei programmatori esperti. Dal punto di vista finanziario, questa storia è molto conveniente, quindi tutti ci guadagnano: l’azienda, i nostri sviluppatori e, naturalmente, i junior, che non devono trasferirsi in grandi città o capitali per far parte di un team esperto e lavorare su progetti interessanti.
Fonte: habr.com
