Quanto tempo uma equipe de desenvolvimento nova leva para ser produtiva? O custo de ramp-up que quase ninguém orçamenta

Uma equipe de desenvolvimento recém-formada leva, em média, entre várias semanas e cerca de cinco meses para chegar ao seu ritmo real de entrega —não no dia em que começa a escrever código, mas no dia em que deixa de perder tempo entendendo o sistema, o negócio e as próprias pessoas com quem precisa se coordenar. A pesquisa disponível sobre cargos profissionais em geral situa esse período em até 20 semanas (Rollag, Parise & Cross, MIT Sloan Management Review, 2005). Para uma equipe inteira —não uma única pessoa— o mesmo problema se repete, multiplicado por cada pessoa nova que precisa ser integrada ao mesmo tempo.

Esse tempo de ramp-up quase nunca aparece em uma proposta comercial nem no cronograma de um projeto. Ele é pago em semanas de menor output, código que precisa ser revisado duas vezes e decisões que demoram mais do que o esperado —não porque a equipe seja ruim, mas porque ela ainda não conhece o terreno. A maior parte do que existe escrito sobre isso é pensada para o RH —checklists de onboarding, planos de 30-60-90 dias—, não para a empresa que precisa decidir, antes de assinar, qual modelo de contratação minimiza esse custo.

O que é exatamente o ramp-up de uma equipe de desenvolvimento?

O ramp-up é a curva de tempo entre o momento em que uma equipe entra em um projeto e o momento em que seu output —código entregue, decisões tomadas, problemas resolvidos— deixa de ser limitado pelo que ela ainda não sabe. Existem três camadas que se aprendem em paralelo, não uma só: o código (arquitetura, convenções, dívida técnica herdada), o negócio (que problema o sistema resolve, quem o usa, que restrições não estão escritas em nenhum documento) e a própria equipe (como cada pessoa se coordena, quem sabe o quê, que acordos tácitos já existem). Uma equipe que começa do zero precisa resolver as três camadas ao mesmo tempo em que já se espera que ela entregue.

Quanto tempo leva, na prática, para uma equipe nova chegar ao seu ritmo real?

O estudo mais citado sobre isso é o de Kevin Rollag, Salvatore Parise e Rob Cross, publicado na MIT Sloan Management Review em 2005: eles encontraram que o tempo para atingir produtividade plena em um cargo profissional pode chegar a 20 semanas —quase cinco meses—, e ainda mais em cargos de maior responsabilidade. Esse número descreve uma pessoa entrando sozinha em uma equipe que já funciona. Quando o que se monta é a equipe inteira —várias pessoas se coordenando entre si pela primeira vez, sem ninguém do outro lado que já conheça o terreno—, não existe uma única curva de aprendizado: existem tantas quantas forem as pessoas, sobrepostas.

O Google chegou a uma conclusão parecida por outro caminho. Em um estudo interno da sua própria equipe de People Analytics, uma mudança simples no processo de onboarding —um checklist enviado ao gestor no momento certo, antes de a nova pessoa começar— reduziu o tempo até a produtividade plena em um mês inteiro, 25% mais rápido que o processo anterior (Google re:Work, “A data-driven approach to optimizing employee onboarding”). O dado importa pelo que implica ao contrário: se estruturar melhor o processo economiza um mês inteiro, é porque, sem essa estrutura, o ramp-up já estava consumindo esse mês sozinho.

Por que somar gente não encurta um projeto atrasado?

A resposta clássica é a Lei de Brooks: adicionar programadores a um projeto de software que já está atrasado o atrasa ainda mais (Fred Brooks, The Mythical Man-Month, 1975). O motivo não é que a gente nova não sirva —é que, durante o período de ramp-up, ela consome tempo da equipe que já está entregando: alguém precisa explicar o sistema, revisar o código de quem acabou de chegar, responder as mesmas perguntas mais de uma vez. A capacidade da equipe cai antes de subir.

Por que esse custo cresce mais rápido do que parece?

Brooks também descreve a razão matemática: a quantidade de canais de comunicação possíveis entre n pessoas é n×(n-1)/2. Com 5 pessoas há 10 canais; com 10 pessoas, 45. Cada pessoa que se soma não só precisa aprender o projeto —também multiplica a quantidade de conversas necessárias para manter todo mundo alinhado. É a mesma razão, de outra forma, pela qual uma equipe que já se conhece chega com esse problema já resolvido: os canais já existem, não é preciso abri-los de novo.

Por que esse custo quase nunca aparece no orçamento de um projeto?

Porque ele não aparece como uma linha à parte: se dissolve dentro dos primeiros sprints, e ali é confundido com “está demorando para engrenar” em vez de ser chamado pelo que realmente é. A maior parte do conteúdo que existe sobre onboarding é escrita para o RH —pensada para um cargo individual que entra em uma estrutura que já funciona—, não para a pergunta que a empresa realmente precisa responder antes de contratar: dos modelos disponíveis para somar capacidade de desenvolvimento, qual minimiza esse custo específico, não o custo por hora?

Uma squad que já trabalhou junta também tem ramp-up?

Sim —nenhuma quantidade de histórico compartilhado elimina a parte do ramp-up que depende do projeto específico: o código daquela empresa, o seu negócio particular, as suas restrições não escritas. Ninguém evita isso, nem mesmo uma equipe com anos de trabalho junta. O que um squad que já trabalhou junto elimina é a outra metade do problema: a coordenação interna. Ele não precisa descobrir no caminho quem é bom em quê, como cada pessoa prefere trabalhar, ou o que acontece quando alguém discorda —essa parte já está resolvida antes de o projeto começar, e é exatamente a parte que uma equipe montada ad hoc precisa reconstruir do zero, mesmo que cada pessoa individualmente seja sênior.

Na Zenit, o Kaizen reduz a outra metade do ramp-up —a do negócio, não a da equipe— documentando o contexto real do projeto antes do match: o que existe, o que falta, que restrições não estão escritas em nenhum documento. O squad ainda precisa aprender o código específico daquela empresa, mas não começa às cegas nem precisa reconstruir sua própria coordenação interna ao mesmo tempo.

O tempo de ramp-up nunca chega a zero —nem com o melhor squad, nem com o melhor processo de onboarding. Mas existe uma diferença real entre pagá-lo uma única vez, do lado do negócio que a equipe ainda não conhece, e pagá-lo duas vezes: uma pelo negócio e outra por uma equipe que também não se conhece.