A auditoria é um "mecanismo de revelação de problemas"

O objetivo da auditoria (ou seja, outra IA verificar o conteúdo do trabalho realizado) não é receber um GO (aqui: sinal de aprovação para seguir em frente).

Esse é o ponto central do princípio que tentamos transmitir ao longo desta segunda parte. A auditoria não foi projetada como um "rito de passagem", mas como um "mecanismo para trazer problemas à superfície". Neste capítulo, vamos organizar o que isso significa.

Fazer auditoria "para conseguir o GO" desvia do propósito

Quando você ouve a palavra auditoria, talvez venha à mente a ideia de que "se o GO sair, foi um sucesso". Há uma revisão, você é aprovado. Há um teste, você passa. É uma sensação que vem de experiências como essa.

No entanto, a auditoria na organização que desenvolvemos nesta série tem um posicionamento um pouco diferente.

Quando o objetivo se torna obter o GO, a forma de conduzir a auditoria muda. Ao agir com a perspectiva de "será que passa?", a atenção se volta menos para encontrar problemas e mais para traçar a linha de onde algo conta como problema. Se o limiar (aqui: a linha de corte para julgar se há problema) for definido de forma permissiva, os problemas se tornam menos visíveis. O GO fica mais fácil de sair, mas os problemas reais permanecem.

A auditoria genuína funciona na direção oposta. Não "verificar se não há problemas", mas "garantir que qualquer problema apareça". Se o design não tolerar a possibilidade de o GO não sair, a auditoria se torna uma formalidade vazia (aqui: a estrutura mantém a forma, mas deixa de funcionar).

Qual é a diferença em relação a "procurar falhas"?

Aqui, vamos esclarecer algo que costuma ser confundido.

Quando se fala em "trazer problemas à tona", pode parecer que se trata de procurar falhas (aqui: buscar defeitos do outro para criticá-lo). Porém, o que a auditoria busca é diferente.

Procurar falhas tem ênfase em encontrar problemas para criticar alguém ou provar um fracasso. O problema encontrado vira material para cobrar responsabilidades ou avaliar o desempenho.

O motivo pelo qual a auditoria traz problemas à tona é diferente. Se problemas permanecerem sem ser resolvidos nas etapas posteriores, surgem custos maiores e retrabalho. O objetivo é a sequência de revelar o problema cedo e corrigi-lo. O fato de um problema aparecer não é prova de fracasso — é a confirmação de que "agora ainda dá para corrigir".

Essa diferença também afeta a mentalidade de quem opera o sistema. Em uma cultura onde "trazer um problema significa ser criticado", o responsável pela auditoria fica relutante em revelar problemas. Se o design for "trazer problemas é o trabalho", o responsável pela auditoria pode fazê-lo sem hesitação. O design que se adota muda a qualidade das informações que efetivamente chegam.

Quando apontamentos aparecem, é sinal de que a auditoria está funcionando

Há uma experiência que vivemos ao montar e colocar isso em prática.

Em relação a uma entrega de determinada rodada, a IA responsável pela auditoria retornou vários apontamentos. A princípio, ao ver a quantidade, sentimos que "há muitos problemas". Mas ao ler o conteúdo de cada apontamento, nenhum podia ser ignorado. Havia divergências na comparação com as diretrizes, termos técnicos que não foram explicados com clareza suficiente, e lacunas na consistência entre capítulos anteriores e posteriores.

Ao comparar o resultado corrigido com a entrega original, a versão corrigida estava claramente melhor. Não foi porque havia muitos apontamentos que havia muitos problemas — foi porque havia muitos problemas que os apontamentos apareceram. Essa é a ordem correta.

A auditoria não está criando problemas. Está apenas trazendo à superfície problemas que já existiam. Uma auditoria com zero apontamentos não significa que não há problemas. Pode ser que os problemas simplesmente não tenham sido encontrados.

"Apontamentos aparecerem" é sinal de que o mecanismo está funcionando normalmente.

Projetar para continuar mesmo quando há problemas

A ansiedade de "talvez apareçam problemas" tende a se transformar em resistência a colocar a auditoria em movimento. Mas os problemas já existem antes de serem revelados. Só não estão visíveis.

Comparando revelar problemas cedo com os problemas virem à tona em uma etapa posterior, o custo de lidar com eles é menor no primeiro caso. Quanto mais tarde um problema é descoberto, mais amplo o alcance das correções necessárias.

No design que operamos neste projeto, quando a auditoria identifica um problema, apresentamos isso diretamente à pessoa responsável pela aprovação. Não "havia um problema, então o GO está retido", mas "foram encontrados tais e tais problemas, por favor, decida o que fazer".

O fato de haver um problema e a decisão de prosseguir ou não são tratados como assuntos separados. Avaliando o tamanho do problema, a urgência e o alcance do impacto, o responsável pela aprovação decide "corrigir antes de prosseguir", "prosseguir assim mesmo" ou "pausar por ora". O papel da auditoria é identificar e registrar os problemas — não tomar as decisões seguintes.

Com esse design, criamos uma estrutura em que o responsável pela auditoria consegue "revelar" problemas mais facilmente. Não há motivo para esconder, e revelar é, por si só, a conclusão da função.

Síntese deste capítulo

O objetivo da auditoria não é receber um GO, mas trazer problemas à superfície.

O fato de problemas aparecerem não é sinal de fracasso — é sinal de que o mecanismo está funcionando. Por outro lado, quando zero apontamentos se tornam a norma, isso se torna motivo para verificar a granularidade do processo e a forma como a auditoria está sendo conduzida.

A auditoria não é procurar falhas. É um design para encontrar problemas cedo e reduzir o retrabalho nas etapas posteriores. Manter uma estrutura em que revelar problemas é, por si só, a conclusão da função — essa é a base para impedir que a auditoria se torne uma formalidade vazia.