Fábrica de software: squad dedicado, escopo fechado ou alocação? Como escolher

Contratar desenvolvimento externo parece uma decisão de fornecedor. Na prática, a decisão que mais impacta o resultado é outra: qual modelo de contratação você escolhe.

Escolher o modelo errado para o seu tipo de demanda produz atrito por todo o contrato, independentemente da qualidade técnica do fornecedor.

Os três modelos

Escopo fechado

Você contrata um resultado. Preço e prazo definidos para uma entrega especificada.

Quem assume o risco de estimativa: o fornecedor. Se o trabalho levar mais tempo que o previsto, o custo é dele.

Funciona quando o requisito está claro, documentado e não deve mudar muito. Substituição de um sistema com comportamento conhecido, integração com especificação definida, módulo com regra estável.

Quebra quando o requisito muda. Cada mudança vira aditivo, e a negociação de aditivo consome mais energia que o desenvolvimento em si. Se você percebe que está negociando escopo toda semana, o modelo está errado — não o fornecedor.

O custo escondido: para assumir o risco, o fornecedor precifica uma margem de segurança. Você paga por essa margem mesmo quando ela não é usada.

Squad dedicado

Você contrata capacidade. Um time exclusivo, com custo mensal previsível, trabalhando no seu backlog com prioridade definida por você.

Quem assume o risco de estimativa: compartilhado. O fornecedor garante capacidade e qualidade; você define o que essa capacidade constrói.

Funciona quando há backlog contínuo, a prioridade muda com frequência e o produto evolui a partir de aprendizado. É o modelo natural para produto digital e para evolução de sistema em uso.

Quebra quando o cliente não tem quem priorize. Squad sem product owner ativo entrega o que o próprio squad decidiu — e depois recebe a crítica de ter construído a coisa errada.

O custo escondido: capacidade ociosa. Se o backlog não estiver pronto, você paga um time esperando definição.

Alocação pontual

Você contrata pessoas. Um ou mais profissionais integrados ao seu time, sob sua gestão.

Quem assume o risco: você, integralmente.

Funciona quando falta uma competência específica e temporária — um especialista ABAP para um projeto, um desenvolvedor mobile para uma entrega, reforço em pico de demanda.

Quebra quando vira substituto permanente de contratação. Alocação de longo prazo sem transferência de conhecimento cria a mesma dependência que existiria com um funcionário, sem os vínculos que garantem permanência.

A comparação direta

O erro que mais encarece

O padrão que mais vemos: contratar escopo fechado para uma demanda que na verdade é evolutiva.

A empresa quer previsibilidade, então especifica tudo antecipadamente e contrata preço fixo. Três meses depois, o mercado mudou, o usuário pediu diferente ou alguém percebeu que a especificação inicial não resolvia o problema.

A partir daí, cada mudança é uma negociação. O fornecedor precisa proteger a margem, o cliente sente que está pagando duas vezes pela mesma coisa, e a relação se deteriora — no que quase sempre é um problema de modelo, não de má-fé de nenhum dos lados.

A pergunta que evita isso: os requisitos deste projeto vão mudar nos próximos seis meses? Se a resposta honesta for sim, escopo fechado é o modelo errado.

Três cláusulas que valem mais que o preço

Independentemente do modelo escolhido:

1. Propriedade e localização do código. O código deve viver no repositório do cliente desde o primeiro commit. Não no fim do contrato — desde o início. Fornecedor que resiste a isso está criando dependência deliberadamente.

2. Substituição de profissional com sobreposição. Quando alguém do time do fornecedor sai, deve haver período de sobreposição entre quem sai e quem entra, custeado pelo fornecedor. Sem essa cláusula, a curva de aprendizado do substituto é paga por você.

3. Documentação como entregável. Definida no contrato, com critério de aceite. "Vamos documentar" sem critério significa um README genérico entregue na última semana.

Como escolher, na prática

• Requisito claro e estável, entrega pontual → escopo fechado
• Backlog contínuo, prioridade dinâmica, produto vivo → squad dedicado
• Falta uma competência específica por tempo determinado → alocação
• Não sei ainda o que preciso construir → nenhum dos três. Contrate primeiro uma

fase de descoberta com escopo e prazo curtos, e decida o modelo depois.

O último caso é mais comum do que parece, e tentar pular essa etapa é a origem da maior parte dos projetos que terminam mal.