Produtização de dados: benefícios e desafios
Produtos de dados são trabalhosos e exigem estratégia, mas tornam os entregáveis da Ciência de Dados mais tangíveis e permitem que a área agregue oportunidades ao negócio
Produtização de dados é um tema quente da Ciência de Dados em anos recentes. Seja no âmbito de negócios, seja em relação à formação de profissionais da área, seja nas descrições de vagas de data scientists, a expressão tem aparecido cada vez com mais frequência, como uma necessidade e um requisito.
Agora que startups e empresas já têm alguns anos de dados gerados, menos ilusões com big data e alguma maturidade no aproveitamento de analytics, é natural que comecem a pensar em como tornar tudo isso mais tangível e melhor aproveitado para o negócio.
Neste artigo, vamos:
traçar uma visão geral do que é a produtização e do que são produtos de dados;
apresentar os benefícios à própria Ciência de Dados e ao negócio — especificamente, tornar os “entregáveis” da Ciência de Dados mais administráveis e gerar oportunidades de melhoria e até receita ao negócio;
comentar sobre os desafios que isso impõe, como dispor de bons dados, contar com infraestrutura e engenharia de dados, ter uma estratégia, um time e gestão de produtos de dados e desenvolver uma cultura de dados.
A ideia é que o texto seja uma introdução ao tema e possa servir de base a possíveis artigos futuros a respeito.
Overview
Produtização de dados é, em resumo, a criação de produtos de software que usam ou se baseiam em Ciência de Dados (o que inclui estatística, machine learning e visualização de dados) para que humanos ou máquinas possam realizar tarefas ou atingir objetivos.
DJ Patil, famoso por ser o primeiro cientista de dados-chefe do governo americano, ainda na gestão Obama, e autor, entre outros livro, de Data Jujitsu: The Art of Turning Data into Product (em tradução livre, “Data Jujitsu: a arte de transformar dados em produtos”, é um pouco mais sucinto:
“[...] para mim, uma boa definição de produto de dados é um produto que facilita um objetivo final por meio do uso de dados” — DJ Patil, KDNuggets, 2012.
É claro que uma definição cabal e incontestável seria pretensiosa, se não fosse impossível. Resumos sempre deixarão muitos aspectos de fora, mas podemos nos deter em alguns deles.
Para fins de senso comum, não será pecado ou crime dizer que produto de dados é um aplicativo ou site com dashboards que exibem indicadores e gráficos automatizados na tela. Ajuda a dar uma noção ao menos visual do que se trata. Até porque é o exemplo mais disponível. Mas, obviamente, pode cristalizar a definição apenas nessa ideia.
De forma mais detalhada e, mesmo assim, certamente incompleta, podemos expandir a compreensão de produtos de dados para:
uma API que fornece um serviço de estatística ou de machine learning (basicamente, previsões, descrições ou inferências), para ser consumido por humanos ou por máquinas;
uma interface que permita que humanos consumam dados quantitativos com mais eficiência e eficácia;
um sistema, programa, aplicativo ou qualquer produto de software que agregue estatísticas e machine learning no back-end (lógica) e/ou no front-end (interface).
No artigo “Designing Data Products”, de 2018, Simon O'Regan lista exemplos de produtos de dados pelos seguintes tipos: dados brutos, dados derivados, algoritmos, suporte à decisão e tomada de decisão automatizada. É uma abordagem interessante, entre as várias possíveis.
Produtização de dados, nessa mesma linha, poderia ser entendida como a ação de fazer com que descrições, análises e previsões quantitativas sejam consumíveis por humanos ou por máquinas.
Mais relacionado a big data, há um conceito de produtização de dados mais no sentido de “data as a product” (dados como produto). Mas isto seria como vender dados brutos ou dados derivados e não como usá-los na construção de soluções viabilizadas por software.
Um software que fornecesse esses dados em tempo real ainda seria um produto de dados, mas os dados em si são como commodities, matéria-prima.
O artigo “Data as a product vs data products. What are the differences?”, no Towards Data Science, aprofunda essa discussão.
Em relação à prática, é interessante perceber que produtos ou produtização de dados são bons conceitos que conectam o “espectro da análise” (aberta, exploratória, que lida com incerteza) ao “espectro da engenharia” (focada em projetar, construir e manter artefatos delimitados), que explanamos em “Um modelo mental para Data Science entre Análise e Engenharia”.
De fato, produtos de dados demandam tanto tarefas relacionadas à análise e construção dos modelos preditivos, descritivos ou inferenciais, quanto competências do desenvolvimento do software, do design de interfaces (UI Design) e até do design de experiência do usuário (UX Design), bem como a gestão de produtos, como veremos.
É possível uma longa problematização dessas tentativas de definições e exemplos, até porque o conceito ainda é novo e está sendo maturado. Mas isso deve bastar para uma visão geral rápida e introdutória do que são produtos e a produtização de dados.
Benefícios
Dependendo do contexto da organização em que se está, pode haver vantagens específicas em relação a um produto de dados. Aqui, porém, apresentamos três vantagens amplas que produtos de dados fornecem tanto a profissionais da Ciência de Dados como ao negócio:
entregáveis mais tangíveis aos data scientists;
impulso à cultura de dados no âmbito interno do negócio;
oportunidades de receita no âmbito externo.
Entregáveis tangíveis
O primeiro benefício que produtos de dados fornecem diz respeito a data scientists e a seu trabalho no dia a dia. Produtização de dados é, basicamente, uma forma de tornar os entregáveis da Ciência de Dados mais tangíveis, mais delimitáveis, mais “objetivos”.
Explicamos. No cotidiano, ainda é comum data scientists estarem envolvidos com tarefas ad-hoc, isto é, realizadas localmente (em sua própria máquina) e para uma finalidade de momento, não para a construção de um artefato (dashboard, API etc.) e sua permanência e persistência no tempo.
O exemplo mais claro disso são as análises exploratórias para fins relatoriais ou de apresentação, um trabalho mais de “analytics” ou de Business Intelligence (BI), digamos. Talvez se esteja buscando conhecer uma informação sobre a qual apenas se tem suposições e intuições, para a qual ainda não há dados automatizados exibidos em um dashboard, por exemplo.
O cientista de dados irá passar bastante tempo na coleta, limpeza e exploração dos dados para extrair deles pequenas informações úteis e acionáveis, talvez algum indicador que possa estampar uma apresentação ou dados quantitativos que embasam contextualizações em um relatório gerencial.
O objetivo aqui não é construir nada robusto nem sustentável em termos de código e de análise. O foco está mais em agilidade e insights, que até podem vir a subsidiar alguma automatização futura, mas que não vêm ao caso naquele momento.
Na prática, o código construído não rodará em produção, para consumo de outras pessoas ou máquinas. Ele não precisará ser mantido, a não ser para fins de histórico ou de consulta posterior. É algo que “morrerá” com a conclusão da tarefa.
Muito desse trabalho não raro é difícil de quantificar, prever, sequenciar em etapas e administrar. Não é linear, envolve muita incerteza e pode demandar muito mais tempo com idas e vindas do que para um propósito mais estruturado e objetivo.
Obviamente, análises exploratórias ou experimentos em dados desconhecidos ou poucos conhecidos não escaparão a isso. O problema é acabar usando demasiadamente essa abordagem, de Ciência de Dados ad-hoc, para tarefas que poderiam se tornar “entregáveis” na forma de um dashboard, de uma API, de alguma rotina automatizada que possa ser integrada a um software em produção.
Produtização de software pode nortear e aproveitar melhor o trabalho de data scientists, em colaboração, muito provavelmente, com outros profissionais, como engenheiros de dados e desenvolvedores de software.
Um produto de dados ajudará a delimitar o que deve ser descoberto e, principalmente, o que será construído e como construí-lo. Certamente, não gerará um mapa e um documento de requisitos para que isso seja feito perfeitamente. Software sempre envolve incertezas e requer melhorias contínuas e incrementais.
Entretanto, pensar em um produto de software fornece um raciocínio muito mais de engenharia, de estruturação e construção, de algum planejamento e design (no sentido de pensar e projetar algo), para que ideias se transformem em artefatos úteis e utilizáveis.
Isso permite tornar o trabalho, dentro do possível, um pouco mais previsível e administrável, com ao menos alguma noção de andamento e de onde se quer chegar.
Diferentemente de uma análise ou experimento puro, também, o produto de software cria a necessidade de se estar sempre olhando e cultivando aquele artefato, o que ajuda em sua correção e aprimoramento.
Além disso, permite o acréscimo de novas funcionalidades dentro de uma estrutura já pré-estabelecida, sem ter, a cada abordagem, de se recriar a roda do zero.
É claro que tudo isso dependerá de desafios, como veremos. Mas produtos de dados, mesmo que simples, podem delimitar melhor o escopo do trabalho a ser feito por cientistas de dados, uni-los em torno de padrões e especificações e fazê-los trabalhar em colaboração com outros especialistas, como desenvolvedores de software, designers, entre outros.
Talvez lhes forneça aquele quadro maior ou algum “propósito” que às vezes é difícil de captar em tarefas rápidas e isoladas, assim como pode fazê-los engajarem-se em torno de metas e resultados mais mensuráveis e nos feedbacks que o produto proporcionará.
Impulso à cultura de dados
Um segundo benefício de produtos de dados diz respeito ao âmbito interno do negócio. Produtos de dados podem fazer a Ciência de Dados aparecer à organização.
Pode levar outros profissionais, de áreas técnicas ou não técnicas, a se interessarem, se envolverem e compreender melhor a lida com dados, a mentalidade analítica e, em um plano maior, as vantagens de uma cultura de dados.
À medida em que facilitam e/ou automatizam insights e decisões, esses produtos eliminam etapas burocráticas do trabalho de outros profissionais e passam a fazer parte do dia a dia, não raro de forma indispensável e permanente.
Em casos mais avançados, produtos de dados podem levar a uma linguagem comum em torno de indicadores e métricas de negócios, maneiras de analisá-los e, também, às restrições que o trabalho analítico naturalmente envolve. Ou seja, pode desmistificar e facilitar o trabalho da Ciência de Dados.
Não que produto em produção seja garantia de sucesso. Produtos de dados trazem complexidades adicionais à equipe técnica, pedidos de features (funcionalidades) por parte do negócio, ajustes, reclamações tanto objetivas como subjetivas.
Podem levar a equívocos e falhas de negócio, se problemáticos em sua concepção, construção, manutenção e monitoramento.
Em última análise, contudo, até pelo que proporcionam e por sua impessoalidade (não é alguém ordenando, é o software indicando), produtos de dados podem funcionar como fontes de “verdade” no negócio e engajar profissionais em torno de dados de qualidade, governança, enfim, a, como já dito, uma cultura de dados.
Oportunidades de receita
O terceiro benefício amplo da produtização de dados é a chance de a Ciência de Dados agregar ainda mais valor ao negócio do que rotineiramente já faz.
Como? Gerando um produto relacionado ou completamente diferente do core do negócio, que possa ser adquirido por pessoas ou empresas externas, por exemplo.
Um exemplo banal seria uma plataforma de entrega de comida, que conecta restaurantes, motoristas e clientes, fornecer uma solução de administração de estoque aos restaurantes com base nos dados de venda que obtém deles.
Outro exemplo, já fora do core do negócio, seria o fornecimento de um produto de geolocalização, com base nas rotas de entrega, para outros serviços de transportes.
Um produto de dados tem essa possibilidade de se descolar de um negócio existente e dar origem a um novo negócio à parte, quem sabe muito promissor.
Desde soluções gratuitas e de código aberto que alguns players entregam ao mercado até o império de computação em nuvem que a Amazon construiu a partir de seus servidores ociosos de e-commerce, exemplos de produtos de dados de sucesso não faltam.
Essa visão e atuação exige, é claro, times à disposição, ambiente voltado à experimentação e lançamentos de projetos paralelos.
É um diferencial, porém, que pode agregar muito valor, principalmente a negócios em crescimento rápido ou que já atingiram estabilidade, onde a inovação fica mais complicada.
Algumas startups e empresas certamente adorariam ver novos produtos promissores nascer de iniciativas de seus próprios profissionais, às vezes como projetos paralelos e despretensiosos mesmo, mas com foco em explorar problemas e oportunidades do mercado em que há boa demanda e pouca concorrência.
Desafios
A segunda parte do artigo trata dos desafios, que não são poucos, para a produtização de dados. Cada requisito listado é como um degrau para o que vem a seguir. No fim, todos se relacionam como uma lista circular.
É claro que pode haver produtos de dados em que nem todos os pontos tenham de ser contemplados. Produtos robustos, porém, certamente exigirão essa combinação de fatores.
Ter dados, e de qualidade
O primeiro desafio para qualquer produto de dados é, obviamente, ter dados, e de preferência de qualidade.
Desconsideremos a situação em que não há dados, porque aí nem negócio teremos (ou estaremos falando da quitanda em que o dono anota o “fiado” à mão ou “de cabeça”).
Quanto a dados de qualidade, muito provavelmente dados ruins, com falhas, muitos registros ausentes e outros problemas, resultarão em produtos de dados também ruins.
Startups e empresas que já acumulam alguns anos de mercado já possuem dados acionáveis, alguns provavelmente alimentando pequenos produtos de dados.
Esta situação é um ponto de partida em direção a produtos simples, mas que podem se tornar robustos no futuro, com maior potencial interno ou até externo.
Mesmo que não haja toda uma infraestrutura e engenharia de dados como em grandes startups e empresas, alguma base de dados de qualidade que o negócio já cultiva pode servir para que data scientist se aventurem em criar alguns dos primeiros produtos de dados da organização.
Isso pode acelerar os benefícios descritos na seção anterior, principalmente um melhor trabalho dos profissionais de dados e uma melhor compreensão e envolvimento das demais pessoas do negócio.
Dados verdadeiramente de qualidade, de qualquer forma, irão depender de infraestrutura e engenharia de dados estabelecidos (o próximo tópico) e do topo (ou base) da lista, que é a cultura de dados.
Produtos de dados, mesmo que prematuros, também podem despertar empresas para a necessidades desses aspectos.
Ter infraestrutura e engenharia de dados
Infraestrutura de dados é toda a parte de máquina em que dados são capturados e armazenados e a partir da qual são consumidos. Hoje, é muito comum usar-se data warehouses e data lakes baseados em nuvem para isso.
Em contextos mais avançados, é algo que requer grandes investimentos, cuidados com segurança e outras atenções. Normalmente, estabelecer e contratar isso diz respeito a decisores de negócios. A técnicos, cabem mais operações e avaliações das ferramentas.
Engenheiro de dados, profissional bastante requisitado em startups em crescimento, é o profissional que em geral trata de construir, operar e manter a infraestrutura de dados do negócio.
São fundamentais quando o negócio passa a lidar com big data (grandes quantidades de dados), distribuídos em vários bancos ou fontes de dados, que precisam ser integrados e relacionados para serem usados por cientistas de dados ou pelos próprios produtos.
Produtos de dados robustos, consumidos por muitos usuários em tempo real, terão exigências críticas de disponibilidade de dados, velocidade, entre outras características.
Infraestrutura e engenharia de dados serão essenciais para atender esses requisitos. Do contrário, o produto provavelmente não funcionará corretamente. Travará, gerará erros, será um produto de dados de má qualidade.
Ter estratégia
Estratégia é um conceito difícil de intuir e mais difícil ainda de praticar. É amplo e ambíguo. Porém, sem estratégia definida, é bastante complicado construir produtos de dados que serão úteis, entregarão valor a usuários e ao negócio e se manterão relevantes a longo prazo.
Para um produto de dados, estratégia tem a ver, primeiro, com definir uma visão, um “propósito” para o que se busca construir. Pode ser algo como “fornecer previsões de vendas mais assertivas aos analistas internos”.
A partir disso, é interessante haver resultados que devem ser perseguidos pelo produto, algum tipo de indicador que permita saber se ele está no caminho certo. Em relação ao exemplo citado, pode ser um percentual de vendas acima de uma taxa dinâmica já praticada.
A partir disso, há necessidade de “ideação”, ou seja, do processo de design para a concepção do produto. Isso pode (em vários casos, deve) demandar conversas com usuários do produto, principalmente se ele se destina a humanos, embora também valha conversa com técnicos se ele for uma API.
Por fim, há a construção, testes e implementação do produto em produção, e todo o trabalho que decorre a partir daí, que é o refinamento, a melhoria contínua e iterativa e o monitoramento do desempenho do produto.
Este é um resumo da estratégia e de seu desdobramento, é claro. O tópico é muito amplo e vale considerar ter um time com conhecimento e chamar um product manager (gestor de produtos) para conduzir toda estruturação.
Atualmente, já existem os data product managers, gestores de produtos especializados em produtos de dados, que podem ajudar com esse trabalho, o qual é um tanto árduo e contínuo.
A estratégia é essencial para que não se gaste tempo criando produtos sem “pé nem cabeça”, irrelevantes ou que apenas seus criadores (talvez um ou alguns cientistas de dados) achem sensacionais, mas que ninguém entenderá, usará nem gerará benefícios ao negócio, muito menos qualquer possibilidade de receita.
Ter time e gestão de produtos de dados
Produtos mais robustos e uma maior quantidade deles exigirá times dedicados, provavelmente não apenas com data scientists, mas com desenvolvedores, engenheiros, devops, entre outros profissionais.
Aqui, estamos falando, em geral, de startups e empresas muito mais maduras em relação aos dados.
É provável que esse time acabe funcionando como outros da startup ou empresa, já no modelo de squads (esquadrões), que normalmente contam com desenvolvedores, um gestor de produtos e um designer.
Isso demandará que cientistas de dados que participem do produto saibam se relacionar com esses outros profissionais e trabalhar muito mais alinhados a uma estratégia, a indicadores de resultados e outras práticas que fogem apenas à Ciência de Dados.
É nesse contexto que entra o data product manager de que falamos. Esse gestor de produtos será como um elo entre o negócio (o “viável”), o design (o “desejável”), se o produto tiver interface para humanos, e a tecnologia (o “possível”), onde entram data scientists e desenvolvedores.
O gestor de produtos e uma cultura de gestão de produtos fará diferença na estruturação e manutenção deste produto ao longo do tempo. Hoje, já existem data scientists experientes que migraram para essa função, onde atuam na liderança de produtos de dados.
Além de conhecer sobre Ciência de Dados e Machine Learning em geral, é necessário que esse profissional tenha visão de negócio e de gestão do produto para que ajude a descobrir e entregar soluções com chances de se tornar produtos de referência.
Ter cultura de dados
Esse tópico poderia vir tanto no início como aqui no fim da lista de desafios. Desenvolver uma cultura de dados em uma organização não é tarefa trivial nem previsível.
Isso envolve que todos na organização, do CEO (talvez até investidores e acionistas, onde for o caso), até quem entrou ontem na empresa, sejam orientados por dados, tenham alguma capacidade analítica, entendam a importância dos dados e porque quase tudo gira em torno deles.
Cultura de dados tem a ver tanto com essa educação interna como com padronizações e marcos relacionados, como governança, proteção e segurança de dados.
Até há pouco tempo, isso só era visto em grandes corporações. Com a Lei Geral de Proteção de Dados (LGPD), mais organizações estão tendo de se adequar e têm dado mais atenção a estes aspectos.
Produtização de dados de uma forma profissional, voltada a clientes externos em larga escala, por exemplo, como fazem grandes soluções como um Airtable, uma h20.ai e várias outras startups como as que listamos em “O cenário das startups de IA no Brasil e no mundo” dependerão de uma cultura de dados madura, capaz de fornecer a base para o funcionamento de todos os pontos anteriores.
Considerações
Como dito, essa é uma visão bastante introdutória e resumida do que é a produtização de dados, seus benefícios e desafios, o que nos ajuda a avançar com o assunto em eventuais artigos futuros a respeito.
Aprofundar cada tópico listado certamente demandaria um livro. Mesmo assim, como o assunto é bastante novo e está em desenvolvimento tanto na comunidade de Ciência de Dados como de Produtos, provavelmente seria um livro que logo estaria desatualizado.
O que é interessante reter é que a produtização de dados tem tornado mais tangível as entregas da Ciência de Dados, além de ter feito o trabalho dela aparecer e ser disseminado dentro de startups e empresas.
Em outras frentes, tem entregado valor tanto interno quanto externo aos negócios. A impressão, principalmente no Brasil, é que produtos internos parecem prevalecer no momento, fornecendo insights e apoio à tomada de decisão a outros profissionais de negócio, enquanto produtos externos ainda estão mais concentrados em empresas voltadas a soluções de analytics e Inteligência Artificial (IA).
O ciclo de descoberta e desenvolvimento de produtos de dados também é algo que aproxima a Ciência de Dados dos times de produto e da cultura de produtos, que hoje move o mundo das startups.
Em um nível mais avançado, a produtização de dados faz a Ciência de Dados não ser só um silo dentro de organizações, mas ser ver distribuída em todo o contexto e evolução da empresa, principalmente em todo seu ciclo de crescimento.
Para ir além, alguns artigos que podem ajudar a aprofundar ou fornecer mais insights sobre o conceito de produtos e de produtização de dados são:
“Designing Data Products”, de Simon O’Regan, 2018, já citado;
“Defining a Data Product”, de Joey Jablonski, 2021;
“The Age of the Data Product”, de Benjamin Bengfort, sem data;
a parte intitulada “What Is a Data Product?”, no capítulo do livro “The Age of the Data Product - Data Analytics with Hadoop”, de Jenny Kim, disponível na O’Reilly;
“What's a Data Product?”, de Kevin Le, 2019;
“Define: What is product data?”, DiffBot, 2018;
“What are data products?”, o debate no Quora em torno do assunto;
“The Fundamentals of Building Better Data Products”, Chistopeh Tempich, da Mind The Product, uma comunidade de gestão de produtos, 2018.
Apesar de já o ser em algumas organizações, é muito provável que a produtização de dados se torne um conceito rotineiro e muito disseminado nos ambientes de inovação nesta década, com o crescimento do analytics, do Machine Learning e da IA nos negócios.
Talvez, o conceito acabe por fornecer até novos padrões para a atuação da Ciência de Dados nas organizações. Por conta disso, é algo que vale ser estudado e acompanhado de perto.
Se ainda não é tão simples construir e manter produtos de dados, pelo menos ter uma visão geral sobre o assunto talvez seja uma boa maneira de começar a mudar o cenário.
Artigo escrito por Rogério Kreidlow, jornalista, que gosta de observar a tecnologia em relação a temas amplos, como política, economia, história e filosofia.