Como substituir uma equipe alocada sem interromper a produção

Substituir uma equipe alocada (bodyshop) sem interromper a produção exige mais do que trocar contratos. Você precisa tratar a saída como um projeto de risco operacional, com inventário técnico, plano de transferência de conhecimento e critérios objetivos de aceitação da nova squad. Quando isso não acontece, o problema não é só velocidade, é continuidade de negócio. Na prática, a troca falha por três motivos recorrentes: conhecimento concentrado em poucas pessoas, ausência de critérios de saída e transição sem governança. Em empresas com sistemas críticos, isso aparece como aumento de incidentes, fila de bugs e dependência de decisões informais. Se o seu time já sofre com backlog travado, este é justamente o momento de estruturar a troca com método. Este guia foi pensado para CTOs, CEOs e Heads de Produto que precisam fazer a transição com previsibilidade. A lógica é simples: primeiro você estabiliza o que já existe, depois transfere conhecimento, em seguida sobe a nova equipe em paralelo e só então reduz o time antigo. Esse modelo conversa bem com práticas de governança e saída contratual já abordadas em Contrato de saída e code escrow para squads alocados e Governança prática para equipes alocadas, que são a base para qualquer troca sem susto. Na OrbeSoft, a visão é pragmática: a transição só é segura quando o fornecedor novo entra com squad sênior dedicada, escopo claro e capacidade real de assumir produção. Isso vale especialmente em ambientes com alta disponibilidade, integrações legadas, SAP, nuvem e rotinas sensíveis de negócio.

O contrato certo não serve só para cobrar entrega, ele também protege a continuidade da operação. Na substituição de um bodyshop, as cláusulas mais úteis são as que obrigam o fornecedor atual a documentar, treinar, disponibilizar artefatos e cooperar com a nova equipe por um período delimitado. Sem isso, a transição fica refém da boa vontade de quem está saindo. As cláusulas que mais fazem diferença são estas: obrigação de transferência de conhecimento, manutenção de disponibilidade durante a transição, acesso a repositórios e ambientes, atualização de documentação técnica, apoio em janela de coexistência, definição de responsáveis por aceite e previsão de penalidades em caso de bloqueio à saída. Em contratos mais maduros, também vale prever um anexo de handover com entregáveis mínimos, como runbooks, mapa de arquitetura, inventário de integrações e lista de riscos abertos. Outro ponto crítico é a propriedade intelectual. Se o seu contrato anterior não separa claramente o que pertence ao cliente, a troca pode virar disputa sobre código, documentação e pipelines. Por isso, faz sentido alinhar a transição com a lógica de Blueprint técnico: propriedade do código entre time interno e equipes alocadas e, quando aplicável, com Plano de Sucessão e Transferência de Conhecimento entre equipe alocada e time interno. Do lado jurídico, dois cuidados ajudam muito: a cláusula de saída precisa ter prazo e dever de cooperação, e os marcos de transição precisam ser verificáveis. Evite redações genéricas do tipo "apoio razoável". Prefira entregáveis concretos, como "duas sessões de handover por semana, documentação atualizada até a data X e suporte a incidentes críticos por 30 dias após o início da coexistência". Quando a linguagem é vaga, a execução tende a ser vaga também.

Na substituição de uma equipe alocada, SLA sem SLI vira promessa difícil de auditar. O ideal é vincular disponibilidade e qualidade a métricas observáveis, como tempo médio de resposta, tempo para restaurar serviço, taxa de falha em deploy, sucesso de rollback e tempo de fechamento de incidentes críticos. Assim você sabe se a nova squad está operando no mesmo nível da anterior antes de encerrar o contrato antigo. A regra prática é simples: os SLAs da transição devem ser mais conservadores do que os SLAs de regime estável. Durante a coexistência, você quer reduzir risco, não testar a tolerância do negócio. Por isso, faz sentido exigir janelas maiores de suporte, maior frequência de relatórios e um processo de escalonamento mais curto do que o usual. Também vale revisar SLAs à luz do tipo de produto. Sistemas que atendem operações críticas, como saúde, indústria, varejo enterprise ou governo, pedem monitoramento mais rígido e rollback mais rápido. Quando a operação envolve integrações com AWS, Azure, Google Cloud Platform, SAP ou painéis executivos em Power BI, a visibilidade precisa ser end-to-end para não esconder gargalos entre fornecedores. Se você quer aprofundar o desenho dessas métricas, o material SLA e SLIs ideais por tipo de entrega em contratos de alocação ajuda a transformar intenção em métrica. E, se o seu caso inclui produto com IA ou automação, a disciplina de observabilidade precisa vir junto, como detalhado em Guia prático de observabilidade para produtos digitais com IA.

O primeiro erro é fazer a troca sem um período de sobreposição. Isso parece mais barato no curto prazo, mas costuma sair mais caro quando o novo fornecedor descobre dependências tarde demais. O segundo erro é negociar só preço, sem amarrar transferência de conhecimento, suporte e dever de cooperação no contrato. Outro problema recorrente é tratar documentação como entregável secundário. Em substituições de bodyshop, documentação não é burocracia, é ativo operacional. Se ela estiver incompleta, o time novo vai gastar semanas reconstituindo decisões que poderiam ter sido passadas em poucos dias. Também é comum subestimar a tensão entre CEO e CTO durante a troca. O CEO quer previsibilidade e velocidade, o CTO quer risco controlado e sustentabilidade. Quando essa conversa não é alinhada cedo, a transição vira disputa política. Um bom ponto de partida é usar o playbook de Como alinhar CEO e CTO ao contratar um squad externo para definir quem decide o quê, quando e com base em qual métrica. O último erro é não considerar o que vem depois da troca. Se a empresa não revisar governança, monitoramento e estrutura de squads, ela corre o risco de repetir o mesmo problema com outro fornecedor. Substituir sem aprender com a transição apenas troca o nome do parceiro, não a qualidade da operação.