: :
os agilistas

#104 Data Science na prática

#104 Data Science na prática

os agilistas
: :

M1: Bom dia, boa tarde, boa noite, vamos começar mais um episódio dos agilistas, hoje a gente vai abordar um tema que eu acho que é vital para que os squads possam de fato gerar valor, um tema recorrente que a gente aqui no podcast, já tivemos enzimas sobre isso, como é que os squads tem que ser times multidisciplinares, autônomos e capazes de gerar valor e como isso muitas vezes não acontece, e é curioso que nós vamos adotar esse termo a partir de uma perspectiva de ciência de dados e porque? Porque se pensa muito em uma ciência de dados da perspectiva de machine learning de modelos de tedição e de coisas super avançadas mas a verdade não se pensa que você tem todo um caminho para percorrer isso para fazer com que um squad, por exemplo, seja

orientada a dados, ganhe maturidade para tomar decisões que sejam realmente significativas para o negócio, consiga de fato elaborar hipóteses, testar hipóteses e na medida que ele naturalmente amadureça, ele vai talvez e possivelmente incorporando essas técnicas mais avançadas, então eu acho muito interessante porque isso tem muito a ver com agilismo, porque é na verdade muito mais uma preocupação em juntar todas disciplinas para gerar o tempo todo do que pensar o seguinte, eu tenho que fazer machine learning de qualquer jeito e para poder falar sobre isso, nós trouxemos aqui três convidados que vão se apresentar e vai ser super interessante que vai ter uma visão de cientista de dados, visão de desenvolvimento, visão de gestão sabe, então nós vamos poder combinar todas essas visões para entender o seguinte, afinal das contas como é que a gente usa ciência de dados na prática e como a gente faz para fazer um squad ficar (inint), então estamos aqui com a Maria Eugênia, o Zé Renato e com o André Luiz ou Andrezão, queria pedir para que você se apresentasse, tudo bem Maria Eugênia?
Maria Eugênia: E aí, (inint), é me apresentar rapidinho, eu sou a Maria Eugênia, sou formada em estatística, trabalho aqui na DTI com ciência de dados, ajudando em iniciativas para tornar os clientes data driving.
M1: Bacana, tudo bom Zé Renato?

Zé Renato: Tudo bem, eu sou o Zé Renato e hoje o meu papel do DTI é DL, sou formado em engenharia de controle e automação.
M1: Beleza, e aí Andrezão, não consigo te chamar e André Luiz não Andrezão.

André Luiz: Bom dia, boa tarde, boa noite para todos, meu nome é André Luiz, todo mundo me conhece por Andrezão eu sou filho da casa, sou formado em sistema de informação pela (inint) entrei na área de T.I como estagiário e hoje estou no papel de técnico (inint).
M1: Bacana demais, eu queria começar com a Maria Eugênia, para abordar o seguinte, como a gente colocou no começo, quando se fala em Data Science, todo mundo pensa nessas coisas mais sexys aí que é machine learning, tradeção, algoritmo e coisas muito avançadas e não que elas não possam ser importantes e não possam gerar valor mas existe um longo caminho a ser percorrido, a gente fala um pouquinho sobre isso.
Maria Eugênia: Sim, eu acho que essas palavras são (buzz order) atualmente o olho até brilha quando a gente escuta falar mas acho que para uma empresa que nunca trabalhou com dados é muito difícil, soa como um bicho de sete cabeças, a pessoa nunca fez nada parecido com dados e isso soa muito distante da realidade e como começar, a gente fala que em ciência de dados a gente divide em quatro tipos de análise de dados, para esse caminho de se tornar data driving digamos assim, então primeiro tipo de análise seria análise descritiva que é quando a gente responde o que está acontecendo, o segundo tipo de análise seria análise diagnóstica que é quando a gente já entendeu o que está acontecendo e agora a gente explica o porquê está acontecendo, o terceiro tipo de análise seria de fato a preditiva, que enche os olhos ai, que a gente vai prever o que vai tentar acontecer e a prescritiva que é quando a gente explica o que é preciso fazer, mudar algum padrão, alguma tendência e a preditiva chama atenção mas eu acredito que tem um pouco dessa escadinha, a gente precisa entender primeiro o que está

acontecendo hoje para depois a gente poder explicar depois o que vai acontecer no futuro.
M1: É curioso, você falando desse jeito fica tão óbvio, assim, eu não sei nem o que está acontecendo e já quer fazer previsão, prescrição, chega ser engraçado, isso é um cenário digamos assim, comum na maior parte das organizações, não conseguir esta nem nesse nível de descrição?
Maria Eugênia: De certa forma sim, depende do cenário, eu já participei de alguns squads, de alguns times e que chegava lá e a gente tinha algumas hipóteses do que estava acontecendo no momento: “eu acho que tal coisa é um gargalo”, “acho que isso é um problema”, e a gente ia fazer todo um estudo, fazer análise descritiva, como que as coisas (inint), às vezes a hipótese caia por água abaixo, não acho que não é isso exatamente que está acontecendo, então, acontece.
M1: Mas isso acontece porque Maria Eugênia? Eu falo pelo seguinte, eu tenho duas hipóteses, um é porque muita gente acha que sabe, quando a gente fala (day trade dream), muita gente acha que sabe, já acha que acha que sabe que isso acontece por causa disso e talvez nem fomente o uso do dado e outro talvez por dificuldade técnica mesmo, do dado não estar visível, não estar presente e algo que a gente já comentou aqui até em outros podcasts, muitas vezes não nem, eu quero depois que o Zé Renato e André fale sobre isso, não dá nem liberdade para o squad tentar fazer essa análise descritiva, começar levantar os dados e tudo, o que você enxerga sendo mais comum? É isso mesmo que eu disse?
Maria Eugênia: Eu acho que é os dois mesmo, dificuldade de organizar e saber o que eu vou medir e como, e a dificuldade de entender que às

vezes uma hipótese que a gente tem como verdade, não é necessariamente o que está acontecendo, acho que acontece os dois.
André Luiz: Você até citou (inint) mas uma coisa que esses anos já trabalhando na DTI, eu percebi, uma coisa que você já falou em outros podcast também é que hoje o agilismo é meio (inint) mas não sei se todo mundo entende isso de verdade não sabe, eu acho que todo mundo quer aplicar de uma forma rápida e não agiu, então assim, igual tem o episódio da maldição do escopo, a galera fica (inint) no escopo, todo mundo quer que o desenvolvedor do software desenvolva ele não quer saber se o desenvolvedor tem que entender o contexto como um todo, pelo menos é isso que a gente vem percebendo, é claro que (inint), mas ainda está muito nesse viés ainda.
M1: Existem razões filosóficas anteriores a própria ciência de dados que impossibilita assim, uma é essa questão que você colocou de escopo outra é a questão de produtividade, a gente já falou sobre isso aqui, para muitos clientes produtividade é ver o pessoal soltando features e mesmo que não sirvam para nada, a gente até brinca, pode estar fazendo um monte de coisa que não serve para nada e dependendo da medida ali tá sendo improdutivo e não gerando valor, eu concordo com o Andrezão, que isso no fundo é uma falta de compreensão do que é ágil, porque ágil não é ser mais rápido sair fazendo as coisas igual doido, eu sempre brinco não tem ninguém ali digitando super rápido, e ágil é fazer você aprender super rápido inclusive dispensar menos, e para você aprender rápido precisa partir de alguma hipótese até para saber se aprendeu ou não, sem hipótese você não sabe nem se aprendeu alguma coisa e é difícil cara, as pessoas realmente não pensam sobre hipóteses, antes até de entrar no

case prático aqui que nós vamos discutir um pouquinho, então qual seria um caminho assim Maria Eugênia, a gente não acredita muito em prescrição mas normalmente seria um caminho pelo menos, uma visão como que o squad poderia trilhar essa jornada para ir saindo do descritivo para o diagnóstico, pro predição para chegar ate o descritivo, só para ficar mais claro para o pessoal.
Maria Eugênia: Acho que de fato mesmo, não tem essa receita de bolo, mas acho que você meio que já respondeu no seu comentário anterior, porque eu acho que o segredo é esse, testar, qualquer hipótese que eu tenha vou lá consigo medir, acompanhar isso, evoluir e testar, sempre pensar em métricas, no que é o objetivo do time ou da solução e pensar consigo medir isso? Isso faz sentido? E tentar metrificar nisso e a partir de análise descritiva por exemplo de como eu vejo como as coisas estão, eu acho que é natural, eu consigo pensar e enxergar oportunidade de evoluir aquilo.
M1: Quais exemplos de análise descritivas? Só para ficar mais claro para quem está nos ouvindo, são gráficos, indicadores? Quando você fala análises descritivas o que exatamente você está falando?
Maria Eugênia: A gente fala muito de visualização de dados nessa parte descritiva então muito gráfico, tabela, painéis de visualização de dados para deixar na mão ali da pessoa, um painel interativo que ela consiga filtrar por data e ver evolução do tempo, ver um gráfico, indicadores, ter todas essas métricas ali não dela.
M1: Esse é o descritivo e o que caracterizaria o diagnóstico? Essa análise diagnóstica?

Maria Eugênia: Diagnóstico seria eu entendo que isso está acontecendo, então por que está acontecendo? Ai pode misturar um pouco com a preditiva, mas neste momento a gente pode fazer teste estatístico então por exemplo eu sei que o volume de vendas caiu mas ele pode ter caído e não ser estatisticamente significante pode ser uma flutuação que ocorreu e eu posso fazer um teste para confirmar se aconteceu mesmo, mas já começa ser uma análise mais robusta, depois eu posso entrar de fato em modelagem, então eu entendo que a venda caiu porque, um outro motivo, uma outra variável que ajude a explicar.
M1: Entendi, então André e Zé Renato, queria que vocês pegassem um exemplo, vocês tiveram a oportunidade de participar de um squad com o Andrezão desde o começo, que foi se movendo para ser orientada a dados, fale um pouco sobre isso por favor Andrezão para depois o Zé completar com a experiência mais recente.
André Luiz: Esse é um squad que a gente atua a muito tempo com um cliente nosso em T.I e por ele já passaram várias pessoas, eu fui líder dele também e era um squad que hoje a gente considera que o time muito é maduro pelo tanto que a gente já é, a gente começou desde o início reformulou uma parte desse cliente, uma parte ligada a gente reformulou tudo, e a gente veio conhecendo muito das integrações de uma parte muito técnica desse produto mas até com essas iniciativas que a gente está tendo de promover e dar esse conhecimento do time, a gente percebeu que esse era um time que poderia começar a entender mais sobre o cenário atual dele baseado nos dados e poder criar insights para isso e agora que surgiu essa iniciativa, mercantilidade e essa forma de colocar na pratica mesmo e ai já foi o Zé Renato que agora é o líder do

time que a gente aplicou junto com eles, e ele conhece hoje muito mais do cenário que eu, ele pode dar mais informações para gente.
M1: Como é que foi isso então Zé? Você pegou o time bom e gradativamente foi mudando de um time que basicamente se orientava pela funcionalidade mesmo e agora cada vez mais ele se orienta hipótese embasada por dados, é isso?
Zé Renato: Sim, a gente começou bem, mas trabalhando sob demanda mas acabou que a gente mudou a mentalidade foi tentar a ser mais orientado a dados, inclusive teve influência forte do time que entrou mais recente que tem essa mentalidade data driving mas o primeiro passo zero que a deu foi tentar pegar os dados do zero mesmo e montar no Excel para ter uma direção, mas para ficar mais claro, o processo que a gente trabalha se resume basicamente, a gente recebe algumas solicitações que tem alguns itens e uma pessoa analisa essa situação com os itens e pode aprovar ou reprovar ou mexer e negociar e aprovar essa solicitação depois da renegociação e a gente estava tentando automatizar alguns solicitações, algumas provações dessas solicitações, o primeiro passo a gente tentou por conta própria buscando direto na base de dados as informações a gente fez um pareto, agrupou os itens por volume, e vou citar o que mais chega aqui, o item A e vão tentar automatizar esse item primeiro para ver o que acontece e tem alguns itens que não dá por conta de regra de negócio que precisa de olhar a foto não dá para ser automático por enquanto, vamos pegar os mais simples e vai de cada negócio, que regras tem e colocamos lá e fomos ver o que estava acontecendo e ainda sim, começou a aprovar alguns itens mas mesmo assim alguns não aprovavam e também tinha o empecilho de sempre eu o

desenvolvedor do time sempre quer que fazer esse trabalho de minerar os dados na unha.
M1: O Zé, só um segundo, só porque eu fiquei tentando me colocar na posição do ouvinte e para casar o que a Maria Eugênia falou, ou seja, normalmente existia uma necessidade de negócio de automatizar essas aprovações.
Zé Renato: Isso.

M1: Normalmente, pensando em uma abordagem ágil gerar valor em longo e curto prazo, eu já não vou tentar automatizar tudo, eu não sei nem se consigo, aí alguém pensa assim, mas quais então? Esse quais vocês fizeram então análise descritiva, é isso Maria Eugenia? Uma análise descritiva para entender qual é o perfil de aprovações e etc e a partir disso começar autorizar a partir dessa análise descritiva.
Zé Renato: Sim, é, começamos pequeno, justamente por isso, eu não vou autorizar tudo é impossível então vamos começar aqui, mas esses itens pequenos qual vai ter um maior retorno, por isso que a gente fez isso de ver um item só que eu vou (inint) mas ele representa um volume grande então vamos pegar esse item que vai me dar um score de negócio, dava para colocar suas regras específicas lá, vamos colocar e ver o que acontece, fizemos isso mas o passo antes dessa análise que a gente fez também ficava um pouco oneroso porque dependia de mim ou de outro desenvolvedor para buscar essa base para passar para a p.o para ela montar no Excel e montar os gráficos e chegar em alguma conclusão, acabava que era oneroso, ai a Maria Eugênia veio ajudar a gente no time, ela ajudou a gente a montar um dashboard aí pensando mais nessa linha que a gente tenta seguir do (inint) ficou muito melhor porque

ele casa com esse raciocínio de ter sempre os dados avista e facilita o trabalho, automatiza a mineração desses dados, digamos assim e fica visível para todo time e você acaba democratizando esse conhecimento dos dados e ter opinião de todo mundo ao invés de ficar só na mão do p.o e todo mundo ver só quando ela apresenta na tela dela para gente e o dashboard acaba ajudando nessa parte de discussão e todo mundo ter acesso aos dados de forma mais rápida, e quando a gente estava tentando desenvolver, a Maria pode complementar também, ela conversou com a gente para tentar entender melhor o que a gente tinha que descrever porque só essa análise da quantidade de itens por volume foi bem simplista, então vamos tentar descrever o que está acontecendo depois dessa primeira ação, voltando um passo antes ainda, o sistema nosso de automação ele salva no banco os motivos da reprovação dos itens e a gente pegou e falou vamos ver o motivo de maior reprovação, mesmo eu configurando porque ainda está reprovando, a gente fez essa análise, ela colocou no dashboard também, você selecionar o item e ele agrupava por motivo de aprovação e a gente via o resultado, por exemplo um dos caso que a gente viu, o valor está acima do valor de referência e isso deu feedback para gente que não adianta nada eu fazer a regra aqui para provar sendo que quem envia a solicitação está colocando valor acima, isso acabou gerando ações para gente pensar em (inint) voltada no momento que houve solicitação, tem como eu induzir ele a colocar um valor menor ou criar algum processo da área de negócio dele já fazer uma negociação para esse valor, já vir sempre no padrão para eu poder aprovar no automático? Acabou que a gente teve essas ações que a gente está inclusive fazendo até hoje ainda, foi ativada depois desse feedback

que é bem recente, essa análise e deu uma subida depois dessas ações graças a esses dados que a gente acabou estudando.
M1: Isso que eu queria pergunta para a Maria Eugênia, imagina, existe essa questão então, preciso automatizar a aprovação dessas estações: “Eu quero fazer isso orientado a dados”, então precisa descrever os dados que eu tenho, mas como é o processo agora, quais dados eu uso, o que eu uso, e se tem coisa que eu nem sei que é importante, como é isso, o que quero visualizar.
Maria Eugênia: Sim, muita conversa do time sempre falam que a parte mais difícil do trabalho de um cientista de dados quando ele chega em um projeto novo é entender o que é importante para o time e assim, dando continuidade no que o Zé falou, a gente fez esse processo inicialmente descritivo de ver quais itens são os mais frequentes, eles são automáticos hoje, sim? Não? Será que eu posso escolher um deles para automatizar e depois a partir dessa análise exploratória e descritiva, a gente até conseguiu avançar um pouco além da análise descritiva, foi tentar explicar um pouco mais e ajudar o time a priorizar e a gente acabou fazendo uma análise de correspondência, em termos mais leigos é como se fosse analise de carrinho de supermercado, que é entender que sempre que eu compro o item A eu sempre compro o item B, por exemplo, então não adianta nada eu automatizar o item A que é o de maior volume por exemplo sendo que ele sempre vem com o item B, então se eu automatizar o A eu tenho que automatizar o B, se não, não adianta nada, ai a gente conseguiu fazer esse tipo de análise e acho que ajudou também um pouco na parte de priorização.

M1: Isso é bem interessante, porque sem essa parte estatística, você pode ficar ali frustrado que na verdade não está conseguindo aprovar nada, fazer outras coisas e daqui um tempão descobrir que existe uma correspondência que você não levou em consideração.
Zé Renato: Exatamente, aconteceu isso também, o segundo passo, depois a gente analisou ainda se subiu um pouco mais ainda tinha outros fatores que ainda não subiu o quanto a gente esperava, a gente fez uma análise mais simplista, a Maria Eugênia fez essa correspondência, que é parecido com a análise de carrinho, que em site de compra geralmente tem, você compra e aparece que quem comprou isso também levou isso e tenta te induzir levar mais algum item mas nesse cenário a gente viu isso de aprovar solicitação, então não adianta nada aprovar um item da solicitação sendo que o outro você é reprovado, então eu configurei o item A para ser aprovado automaticamente mas ele vem junto com o item B que não aprova automaticamente, consequentemente a solicitação como um todo não é aprovada, isso ajudou bastante a gente levantar ações e voltando ao assunto da construção do dashboard, primeiro a gente fez essa divisão sem a correspondência e testando mesmo, a gente testou e viu que precisava dessa análise de correspondência, ela foi lá adaptou o dashboard e colocou mais essa outra análise de correspondência junto e como MVP a gente ainda não fez aquela data lake que processa os dados e transforma eles para ir direito, como a gente estava testando a gente não sabia ainda o que a gente queria ver, por exemplo, tinha um banco que era réplica, a gente leu direto essa réplica sem transformar os dados nenhum, acaba que a gente não consegue ver um horizonte de dados tão longe no passado porque acaba atrapalhando

um pouco em performance mas conseguiu contribuir para gente tomar essas ações e conseguir definir o que a gente quer ver, se não, não seria ágil, começaria fazer de cara, replicar os dados, transformar e depois você ver que não era aquilo que você queria ver, aí fica para um passo para frente que a gente ainda não chegou, essa parte de definir tudo que a gente quer e partir para essa etapa de transformar os dados para melhorar a performance e ver o tempo mais longe.
M1: Isso me traz uma dúvida que eu sempre tenho que é o que é o certo? Não sei se é o certo a pergunta, qual é a melhor forma de se agir, é já se partir de uma demanda, de uma necessidade de negócio, por exemplo e ir puxando os dados e eventualmente até chegar na necessidade de criar um data lake para satisfazer aquilo, ou eu primeiro penso, porque eu vejo muita abordagem no sentido contrário, você vai e começa criar um data lake vai jogando informação lá imaginando que alguém vai usar, ou são as duas coisa sabe, faz um pouco de uma, um pouco da outra, como é que é?
Maria Eugênia: Bom, eu vou tentar responder um pouco então, acho que pode ter os dois casos, no caso do time do Zé a gente queria entender um pouco do contexto deles, era muito específico do time deles e a gente conseguia pegar os dados ali de forma mais rápida, do jeito que ele falou, existia um banco que a gente conseguia pegar e já analisar e fazer essa análise, é claro que depois, igual foi o caso, a gente identificou um gargalo, a gente queria um histórico mais de dados e talvez a gente precisasse de ajuda de um time de engenharia de dados para fornecer esses dados com histórico mais completo para gente e ai teria que passar por esse processo, um outro exemplo que a gente passou similar que o Zé relatou, um outro cliente, a gente passou por esse processo de construir parede de

visualização e quando a gente queria expandir isso para todos os produtos, digamos assim do cliente, a gente viu que as fontes de dados não estavam centralizadas, organizadas e que existia de fato a necessidade de construir um data lake, então acho que as duas coisas vão casando, a gente vai enxergando oportunidade quando a gente começa a fazer as análises.
M1: Acho isso bacana porque é o ágil em ação mesmo, porque você não precisa ficar ali um ano fazendo data lake e depois começar usar, você às vezes sabe que a informação é imperfeita ou limitada mas tenta tirar uma conclusão ali, com aquela conclusão você começa a gerar valor, mas você começa perceber que aquele é um caminho bom mas gostaria de explorar mais e talvez para explorar mais você começa a criar um data lake e assim começa a fazer sentido colocar outras fontes de informação, outras coisa.
Maria Eugênia: E começa ficar ate mais fácil de justificar o porque eu quero construir um data lake talvez porque eu preciso dessa parte da engenharia de dados, porque eu quero responder, atender tal demanda, nesse sentido.
M1: Ou seja, nesse case Zé Renato nós estamos usando, vamos dizer assim, dentro do que a Maria Eugênia falou, a parte descritiva é a parte diagnóstica porque a gente também consegue tirar conclusões desses dados, vocês enxergam a possibilidade de fazer a preditiva e prescritiva de alguma forma? Como é que é?
Zé Renato: Ainda não, a gente está trabalhando para evoluir essa parte prescritiva e diagnóstica ainda, tanto que a gente está até pensando em rever agora essa questão da transformação dos dados para conseguir ver

um horizonte maior e ter um diagnóstico ainda melhor do que a gente já tem hoje.
M1: Curioso, eu imagino que deve haver um potencial gigante só na descritiva e diagnóstica porque é pouco utilizado, não é isso?
Maria Eugênia: Eu acho que a prescritiva também é pesada de ter ficado meio que nessa escadinha como se fosse o ponto máximo, a gente consegue usar ela antes também, apesar de análise descritiva soar mais simples e a diagnóstica ali seria o segundo passo, o que a gente fez com o time do Zé, a gente conseguiu tomar ações e tomar ações prescritivas, de chegar para o time e falar, olha o próximo item a ser automatizado não deveria ser esse, então apesar de ser uma análise descritiva ou diagnóstica, não ser a preditiva ainda, o time já conseguiu tomar decisões, ajudou de alguma forma.
M1: A sim, a prescrição não precisa vir de um modelo de predição, a prescrição pode vir do diagnóstico?
Maria Eugênia: Não necessariamente, sim, tenho um outro exemplo se quiser que eu conte.
M1: Aham.

Maria Eugênia: Um outro cliente nosso a gente construir de forma similar um painel de visualização e o cliente tem vários parceiros comerciais, então hoje em dia com esse painel de visualização eles tem em mão, o time comercial, tem em mãos a conversão de cada parceiro comercial, então agora ele consegue saber a média de conversão de vendas é de 50%, porque o parceiro está apenas com 20%, ai o time comercial, por um dado que é descritivo, simples, é um percentual, ele consegue tomar a

decisão de falar que vai ter um contato maior com a pessoa porque o parceiro está com a conversão bem abaixo do esperado, ele consegue tomar decisões a partir de uma informação que é bem simples.
M1: Entendi, isso é curioso, teve outro episódio que a gente gravou sobre senha de dados, a Melissa falou muito isso, a boa visualização já faz uma diferença brutal, é o que o Zé Renato falou de ter gestão a vista etc, mas é engraçado se você explorar bem a própria visualização ela por si só já pode gerar ação, que é o caso que você falou.
Maria Eugênia: Sim.

Zé Renato: Sim, uma coisa bacana que rolou com a gente, comigo, como desenvolvedor, quando eu vi os dados na parte de valor, eu não tinha noção que valor era aquele, porque eu sempre via os itens separados quando ia testar alguma coisa, quando eu vi o volume acumulado do mês, é absurdo ver o volume de dinheiro que acaba sendo envolvido, então qualquer coisinha que você consiga melhorar ali, na escala da um retorno enorme.
André Luiz: Zé, você falou um negócio interessante isso, como é que a gente fala muito do ágil mas tem muitas vitórias que tinham que ter ainda, eu falo a comunidade do agilismo, é extremamente comum o time ágil ficar ali em uma bolha sem nunca ter visto os dados, ele fica anos lai trabalhando fazendo funcionalidade e nunca foi sensibilizado dessa forma, esse exemplo que você deu é um exemplo que eu chamo de propósito na veia, hora que você vê aquele dado ali e vê a diferença que você pode fazer, o time tem um tanto de ideia e começa a pensar em um tanto de hipótese e começa a perseguir aquilo, mas muitas vezes o pessoal prefere que o time não pode ver o dado, ou que o time está perdendo tempo de

ver o dado, ou o time tem que focar na funcionalidade, focar no backlog, você vê só de realimentar o time ele começa a aprender sobre o negócio e traçar suas hipóteses.
Zé Renato: Sim, é como você falou, um negócio legal é que é realmente realimentado, porque por exemplo uma coisa que eu percebi também, é como você precisa puxar os dados para tomar decisão você acaba pensando melhor em como salvar os dados, se você está desenvolvendo um sistema e tem que salvar alguma informação, você já pensa melhor de como você vai salvar aquela informação que você foi puxar de novo, para você ter retorno da ação que você está fazendo, se o cara passa uma demanda e você só refaz e pronto, mas se você pensa que você tem que medir o valor que lá está gerando, você já pensa em como vai salvar os dados que aquela features está agregando no sistema para você ter o feedback sendo que features está gerando valor ou não, acaba que você realimenta para você desenvolver pensando no que vai medir.
M1: Então Andrezão, observando isso porque imagina, isso é uma mudança muito grande na forma que o time é gerido na liberdade que o próprio cliente dá para o time porque o time tem que ter espaço para fazer essas coisas, isso que eu queria que vocês falassem um pouco, um time que é orientado a dados é tão (day trade dreams) ele pode ter até um backlog ali para refletir certas hipóteses, para traduzir as hipóteses em certas funcionalidades mas isso é de longe o mais importante, não é?
André Luiz: Acho que o grande valor gerado por essa iniciativa nossa, é exatamente esse, o que o Zé falou dessa retroalimentação e do time começar olhar mais para isso, nesse time tem até algumas situações legais

que aconteceram, foi que o Zé ficou, o time ficou sem p.o e o Zé ficou um tempo assumindo esse papel lá dentro, então ele já tinha uma certa mobilidade para pensar, mas era uma coisa que agente já estava engatilhando a muito tempo, porque a gente não estava (inint) baseado em dados, nessa data driven e depois que a gente começou com essa iniciativa, começou dar super certo, o time hoje é muito mais pautado por isso, então hoje surge uma features lá sem ela ser questionada se ela dá um resultado, primeiro baseado nos locais (inint) em si e segundo se aquilo está voltado para tangenciar o grupo por muito, essa parte dos dados que eles estão levantando, então eles ajudam muito porque o time começa ter autonomia legitimada, (inint) eles tem autonomia porque sabem o que estão falando e vão bater de frente com o pessoal do (inint), se eu atuar nisso aqui eu começo a gerar muito mais a economia, não é esse nosso (inint), então eles têm uma legitimidade já intrínseca ali porque já conhecem muito mais do negócio, não só tecnicamente por trás dos panos do que está sendo feito.
M1: Sim, é o que o pessoal chama muito de restrição habilitadora, porque muitas vezes a liderança morre de medo de dar autonomia, fica parecendo que vai dar autonomia e vão fazer o que quiser, e na verdade existe algumas exceções que cria essas condições de contorno dentro do que você pode atuar e dentro disso você consegue atuar, a gente viu aqui como a ciência de dados pode ser usada de uma forma bem prática para fazer um time de data driven e vimos um exemplo de um time que ficou na data driven e conseguiu ficar, tanto pelo espaço que o próprio cliente, a própria estrutura comercial foi dando para que isso acontecesse,

autonomia, liberdade, a vontade de ficar na data driven mas também por que ele seguiu um determinado método que lhe permitiu a ficar na data diven, para quem está ouvindo isso, Maria Eugênia, como é que eu faço? Como é que eu começo? Como que a gente fala que é agilista, não tem receita, mas qual é um caminho interessante que você fala que é um bom jeito de começar.
Maria Eugênia: Passa por vários testes para chegar hoje e saber o que funciona melhor mas é aquela ideia de testar tudo, uma forma que a gente identificou assim como a gente tinha vários times que a gente queria orientar dados a gente passou por uma época que a ente mapeou a maturidade de dados em cada time, então a parte principal é sentar com o time e entender, a minha parte como pessoa que vai atuar em dados, então a primeira vez que cheguei no time do Zé, eu não tinha a mínima ideia do que era importante e do que eu deveria medir e da parte do Zé eu imagino que eles conheçam muito do negocio mas eles não sabiam como medir, então a gente precisava dessa troca então a gente fez esse mapeamento com vários times e no final a gente tentava resumir de uma forma que tinha três pilares, então o que o squad pode medir, ele sabe quais são as métricas, o que ele pode medir, o segundo pilar seria o que de fato ele mede e o terceiro pilar seria o que ele apresenta, e a gente fez essa conversa com vários time e a gente conseguiu entender quais estavam mais maduros, quais menos maduros, até a escolha de em qual squad a gente vai atuar agora, foi muito dessa iniciativa assim.
M1: Que interessante você fez o processo de explicar data driven, data driven.
Maria Eugênia: Sim.

M1: É o meta data driven.

Maria Eugênia: Não tinha pensado assim não.

M1: Achei interessante, você fez uma análise descritiva de como o squad está em relação a ser data driven ou não.
Maria Eugênia: Foi, isso mesmo.

M1: Para poder fazer um diagnóstico para depois tomar uma decisão, fazer uma descrição (inint)
Maria Eugênia: Isso aí.

M1: Interessante, interessante demais, ou seja, o que pode ser medido, porque tem informações que ele nem consegue medir.
Maria Eugênia: Sim, a gente passou por alguns times nessa parte de mapeamento que às vezes o time queria medir alguma coisa, sabia que era importante, mas não media, então passou a identificar que precisava colocar uma flag no sistema que quando acontecer tal solicitação vai marcar que aconteceu e vai conseguir medir, então teve esse processo também, de querer medir e não ter o dado, e ai dar um passo atrás, voltar e tentar começar medir.
M1: Interessante, nossa eu gostei demais desse episódio gente, eu queria agradecer a presença de vocês, achei interessante demais porque a gente aqui na DTI gosta de ser extremamente pragmáticos e a comunidade acha que tem que ser pragmática, você vê, a gente fala em ciência de dado e um passo ai pode ser ter que mudar um banco de dados, um flag para poder a informação existir, quando determinado evento por exemplo acontecer, isso pode não ser sexy igual falar em marching learning mas pode ser a decisão que vai te permitir medir alguma coisa, que vai te

permitir fazer análise de correspondência e talvez fazer a empresa economizar alguns milhões, então acho que é um jeito de colocar, eu sempre falo como eu sou um cara cético, eu gosto de sempre falar para os céticos, para os cético que ficam falando que esse negócio de ciência de dados está na moda, vocês vêm que da para ser extremamente pragmático e gerar muito valor, é calor na medida que avança a partir daquelas análises também. É isso aí pessoal, muito obrigado, abraço a todos.
André Luiz: Valeu pessoal, abraço. Zé Renato: Valeu, obrigadão.
Maria Eugênia: Valeu.

 

M1: Bom dia, boa tarde, boa noite, vamos começar mais um episódio dos agilistas, hoje a gente vai abordar um tema que eu acho que é vital para que os squads possam de fato gerar valor, um tema recorrente que a gente aqui no podcast, já tivemos enzimas sobre isso, como é que os squads tem que ser times multidisciplinares, autônomos e capazes de gerar valor e como isso muitas vezes não acontece, e é curioso que nós vamos adotar esse termo a partir de uma perspectiva de ciência de dados e porque? Porque se pensa muito em uma ciência de dados da perspectiva de machine learning de modelos de tedição e de coisas super avançadas mas a verdade não se pensa que você tem todo um caminho para percorrer isso para fazer com que um squad, por exemplo, seja orientada a dados, ganhe maturidade para tomar decisões que sejam realmente significativas para o negócio, consiga de fato elaborar hipóteses, testar hipóteses e na medida que ele naturalmente amadureça, ele vai talvez e possivelmente incorporando essas técnicas mais avançadas, então eu acho muito interessante porque isso tem muito a ver com agilismo, porque é na verdade muito mais uma preocupação em juntar todas disciplinas para gerar o tempo todo do que pensar o seguinte, eu tenho que fazer machine learning de qualquer jeito e para poder falar sobre isso, nós trouxemos aqui três convidados que vão se apresentar e vai ser super interessante que vai ter uma visão de cientista de dados, visão de desenvolvimento, visão de gestão sabe, então nós vamos poder combinar todas essas visões para entender o seguinte, afinal das contas como é que a gente usa ciência de dados na prática e como a gente faz para fazer um squad ficar (inint), então estamos aqui com a Maria Eugênia, o Zé Renato e com o André Luiz ou Andrezão, queria pedir para que você se apresentasse, tudo bem Maria Eugênia? Maria Eugênia: E aí, (inint), é me apresentar rapidinho, eu sou a Maria Eugênia, sou formada em estatística, trabalho aqui na DTI com ciência de dados, ajudando em iniciativas para tornar os clientes data driving. M1: Bacana, tudo bom Zé Renato? Zé Renato: Tudo bem, eu sou o Zé Renato e hoje o meu papel do DTI é DL, sou formado em engenharia de controle e automação. M1: Beleza, e aí Andrezão, não consigo te chamar e André Luiz não Andrezão. André Luiz: Bom dia, boa tarde, boa noite para todos, meu nome é André Luiz, todo mundo me conhece por Andrezão eu sou filho da casa, sou formado em sistema de informação pela (inint) entrei na área de T.I como estagiário e hoje estou no papel de técnico (inint). M1: Bacana demais, eu queria começar com a Maria Eugênia, para abordar o seguinte, como a gente colocou no começo, quando se fala em Data Science, todo mundo pensa nessas coisas mais sexys aí que é machine learning, tradeção, algoritmo e coisas muito avançadas e não que elas não possam ser importantes e não possam gerar valor mas existe um longo caminho a ser percorrido, a gente fala um pouquinho sobre isso. Maria Eugênia: Sim, eu acho que essas palavras são (buzz order) atualmente o olho até brilha quando a gente escuta falar mas acho que para uma empresa que nunca trabalhou com dados é muito difícil, soa como um bicho de sete cabeças, a pessoa nunca fez nada parecido com dados e isso soa muito distante da realidade e como começar, a gente fala que em ciência de dados a gente divide em quatro tipos de análise de dados, para esse caminho de se tornar data driving digamos assim, então primeiro tipo de análise seria análise descritiva que é quando a gente responde o que está acontecendo, o segundo tipo de análise seria análise diagnóstica que é quando a gente já entendeu o que está acontecendo e agora a gente explica o porquê está acontecendo, o terceiro tipo de análise seria de fato a preditiva, que enche os olhos ai, que a gente vai prever o que vai tentar acontecer e a prescritiva que é quando a gente explica o que é preciso fazer, mudar algum padrão, alguma tendência e a preditiva chama atenção mas eu acredito que tem um pouco dessa escadinha, a gente precisa entender primeiro o que está acontecendo hoje para depois a gente poder explicar depois o que vai acontecer no futuro. M1: É curioso, você falando desse jeito fica tão óbvio, assim, eu não sei nem o que está acontecendo e já quer fazer previsão, prescrição, chega ser engraçado, isso é um cenário digamos assim, comum na maior parte das organizações, não conseguir esta nem nesse nível de descrição? Maria Eugênia: De certa forma sim, depende do cenário, eu já participei de alguns squads, de alguns times e que chegava lá e a gente tinha algumas hipóteses do que estava acontecendo no momento: “eu acho que tal coisa é um gargalo”, “acho que isso é um problema”, e a gente ia fazer todo um estudo, fazer análise descritiva, como que as coisas (inint), às vezes a hipótese caia por água abaixo, não acho que não é isso exatamente que está acontecendo, então, acontece. M1: Mas isso acontece porque Maria Eugênia? Eu falo pelo seguinte, eu tenho duas hipóteses, um é porque muita gente acha que sabe, quando a gente fala (day trade dream), muita gente acha que sabe, já acha que acha que sabe que isso acontece por causa disso e talvez nem fomente o uso do dado e outro talvez por dificuldade técnica mesmo, do dado não estar visível, não estar presente e algo que a gente já comentou aqui até em outros podcasts, muitas vezes não nem, eu quero depois que o Zé Renato e André fale sobre isso, não dá nem liberdade para o squad tentar fazer essa análise descritiva, começar levantar os dados e tudo, o que você enxerga sendo mais comum? É isso mesmo que eu disse? Maria Eugênia: Eu acho que é os dois mesmo, dificuldade de organizar e saber o que eu vou medir e como, e a dificuldade de entender que às vezes uma hipótese que a gente tem como verdade, não é necessariamente o que está acontecendo, acho que acontece os dois. André Luiz: Você até citou (inint) mas uma coisa que esses anos já trabalhando na DTI, eu percebi, uma coisa que você já falou em outros podcast também é que hoje o agilismo é meio (inint) mas não sei se todo mundo entende isso de verdade não sabe, eu acho que todo mundo quer aplicar de uma forma rápida e não agiu, então assim, igual tem o episódio da maldição do escopo, a galera fica (inint) no escopo, todo mundo quer que o desenvolvedor do software desenvolva ele não quer saber se o desenvolvedor tem que entender o contexto como um todo, pelo menos é isso que a gente vem percebendo, é claro que (inint), mas ainda está muito nesse viés ainda. M1: Existem razões filosóficas anteriores a própria ciência de dados que impossibilita assim, uma é essa questão que você colocou de escopo outra é a questão de produtividade, a gente já falou sobre isso aqui, para muitos clientes produtividade é ver o pessoal soltando features e mesmo que não sirvam para nada, a gente até brinca, pode estar fazendo um monte de coisa que não serve para nada e dependendo da medida ali tá sendo improdutivo e não gerando valor, eu concordo com o Andrezão, que isso no fundo é uma falta de compreensão do que é ágil, porque ágil não é ser mais rápido sair fazendo as coisas igual doido, eu sempre brinco não tem ninguém ali digitando super rápido, e ágil é fazer você aprender super rápido inclusive dispensar menos, e para você aprender rápido precisa partir de alguma hipótese até para saber se aprendeu ou não, sem hipótese você não sabe nem se aprendeu alguma coisa e é difícil cara, as pessoas realmente não pensam sobre hipóteses, antes até de entrar no case prático aqui que nós vamos discutir um pouquinho, então qual seria um caminho assim Maria Eugênia, a gente não acredita muito em prescrição mas normalmente seria um caminho pelo menos, uma visão como que o squad poderia trilhar essa jornada para ir saindo do descritivo para o diagnóstico, pro predição para chegar ate o descritivo, só para ficar mais claro para o pessoal. Maria Eugênia: Acho que de fato mesmo, não tem essa receita de bolo, mas acho que você meio que já respondeu no seu comentário anterior, porque eu acho que o segredo é esse, testar, qualquer hipótese que eu tenha vou lá consigo medir, acompanhar isso, evoluir e testar, sempre pensar em métricas, no que é o objetivo do time ou da solução e pensar consigo medir isso? Isso faz sentido? E tentar metrificar nisso e a partir de análise descritiva por exemplo de como eu vejo como as coisas estão, eu acho que é natural, eu consigo pensar e enxergar oportunidade de evoluir aquilo. M1: Quais exemplos de análise descritivas? Só para ficar mais claro para quem está nos ouvindo, são gráficos, indicadores? Quando você fala análises descritivas o que exatamente você está falando? Maria Eugênia: A gente fala muito de visualização de dados nessa parte descritiva então muito gráfico, tabela, painéis de visualização de dados para deixar na mão ali da pessoa, um painel interativo que ela consiga filtrar por data e ver evolução do tempo, ver um gráfico, indicadores, ter todas essas métricas ali não dela. M1: Esse é o descritivo e o que caracterizaria o diagnóstico? Essa análise diagnóstica? Maria Eugênia: Diagnóstico seria eu entendo que isso está acontecendo, então por que está acontecendo? Ai pode misturar um pouco com a preditiva, mas neste momento a gente pode fazer teste estatístico então por exemplo eu sei que o volume de vendas caiu mas ele pode ter caído e não ser estatisticamente significante pode ser uma flutuação que ocorreu e eu posso fazer um teste para confirmar se aconteceu mesmo, mas já começa ser uma análise mais robusta, depois eu posso entrar de fato em modelagem, então eu entendo que a venda caiu porque, um outro motivo, uma outra variável que ajude a explicar. M1: Entendi, então André e Zé Renato, queria que vocês pegassem um exemplo, vocês tiveram a oportunidade de participar de um squad com o Andrezão desde o começo, que foi se movendo para ser orientada a dados, fale um pouco sobre isso por favor Andrezão para depois o Zé completar com a experiência mais recente. André Luiz: Esse é um squad que a gente atua a muito tempo com um cliente nosso em T.I e por ele já passaram várias pessoas, eu fui líder dele também e era um squad que hoje a gente considera que o time muito é maduro pelo tanto que a gente já é, a gente começou desde o início reformulou uma parte desse cliente, uma parte ligada a gente reformulou tudo, e a gente veio conhecendo muito das integrações de uma parte muito técnica desse produto mas até com essas iniciativas que a gente está tendo de promover e dar esse conhecimento do time, a gente percebeu que esse era um time que poderia começar a entender mais sobre o cenário atual dele baseado nos dados e poder criar insights para isso e agora que surgiu essa iniciativa, mercantilidade e essa forma de colocar na pratica mesmo e ai já foi o Zé Renato que agora é o líder do time que a gente aplicou junto com eles, e ele conhece hoje muito mais do cenário que eu, ele pode dar mais informações para gente. M1: Como é que foi isso então Zé? Você pegou o time bom e gradativamente foi mudando de um time que basicamente se orientava pela funcionalidade mesmo e agora cada vez mais ele se orienta hipótese embasada por dados, é isso? Zé Renato: Sim, a gente começou bem, mas trabalhando sob demanda mas acabou que a gente mudou a mentalidade foi tentar a ser mais orientado a dados, inclusive teve influência forte do time que entrou mais recente que tem essa mentalidade data driving mas o primeiro passo zero que a deu foi tentar pegar os dados do zero mesmo e montar no Excel para ter uma direção, mas para ficar mais claro, o processo que a gente trabalha se resume basicamente, a gente recebe algumas solicitações que tem alguns itens e uma pessoa analisa essa situação com os itens e pode aprovar ou reprovar ou mexer e negociar e aprovar essa solicitação depois da renegociação e a gente estava tentando automatizar alguns solicitações, algumas provações dessas solicitações, o primeiro passo a gente tentou por conta própria buscando direto na base de dados as informações a gente fez um pareto, agrupou os itens por volume, e vou citar o que mais chega aqui, o item A e vão tentar automatizar esse item primeiro para ver o que acontece e tem alguns itens que não dá por conta de regra de negócio que precisa de olhar a foto não dá para ser automático por enquanto, vamos pegar os mais simples e vai de cada negócio, que regras tem e colocamos lá e fomos ver o que estava acontecendo e ainda sim, começou a aprovar alguns itens mas mesmo assim alguns não aprovavam e também tinha o empecilho de sempre eu o desenvolvedor do time sempre quer que fazer esse trabalho de minerar os dados na unha. M1: O Zé, só um segundo, só porque eu fiquei tentando me colocar na posição do ouvinte e para casar o que a Maria Eugênia falou, ou seja, normalmente existia uma necessidade de negócio de automatizar essas aprovações. Zé Renato: Isso. M1: Normalmente, pensando em uma abordagem ágil gerar valor em longo e curto prazo, eu já não vou tentar automatizar tudo, eu não sei nem se consigo, aí alguém pensa assim, mas quais então? Esse quais vocês fizeram então análise descritiva, é isso Maria Eugenia? Uma análise descritiva para entender qual é o perfil de aprovações e etc e a partir disso começar autorizar a partir dessa análise descritiva. Zé Renato: Sim, é, começamos pequeno, justamente por isso, eu não vou autorizar tudo é impossível então vamos começar aqui, mas esses itens pequenos qual vai ter um maior retorno, por isso que a gente fez isso de ver um item só que eu vou (inint) mas ele representa um volume grande então vamos pegar esse item que vai me dar um score de negócio, dava para colocar suas regras específicas lá, vamos colocar e ver o que acontece, fizemos isso mas o passo antes dessa análise que a gente fez também ficava um pouco oneroso porque dependia de mim ou de outro desenvolvedor para buscar essa base para passar para a p.o para ela montar no Excel e montar os gráficos e chegar em alguma conclusão, acabava que era oneroso, ai a Maria Eugênia veio ajudar a gente no time, ela ajudou a gente a montar um dashboard aí pensando mais nessa linha que a gente tenta seguir do (inint) ficou muito melhor porque ele casa com esse raciocínio de ter sempre os dados avista e facilita o trabalho, automatiza a mineração desses dados, digamos assim e fica visível para todo time e você acaba democratizando esse conhecimento dos dados e ter opinião de todo mundo ao invés de ficar só na mão do p.o e todo mundo ver só quando ela apresenta na tela dela para gente e o dashboard acaba ajudando nessa parte de discussão e todo mundo ter acesso aos dados de forma mais rápida, e quando a gente estava tentando desenvolver, a Maria pode complementar também, ela conversou com a gente para tentar entender melhor o que a gente tinha que descrever porque só essa análise da quantidade de itens por volume foi bem simplista, então vamos tentar descrever o que está acontecendo depois dessa primeira ação, voltando um passo antes ainda, o sistema nosso de automação ele salva no banco os motivos da reprovação dos itens e a gente pegou e falou vamos ver o motivo de maior reprovação, mesmo eu configurando porque ainda está reprovando, a gente fez essa análise, ela colocou no dashboard também, você selecionar o item e ele agrupava por motivo de aprovação e a gente via o resultado, por exemplo um dos caso que a gente viu, o valor está acima do valor de referência e isso deu feedback para gente que não adianta nada eu fazer a regra aqui para provar sendo que quem envia a solicitação está colocando valor acima, isso acabou gerando ações para gente pensar em (inint) voltada no momento que houve solicitação, tem como eu induzir ele a colocar um valor menor ou criar algum processo da área de negócio dele já fazer uma negociação para esse valor, já vir sempre no padrão para eu poder aprovar no automático? Acabou que a gente teve essas ações que a gente está inclusive fazendo até hoje ainda, foi ativada depois desse feedback que é bem recente, essa análise e deu uma subida depois dessas ações graças a esses dados que a gente acabou estudando. M1: Isso que eu queria pergunta para a Maria Eugênia, imagina, existe essa questão então, preciso automatizar a aprovação dessas estações: “Eu quero fazer isso orientado a dados”, então precisa descrever os dados que eu tenho, mas como é o processo agora, quais dados eu uso, o que eu uso, e se tem coisa que eu nem sei que é importante, como é isso, o que quero visualizar. Maria Eugênia: Sim, muita conversa do time sempre falam que a parte mais difícil do trabalho de um cientista de dados quando ele chega em um projeto novo é entender o que é importante para o time e assim, dando continuidade no que o Zé falou, a gente fez esse processo inicialmente descritivo de ver quais itens são os mais frequentes, eles são automáticos hoje, sim? Não? Será que eu posso escolher um deles para automatizar e depois a partir dessa análise exploratória e descritiva, a gente até conseguiu avançar um pouco além da análise descritiva, foi tentar explicar um pouco mais e ajudar o time a priorizar e a gente acabou fazendo uma análise de correspondência, em termos mais leigos é como se fosse analise de carrinho de supermercado, que é entender que sempre que eu compro o item A eu sempre compro o item B, por exemplo, então não adianta nada eu automatizar o item A que é o de maior volume por exemplo sendo que ele sempre vem com o item B, então se eu automatizar o A eu tenho que automatizar o B, se não, não adianta nada, ai a gente conseguiu fazer esse tipo de análise e acho que ajudou também um pouco na parte de priorização. M1: Isso é bem interessante, porque sem essa parte estatística, você pode ficar ali frustrado que na verdade não está conseguindo aprovar nada, fazer outras coisas e daqui um tempão descobrir que existe uma correspondência que você não levou em consideração. Zé Renato: Exatamente, aconteceu isso também, o segundo passo, depois a gente analisou ainda se subiu um pouco mais ainda tinha outros fatores que ainda não subiu o quanto a gente esperava, a gente fez uma análise mais simplista, a Maria Eugênia fez essa correspondência, que é parecido com a análise de carrinho, que em site de compra geralmente tem, você compra e aparece que quem comprou isso também levou isso e tenta te induzir levar mais algum item mas nesse cenário a gente viu isso de aprovar solicitação, então não adianta nada aprovar um item da solicitação sendo que o outro você é reprovado, então eu configurei o item A para ser aprovado automaticamente mas ele vem junto com o item B que não aprova automaticamente, consequentemente a solicitação como um todo não é aprovada, isso ajudou bastante a gente levantar ações e voltando ao assunto da construção do dashboard, primeiro a gente fez essa divisão sem a correspondência e testando mesmo, a gente testou e viu que precisava dessa análise de correspondência, ela foi lá adaptou o dashboard e colocou mais essa outra análise de correspondência junto e como MVP a gente ainda não fez aquela data lake que processa os dados e transforma eles para ir direito, como a gente estava testando a gente não sabia ainda o que a gente queria ver, por exemplo, tinha um banco que era réplica, a gente leu direto essa réplica sem transformar os dados nenhum, acaba que a gente não consegue ver um horizonte de dados tão longe no passado porque acaba atrapalhando um pouco em performance mas conseguiu contribuir para gente tomar essas ações e conseguir definir o que a gente quer ver, se não, não seria ágil, começaria fazer de cara, replicar os dados, transformar e depois você ver que não era aquilo que você queria ver, aí fica para um passo para frente que a gente ainda não chegou, essa parte de definir tudo que a gente quer e partir para essa etapa de transformar os dados para melhorar a performance e ver o tempo mais longe. M1: Isso me traz uma dúvida que eu sempre tenho que é o que é o certo? Não sei se é o certo a pergunta, qual é a melhor forma de se agir, é já se partir de uma demanda, de uma necessidade de negócio, por exemplo e ir puxando os dados e eventualmente até chegar na necessidade de criar um data lake para satisfazer aquilo, ou eu primeiro penso, porque eu vejo muita abordagem no sentido contrário, você vai e começa criar um data lake vai jogando informação lá imaginando que alguém vai usar, ou são as duas coisa sabe, faz um pouco de uma, um pouco da outra, como é que é? Maria Eugênia: Bom, eu vou tentar responder um pouco então, acho que pode ter os dois casos, no caso do time do Zé a gente queria entender um pouco do contexto deles, era muito específico do time deles e a gente conseguia pegar os dados ali de forma mais rápida, do jeito que ele falou, existia um banco que a gente conseguia pegar e já analisar e fazer essa análise, é claro que depois, igual foi o caso, a gente identificou um gargalo, a gente queria um histórico mais de dados e talvez a gente precisasse de ajuda de um time de engenharia de dados para fornecer esses dados com histórico mais completo para gente e ai teria que passar por esse processo, um outro exemplo que a gente passou similar que o Zé relatou, um outro cliente, a gente passou por esse processo de construir parede de visualização e quando a gente queria expandir isso para todos os produtos, digamos assim do cliente, a gente viu que as fontes de dados não estavam centralizadas, organizadas e que existia de fato a necessidade de construir um data lake, então acho que as duas coisas vão casando, a gente vai enxergando oportunidade quando a gente começa a fazer as análises. M1: Acho isso bacana porque é o ágil em ação mesmo, porque você não precisa ficar ali um ano fazendo data lake e depois começar usar, você às vezes sabe que a informação é imperfeita ou limitada mas tenta tirar uma conclusão ali, com aquela conclusão você começa a gerar valor, mas você começa perceber que aquele é um caminho bom mas gostaria de explorar mais e talvez para explorar mais você começa a criar um data lake e assim começa a fazer sentido colocar outras fontes de informação, outras coisa. Maria Eugênia: E começa ficar ate mais fácil de justificar o porque eu quero construir um data lake talvez porque eu preciso dessa parte da engenharia de dados, porque eu quero responder, atender tal demanda, nesse sentido. M1: Ou seja, nesse case Zé Renato nós estamos usando, vamos dizer assim, dentro do que a Maria Eugênia falou, a parte descritiva é a parte diagnóstica porque a gente também consegue tirar conclusões desses dados, vocês enxergam a possibilidade de fazer a preditiva e prescritiva de alguma forma? Como é que é? Zé Renato: Ainda não, a gente está trabalhando para evoluir essa parte prescritiva e diagnóstica ainda, tanto que a gente está até pensando em rever agora essa questão da transformação dos dados para conseguir ver um horizonte maior e ter um diagnóstico ainda melhor do que a gente já tem hoje. M1: Curioso, eu imagino que deve haver um potencial gigante só na descritiva e diagnóstica porque é pouco utilizado, não é isso? Maria Eugênia: Eu acho que a prescritiva também é pesada de ter ficado meio que nessa escadinha como se fosse o ponto máximo, a gente consegue usar ela antes também, apesar de análise descritiva soar mais simples e a diagnóstica ali seria o segundo passo, o que a gente fez com o time do Zé, a gente conseguiu tomar ações e tomar ações prescritivas, de chegar para o time e falar, olha o próximo item a ser automatizado não deveria ser esse, então apesar de ser uma análise descritiva ou diagnóstica, não ser a preditiva ainda, o time já conseguiu tomar decisões, ajudou de alguma forma. M1: A sim, a prescrição não precisa vir de um modelo de predição, a prescrição pode vir do diagnóstico? Maria Eugênia: Não necessariamente, sim, tenho um outro exemplo se quiser que eu conte. M1: Aham. Maria Eugênia: Um outro cliente nosso a gente construir de forma similar um painel de visualização e o cliente tem vários parceiros comerciais, então hoje em dia com esse painel de visualização eles tem em mão, o time comercial, tem em mãos a conversão de cada parceiro comercial, então agora ele consegue saber a média de conversão de vendas é de 50%, porque o parceiro está apenas com 20%, ai o time comercial, por um dado que é descritivo, simples, é um percentual, ele consegue tomar a decisão de falar que vai ter um contato maior com a pessoa porque o parceiro está com a conversão bem abaixo do esperado, ele consegue tomar decisões a partir de uma informação que é bem simples. M1: Entendi, isso é curioso, teve outro episódio que a gente gravou sobre senha de dados, a Melissa falou muito isso, a boa visualização já faz uma diferença brutal, é o que o Zé Renato falou de ter gestão a vista etc, mas é engraçado se você explorar bem a própria visualização ela por si só já pode gerar ação, que é o caso que você falou. Maria Eugênia: Sim. Zé Renato: Sim, uma coisa bacana que rolou com a gente, comigo, como desenvolvedor, quando eu vi os dados na parte de valor, eu não tinha noção que valor era aquele, porque eu sempre via os itens separados quando ia testar alguma coisa, quando eu vi o volume acumulado do mês, é absurdo ver o volume de dinheiro que acaba sendo envolvido, então qualquer coisinha que você consiga melhorar ali, na escala da um retorno enorme. André Luiz: Zé, você falou um negócio interessante isso, como é que a gente fala muito do ágil mas tem muitas vitórias que tinham que ter ainda, eu falo a comunidade do agilismo, é extremamente comum o time ágil ficar ali em uma bolha sem nunca ter visto os dados, ele fica anos lai trabalhando fazendo funcionalidade e nunca foi sensibilizado dessa forma, esse exemplo que você deu é um exemplo que eu chamo de propósito na veia, hora que você vê aquele dado ali e vê a diferença que você pode fazer, o time tem um tanto de ideia e começa a pensar em um tanto de hipótese e começa a perseguir aquilo, mas muitas vezes o pessoal prefere que o time não pode ver o dado, ou que o time está perdendo tempo de ver o dado, ou o time tem que focar na funcionalidade, focar no backlog, você vê só de realimentar o time ele começa a aprender sobre o negócio e traçar suas hipóteses. Zé Renato: Sim, é como você falou, um negócio legal é que é realmente realimentado, porque por exemplo uma coisa que eu percebi também, é como você precisa puxar os dados para tomar decisão você acaba pensando melhor em como salvar os dados, se você está desenvolvendo um sistema e tem que salvar alguma informação, você já pensa melhor de como você vai salvar aquela informação que você foi puxar de novo, para você ter retorno da ação que você está fazendo, se o cara passa uma demanda e você só refaz e pronto, mas se você pensa que você tem que medir o valor que lá está gerando, você já pensa em como vai salvar os dados que aquela features está agregando no sistema para você ter o feedback sendo que features está gerando valor ou não, acaba que você realimenta para você desenvolver pensando no que vai medir. M1: Então Andrezão, observando isso porque imagina, isso é uma mudança muito grande na forma que o time é gerido na liberdade que o próprio cliente dá para o time porque o time tem que ter espaço para fazer essas coisas, isso que eu queria que vocês falassem um pouco, um time que é orientado a dados é tão (day trade dreams) ele pode ter até um backlog ali para refletir certas hipóteses, para traduzir as hipóteses em certas funcionalidades mas isso é de longe o mais importante, não é? André Luiz: Acho que o grande valor gerado por essa iniciativa nossa, é exatamente esse, o que o Zé falou dessa retroalimentação e do time começar olhar mais para isso, nesse time tem até algumas situações legais que aconteceram, foi que o Zé ficou, o time ficou sem p.o e o Zé ficou um tempo assumindo esse papel lá dentro, então ele já tinha uma certa mobilidade para pensar, mas era uma coisa que agente já estava engatilhando a muito tempo, porque a gente não estava (inint) baseado em dados, nessa data driven e depois que a gente começou com essa iniciativa, começou dar super certo, o time hoje é muito mais pautado por isso, então hoje surge uma features lá sem ela ser questionada se ela dá um resultado, primeiro baseado nos locais (inint) em si e segundo se aquilo está voltado para tangenciar o grupo por muito, essa parte dos dados que eles estão levantando, então eles ajudam muito porque o time começa ter autonomia legitimada, (inint) eles tem autonomia porque sabem o que estão falando e vão bater de frente com o pessoal do (inint), se eu atuar nisso aqui eu começo a gerar muito mais a economia, não é esse nosso (inint), então eles têm uma legitimidade já intrínseca ali porque já conhecem muito mais do negócio, não só tecnicamente por trás dos panos do que está sendo feito. M1: Sim, é o que o pessoal chama muito de restrição habilitadora, porque muitas vezes a liderança morre de medo de dar autonomia, fica parecendo que vai dar autonomia e vão fazer o que quiser, e na verdade existe algumas exceções que cria essas condições de contorno dentro do que você pode atuar e dentro disso você consegue atuar, a gente viu aqui como a ciência de dados pode ser usada de uma forma bem prática para fazer um time de data driven e vimos um exemplo de um time que ficou na data driven e conseguiu ficar, tanto pelo espaço que o próprio cliente, a própria estrutura comercial foi dando para que isso acontecesse, autonomia, liberdade, a vontade de ficar na data driven mas também por que ele seguiu um determinado método que lhe permitiu a ficar na data diven, para quem está ouvindo isso, Maria Eugênia, como é que eu faço? Como é que eu começo? Como que a gente fala que é agilista, não tem receita, mas qual é um caminho interessante que você fala que é um bom jeito de começar. Maria Eugênia: Passa por vários testes para chegar hoje e saber o que funciona melhor mas é aquela ideia de testar tudo, uma forma que a gente identificou assim como a gente tinha vários times que a gente queria orientar dados a gente passou por uma época que a ente mapeou a maturidade de dados em cada time, então a parte principal é sentar com o time e entender, a minha parte como pessoa que vai atuar em dados, então a primeira vez que cheguei no time do Zé, eu não tinha a mínima ideia do que era importante e do que eu deveria medir e da parte do Zé eu imagino que eles conheçam muito do negocio mas eles não sabiam como medir, então a gente precisava dessa troca então a gente fez esse mapeamento com vários times e no final a gente tentava resumir de uma forma que tinha três pilares, então o que o squad pode medir, ele sabe quais são as métricas, o que ele pode medir, o segundo pilar seria o que de fato ele mede e o terceiro pilar seria o que ele apresenta, e a gente fez essa conversa com vários time e a gente conseguiu entender quais estavam mais maduros, quais menos maduros, até a escolha de em qual squad a gente vai atuar agora, foi muito dessa iniciativa assim. M1: Que interessante você fez o processo de explicar data driven, data driven. Maria Eugênia: Sim. M1: É o meta data driven. Maria Eugênia: Não tinha pensado assim não. M1: Achei interessante, você fez uma análise descritiva de como o squad está em relação a ser data driven ou não. Maria Eugênia: Foi, isso mesmo. M1: Para poder fazer um diagnóstico para depois tomar uma decisão, fazer uma descrição (inint) Maria Eugênia: Isso aí. M1: Interessante, interessante demais, ou seja, o que pode ser medido, porque tem informações que ele nem consegue medir. Maria Eugênia: Sim, a gente passou por alguns times nessa parte de mapeamento que às vezes o time queria medir alguma coisa, sabia que era importante, mas não media, então passou a identificar que precisava colocar uma flag no sistema que quando acontecer tal solicitação vai marcar que aconteceu e vai conseguir medir, então teve esse processo também, de querer medir e não ter o dado, e ai dar um passo atrás, voltar e tentar começar medir. M1: Interessante, nossa eu gostei demais desse episódio gente, eu queria agradecer a presença de vocês, achei interessante demais porque a gente aqui na DTI gosta de ser extremamente pragmáticos e a comunidade acha que tem que ser pragmática, você vê, a gente fala em ciência de dado e um passo ai pode ser ter que mudar um banco de dados, um flag para poder a informação existir, quando determinado evento por exemplo acontecer, isso pode não ser sexy igual falar em marching learning mas pode ser a decisão que vai te permitir medir alguma coisa, que vai te permitir fazer análise de correspondência e talvez fazer a empresa economizar alguns milhões, então acho que é um jeito de colocar, eu sempre falo como eu sou um cara cético, eu gosto de sempre falar para os céticos, para os cético que ficam falando que esse negócio de ciência de dados está na moda, vocês vêm que da para ser extremamente pragmático e gerar muito valor, é calor na medida que avança a partir daquelas análises também. É isso aí pessoal, muito obrigado, abraço a todos. André Luiz: Valeu pessoal, abraço. Zé Renato: Valeu, obrigadão. Maria Eugênia: Valeu.  

Descrição

Ser data driven significa ter uma base sólida para tomar decisões, ao invés de partir de suposições. Essa base é formada por centenas de milhões de dados que podem ser coletados, tratados e interpretados para gerar insights valiosos nas empresas e o Data Science é um dos principais parceiros para torná-los úteis para uma empresa. Data driven é muito mais que uma buzzword: é o futuro dos negócios orientado a dados, mas afinal como que nós utilizamos a ciência de dados na prática e como nos tornamos data driven?

Newsletter