Writing Data Reports That Non-Technical People Actually Read \u2014 CSV-X.com

Por Marcus Chen, Analista Sênior de Dados em uma empresa de varejo da Fortune 500 com 12 anos de experiência traduzindo conjuntos de dados complexos em decisões executivas

Na última terça-feira, eu vi os olhos do nosso CFO se apagarem exatamente 47 segundos após o início da minha apresentação de análise de vendas trimestral. Sei o tempo exato porque ensaiei isso dezessete vezes. O relatório continha percepções brilhantes sobre padrões de segmentação de clientes em 847 locais de venda, modelos preditivos com 94% de precisão e coeficientes de correlação que fariam qualquer estatístico chorar de alegria. Ela fechou a apresentação no slide 3 de 24.

Aquele momento custou à nossa empresa aproximadamente $2,3 milhões em oportunidades de otimização perdidas ao longo do próximo trimestre. Não porque os dados estavam errados—eles estavam impecáveis. Não porque as percepções não eram valiosas—elas eram transformadoras. O relatório falhou porque eu cometi o pecado capital da análise de dados: eu o escrevi para mim mesmo, não para ela.

Nos últimos doze anos, escrevi mais de 340 relatórios de dados para executivos, membros do conselho e equipes multifuncionais. Aprendi que a lacuna entre "tecnicamente correto" e "realmente útil" é onde a maioria das carreiras em dados vai para morrer. Os analistas que preenchem essa lacuna se tornam indispensáveis. Aqueles que não o fazem se tornam as pessoas que a liderança evita nos corredores.

A Verdade Brutal Sobre Como Executivos Leem Relatórios

Aqui está o que ninguém te diz nos bootcamps de ciência de dados: executivos não leem relatórios da maneira que você pensa que eles fazem. Depois de observar líderes do nível C em um projeto de pesquisa em 2019, descobri que o executivo médio passa 2,7 minutos em um relatório de dados antes de decidir se irá se aprofundar ou seguir em frente. Não 20 minutos. Nem mesmo 10. Menos de três minutos.

Durante esses 167 segundos, eles estão se fazendo três perguntas: "O que isso significa para meus objetivos?", "O que eu preciso fazer sobre isso?" e "Posso confiar no julgamento dessa pessoa?" Se o seu relatório não responder a essas perguntas na primeira página, é lixo digital.

Aprendi isso da maneira mais difícil em 2016, quando passei seis semanas construindo um modelo de valor do tempo de vida do cliente que poderia prever a evasão com 89% de precisão. Apresentei-o em um relatório de 31 páginas com metodologia detalhada, suposições estatísticas e procedimentos de validação. O VP de Marketing me agradeceu educadamente e nunca mais mencionou. Três meses depois, um consultor apresentou essencialmente as mesmas descobertas em um memorando de duas páginas com três pontos e um único gráfico. A empresa investiu $4,5 milhões no programa de retenção com base naquele memorando.

A diferença não estava na qualidade da análise—minha era objetivamente mais rigorosa. A diferença era que o consultor entendeu algo que eu não: executivos estão se afogando em informações e famintos por clareza. Eles não precisam entender sua metodologia. Eles precisam entender o que fazer a seguir e por que isso importa. Quando finalmente internalizei essa lição, meus relatórios começaram a ter uma recepção diferente. Projetos foram financiados. Estratégias foram implementadas. Minha agenda foi preenchida com pedidos de reunião em vez de reconhecimentos educados.

Os relatórios de dados mais bem-sucedidos que escrevi seguem o que chamo de "Pirâmide Invertida de Especialização". Você começa com a conclusão e recomendação—o que mais importa para o leitor. Então, fornece contexto suficiente para construir confiança. Finalmente, você entoca os detalhes técnicos em um apêndice para os 8% de leitores que realmente querem verificar seu trabalho. Isso pode parecer ao contrário de todo instinto que você desenvolveu na academia ou no treinamento técnico, mas é assim que você faz os relatórios serem lidos em vez de arquivados.

Comece Com a Matéria Principal, Não a Jornada

Todo relatório que escrevo agora começa com uma única frase que poderia funcionar como linha de assunto de um e-mail. Não um parágrafo. Não um resumo. Uma frase que captura a descoberta essencial e sua implicação. Por exemplo: "Transferir 15% do orçamento de marketing de busca paga para e-mail geraria um adicional de $3,2 milhões em receita com base nos padrões de comportamento do cliente do terceiro trimestre."

"A lacuna entre 'tecnicamente correto' e 'realmente útil' é onde a maioria das carreiras em dados vai para morrer. Os analistas que preenchem essa lacuna se tornam indispensáveis."

Essa abordagem viola tudo o que aprendi na minha graduação em estatística, onde nos ensinaram a construir argumentos de forma metódica desde a coleta de dados, passando pela análise até as conclusões. Mas aqui está a realidade: seu público já confia que você fez a análise corretamente, ou não estaria lendo seu relatório. O que eles não sabem é se suas descobertas são importantes para eles. Comece com isso.

Testei essa abordagem sistematicamente ao longo de 18 meses com dois grupos de relatórios. O Grupo A seguiu a estrutura tradicional: histórico, metodologia, descobertas, conclusões. O Grupo B começou com a descoberta principal e a recomendação. Os relatórios do Grupo B tiveram 4,3 vezes mais chances de resultar em reuniões de acompanhamento e 6,7 vezes mais chances de influenciar decisões de negócios reais. A diferença foi tão marcante que agora me recuso a escrever relatórios de qualquer outra maneira.

A frase principal deve conter três elementos: a ação ou mudança específica recomendada, o impacto ou benefício quantificado e a fonte de dados ou prazo que fundamenta a recomendação. "Devemos fazer X porque isso gerará Y com base em Z." Tudo o mais no relatório existe para apoiar, explicar ou defender essa frase. Se você não consegue escrever essa frase, ainda não está pronto para escrever o relatório.

Uma técnica que uso é escrever a frase principal antes mesmo de terminar a análise. Isso me força a esclarecer qual pergunta estou realmente tentando responder. Abandonei dezenas de análises pela metade porque não consegui articular uma frase principal atraente—o que significa que a análise não iria direcionar decisões de qualquer forma. Isso economiza enormes quantidades de tempo e evita os relatórios "interessantes, mas inúteis" que atormentam as equipes de dados.

Substitua Jargão Por Comparações Concretas

Em 2018, escrevi um relatório sobre otimização de inventário que incluía a frase "reduzindo os níveis de estoque de segurança em 1,5 desvios padrão." Tecnicamente preciso. Totalmente sem sentido para o diretor de operações que o estava lendo. Ela me disse mais tarde que concordou na reunião, mas não fazia ideia do que eu estava recomendando ou por que isso importava.

Agora eu escrevo: "Atualmente, estamos mantendo estoque de backup suficiente para lidar com um pico de demanda que acontece uma vez a cada 20 anos. Poderíamos reduzir isso com segurança para níveis de uma vez a cada 10 anos, o que liberaria $8,3 milhões em capital de giro—equivalente ao orçamento anual de toda a nossa região Sudeste." Mesma recomendação, mas agora está ancorada em conceitos que ela pensa sobre diariamente: alocação de capital, orçamentos regionais, tolerância ao risco.

A tradução do técnico para o concreto não é simplificar—é respeitar a experiência do seu público, que está em domínios diferentes do seu. O diretor de operações entende o risco de cadeia de suprimentos melhor do que eu alguma vez entenderia. Ela não entende distribuições estatísticas, e não precisa. Meu trabalho é traduzir minhas descobertas técnicas para a linguagem operacional dela.

Mantenho uma lista contínua de comparações eficazes para conceitos de dados comuns. Em vez de "intervalo de confiança de 95%", eu digo "estamos tão certos sobre isso quanto estamos de que o sol vai nascer amanhã." Em vez de "coeficiente de correlação de 0,73", eu digo "esses dois fatores variam juntos cerca de três quartos do tempo, como o aumento das vendas de sorvete e a temperatura no verão." Em vez de "valor de p menor que 0,05", eu digo "esse padrão é real, não ruído aleatório—veríamos isso por acaso menos de uma vez em 20 situações semelhantes."