O Que É um SLA em Desenvolvimento de Software (e Por Que Não Basta para um Projeto)?

Um SLA (service level agreement, ou acordo de nível de serviço) é um contrato que define como se mede o serviço entregue por um fornecedor: tempo de resposta, tempo de resolução, disponibilidade (uptime) e o que acontece se esses números não forem cumpridos. Ele nasceu para suporte técnico e infraestrutura —um helpdesk, uma hospedagem—, não para um projeto de software com data de entrega. Por isso, quando uma empresa contrata um squad externo para construir algo novo, um SLA tradicional mede o que não importa (quão rápido respondem um chamado) e fica em silêncio sobre o que realmente importa (se o que está sendo construído é o que foi pedido).

O que um SLA mede em um contrato de desenvolvimento de software?

Um SLA típico define quatro tipos de métrica: uptime, tempo de resposta, tempo de resolução e disponibilidade de suporte. O documento geralmente também descreve o que acontece se o fornecedor não cumprir esses índices —créditos de serviço, renegociação, saída do contrato— e quem é responsável por cada camada do sistema.

• Uptime — o percentual de tempo em que o serviço permanece disponível, quase sempre medido por mês (por exemplo, 99,9%).
• Tempo de resposta — quanto tempo o fornecedor leva para reconhecer um problema relatado.
• Tempo de resolução — quanto tempo leva para efetivamente resolvê-lo, algo diferente de apenas reconhecê-lo.
• Disponibilidade de suporte — se a cobertura é 24/7, apenas em horário comercial, ou escalonada por severidade.

Por que um SLA pensado para suporte não é suficiente para construir um projeto?

O problema não é que o SLA esteja mal desenhado — é que ele mede o processo, não o resultado. Uma equipe de suporte pode fechar 95% dos chamados dentro do prazo combinado e mesmo assim deixar o cliente com a sensação de que nada foi realmente resolvido. Transportado para um projeto de desenvolvimento, esse mesmo problema piora: medir a produtividade de uma equipe de engenharia por tempo de resposta ou disponibilidade não diz nada sobre se o código que estão escrevendo resolve o problema real, nem se o projeto vai estar pronto quando disseram que estaria.

A Gartner organiza isso em três níveis de maturidade de contrato: input-based (paga-se por horas ou por pessoas alocadas), output-based (paga-se por entregáveis concretos, como uma feature ou um chamado fechado) e outcome-based (paga-se pelo resultado de negócio, como o uptime ou o impacto medido). A maioria das empresas ainda está no primeiro nível ou migrando para o segundo; poucas chegam ao terceiro. Um SLA de suporte tradicional vive no primeiro nível. Um projeto de software bem gerido precisa viver, no mínimo, no segundo.

O que acontece quando o SLA fica vago?

A causa mais comum de atrito em um contrato com SLA não é o fornecedor descumprir de propósito: é a métrica nunca ter ficado totalmente clara. “Tempo de resposta” pode significar coisas diferentes para cada parte se o momento exato em que o relógio começa a contar não for definido, e “resolvido” pode significar “um patch temporário foi aplicado” para o fornecedor e “o problema não vai voltar” para o cliente. Quanto mais ambígua a definição, mais espaço cada lado tem para interpretá-la a seu favor quando algo dá errado — e esse desacordo, não o descumprimento em si, é o que mais tempo consome para resolver.

O que substitui o SLA em um projeto pago por milestone?

Em um projeto de software —diferente de um serviço contínuo de suporte— o que precisa ser verificado não é quão rápido a equipe responde, mas se ela entregou o que se comprometeu a entregar, quando disse que entregaria. Por isso a Zenit não pede que as empresas redijam um SLA genérico para cada squad: substitui essa lógica por critérios de aceitação assinados antes de cada milestone começar, para que o padrão de “pronto” fique definido de antemão e não seja negociado justamente quando algo não fecha.

O SafePay libera o pagamento de cada milestone contra essa evidência —não contra uma data no calendário nem uma promessa verbal—, então o squad não recebe por um trabalho que não pode ser verificado, e a empresa não paga por um trabalho que não está pronto.

E esse histórico de cumprimento não se perde entre projetos: o ZenitRank o acumula milestone a milestone, com uma taxa de entrega no prazo que se atualiza sozinha, então a próxima empresa que avaliar aquele squad vê um histórico real —não uma promessa nova a cada vez.

Um SLA continua sendo a ferramenta certa quando o que se contrata é um serviço contínuo — suporte, infraestrutura, manutenção. Para um projeto com data de entrega e escopo definido, a pergunta que importa não é quão rápido o fornecedor responde, mas se o que ele vai entregar é exatamente o que a empresa precisa — e essa pergunta o Kaizen responde antes de o projeto começar, não um documento de métricas de suporte.