Quase toda a equipe de desenvolvimento da Skyeng, composta por mais de 100 pessoas, trabalha remotamente e as exigências para os profissionais sempre foram altas: procurávamos seniores, desenvolvedores fullstack e intermediários. Mas no início de 2019, contratamos pela primeira vez três juniores. Isso foi feito por várias razões: contratar apenas superespecialistas não resolve todos os problemas, e para criar uma atmosfera saudável no desenvolvimento, precisamos de pessoas de diferentes níveis de profissionalismo.
Quando você trabalha remotamente, é extremamente importante que a pessoa chegue ao projeto e comece a trazer valor imediatamente, sem longos processos de treinamento e adaptação. Com juniores não é bem assim, além de precisar de treinamento, é necessário também uma integração adequada do novato na equipe, pois tudo é novo para ele. E isso já é uma tarefa separada para o líder de equipe. Portanto, estávamos focados em encontrar e contratar desenvolvedores mais experientes e já estabelecidos. Mas com o tempo ficou claro que, em equipes compostas apenas por seniores e desenvolvedores fullstack, existem problemas próprios. Por exemplo, quem vai lidar com tarefas rotineiras, mas obrigatórias, que não requerem superqualificações ou conhecimentos especiais?
Antes, em vez de contratar juniores, nós lidávamos com freelancers.
Enquanto as tarefas eram poucas, nossos seniores, com algum esforço, aceitavam essas tarefas que não eram interessantes para eles, pois o desenvolvimento precisava avançar. Mas isso não poderia durar muito tempo: os projetos cresciam e a quantidade de tarefas rotineiras e simples aumentava. A situação começou a se assemelhar cada vez mais a uma piada, onde pregos são martelados com um microscópio em vez de um martelo. Para ilustrar, podemos olhar a aritmética: se você contrata uma pessoa cujo valor é de 50$/hora para trabalhos que poderiam ser realizados por um funcionário com valor de 10$/hora, então você tem um problema.
A coisa mais importante que aprendemos com essa situação é que a atual paradigma de contratar apenas especialistas excelentes não resolve nossos problemas com tarefas rotineiras. Precisamos de alguém disposto a realizar o trabalho que experientes seniores consideram um fardo e que delegá-los é simplesmente ineficiente. Por exemplo, escrever bots para os chats Slack de nossos professores e criadores de cursos ou lidar com pequenos projetos de melhorias para necessidades internas, que os desenvolvedores estão sempre sem tempo, mas cuja vida se tornaria muito mais agradável.
Nesse momento, foi desenvolvido uma solução intermediária. Começamos a envolver freelancers em nossos projetos. Essas tarefas simples e não urgentes começaram a ser delegadas para a terceirização: corrigir alguma coisa aqui e ali, revisar, reescrever. Nossa equipe de freelancers crescia de maneira bastante ativa. Um dos nossos gerentes de projeto reunia tarefas de diferentes projetos e distribuía para os freelancers, com base em um banco de dados de executores existente. Na época, parecia uma boa solução: aliviamos a carga dos seniores e eles podiam novamente criar livremente, em vez de se ocuparem com algo elemental. Claro, havia tarefas que não podiam ser passadas para executores externos devido a segredos comerciais, mas essas questões eram muito menos em comparação com a massa de tarefas enviadas para freelancers.
Mas isso não poderia continuar para sempre. A empresa enfrentou o fato de que o departamento de freelancers se tornou um monstro lento. A quantidade de tarefas rotineiras simples cresceu junto com os projetos e, em algum momento, tornou-se grande demais para que pudéssemos distribuí-las de forma eficaz entre os executores externos. Além disso, o freelancer não está imerso na especificidade dos projetos, o que gera uma constante perda de tempo em treinamento. É evidente que, quando sua equipe tem mais de 100 desenvolvedores profissionais, você não pode contratar nem mesmo meia centena de freelancers e gerenciar sua atividade de forma eficaz. Além disso, a interação com freelancers sempre envolve alguns riscos de atrasos e outros problemas organizacionais.
É importante destacar que um funcionário remoto e um freelancer são duas entidades distintas. O empregado remoto está plenamente registrado na empresa, possui um horário de trabalho definido, uma equipe, supervisores e assim por diante. O freelancer, por sua vez, trabalha por projeto, regulado, em sua maioria, apenas por prazos. Diferente do funcionário remoto, o freelancer na maioria das vezes está à sua própria mercê e tem pouca interação com a equipe. Daí surgem os potenciais riscos ao interagir com esses profissionais.
Como chegamos à criação do "departamento de tarefas simples" e o que conseguimos
Ao analisar a situação, chegamos à conclusão de que precisávamos de funcionários de qualificação mais baixa. Não tínhamos ilusões de que, entre todos os juniores, iríamos formar futuras estrelas, ou que contratar uma dezena de juniores nos custaria uma bagatela. Na realidade, a situação com juniores é a seguinte:
- A curto prazo, contratar juniores não é economicamente viável. Em vez de cinco a dez juniores "imediatamente", é melhor contratar um sênior e pagar-lhe milhões por um trabalho de qualidade do que gastar orçamentos com novatos.
- Juniores têm um longo período de adaptação ao projeto e treinamento.
- No momento em que um júnior aprende algo e supostamente deve começar a "retornar" o investimento em si nos primeiros seis meses de trabalho, ele precisa ser promovido a médio, ou ele irá para essa posição em outra empresa. Portanto, contratar juniores é apropriado apenas para organizações maduras que estão dispostas a investir neles sem garantias de retorno no curto prazo.
Mas chegamos a um ponto em que sem juniores na equipe não dá: a quantidade de tarefas rotineiras está aumentando, e gastar horas de profissionais experientes para elas é simplesmente um crime. Por isso, criamos um departamento especificamente para desenvolvedores juniores.
O período de trabalho no departamento de tarefas simples é limitado a três meses — ou seja, é o prazo padrão de experiência. Após três meses de trabalho remunerado, o novato ou é encaminhado para a equipe que desejou vê-lo como desenvolvedor júnior, ou nós nos separamos dele.
À frente do departamento que criamos está um PM experiente, responsável pela distribuição de tarefas aos juniores e sua interação com outras equipes. O júnior recebe uma tarefa, a executa e recebe feedback tanto da equipe quanto do seu gerente. Na fase de trabalho no departamento, não amarramos os novatos 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-enders em AngularJS, back-enders em PHP ou procurando candidatos para a posição de desenvolvedor web com ambas as linguagens) e podem trabalhar em vários projetos ao mesmo tempo.
Mas a contratação de juniores não se resume a isso — é necessário criar condições de trabalho adequadas, e essa já é uma tarefa completamente diferente.
A primeira coisa que definimos foi o mentorado voluntário em volumes razoáveis. Ou seja, além do fato de que não forçamos ninguém a ser mentor entre os especialistas existentes, ficou claro que o treinamento do novato não deveria substituir o trabalho principal. Nada de "50% do tempo trabalhando, 50% ensinando o júnior". Para ter uma ideia clara de quanto tempo seria necessário para a mentoria, foi elaborado um pequeno "plano de estudos": uma lista de tarefas que cada mentor deveria realizar com seu pupilo. O mesmo foi feito para o gerente de projeto dos juniores, e no final conseguimos um cenário bastante suave e compreensível para a integração dos novatos ao trabalho.
Levamos em conta os seguintes aspectos: verificação de conhecimentos teóricos, preparação de um conjunto de materiais, caso o júnior precise aprender algo mais, e aprovamos um princípio único para a realização de code review para os mentores. Em cada etapa, os líderes oferecem feedback ao novato, o que é extremamente importante para ele. O jovem funcionário entende em quais aspectos é forte e em quais deve prestar mais atenção. Para simplificar o processo de aprendizado para juniores e desenvolvedores experientes, foi criado um chat comum no Slack, para que outros membros da equipe possam se juntar ao processo de aprendizado e responder a alguma dúvida em vez do mentor. Tudo isso torna o trabalho com os juniores um processo bastante previsível e, o que é importante, controlável.
Após o término do período experimental de três meses, o mentor realiza uma entrevista técnica final com o júnior, a partir da qual se decide se o júnior pode ser efetivado em uma das equipes ou não.
Total
À primeira vista, nosso departamento para juniores se assemelha a um incubadora ou a uma espécie de caixa de areia especialmente criada. Mas, na verdade, é um departamento real com todos os atributos de uma equipe operacional completa que resolve tarefas reais, e não apenas simuladas.
Mas o mais importante é que oferecemos às pessoas um horizonte concreto. O departamento de tarefas simples não é um limbo infinito onde se pode ficar preso para sempre. Existe um prazo claro de três meses durante o qual o júnior resolve tarefas simples em projetos, mas ao mesmo tempo tem a chance de se destacar e passar para alguma equipe. Os novatos que contratamos sabem que terão seu próprio gerente de projeto, um mentor da equipe sênior (ou até mais de um) e a oportunidade de realmente se integrar à equipe, onde serão bem-vindos e esperados.
Desde o início do ano, 12 juniores foram contratados para o departamento de tarefas simples, e apenas dois não conseguiram passar pelo período experimental. Outro rapaz não se adaptou ao ambiente, mas como ele é muito capaz em termos de trabalho, foi reintegrado ao departamento de tarefas simples por um novo prazo, durante o qual, esperamos, ele encontre uma nova equipe. A interação com os juniores também teve um impacto positivo em nossos desenvolvedores experientes. Alguns deles, após o período de mentoria, descobriram suas forças e o desejo de tentar assumir papéis de liderança, enquanto outros, observando os juniores, aprimoraram seus próprios conhecimentos e foram promovidos de suas posições de médio para sêniores.
Nós vamos continuar expandindo nossa prática de contratação de jovens desenvolvedores, pois isso traz muitos benefícios para a equipe. Os juniores têm a oportunidade de trabalhar remotamente, independentemente de onde moram: nossos membros das equipes de desenvolvimento vivem desde Riga até Vladivostok e lidam bem com a diferença de fuso horário devido a processos bem estabelecidos dentro da empresa. Tudo isso abre portas para talentos que vivem em cidades e vilarejos remotos. E não estamos falando apenas de estudantes e recém-formados, mas também de pessoas que decidiram mudar de profissão por algum motivo. Nosso júnior pode ter tanto 18 quanto 35 anos, já que ser júnior é sobre experiência e habilidades, e não sobre idade.
Estamos certos de que nosso método pode ser facilmente replicado por outras empresas que utilizam o modelo de desenvolvimento remoto. Ele permite a contratação pontual de juniores talentosos de qualquer lugar da Rússia ou da CEI, e ao mesmo tempo aprimora as habilidades de mentoria dos desenvolvedores mais experientes. Financeiramente, esse modelo é extremamente acessível, beneficiando a todos: 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
