Nos primórdios do Business Intelligence, levávamos pelo menos aí um ano dentro da construção de um Data Warehouse para fazer, de fato, uma entrega de valor. Ao longo desse tempo, muitos projetos naufragavam. Período longo demais para manter o patrocínio da alta gestão. Boas notícias! Nós viramos esse jogo. Com uma stack moderna de dados, trazendo agilidade na gestão dos projetos, usando ferramentas low-code, indo para cloud, trabalhando muito mais DataOps, hoje, em pouquíssimo tempo, nós conseguimos entregar na mão dos analistas, dos times de gestão, informações consistentes para a tomada de decisão. Eu sou a Tassiana, sou gestora de dados e analytics na triggo.ai, que é uma startup de Inteligência Artificial, professora e coordenadora de MBA aqui na FIAP. E eu estou aqui com o nosso querido Lucas Brandi, sumidade quando o assunto é dado. Ele vai contar um pouquinho da carreira dele para nós, contar como os dados fazem parte hoje do seu cotidiano né, Lucas? E nós vamos bater um papo aqui bem gostoso sobre boas práticas, justamente nesse contexto das informações. Exatamente. Bom, meu nome é Lucas Brandi, eu sou engenheiro de dados. Trabalho para uma empresa chamada X-Team como consultor para projetos internacionais, principalmente no âmbito de Data Warehouse e Data Lake. Ambos os projetos são voltados para organizarmos os dados de uma forma eficiente para o uso posterior, para ciência de dados, para análises, desenvolvimento de métricas e assim por diante. Em poucas palavras, trazer valor para o negócio. Muito bacana. Gente, o Lucas é um engenheiro incrível. Vai dar dicas importantíssimas para vocês. E para partirmos do início, Lucas, sempre tem ali uma necessidade de tomada de decisão, uma necessidade de análise. Toda organização tem. Mas daí até chegar a implementação de um projeto, uma esteira de construção de engenharia, uma entrega de valor lá na ponta, com dashboards, com estatísticas, e às vezes até evoluir para um Machine Learning, enfim, como funciona esse trilho, como nascem esses projetos, e como vamos fazendo toda essa construção? Eu acho que nós temos diversas situações. Em alguns casos, quando começamos um projeto de dados, pode ser que seja numa empresa que também está começando. Então avançamos com a maturidade de dados, assim como a empresa está avançando também com o desenvolvimento do produto. Em outros cenários, já temos um produto desenvolvido, uma empresa estabelecida, mas que ainda não estava utilizando das boas práticas do mercado para uso de dados, para se tornar uma empresa data-driven, enfim. Nesses cenários, nós precisamos estar muito mais próximos das áreas de negócio, de quem conhece, domina de fato o produto, para conseguir extrair esses insumos do negócio, para conseguir pensar, planejar como vamos implementar esse projeto de Data Warehouse, numa boa plataforma de dados para agregar valor rápido, como você mesma disse, para o negócio, utilizando diversas outras ferramentas. E dependendo do tipo de produto que estamos trabalhando, as origens dos nossos dados, temos que pensar também, quais ferramentas vamos utilizar ali. Então, esse passo inicial, entendermos se o produto já existe, se a empresa já trabalha com algum tipo de métrica, quais são essas métricas, como elas são calculadas, é a base de tudo, né, é onde começamos. E caso seja uma empresa nova, que já está nascendo na nuvem mesmo, que já temos essa ideia de trabalhar com analytics desde o início, às vezes é um pouquinho mais fácil, porque aí conseguimos trabalhar em conjunto com o desenvolvimento do produto, já trazendo essas métricas e acompanhando as métricas enquanto o produto está sendo desenvolvido. Então é um crescimento meio que paralelo das duas frentes, não só o negócio, como também a plataforma que estamos desenvolvendo. Perfeito. Quando falamos do mercado, o cenário é complexo, né, então você tem ali uma estratégia de negócio a ser pensada, depois tem um olhar arquitetural também. As arquiteturas são híbridas, às vezes uma colcha de retalhos. É sempre muito, né... O Lucas está bastante adaptado a essa realidade. É sempre muito consultivo, né? Não existe uma receita de bolo. Trabalhamos os conceitos com os alunos, mas no mercado, essa adaptabilidade e flexibilidade são superimportantes, essa leitura ali do contexto e da necessidade do cliente. Por falar em necessidade do cliente, Lucas, falamos muito de visão 360. Isso é um termo meio negócio, né? Eu quero uma visão 360 ali do meu cliente. Você acha que um projeto nessa linha que nós estamos comentando, de um Data Warehouse, de uma base analítica, contribui para chegarmos nessa visão? Com certeza. Pensando numa estratégia para entendermos como a empresa está funcionando, essa visão 360 acaba sendo... O que nós temos ao nosso redor? Conseguíamos enxergar desde as origens dos nossos dados como estamos definindo o nosso produto, como esse produto está sendo consumido, como diferentes áreas estão trabalhando com o desenvolvimento desse produto, e, consequentemente, falando de dados, como todos esses insumos estão sendo utilizados internamente. Então, a base dessa visão 360 é construir uma plataforma onde consigamos servir os nossos usuários internos com dados para que eles possam responder as próprias perguntas e entender, ter essa visão ampla, de tudo o que está acontecendo na empresa. Em alguns casos, essa visão ampla, dentro de grandes empresas e grandes projetos, acaba sendo muito difícil centralizarmos num único grupo de pessoas. Então descentralizamos até um pouco mais essa estrutura para conseguirmos controlar escopos de negócio. Ao invés de termos silos muito fechados, termos essas estruturas individuais funcionando em paralelo dentro de uma empresa, que é muito o conceito de data mesh, né, onde conseguimos que pequenas áreas, ou pequenos grupos de pessoas, consigam ali controlar toda essa visão 360 de um escopo de trabalho específico, por exemplo, só de finanças, só de marketing, de aquisição de novos usuários, e assim por diante. Aí, tudo isso funcionando em paralelo, quando precisarmos ter essa visão da empresa como um todo, vamos extraindo os dados de cada ponta para conseguir entender o funcionamento da plataforma como um todo. Sensacional. A ideia da malha de dados, que é algo super-recente e moderno, apoia muito essa completude de informações. Sensacional! E eu comecei, Lucas, falando um pouco do patrocinador, do sponsor, né, que o PMBOK fala muito também. Porque sabemos que na gestão de um projeto, e você já viveu vários contextos assim, um patrocínio é superimportante, né? Quando falamos de um projeto de estruturação dos dados, assim como um projeto de governança, às vezes demoramos um pouquinho para entregar valor. É muito mais fácil entregar valor num dashboard, né? Concorda comigo? É palpável, né? Todo mundo acessa aquele relatório, ele responde às perguntas. Mas e essa esteira de engenharia que vem antes, esse tempo do tratamento dos dados? Isso toma um pouquinho de tempo, mesmo que sejamos ágeis, e vai gerando uma certa ansiedade na organização. Então, mesmo com a agilidade, ainda é um projeto que precisa de patrocínio, né, patrocínio forte ali. Sem dúvida. Falando de dados, quem é o patrocinador? Quais são as áreas? Quem costuma ser esse sponsor? Esse projeto costuma partir de quem? Como isso tem funcionado? Existe um padrão ou varia de uma empresa para outra? É interessante pensarmos em quem é o sponsor, né, principalmente em algumas empresas pequenas. Um dos projetos que eu atuo agora é de uma empresa um pouco menor, onde o sponsor do projeto acaba sendo, de fato, o CEO, o dono da empresa, quem está precisando, de fato, de insumos para a tomada de decisão. Então acaba sendo algo um pouco mais direcionado. Mas quando pensamos em empresas maiores, um patrocinador do projeto normalmente seria aquela empresa, aquele grupo de... Aquela área ou aquele grupo de pessoas, que precisam tomar uma decisão, responder algum tipo de pergunta, e não necessariamente tem todos esses assuntos prontos, seja origem de dados onde não temos mapeado dentro da nossa plataforma, seja processos de transformação que não foram implementados para calcular determinadas métricas, indicadores, ou até mesmo desenvolvimento de dashboards. Então, todo esse processo, essa esteira inteira, desde a extração dos dados, a manipulação desses dados, o desenvolvimento das métricas, e, por fim, o consumo para tomada de decisão, tudo isso parte da necessidade de alguém, ou de algum grupo de pessoas, ou de alguma área. Então, normalmente essa área que vai patrocinar, que vai investir ali, não só o recurso financeiro, mas também tempo, né, para fazermos toda a organização do projeto, para disponibilização... E implementação desse projeto completo de dados. Normalmente vemos esse tipo de cenário. E faz sentido dizer que, na maioria das vezes, é uma dor de negócio. E quando não se conecta o negócio que está sendo desenvolvido, temos até dificuldade de vender internamente. Então eu observo muitos projetos de novo naufragando, porque tem toda um aparato tecnológico, mas os times de negócio ainda não conseguiram enxergar valor, não utilizam. E se não se conecta com valor para a organização, aquilo perde, perde em si. Então esse processo de empurrar a tecnologia é muito mais desafiador, né, diferente de quando o negócio está puxando ali e consegue entregar muito valor. Como é essa sinergia? Eu me lembro, nesse mercado, de ter um preciosismo técnico muito grande. Quando você ia contratar, tinha que ser aquele profissional que dominava o código, aquela tela ali do "shell", aquela tela preta e tudo mais. E eu tenho percebido o mercado mudando, né? Mesmo hoje, quando eu estou contratando um dev. um profissional que vai atuar mais tecnicamente, ele precisa ter esse feeling de negócio, essa conexão com o propósito que ele está fazendo. Você enxerga assim também, esse alinhamento, negócio técnico... Porque até parece que, na malha de dados, conseguimos fazer melhor. Com certeza. Esse alinhamento é muito interessante, principalmente quando pensamos na stack moderna de dados, que é um conceito, um framework que surgiu recentemente, tentando trazer algumas boas práticas, algumas situações que visam justamente permitir que profissionais não tão técnicos, não necessariamente só engenheiros de dados, possam trabalhar com desenvolvimento, contribuir com uma plataforma de dados. Então utilizamos ferramentas como low-code ou no-code, por exemplo, ferramentas visuais para conseguirmos fazer a integração de dados, ferramentas visuais para conseguirmos também criar projetos de transformação de dados, quando cabe... Ferramentas de visualização. Quase todas são drag-and-drop, onde vamos construindo ali a nossa visualização sem precisar necessariamente de código. Então, esse tipo de recurso permite com que outros profissionais, normalmente de negócios, também consigam participar mais dentro de uma plataforma, Então nós estamos mudando um pouco aquele paradigma de que dados, uma área de dados, seria uma área de TI. Não necessariamente. Eu penso em dados como uma área híbrida, uma área onde temos uma sinergia muito grande com negócios, onde precisamos entender o que está sendo realizado do lado de negócios, do lado do nosso produto, e assim por diante, e também que possa navegar no ferramental que temos disponível dentro de uma plataforma de dados. Então, esse cenário onde conseguimos utilizar ferramentas para resolver problemas de negócio, essa ponte acaba sendo o cenário ideal onde conseguimos escalar projetos de dados, de Data Warehouse, de BI, visualização, e assim por diante. A ferramenta é sempre um meio, né, TI é um meio. Nunca um fim em si, né? Até por isso vemos projetos muitas vezes começando com estabelecimento de domínio. Domínio é um assunto de negócio, né? Qual é o meu domínio financeiro, o meu domínio de pessoas. Hoje temos falado muito em governança, na identificação do owner, quem é o dono do dado. E geralmente esse dono do dado é alguém de negócio, que entende bem da transação, mas também do analítico, porque até então tínhamos uma barreira muito grande. Parece que o mundo transacional... Do transacional para o analítico, trocávamos de assunto. E não é. É uma nova forma de organizar o dado, mas é o mesmo dado, é o mesmo assunto, é o mesmo domínio de negócio, e dores muito parecidas, né? Então, no mesh, nós temos conseguido uma malha de dados, temos conseguido essas evoluções que trazem mais o negócio para o jogo. Eu tenho observado isso, ferramentas mais colaborativas também, que o time de negócio consegue entender o que está acontecendo e colaborar. E aí são projetos que você gasta mais tempo discutindo o negócio do que aplicando ali a complexidade técnica. Que, no final das contas, é o que importa, né? Que é o que importa. Exatamente. Estão, assim, são tendências importantes. Não importa se você é de negócio ou se é uma pessoa mais técnica, isso precisa estar no nosso radar. Mas eu acho importante ressaltar também que não necessariamente o que estamos mencionando de ferramentas low-code, ou visuais, né, e assim por diante, que não temos código, que não estamos falando de Python, Scala, Java, enfim, essa parte mais técnica mesmo da área de dados. Nós temos isso também. Só que, em alguns cenários, nós não precisamos de muita complexidade para resolver problemas. Não precisamos utilizar as ferramentas que estão super em alta no mercado só porque estão em alta no mercado. Não necessariamente. Podemos utilizar outras alternativas que já vão resolver os nossos problemas de determinada área da empresa, ou às vezes até mesmo da empresa inteira, com uma simplicidade maior, facilidade maior, sem a necessidade de um grande time de dados, garantindo que outras pessoas estejam contribuindo ali também, colaborando com o projeto. Então é aquela questão, né, precisamos identificar o cenário, os requisitos que nós temos, onde queremos chegar, para conseguir ter essa escolha também do ferramental. Mas... Frisando essa escolha de ferramentas, não descartamos ferramentas mais complexas, mais técnicas de fato, com código, para resolução de problemas mais complexos também. Então elas caminham em paralelo. Para cada situação, vamos ter ali um ferramental mais específico resolvendo um problema de uma forma diferente. Bom ponto, bom ponto. Porque nós estamos falando de um mundo de BI, de um Data Warehouse, de KPIs para tomada de decisão, mas, de repente, eu preciso de uma latência mais baixinha, o dado não entrar tão estruturado. A minha dor de negócio está relacionada a uma fonte que é um log, que é algo que exige, de repente, um monitoramento, e aí eu vou para o mundo de Big Data. Talvez eu não esteja falando só do DW, talvez seja um data lake, que é um outro repositório analítico, um Data Lakehouse, que é alguma coisa um pouco mais moderna. De repente eu quero fazer uma implementação mais open source por uma necessidade específica ali do meu contexto. As ferramentas open source, muitas delas de Big Datas mais robustas, vêm com uma necessidade de código maior, né? Então tem casos em que a implementação vai ser um pouco mais complexa. Geralmente projetos mais robustos, um maior volume de dados, uma complexidade técnica maior, uma latência menor. Ainda cabe essa questão, né, cabe bastante ainda a questão do desenvolvimento. Eu acho que o importante é não ter preconceito. Eu brinco muito com os alunos: você vai de raiz ou vai de Nutella? O raiz é o código lá e tudo mais, e o Nutella é o low-code, o drag-and-drop, a questão visual, né? E existe preconceito. Eu já ouvi de gestores em reuniões mesmo, que eu estou ali, apresentando uma proposta, e eu percebo que eu falei alguma coisa de low-code e ele torceu o nariz... "Aqui todo mundo coda. Temos codar. Hand coding...". Mas aí é um preconceito, né, porque, de repente, como você falou, em alguns casos você traz alguma coisa mais low-code, resolve, você entrega o projeto muito mais rápido. Uma questão de custo. Então, quem está gerindo o projeto precisa ter esse olhar mais agnóstico de pensar qual é a melhor ferramenta, a melhor estratégia, para aquele cenário específico. É isso, né? Muito desse preconceito vem do uso indevido de algumas ferramentas justamente nesse cenário... "Ah, esse projeto aqui precisava de uma complexidade um pouco maior", porque a demanda de negócio chegava.... A necessidade de negócio precisava de uma latência mais baixa, ?, dependendo ou até mesmo a quantidade de pessoas trabalhando juntas no mesmo pipeline. Com algumas ferramentas visuais, temos algumas limitações desse tipo. Às vezes não tem versionamento de código. Tem alguns problemas nessas ferramentas. Elas não são perfeitas. Elas são mais fáceis para começarmos a trabalhar, mas não necessariamente resolvem todos os problemas. Só que aí tentamos utilizar essas ferramentas conforme o projeto vai ganhando algum tipo de complexidade, que outras soluções fariam mais sentido. Daí que acaba entrando um pouco desse preconceito, porque vemos muito esse tipo de infraestrutura com um projeto legado utilizando dessas ferramentas, e que já enxergamos hoje que não são mais escaláveis. Então quer dizer que eu não vou mais utilizar esse tipo de ferramenta? Não, tem casos e casos. Só precisamos escolher corretamente e entender a hora de mudar, caso seja necessário. Na hora de escalar, exato. E o contrário também é válido, né? Vemos aí a onda do Kafka, que é uma superferramenta de mensageria. Quem gosta da coisa técnica, adora. Ela é parruda, está na arquitetura de grandes players, né, LinkedIn, Uber e por aí vai. Então o entusiasta técnico que pôr Kafka em tudo, né? Isso vale no contexto corporativo, nas aulas também... "Vamos desenhar uma arquitetura?". Eu trago uma dor de negócio, eu especifico ali o volume, o aluno vem com Kafka na arquitetura. Mas às vezes é uma dor que o Excel resolveria, né? E nada contra o Excel. Se resolve, está ótimo. Então eu acho que são os dois lados. Existe o time do hand-code e o time do low-code. Na verdade, a visão arquitetural, a visão estratégica, madura, é superimportante, Com certeza. O nosso aluno precisa ir ganhando essa maturidade para a tomada de decisão. Muito bacana! E falando, Lucas... Bom esse papo, né, profundo. Falando aí para o nosso aluno mesmo, que está vivenciando esse mundo dos dados, alguns já estão ali atuando, você enxerga papéis claros na construção de uma solução analítica? O que eu posso ser, pensando no que eu posso estudar e tudo mais? Você, como engenheiro, interage ali com outros profissionais. Quais são esses papéis? Nós temos aquela divisão básica de uma plataforma de dados. Temos um time de engenharia de dados, time de ciência de dados e de análise de dados. Essa é a divisão tradicional, mas temos muito mais carreiras dentro de dados, principalmente quando escalamos, quando pensamos em grandes empresas, grandes projetos. Temos que levar muito em consideração segurança de dados, temos que levar em consideração governança. Dependendo, um engenheiro de dados, pode estar muito mais próximo, por exemplo, do Kafka, de ferramentas mais técnicas, mais tela preta, e outros engenheiros de dados estão mais próximos de transformação, especificamente, têm mais facilidade de lidar com o negócio, de extrair aqueles insumos de negócio para conseguir implementar um pipeline de transformação. E não conseguimos classificar tudo numa mesma caixinha. O engenheiro de dados, ou a engenheira de dados... Vai conseguir fazer tudo, né, realizar todos essas atividades, dominar todas essas possíveis ferramentas. Então está cada vez mais ficando segregado algumas responsabilidades. Hoje, a engenharia de dados está muito mais próxima de plataforma, onde pensamos em integração de dados, onde pensamos em manutenção de ferramentas, como sistemas de mensageria, de orquestração de dados, Data Warehouse, data lakes, toda essa parte mais de infraestrutura. E enquanto no processo de transformação nós estamos usando lyrics engineers que é uma carreira razoavelmente nova e é especializada em implementar processos de transformação de dados utilizando insumos de negócio que foram coletados e navegando na plataforma que foi desenvolvida pelo time de engenheiros de dados. Ele é meio híbrido ali, né? De todas as profissões, essa é que acaba sendo mais híbrida mesmo, que demanda bastante de conhecimento de negócio e também conhecimento das ferramentas utilizadas para implementar as soluções necessárias para o negócio. E na outra ponta, uma vez que já temos esses processos de transformação implementados e tudo mais, nós temos times de análise, times de ciência de dados, times de governança, qualidade. Podemos até mesmo ter outros times de negócio, como marketing, por exemplo, trabalhando diretamente com dados Dados acaba sendo quase que o coração dentro de marketing também. É o principal insumo para conseguirmos investir melhor os nossos recursos em campanhas, aquisição de usuários, fazer testes A/B, tudo baseado em dados. Então são várias possibilidades que nós temos dentro de uma plataforma. Em desenvolvimento de projetos de dados, as diversas possíveis carreiras, ou em empresas menores, acabamos tendo aquele profissional de dados... - Que acaba fazendo um pouco de tudo também. - Também, é verdade. Ele põe a mão de ponta a ponta. E tudo bem, é a realidade da empresa, e para o profissional até é bacana, porque às vezes ele aprende mais colocando a mão ali. E aí que as ferramentas mais simples, mais visuais, acabam auxiliando também, porque mesmo que, por exemplo, a minha especialidade não é visualização, mas se eu tenho uma ferramenta que me ajuda de forma gráfica a construir um dashboard de forma mais eficiente, ótimo, porque eu não preciso aprender uma outra tecnologia do zero e tudo mais. Eu já consigo utilizar aquilo para fazer o quê? Responder perguntas de negócios, que, no final das contas, é o que importa. É o que importa. Você tocou num ponto interessante, como outras áreas têm vindo para dados e se empoderado. Temos trabalhado muito nesse processo de data literacy, alfabetização em dados, e vale muito alfabetizar a empresa como um todo, né, todos precisam falar dados. Então agora é algo que tem crescido e que talvez até nos ajude muito mais a alavancar a questão da cultura. Como nós podemos, Lucas, fazer essa combinação? O que vem primeiro? A cultura, a cultura de dados, a cultura data-driven, ou colocar lá um Data Warehouse? Eu percebo que, dependendo do cliente, nós começamos o papo pela ponta que está mais fácil, não é? Eles querem ter a ferramenta, e, ok, vamos por ali. Outros já perceberam que, apesar de ter a ferramenta, eles não conseguem garantir um bom uso. As pessoas ainda seguem muito no feeling, e aí voltam um pouquinho atrás e começam a falar de cultura, mindset. Você percebe o mercado assim? O que deveria... Vamos falar do correto. O mercado é muito híbrido. Mas o que deveria vir primeiro? A cultura ou a implementação ali da solução? Então, quando temos um tempo limitado para conseguirmos implementar um processo de dados uma plataforma de dados, normalmente não conseguimos preparar todas as pessoas antes de começarmos um projeto desse tipo. Aí que entram muitos consultores para conseguir implementar a parte técnica utilizando do que a empresa já entende ali que vai agregar valor para ela a partir daquele ferramental. Mas eu não colocaria a implementação técnica na frente dessa questão cultural. Eu acho que tem que caminhar em paralelo. Enquanto estamos construindo essa plataforma, já temos que demonstrar o porquê essa plataforma é relevante, como ela é relevante, como que vamos utilizar, como vamos agregar valor, porque é mais fácil trabalhar com esse tipo de ferramenta, com essa plataforma. E tudo isso, em paralelo, acaba garantindo o sucesso do projeto. Não adianta gastarmos muito tempo fazendo uma grande preparação, cursos, treinamentos, e não estamos vendo a métrica ali. - Muita teoria, né... - Exato. E nada prático. E ao mesmo tempo que... "Nossa, nós já temos aqui toda essa plataforma construída. Agora nós vamos desligar aqui todo esse processo que vocês já estavam fazendo e vamos utilizar só essa". "Por quê? O outro funcionava", alguém pode perguntar. E, de fato, estava funcionando. Estava da melhor forma? Não necessariamente, mas estava funcionando. Então, explicar e passar essa sensação de que, beleza, estamos dando agora um passo que, de fato, vai ser relevante para nós, é fundamental. Porque quando temos um sponsor no projeto, pode ser que esse sponsor já tenha comprado a ideia, já entenda o valor, de fato, que vamos agregar com essa plataforma desde o início. Mas, beleza, temos uma pessoa, e todo o restante do time, todo o restante da empresa podemos ter mais dificuldade em comprovar isso para eles. Então não adianta simplesmente entregarmos esse projeto sem pensar na questão cultural que caminha junto ao projeto. Sim, e aspectos políticos que são tão desafiadores, né? Às vezes o gestor não quer que se fale de uma nova tecnologia, de uma nova metodologia, porque ele não quer soar retrógrado, não quer gerar uma impressão que a gestão dele está atrasada. E aí tem todo um cuidado, porque nós estamos falando de pessoas, e elas precisam ser respeitadas porque estão dando o seu melhor. É muito fácil você vir de fora com as suas novas ideias. Você não está ali no dia a dia, matando um leão por dia. Então, a cultura vem junto com a questão política também, de se mostrar... Quem quiser fomentar essa cultura, esse mindset, precisa se mostrar como alguém que quer somar, alavancar, enfim, e não alguém que veio para dizer que está tudo errado, que você está fazendo tudo errado, vamos fazer agora dessa outra forma que é superdiferente e funciona. Até porque nada funciona saindo dos livros e sendo encaixado na realidade corporativa ali. Precisamos adaptar tudo. Então são aspectos mais complexos que as questões técnicas, não é, Lucas? Parece que até resolvemos mais rápido o técnico. Quando falamos de cultura, de questões políticas, elas são mais desafiadoras, mas precisam ser consideradas, senão você faz uma superimplementação e ninguém usa, né, enterra, ela morre ali. Exatamente. Muito bom! Gente, que papo bom! São muitas coisas. É o tipo do papo que temos que ouvir algumas vezes para poder extrair tudo o que está sendo dito. São nortes superimportantes. Mas tem um último ponto que eu queria te ouvir, aproveitar bem a sua experiência, que é a questão da segurança dos dados. Temos uma referência na Europa, na lei europeia de proteção aos dados. A LGPD já veio com alguns avanços, estabelecendo alguns limites. De novo, temos alguns desafios que são culturais aqui no Brasil. Como você vê a questão da segurança dos dados, num contexto analítico, onde muitas vezes você vai, de fato, armazenar ali, de forma agregada, todas as suas informações gerenciais? Quais cuidados, qual a maturidade brasileira nesse momento em relação ao assunto? Conforme a lei chegou, ela chegou para proteger, de fato, as pessoas que têm os dados compartilhados com outras empresas. Então ela talvez tenha chegado até um pouco tarde porque ela surgiu porque encontramos problemas de dados sendo vazados e tudo mais, justamente porque algumas práticas não estavam sendo utilizadas. Disponibilizamos dados sensíveis, que já conseguimos enxergar hoje essa diferença de dados sensíveis ou não, identificadores de usuários... Telefones, endereço, enfim, dados ali que podem ser utilizados de forma indevida. Tudo isso de forma muito acessível, que seria fácil de alguém mal-intencionado conseguir extrair esses dados e utilizar para outras finalidades. Então, algumas etapas, algumas camadas de proteção, são desenvolvidas para mitigarmos, evitarmos esse tipo de situação. Obviamente, o acesso ao Data Warehouse, ao data lake, aos dados de origem, se alguém invadir esses sistemas, com certeza vamos ter um grande problema. Mas pensando em todo o funil de transformação de dados, todo esse processo que nós temos dentro de uma plataforma, são várias camadas que nós temos até chegar num dado sensível, Normalmente a ponta de visualização, a ponta de consumo, onde temos respostas ali para as nossas perguntas. não precisa necessariamente do CPF do cliente ou do telefone. Precisamos de números indicando se determinada campanha de marketing, por exemplo, está funcionando da forma esperada ou não. Então não precisamos de muitos detalhes. Os dados que ficam disponíveis para amplo acesso, seja interno ou dependendo até mesmo como um produto sendo exposto de alguma forma, são dados agregados, como você disse, métricas já calculadas, dados onde nós... Esses dados são anônimos. Não conseguimos vincular toda essa informação a pessoas, não conseguimos trazer insumos para ser utilizado de forma indevida por outras pessoas. Então eu acho que essas leis que surgiram, como temos implementado isso agora, já deveríamos estar fazendo isso bem antes. Agora, por ter virado, de fato, uma lei, principalmente o cenário nacional tem evoluído de uma forma interessante, temos nos preocupado cada vez mais com isso. E tem até diversos memes na internet também. Quando tem ali o vazamento de dados, daí começa-se a investir muito dinheiro e tudo mais. E não precisamos disso, porque se vazar, vão ter muitas multas, vão ter muitas coisas envolvidas, então ninguém quer que isso aconteça. Então, além de proteger o cliente, as empresas estão se protegendo também. Consequentemente, temos um cenário cada vez melhor pensando em proteção de dados. Ferramentas de governança estão sendo cada vez mais utilizadas para conseguirmos identificar o que é um dado sensível ou não, para protegê-los de uma forma mais eficiente. Ferramentas para dar nível de acesso de uma forma mais eficiente. Os próprios Data Warehouses. Hoje nós conseguimos dar acesso em nível de linha, nível de coluna de uma mesma tabela, o que acaba sendo muito mais prático também para esse tipo de proteção. Então toda essa tecnologia está em favor justamente de proteger, de como estamos utilizando esses dados. Muito bacana. E é um ganha ganha, né, como você diz. Todo mundo sai ganhando com uma postura mais ética e mais segura também. Com certeza. Muito bom, Lucas. Eu quero te agradecer né? Muito bom aprender com você, te ouvir, ouvir cases. Eu sei que você traz o frescor, a prática do mercado. O Lucas é professor. Eu acho que deu para vocês perceberem, né? Além de estar aí no contexto corporativo, ele também nos ensina aqui. E unir as duas coisas, fica uma delícia para os ouvidos, viu? Foi um prazer. Muito obrigado. Eu que agradeço a participação, o convite. Falar do intermake para mim é superimportante Está presente em todos os meus dias do trabalho, então acaba sendo muito interessante poder compartilhar um pouquinho dessa experiência também, e também ouvir todos os seus pontos, né? A sua experiência também é muito boa. Sempre aprende um pouquinho mais nesses papos. Nós crescemos. E você também, que ficou conosco até agora, cresceu, e pôde perceber que nós temos uma série de papéis, muita tecnologia, várias ferramentas. A nossa dica, né, Lucas, é: comece. Tem muita oportunidade. Muita, muita, um mercado muito aquecido. Comece, vá mergulhando. Com o tempo você vai ganhando maturidade, visão arquitetural. O céu é o limite, de fato, nesse mercado de dados. Nós somos suspeitos, amamos tudo isso aqui. Queremos que você venha aqui para o nosso lado também.