Case todo o equipo de desenvolvemento de Skyeng, formado por máis de 100 persoas, traballa de forma remota e os requisitos de especialistas sempre foron altos: buscabamos maiores, desenvolvedores full-stack e xestores intermedios. Pero a principios de 2019, contratamos a tres mozos por primeira vez. Isto fíxose por varias razóns: contratar só superespecialistas non resolve todos os problemas e, para crear un ambiente saudable no desenvolvemento, necesítanse persoas de diferentes niveis de profesionalidade.
Cando traballas de forma remota, é extremadamente importante que unha persoa acuda ao proxecto e comece inmediatamente a aportar valor, sen ningún proceso de aprendizaxe ou acumulación longos. Isto non funciona cos xuvenís, ademais, ademais de adestrar, tamén require unha integración competente do recén chegado no equipo, porque todo é novo para el. E esta é unha tarefa separada para o líder do equipo. Polo tanto, centrámonos en atopar e contratar desenvolvedores máis experimentados e establecidos. Pero co paso do tempo, quedou claro que os equipos formados só por persoas maiores e desenvolvedores de pila completa teñen os seus propios problemas. Por exemplo, quen fará tarefas rutinarias pero obrigatorias que non requiran super cualificacións nin ningún coñecemento especial?
Anteriormente, en lugar de contratar mozos, xogabamos con autónomos
Aínda que eran poucas as tarefas, os nosos señores dalgunha maneira apertaron os dentes e asumiron estas tarefas pouco interesantes, porque o desenvolvemento debe avanzar. Pero isto non puido continuar por moito tempo: os proxectos creceron, aumentou o número de tarefas sinxelas rutineiras. A situación comezou a parecerse cada vez máis á broma cando se meten os cravos cun microscopio en lugar de cun martelo. Para máis claridade, podes recurrir á aritmética: se atraes a unha persoa cuxa tarifa é de 50 $/hora condicional para que faga un traballo que un empregado cunha taxa de 10 $/hora pode xestionar, entón tes problemas.
O máis importante que aprendemos desta situación é que o paradigma actual de contratar só especialistas de primeira liña non soluciona os nosos problemas coas tarefas rutineiras. Necesitamos alguén que estea preparado para facer un traballo que os cabaleiros experimentados perciben como un castigo e que simplemente é ineficaz encomendalos. Por exemplo, escribir bots para os chats de Slack dos nosos profesores e creadores de cursos, ou abordar pequenos proxectos de mellora para necesidades internas, para os que os desenvolvedores constantemente non teñen tempo suficiente, pero cos que a vida sería moito máis agradable.
Neste punto, desenvolveuse unha solución provisional. Comezamos a involucrar a autónomos nos nosos proxectos. Tarefas sinxelas e non urxentes comezaron a ir a este tipo de subcontratación: corrixir algo nalgún lugar, comprobar algo, reescribir algo. A nosa á de freelance está a crecer de forma bastante activa. Un dos nosos xestores de proxectos recolleu tarefas de diferentes proxectos e distribuíunas entre autónomos, guiados pola base de intérpretes existente. Entón pareceunos unha boa solución: quitámoslles a carga aos maiores e puideron de novo crear todo o seu potencial, en lugar de xogar con algo básico. Por suposto, houbo tarefas que, debido a segredos comerciais, non se podían delegar en intérpretes externos, pero tales cuestións eran varias veces menores en comparación coa masa de tarefas que se dedican ao freelance.
Pero isto non podía continuar para sempre. A empresa enfrontouse ao feito de que a división freelance se converteu nun monstro torpe. O número de tarefas sinxelas rutineiras creceu xunto cos proxectos e nalgún momento houbo demasiadas para distribuílas de forma eficaz entre os intérpretes externos. Ademais, un autónomo non está inmerso nas especificidades dos proxectos, e isto é unha constante perda de tempo na incorporación. Obviamente, cando o teu equipo ten máis de 100 desenvolvedores profesionais, non podes contratar nin sequera cincuenta autónomos para axudarlles e xestionar eficazmente as súas actividades. Ademais, a interacción con autónomos sempre implica algúns riscos de perder prazos e outros problemas organizativos.
É importante ter en conta aquí que un empregado remoto e un autónomo son dúas entidades diferentes. Un traballador remoto está totalmente rexistrado na empresa, ten horarios de traballo designados, un equipo, superiores, etc. Freelancer é un traballo baseado en proxectos que está regulado principalmente por prazos. Un autónomo, a diferenza dun empregado remoto, déixase na súa maioría aos seus propios dispositivos e ten pouca interacción co equipo. De aí os riscos potenciais de interactuar con tales artistas.
Como chegamos a crear o "departamento de tarefas sinxelas" e que logramos
Despois de analizar a situación actual, chegamos á conclusión de que necesitamos empregados de menor cualificación. Non nos fixemos ilusións de que de entre todos os xuvenís levantaríamos futuras superestrellas, nin de que contratar unha ducia de xuvenís custaríanos tres copeques. En xeral, a realidade cos xuvenís é a seguinte:
- A curto prazo non resulta rendible economicamente contratalos. En lugar de cinco ou dez xuños "agora mesmo", é mellor levar a un ancián e pagarlle millóns de cartos por un traballo de calidade que malgastar os orzamentos en recén chegados.
- Os xuvenís teñen un longo período de entrada no proxecto e formación.
- No momento no que un júnior aprende algo e parece que debe comezar a "traballar" os seus investimentos nos primeiros seis meses de traballo, ten que ascender a medio ou marcha a este posto noutra empresa. Polo tanto, a contratación de mozos só é adecuada para organizacións maduras que están listas para investir nelas sen garantías de obter beneficios a curto prazo.
Pero chegamos ata o punto de que non podemos ter xuvenís no equipo: o número de tarefas ordinarias está a crecer e gastar nelas as horas de traballo de profesionais experimentados é simplemente un delito. É por iso que creamos un departamento especificamente para desenvolvedores júnior.
O período de traballo no departamento de tarefas simples está limitado a tres meses, é dicir, este é un período de proba estándar. Despois de tres meses de traballo remunerado a tempo completo, o recén chegado ou vai a un equipo que quería velo nas súas filas como desenvolvedor júnior, ou nos separamos del.
O departamento que creamos está dirixido por un PM experimentado, que se encarga de repartir as tarefas de traballo entre os mozos e a súa interacción con outros equipos. June recibe unha tarefa, complétaa e recibe comentarios tanto do equipo como do seu director. Na fase de traballo no departamento de tarefas simples, non asignamos novos chegados a equipos e proxectos específicos: teñen acceso a todo o conxunto de tarefas segundo as súas habilidades (actualmente estamos contratando front-endrs de AngularJS, patrocinadores de PHP ou buscando para candidatos ao posto de desenvolvedor web con ambas as dúas linguas) e pode traballar en varios proxectos á vez.
Pero todo non se limita a contratar mozos, tamén necesitan crear condicións de traballo aceptables, e esta é unha tarefa completamente diferente.
O primeiro que decidimos foi unha titoría voluntaria en cantidades razoables. É dicir, ademais de que non obrigamos a ningún dos especialistas existentes a ser mentor, afirmábase claramente que a formación dun recén chegado non debía converterse nunha substitución do traballo principal. Non "o 50% do tempo traballamos, o 50% do tempo ensinamos ao menor". Para ter unha idea clara de canto tempo levaría a titoría, recompilouse un pequeno "currículo": unha lista de tarefas que cada mentor tiña que completar co seu aprendiz. Fíxose o mesmo co director de proxecto júnior e, como resultado, recibimos un escenario moi suave e comprensible para preparar aos recén chegados e poñelos no traballo.
Proporcionamos os seguintes puntos: proba dos coñecementos teóricos, preparamos un conxunto de materiais se un alumno necesita aprender algo e aprobamos un principio unificado para realizar revisións de código para mentores. En cada etapa, os xestores danlle feedback ao recén chegado, o que é moi importante para este último. Un empregado novo entende en que aspectos é forte e en que ten que ter máis coidado. Para simplificar o proceso de aprendizaxe para os máis novos e os desenvolvedores experimentados, creouse un chat común en Slack, para que outros membros do equipo poidan unirse ao proceso de aprendizaxe e responder a unha pregunta en lugar de a un mentor. Todo isto fai que traballar con xuvenís sexa un proceso completamente previsible e, sobre todo, controlado.
Ao final do período de proba de tres meses, o mentor realiza unha entrevista técnica final co júnior, en función dos resultados da cal se decide se o júnior pode pasar a un posto de traballo fixo nun dos equipos ou non.
En total
A primeira vista, o noso departamento de menores parece unha incubadora ou algún tipo de caixa de area creada especialmente. Pero, de feito, este é un departamento real con todos os atributos dun equipo de combate completo que resolve problemas reais, non de adestramento.
Pero o máis importante é que lle demos á xente un horizonte concreto. O departamento de tarefas sinxelas non é un limbo infinito no que podes quedar atrapado para sempre. Hai un prazo claro de tres meses durante os cales un júnior resolve problemas sinxelos en proxectos, pero ao mesmo tempo pode demostrarse e pasar a algún equipo. Os recén chegados que contratamos saben que terán o seu propio xefe de proxecto, un mentor senior (ou quizais varios) e a oportunidade de unirse plenamente ao equipo, onde serán benvidos e benvidos.
Desde comezos de curso, no departamento de tarefas sinxelas contribúen a 12 júnior, só dous non superaron o período de proba. Outro rapaz non encaixaba no equipo, pero como é moi capaz de traballo, foi devolto ao departamento de tarefas sinxelas para un novo mandato, durante o cal, esperamos, atopará un novo equipo. Traballar con mozos tamén tivo un impacto positivo nos nosos desenvolvedores experimentados. Algúns deles, despois dun período de mentoría, descubriron a forza e as ganas de probar o papel de xefes de equipo; algúns, mirando aos xuvenís, melloraron os seus propios coñecementos e pasaron da posición de medio á posición de senior.
Só ampliaremos a nosa práctica de contratar desenvolvedores novos porque aporta moitos beneficios ao equipo. Junes, por outra banda, ten a oportunidade de realizar un emprego remoto completo, independentemente da súa rexión de residencia: os membros dos nosos equipos de desenvolvemento viven desde Riga ata Vladivostok e afrontan ben a diferenza horaria grazas aos procesos simplificados dentro da empresa. Todo isto abre o camiño para persoas talentosas que viven en cidades e aldeas remotas. Ademais, non só falamos dos escolares e estudantes de onte, senón tamén de persoas que, por algún motivo, decidiron cambiar de profesión. O noso júnior podería ter ben 18 ou 35 anos, porque o júnior trata de experiencia e habilidades, pero non de idade.
Confiamos en que o noso enfoque pode estenderse facilmente a outras empresas que utilizan un modelo de desenvolvemento remoto. Simultáneamente, permítelle contratar específicamente mozos talentosos de calquera lugar de Rusia ou da CEI e, ao mesmo tempo, actualizar as habilidades de mentoría dos desenvolvedores experimentados. En termos económicos, esta historia é moi barata, polo que todos gañan: a empresa, os nosos desenvolvedores e, por suposto, os mozos que non teñen que mudarse a grandes cidades ou capitais para formar parte dun equipo experimentado e traballar en proxectos interesantes. .
Fonte: www.habr.com