Latest / Entre Chaves / O problema da obsessão pela ‘arquitetura perfeita’

Transcript

O problema da obsessão pela ‘arquitetura perfeita’ · Entre Chaves

• 0:02
  É uma é uma coisa que deixou o nosso desafio um pouco mais
• 0:07
  difícil e até a solução, né? Consequentemente, ficou mais
• 0:10
  robusta por causa disso. Quando a gente fala de
• 0:12
  recomendação no universo b to b, né, que foi o nosso caso, né?
• 0:16
  Pelo menos na minha visão, bem mais difícil de se fazer do que
• 0:20
  no universo b to c, porque é é bem factível pensar que.
• 0:25
  No b to c, né? Pra pessoa física, quando você
• 0:27
  entra no site ou vai na loja, está olhando o mouse ou
• 0:30
  computador, é razoável pensar que faz sentido eu te recomendar
• 0:35
  um mousepad, um teclado ou um acessório?
• 0:37
  No b to b é diferente, né? Não tem essa relação direta
• 0:41
  entre os produtos. Ou seja, se o meu cliente está
• 0:44
  me comprando o leite ninho, pode ser que não tenha nenhuma
• 0:46
  relação com ele querer comprar o toddy ou não.
• 0:49
  Porque ele, na verdade, está comprando um produto para
• 0:52
  revenda e não para consumo. Então essas relações entre
• 0:55
  produtos, entre categorias, fica mais difícil, né?
• 0:59
  De não são tão explícitas. Então acho que isso deixa esse
• 1:02
  desafio, né? Dentro desse universo que você
• 1:04
  falou, ainda mais mais difícil. Eu quero entrar um pouco mais em
• 1:08
  detalhe, Pablo, nisso que você acabou de falar, né, que eu
• 1:10
  fiquei bem curiosa em como que é a recomendação, né?
• 1:13
  Esse desafio da recomendação em marketplaces b to b, né?
• 1:16
  Já como como você disse, né, que é um desafio bem diferente de um
• 1:19
  b to c mas antes eu só queria reforçar que eu acho que tem um
• 1:22
  negócio bem legal que vocês foram falando sobre a fundação
• 1:24
  de dados, né? E como que as coisas evoluíram,
• 1:26
  né, que realmente foi tomada uma decisão de começar pequeno, né,
• 1:30
  pra depois ir evoluindo aquela estrutura de dados.
• 1:33
  Pra ir habilitando o caso de uso mais robusto, como se fosse
• 1:37
  assim. Isso tem tudo a ver com o que a
• 1:39
  gente já falou aqui no entre chaves algumas vezes sobre é a
• 1:44
  fundação, né? A evolução mesmo da fundação de
• 1:46
  dados e uma arquitetura, a ired, né?
• 1:49
  Que a gente chama aqui. Claro que eu tenho uma.
• 1:51
  Uma arquitetura que é a ideal. Mas é óbvio também que eu não
• 1:55
  consigo chegar no que é ideal de primeira, porque senão eu vou
• 1:59
  ficar evoluindo tecnicamente pela tecnologia, né?
• 2:02
  Simplesmente sem que o negócio esteja do meu lado.
• 2:05
  Para falar assim, ó, eu estou vendo o valor, eu estou vendo o
• 2:07
  valor da entrega e pelo que vocês foram falando.
• 2:10
  Desde o início já tentaram habilitar o valor de ser
• 2:13
  entregue, claro, no início talvez foi um valor que foi um
• 2:16
  MVP, né? Talvez um MVP de verdade, né?
• 2:19
  Mas foi um valor talvez um pouco menos assertivo do que poderia,
• 2:23
  mas já foi um valor que aí, né? Enfim, é aquela coisa, né, que a
• 2:26
  gente também pode falar que quando eu vou melhorando a minha
• 2:30
  minha fundação, eu vou habilitando casos de uso mais
• 2:33
  complexos. Quando eu vou habilitando casos
• 2:34
  de uso mais complexos, eu vou vendo possibilidades de melhorar
• 2:37
  minha fundação. Então isso é acho que é bem
• 2:39
  legal e tem tudo a ver. Com muita coisa que a gente já
• 2:41
  falou aqui no entre chaves sobre essa arquitetura, né?
• 2:44
  E iread, né? E é.
• 2:46
  Nesse ponto que Eu Acredito que é a razão de que muitos DAT
• 2:50
  lakes falham, né? Porque justamente porque querem
• 2:53
  começar é já implementando toda a arquitetura, né?
• 2:58
  Robusta, com catálogo, com governança, com todo mundo de
• 3:04
  dados e. Pensando de forma corporativa.
• 3:08
  E aí você acaba atrasando, né? Muitas das entregas de valor,
• 3:12
  porque você vai gastar muito tempo ali construindo a fundação
• 3:16
  antes de validar se essa fundação tá fazendo sentido.
• 3:19
  Então acho que foi aí que é que eu acho que foi uma decisão
• 3:22
  acertada de ter começado com o data pug e aí só conceituando,
• 3:27
  talvez pra ficar um pouco mais claro, o data pug, ele seria um
• 3:30
  data Lake e focado em um caso de uso.
• 3:32
  Então ele é ele é um propósito específico, então, normalmente.
• 3:36
  Gente, você não vai se preocupar tanto com a robusteza, a sua
• 3:39
  arquitetura, com AO data surving, porque você só vai
• 3:43
  servir um caso de uso. E aí quando você começa a ter
• 3:47
  mais casos de uso, né? O seu data poodle começa a gerar
• 3:51
  valor. Você vai ter, naturalmente, os
• 3:53
  usuários pedindo mais dados, querendo implementar mais casos
• 3:55
  de uso. E aí você é tem o data point,
• 3:59
  que seria um conjunto de data poodles com mais usuários
• 4:02
  utilizando o seu data poodle. Você precisa se preocupar com
• 4:05
  governança, catalogação, com modelagem, com variação, com
• 4:11
  tolerância a falhas à medida que você vai ingerindo dados, até
• 4:14
  que não não vão ser utilizados de forma imediata.
• 4:18
  Você começa a se preocupar com self service porque vai ter
• 4:21
  muitas pessoas consumindo e aí sim você tem o nascimento de um
• 4:25
  data lay que de forma orgânica. Então eu acho que se a gente
• 4:28
  tivesse caído nessa armadilha, né, de ter, vamos começar um
• 4:32
  data Lake corporativo pro Martins pra poder construir o
• 4:35
  nosso motor de recomendação. A gente vai ficar talvez um ano
• 4:37
  trabalhando nisso e não IA ter um motor de recomendação
• 4:41
  funcionando.