Quase toda a equipe de desenvolvimento da Skyeng, composta por mais de 100 pessoas, trabalha remotamente e os requisitos para especialistas sempre foram altos: procurávamos seniores, desenvolvedores full-stack e gerentes intermediários. Mas no início de 2019 contratamos pela primeira vez três juniores. Isso foi feito por vários motivos: contratar apenas superespecialistas não resolve todos os problemas e, para criar um clima saudável de desenvolvimento, são necessárias pessoas com diferentes níveis de profissionalismo.
Quando você trabalha remotamente, é extremamente importante que uma pessoa venha ao projeto e imediatamente comece a agregar valor, sem longos processos de aprendizagem ou acumulação. Isso não funciona com os juniores e, além do treinamento, também exige uma integração competente do recém-chegado à equipe, porque tudo é novo para ele. E esta é uma tarefa separada para o líder da equipe. Portanto, estávamos focados em encontrar e contratar desenvolvedores mais experientes e estabelecidos. Mas com o tempo, ficou claro que equipes compostas apenas por desenvolvedores seniores e full-stack têm seus próprios problemas. Por exemplo, quem fará tarefas rotineiras, mas obrigatórias, que não exigem superqualificações ou nenhum conhecimento especial?
Anteriormente, em vez de contratar juniores, consertávamos freelancers
Embora houvesse poucas tarefas, os nossos senhores de alguma forma cerraram os dentes e assumiram essas tarefas desinteressantes, porque o desenvolvimento deve avançar. Mas isso não poderia durar muito: os projetos cresceram, o número de tarefas simples e rotineiras aumentou. A situação começou a parecer cada vez mais uma piada quando pregos são cravados com um microscópio em vez de um martelo. Para maior clareza, você pode recorrer à aritmética: se você atrair uma pessoa cujo salário é condicional de US$ 50/hora para fazer um trabalho que um funcionário com um salário de US$ 10/hora pode realizar, então você terá problemas.
O mais importante que aprendemos com esta situação é que o paradigma atual de contratar apenas especialistas de topo não resolve os nossos problemas com tarefas rotineiras. Precisamos de alguém que esteja pronto para realizar um trabalho que os cavalheiros experientes consideram um castigo e que é simplesmente ineficaz para lhes confiar. Por exemplo, escrever bots para os chats do Slack de nossos professores e criadores de cursos, ou realizar pequenos projetos de melhoria para necessidades internas, para os quais os desenvolvedores constantemente não têm tempo suficiente, mas com os quais a vida se tornaria muito mais agradável.
Neste ponto, uma solução provisória foi desenvolvida. Começamos a envolver freelancers no trabalho em nossos projetos. Tarefas simples e não urgentes começaram a ser terceirizadas: corrigir algo em algum lugar, verificar algo, reescrever algo. Nossa ala freelancer tem crescido bastante ativamente. Um de nossos gerentes de projeto coletou tarefas de diferentes projetos e as distribuiu entre freelancers, orientados pela base existente de performers. Então pareceu-nos uma boa solução: aliviámos a carga dos seniores e eles puderam novamente criar todo o seu potencial, em vez de ficarem a brincar com algo básico. É claro que havia tarefas que, devido a segredos comerciais, não podiam ser delegadas a artistas externos, mas tais questões eram várias vezes menores em comparação com a massa de tarefas atribuídas ao freelancer.
Mas isso não poderia continuar para sempre. A empresa se deparou com o fato de que a divisão freelancer havia se transformado em um monstro desajeitado. O número de tarefas simples e rotineiras cresceu junto com os projetos e, em algum momento, havia muitas delas para serem efetivamente distribuídas entre executores externos. Além disso, o freelancer não está imerso nas especificidades dos projetos, o que é uma constante perda de tempo de onboarding. Obviamente, quando sua equipe tem mais de 100 desenvolvedores profissionais, você não pode contratar nem cinquenta freelancers para ajudá-los e gerenciar com eficácia suas atividades. Além disso, a interação com freelancers sempre envolve alguns riscos de perda de prazos e outros problemas organizacionais.
É importante observar aqui que um funcionário remoto e um freelancer são duas entidades diferentes. O trabalhador remoto está totalmente cadastrado na empresa, tem horário de trabalho designado, equipe, superiores e assim por diante. Freelancer é um trabalho baseado em projetos que é regulado principalmente por prazos. Um freelancer, ao contrário de um funcionário remoto, fica praticamente sozinho e tem pouca interação com a equipe. Daí os riscos potenciais de interagir com esses artistas.
Como criamos o “departamento de tarefas simples” e o que realizamos
Depois de analisar a situação atual, chegamos à conclusão de que precisamos de funcionários com qualificações mais baixas. Não criamos ilusões de que, dentre todos os juniores, criaríamos futuras superestrelas, ou que contratar uma dúzia de juniores nos custaria três copeques. Em geral, em termos da situação dos juniores, a realidade é esta:
- No curto prazo, não é economicamente rentável contratá-los. Em vez de cinco a dez meses de junho “agora”, é melhor pegar um veterano e pagar-lhe milhões de dinheiro por um trabalho de qualidade do que desperdiçar orçamentos com recém-chegados.
- Os juniores têm um longo período de ingresso no projeto e treinamento.
- No momento em que um júnior aprendeu alguma coisa e parece ter que começar a “trabalhar” os investimentos em si mesmo nos primeiros seis meses de trabalho, ele precisa ser promovido para médio, ou sai para esse cargo em outra empresa. Portanto, a contratação de juniores só é adequada para organizações maduras que estão dispostas a investir dinheiro neles sem garantias de lucro no curto prazo.
Mas crescemos a tal ponto que não podemos ter juniores na equipe: o número de tarefas comuns está crescendo e gastar horas de trabalho de profissionais experientes nelas é simplesmente um crime. É por isso que criamos um departamento específico para desenvolvedores juniores.
O período de trabalho no departamento de tarefas simples é limitado a três meses - ou seja, é um período probatório padrão. Depois de três meses de trabalho remunerado em tempo integral, o recém-chegado vai para uma equipe que queria vê-lo como desenvolvedor júnior ou nos separamos dele.
O departamento que criamos é chefiado por um PM experiente, responsável pela distribuição das tarefas de trabalho entre os juniores e sua interação com outras equipes. June recebe uma tarefa, conclui-a e recebe feedback da equipe e de seu gerente. Na fase de trabalho no departamento de tarefas simples, não atribuímos recém-chegados a equipes e projetos específicos - eles têm acesso a todo o conjunto de tarefas de acordo com suas habilidades (atualmente estamos contratando front-endrs AngularJS, backers PHP, ou procurando para candidatos ao cargo de desenvolvedor web com ambos os idiomas) e pode trabalhar em vários projetos ao mesmo tempo.
Mas nem tudo se limita à contratação de juniores - eles também precisam criar condições de trabalho aceitáveis, e esta é uma tarefa completamente diferente.
A primeira coisa que decidimos foi a orientação voluntária em quantidades razoáveis. Ou seja, para além de não obrigarmos nenhum dos especialistas existentes a ser mentores, ficou claramente afirmado que a formação de um recém-chegado não deve substituir o trabalho principal. Não, “50% do tempo trabalhamos, 50% ensinamos os juniores”. Para se ter uma ideia clara de quanto tempo levaria a mentoria, foi compilado um pequeno “currículo”: uma lista de tarefas que cada mentor deveria realizar com seu pupilo. O mesmo foi feito para o gerente de projeto júnior e, como resultado, obtivemos um cenário muito tranquilo e compreensível para preparar os recém-chegados e colocá-los no trabalho.
Fornecemos os seguintes pontos: teste de conhecimento teórico, preparamos um conjunto de materiais caso um júnior precise aprender alguma coisa e aprovamos um princípio unificado de realização de revisões de código para mentores. Em cada etapa, os gestores dão feedback ao recém-chegado, o que é extremamente importante para este. Um jovem colaborador entende em quais aspectos ele é forte e em quais precisa ter mais cuidado. Para simplificar o processo de aprendizagem para desenvolvedores juniores e experientes, um chat comum foi criado no Slack, para que outros membros da equipe possam participar do processo de aprendizagem e responder a uma pergunta em vez de um mentor. Tudo isso torna o trabalho com juniores um processo completamente previsível e, principalmente, controlado.
Ao final do período probatório de três meses, o mentor realiza uma entrevista técnica final com o júnior, com base nos resultados da qual é decidido se o júnior pode ou não passar para um emprego permanente em uma das equipes.
No total
À primeira vista, nosso departamento júnior parece uma incubadora ou algum tipo de caixa de areia especialmente criada. Mas, na verdade, este é um departamento real com todos os atributos de uma equipe de combate completa que resolve problemas reais e não de treinamento.
Mas o mais importante é darmos às pessoas um horizonte concreto. O departamento de tarefas simples não é um limbo sem fim no qual você pode ficar preso para sempre. Há um prazo claro de três meses durante o qual um júnior resolve problemas simples em projetos, mas ao mesmo tempo pode provar seu valor e passar para alguma equipe. Os recém-chegados que contratamos sabem que terão o seu próprio gestor de projetos, um mentor sénior (ou talvez vários) e a oportunidade de integrar plenamente a equipa, onde serão bem-vindos e bem-vindos.
Desde o início do ano, 12 juniores foram contratados na área de tarefas simples e apenas dois não passaram no período probatório. Outro rapaz não se encaixou na equipe, mas por ser muito capaz no trabalho, foi devolvido ao departamento de tarefas simples para um novo mandato, durante o qual, esperamos, encontre uma nova equipe. Trabalhar com juniores também teve um impacto positivo em nossos desenvolvedores experientes. Alguns deles, após um período de mentoria, descobriram a força e a vontade de tentar o papel de líderes de equipe; alguns, olhando para os juniores, aprimoraram seus próprios conhecimentos e passaram da posição intermediária para a posição sênior.
Só ampliaremos nossa prática de contratação de jovens desenvolvedores porque isso traz muitos benefícios para a equipe. Os juninos, por outro lado, têm a oportunidade de emprego remoto completo, independentemente da região de residência: os membros de nossas equipes de desenvolvimento moram de Riga a Vladivostok e lidam bem com a diferença de fuso horário graças a processos bem estabelecidos dentro da empresa . Tudo isso abre caminho para pessoas talentosas que vivem em cidades e vilarejos remotos. Além disso, não estamos a falar apenas dos alunos e estudantes de ontem, mas também de pessoas que, por algum motivo, decidiram mudar de profissão. Nosso júnior poderia facilmente ter 18 ou 35 anos, porque júnior tem a ver com experiência e habilidades, mas não com idade.
Estamos confiantes de que nossa abordagem pode ser facilmente estendida a outras empresas que utilizam um modelo de desenvolvimento remoto. Ao mesmo tempo, permite que você contrate especificamente juniores talentosos de qualquer lugar da Rússia ou da CEI e, ao mesmo tempo, atualize as habilidades de mentoria de desenvolvedores experientes. Em termos financeiros, essa história é extremamente barata, então todos ganham: a empresa, nossos desenvolvedores e, claro, os juniores que não precisam se mudar para grandes cidades ou capitais para fazer parte de uma equipe experiente e trabalhar em projetos interessantes .
Fonte: habr.com