3 coisas que você deve fazer quando um desenvolvedor se demite

Mesmo quando você tem uma equipe de engenharia de classe mundial, não há muito que você possa fazer para evitar a rotatividade.

Na verdade, os melhores gerentes de engenharia permanecem preparados para o dia em que um desenvolvedor aceitar uma nova oportunidade de trabalho ou decidir abrir sua própria empresa. Mas essa preparação vai muito além de uma pequena lista de pessoas...

 

Mesmo quando você tem uma equipe de engenharia de classe mundial, não há muito que você possa fazer para evitar a rotatividade. Na verdade, os melhores gerentes de engenharia permanecem preparados para o dia em que um desenvolvedor aceitar uma nova oportunidade de trabalho ou decidir abrir sua própria empresa. Mas essa preparação vai muito além de uma pequena lista de pessoas a quem recorrer sempre que você precisar preencher uma função. A maior parte do seu trabalho envolve garantir que as informações não sejam perdidas, os projetos sejam entregues no prazo e o resto da equipe não se sinta sobrecarregado.

 

Para manter o resto de sua equipe no caminho certo, aqui estão algumas coisas que os gerentes de engenharia devem fazer assim que receberem a demissão de um de seus funcionários.

 

 

Agende um tempo para criar um plano de transição

 

Mesmo que as leis trabalhistas dos Estados Unidos não exijam que você avise com duas semanas de antecedência, os desenvolvedores que quiserem sair com uma nota positiva farão isso de qualquer maneira. No caso muito provável de que o funcionário que está saindo fique por duas ou três semanas, aproveite isso e crie um plano de transição com essa pessoa.

 

Imediatamente após o programador apresentar sua renúncia, agende uma reunião para descrever seus projetos atuais, os desafios que enfrentaram para concluí-los e o trabalho que foi concluído nos últimos meses. Para evitar trabalho duplicado e criar novos problemas de documentação , peça ao seu desenvolvedor para trazer o máximo de informações possível. A partir daí, trabalhe com essa pessoa para preencher quaisquer lacunas de conhecimento restantes.

 

A princípio, pode fazer sentido notificar o restante da equipe antes de fazer qualquer outra coisa. Embora você deva alertar o grupo o mais rápido possível, ter o plano de transição em vigor antes de fazer o anúncio permitirá que você responda às perguntas de acompanhamento sobre a partida com mais facilidade.

 

Notifique a equipe e os principais interessados

 

Mais uma vez, depois de esboçar um plano de transição, não espere até a próxima reunião de equipe para compartilhar as novidades. Agende um horário separado assim que possível e certifique-se de ser explícito em seu convite sobre o que deseja discutir.

 

Use esse tempo para revisar a linha do tempo do desenvolvedor que está saindo, bem como o plano de transição que você criou. Seja claro sobre quem assumirá as responsabilidades dessa pessoa e deixe tempo para o desenvolvedor responder a quaisquer perguntas que seus colegas possam ter. Isso evitará quaisquer problemas de documentação no futuro.

 

Mas se um desenvolvedor não está saindo em boas condições e não está presente para esta reunião, não evite perguntas sobre esse cronograma acelerado. Ao mesmo tempo, resista ao impulso de se aprofundar muito nos detalhes que cercam a transição dessa pessoa.

 

Agendar sessões de acompanhamento antes da partida do funcionário

 

Anat Lechner, um professor clínico associado de administração e organizações da NYU Stern, disse à Harvard Business Review que a transferência de conhecimento é um dos componentes mais difíceis e críticos da rotatividade de funcionários . Você não apenas precisará substituir essa pessoa, mas sua equipe existente também se sentirá sobrecarregada enquanto isso. Normalmente, o acompanhamento é uma parte essencial do treinamento de engenharia de software para novos contratados. Mas Lechner diz que esse conceito também deve ser aplicado quando um desenvolvedor decide seguir em frente.

 

“Durante o período de aviso de saída do funcionário, estabeleça um 'mecanismo de sombreamento extensivo' para que aqueles que estão assumindo suas responsabilidades possam absorver o que precisam”, diz Lechner. “[A parte mais difícil] é transferir o conhecimento fixo - as coisas que um funcionário sabe que não podem necessariamente ser mostradas em uma planilha do Excel.”

 

Enquanto um desenvolvedor se prepara para sair, peça a essa pessoa que oriente seus colegas pelo código que estavam escrevendo. Quais são as nuances de seus projetos que não podem ser vistas no próprio código? Quais são os erros que ele ou ela cometeu ao longo do caminho? As respostas a essas perguntas podem tornar a vida muito mais confortável para qualquer programador que está assumindo um projeto de um ex-colega de equipe.

 

Quer compartilhar conhecimento sem repetir informações continuamente? Descubra como a comunidade Avance Network pode ajudar.


Strong

5178 Blog Mensajes

Comentarios