Como terceirizar desenvolvimento de software sem perder o controle do produto.

Como terceirizar desenvolvimento de software sem perder o controle do produto depende menos do fornecedor escolhido e mais de três decisões antes de assinar: o modelo de contrato, as cláusulas de propriedade e governança, e o mecanismo de visibilidade contínua que você combina pra acompanhar o trabalho. Quando essas três coisas estão bem desenhadas, qualquer time competente entrega. Quando não estão, nenhum time entrega.

Este texto trata cada uma delas com profundidade prática — modelos de outsourcing de software, cláusulas que precisam estar no papel, e como manter visibilidade sem virar o gerente do squad terceiro.

Por que a terceirização falha na maioria dos casos

Em geral, o fracasso não está no time terceirizado. Está no acordo. Os padrões que se repetem:

• Escopo aberto vendido como flexibilidade. "A gente vai descobrindo no caminho" é frase elegante pra dizer que ninguém vai assumir responsabilidade quando a conta crescer.
• Propriedade do código não contratada. Cliente assume que o código é dele. Não é, sem cláusula explícita de cessão de direitos autorais sobre obra encomendada.
• Cadência de entrega indefinida. Sem sprint definida, demo combinada e critério de aceite, qualquer entrega vira "está pronto" pela ótica da fornecedora e "ainda falta" pela ótica do cliente.
• Comunicação por demanda. Quando o cliente só ouve falar do projeto quando ele liga pra cobrar, já passou do ponto.
• Métrica de sucesso ausente. Sem definir o que conta como entrega boa, o tempo passa sem que ninguém saiba se o produto está crescendo ou apodrecendo.
• Modelo de receita desalinhado. Fornecedora cobra por hora ganha quando demora. Fornecedora cobra por sprint fechada ganha quando entrega. Incentivo importa.

Os 4 modelos de terceirização e quando usar cada um

Outsourcing de software tem quatro formatos típicos. Cada um cabe em um contexto diferente.

Erro comum: escolher staff augmentation quando o cliente não tem capacidade técnica interna pra dirigir o time. Sem tech lead próprio, staff augmentation vira squad dedicado mal organizado.

O que o contrato precisa ter para você não perder o controle

Mínimo aceitável em um contrato de terceirização ou squad dedicado:

• Cessão integral de direitos autorais sobre obra encomendada (Lei 9.610/98), com licença irrevogável e perpétua para o cliente, desde o primeiro commit.
• Repositório no controle do cliente, com acesso da fornecedora apenas durante o contrato.
• NDA mútuo com vigência de 5 anos após o encerramento e cláusula penal em valor concreto por descumprimento.
• Escopo por sprint definido, com roadmap geral separado. Mudança no roadmap não muda automaticamente o escopo da sprint corrente.
• SLA de bug crítico com prazo de resposta e prazo de resolução. Bug em produção que derruba operação não pode esperar próxima sprint.
• Cláusula de compensação por atraso da fornecedora — desconto na mensalidade, crédito em sprint futura ou multa progressiva.
• Cláusula de saída sem multa abusiva. Saída desejada deve ter aviso prévio de 30 a 60 dias, com entrega de handover técnico.
• Tratamento de dados (LGPD) com DPO indicado da fornecedora, mapeamento de dados pessoais, base legal definida e cláusula de processamento.
• Garantia de funcionamento de 60 a 90 dias após cada entrega, corrigindo defeitos sem custo adicional.
• Proibição de reuso de código encomendado em outros clientes.

Como manter visibilidade do progresso sem microgerenciar

Visibilidade é diferente de comando. Três mecanismos resolvem 90% dos casos:

• Acesso direto ao board. Cliente vê o que está em backlog, em andamento, em review e pronto. Jira, Linear, GitHub Projects — qualquer ferramenta serve, desde que o cliente tenha login.
• Demo curta a cada 1 ou 2 semanas. Não é reunião de status. É entrega funcionando, com fluxo de uso real. Vinte minutos resolvem.
• Reunião mensal de saúde técnica. Métricas que importam: velocity (entrega por sprint), bugs em produção, débito técnico, performance, custo de infra. Tendência ao longo dos meses revela se o produto está crescendo de forma saudável.

O que não ajuda: stand-up diário com o cliente. Vira microgerenciamento, consome tempo do time, gera ansiedade pra ambos os lados e não substitui ferramenta de board. O ritual diário é interno do squad — o cliente acompanha pela ferramenta.

O que perguntar antes de assinar com qualquer software house

Checklist de 7 perguntas. Se a fornecedora hesitar em qualquer uma, é sinal.

1. Quem vai estar no squad — com nome, foto, currículo e senioridade? Resposta "vou montar conforme a demanda" é body shop.
2. O código é do cliente desde o primeiro commit? Pergunte pela cláusula exata. Cessão integral, não licença de uso.
3. Como funciona substituição de pessoa do squad? Prazo, processo, quem absorve o custo do onboarding.
4. Qual o SLA de bug crítico em produção? Prazo de resposta separado de prazo de resolução.
5. Quem é o DPO indicado para LGPD? Se a resposta for "nosso advogado externo cuida disso", o controle é nenhum.
6. Existe cláusula de compensação por atraso? Em valor concreto, não em "boa vontade".
7. Como é o handover técnico no fim do contrato? Documentação, transferência de conhecimento, prazo, custo extra ou incluso.

Como a Skala estrutura a terceirização

Na Skala, o modelo é fixo: escopo por sprint definido em contrato, código 100% do cliente desde o dia 1 (repositório dele), RC profissional ativa, DPO formal, NDA mútuo, cláusula de compensação por atraso. Não cobramos por scrum master que não escreve código nem por hora avulsa.

Cliente recebe acesso ao board do projeto, demo quinzenal de entrega funcionando, e relatório mensal técnico com velocity, qualidade e débito. Substituição de membro do squad em 5 a 10 dias úteis, com onboarding por conta da Skala. Permanência média atual nos 13 contratos recorrentes é de 2 anos ou mais — em 2025, zero saídas. Construímos pra cliente ficar, não pra fechar venda.

Perguntas frequentes