Contrato de sustentação não deveria significar ficar de plantão à espera de chamados. Ele precisa deixar claro o que será mantido, como incidentes serão tratados, quais melhorias cabem e como o serviço será avaliado.

O que um contrato de sustentação saudável deve cobrir

A ISO/IEC/IEEE 14764:2022 trata a manutenção de software após a entrega como um conjunto de atividades que inclui corrigir falhas, adaptar o software a mudanças no ambiente e melhorar o desempenho ou outros atributos. A pergunta deixa de ser apenas quem atende o chamado e passa a ser qual trabalho mantém o produto útil e confiável.

Na prática, o escopo pode ser organizado em quatro frentes:

  • Correção. Investigar e ajustar erros que afetam o uso, os dados ou a operação.
  • Adaptação. Atualizar integrações, dependências ou comportamentos quando o ambiente muda.
  • Melhoria. Reduzir lentidão, fragilidade ou dificuldade de manutenção quando isso fizer parte da prioridade.
  • Aprendizado operacional. Registrar a causa, a decisão e o próximo passo depois de uma ocorrência.

Sustentação não é plantão permanente

Plantão descreve a disponibilidade de pessoas para responder em uma janela específica. Sustentação descreve o conjunto de responsabilidades sobre o software. Os dois podem coexistir, mas um não substitui o outro.

Se o contrato prevê atendimento de incidentes, ele deve deixar definidos:

  • o que caracteriza um incidente e o que é uma solicitação de melhoria;
  • como a prioridade será classificada pelo impacto;
  • qual canal registra a ocorrência;
  • quando começa e termina a janela de atendimento;
  • quem decide a comunicação, a correção e a validação;
  • qual registro fica para evitar repetir o problema.

O NIST SP 800-61 Rev. 3 organiza a resposta a incidentes em preparação, detecção, resposta e recuperação. Em um contrato, isso significa que a atuação não termina quando alguém responde ao chamado. É preciso preparar o serviço, identificar o problema, responder ao impacto, recuperar a operação e revisar o que deve mudar.

Como definir um nível de serviço que possa ser avaliado

O guia do Google sobre Service Level Objectives diferencia uma expectativa vaga de um objetivo mensurável. Um acordo saudável precisa indicar o indicador, o objetivo e a consequência quando o objetivo não for atingido. Atender rápido não permite avaliar o serviço; registrar a primeira resposta em uma janela definida para incidentes de determinada severidade permite.

Um exemplo de definição, sem impor números a todo contrato, seria:

  • Indicador. Tempo até a primeira resposta.
  • Objetivo. Valor acordado por severidade e janela de atendimento.
  • Evidência. Registro no canal de suporte.
  • Consequência. Procedimento acordado se o objetivo não for atingido.

O indicador também precisa refletir o que importa para o produto. Medir apenas disponibilidade pode esconder erros de cadastro, falhas de integração ou lentidão no fluxo que o usuário precisa concluir.

Exemplo de uma rotina de sustentação saudável

Simulação, sem representar um cliente real. Uma loja virtual informa que o pagamento começou a falhar depois de uma mudança no provedor. A equipe registra o incidente, classifica o impacto, verifica se a alteração externa explica o comportamento, aplica uma correção ou adaptação, valida o fluxo e registra o que deve ser acompanhado.

Se a análise mostrar que a causa está na integração, o trabalho não termina com o retorno do checkout. A sustentação pode incluir o ajuste da integração, o teste do fluxo afetado e uma mudança no acompanhamento para detectar nova falha. Se o pedido for uma nova modalidade de pagamento, isso é uma evolução e deve ser priorizado separadamente, conforme o modelo contratado.

Esse limite evita duas distorções. Tratar toda demanda como emergência aumenta a confusão. Empurrar toda manutenção para um backlog sem dono deixa a operação exposta. O contrato deve tornar visível o que é incidente, o que é manutenção e o que compete com uma nova entrega.

Se o contrato atual mistura manutenção, evolução e plantão, converse com a LYPES para mapear o gargalo do produto e avaliar se uma capacidade mensal por horas ou um escopo fechado atende melhor à necessidade.