Guia para times de Big Data & Analytics
Como entregar produtos e não ser um gerador de relatórios
Na Oncase sofremos um bocando nesse ~11 anos de história com Big Data & Analytics (BD&A). No começo, fizemos muitos relatórios e éramos vistos como implementadores de BI, mas se resumia a meros geradores de relatório e cubos OLAP.
Era comum chegar em clientes e ouvir “Precisamos de um relatório de vendas” — lembre se que nossos clientes são bem corporativos — e que não existem nem os dados para tal relatório. Todos queriam a “cereja do bolo” — BI — e não tinham os dados (organizados).
Aprendemos muito nos últimos anos sobre gestão de produtos, Entretanto, os times de BD&A não são vistos como um “squad” de produto, mas apenas como um time técnico. Criar produtos de “sucesso” continua não sendo algo tão simples.
Quando se fala de produtos intensivos em dados — entenda como produtos de Big Data ou Inteligência Artificial — é ainda mais nebuloso. Os clientes mudaram a forma de falar, agora é “temos uma montanha de dados, sabemos que vale ouro”, mas não sabem como extrair esse valor. É cada vez mais comum escutar algo no gênero.
Em uma discussão na comunidade de produto, perguntaram como é “shipar” um produto intensivo em dados. Na realidade, não é muito diferente do que já existe para gestão de produtos, só para deixar isso claro, mas os times de dados não estão preparados para pensar assim.
Times se preocupam em entregar o “job do Spark”, uma consulta no Superset/Redash/Metabase ou subir um Grafana. Tem piores, que “só” pensam como vão atualizar/consultar mais rápido o cluster montado na AWS e não preocupado em resolver um problema do negócio.
Era necessário deixar claro os paralelos e as entregas de valores. Assim, dividi em duas seções: paralelos entre time de dados e time de produto; e formas de entregar mais valor de negócios em suas entregas.
O processo de gestão de produtos intensivos em dados
A preocupação não são as entregas — leia-se valor para o cliente — e sim com a técnica. Simplificando para traduzir para a gestão de produto tradicional, pense:
- Data viz → frontend
- Data engineering →backend
- Data Science/machine learning → diferenciação via algoritmo (a la busca do Google ou feed do Facebook)
Pronto, como o paralelo fica bem mais simples de pensar como ajustar a uma cultura de produto. Não se esqueça que em gestão de produto você precisa se preocupar com coisas como sucesso do cliente , onboarding, entender o cliente/usuário, churn, ciclo de vida do produto e por aí vai. Claro, vai haver momentos que a apresentação vai ser diferencial ou até mesmo a performance do produto, mas a priori não é.
Por exemplo, produtos iniciais vão estar preocupados com um algoritmo que funcione e que seja apresentado de forma útil, pode até demorar para processar se o valor da entrega for maior que a espera. Quando o foco passa a ser eficiência do produto, normalmente é quando a entrega de valor já está mais madura, aí passa-se a se preocupar com performance.
Na Oncase decidimos mudar nosso mindset para produto tanto da nossa área de serviços, como em entregar produtos open source. Hoje focamos entregar valor com algo não escalável para nossos clientes a princípio. Assim, vemos o que é replicável e que já se usou em alguns clientes, isolamos e disponibilizamos no nosso Toolkit.
Temos vários “pequenos produtos” que podem ser considerados features, mas isso já aprendemos que muda constantemente — vide a Siri para a Apple. Quando uma empresa adquire outra, passa-se a ver o produto apenas como uma feature do seu produto ou do portfólio da suite.
Assim, sempre pensamos que esse pequeno repo pode ser algo importante para muita gente, por exemplo, o Tapa, um projeto relativamente simples desenvolvido pelo Marcello Pontes e que já foi baixado dezenas de milhares de vezes — no mundo de BD&A isso é um bocado!
Agora estamos em um momento de consolidação dos nossos repos e vendo o bundle que mais se repete nos nossos clientes. Com isso, juntamos por funcionalidade e alteramos para se tornar produtos com entregas de valores maiores, facilitando a vida de quem implementa. Claro, tudo open source ❤.
O código aberto não é só apenas por acreditarmos nesse modo de desenvolvimento, mas também por ser comum na indústria de BD&A. Foi a forma que a área entrou em grandes clientes corporativos, pois passa confiabilidade da ferramenta e não “deixar o cliente na mão” se o projeto for descontinuado.
Um exemplo desse bundle é o nosso Tarantulla que está juntando todas as nossas formas de obter dados não estruturados. Pegamos a forma de coletar dados da web, facebook, twitter e youtube e colocamos tudo em um único produto. Além deste, outro bundle é o nosso Scora, no qual juntamos tudo que é necessário para se gerenciar fraudes e não ser “apenas” mais um algoritmo de detecção de fraude. Ou seja, nos preocupamos com as visualizações, possíveis formas de análises e, claro, os algoritmos.
O que o time pode entregar
Outro problema comum que vemos: o time de dados não sabe o que entregar. O entregável sempre se pensa em jobs, query ou relatório. Para nós, ficou claro como entregar algo de valor através de alguns tipos de entregas e focamos nessas entregas, pois vemos que resolvem problemas de negócios.
Pense como três grandes grupos de entregáveis. O time pode entregar:
- API/Enriquecimento de dados
- Widget/Dashboard
- Solução Analítica
API/Enriquecimento de dados
Para algoritmos de machine learning é fácil entender como criar um script e gerar uma api. Esta API pode ser gerada de algum framework web e subindo tudo pra uma “cloud” e usar uma API Gateway, como por exemplo pode ser visto aqui.
Depois de disponibilizar é necessário manter e estar preocupado com taxa de uso, sucesso do uso, qual o problema que está se resolvendo, etc. Isso é algo muito comum de ver os times de produto falhando. Após a entrega, eles não se sentem responsáveis por manter o serviço e melhorá-lo sempre, ou seja, manter updated e focar no sucesso do cliente.
Widget/ Dashboard
Este entregável substituiu o “gerar relatório”. Cada vez mais a área de negócios deixa de lado os Crystal Reports da vida e passam a pedir dashboards (near) real-time. Com isso, o paralelo de data viz com criação de front-end fica mais palpável.
Normalmente cria-se alguns widgets/dashboards e envia para o cliente embedar, com o Google Data Studio, Tableau, Klipfolio ou — se tiver uns cientistas de dados no time — usando o Shiny.
Tipicamente tanto este, quanto as APIs, são entregáveis os quais fazem parte de um produto maior e tal entrega se trata de uma feature de outro produto. Assim, é importante se entender como um time que entrega uma feature que faz parte de um produto maior e não achar que após a entrega, está resolvido e não preciso me preocupar com o todo.
Soluções Analíticas
Já para sistemas analíticos, vemos muitos times cometendo erros clássicos de gestão de produto. Principalmente, pensar em várias features, desenvolvê-las antes mesmo de descobrir o valor real o qual entrega. Isso é bem comum — e já erramos MUITO isso.
Por conta disto, criamos o Oktopus. Por exemplo, na NZN precisávamos entregar valores aos poucos ao Cassius — quando dois times de produto trabalham junto é lindo! — e criamos o Oktopus para poder modular as entregas, sem precisar alterar, usando diversas ferramentas analíticas — tem PowerBI, Pentaho, Shiny e Databricks — mantendo a segurança por perfil de acesso.
Assim, encaramos cada entrega como um item do menu, sendo cada uma nova feature. Cada uma foi entregue na forma dos dois outros grupos de produto e podem ser atualizadas separadamente. Esse bundle é que deu origem ao Cassius, uma solução analítica para o mercado de publishers.
Já nas outras duas formas de produto, encara-se como uma entrega de um produto invisível. Logo, fica mais simples seguir o fluxo comum de gestão do produto.
Ou seja, isso não é “rocket science”
Um grande problema de time de dados é: em casa de ferreiro o espeto é de pau. De modo geral, poucos projetos de BD&A se preocupam com o próprio analytics e muitas vezes não é nada simples implementar em projetos open source — algumas vezes já tivemos que fazer por análise de logs do banco de dados.
Muitos veem produtos intensivos em dados como “rocket science” e esse texto é para tentar desmistificar isso. Como a Isa Silveira fala na apresentação da imagem, criar uma API com machine learning não é mais um grande desafio para um desenvolvedor.
É comum features intensivas em dados serem parte de um produto maior , isso é uma realidade— qual produto não tem um dashboard? Ou machine learning por trás hoje? — e vejo muitas softwares studios/times de desenvolvimento tendo que se preocupar cada vez mais com problemas que envolvem BD&A dentro de um projeto.
Entretanto, o que é feature e produto, só depende do uso e muitos produtos têm PMs alocados em features. Logo, pense como entregar valor com os dados , ou seja, qual problema esse entregável resolve e não pense em “preciso de uma relatório para [preencha aqui qualquer sumarização de dados]”. Torcemos para deixarmos de ver essa falta de mindset de produto em times de BD&A.
