Essa é uma história sobre um projeto que visava a utilização de machine learning para cálculo de índice de rentabilidade por canal de forma automática e dinâmica.
Na equipe do projeto como um todo, não havia um cientista de dados – tínhamos engenheiros e analista de dados. No papel de analista de dados do projeto, pensei que seria ótimo ter um novo membro cientista de dados, pois isso renderia muitos aprendizados sobre como funciona este trabalho.
No início do projeto, tivemos a fase de entendimento das necessidades do cliente, onde todo o time, incluindo o cientista de dados, participou colhendo o máximo de informações com o cliente, suas necessidades, expectativas, o que já tinham na ocasião, etc. Após este momento, fomos para a fase de coleta dos dados necessários, e isso ficou sob minha responsabilidade como analista que já entendia como os dados do cliente estavam dispostos e funcionavam.
Em seguida, me reuni com o cientista de dados para falarmos sobre o problema que tínhamos – uma ótima oportunidade para aprender com alguém que é referência, e o melhor: em um projeto na prática. Conversamos sobre o problema, sobre a necessidade do cliente e onde encontrar os dados. A proposta dele foi trazer uma fórmula que faz o cálculo do índice de rentabilidade tradicional. Colhi todas as informações com base na explicação dele e desenvolvi uma view (via SQL) que realizava o cálculo informado e coloquei no Power BI para passar para o cliente validar de uma forma mais visual e dinâmica como haviam solicitado. Pegamos esta solução como nossa baseline do projeto (aqui cabe parênteses: na baseline, os dados já se encontram qualificados e podem ser utilizados em futuros ciclos para predições, prescrições, etc.)
Enviamos ao cliente a versão 1 e poucas horas depois já recebemos um feedback informando que o cálculo estava correto, mas estavam precisando de uma melhor forma de visualizar os dados. Pediram a adição de novos campos que permitissem filtrar a informação por períodos, canais de vendas, vendedores, lojas e produtos específicos. Tratamos a view para trazer as informações solicitadas, alteramos a visualização e, por fim, geramos uma nova versão (versão 2) da visualização e mandamos ao cliente. Aqui vem em mente o ciclo de feedback “construir-medir-aprender”, proposto por Eric Ries no livro Startup Enxuta, ou em outras palavras, faça rápido e erre rápido!
Durante nosso projeto, geramos a versão 1 com base em uma hipótese de solução, e enviamos ao cliente (construir), o cliente nos enviou um feedback com melhorias no visual e filtros (medir-aprender), fizemos os devidos ajustes e enviamos a nova versão (construir) ao cliente logo em seguida.
Até o momento, neste projeto tivemos 2 ciclos, mas esses ciclos podem ser constantes, varia muito dependendo do “problema” (produto), da maturidade do cliente no entendimento do problema e em como pode ser evoluído a solução.
“Aqui cabe uma frase e uma reflexão: Apaixone-se pelo problema e não pela solução! Lembram da KODAK? A empresa pensava na solução para registrar momentos importantes e recordações. Sabe a Uber? Eles pensam no problema de mobilidade urbana. E assim por diante.”
Em resumo, apresentamos ao cliente a solução. Eles validaram e os cálculos e estavam conforme precisavam, tiveram algumas solicitações de melhorias, mas apenas em relação a layout. Enquando isso, pensei sobre onde e quando iremos implementar machine learning, e qual algoritmo vamos utilizar.
Como descrito no início do artigo, tinha uma grande vontade de saber mais sobre como é o trabalho de um cientista de dados. Imaginava aprender a aplicar um algoritmo e ver uma predição no final, mas o que aprendi foi que devemos nos apaixonar pelo problema e não pela solução! Nem sempre precisamos aplicar algoritmos, técnicas e recursos estatísticos avançados, quando uma simples análise exploratória de dados, uma análise de dados simples, ou como foi no caso, uma fórmula, atende perfeitamente bem a necessidade. Porém, com a evolução da solução, vai haver a necessidade de aplicarmos machine learning e assim iremos aprender e praticar esses algoritmos de forma que consigamos medir a sua eficácia e meu aprendizado através da baseline que foi criada. A evolução foi do analista em conjunto com a solução, um jogo de ganha/ganha.
Isso é uma das skills de um cientista de dados, saber distinguir se numa determinada solução precisa ser utilizando análises avançadas, algoritmos, ou apenas uma análise de dados já atenda a demanda. Como comentado, com base nos ciclos de feedback, a solução tende a evoluir para gerar ainda mais valor ao negócio e em algum momento pode ser que seja necessário o uso de algoritmos de machine learning, por exemplo (ou seja, o machine learning aparece naturalmente, de forma orgânica).
O projeto também proporcionou um entendimento que a rotina construída nos últimos anos tem uma base teórica e consolidada (ciclo de feedback construir-medir-aprender). Para saber mais, recomendo o livro: A Startup Enxuta, de Eric Ries.
Por fim, cabe aqui mais alguns pontos importantes. Primeiramente, em muitos trabalhos e projetos que entregamos, recebemos excelente feedbacks e elogios, mas se eles (os projetos) não são utilizados no dia a dia, isso se torna uma métrica de vaidade. Então, sempre monitore a solução e evolua conforme necessidade do cliente. Outro ponto é que em dados, a medida é a utilização da informação pelo usuário. Comparado a um like de rede social, quanto mais a informação for usada, mais valor ela gera para a organização. E por último, mas não menos importante, a dica é não é sair por aí aplicando algoritmos de machine learning para qualquer problema, mas sim entender e encontrar a solução mais aderente e evoluir, seja ela com o uso de machine leaning ou com regras / fórmulas. E claro, sempre observando a aderência da solução com a necessidade do negócio.
