DTW CAP03 2024 BP BOAS PRATICAS PROJETOS DW E BI

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 ter
todos esses assuntos prontos,

seja origem de dados onde não os temos
mapeados 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, com código de fato,

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,

near real-time, 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 engenharia de dados.

Ele é meio híbrido ali, né?

De todas as profissões, essa é
que acaba sendo a 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
há diversas possíveis carreiras,

ou em empresas menores, acabamos
tendo o 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, 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 os demais.

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 precisamos 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 à 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.