Armadilhas Comuns do Analista de Negócios (E Como Sair Delas)

Tomei café com uma BA no mês passado. Quatorze meses no cargo. Perspicaz, rápida, bem-quista. Ela me disse que estava "afogada em solicitações": mais de sessenta tickets por trimestre, fins de semana invadindo as segundas, sem fim à vista.

Fiz uma pergunta: cite uma decisão que o seu trabalho mudou no último trimestre.

Ela não conseguiu. Nenhuma. Tinha entregado 47 painéis, respondido 312 mensagens no Slack, escrito queries que fariam um engenheiro sênior assentir. E não conseguia citar uma única decisão que tivesse sido diferente por causa de qualquer uma delas.

Essa lacuna é o artigo inteiro. Também é a diferença entre o BA que é promovido no segundo ano e o que ainda está rodando queries ad hoc no quarto ano.

Por que o segundo ano é a bifurcação

A maioria dos BAs sobrevive o primeiro ano no esforço bruto. Você aprende o schema, memoriza os painéis, descobre quem realmente é responsável pelo quê. O output parece progresso porque tudo é novo.

O segundo ano é diferente. O schema não é mais novo. O output parece igual ao do primeiro ano (as mesmas queries, os mesmos painéis, as mesmas threads no Slack), mas agora é esperado. O esforço para de se traduzir em visibilidade. Você ou acumula (seu trabalho começa a remover decisões do prato de outras pessoas) ou estagna (você se torna uma versão mais rápida do help desk).

A bifurcação acontece silenciosamente. A maioria das pessoas não percebe que tomou o caminho errado até a temporada de avaliações, quando o gestor diz algo como "você está fazendo um ótimo trabalho, mas preciso ver mais impacto estratégico." Isso é o gestor dizendo, da forma mais gentil possível, que não consegue identificar o que seu trabalho mudou.

Aqui estão as sete armadilhas que colocam você no caminho do platô. Cada uma tem um sintoma que você pode identificar na sua própria semana, um número que você pode medir e uma correção que você pode implementar na segunda-feira.

Armadilha 1: Virar o help desk

Sintoma. Suas mensagens diretas parecem uma fila. "Pergunta rápida, você pode puxar X?" "Desculpe incomodar, mas Y inclui Z?" Você responde porque responder é rápido e dizer não parece rude. Aí você se pergunta por que não consegue chegar ao projeto estratégico.

O número. Na minha experiência, um BA que vira o help desk gasta de 12 a 18 horas por semana em solicitações ad hoc. Isso é um quarto a um terço da sua semana, toda semana, evaporado em perguntas que têm basicamente as mesmas cinco respostas.

A correção. Pare de responder pings individuais. Crie um canal #analytics-help e redirecione cada mensagem direta para lá com uma linha: "Postando no #analytics-help para que outros possam ver a resposta." Dentro de duas semanas você verá as mesmas cinco perguntas se repetindo. Construa um documento de autoatendimento ou um painel no Looker que as responda, adicione o link e veja sua fila diminuir.

A parte difícil não é o canal. É dizer "isso deveria ser autoatendimento" para um VP sem soar como se estivesse recusando trabalho. A formulação que funciona: "Posso buscar isso desta vez. Para não bloquear suas próximas dez solicitações, vou adicioná-lo ao [painel da equipe] até sexta para que você possa consultá-lo por conta própria." Você atendeu a solicitação. E também moveu o trabalho de "sua fila para sempre" para "sua fila uma vez."

Armadilha 2: Pular a aprovação formal dos requisitos

Sintoma. Uma parte interessada descreve o que quer em uma ligação de 20 minutos. Você concorda, anota, vai construir. Duas semanas depois ela olha e diz "ah, mas eu também preciso dividido por região" ou "espera, isso é mensal. Eu precisava semanal." Você reconstrói. Ela está "quase lá." Você reconstrói novamente.

O número. Cada reconstrução custa de 4 a 12 horas. Três ciclos de reconstrução em um único painel equivalem a uma semana inteira do seu tempo, e a parte interessada ainda não tem certeza se confia nos números.

A correção. Antes de escrever uma única query, envie um documento de requisitos de uma página com três seções: Decisão (que ação este trabalho vai possibilitar, e quem a toma), Definição (o que conta como "lead", "usuário ativo", "churn", acordado por escrito) e Pronto (como isso se parece quando é entregue, com um esboço). Obtenha um "ok" por escrito nas três partes. Se a parte interessada não quiser ler uma página, esse é o sinal de que a solicitação não é séria o suficiente para construir.

O documento de aprovação formal não é burocracia. É um mecanismo que transforma "quero um painel" em "quero decidir X toda segunda-feira e preciso de Y para isso." Noventa por cento da expansão do escopo morre nessa tradução.

Armadilha 3: Construir painéis antes de definir a decisão

Sintoma. Você entrega um painel. Ele tem 14 gráficos, 6 filtros, tudo codificado por cor. A parte interessada diz "isso é incrível, obrigada." Três semanas depois, quando você verifica, foi aberto duas vezes. As duas vezes por você.

O número. Na maioria das ferramentas de BI, o painel mediano é visualizado menos de 5 vezes por mês após o primeiro mês. Se "o cliente adorou" não corresponde a "o cliente usa", o painel não tinha uma decisão real vinculada a ele.

A correção. Antes de abrir o Tableau ou o Looker, escreva uma frase no topo do seu rascunho: "Este painel existe para que [função] possa decidir [ação] a cada [cadência]." Se você não consegue preencher as três lacunas, não tem um painel. Tem uma solicitação vaga para fazer uma coisa.

Exemplos que passam no teste:

"Este painel existe para que o VP de Vendas possa decidir quais duas regiões recebem headcount neste trimestre toda segunda-feira de manhã."
"Este painel existe para que o líder de CS possa decidir quais 5 contas ligar esta semana toda terça-feira às 9h."

Exemplos que falham:

"Este painel existe para que a liderança tenha visibilidade do funil."
"Este é um painel de desempenho de marketing."

Se a decisão não está nomeada, o painel vira papel de parede.

Armadilha 4: Depender demais de exportações para Excel

Sintoma. Você puxa dados para o Excel porque a parte interessada quer "brincar com eles." Você constrói uma tabela dinâmica. Adiciona um vlookup. Envia o arquivo por e-mail. Duas semanas depois a parte interessada o compartilha em uma reunião e os números estão errados, mas de uma forma que ninguém consegue reproduzir porque estão aninhados em uma planilha que vive na pasta de Downloads de alguém.

O número. Excel como fonte da verdade custa mais em reputação do que em horas. Um número ruim em um deck do conselho e seu status de "parceiro de dados" leva seis meses para se reconstruir.

A correção. Excel está bem para uma exploração pontual. Não está bem como relatório recorrente. A regra que uso: se você enviou o mesmo arquivo Excel duas vezes, a terceira versão precisa viver na ferramenta de BI, com o SQL salvo em algum lugar que um colega possa encontrar.

As ferramentas de produtividade da Rework e a maioria das plataformas de BI podem substituir 80% das exportações recorrentes para Excel por um relatório agendado. Os 20% restantes são análises ad hoc genuínas, e é aí que o Excel cumpre seu papel. Não lute contra o Excel. Lute contra o Excel-como-pipeline.

Armadilha 5: Sem controle de versão em SQL/modelos dbt

Sintoma. Você abre sua pasta de queries e encontra customer_metrics.sql, customer_metrics_v2.sql, customer_metrics_FINAL.sql, customer_metrics_FINAL_USE_THIS.sql e um assustador customer_metrics_old_NAO_USAR.sql. Nenhum deles produz os mesmos números. Você não se lembra qual rodou no deck do conselho do último trimestre.

O número. O tempo gasto reconciliando "por que meu número não corresponde ao seu" facilmente chega a 3-5 horas por mês. Mais se você é o analista que precisa defender o número em uma reunião de liderança.

A correção. Coloque seu SQL no git. Não importa se é um repositório privado, um projeto dbt compartilhado ou uma pasta sincronizada com um drive na nuvem. Versione, faça commit e pare de usar nomes de arquivo como controle de versão. Se você já usa dbt, isso é gratuito; você só precisa parar de contorná-lo com queries pontuais na ferramenta de BI.

Uma configuração mínima viável para um BA solo:

ba-queries/
  models/
    revenue/
      monthly_revenue.sql
      arr_by_segment.sql
    customers/
      active_customer_definition.sql
  README.md   # o que cada modelo significa, quem é responsável por cada definição

Faça commit de cada alteração. Referencie o hash do commit quando alguém perguntar "de onde veio esse número." Esse hábito por si só o transforma de "o analista" em "o analista que pode defender seus números em uma reunião de liderança." Esses são dois trabalhos diferentes e são remunerados de forma diferente.

Armadilha 6: Ignorar revisões de descontinuação

Sintoma. Você abre o Looker. Conta seus painéis. São 47. Você mantém ativamente 9. Consegue nomear 3 de memória. Os outros 44 ainda estão "ativos", ainda puxando dados toda manhã, ainda aparecendo no catálogo quando as partes interessadas pesquisam.

O número. Entre equipes com as quais trabalhei, 30 a 50% dos painéis não foram abertos em 90 dias. Ainda custam processamento, ainda confundem novos contratados, ainda criam momentos de "espera, qual é o certo?" em reuniões.

A correção. Execute uma revisão trimestral de descontinuação. Leva uma tarde. Puxe um relatório de uso da sua ferramenta de BI, ordene por last_viewed_at e para tudo com mais de 90 dias faça uma das três coisas:

Arquivar se ninguém é responsável.
Promover se for a versão canônica de uma métrica recorrente (mova para uma pasta "core", bloqueie as definições).
Mesclar se houver três quase-duplicatas que deveriam ser uma.

Na primeira vez que você fizer isso, vai arquivar mais de 20 painéis e nada de ruim vai acontecer. Esse é o ponto. O catálogo fica mais limpo, suas queries rodam mais rápido e novos contratados conseguem encontrar o painel certo sem precisar perguntar para você.

Armadilha 7: Medir uso sem impacto nas decisões

Sintoma. Seu gestor pergunta como a função de analytics está indo. Você diz "o painel executivo teve 1.200 visualizações no mês passado." Ela concorda e faz uma pergunta diferente.

O número. "1.200 visualizações" impressiona até você perguntar: visualizações de quem, levando a que ação, com qual resultado? Se a resposta é "não sei, mas o gráfico está subindo", você mediu a coisa errada.

A correção. Mude seus relatórios de métricas de uso para métricas de decisão. Para seus cinco principais painéis, nomeie:

A decisão que o painel apoia (mesma prática da Armadilha 3)
A cadência dessa decisão (semanal, mensal, trimestral)
Um exemplo, no último trimestre, em que o painel mudou a decisão tomada

Esse último é o divisor. Se você não consegue citar um único exemplo em que o painel mudou uma decisão, o painel é decoração. Se consegue citar três ou quatro nos seus cinco principais, você não é mais um gerador de relatórios. É um analista cujo trabalho moveu dinheiro.

Quando chegar a temporada de avaliações, "a equipe de liderança de marketing realocou R$2M de mídia paga para orgânico em março com base no painel de atribuição de canal que construí" é uma frase que leva à promoção. "1.200 visualizações" é uma frase que leva a um obrigado e ao mesmo título.

O padrão por baixo

Se você reler as sete armadilhas, todas compartilham uma raiz: otimizar para output em vez de decisões.

Help desk = output (tickets fechados)
Sem aprovação formal = output (construir rápido, construir errado)
Painéis antes de decisões = output (gráficos entregues)
Exportações para Excel = output (arquivos enviados)
Sem controle de versão = output (queries escritas, não compreendidas)
Sem descontinuação = output (catálogo cresce, nunca encolhe)
Uso sem impacto = output (visualizações medidas, não valor)

Reformule o trabalho. Você não é pago para escrever queries, entregar painéis ou fechar tickets. Você é pago para reduzir a latência de decisão do negócio. Transforme decisões que antes precisavam de uma reunião em decisões tomáveis a partir de um gráfico. Transforme decisões que antes levavam uma semana em decisões tomáveis em um dia.

Cada hora da sua semana deve se mapear a isso. Se não se mapeia, é overhead, e overhead não acumula.

Um plano de 30 dias para sair das armadilhas

Você não pode corrigir as sete de uma vez. Tente isto:

Semana 1: Estanque o sangramento. Configure seu canal #analytics-help. Mova cada mensagem direta para lá. Escreva um template de uma página para aprovação formal de requisitos. Comprometa-se a usá-lo nas próximas duas solicitações, sem exceções.

Semana 2: Reconquiste a confiança. Escolha seus três painéis mais visualizados. Para cada um, escreva a frase "este existe para que [função] decida [ação] a cada [cadência]." Se não conseguir preencher, agende uma conversa de 20 minutos com o responsável para descobrir. Atualize a descrição do painel com a frase.

Semana 3: Limpe a casa. Coloque seu SQL em um repositório git, mesmo que seja privado. Mova pelo menos as queries que alimentam seus três principais painéis. Execute uma revisão de descontinuação. Liste todos os painéis que você possui, marque cada um como Arquivar, Promover ou Mesclar.

Semana 4: Mostre o trabalho. Pegue o último trimestre e escreva três frases de "impacto na decisão." Reais. ("A equipe X realocou Y com base na análise Z que entreguei.") Se não conseguir escrever três, isso é diagnóstico. O plano do próximo trimestre é fazer três reais acontecerem.

A autoavaliação de sexta-feira. Toda sexta-feira, antes de fechar o computador, faça três perguntas a si mesmo:

Que decisão o meu trabalho mudou esta semana?
Que solicitação eu aceitei que deveria ter sido autoatendimento?
Qual é um painel que devo arquivar na próxima semana?

Três minutos, três perguntas. As perguntas não mudam. Suas respostas, ao longo de seis meses, vão mudar.

Conclusão

A BA no início deste artigo, a que não conseguia citar uma decisão que seu trabalho tinha mudado, não era ruim no trabalho. Era ótima nele. Ela era excepcional no trabalho de superfície (fechar o ticket, entregar o painel, responder o ping) e submersa no trabalho real (remover a latência de decisão do negócio).

As armadilhas neste artigo não são problemas de inteligência. São problemas de atenção. Você cai nelas não porque é preguiçoso, mas porque o trabalho de superfície parece produtivo no momento e o trabalho real parece invisível até a temporada de avaliações.

Escolha uma armadilha esta semana. Corrija-a antes de sexta. A promoção não vai vir de fazer mais. Vai vir de fazer as coisas que mudam decisões, e dizer não (gentilmente, por escrito) para todo o resto.

Playbooks para Analistas de Negócios