Quanto custa a rotatividade de desenvolvedores em um projeto de software?

Substituir um desenvolvedor que sai no meio de um projeto custa mais do que um mês de busca. A conta real soma três partes: recrutar e contratar alguém novo, o tempo que essa pessoa nova leva para render no nível de quem saiu —quase nunca são dias, são semanas ou meses—, e o conhecimento do projeto que se perde porque mais ninguém tinha documentado em lugar nenhum. Segundo o Work Institute (Retention Report 2024, com base em mais de 20.000 entrevistas de desligamento), cada saída voluntária custa em média para a empresa o equivalente a 33% do salário anual dessa pessoa, e esse número sobe quanto mais crítico é o conhecimento que vai embora com ela.

Em um projeto de software, essa conta costuma ficar aquém. Os times costumam ser pequenos, cada pessoa acaba sendo dona de uma parte grande do sistema, e perder alguém não abre só uma vaga: também trava o milestone em que essa pessoa estava trabalhando até que outra pessoa entenda aquela parte do código.

O que é exatamente a rotatividade de desenvolvedores em um projeto (e em que difere da rotatividade geral de uma empresa)?

A rotatividade de desenvolvedores que importa para um projeto em andamento não é a métrica anual que o RH acompanha —quantas pessoas do time de engenharia saíram no ano—, mas algo mais pontual: alguém com uma fatia específica do contexto do projeto sair antes de terminar os milestones que tinha sob sua responsabilidade. Acontece com um funcionário interno que pede demissão, com um freelancer que consegue um contrato melhor pago e corta a relação de um dia para o outro, e com um integrante de um time terceirizado que a consultoria realoca para outro cliente sem aviso. O resultado é o mesmo nos três casos: o projeto perde a pessoa que entendia por que determinada decisão de arquitetura foi tomada ou o que foi testado com o cliente e não funcionou, bem na hora em que essa informação importa.

Quanto tempo leva para um substituto render no mesmo nível da pessoa que saiu?

Mais do que costuma ser planejado. A DX, plataforma de métricas de produtividade de engenharia usada por centenas de times, mede o tempo até o décimo pull request de uma pessoa nova como proxy de quando ela começa a render de verdade: esse número caiu de 86 dias no primeiro trimestre de 2024 para 33 dias no fim de 2025, graças sobretudo à adoção de ferramentas de IA no onboarding. Mesmo com essa melhora, ainda é mais de um mês de ramp-up real antes de alguém novo contribuir no ritmo do resto do time —e esse mês não é tempo morto: é tempo em que o resto do squad precisa explicar o projeto em vez de avançá-lo.

Que conhecimento se perde quando alguém sai no meio do projeto?

O problema não é só o tempo de ramp-up: boa parte do que essa pessoa sabia nunca esteve escrito em lugar nenhum. Segundo o Workplace Knowledge and Productivity Report da Panopto (2018), um estudo com mais de 1.000 trabalhadores dos EUA, 42% do conhecimento que alguém usa no dia a dia da sua função é exclusivo dessa pessoa —mais ninguém no time aprendeu ou documentou aquilo. Quando essa pessoa sai, esse 42% não se transfere sozinho: precisa ser reconstruído, quase sempre reconstruindo primeiro um problema que já tinha sido resolvido uma vez.

• Por que uma decisão de arquitetura foi tomada e quais alternativas já haviam sido descartadas
• O que foi testado com o cliente e não funcionou, para não repetir
• O estado real de um milestone que “já está quase pronto” segundo a última reunião
• O acesso e o conhecimento operacional dos serviços que só aquela pessoa mexia

Por que o desenvolvimento de software tem mais rotatividade do que quase qualquer outra indústria?

Não é um problema novo nem exclusivo desta década: já em 2017 o software liderava a rotatividade entre todas as indústrias analisadas pelo LinkedIn, com 13,2% ao ano (LinkedIn Workforce Report, 2018) —resultado combinado de uma escassez de talento técnico que ainda não foi resolvida e de um mercado de trabalho remoto que torna muito mais fácil trocar de projeto sem trocar de cidade. Esse padrão estrutural é o outro lado de um problema que já cobrimos em detalhe: a maioria dos times tem um bus factor mais baixo do que imagina, justamente na indústria onde é mais provável que alguém-chave saia.

Um squad que já trabalhou junto absorve melhor uma saída do que um freelancer ou uma consultoria montada para o projeto?

Quando um freelancer corta a relação, não há mais ninguém para herdar o contexto dele —é preciso começar do zero com outra pessoa. Uma consultoria que monta um time novo para cada cliente também não parte de um lugar muito diferente: se alguém desse time sai, o resto ainda está construindo o terreno comum que faz o conhecimento circular em vez de se acumular em uma única cabeça.

Um squad que já entregou projetos juntos antes parte com esse terreno comum já construído: as decisões de arquitetura, o padrão de código e o contexto do cliente já circularam entre várias pessoas em projetos anteriores. Isso não torna ninguém insubstituível —nenhum time é— mas reduz quanto se perde quando uma pessoa específica sai, porque o conhecimento nunca dependeu de uma única cabeça para começar.

Como proteger um projeto da rotatividade sem conseguir evitá-la totalmente?

Nenhuma plataforma ou processo elimina a possibilidade de alguém sair. O que dá para controlar é quanto do que essa pessoa sabia sobrevive à saída dela. Isso passa por duas coisas: o avanço do projeto ficar documentado como evidência verificável —quem fez o quê, em qual milestone, sob qual critério de aceitação— em vez de viver só na cabeça de uma pessoa e nas reuniões que ela participou, e o time que você contratou ter, desde o vetting inicial, uma forma comprovada de responder se alguém específico deixar de estar disponível.

Na Zenit isso é resolvido com duas peças do mesmo sistema: o ZenitRank verifica o histórico de cumprimento de cada squad antes de ele aparecer como opção em um match, e se um squad não consegue continuar um projeto em andamento, o mecanismo de Squad B backup transfere o contexto acumulado até aquele ponto para outro time em vez de reiniciar o projeto do zero.

A rotatividade no desenvolvimento de software não vai cair sozinha. A pergunta que você pode controlar antes de assinar um projeto é se o time que você vai contratar já construiu, em outros projetos, uma forma de o conhecimento sobreviver à saída de alguém.