Alocação de desenvolvedores ou squad gerenciado: qual escolher

A conversa costuma começar pela planilha de custos. Uma proposta oferece desenvolvedores alocados, cobrados por hora ou por mês, que trabalham "como se fossem da casa". A outra oferece um squad gerenciado, com gerente de produto, arquiteto, desenvolvedores e testes, comprometido com entregas. Lado a lado, a primeira parece mais barata e mais flexível, e a segunda parece mais cara e mais amarrada.

Essa comparação engana porque os dois modelos não vendem a mesma coisa. Um vende capacidade de trabalho. O outro vende responsabilidade por um resultado. Contratar pedreiros não é o mesmo que contratar uma construtora: no primeiro caso, alguém da sua casa precisa comandar a obra.

Este texto ajuda a responder a pergunta que vem antes do preço: quem, na prática, vai decidir o que é construído, como é construído e se está bom o suficiente para ir para produção.

Resposta curta: decida por quem vai gerir o trabalho técnico

Se a sua empresa já tem liderança técnica, backlog priorizado e padrão de código definido, a alocação de desenvolvedores costuma funcionar bem: você só precisa de mais mãos. Se essas três coisas não existem, ou dependem de uma pessoa sobrecarregada, o squad gerenciado é o modelo mais seguro, porque a responsabilidade por produto, arquitetura e qualidade fica com o fornecedor. O critério não é o preço por hora, e sim onde mora a responsabilidade pelo que vai para produção.

O que é alocação de desenvolvedores e o que é squad gerenciado

Alocação de desenvolvedores, também chamada de body shop ou staff augmentation, é a contratação de profissionais de um fornecedor para trabalhar sob a gestão da sua empresa. O fornecedor recruta, contrata, paga e substitui. Quem distribui as tarefas, revisa o código, decide a arquitetura e aprova a entrega é você. O profissional entra no seu time, usa suas ferramentas e segue seus processos.

Squad gerenciado é um time completo, montado e conduzido pelo fornecedor, responsável por um produto ou por um conjunto de objetivos. Além dos desenvolvedores, ele inclui os papéis que fazem o trabalho andar: alguém que organiza o backlog com a área de negócio, alguém que responde pela arquitetura, alguém que cuida de testes e qualidade. Sua empresa participa definindo prioridades e validando entregas, mas não precisa coordenar o dia a dia técnico.

A diferença prática aparece na primeira semana. O desenvolvedor alocado chega e pergunta: "qual é a minha tarefa?". O squad gerenciado chega e pergunta: "qual problema do negócio precisamos resolver primeiro?".

Nenhum dos dois é melhor em abstrato. São ferramentas para situações diferentes. Se a dúvida ainda é anterior, entre montar time próprio ou terceirizar, vale ler antes equipe interna ou terceirizar o desenvolvimento.

A pergunta central: a empresa tem liderança técnica?

Alocação funciona quando já existe alguém na empresa capaz de fazer três coisas que o desenvolvedor alocado não vai fazer por você.

Transformar necessidade de negócio em tarefa técnica. O diretor comercial diz que precisa de "um jeito de acompanhar as propostas". Alguém precisa converter isso em histórias, regras, telas e critérios de aceite. Desenvolvedor alocado executa bem tarefas claras. Tarefas vagas viram retrabalho.

Decidir a arquitetura e manter a coerência. Onde fica a regra de cálculo, como os sistemas se integram, que banco usar, como tratar falhas. Sem alguém da casa tomando essas decisões, cada profissional alocado resolve do seu jeito, e o sistema vira uma colcha de soluções diferentes.

Revisar e aprovar o que vai para produção. Code review, testes, padrões de segurança, critério de pronto. Se ninguém da empresa tem conhecimento para dizer "isso não está bom", a qualidade passa a depender da boa vontade de cada pessoa alocada.

Faça um teste honesto. Se amanhã chegassem três desenvolvedores experientes, quem na sua empresa passaria a manhã com eles explicando o sistema, o backlog e o padrão de código? Se a resposta é "ninguém" ou "o nosso único programador, que já está atolado", a alocação vai somar pessoas sem somar entrega.

Os sinais de que a liderança técnica existe

• Há um responsável técnico com tempo real dedicado a coordenar, e não só a programar.
• O backlog está escrito, priorizado e tem alguém do negócio que responde por ele.
• Existe padrão de código, revisão obrigatória antes de subir para produção e algum nível de teste automatizado.
• O ambiente de desenvolvimento, os acessos e a documentação permitem que alguém novo comece a contribuir em poucos dias.

Quando esses sinais estão presentes, alocação é uma forma eficiente de ganhar capacidade sem a demora de recrutar e contratar cada profissional. Quando faltam, a alocação expõe a falta.

Quem responde pela qualidade, pelos prazos e pela arquitetura

Esta é a parte que a planilha de custos não mostra.

Na alocação, o fornecedor responde pela pessoa: que ela seja competente, cumpra a jornada combinada e seja substituída se não servir. Ele não responde pelo resultado. Se o projeto atrasar porque o escopo estava mal definido, a hora foi consumida e é devida. Se a arquitetura escolhida não aguentar o crescimento, a decisão foi sua. Se um bug grave chegar à produção, a revisão que deixou passar era da sua equipe.

No squad gerenciado, o fornecedor assume uma parte maior do risco técnico. Ele responde pelas decisões de arquitetura, pelo padrão de código, pela cobertura de testes e pelo ritmo de entrega combinado. Sua empresa continua dona das prioridades e da aceitação, mas não precisa ter, dentro de casa, a competência para julgar cada decisão técnica no detalhe.

Isso não quer dizer que no squad gerenciado a empresa possa se desligar. Ela precisa de alguém do negócio presente, decidindo prioridades e validando entregas. Sem isso, nenhum modelo funciona. A diferença é que o papel exigido é de gestão de produto e de negócio, não de liderança técnica.

O modelo de contrato acompanha essa diferença. Alocação quase sempre é por tempo e material. Squad gerenciado costuma funcionar melhor em contrato ágil, com ciclos, metas e revisões periódicas. Detalhamos os riscos de cada formato em escopo fechado ou contrato ágil.

Um cuidado trabalhista na alocação

Na alocação, o profissional trabalha no seu dia a dia, mas o vínculo dele é com o fornecedor. Isso não elimina o risco para a sua empresa. Pela lei que regula a terceirização (Lei 6.019/1974, com as mudanças de 2017), a contratante responde de forma subsidiária pelas obrigações trabalhistas do período em que o serviço foi prestado: se o fornecedor deixar de pagar, a conta pode chegar até você. Por isso, peça comprovação periódica de regularidade trabalhista e fiscal do fornecedor. E, se ele contrata os profissionais como pessoa jurídica, converse com o seu jurídico sobre o arranjo, porque a forma como o trabalho é comandado no dia a dia pesa em uma eventual discussão de vínculo.

Rotatividade, conhecimento e documentação

Todo time troca de gente. A diferença está em onde o conhecimento fica quando alguém sai.

Na alocação, o conhecimento fica na cabeça de quem foi alocado, a menos que a sua empresa tenha exigido o contrário. O fornecedor substitui a pessoa, mas o substituto chega do zero. Se a sua liderança técnica não cobrou documentação, revisão cruzada e registro de decisões, cada troca custa semanas de reaprendizado. E há um risco mais sério: com o tempo, um profissional alocado pode se tornar a única pessoa que entende uma parte do sistema, o que recria o problema descrito em sistema dependente de um único programador, só que agora com um contrato de terceiro no meio.

No squad gerenciado, a continuidade é responsabilidade do fornecedor. Um squad bem conduzido tem mais de uma pessoa conhecendo cada parte, documenta as decisões de arquitetura e faz a passagem de bastão quando alguém sai. Isso deve estar escrito no contrato, e não apenas prometido na reunião comercial.

Em qualquer modelo, três cuidados protegem a empresa:

• O código e os acessos são seus. Repositório na conta da empresa, credenciais de produção sob seu controle, nada hospedado em conta pessoal de quem trabalha no projeto. A cláusula que garante isso está explicada em propriedade do código-fonte no contrato.
• Existe documentação mínima e viva. Arquitetura, como subir o ambiente, integrações e regras de negócio importantes. O que é esse mínimo está em documentação de software: o mínimo que todo sistema precisa.
• Ninguém é insubstituível. Toda parte crítica do sistema tem pelo menos duas pessoas que a entendem.

Como medir entrega em cada modelo

O que se mede define o comportamento de quem é medido. E cada modelo pede uma régua diferente.

Na alocação

O fornecedor entrega horas e pessoas, então a medição natural é de presença e de produtividade individual. O problema é que horas trabalhadas não dizem nada sobre valor entregue. Quem mede entrega, na alocação, é a sua liderança técnica, com os mesmos critérios que usaria para um time interno:

• Itens do backlog concluídos e aceitos por ciclo, e não apenas "em andamento".
• Retrabalho: quantas entregas voltam por defeito ou por não atender ao que foi pedido.
• Qualidade do código entregue, avaliada em revisão.
• Autonomia: quanto tempo da liderança cada profissional consome para produzir.

Se a sua empresa não tem quem faça essa leitura, a única métrica que sobra é a fatura.

No squad gerenciado

A medição sobe de nível. Em vez de olhar para pessoas, olha-se para resultados:

• Objetivos do ciclo cumpridos, combinados com a área de negócio antes de começar.
• Frequência e estabilidade das entregas em produção.
• Defeitos encontrados depois da entrega e tempo para corrigi-los.
• Evolução de indicadores do negócio ligados ao sistema, quando fizer sentido medir.

Mesmo sem saber programar, o gestor consegue checar sinais objetivos da qualidade do que está recebendo. Reunimos esses sinais em como avaliar a qualidade do código sem programar.

Tabela comparativa: alocação x squad gerenciado

Leia a tabela por linhas: basta um pré-requisito que sua empresa não cumpra para mudar a resposta.

Quando escolher cada um

Escolha alocação de desenvolvedores quando

• Você já tem um time interno funcionando, com liderança técnica, e precisa de mais capacidade para um período de pico.
• Falta uma competência específica e pontual no time, como um especialista em determinada tecnologia, e alguém da casa sabe exatamente o que pedir a ele.
• O backlog está maduro, os padrões estão definidos e o gargalo é claramente de mãos, não de direção.
• Você quer flexibilidade para ajustar o tamanho do time com frequência e tem quem absorva a integração de pessoas novas.
• A empresa está construindo time próprio e usa a alocação como ponte enquanto contrata, com plano para transferir o conhecimento.

Nesses cenários, a alocação é a escolha certa e um squad gerenciado seria gestão em dobro: você pagaria por coordenação que já tem.

Escolha squad gerenciado quando

• A empresa não tem liderança técnica, ou o único profissional técnico já está no limite.
• O projeto é novo, ainda precisa de discovery, arquitetura e definição de produto.
• O sistema é crítico para a operação e você precisa de alguém respondendo formalmente pela qualidade do que vai para produção.
• Tentativas anteriores com profissionais avulsos geraram código sem padrão, sem documentação ou dependente de uma pessoa.
• A diretoria quer cobrar resultado de negócio, e não acompanhar a agenda de cada desenvolvedor.

Sinais de que o modelo atual está errado

• Os desenvolvedores alocados vivem parados esperando definição, ou fazem cada um do seu jeito.
• A sua liderança técnica passa o dia coordenando e não sobra tempo para decidir arquitetura.
• O squad gerenciado está pedindo validação de decisões técnicas que ninguém da empresa sabe avaliar e, mesmo assim, a empresa insiste em microgerenciar.
• As faturas sobem e ninguém consegue dizer o que foi entregue no último mês.

Também é possível combinar os dois. Um arranjo comum é um squad gerenciado conduzindo o núcleo do produto e a arquitetura, enquanto profissionais alocados reforçam o time interno em demandas de sustentação. O que não funciona é misturar sem deixar claro quem decide o quê. Para outras variações de contratação, como profissional autônomo, vale ver freelancer ou software house.

Perguntas frequentes

O que é body shop em desenvolvimento de software?

Body shop é o nome informal da alocação de desenvolvedores, também chamada de staff augmentation: o fornecedor recruta, contrata, paga e substitui profissionais que trabalham sob a gestão da sua empresa. Quem distribui as tarefas, revisa o código, decide a arquitetura e aprova a entrega é a empresa contratante, e não o fornecedor.

A empresa responde por dívida trabalhista de desenvolvedor alocado?

Pode responder. Pela lei da terceirização (Lei 6.019/1974, com as mudanças de 2017), a contratante tem responsabilidade subsidiária pelas obrigações trabalhistas do período em que o serviço foi prestado. Por isso, peça ao fornecedor comprovação periódica de regularidade trabalhista e fiscal e, se os profissionais forem contratados como pessoa jurídica, avalie o arranjo com o jurídico.

Squad gerenciado funciona para empresa sem time de TI?

Sim, é justamente o cenário em que o squad gerenciado faz mais sentido, porque produto, arquitetura e qualidade ficam sob responsabilidade do fornecedor. A empresa, porém, não pode se ausentar: precisa de alguém do negócio presente para definir prioridades e validar as entregas. Sem essa pessoa, nenhum modelo de contratação de desenvolvimento funciona.

Qual tipo de contrato usar na alocação e no squad gerenciado?

Alocação de desenvolvedores quase sempre é contratada por tempo e material, com cobrança por hora ou por mês. Squad gerenciado costuma funcionar melhor em contrato ágil, com ciclos, metas e revisões periódicas. Em ambos os modelos, o código deve ficar em repositório da empresa e as credenciais de produção, sob controle dela.

Dá para combinar alocação de desenvolvedores e squad gerenciado?

Sim. Um arranjo comum é o squad gerenciado conduzir o núcleo do produto e a arquitetura, enquanto profissionais alocados reforçam o time interno em demandas de sustentação. O que não funciona é misturar os dois modelos sem deixar claro, por escrito, quem decide prioridade, arquitetura e aprovação do que vai para produção.

Como a Pervian Tech ajuda a decidir e a montar o time certo

Começamos com um diagnóstico inicial gratuito, olhando para a situação real da empresa: se existe liderança técnica, como está o backlog, qual o estado do código e da documentação, e quem do negócio vai decidir prioridades. A partir disso, recomendamos o modelo que se encaixa, mesmo quando a resposta é que a empresa só precisa reforçar o time que já tem.

Quando o melhor caminho é uma solução pronta de mercado em vez de desenvolvimento, dizemos isso. Quando faz sentido construir, montamos o time adequado: reforço técnico integrado ao seu processo, se a sua liderança já conduz bem o trabalho, ou um squad responsável por produto, arquitetura e qualidade, se essa responsabilidade precisa sair de casa. Nosso trabalho de arquitetura de software entra justamente para que as decisões técnicas fiquem registradas e o conhecimento não dependa de uma pessoa só.

O cronograma e o investimento são definidos sob consulta, depois de entender o contexto. Outros textos sobre como contratar desenvolvimento estão em contratação de software. Se você está diante dessa escolha agora, conte para nós como está o seu time hoje.