Como funciona o processo de dois engenheiros estão verificando
Quando você trabalha com sistemas críticos, uma verificação única nunca é suficiente. O método conhecido como dois engenheiros estão verificando consiste em ter duas pessoas independentes analisarem o mesmo artefato — seja um projeto, um código ou um cálculo — antes de qualquer liberação. Não é sobre desconfiança. É sobre reduzir a probabilidade de erro para algo dentro de limites aceitáveis. Na prática, isso significa que o engenheiro A desenvolve ou revisa algo, e o engenheiro B refaz a verificação do zero, sem consultar as anotações do primeiro. Só depois as duas perspectivas são confrontadas. O tempo gasto nessa etapa costuma representar entre 15% e 30% do ciclo total de desenvolvimento, mas projetos que pulam essa fase frequentemente gastam três vezes mais corrigindo problemas pós-lançamento.
dois engenheiros estão verificando na prática
O problema mais chato que já encontrei envolvendo esse processo ocorreu durante a revisão de uma arquitetura de controle para um sistema de instrumentação industrial. Um dos engenheiros estava verificando as tolerâncias de um laço de PID e assumiu que o sensor de temperatura tinha linearidade perfeita. O outro engenheiro, que estava verificando a parte de comunicação serial, notou que o protocolo de transmissão impunha um erro de quantização que, somado à não linearidade do sensor, gerava uma oscilação de meio grau no setpoint. Se apenas um tivesse revisado, o bug seria descoberto meses depois em campo. A solução foi simples: criei uma planilha de cruzamento onde cada parâmetro tinha colunas separadas para valores calculados, valores medidos e margem de erro aceitável. Isso permitiu que os dois engenheiros vissem onde suas análises convergiam e onde divergiam, sem precisar ficar interrompendo um ao outro a cada duvida. Reduziu o tempo de revisão de quatro dias para dois.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que poucos iniciantes entendem é que a verificação independente só funciona se as duas pessoas realmente trabalharem de forma isolada. Se o engenheiro B consulta o resultado do engenheiro A antes de fazer seu próprio cálculo, o processo vira uma mera confirmação, não uma verificação. Já vi times inteiros cometendo esse erro e acreditando que estavam seguindo um protocolo rigoroso. Outro ponto que as pessoas subestimam é a escolha de quem faz a segunda verificação. Ter um colega júnior revisando o trabalho de um sênior raramente encontra os mesmos tipos de erro. O ideal é que o segundo verificador tenha profundidade técnica equivalente e, preferencialmente, uma especialidade complementar. Alguém que entenda bem de teoria de controle pode não notar um problema de interface que alguém focado em software identifieria em segundos.
Existem situações em que dois engenheiros estão verificando simplesmente não funciona. Quando o prazo é extremamente apertado e o risco percebido pelo gestor é baixo, a pressão por velocidade costuma matar o processo. Também não se aplica bem a tarefas muito simples ou repetitivas, onde o custo da segunda revisão supera o custo potencial de um erro. Nesse caso, automação de teste ou verificações por checklist são mais eficientes. Se o seu time ainda não tem um procedimento estruturado, comece com um guia básico antes de implementar anything sofisticado. O documento deve definir: o que precisa ser verificado, quem pode fazer a segunda revisão, como registrar as divergências e qual critério fecha uma verificação como aprovada. Sem isso, o processo se transforma em conversa de corredor e ninguém assume responsabilidade pelo resultado.
