Um modelo mental para Data Science entre Análise e Engenharia
A busca por conhecimento e vagas em Ciência de Dados compreendida dentro de um espectro que vai da exploração na incerteza à construção de certeza
Quando começamos a nos interessar por Ciência de Dados ou iniciamos a busca por vagas na área, a sensação é de nos depararmos com um iceberg: claro e reluzente na superfície, mas desconhecido e, às vezes, amedrontador, nas profundezas. É fácil cairmos naquelas dúvidas óbvias, mas que só levam à ansiedade e a poucos avanços.
Quanto de estatística é preciso dominar para ser Cientista de Dados? É preciso ter habilidades de desenvolvedor de software sênior para conseguir uma vaga? Nem background matemático mínimo tenho, como começar do zero? Como dar conta de aprender a programar, passar por toda a matemática necessária para a estatística e ainda lidar com a confusão entre Machine Learning, Deep Learning e Inteligência Artificial?
Como o iceberg, a parte visível pode parecer até sedutora, mas a porção submersa pode ser frustrante. Mesmo após avançar no aprendizado, colocar alguns projetos no Github e divulgar o portfólio, ainda há incertezas sobre os ambientes em que iremos trabalhar, o que vamos fazer de fato e quais resultados serão esperados.
Um modelo mental que pode ajudar nos estudos, na aplicação para vagas e na evolução da carreira é entender a Ciência de Dados em um espectro entre Análise e Engenharia.
O modelo, obviamente, não fará aprender Python mais rápido ou dominar regressão logística em algumas horas, mas pode ajudar quanto ao que priorizar no aprendizado, a quais vagas procurar e o que observar nelas, além de nos permitir um melhor fit pessoal, profissional e cultural com startups e empresas.
Double diamond, discovery e delivery e afins
A Gestão de Produtos utiliza os termos “discovery” (descoberta) e “delivery” (entrega) para conceituar dois momentos do desenvolvimento de produtos digitais. Cada um desses momentos requer estratégias, táticas e operações — e mentalidades — diferentes para serem executados com eficiência.
Da mesma forma, no Design, com o Design Thinking, é utilizado o Double Diamond (Duplo Diamante) como um artefato mental para pensar nas fases de descoberta e definição de um problema (ideação) e de elaboração e entrega de um protótipo de solução (prototipação).
Em relação a negócios, de forma mais ampla, esta abstração também se encaixa na dualidade “problem space” (espaço do problema) e “solution space” (espaço da solução), duas expressões que têm se popularizado em ambientes de inovação.
Mas o que esses termos do Design, de Negócios ou da Gestão de Produtos têm a ver com Data Science? A resposta, em uma abstração ainda mais ampla, é: separar um domínio onde o foco é explorar na incerteza de outro domínio, onde a ênfase está em construir certeza.
Sobrepondo-se essa compreensão de incerteza e certeza à Figura 1 temos outra representação:
Qualquer semelhança em enxergar Business Analytics (Análise de Negócios) à esquerda e Machine Learning Engineering (Engenharia de Aprendizado de Máquina) à direita não será mera coincidência, já que a Ciência de Dados ajudou a delimitar melhor ambos e está constantemente transitando entre um e outro.
A ideia aqui, porém, não é falar de divisões de trabalho mais especializadas, mas entender como a Ciência de Dados e o cientista de dados podem se situar nesse espectro e tirar proveito dele no desenvolvimento de projetos, nos estudos e na carreira.
Análise
Vamos esquecer por um momento Analytics, Business Analytics, pessoal de negócio olhando dashboards ou relatórios de Business Intelligence, que são estereótipos comuns quando se fala em análise ou capacidade analítica nos dias atuais.
“Análise”, etimologicamente, é o processo de quebrar um tópico ou substância complexa em partes menores para obter um melhor entendimento sobre o “todo” desse tópico ou dessa substância. É uma metodologia presente na Ciência e que faz parte da Matemática e da Lógica desde a Antiguidade.
No espectro mencionado, a Análise está para a Ciência de Dados da mesma forma que o “problem space” e o “discovery” estão para os outros domínios. Podemos dizer que a Análise é onde a Ciência de Dados investiga seu espaço de problema e realiza descobertas. Mais do que isso: é onde ela tem de se sentir confortável em explorar em meio à incerteza.
Incerteza, aqui, não tem a ver com insegurança, é claro. O profissional não estará tendo de “pisar em ovos” para fazer seu trabalho. A incerteza citada é um fator inerente à análise, decorrente do fato de termos de encontrar e estudar dados e transformá-los em informações que forneçam respostas a perguntas estratégicas, sem sabermos de antemão exatamente o que iremos encontrar ou quais informações serão extraídas dos dados.
Nesse campo, a Ciência de Dados está muito mais perto da estratégia, do negócio, do marketing e da política da tomada de decisões, inevitavelmente, porque essas são as áreas estratégicas que precisam de insumos para responder perguntas difíceis. É um terreno de escopo aberto, de apostas a partir de informação incompleta e de oportunidades ou riscos difíceis de serem conhecidos por inteiro.
Para ficar mais fácil, podemos pensar no trabalho de análise clássico como aquele que explora dados para fornecer percepções e insights a tomadores de decisão humanos da empresa, normalmente gestores ou C-levels.
Cabem aqui a análise de vendas, da concorrência, do aumento ou da queda do número de clientes, dos riscos do produto ou do nicho de mercado em que ele está inserido; enfim, decisões estratégicas, que normalmente são de consumo interno da organização e é melhor que fiquem resguardadas nesse âmbito.
O trabalho pode ser bastante dinâmico, tracionado pelos problemas e oportunidades de negócio que surgem no dia a dia, o que exige flexibilidade, adaptação e abertura do profissional para transitar entre diferentes desafios.
As tarefas podem se assemelhar mais a projetos de consultoria do que de construção de soluções. O foco pode nem ser o de entregar “soluções” na forma de software, seja um painel ou um mini aplicativo, mas de fornecer informações para consumo simplificado e rápido, talvez em uma apresentação ou relatório, que subsidiem decisões.
A própria natureza volátil das questões a serem investigadas neste espectro pode tornar supérfluo qualquer esmero a mais. Talvez valha mais ter um um resumo simples com as principais informações em mãos do que quebrar a cabeça em como transformar aquilo em produto. Talvez na semana seguinte o desafio seja outro e a decisão anterior já esteja tomada — e todo o processo de produzir as informações para a decisão, esquecido.
Nesse lado do modelo, saber se comunicar com pessoas de negócio e tomadores de decisão, saber se adaptar ao contexto dos desafios que surgem (e que podem mudar com frequência), ser honesto quanto à exploração realizada e quanto aos resultados obtidos (mesmo que eles não atendam as expectativas dos stakeholders) são habilidades desejadas e necessárias.
Não será raro se deparar com gestores ou CEOs que podem querer pular das explicações para os resultados finais e o que eles querem dizer para o negócio. A impaciência pode se justificar pela pressa de resolver um problema ou aproveitar uma oportunidade de negócio. E, talvez, toda a captura de dados realizada, a transformação dos mesmos e a análise exploratória acabe na lixeira depois de satisfazer seu propósito.
A capacidade de transformar perguntas de alto nível do negócio em questões estatísticas a serem aplicadas sobre massas de dados é essencial. A busca por dados devem corresponder às perguntas que se está tentando responder, mas será compreensível se não houver dados “perfeitos”.
Vale lembrar que estamos falando de atuar na incerteza, onde talvez haja informação insuficiente, dados de má qualidade ou cujos cruzamentos não resultem em insights fáceis e óbvios de se interpretar — inclusive, com riscos de levar a interpretações equivocadas. O “bom o suficiente” pode ser o que há de “perfeito” nesse território.
Em organizações maduras, a análise pode ser muito mais assunto de Business Analytics, é claro. Mas mesmo que a Ciência de Dados forneça apoio em análises mais complexas ou auxiliadas por algoritmos de aprendizado de máquina, por exemplo, ainda assim estará flertando com o campo analítico e terá de entender suas nuances.
De qualquer modo, não é incomum vagas de empregos requisitarem cientistas de dados para desempenhar tarefas mais próximas deste lado do espectro, sem que haja um Business Analytics por perto ou qualquer menção ao termo. O importante é estar ciente da possibilidade de ser um cientista de dados trabalhando muito mais no campo analítico do que no da engenharia (que veremos a seguir) e a mentalidade que isso requer e implica.
Um cientista de dados mais voltado para a análise pode se ver auxiliando o marketing com testes A/B, pode ser demandado pela área de vendas, que deseja entender uma taxa de entrada ou desistência de clientes ou pode ser consultado pela Gestão de Produtos ou pelo Design, que precisam elaborar uma pesquisa com usuários ou quantificar as respostas recebidas.
Domínio de técnicas estatísticas, rigor com experimentos e resultados, entender a natureza e a qualidade dos dados utilizados são alguns dos requisitos essenciais para transitar neste lado do escopo da Ciência de Dados. O que menos interessa é se a exploração for feita em R, Python ou mesmo no Excel. Os “fins” (informação para subsidiar a tomada de decisão) importam muito mais que os “meios” (a forma como se chegou a tais informações).
Um modelo de aprendizado de máquina ou um painel de dados dinâmico pode até ser implementado e rodar para consulta de pessoas de negócios, mas talvez não seja definitivamente um “produto interno”. Talvez não passe de solução temporária, interessante enquanto o problema ou oportunidade em questão estiver em evidência. Uma vez superado, pode-se partir para novos desafios.
Estatísticos, pessoas que vêm do Marketing, da Administração ou de áreas ligadas a negócios para a Ciência de Dados podem se ver realizados nesta parte do espectro, alimentados por problemas diferentes, tendo de usar a criatividade para transformar perguntas em investigações quantitativas, farejando dados de diversas fontes, comunicando-se com tomadores de decisão e contribuindo com decisões estratégicas.
Em resumo, a atuação mais voltada à Análise tem a ver com incerteza, seja na forma de perguntas muito abertas e abrangentes, nas caraterísticas dos dados que serão usados para respondê-las, na possibilidade das informações extraídas não corresponderem ao que se procura (podem, inclusive, demonstrar o oposto), isso se a exploração não se revelar infrutífera. Também tem a ver com gerar informações para tomada de decisões por humanos, o que requer interação e comunicação, um domínio nada linear nem exato.
Ter “apetite” por essas nuances fará um profissional muito mais produtivo e realizado neste lado do espectro.
Engenharia
Engenharia, por sua vez, pode ser entendida como o ato de projetar e construir artefatos físicos ou informacionais. Note-se o verbo “construir”, que contrasta em alto grau com “explorar”, “descobrir” ou “quebrar em partes” da Análise.
Se a análise é como uma incisão cirúrgica em um domínio (algo bastante pontual e específico, instável e volátil), a Engenharia é voltada à replicação e à reprodutibilidade dentro de padrões (algo voltado à permanência, à robustez e à escala).
Isso significa que a Engenharia, ao contrário da Análise, que atua na incerteza, tem sua atuação focada em construir certeza. Não significa que um empreendimento em engenharia não envolva incerteza, mas que sua busca é, se possível, por eliminá-la.
Obviamente, como todo engenheiro sabe em teoria (ou aprenderá com a experiência), é impossível eliminar completamente a incerteza de qualquer empreitada, por mais simples que seja. Isto seria platonismo, mundo ideal, perfeição.
Porém, como todo engenheiro também sabe (e Engenharia é basicamente sobre isso), há técnicas e métodos para se chegar mais e mais perto desse “ótimo”, nunca à “perfeição”, mas, com bastante trabalho e uma boa noção prática, a uma distância infinitesimal dela — uma questão de limites, como se aprender desde o início no campo.
De novo, o que limites, construção e se aproximar da certeza tem a ver com Data Science?
Quando falamos em implementar modelos de aprendizado de máquina para a tomada de decisão automatizada (recomendações de produtos em um e-commerce, para ficar em um dos exemplos mais óbvios), ou quando pensamos no dashboard que, agora sim, funciona como “produto interno” da empresa, ou quando implantamos ou melhoramos o aplicativo que aprende a classificar manifestações dos clientes como reclamações e elogios (análise de sentimentos), estamos nos deslocando para o lado da Engenharia em nosso modelo mental da Ciência de Dados.
É aqui que nos encontramos muito mais próximos do desenvolvimento de software, suas técnicas e métodos, que fazem deste domínio também uma forma de Engenharia.
Para um exemplo bastante simples, em contraste com a Análise, uma coisa é elaborarmos gráficos, mesmo que interativos e dinâmicos, para uma apresentação específica, voltada a uma decisão de negócios pontual, sem compromisso que isso se sustente e seja incrementado no futuro.
Outra coisa bem diferente é um painel de gráficos se tornar ferramenta, um “produto”, utilizado por gestores, que irão solicitar a inclusão de mais indicadores no painel com o tempo, ou o refinamento estético da visualização, ou compilações e resumos estatísticos mais aprofundados.
A tarefa, nesse caso, migra completamente da descoberta e exploração de um problema (território da incerteza) para a manutenção e o ajuste de uma solução (aproximar-se da certeza, tornar a ferramenta o mais próximo possível de “ótima”). Repare-se que estamos dentro do espaço da solução (solution space) de Data Science.
Questões como robustez e sustentabilidade da solução, implicações a longo prazo, possibilidade de ampliação e acoplamento de outras partes sobre as já construídas, garantia de que a estrutura se manterá em funcionamento, monitorar o comportamento — tudo isso são preocupações que passam a existir quanto mais nos deslocamos para o espectro da Engenharia.
Quando vemos cientistas de dados que se especializam como engenheiros de aprendizado de máquina (ML engineers), uma função mais desenvolvida no exterior, mas que começa a ganhar campo no Brasil, temos um bom exemplo de atuação neste outro lado da Ciência de Dados.
Embora possa haver um momento de exploração e descoberta em relação a um algoritmo a ser implantado, ainda assim é uma etapa inerente à “construção” de uma solução, não uma exploração aberta, em busca de responder perguntas com dados. O foco está muito mais em estruturar algo e fazê-lo funcionar da melhor maneira possível e pelo maior tempo.
Queremos evitar ao máximo ter de resolver duas vezes o mesmo problema, outra forma de dizer uma frase comum na Engenharia: “reinventar a roda”.
Uma vez implantado o modelo em produção, pode haver uma série de ajustes a serem realizados ao longo do tempo, dependendo do comportamento e da qualidade dos dados recebidos e injetados na função ou da evolução da própria empresa e seus negócios.
Se esses dados forem oriundos do comportamento humano em escala, como consumo ou utilização de um aplicativo, espere-se variações sujeitas a outliers, irregularidades e eventuais mudanças bruscas, as quais podem causar alguma instabilidade no algoritmo até que ele aprenda e corresponda a novos padrões. Ou seja, monitoramento e melhoria contínua.
No lado da Engenharia no espectro, diferente da Análise, o cientista de dados pode ter tempo e espaço para trabalhar mais dissociado das pessoas de negócio. Reduzidas as incertezas, descoberto o que deve ser construído, entra-se muito mais numa seara de decisões técnicas de arquitetura (projeto) e construção (estrutura) da solução, que podem ser discutidas com um líder técnico, o qual se encarregará de comunicar pessoas de negócio sobre o que for necessário.
Os detalhes técnicos da implementação ou manutenção não irão interessar tanto ao negócio, a menos que surjam incertezas na construção da solução. Como em tecnologia da informação isso é comum, dada a quantidade de pequenas decisões envolvidas na criação de código, novamente cabe a observância a princípios e padrões de desenvolvimento de software para que se reduza “débitos técnicos”.
Isso envolve, em geral, seguir guias de estilo e boas práticas de codificação, manter controle de versão, manter a organização e coerência de objetos e funções, dependendo do paradigma de desenvolvimento utilizado, entre tantos outros padrões “universais” ou acordados no ambiente de trabalho.
Note-se como migramos de um campo onde o “meio” importa menos (Análise) para outro em que o “meio” se torna crítico (Engenharia).
Em resumo, saber que irá se deparar com essas necessidades, inerentes à construção e manutenção de soluções, o ato de se pensar em estrutura, padrões e “otimização”, permite muito mais clareza e assertividade na migração e atuação neste lado da Ciência de Dados.
Novamente, estar confortável em trabalhar com a certeza e o modo de pensar que ela impõe, além de persegui-la constantemente (sabendo que é impossível atingi-la e que é necessário trabalho árduo e constante para se manter próximo dela) são requisitos nesse território.
Complexidade e ferramentas
Outra forma de pensar na Ciência de Dados em nosso modelo mental entre Análise e Engenharia é quanto à complexidade de dados e às ferramentas computacionais com que cada lado trabalha.
Obviamente, há exceções, mas no geral Análise está mais associada a dados mais estruturados e menos complexos (com menos dimensões, por exemplo) ou tornados menos complexos após limpeza e tratamento, o que envolve ferramentas também menos complexas, que permitam gastar menos tempo com configuração ou construção do que com exploração e descobertas.
Enquanto isso, a Engenharia, por operar soluções robustas em escala e tempo, normalmente tem de lidar com maior complexidade de dados, o que requer, por sua vez, ferramentas capazes de satisfazer esse requisito.
A figura a seguir ajuda a pensar nessa relação:
Quanto mais se caminha à parte direita (eixo x) e superior (eixo y) da figura, maior a complexidade dos dados com os quais se trabalha e, consequentemente, maior a complexidade das ferramentas computacionais para lidar com eles — ou seja, mais a mentalidade de engenharia é demandada. Mais à esquerda e abaixo, é mais comum se estar no terreno da Análise.
Em termos práticos, quando trabalhamos com Análise, na grande maioria dos casos vamos trabalhar com dados tabulares, desde planilhas simples a bancos de dados relacionais com maior quantidade de colunas e linhas. Pode-se chegar a séries temporais, que agregam a dimensão “tempo” aos demais dados. No extremo, até dados textuais (ou speech to text, fala convertida em texto,), como na análise de sentimentos, que poderão ser reduzidos a dados tabulares.
Já quando estamos no espectro da Engenharia, pode ser muito mais comum lidarmos do meio para o alto e à direita dessa outra representação. Machine Learning, por exemplo, vai desde dados tabulares com maior quantidade de colunas e linhas (pense-se no banco de dados de interações de usuários no produto) até processamento de texto e voz em dados brutos. Deep Learning, por outro lado (redes neurais, com dados de várias dimensões), já se situa no extremo superior e direito, na lida com imagens e vídeos, por exemplo.
Importante: não é uma escala discreta, em que onde um acaba o outro começa, mas uma representação (todo “modelo” joga fora várias nuances da realidade) que ajuda a visualizar e entender como a complexidade de dados e de ferramentas se relaciona com o espectro da Análise e da Engenharia.
Por falar em ferramentas, vale detalhar algumas diferenças. Do lado da Análise, ferramentas visuais como Tableau, PowerBI ou mesmo Microsoft Excel podem se demonstrar suficientes para exploração e descoberta, embora suites online, como Google Data Studio, entre outras, estejam ganhando relevância. Havendo necessidade, R Studio, Jupyter Notebook ou mesmo softwares estatísticos como MATLAB rodando em uma máquina local podem dar conta do recado. Os meios, vale lembrar, importam menos que os fins.
A ferramenta estará relacionada à fonte dos dados. No caso da Análise, provavelmente serão planilhas, arquivos CSV ou bancos de dados SQL, por exemplo.
Aumentando-se a complexidade de dados, começa-se a entrar em território onde a intensidade computacional também aumenta. É onde encontramos ferramentas de computação em nuvem, onde se começa a ouvir falar em Hadoop, Spark e similares, utilizadas para armazenamento e processamento de dados distribuídos em escala. Também entram aqui Google Big Query, Amazon Redshift e outras soluções de Data Warehouses ou de Data Lakes.
Modelos de machine learning em produção (um classificador de quem está apto a um empréstimo ou seguro, por exemplo) podem requerer uma sintonia fina com esses repositórios e armazéns de dados de maior escala, o que requer conhecimento nesse domínio, onde a mentalidade da Engenharia é uma aliada.
Essas distinções ajudam a entender o perfil de vagas para cientistas de dados. Vagas que descrevem um trabalho mais voltado a insights para negócios, experiência com análise exploratória em R ou Python, conhecimento em SQL, construção de painéis ou relatórios a partir de bancos de dados relacionais e que visam manter times de marketing, produto ou negócio informados, estão claramente do lado da Análise, como os exemplos a seguir.
Na outra ponta, vagas descritas como Ciência de Dados, mas que exigem conhecimentos em computação distribuída e ferramentas de nuvem, ao menos algum conhecimento em linguagens usadas em aplicações de larga escala na indústria (talvez Java ou até C) ou em frameworks de machine learning e deep learning também requeridos na indústria (TensorFlow é um que se vê em grandes empresas) estão muito mais para o espectro da Engenharia.
Embora empresas maduras e com cultura de dados estabelecida já separem essas responsabilidades e procurem perfis adequados para cada uma, como a Ciência de Dados ainda é novidade ou vem sendo amadurecida em muitas organizações, é interessante o profissional ter clareza quanto ao que é exigido, principalmente quando a descrição da vaga não detalha todos os requisitos ou mistura vários deles.
Novamente, entender em qual lado do espectro a empresa atua ou pretende atuar e para quais atividades o profissional está sendo contratado evitará frustrações para ambos os lados.
Transitando no espectro
É claro que alguém com características e mentalidade de Análise não está fadado a permanecer para sempre nesse campo. O mesmo vale para o outro lado do modelo mental, a Engenharia.
O que empresas e startups procuram, na verdade, mesmo com maior realismo quanto a profissionais “unicórnios”, é quem domine toda a extensão do espectro com excelência, da Análise à Engenharia.
O profissional que conseguir a façanha, certamente se destacará no mercado. Entretanto, vale reconhecer que não é fácil dominar profundamente ambos os campos, por causa da profundidade e da atualização que sofrem constantemente, além da transição mental que trabalhos de qualidade exigem em um e outro.
Ironia ou brincadeiras à parte, o ditado de que “um cientista de dados é um melhor estatístico do que a maioria dos programadores e um melhor programador do que a maioria dos estatísticos” ilustra um pouco o lugar da Ciência de Dados do dia a dia no espectro: a metade dele, um pé na Análise, outro na Engenharia, com capacidade de se virar bem, até um limite razoável, em cada um deles.
Em startups, um cientista de dados que ingressa junto com os fundadores talvez se veja muito mais em tarefas analíticas nos primeiros anos, típicas dessa fase do negócio. Se ele permanecer na organização, pode se ver migrando para um espectro muito mais de engenharia, trabalhando próximo do time de desenvolvimento de software (agora maior e mais estruturado), quando o negócio atingir a fase de crescimento ou a maturidade.
Em empresas que atuam como “fábrica de software”, talvez o cientista de dados ingresse para exercer um trabalho muito mais do lado da Engenheira, ou seja, implementar ou ajudar na implantação de modelos automatizados em produção.
Pense-se em empresas que oferecem soluções de dados para outros negócios, uma agrotech, por exemplo, que fornece serviços de otimização de lavoura ou pecuária. Talvez a grande força de cientistas de dados da empresa esteja concentrada em engenharia de ponta para implementar, monitorar, aprimorar e evoluir algoritmos que controlam o cultivo de vegetais ou a criação de animais à distância, em escala, por meio de sensores, drones ou outros dispositivos de Internet das Coisas (IoT, Internet of Things). É nítida, aqui, uma inclinação para o lado da Engenharia.
Por outro lado, talvez haja outro time, com analistas de negócios, trabalhando na sede administrativa dessa mesma empresa, para investigar questões estratégicas de mercado, expansão para outros países, concorrência no exterior, tentando entender questões relacionadas ao fluxo de caixa da empresa. Aqui, é óbvio um deslocamento para o lado da Análise no espectro.
Há exceções, sempre há, mas talvez cientistas de dados com experiência em programação se vejam muito mais confortáveis do lado da Engenharia, operando na “certeza”, em concordância com o perfil que levou à sua escolha profissional anterior. Enquanto que um estatístico, um econometrista ou um analista de negócios que avançou para Data Science talvez goste muito mais do território da análise, de flertar com as explorações e as descobertas na incerteza.
Situar a Ciência de Dados entre essas duas características e entender como um lado atua na incerteza e outra atua na certeza permite mais assertividade na escolha de vagas, no fit profissional e cultural com startups e empresas e na evolução da carreira. Também permite enxergar o leque de possibilidades em que um Cientista de Dados pode transitar, mergulhar em momentos diferentes de sua jornada ou se especializar ao longo da vida.
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.