SLA em contrato de squad: o que negociar antes de fechar

Quando uma empresa decide contratar uma squad externa para desenvolver ou manter um sistema, a negociação costuma travar em dois pontos: valor da hora e stack técnica. O SLA — o conjunto de compromissos de nível de serviço — fica em segundo plano, tratado como cláusula padrão de contrato. O problema aparece depois, quando um bug crítico demora dias para ser respondido, um desenvolvedor sai do time sem plano de transição, ou a squad simplesmente não documenta o que foi entregue. Nesse momento, sem SLA definido, não há o que cobrar.

Este guia detalha o que compõe um SLA de contrato de squad de desenvolvimento, como ele muda conforme o modelo de contratação e quais cláusulas realmente protegem a empresa contratante — sem transformar a negociação em um processo burocrático que afasta bons fornecedores.

O que é SLA em contrato de squad de desenvolvimento

SLA (Service Level Agreement, ou acordo de nível de serviço) é o conjunto de métricas e compromissos que definem como o fornecedor vai atender a empresa contratante ao longo do contrato. Em uma squad de desenvolvimento, isso normalmente cobre tempo de resposta a incidentes, prazo de entrega de demandas, canais de comunicação, critérios de qualidade e regras para troca de profissionais.

A diferença entre um contrato com SLA claro e um contrato genérico não está no preço da hora técnica, e sim no que acontece quando algo sai do esperado. Um SLA bem definido diz exatamente quem responde, em quanto tempo, e o que é considerado aceitável. Sem isso, cada problema vira uma negociação nova.

Isso não significa que toda squad terceirizada precisa de um SLA rígido, no estilo de contrato de infraestrutura crítica. O nível de formalidade deve ser proporcional ao risco: um sistema que gera receita direta ou lida com dados sensíveis pede cláusulas mais duras do que um projeto interno de baixo impacto.

Por que ignorar o SLA custa caro depois

É comum empresas avaliarem squads terceirizadas apenas pelo portfólio e pelo valor da hora, deixando o SLA para "resolver depois, se precisar". O problema é que o momento em que o SLA faz falta é justamente quando a relação já está sob estresse — um incidente em produção, um prazo estourado, uma saída inesperada de um desenvolvedor-chave.

Sem cláusulas definidas, a empresa contratante fica com três riscos concretos:

• Falta de previsibilidade de resposta. Sem tempo de resposta contratual, um bug crítico pode esperar na fila junto com pedidos de baixa prioridade.
• Dependência de pessoas, não de processo. Se o conhecimento do sistema está apenas na cabeça de um ou dois desenvolvedores e o contrato não prevê documentação nem plano de transição, a saída dessas pessoas vira um risco operacional.
• Ausência de critério objetivo para avaliar o fornecedor. Sem indicadores acordados, discordâncias sobre qualidade de entrega viram debate de opinião, não de dado.

Nenhum desses riscos aparece no início do contrato — eles aparecem depois, quando trocar de fornecedor já é caro e o sistema já depende da squad em operação.

Quais cláusulas formam um SLA de squad terceirizado sólido

Um SLA não precisa ser extenso para ser eficaz. Ele precisa cobrir os pontos que realmente geram atrito quando ficam em aberto.

Tempo de resposta e tempo de resolução

Defina prazos diferentes para "responder" (confirmar que o time está ciente e vai atuar) e "resolver" (efetivamente corrigir o problema). Classifique os chamados por severidade — por exemplo, incidente crítico em produção, bug de impacto médio e ajuste de baixa prioridade — e associe um prazo a cada categoria. Sem essa distinção, tudo tende a ser tratado com a mesma urgência, o que na prática significa que nada tem urgência real.

Indicadores de entrega e qualidade

Acompanhe métricas simples e verificáveis: percentual de sprints entregues no prazo, taxa de retrabalho, tempo médio até a primeira resposta e cobertura de testes em código novo. Não é necessário um painel sofisticado — uma planilha compartilhada e revisada mensalmente já cria o hábito de tratar qualidade como dado, não como impressão.

Comunicação e pontos de contato

O contrato deve nomear quem é o ponto de contato técnico e quem é o ponto de contato comercial de cada lado, além da cadência mínima de comunicação — reunião semanal de status, relatório quinzenal de progresso, ou o que fizer sentido para o porte do projeto. Isso evita que informação relevante fique presa em conversas informais.

Continuidade em caso de saída de profissionais

Esta é a cláusula mais negligenciada e a que mais dói quando falta. Exija que o fornecedor documente decisões de arquitetura, mantenha código comentado nos pontos críticos e apresente um plano de transição caso um desenvolvedor-chave saia do projeto. Uma squad que se recusa a formalizar isso está, na prática, pedindo para que a empresa contratante dependa de pessoas específicas — não de um processo.

Regras de rescisão e transição

Defina o prazo de aviso prévio para encerramento de contrato, o que precisa ser entregue nesse período (documentação, acessos, repositórios, histórico de decisões) e por quanto tempo o fornecedor se compromete a dar suporte à migração para outro time, caso necessário. Isso protege a empresa contratante de ficar refém do fornecedor atual só porque trocar seria operacionalmente inviável. O mesmo raciocínio vale para contratos de sustentação de sistemas: sem regra de transição clara, encerrar o contrato com um fornecedor de manutenção corretiva pode significar meses sem cobertura até o próximo time assumir.

Squad por assinatura vs squad as a service: o SLA muda conforme o modelo

O SLA não é genérico — ele deve refletir o modelo de contratação. A diferença entre squad por assinatura vs squad as a service muda o que faz sentido negociar.

Em uma squad por assinatura, o foco é continuidade: horas mensais recorrentes para evolução de produto, backlog priorizado em ciclos regulares e previsibilidade orçamentária. Aqui, o SLA tende a girar em torno de cadência de entrega, transparência do backlog e critérios para replanejar prioridades no meio do ciclo.

Em uma squad as a service (ou bodyshop), o foco é reforço de capacidade — profissionais alocados para acelerar um roadmap ou cobrir um gap técnico específico. O SLA aqui pesa mais sobre tempo de resposta a chamados, critérios de substituição de profissionais e regras claras de escopo, para evitar que a alocação vire um contrato indefinido sem entregável mensurável.

Empresas que já pagam por hora técnica sem cláusulas de nível de serviço costumam sentir esse gap primeiro no contrato por horas para software: a hora é cobrada, mas nada garante prioridade, prazo ou qualidade mínima da entrega.

Como negociar SLA sem travar a relação comercial

SLA não deveria ser um documento imposto por um lado sobre o outro — funciona melhor como um acordo construído em conjunto, no início da relação, quando ainda não há atrito.

Algumas práticas ajudam a manter a negociação saudável:

1. Comece pelos riscos, não pelas penalidades. Liste o que mais preocupa a empresa contratante (indisponibilidade, perda de conhecimento, atraso recorrente) antes de definir multas. Cláusulas nascem melhor quando respondem a um risco real, não a um modelo genérico copiado de outro contrato.
2. Proponha metas realistas antes de exigir metas agressivas. Um fornecedor que aceita prazos de resposta impossíveis só para fechar contrato provavelmente não vai cumprir. Prazos discutidos abertamente tendem a ser mais confiáveis do que prazos aceitos sem questionamento.
3. Revise o SLA periodicamente. Um contrato de longo prazo deve prever revisão do SLA a cada 6 ou 12 meses, ajustando indicadores conforme o projeto amadurece.
4. Documente exceções. Feriados, picos sazonais de demanda e mudanças de escopo grande merecem regras próprias, para não gerar discussão a cada evento previsível.

Riscos de fechar um contrato sem SLA definido

Vale nomear diretamente o que está em jogo quando o SLA fica de fora do contrato:

• Perda de prioridade em momentos críticos. Sem prazo contratual, a urgência da empresa contratante depende da disponibilidade do fornecedor naquele momento, não de um compromisso formal.
• Dificuldade para trocar de fornecedor. Sem cláusula de transição, migrar para outro time pode levar meses só para reconstruir o conhecimento que deveria estar documentado.
• Avaliação subjetiva de desempenho. Sem indicadores, a percepção de "a squad está entregando bem" vira opinião, o que dificulta decisões objetivas de renovação ou substituição.
• Concentração de risco em poucas pessoas. Sem exigência de documentação e continuidade, o conhecimento do sistema fica preso a indivíduos específicos, não à squad como organização.

Nenhum desses riscos é hipotético — todos aparecem com frequência em empresas que herdam sistemas de fornecedores anteriores sem histórico de decisões registrado, como descrito em como contratar desenvolvedores sem ter CTO ou gestor técnico, quando não há alguém internamente para cobrar esse tipo de cláusula na ponta técnica.

Checklist antes de assinar o contrato

Antes de assinar um contrato de squad terceirizado, vale confirmar:

• Prazos de resposta e resolução estão definidos por nível de severidade.
• Indicadores de qualidade e entrega estão listados e serão revisados com frequência definida.
• Pontos de contato técnico e comercial estão nomeados dos dois lados.
• Existe cláusula de continuidade e plano de transição em caso de saída de profissionais.
• As regras de rescisão definem prazo de aviso e entregáveis obrigatórios (documentação, acessos, código).
• O modelo de contrato (assinatura ou squad as a service) está refletido nas cláusulas de SLA, e não copiado de um template genérico.
• Existe previsão de revisão periódica do SLA ao longo do contrato.

Se a resposta for "não" em mais de um item, vale pausar a assinatura e revisar a minuta com o fornecedor antes de seguir.

Perguntas frequentes

O SLA deve ser igual para squad por assinatura e squad as a service?

Não. Squad por assinatura tende a priorizar cadência de entrega e transparência de backlog; squad as a service pesa mais sobre tempo de resposta e critérios de substituição de profissionais. O SLA deve refletir o modelo contratado, não um template único aplicado a qualquer formato.

Quem deve escrever o SLA, o contratante ou o fornecedor?

Idealmente, os dois lados constroem o SLA juntos. Um documento imposto unilateralmente pelo fornecedor tende a favorecer prazos confortáveis para quem entrega; um documento imposto unilateralmente pela empresa contratante tende a incluir metas que o fornecedor não consegue sustentar. O ponto de equilíbrio nasce da negociação, não da imposição.

O que acontece se o fornecedor não cumprir o SLA?

Depende do que foi acordado em contrato. Algumas empresas preferem cláusulas de compensação (desconto proporcional, horas extras sem custo); outras preferem apenas o direito de rescisão facilitada se o descumprimento for recorrente. O importante é que essa consequência esteja escrita antes de o problema acontecer, não negociada depois, sob pressão.

Conclusão

SLA não é burocracia de contrato — é o que transforma uma squad terceirizada de "fornecedor que cobra por hora" em parceiro com compromissos mensuráveis. Empresas que negociam essas cláusulas no início da relação evitam boa parte dos atritos que aparecem meses depois, quando trocar de fornecedor já não é uma opção simples.

Se sua empresa está avaliando reforçar o time com profissionais externos ou fechar um contrato de squad dedicada, vale estruturar o SLA antes de assinar, não depois do primeiro problema. Conheça o Squad as a Service da Clicksoft e entenda como funciona um contrato com prazos, indicadores e continuidade definidos desde o início.