Por que equipes de dados tecnicamente excelentes ainda fracassam

• O valor de uma equipe de dados não vem do volume de pipelines, schemas ou dashboards produzidos, mas da mudança nas decisões da organização; entre dados e ação, é necessária uma camada de interpretação: a perspectiva (Perspective)
• Data-Perspective-Action é um modelo operacional que constrói dados confiáveis, interpreta-os conforme o contexto de negócios e sugere continuamente ações concretas
• No 2026 AI & Data Leadership Executive Benchmark Survey, 93% dos líderes de dados e IA apontaram cultura e gestão de mudanças como a principal barreira à adoção, enquanto apenas 7% citaram tecnologia
• É possível transformar perspectiva em hábito e conectá-la a decisões reais com documentos semanais de uma página, uma estrutura de métricas-chave, codesign com stakeholders e a regra de anexar recomendações de ação a toda análise
• À medida que a IA gera pipelines, análises iniciais e dashboards, conhecimento de domínio e confiança se tornam diferenciais; por isso, equipes de dados precisam ir além de entregar resultados corretos e construir uma realidade compartilhada

---

Por que Data-Perspective-Action é necessário

• O valor de uma organização é criado nas decisões, não nos artefatos de dados; entre a saída bruta e a ação real, é necessária uma camada interpretativa: a perspectiva
• Mesmo equipes tecnicamente competentes, com dados corretos, podem se tornar irrelevantes para a tomada de decisão da organização se otimizarem apenas a produção, como atender solicitações, fechar tickets e publicar dashboards
• Mesmo sistemas de dados bem projetados podem perder prioridade, orçamento ou desaparecer em uma reestruturação se não criarem o hábito de conectar trabalho e decisões
• Data-Perspective-Action é um framework que repete intencionalmente o processo que vai dos dados a uma interpretação opinativa e, então, a decisões concretas

O ponto de partida do framework

• O relatório mensal de uma agência de publicidade levava 4 semanas para ser produzido e já chegava defasado quando era entregue; ao automatizar o workflow em cerca de um dia, o tempo restante pôde ser usado em modelos preditivos
• Embora o modelo não fosse complexo, ele mostrava os resultados esperados ao mover orçamento entre canais, permitindo que clientes vissem com antecedência o retorno esperado e executassem mudanças de canal e experimentos
• Dessa experiência surgiu a sequência de dados, interpretação e decisão específica, e o mesmo modelo foi aplicado depois em várias organizações

Etapa 1: Data confiável

• A camada de Data inclui infraestrutura, confiabilidade, consistência, fluxo de informações, pipelines, schemas, modelos e dashboards; a maior parte do trabalho diário de engenheiros de dados e analytics engineers fica aqui
• Não é possível criar perspectiva com dados não confiáveis, mas, se o trabalho parar em receber solicitações → processar → fechar tickets, o ônus de interpretar dados corretos passa para stakeholders que não estão preparados
• Uma equipe construiu 200 dashboards com pipelines e schemas sofisticados, além de lógica de atualização validada, mas apenas 10 eram abertos antes de decisões reais
  • Os outros 190 foram criados sem que a equipe de dados e os stakeholders concordassem sobre para qual decisão serviam
  • Dashboards desnecessários foram descartados, mas a causa raiz era a ausência de uma definição compartilhada sobre o objetivo do trabalho
• Ao permanecer na camada de Data, o backlog e a carga de trabalho continuam existindo, mas a distância em relação às decisões reais aumenta, tornando mais fácil a equipe perder prioridade

Etapa 2: Perspective

• Perspective é a camada que transforma uma equipe que fornece informações em uma equipe que influencia a organização; o ponto central é o conhecimento de domínio para julgar se as métricas acompanhadas são adequadas a uma decisão específica
• No 2026 AI & Data Leadership Executive Benchmark Survey, 93% dos líderes seniores de dados e IA escolheram cultura e gestão de mudanças como o principal desafio de adoção, enquanto 7% escolheram tecnologia
  • Diferença entre cultura/gestão de mudanças e tecnologia: {b:93,7}
  • Essa foi a maior diferença em 15 pesquisas anuais, e cultura e gestão de mudanças apareceram repetidamente como barreiras ao longo de todo o período da pesquisa, mais do que tecnologia
  • Mesmo que organizações invistam em infraestrutura e talentos, os resultados ficam limitados se faltarem capacidade de interpretação e execução da mudança
• À medida que a IA passa a criar pipelines, análises iniciais e dashboards por prompt, o gargalo se desloca da construção para a confiança
  • Quanto maior o volume de outputs, mais importantes se tornam guardrails como qualidade dos dados, governança e uma definição clara da verdade
  • Mick Dreeling, da Netflix, considera provável que, em um ambiente em que stakeholders consultam agentes diretamente, a responsabilidade por garantir respostas corretas e elevar continuamente o padrão recaia sobre a equipe de engenharia de dados
  • Shridhar Iyer, da Meta, avalia que, mesmo que agentes absorvam conhecimento geral, a expertise de domínio é propriedade intelectual que não desaparece
• Profissionais que desenvolvem Perspective de forma sistemática passam a valer mais conforme as ferramentas de IA evoluem, enquanto trabalhos restritos à camada de Data se tornam mais fáceis de automatizar

• A armadilha da objetividade

  • Profissionais de dados podem sentir que oferecer interpretações invade a autoridade de outros e cair na passividade de não acrescentar contexto às análises
  • Stakeholders, com tempo limitado e várias prioridades, acabam interpretando por conta própria dashboards que só entenderam pela metade, ou recorrendo à intuição
  • Dados não falam por si; se a equipe de dados não os interpretar com cuidado, com base em contexto e expertise, outra pessoa fará isso em seu lugar

• O problema de não enxergar além da entrega

  • Mesmo que pipelines estejam fluindo, dashboards sejam abertos e testes passem, stakeholders podem baixar CSVs, abrir no Excel, adicionar colunas e fórmulas e recriar análises sempre que precisarem
  • Esses sistemas podem estar tecnicamente corretos, mas, na prática, estão sendo contornados
  • Ao perguntar a 5 stakeholders quais decisões estão tomando agora e onde há incerteza, é possível encontrar problemas solucionáveis em um ou dois dias
  • A confiança acumulada ao resolver proativamente pequenos problemas se torna a base para a equipe de dados participar de reuniões antes das decisões, não depois delas

• Treinar perspectiva com uma página semanal

  • Toda semana, escreva uma página em três partes
    • Resuma em um parágrafo os fatos que os dados mostram
    • Interprete em um parágrafo, com opinião, o que isso significa para o negócio agora
    • Sugira em 1 ou 2 bullets concretos o que fazer a seguir
  • Ao compartilhar isso com um gestor, colega ou pessoa de negócio e receber um feedback, repetindo o ciclo por 3 meses, a intuição sobre os dados que decisores consideram importantes muda
  • O trabalho mais importante começa pela sugestão de ação; mesmo que seja desconfortável, é preciso treinar a formação da própria opinião

• Métricas macro e micro

  • Métricas macro são um pequeno conjunto de números-chave que respondem se a empresa está saudável; métricas micro são números de entrada que explicam o movimento das métricas macro
  • Monisha Kanoth, da Apple, vê uma métrica North Star sólida, acordada por todo o negócio, como base da confiança
  • Para um líder de marketing que recebia dados de dezenas de fontes, o sistema de reporting foi reconstruído em torno de 3 métricas macro e 5 sinais micro
  • Em um trimestre, a empresa deixou de não saber em quais números confiar e passou a explicar com precisão, em conversas com o conselho, quais eram os motores de crescimento e quais não eram
  • Ao definir as métricas importantes e priorizar sua integridade, a qualidade das perguntas e das respostas da equipe de dados também melhorou

• Codesign com stakeholders

  • Lançar a versão 0.8 é uma forma de mostrar resultados antes de estarem completos e envolver stakeholders nos últimos 20% da construção
  • A cocriação gera senso de propriedade sobre o resultado, e esse senso de propriedade transforma entregáveis em compromissos reais de ação
  • Um stakeholder escreveu 100 perguntas realmente importantes, e a maioria das perguntas que surgiram nos anos seguintes estava dentro dessa lista
  • Essa lista foi usada tanto como roadmap de construção quanto como ferramenta de controle de escopo
  • Quando surgia uma nova solicitação, a questão não era se ela seria rejeitada, mas se era mais importante do que os itens já acordados

• Transformar narrativa, não link, em entregável

  • Ao compartilhar apenas uma consulta SQL, uma planilha ou um link de dashboard, o trabalho interpretativo mais difícil é transferido para o usuário
  • Ao escrever uma narrativa, mesmo curta, é preciso escolher o que importa e assumir responsabilidade por uma interpretação específica, criando um entregável que pode receber feedback, contestação e revisão
  • IA generativa pode ser usada para refinar frases, mas não deve assumir o pensamento em si
  • Escrever é um processo de pensamento, e a IA não pode desenvolver uma perspectiva única no seu lugar
  • Se você entregar sem envolvimento direto no raciocínio uma narrativa criada pela IA, estará pulando a camada de Perspective que se acumula com o tempo

Etapa 3: Action

• A distância entre uma recomendação e uma decisão organizacional real é grande, e equipes de dados tendem a subestimar o trabalho necessário nessa transição e a própria responsabilidade sobre ela
• O espaço entre a análise e a reunião de decisão deve ser preenchido com recomendações claras, dimensionamento da oportunidade e apoio contínuo
• Se a equipe de dados não participar dessa área, as interpretações, interesses e agendas dos stakeholders preencherão o vazio, e a equipe cederá o controle da parte mais importante do trabalho

• A regra de não apresentar apenas dados

  • Toda análise deve incluir uma ação recomendada; dados não devem ser apresentados sozinhos
  • A restrição de precisar recomendar algo no fim muda o escopo do trabalho desde o início
    • A investigação passa a se concentrar em uma pergunta específica
    • As métricas relacionadas à decisão passam a ser instrumentadas
    • Passa-se a considerar quais informações um líder precisa para agir
  • Em um caso em que um modelo quantificou uma oportunidade de crescimento, mas não levou a uma ação da liderança, o problema não era a precisão da análise, e sim a falta de recomendação e de contexto compartilhado
  • Ao pular diretamente de Data para Action, ficam de fora construção de relacionamento, cocriação e construção de confiança, e a recomendação pode permanecer sem execução

• Dimensionamento da oportunidade e apoio contínuo

  • Quando uma hipótese surge da análise, a equipe de dados deve quantificar diretamente quanto vale a oportunidade e por que ela deve ser priorizada
  • Mesmo que a estimativa possa estar errada, um número concreto oferece ao decisor algo para contestar, e uma estimativa discutível tem mais chance de levar a uma decisão do que uma direção vaga
  • Uma única apresentação não significa que algo entrará no roadmap; chegar à camada de Action pode levar meses
  • É preciso manter uma learning agenda para acompanhar recomendações executadas e não executadas, apresentar números atualizados para itens ainda importantes e continuar defendendo-os
  • Interromper o acompanhamento porque a primeira apresentação não foi aceita é abandonar o trabalho central de conectar a análise à decisão

A estrutura organizacional que sustenta o framework

• A unidade básica ideal é um duo com 1 analytics engineer e 1 analista alocados a uma área específica do negócio
  • O analytics engineer é responsável pela solidez do sistema
  • O analista fica responsável pela narrativa, pelo relacionamento com stakeholders e pelas recomendações de ação
• Um engenheiro sem um parceiro responsável pela narrativa tende a construir em busca de completude, não de decisões; um analista sem um parceiro de sistemas confiável tem dificuldade de criar evidências convincentes
• Organizações existentes não precisam se reorganizar imediatamente: podem alocar os dois papéis a uma área de negócio por um trimestre para validar o modelo e depois expandi-lo
• Se, como em empresas em estágio inicial, o trabalho de infraestrutura consome a maior parte da capacidade da equipe, é possível proteger tempo para compartilhar perspectiva em vez de formar um duo
  • Realizar uma revisão semanal do negócio
  • Abrir demos mensais para equipes que não são atendidas diretamente
• Mais importante do que o organograma em si é o hábito de repetir Perspective

Ritmo operacional acumulado no longo prazo

• Ao repetir semanalmente o trabalho de criar perspectiva e defender ações, o efeito se acumula ao longo de meses e anos
• Quanto mais a equipe participa do processo decisório, melhor consegue distinguir pipelines sem razão clara de existir, alertas que são quase ruído e investimentos em infraestrutura que serão realmente necessários no futuro
• O papel da equipe de dados é construir uma realidade compartilhada em que os membros da organização possam confiar em comum sobre a situação atual e seu significado
• Data-Perspective-Action é um modelo operacional que deixa continuamente claro que o propósito do trabalho técnico é tomar decisões melhores; pipelines e schemas também existem para essas decisões