A 30 de outubro de 1935, em Wright Field, no Ohio, o Exército dos EUA (US Army Air Corps) reuniu-se para assistir a uma formalidade. O Model 299 da Boeing era mais rápido, voava mais longe e transportava mais carga do que qualquer outro concorrente apresentado; o exército estava praticamente a assinar a encomenda. A aeronave descolou, subiu a cerca de trezentos pés, entrou em perda e caiu numa bola de fogo que matou dois dos cinco homens a bordo, incluindo o piloto, o major Ployer Hill — que, por acaso, era o chefe de ensaios de voo do Air Corps, tão experiente quanto um piloto podia ser.
A investigação não encontrou qualquer falha na aeronave. Hill, ocupado com os inúmeros comandos de uma máquina muito mais complexa do que qualquer uma que tivesse pilotado antes, tinha simplesmente esquecido de libertar um bloqueio do leme de profundidade. Um jornal resumiu bem a situação: era avião a mais para um único homem pilotar. A parte instrutiva é o que os pilotos de ensaio fizeram a seguir. Não prescreveram mais treino — o seu piloto mais experiente tinha acabado de morrer. Escreveram uma checklist curta com os passos que todos os pilotos já conheciam, para ser lida em voz alta antes da descolagem. O Model 299 seguiu em frente, como o B-17, e voou bem mais de um milhão de milhas sem um acidente comparável.
A história chegou à medicina através do cirurgião Atul Gawande, cujas equipas testaram uma checklist cirúrgica de dezanove itens em oito hospitais. As complicações graves caíram de 11% para 7%, e as mortes de doentes internados de 1,5% para 0,8%, ambas em mais de um terço. Vale a pena referir também a contraprova honesta: uma implementação posterior no Ontário não encontrou uma melhoria significativa, o que revela algo importante — uma checklist lida em voz alta enquanto todos assinalam caixas e olham para o chão não serve de nada. Só funciona quando quem a usa realmente pára e verifica.
A um modelo financeiro sério é, exatamente neste sentido, modelo a mais para um único analista guardar na cabeça. Os erros em folhas de cálculo mais dispendiosos alguma vez registados foram cometidos por especialistas, não por principiantes. Por isso, o argumento para rever um modelo face a uma lista fixa é o mesmo que o da checklist do piloto: não que sejamos descuidados, mas que a tarefa tem mais partes móveis do que a memória de trabalho consegue policiar, e as falhas são silenciosas. Segue-se a lista que eu percorreria antes de deixar um modelo sair das minhas mãos. Trate-a como algo a verificar, não a assinalar.
1. Integridade — os números batem certo?
- O balanço fecha em todos os períodos e em todos os cenários. O ativo é igual ao passivo mais o capital próprio, ano a ano, no cenário base, otimista e pessimista — não apenas naquele que apresentou.
- As três demonstrações financeiras encaixam entre si. O resultado líquido cai nos resultados transitados; o cash flow reconcilia com a linha de caixa do balanço. Um modelo em que estas se desviam está errado nalgum sítio que ainda não verificou.
- Nenhum número está fixado (“hard-coded”) dentro de fórmulas. Os inputs vivem em células de input, não escondidos a meio de um cálculo onde ninguém os vai encontrar para atualizar.
- Os totais captam todas as linhas. Este é o erro de Reinhart-Rogoff: uma média ou uma soma que silenciosamente para umas linhas antes do fim e desvia toda a conclusão.
- Os sinais e as unidades são consistentes do início ao fim. Nenhum custo é acidentalmente somado como receita, nenhum valor mensal é multiplicado por um valor anual.
2. Rastreabilidade — outra pessoa consegue segui-lo?
- Todos os pressupostos relevantes têm uma origem ou justificação visível. Um número sem proveniência é um palpite que mais tarde terá de defender sem nada.
- A lógica corre numa única direção, dos inputs aos drivers e destes aos outputs. Qualquer circularidade é intencional, documentada e explicável.
- Um novo leitor consegue encontrar os dois ou três drivers principais em poucos minutos. Se não conseguir, também o cliente não conseguirá, nem você mesmo dentro de seis meses.
- O modelo pode ser reproduzido a partir dos seus inputs. Os mesmos inputs devolvem os mesmos outputs, sem ajustes manuais que só existem na memória do autor.
- Existe um histórico de versões real. Consegue dizer o que mudou entre esta versão e a anterior, e porquê — para além de um nome de ficheiro terminado em
_final_v3.
3. Robustez — sobrevive ao contacto com a incerteza?
- Os pressupostos que mais influenciam o resultado estão identificados. Uma análise de sensibilidade identifica-os; a intuição normalmente engana-se quanto a eles.
- Existe um cenário pessimista genuíno. Não o cenário base com números mais pequenos, mas um cenário em que uma decisão real — contratação, preços, momento de financiamento — mudaria.
- O modelo foi testado em toda a amplitude, não apenas em três pontos escolhidos a dedo. Análise de cenários, e simulação de Monte Carlo quando a importância o justifica.
- A tesouraria é verificada mês a mês, não apenas como um VAL (NPV) ao longo do horizonte. Um projeto pode ser solvente ao longo de cinco anos e insolvente no décimo quarto mês.
- O ponto de equilíbrio (break-even) e as condições para o atingir estão explícitos. Consegue afirmar claramente o nível a partir do qual o plano deixa de funcionar.
4. Entregabilidade — pode sair das suas mãos em segurança?
- O cliente conseguiria questioná-lo sem que estivesse presente. O teste da entrega: um modelo cuja lógica morre com o seu autor é um passivo, não um ativo.
- Os resultados principais coincidem com a narrativa da apresentação. Sem desvio entre o que o modelo diz e o que os slides afirmam.
- Os inputs confidenciais e sensíveis são tratados de forma deliberada. Dados escondidos que vazam através de uma tabela dinâmica ou de uma coluna “removida” são uma categoria de desastre documentada, não uma hipótese.
- O ficheiro que entrega é o ficheiro que reviu. Uma versão, identificada, não uma pasta cheia de quase-duplicados.
- Alguém que não o autor reviu-o. O princípio dos quatro olhos justifica o seu lugar porque o erro que lisonjeia a sua conclusão é precisamente aquele que menos inclinado está a procurar.
Como usar a lista, e para onde vai o trabalho
Percorra a lista em quatro passagens, não em vinte olhares dispersos, e resista à tentação de assinalar de memória — o resultado do Ontário é o que a marcação mecânica lhe compra. Algumas destas verificações são tediosas à mão e discretamente automáticas quando o modelo assenta nos alicerces certos. Um motor determinístico transforma o “reproduzível a partir dos seus inputs” numa garantia, em vez de uma aspiração; um histórico de versões incorporado transforma o “o que mudou e porquê” numa única comparação; cenários nativos e simulação de Monte Carlo transformam a secção de robustez de um projeto à parte num simples separador. O FinModeler foi construído precisamente à volta destas propriedades, o que significa que boa parte desta checklist é menos uma tarefa a cumprir do que uma descrição do que uma infraestrutura decente lhe oferece de graça.
Os itens que restam — proveniência, consistência da narrativa, um cenário pessimista real, o segundo par de olhos — são questão de discernimento, e nenhuma ferramenta os realiza por si. É precisamente esse o propósito de os escrever. O major Hill sabia pilotar a aeronave. Ainda assim, precisou da lista.
Compare as versões do seu modelo antes de decidir — construa e reveja o seu modelo no FinModeler. Quer a versão de uma página para manter junto ao ecrã? Descarregue a Checklist de Revisão de Modelos em PDF, pronta a imprimir.
Perguntas frequentes
Para quem é esta checklist?
Qualquer pessoa que entregue um modelo financeiro do qual outra pessoa vá depender — consultores e assessores, acima de tudo, mas também fundadores a preparar-se para investidores e professores a avaliar os modelos dos alunos. O fio condutor é a responsabilização: tem de defender o modelo, não apenas construí-lo.
Uma checklist não é um pouco básica para um modelador experiente?
A experiência é exatamente a razão pela qual ajuda. Os desastres de modelação mais citados foram produzidos por pessoas competentes cuja memória de trabalho simplesmente não conseguiu policiar todas as partes móveis. Uma checklist tira de cima de si a tarefa de memorizar, para que a atenção possa ir para o discernimento.
A ordem das quatro secções é importante?
De um modo geral, sim. A integridade vem primeiro porque um modelo cujos números não batem certo torna qualquer verificação posterior irrelevante. Seguem-se a rastreabilidade e a robustez, e a entregabilidade em último lugar, uma vez que é o último portão antes de o modelo sair das suas mãos.
Fontes
- O acidente do Boeing Model 299, a omissão do bloqueio (“gust lock”) e a origem da checklist do piloto; os resultados da checklist cirúrgica (complicações 11%→7%, mortes 1,5%→0,8%) e o resultado nulo posterior no Ontário: Atul Gawande, The Checklist Manifesto; Haynes et al., A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population, NEJM (2009); Urbach et al. sobre a implementação no Ontário, NEJM.
- Categorias de erros em folhas de cálculo referidas na checklist (totais, confidencialidade, quatro olhos): o arquivo do European Spreadsheet Risks Interest Group, tal como discutido no artigo complementar sobre o caos das folhas de cálculo.