Checklist, de Atul Gawande: como evitar erros quando já sabemos o que fazer

Há erros que acontecem porque ainda não sabemos o suficiente. Outros acontecem apesar de sabermos exatamente o que deveria ter sido feito.

É sobre estes últimos que Atul Gawande escreve em Checklist — Como fazer as coisas bem. Num mundo em que o conhecimento e a complexidade ultrapassaram a capacidade de uma única pessoa memorizar, coordenar e executar tudo sem falhas, a competência individual já não chega. Precisamos de sistemas que protejam os passos críticos precisamente quando a pressão, a rotina ou o excesso de confiança nos tornam mais vulneráveis.

Este não é, contudo, um livro sobre transformar pessoas em máquinas obedientes. É um livro sobre criar espaço para que pessoas competentes consigam exercer melhor o seu julgamento.

O problema: ignorância ou falha de execução?

Gawande distingue dois tipos de falha. Existe a ignorância: falhamos porque ainda não sabemos como resolver determinado problema. Nesse caso, precisamos de investigação, aprendizagem ou experimentação.

E existe a ineptidão: o conhecimento necessário já existe, mas não foi aplicado corretamente. Um passo foi esquecido, uma informação não circulou, uma verificação não aconteceu ou várias pessoas assumiram que outra pessoa trataria do assunto.

Se tratarmos uma falha de execução como falta de conhecimento, criamos mais formação, documentação e reuniões sem resolver o problema. Quando as pessoas já sabem o que fazer, aquilo que pode faltar é um sistema que torne a execução mais fiável.

Se não sabíamos, precisamos de aprender. Se sabíamos mas não fizemos, precisamos de melhorar o processo, o gatilho ou a checklist.

A ideia central

À medida que uma atividade se torna mais complexa, a memória e a atenção individuais deixam de ser garantias suficientes.

Isto acontece em blocos operatórios, na aviação e na construção, mas também numa pequena empresa, numa associação, numa equipa ou numa família. Quanto mais pessoas, decisões, exceções e dependências existem, maior é a probabilidade de um passo aparentemente óbvio ficar por fazer.

A checklist funciona como proteção contra essa fragilidade. Não substitui conhecimento, experiência ou responsabilidade. Garante apenas que alguns elementos críticos não dependem exclusivamente da memória de alguém.

O seu valor não está em listar tudo. Está em identificar aquilo que é simultaneamente essencial, vulnerável ao esquecimento, verificável e necessário num momento concreto.

Uma checklist não é uma lista de tarefas

Uma lista de tarefas pode conter tudo o que precisamos de fazer. Uma checklist contém os pontos críticos que precisamos de confirmar para executar uma atividade com segurança e consistência.

Se uma checklist tenta explicar todo o processo, deixa de ser uma checklist e transforma-se num manual. O manual pode ser necessário, mas serve uma função diferente.

READ–DO

Lemos cada ponto e executamo-lo antes de avançar. É adequado quando a ordem é importante ou quando os passos devem ser realizados um a um.

DO–CONFIRM

Executamos a atividade com base na experiência e, num momento definido, usamos a checklist para confirmar que nenhum ponto crítico ficou esquecido.

Este formato preserva melhor a autonomia de profissionais experientes. A checklist não lhes diz como fazer o trabalho; obriga-os apenas a confirmar os elementos indispensáveis.

A importância do momento certo

Uma checklist excelente apresentada no momento errado continua a ser inútil.

Por isso, deve existir um ponto de pausa claro: antes de enviar, antes de abrir, antes de fechar, antes de começar, antes de o cliente sair ou imediatamente após determinado acontecimento.

“Rever quando houver tempo” não é um ponto de pausa. É uma intenção vaga. O gatilho deve estar incorporado no próprio fluxo de trabalho.

Checklists também servem para obrigar as pessoas a comunicar

Nem todos os pontos críticos são tarefas técnicas. Em ambientes complexos, muitos erros acontecem porque a informação relevante fica fragmentada entre pessoas.

Por isso, uma checklist pode incluir momentos como:

• confirmar quem é responsável por cada parte;
• partilhar riscos ou dúvidas antes de começar;
• garantir que todos trabalham com a mesma informação;
• interromper o processo quando surge uma anomalia.

Uma equipa não se torna coordenada apenas porque os seus membros são competentes.

O framework CHECK

• C — Critical: inclui apenas aquilo cuja omissão tem consequências relevantes.
• H — Human: protege pontos vulneráveis ao esquecimento, à distração ou à suposição.
• E — Exact moment: define o instante concreto em que a verificação acontece.
• C — Communication: inclui as trocas de informação indispensáveis entre pessoas.
• K — Keep it short: mantém a checklist curta, clara e utilizável sob pressão.

Se não sabemos explicar quando será usada, por quem e para prevenir qual falha, provavelmente ainda não temos uma checklist. Temos apenas uma lista.

Como criar uma checklist realmente utilizada

1. Escolher um processo recorrente com falhas reais. Não começar por uma atividade apenas porque parece organizada o suficiente para ter uma checklist.
2. Identificar os erros mais perigosos ou frequentes. Procurar aquilo que já foi esquecido, duplicado, comunicado tarde ou assumido incorretamente.
3. Selecionar apenas os pontos críticos. Se tudo é prioritário, nada é prioritário.
4. Definir o tipo de checklist. Decidir entre READ–DO e DO–CONFIRM.
5. Criar um ponto de pausa inequívoco. A utilização deve estar associada a um momento observável.
6. Escrever instruções curtas e concretas. Cada linha deve ser rapidamente compreendida.
7. Testar em condições reais. Uma checklist desenhada numa secretária é apenas uma hipótese.
8. Observar onde cria atrito ou ambiguidade. Se é sistematicamente ignorada, o problema pode estar no desenho.
9. Corrigir e testar novamente. A primeira versão não merece estatuto permanente.
10. Eliminar o que deixou de ser crítico. Uma checklist deve evoluir com o processo.

Onde isto se torna útil na vida real

Não precisamos de uma checklist para escovar os dentes. Precisamos dela quando a complexidade, a frequência ou o custo do erro justificam uma proteção adicional.

• abertura e fecho de uma loja;
• publicação de um novo produto num e-commerce;
• preparação de uma campanha;
• entrega de um trabalho a um cliente;
• organização de uma assembleia ou processo eleitoral;
• preparação de uma atividade com jovens;
• saída de casa para uma viagem familiar;
• integração de uma nova pessoa numa equipa.

O que o livro não deve levar-nos a fazer

O entusiasmo por sistemas pode facilmente transformar-se em burocracia.

Nem tudo precisa de uma checklist. Uma checklist excessiva pode retirar atenção ao que é realmente importante, criar uma falsa sensação de segurança e permitir que as pessoas deixem de pensar.

Também não resolve falta de competência, ausência de responsabilidade ou uma cultura em que ninguém se sente autorizado a levantar problemas. Um processo não substitui confiança nem julgamento.

O teste decisivo não é saber se a checklist existe. É saber se reduz erros relevantes sem criar mais atrito do que valor.

Para quem vale a pena

• quem gere equipas, projetos ou operações recorrentes;
• quem trabalha em ambientes onde pequenas omissões têm consequências importantes;
• quem sente que está constantemente a resolver os mesmos erros;
• quem depende demasiado da memória, de mensagens dispersas ou de pessoas específicas;
• quem quer criar sistemas sem sufocar a autonomia.

Poderá ser menos útil para: quem procura apenas técnicas rápidas de produtividade pessoal. O argumento de Gawande é mais profundo: não se trata de fazer mais tarefas, mas de tornar sistemas complexos mais fiáveis.

Uma aplicação para hoje

Escolhe apenas um processo que tenha falhado ou criado stress recentemente. Responde a três perguntas:

1. O que já sabíamos que deveria ter acontecido?
2. Que passo crítico foi esquecido, atrasado ou mal comunicado?
3. Em que momento concreto poderíamos verificá-lo da próxima vez?

Transforma as respostas numa checklist experimental com, no máximo, sete pontos. Usa-a uma vez e corrige-a depois da experiência.

Não cries já uma biblioteca de processos. Resolve uma falha real.