Por que pensar nos dados desde o design do produto pode definir o que uma organização será capaz de aprender no futuro.

Em uma empresa onde trabalhei, tínhamos um processo de solicitações que passava por diferentes estados.

Toda vez que uma solicitação avançava, o sistema atualizava seu estado. Se estava em iniciada e passava para validação, simplesmente substituíamos um valor pelo outro.

Operacionalmente, funcionava. O sistema sempre sabia qual era o estado atual de cada solicitação, e isso era suficiente para dar continuidade ao processo.

Até que surgiu uma pergunta de negócio bastante simples.

Queríamos entender quanto tempo os clientes levavam para passar de um estado para o seguinte. Queríamos identificar em quais momentos ficavam parados para avaliar se poderíamos intervir, enviar um lembrete ou gerar algum tipo de estímulo que os ajudasse a concluir o fluxo.

E não conseguimos responder.

Sabíamos onde cada solicitação estava, mas não como havia chegado até ali. O estado anterior tinha sido sobrescrito. Não tínhamos os timestamps de cada transição nem o histórico necessário para reconstruir a jornada.

Naquele momento, o problema já não era de analytics.

O dado simplesmente não existia.

Salvar o estado atual nos permite operar. Salvar o histórico nos permite aprender.

Um sistema pode funcionar perfeitamente e ainda assim perder informações valiosas

Quando projetamos software, naturalmente pensamos primeiro no que o sistema precisa fazer.

Quais informações precisamos para executar esse processo? Em que estado está uma solicitação? Qual é o saldo de uma conta? Qual produto o cliente escolheu? Qual foi o resultado de uma operação?

São perguntas necessárias. O problema aparece quando projetamos exclusivamente para respondê-las.

Essa tensão entre operar no presente e preservar o histórico está bem documentada em padrões de arquitetura como Event Sourcing. Em um modelo tradicional, normalmente atualizamos o estado atual de uma entidade e perdemos seu histórico caso não adicionemos explicitamente mecanismos de auditoria. Event Sourcing, por outro lado, preserva a sequência de eventos que produziu aquele estado.

Não acredito que todos os sistemas devam implementar Event Sourcing. Ele introduz complexidade e trade-offs que nem sempre se justificam.

Mas acredito que todos os sistemas deveriam fazer uma pergunta antes de decidir quais informações preservar:

O que vamos querer entender amanhã sobre o que está acontecendo hoje?

Porque são dois problemas diferentes.

Um sistema pode estar perfeitamente projetado para executar uma operação e mal projetado para aprender com essa operação.

A temporalidade também faz parte do dado

Há algo ao qual tento prestar atenção especial quando penso em dados: o tempo.

Suponhamos que temos esta informação:

status = aprovado

Isso pode ser suficiente para executar o processo.

Mas, para analisá-lo, talvez precisemos saber muito mais: quando foi aprovado, quanto tempo permaneceu no estado anterior, o que aconteceu antes da aprovação, quantas vezes mudou de estado, qual regra estava vigente quando a decisão foi tomada ou se houve alguma intervenção manual.

Muitas das perguntas interessantes que fazemos sobre um negócio não são apenas perguntas sobre o que aconteceu.

São perguntas sobre quando aconteceu, em que ordem e em qual contexto.

Na gestão de dados, existe um conceito particularmente útil: procedência dos dados (data provenance). Ele se refere à preservação de informações sobre a origem dos dados e as transformações pelas quais passaram ao longo de seu ciclo de vida.

Em um produto digital, não precisamos necessariamente aplicar esse conceito com o mesmo rigor de um ambiente científico, mas a ideia por trás dele é poderosa:

Seu sistema não deveria registrar apenas o que aconteceu. Deveria permitir entender como aconteceu.

Porque, quando perdemos a sequência, podemos continuar tendo o resultado e, ainda assim, ter perdido uma parte fundamental da informação.

O dado mais caro pode ser aquele que você decidiu não salvar

Armazenar dados hoje é relativamente barato.

Isso não significa que os dados sejam gratuitos.

Existem custos associados a processamento, pipelines, qualidade, observabilidade, governança, segurança, privacidade e consultas. Quanto mais dados preservamos, mais precisamos administrar.

Por isso, também não acredito em salvar absolutamente tudo "por via das dúvidas". Precisamos tomar decisões.

O interessante é que essas decisões são assimétricas.

Se armazenamos um dado e, três anos depois, descobrimos que nunca o utilizamos, provavelmente assumimos um custo desnecessário. Mas, se decidimos não armazená-lo e três anos depois descobrimos que era essencial para responder a uma pergunta, talvez não exista nenhuma maneira de recuperá-lo.

Podemos decidir eliminar informações mais tarde. O que nem sempre podemos fazer é voltar no tempo e capturar algo que nunca registramos.

O dado mais caro pode ser aquele que você decidiu não salvar.

Não porque todos os dados terão valor no futuro.

Mas porque algumas oportunidades de capturá-los acontecem uma única vez.

O problema é que ainda não sabemos do que vamos precisar

Isso acontece o tempo todo em Data Science.

Alguém pode perguntar:

"Essa variável realmente será útil para o modelo?"

E, muitas vezes, a resposta correta é:

Não sabemos.

Podemos ter uma intuição. Com base na experiência, podemos acreditar que determinada variável esteja relacionada ao comportamento que queremos prever, mas precisamos testá-la.

Se o dado já existe, podemos analisá-lo, construir a variável, avaliar sua capacidade preditiva e decidir se vale a pena incorporá-la. Se conseguirmos reconstruí-lo retroativamente a partir de outra fonte, também temos uma alternativa.

O problema aparece quando o dado não existe e também não pode ser inferido.

Nesse caso, precisamos modificar o sistema para começar a capturá-lo e esperar até acumular histórico suficiente. Isso pode levar semanas, meses ou até mais, dependendo do fenômeno que queremos estudar.

Portanto, a ausência de um dado não gera apenas uma limitação analítica.

Ela pode gerar tempo de espera antes que sejamos capazes de tomar uma decisão.

E esse custo pode ser muito maior do que preservar uma variável ou um evento que, no fim, nunca utilizaremos.

Data deveria estar presente desde o início do desenvolvimento do produto

É por isso que tento fazer com que os times de desenvolvimento também pensem de maneira data-driven.

Tradicionalmente, podemos imaginar um fluxo como este:

Negócio define → Desenvolvimento constrói → O sistema gera dados → Data analisa

O problema é que, quando Data aparece apenas no final, muitas decisões já foram tomadas: quais eventos são registrados, quais timestamps existem, quais informações são sobrescritas, quais identificadores permitem relacionar sistemas, qual contexto preservamos em torno de uma decisão e qual histórico conseguimos reconstruir.

Depois podemos construir um pipeline extraordinário, um warehouse impecável e dashboards extremamente sofisticados.

Mas nada disso consegue inventar informações que o produto nunca gerou.

Por isso, prefiro pensar o processo de outra maneira:

Negócio + Desenvolvimento + Data projetam → O produto opera → O produto gera conhecimento

Isso não significa que Data precise aprovar cada funcionalidade ou que devamos adicionar burocracia ao desenvolvimento.

Significa introduzir algumas perguntas desde o início:

  • O que queremos medir?
  • O que poderemos querer entender mais adiante?
  • Quais decisões futuras essa funcionalidade poderá ajudar a tomar?
  • Qual histórico precisamos preservar para conseguir reconstruir o que aconteceu?

A infraestrutura de dados começa muito antes do data warehouse.

Ela começa no design do produto.

Projetar para aprender não significa salvar tudo

Existe um equilíbrio importante aqui.

Poderíamos levar esse argumento ao extremo e concluir que deveríamos salvar absolutamente tudo.

Não acredito que essa seja uma boa solução.

Além dos custos de processamento e governança, existem dados que não deveríamos manter indefinidamente por razões de privacidade, segurança ou regulamentação. E, quanto mais dados acumulamos, maior também se torna nossa responsabilidade sobre eles.

O objetivo não é maximizar a quantidade de dados que coletamos.

É melhorar nossa capacidade de tomar boas decisões sobre o que vale a pena capturar, por quanto tempo devemos manter e com qual nível de detalhe.

No início, provavelmente sempre haverá algum grau de intuição envolvido. Não conhecemos todas as perguntas que o negócio fará daqui a dois anos.

Mas podemos prestar atenção especial às informações que são difíceis ou impossíveis de reconstruir depois: mudanças de estado, eventos, timestamps, contexto de uma decisão, versões de regras ou modelos e relações entre entidades.

Depois podemos decidir o que preservar e por quanto tempo.

Capturar e reter não precisam necessariamente ser a mesma decisão.

A IA torna essa discussão ainda mais importante

Também estamos entrando em um momento particularmente interessante.

Temos ferramentas cada vez mais poderosas para processar grandes volumes de informação, encontrar padrões e trabalhar com dados menos estruturados. Ao mesmo tempo, coding agents e vibe coding estão reduzindo drasticamente o esforço necessário para construir determinadas funcionalidades.

Isso pode gerar uma consequência interessante.

Se precisamos dedicar menos energia a escrever mecanicamente cada linha de código, podemos dedicar mais energia a pensar no que estamos construindo, por que estamos construindo e o que queremos obter com isso.

Por isso, acredito que as specs vão se tornar cada vez mais importantes.

Uma especificação poderia simplesmente dizer:

Quando X acontecer, alterar o estado para Y.

Mas uma boa spec deveria nos levar um pouco além.

Qual evento queremos registrar? Quando aconteceu? O que provocou a transição? Quais informações precisamos preservar? Como vamos medir se a funcionalidade produziu o resultado esperado? O que vamos querer analisar sobre esse processo daqui a seis meses?

A IA pode nos ajudar a construir mais rápido.

Mas construir mais rápido também aumenta a importância de decidir qual conhecimento queremos que nossos sistemas produzam.

Projetar software também significa projetar evidências

No artigo anterior, argumentei que ser data-driven não significa ter uma resposta para tudo.

Significa construir um método que nos permita formular hipóteses, testá-las e descobrir rapidamente quando estamos errados.

Mas existe uma condição prévia para fazer isso:

precisamos de evidências.

Se queremos experimentar com um processo, precisamos conseguir medi-lo. Se queremos entender um comportamento, precisamos ter capturado seus sinais. Se queremos comparar uma decisão com outra, precisamos saber o que aconteceu em cada momento. Se queremos treinar um modelo, precisamos de histórico.

Por isso, cada vez mais penso no design de dados como algo que acontece antes, e não depois, do desenvolvimento de um produto.

Projetar software também significa projetar as evidências que teremos amanhã para entender se esse software realmente funcionou.

E isso muda o ponto em que uma estratégia de dados deveria começar.

Ela não começa quando conectamos o produto ao warehouse.

Ela começa quando decidimos o que o produto vai registrar.

O histórico que não salvamos

Voltemos ao exemplo do início.

Tínhamos as solicitações. Tínhamos o estado atual. Tínhamos um sistema funcionando.

O que não tínhamos era o histórico.

E, sem esse histórico, não conseguíamos responder a uma pergunta que ninguém havia previsto quando o sistema foi construído.

Podíamos modificá-lo para começar a registrar as transições daquele momento em diante. O que não podíamos fazer era reconstruir perfeitamente tudo o que já havia acontecido.

Essa experiência me deixou uma pergunta que hoje tento fazer muito antes no processo de desenvolvimento:

O que vamos querer aprender com isso depois de um ano em funcionamento?

Nem sempre vamos acertar.

Vamos salvar coisas que nunca utilizaremos e inevitavelmente esqueceremos outras que, mais tarde, gostaríamos de ter capturado.

O objetivo não é prever todas as perguntas futuras.

É reconhecer que nossa capacidade de aprender amanhã também é projetada hoje.

Podemos mudar uma arquitetura. Podemos refatorar código. Podemos substituir uma tecnologia.

Mas existe algo muito mais difícil de recuperar:

O histórico que decidimos não salvar.

Fontes e leituras

  • Microsoft Azure Architecture Center — Event Sourcing pattern. Referência sobre a preservação do histórico de alterações por meio de eventos e os trade-offs associados a esse padrão arquitetônico.
  • NIST Research Data Framework (RDaF). Framework sobre o ciclo de vida dos dados, metadata, procedência, preservação, uso e reutilização.
  • NIST — Data Provenance. Conceito de procedência dos dados e preservação de informações sobre sua origem e transformações.