Guia prático: avaliando dois lados da mesma moeda em projetos de dados
Quando eu comecei a trabalhar com análises de resultado de campanhas e relatórios financeiros, logo percebi que a maioria dos dashboards entregava apenas metade da história. A métrica de performance estava sempre presente, mas o custo por unidade gerada, o tempo de ciclo ou a taxa de retrabalho simplesmente não apareciam. Isso me levou a desenvolver uma estrutura que chamamos internamente de dois lados da mesma moeda — um método de avaliação simultânea de duas métricas correlacionadas para evitar decisões enviesadas. Não é nada revolucionário no sentido acadêmico. É basicamente parar de olhar para um único KPI e começar a cruzá-lo sistematicamente com sua contraparte direta. A diferença entre um relatório que te faz parecer produtivo e um que mostra se você está realmente sendo produtivo costuma ser essa.
O conceito de dois lados da mesma moeda na prática
A ideia central é simples: todo indicador de desempenho tem um lado que mostra o avanço e outro que mostra o custo ou o esforço necessário para chegar lá. Separados, eles geram ilusão. Cruzados, geram informação. Pegue velocidade de entrega versus taxa de defeitos. Pegue receita bruta versus margem líquida. Pegue número de Leads versus taxa de conversão real. O que a maioria das equipes não faz é criar um formato fixo para isso. Elas olham para os dois lados quando a crise aperta e voltam a ignorar um deles assim que a poeira baixa. Eu mudei isso inserindo os dois lados como campos obrigatórios em qualquer relatório que eu enviasse. Se alguém pedia resultado de campanha, vinha junto o custo de manutenção. Se pedia throughput de desenvolvimento, vinha junto a taxa de bugs em produção. Não era opcional.
Um problema recorrente que eu encontrei foi quando as duas métricas operavam em escalas completamente diferentes. Velocidade de deploy era medida em horas, enquanto o custo operacional vinha em valores monetários com casas decimais distintas. Comparar diretamente gerava distorção visual nos gráficos. Minha solução foi normalizar ambas as escalas usando z-score antes de plottar no dashboard. Isso transformou os valores em desvios padrão em relação à média, e aí a comparação passou a fazer sentido visualmente. O script que eu escrevi em Python para isso é praticamente copiar e colar em qualquer pipeline:
👉 Clique no botão abaixo para saber mais sobre o assunto!
from scipy.stats import zscore
def normalizar_duo(lado_a, lado_b):
return zscore(lado_a), zscore(lado_b)
Depois disso, eu plotava os dois eixos no mesmo gráfico de dispersão. O quadrante superior direito sempre mostrava o cenário ideal — alta performance e baixo custo relativo. O inferior esquerdo era o que precisava de atenção imediata. O restante era análise contextual.
Por que isso falha em alguns cenários
Não funciona em tudo. Se uma das variáveis for intrinsicamente qualitativa — satisfação do cliente, por exemplo —, a normalização estatística perde o sentido. Nesses casos, a alternativa que eu uso é transformar a variável qualitativa em frequências de categorias e cruzar com a quantitativa através de tabelas de contingência. Fica menos bonito visualmente, mas funciona. Também há o problema de correlações espúrias. Já vi times tratarem duas métricas como opostas quando na verdade ambas cresciam juntas por um fator externo não medido. Uma vez eu identifiquei aumento simultâneo de velocity e de bugs, atribuí a culpa à pressa do produto. Só depois de isolar a variável "novos integrantes no sprint" é que percebi que o verdadeiro causal era rotatividade, não pressão por entrega. O dois lados da mesma moeda revela o problema, mas não diagnosticou a causa raiz sozinho. Aqui entra a necessidade de validação com regressão múltipla ou pelo menos análise de variância antes de tomar decisões baseadas nos padrões observados.
Implementação passo a passo
- Escolha o par de métricas — Defina quais dois indicadores representam os lados que importam para o seu contexto. Não escolhe por conveniência, escolhe por relevância causal.
- Coleta consistente — As duas métricas precisam ter a mesma granularidade temporal. Se uma é diária e a outra semanal, o cruzamento vai mentir.
- Normalização ou padronização — Aplique z-score, min-max ou log-transform conforme a distribuição dos dados. Dados com cauda longa pedem log; dados bimodais podem precisar de segmentação prévia.
- Plotagem em gráfico de dispersão com quadrantes — Eixo X para um lado, eixo Y para o outro. Trace linhas de mediana para dividir em quatro quadrantes.
- Monitoramento contínuo — Atualize mensalmente. Um snapshot único engana mais do que ajuda.
O resultado final é um painel que você pode montar em Excel, Google Sheets ou qualquer ferramenta de BI. O custo de implementação inicial gira em torno de 4 a 6 horas para quem já tem familiaridade com Python ou até mesmo com funções nativas de planilha como NORM.S.DIST e PERCENTILE. Para equipes menores sem expertise técnica, ferramentas como Metabase ou Redash oferecem templates prontos de scatter plot com bissetrizes que dispensam código. O que eu mais vejo acontecendo é gente implementing o método mas esquecendo de revisar os quadrantes periodicamente. As fronteiras dos quadrantes não são eternas. O que era aceitável no Q3 pode não ser no Q4. Reavalie os cortes a cada trimestre, senão o dashboard vira móvel de decoração.
