Aceite de projeto de TI: criterios objetivos para dizer que a entrega terminou

Por que projetos de TI "não terminam"

Todo gestor de TI já viveu isso: o projeto foi entregue, o fornecedor emitiu a nota fiscal, mas alguém do time ainda abre chamado dizendo que "falta ajustar uma coisinha". Três meses depois, o mesmo projeto continua consumindo horas de consultoria, gerando atrito com o fornecedor e travando a fila de iniciativas que deveriam ter começado. O problema raramente é má-fé de alguma das partes. Na maioria dos casos, o contrato descreveu o que seria feito, mas nunca definiu como se verifica que foi feito.

Escopo e critério de aceite são coisas diferentes. Escopo responde "o que vamos entregar": migrar 120 caixas de e-mail para o Microsoft 365, implantar backup em nuvem de quatro servidores, substituir o firewall da matriz. Critério de aceite responde "como sabemos que a entrega está correta e completa": todas as 120 caixas acessíveis via Outlook e webmail, com histórico dos últimos 24 meses íntegro e regras de encaminhamento preservadas, validado por amostragem de 10% dos usuários. Sem a segunda parte, o encerramento vira uma negociação subjetiva entre a percepção do cliente e a percepção do fornecedor.

O custo dessa lacuna é maior do que parece. Projeto sem critério de aceite objetivo produz três efeitos encadeados: a equipe do fornecedor não consegue alocar o time para o próximo cliente porque a demanda residual não acaba; o cliente não consegue transferir a solução para a operação de suporte porque ninguém assinou que ela está estável; e a área financeira segura o pagamento da última parcela por tempo indeterminado, o que azeda a relação comercial de forma que raramente se recupera.

O que caracteriza um critério de aceite objetivo

Um critério de aceite útil precisa passar num teste simples: duas pessoas diferentes, lendo o mesmo critério e olhando o mesmo ambiente, chegam à mesma conclusão sobre se ele foi atendido ou não. Se a resposta depende de bom senso, de humor ou de quem está avaliando, o critério não serve. "O sistema deve estar rápido" falha nesse teste. "O tempo de abertura da tela de consulta de pedidos deve ser inferior a 3 segundos em 95% das medições, com 40 usuários simultâneos, medido pelo relatório do próprio ERP" passa.

Na prática, todo critério bem escrito tem quatro componentes: o objeto verificado, a condição mensurável, o método de verificação e o responsável pela validação. Faltando qualquer um deles, o critério fica aberto a interpretação. O método de verificação é o mais esquecido — e o mais importante, porque é ele que evita a discussão sobre qual ferramenta ou qual amostra vale como prova.

• Objeto: o que exatamente está sendo avaliado (o servidor de arquivos, o job de backup, o link secundário).
• Condição mensurável: número, faixa, estado binário ou percentual — nunca adjetivo.
• Método: qual comando, relatório, painel ou teste produz a evidência.
• Responsável: quem, nominalmente, assina que o critério foi atendido.
• Prazo de verificação: em que janela o teste será executado após a entrega técnica.

Vale registrar também o que não é critério de aceite. Treinamento de usuário, ajuste de processo interno, integração com um sistema de terceiro que ainda não existe e customização pedida durante a execução são itens legítimos, mas pertencem a um novo ciclo — não podem ser usados para bloquear o encerramento do escopo original. Deixar isso escrito no início é o que impede a conversa desconfortável no final.

Como escrever critérios para os tipos mais comuns de projeto

A tradução de um escopo genérico em critérios verificáveis muda conforme a natureza da entrega. Projetos de infraestrutura toleram critérios binários e diretos. Projetos de migração dependem de comparação entre estado anterior e posterior. Projetos de segurança exigem evidência de comportamento sob condição adversa, não apenas de configuração aplicada.

Para uma migração de e-mail corporativo, por exemplo, não basta "todas as caixas migradas". Um conjunto sólido seria: contagem de itens por caixa com divergência inferior a 0,1% em relação ao ambiente de origem; envio e recebimento testado em 100% das caixas com registro no log de transporte; registros SPF, DKIM e DMARC publicados e validados por ferramenta externa; e ausência de fila de sincronização pendente por 72 horas consecutivas após o corte.

Para um projeto de backup, o critério nunca pode se limitar à execução do job. Backup que roda e nunca foi restaurado não é backup, é esperança com agendamento. O aceite precisa incluir teste de restauração real: recuperar um servidor completo em ambiente isolado dentro do RTO acordado, e recuperar um arquivo individual de uma data específica dentro do RPO acordado, ambos com evidência em vídeo ou relatório assinado.

Regra prática: se o critério de aceite pode ser atendido apenas mostrando uma tela de configuração, ele é fraco. Critério forte exige demonstrar comportamento — o sistema fazendo o que promete, sob a condição que importa.

Para substituição de firewall ou link, o aceite deve contemplar o cenário de falha: derrubar o link primário e comprovar que o secundário assume dentro do tempo definido, com as sessões críticas preservadas ou restabelecidas conforme acordado. Testar apenas o caminho feliz é o erro mais comum e o mais caro, porque a falha só aparece no dia em que ninguém está preparado.

O ritual de encerramento: termo, janela de garantia e transferência

Critério escrito sem ritual de encerramento continua virando entrega eterna. O fechamento precisa de um evento formal, com data marcada, participantes definidos e um documento que muda o estado do projeto. Esse documento é o termo de aceite, e ele deve conter a lista de critérios com o resultado de cada um, as evidências anexadas, as pendências acordadas com prazo próprio e a assinatura dos responsáveis de ambos os lados.

Um ponto que reduz muito o atrito é separar aceite técnico de aceite operacional. O aceite técnico ocorre quando a entrega atende aos critérios em ambiente controlado — normalmente no dia da virada. O aceite operacional ocorre após uma janela de estabilização, tipicamente de 15 a 30 dias, em que a solução opera com carga real. Nessa janela, correções de defeito são responsabilidade do fornecedor e não geram custo; solicitações novas entram como demanda separada. Essa distinção resolve a maior parte das disputas, porque dá ao cliente a segurança de que não está assinando no escuro e ao fornecedor o direito de encerrar o projeto sem carregar um escopo que cresce sozinho.

1. Execução dos testes de aceite com o cliente presente, item por item.
2. Registro de resultado: atendido, atendido com ressalva, ou não atendido.
3. Classificação de cada pendência em defeito (fornecedor corrige) ou nova demanda (novo escopo).
4. Assinatura do termo de aceite técnico e início da janela de garantia.
5. Entrega da documentação: topologia, credenciais em cofre, runbooks de operação e contatos de escalonamento.
6. Reunião de encerramento ao fim da janela, com aceite operacional e transferência formal ao suporte.

A transferência para o suporte merece atenção especial. Projeto encerrado sem documentação transferida gera um custo invisível: o primeiro incidente vira investigação do zero, porque quem atende não participou da implantação. Exigir runbook, diagrama atualizado e matriz de escalonamento como parte do critério de aceite — e não como cortesia — é o que garante que o conhecimento fique na empresa.

Erros que transformam aceite em disputa

O primeiro erro é definir critérios só no final. Critério de aceite escrito depois que a implantação começou já nasce contaminado pela realidade do que foi possível fazer, e não pelo que era necessário. Ele precisa ser negociado antes da primeira linha de configuração, junto com o escopo, e revisado formalmente se o escopo mudar.

O segundo erro é aceitar critérios com adjetivos. "Ambiente estável", "performance adequada", "usuários satisfeitos", "documentação completa" — todos parecem razoáveis no papel e se tornam impossíveis de verificar na prática. Sempre que um adjetivo aparecer num critério, ele deve ser substituído por número, prazo ou estado binário. "Documentação completa" vira "documento contendo diagrama de rede, inventário de ativos com IP e função, procedimento de restore e matriz de escalonamento, entregue em PDF".

O terceiro erro é não nominar responsáveis. Critério que depende de "a área de negócio validar" trava indefinidamente porque a área de negócio é uma abstração e abstrações não assinam documento. Cada critério precisa de um nome, com substituto definido para o caso de ausência, e um prazo máximo de resposta — geralmente cinco dias úteis, após os quais o silêncio conta como aceite tácito, desde que isso esteja previsto em contrato.

O quarto erro é misturar defeito com melhoria durante o aceite. É natural que, ao ver a solução funcionando, o usuário pense em algo que ficaria melhor. Isso é sinal de projeto bem-sucedido, não de falha. Mas se essas ideias entram na lista de pendências do aceite, o encerramento nunca chega. A disciplina de classificar cada item como defeito ou nova demanda, na hora, com a presença dos dois lados, é o que mantém o processo funcionando.

Como a Duk conduz o aceite nos projetos de TI

Ao longo de mais de 18 anos atendendo empresas de todos os portes, a Duk Informática & Cloud aprendeu que o critério de aceite é o instrumento que protege as duas partes — não uma formalidade burocrática. Por isso, todo projeto começa com uma sessão de definição de critérios antes da execução, em que escopo e forma de verificação são acordados no mesmo documento e assinados junto com a proposta.

Na prática, isso significa que o cliente sabe desde o primeiro dia exatamente qual teste será executado, com qual ferramenta, por quem e em que data. Em projetos de migração para Microsoft 365, a condição de Microsoft Gold Partner permite usar as ferramentas de validação e o suporte do fabricante como evidência formal, e não apenas o relatório interno. Em projetos de backup e continuidade, o teste de restauração faz parte do aceite obrigatório, executado no data center próprio em Alphaville, com relatório entregue ao cliente.

Com mais de 550 empresas atendidas, o padrão que se repete é claro: os projetos que terminam no prazo e sem atrito são aqueles em que a régua foi definida antes, não durante. O encerramento vem acompanhado de janela de garantia definida, documentação transferida e transição formal para o suporte 24/7 com SLA, de modo que a operação não fica órfã no dia seguinte à virada.

Se sua empresa tem projetos de TI que se arrastam sem data de fim, ou histórico de disputa com fornecedor sobre o que estava ou não incluído, o primeiro passo não é trocar de fornecedor — é revisar como o aceite está sendo definido. A conversa sobre critérios objetivos costuma resolver mais do que a troca de contrato.