Em um dos primeiros projetos em que eu trabalhei, houve a seguinte situação: A minha tarefa era desenvolver diversos webscrapers para realizar a aquisição de diversos dados públicos. Um desses datasets em particular era de dados meteorológicos e após eu baixá-los e analisá-los, percebi que os dados não pareciam fazer sentido. Então investiguei aquela fonte de dados e descobri que os dados passavam por uma espécie de compactação, sendo necessário aplicar uma fórmula matemática para que os dados verdadeiros pudessem ser revelados. Eu passei esta informação para o gestor do projeto e a sua resposta foi “nós não temos tempo para corrigir, coloca assim mesmo na base de dados e segue para o próximo”.

Este evento que eu presenciei demonstra bem como a qualidade de dados, por muitas vezes, é ignorada em prol de um deadline apertado ou mesmo por pura negligência. Aqueles dados, quando fossem acessados no banco de dados, provavelmente não fariam sentido para quem os lesse. Porém, no pior cenário, poderia até mesmo induzir à erros em decisões estratégicas.

Em outra ocasião, quando eu já era um profissional sênior, fui encarregado de criar alguns novos reports para o time de CS da empresa. Depois de muito trabalho, consegui gerar os reports e enviei para a equipe responsável que logo me retornou que os dados estavam errados. Eu revisei exaustivamente os dados e encontrei algumas poucas falhas, mas nada que fizesse muita diferença, então fui até o time de CS e perguntei como eles sabiam que os dados estavam errados. Foi então que eles me disseram que havia um dashboard antigo de onde eles extraíam as informações que eram passadas para os clientes. Investigando o dashboard, eu descobri que os dados contidos lá estavam errados. Ao informar esta situação para a equipe de CS, recebi a seguinte resposta, “e como você quer que agora a gente diga que os dados que estavam sendo passados para os clientes estão errados?”.

Uma falha na qualidade de dados pode se tornar uma dívida que acumula juros conforme o tempo passa. Se esta dívida chega à área de negócios, o problema deixa de ser somente técnico e passa também a ser o convencimento da área de negócios para que sejam usados os dados corretos. A ideia é que a qualidade de dados seja pensada desde o início do projeto e que as falhas sejam corrigidas antes que criem raízes no negócio da empresa.

Em outro caso, eu estava em um projeto onde recebíamos dados de um parceiro e precisávamos aplicar algumas rotinas de data science para gerar insights sobre os dados. Os dados demoraram um pouco para serem enviados, porém, assim que eles chegaram, alguns dos cientistas de dados começaram a aplicar fórmulas e gerar gráficos com base nos dados. Contudo, como os dados vieram em planilhas excel, eu decidi olhar os dados com mais atenção, explorando o range dos valores contidos, campos nulos, padronizações etc. Foi então que eu percebi que os dados estavam completamente “sujos”. Eu lembro, particularmente, que a coluna de sexo do cliente às vezes era preenchida como M/F, depois mudava para H/M e, em outras vezes, mudava para 1/2. Ninguém havia se atentado em verificar a qualidade dos dados!

Percebendo o problema eu alertei que os dados que estavam sendo gerados poderiam estar errados e com isso foi decidido que primeiramente seria feita a normalização dos dados e então os cálculos seriam refeitos. No final, viu-se que os resultados não tiveram uma grande alteração porque o volume de dados fora do padrão não era tão grande e muitos dos cálculos consideravam a média dos valores. Após tudo isso, ainda recebi um feedback negativo por ter “atrasado” o processo.

Estes cases que eu vivi me fizeram perceber como a qualidade de dados é algo pouco valorizado nas empresas. É semelhante com a área de cybersecurity, onde se diz que “se você investir em cybersecurity e nada acontecer, você é paranóico e gastou dinheiro à toa, mas se você não investir e algo acontecer, você foi negligente”. Da mesma forma, se você insiste em que sejam tomadas medidas para garantir a qualidade dos dados, você pode ser visto como o “chato” do time. Porém, se você não faz nada, talvez isso se torne um grande problema no futuro e você seja responsabilizado ou tenha que lidar com os erros cometidos por outras pessoas.

Existem muitos exemplos de projetos que foram implodidos por problemas com a qualidade de dados. Um dos exemplos que eu mais gosto de citar é a crise financeira de 2008 que, de certa forma, foi um problema de qualidade de dados, pois os ativos financeiros baseados em hipotecas estavam sendo classificados de forma errada e isso gerou um efeito dominó. Por isso, é importante encarar esta batalha pela qualidade dos dados sabendo que provavelmente será uma batalha ingrata, porém, as consequências de negligenciar este problema podem ser catastróficas.