A etapa difícil (e a razão de existir) da Ciência de Dados
Entendimento de negócio (business understanding) é o que torna profissionais e estratégias de Data Science outliers em relação à média do mercado
A Ciência de Dados não é difícil porque requer conhecimentos em estatística, matemática e programação. Essa poderia ser considerada a parte “fácil” dela — obviamente, “não é fácil” porque requer tempo, mas, ainda assim, “é fácil” porque é possível adquirir esse conhecimento de forma gradual e linear ou, então, desenvolvendo habilidades (hacks) para aprender novos conceitos conforme forem necessários.
O que é realmente difícil na Ciência de Dados é o que resumimos como “Conhecimento de Negócio”, mas que também pode aparecer como “Substantive Expertise” (essa é considerada a primeira esquematização em que o termo aparece), “Domain Knowledge”, “Domain expertise” e outras variações.
A aquisição desse conhecimento é difícil porque não permite treino ou ensaio antecipado: depende de prática em batalha a médio ou longo prazo. Também não afeta apenas aprendizes ou profissionais juniores. À medida que o profissional, um time ou toda uma estratégia de Data Science avança para a senioridade, é natural que os problemas e desafios de negócio também se tornem mais complexos, exigindo novos aprendizados.
Além disso, essa dificuldade é exponenciada porque não basta compreender desafios do domínio de negócio em que se está inserido: é preciso saber como traduzi-los em abordagens estruturadas, passíveis de serem tratados quantitativamente, por meio de técnicas estatísticas e algoritmos computacionais.
Obviamente, essa não é uma mensagem com intuito de desanimar aspirantes ou quem já está no mercado. Para quem se interessa pela área e ama o trabalho, “entendimento do negócio”, ou melhor, problemas de negócio, são como combustível e a razão de existir da Ciência de Dados.
São eles que impulsionam estratégias e projetos, fornecem dados (a matéria-prima), levam a análises e algoritmos e resultam em soluções em produção. Também dão sentido ao dia a dia profissional, permitem enxergar evolução da carreira, ajudar empresas, clientes e projetos a atingirem seus objetivos e, quem sabe, até transformar trabalho em diversão e a formar relacionamentos.
“A primeira coisa é que você tem que ter paixão. Essa rica paixão por perseguir implacavelmente o problema e ser profundamente honesto intelectualmente consigo mesmo sobre se essa é uma resposta razoável.” — DJ Patil, em entrevista ao FiveThirtyEight, em 2015.
Observando o fluxo de Data Science
Há uma metodologia nascida nos anos 2000, na Mineração de Dados (Data Mining), que de certa forma padronizou etapas de projetos na Ciência de Dados (hoje, há muitas variações do ciclo, mas a ideia central é a mesma). A metodologia chama-se CRoss Industry Standard Process for Data Mining (CRISP-DM) e coloca os seguintes estágios para projetos do tipo:
Quando estamos aprendendo Ciência de Dados desde o início ou renovando conhecimentos em técnicas da área, é comum darmos atenção às fases de Data Preparation, Modeling e, mais recentemente, com a busca do mercado por cientista de dados capazes de entregar soluções de ponta a ponta, também em Deployment.
Faz sentido, é claro. Estamos correndo para adquirir habilidades técnicas. Na preparação de dados, estamos aprendendo a lidar com APIs bancos de dados ou limpando ou concatenando tabelas com Numpy e Pandas. Em Modeling, estamos entendendo o comportamento dos dados, por meio de Análise Exploratória de Dados (EDA, de Exploratory Data Analysis), brincando e tentando escolher entre modelos de aprendizado que melhor performam à tarefa ou ao projeto que estamos desenvolvendo. Em Deployment, entram conhecimentos de computação para colocar as saídas na forma de gráficos, em uma página web, ou em alguma automação, como classificação de reclamações ou recomendação de produtos.
A etapa de Business Understanding talvez já tenha sido entregue pronta por um exercício que recebemos de alguém ou que encontramos no Medium ou no Kaggle. Em Data Understanding, provavelmente já temos uma base de dados pronta, talvez bastante limpa e organizada, para irmos rapidamente à exploração e modelagem. Evaluation, por sua vez, acaba se resumindo à performance técnica do modelo.
Quando ingressamos no mercado e à medida que avançamos na carreira, podemos dizer que há uma “inversão” de importância entre essas etapas em relação aos estudos.
Passamos a ter de dar muito mais atenção a Business Understanding, Data Understanding e Evaluation, que são relacionadas a ajustar as soluções da Ciência de Dados aos desafios do negócio em que atuamos. Até porque, pressupõe-se, já estamos confortáveis com as etapas técnicas (preparação dos dados, modelagem e deploy) ou sabemos como e onde buscar conhecimento para realizá-las.
Como aponta um artigo de 2017 do KDNuggets, um tradicional portal sobre Ciência de Dados e Aprendizado de Máquina, a vontade de correr rapidamente para os dados e a modelagem, a parte “mais divertida” da Ciência de Dados, muitas vezes faz profissionais quebrarem o ciclo dos projetos de Data Science.
A quebra ocorre, principalmente, na etapa de Evaluation (avaliação). Se o modelo performa bem, pode ir para Deployment por esse simples critério técnico, sem uma revisão sobre se de fato atende aos objetivos de negócio. Se o modelo não performa bem, volta-se para Data Understanding, tentando-se adicionar mais dados ou dados diferentes para tentar corrigir a performance da análise.
Qual o grande problema desse tipo de abordagem? Muitas vezes, não reside nos dados ou nas técnicas utilizadas, mas nos processos de uma organização e nas expectativas das pessoas que compõem essa organização. Ou seja, falta de atenção ao que origina qualquer ciclo de projeto da Ciência de Dados: o entendimento de negócio, a “parte difícil” a que nos referimos.
“Metade da batalha em um projeto de ciência de dados bem-sucedido pode ser expressar o problema de uma forma que garanta uma solução otimizada baseada em dados, com um conjunto claro de objetivos realistas e alcançáveis.” — de um diretor de Ciência de Dados, no Towards Data Science.
Tornando “negócio” mais tangível
Antes de quebrarmos o “entendimento de negócio” em partes, vale uma explanação sobre “negócios” de forma geral. Nos últimos anos, parece ter-se tornado regra generalizar como “negócio” qualquer aspecto oposto a áreas mais técnicas de uma startup ou empresa, o que não nos ajuda muito.
Mesmo formalmente, porém, o termo também é um tanto ambíguo. Presta-se tanto a significar uma transação comercial individual ou em escala (“o negócio do vestuário”, “a venda de roupas”, por exemplo) como, por metonímia, a sede (estabelecimento físico) de uma organização que realiza esse tipo de transação (“a loja de roupas X”, por exemplo).
Em sentido amplo, pode-se dizer que é uma atividade que explora uma necessidade ou desejo de um mercado, a qual é exercida por meio de uma ou mais empresas. Empresa, por sua vez, é a pessoa jurídica — um “ser” abstrato — que, por meio de capital, maquinário, propriedades, pessoas e processos, exerce essa atividade no mercado.
No mundo da tecnologia e para nossa finalidade em relação a Data Science, podemos, informalmente, classificar empresas em três grandes tipos:
startups, tipo de empresa que tem a tecnologia da informação como core e que está buscando mercado (market-fit) ou está em crescimento rápido, após atingi-lo;
empresas de tecnologia, organizações de maior porte, que também têm a tecnologia da informação como core e que já se consolidaram no mercado;
empresas em transformação digital, organizações tradicionais de diversos portes, que não têm a tecnologia da informação como core, mas que a estão incluindo, gradualmente, em menor ou menor grau, no redesenho de seus processos.
Poderíamos nos perguntar sobre um quarto tipo: empresas que não têm a tecnologia da informação como core e que não a estão incluindo em seus processos (uma pequena oficina ou lavação de carros, uma franquia de posto de gasolina, uma padaria tradicional). Mas estas não geram dados, ao que parece, a ponto de demandarem um cientista de dados.
Dependendo do tipo em que uma empresa se encaixa (e, obviamente, dependendo de seu ramo de atividade, entre outras particularidades) fica mais fácil falar em “entendimento de negócio” para projetos de Ciência de Dados.
Assim, é provável que uma startup que opera um único serviço por meio de tecnologia da informação, como, em exemplo hipotético, entrega de buquês de flores, gere vários tipos de dados desde o início de suas atividades e se depare com diversas necessidades ou desejos em utilizá-los. Exemplos: descobrir como atrair mais clientes, como tornar as compras mais recorrentes ou como otimizar tempo e custo de entrega das flores.
À medida que a startup cresce, seus desafios também aumentam, mas há algumas vantagens evidentes que facilitarão o tal do “entendimento de negócio” para cientistas de dados que atuarem nela:
a empresa já nasceu coletando e armazenando dados, ou seja, tem uma cultura mínima sobre a importância dos dados;
há séries históricas, mesmo que com imperfeições, que facilitam trabalhos de análise do que ocorreu e, com base no passado, previsão do que pode ocorrer no futuro;
trata-se de um único serviço, bem especificado e delimitado, o que facilita o aprofundamento de abordagens quantitativas;
provavelmente, dada a cultura, a empresa já sabe ou intui o que precisa corrigir ou melhorar em seus processos, o que permite iniciar projetos de Ciência de Dados de forma mais assertiva, pelo menos com dados em mãos, clareza onde se quer chegar e, talvez, uma dose de “realismo” sobre as considerações técnicas.
Ainda é fácil enxergar o quadro geral em um contexto como o das startups. O produto se confunde com o negócio, de forma que atrair e reter mais clientes para o produto é quase uma correlação positiva perfeita com as metas de receita da startup para o trimestre ou o ano. É visível onde as melhorias (decisões humanas mais assertivas ou automatização de trabalho repetitivo) impactarão objetivos de negócio. A comunicação pode ser mais direta e informal.
O caso de uma grande empresa de tecnologia provavelmente será parecido, mas com complicações devido à escala. A empresa certamente terá mais tempo de mercado e, em consequência, muitos mais dados. Terá um catálogo de produtos, provavelmente. Poderá operar em mais de um “negócio” distinto, no sentido de transação mercantil. Por exemplo, poderá fornecer soluções para o mercado financeiro e para gestão de outras empresas. Poderá ter produtos B2B (para outras empresas) e B2C (para consumidores) ao mesmo tempo.
Provavelmente, haverá grandes objetivos de “negócio”, ou seja, da organização como um todo, que certamente estarão no volume de milhões ou bilhões, em dinheiro. E haverá metas específicas para cada produto, segmento e mercado em que atua, que somarão aos objetivos gerais.
Por consequência, cada produto pode ter uma série de melhorias específicas, cada qual também visando uma contribuição aos grandes objetivos. Tais melhorias podem não apenas se destinar à geração de receita, mas visar à redução de custos, mesmo que pequenos.
Certamente, torna-se mais complexo conduzir projetos de Ciência de Dados em um ambiente como este. Os dados podem apresentar mais particularidades. Tem de haver alinhamento interno para que as melhorias em um produto ou na infraestrutura de todos os produtos se conectem com os objetivos gerais de um produto, e estes com o do setor daquele produto, e estes, por sua vez, com os objetivos gerais da organização.
Tarefas analíticas podem diferir bastante de um produto para outro e, certamente, irão diferir mais ainda de tarefas analíticas para o core da empresa, onde estão os grandes objetivos da organização e tomadas de decisões que podem impactar montantes milionários ou bilionários.
A especialização aumentará e, provavelmente, haverá mais demanda para machine learning (automação de tarefas repetitivas, para redução de custos), enquanto a análise de indicadores pode estar bastante dominada para produtos e segmentos já maduros. A comunicação é mais formal, com maior quantidade de documentação, comunicados e cerimônias.
O terceiro caso, das empresas em transformação digital, fica mais claro a partir dessa abordagem. Provavelmente, uma organização do tipo tenha muito mais tempo de existência e muito mais problemas com dados fragmentados, de má qualidade, interrompidos ou descontinuados. O histórico pode histórico se preste para previsões.
Enquanto um departamento pode estar mais adiantado com inovações, tentando falar uma linguagem de startups, outro pode estar repetindo processos manuais de 20 anos atrás, e com resistência a mudanças.
A condução da empresa pode representar toda essa mesma fragmentação, com divergência de métodos de gestão, maior preocupação com os custos do que com os benefícios de projetos analíticos e inovadores, entre outros fatores.
A comunicação, por sua vez, pode ser truncada, os acordos dificultados e assinaturas podem ser necessárias em vários níveis para que uma decisão simples seja tomada. Naturalmente, uma melhoria feita em um processo da empresa pode não impactar grandes objetivos do negócio, por causa do desalinhamento.
É claro que esta não é a regra para empresas em transformação digital, mas é um tanto inerente, natural, que haja solavancos em organizações que passam por esse processo.
Poderíamos perguntar, também, como ficam empresas que funcionam como agência, aquelas que fornecem profissionais de dados para trabalhar por projeto a outras empresas. Mas o que interessa, no nosso caso, é a empresa “cliente”, que acabará se encaixando em uma das três categorias acima (startup, empresa de tecnologia ou em transformação digital).
Em resumo, Ciência de Dados terá entendimento, liberdades e vocações particulares em cada um desses contextos e, consequentemente, mais ou menos dificuldades para a etapa do “entendimento de negócio” nos projetos de dados.
Tornando “negócio” mais preciso
O "entendimento de negócio" para a Ciência de Dados é a tarefa de transformar "problemas" da empresa (dela como um todo, de um setor, de um produto) em perguntas precisas e mensuráveis em relação a um objetivo.
Note-se que é importante ter um objetivo, um indicador, se possível um critério de comparação, senão seria como correr indefinitivamente sem uma linha de chegada.
Por "problema", outra generalização muito usada, podemos entender: um aspecto da empresa que se quer maximizar ou minimizar em relação a um objetivo, como aumentar vendas ou reduzir custos de entrega. É tudo sobre eficiência, o tempo todo.
Pode acontecer de uma tarefa ser apenas exploratória, visando descoberta, como saber quantos clientes desistem por mês ou quantas vezes um servidor falha em produção. Em empresas mais estruturadas, porém, isso já é monitorado rotineiramente e, quando se percebe uma anomalia, há muito mais precisão em se abordar a questão para resolvê-la.
Assim, em vez de pessoas de “negócio” demandarem a equipe de Ciência de Dados para descobrir quantos clientes desistem por mês, provavelmente chegará com algo mais detalhado, como: "Percebemos que estamos perdendo X% de clientes por mês. Queremos estudar de forma mais aprofundada isso e o que é mais eficiente fazermos para reter esses clientes?"
É preciso um ponto de onde se partir e um ponto aonde se quer chegar. O restante da tarefa consiste no refinamento da questão em partes ainda mais exatas, que possam ser analisadas por meio de dados. O clássico trabalho de reduzir grandes problemas em suas partes fundamentais.
Provavelmente, uma lista de novas perguntas surgiria da pergunta principal:
Se temos dados do histórico de cancelamentos, que tipo de estudo mais aprofundado queremos fazer? Onde queremos chegar? Entender se isso é sazonal, recorrente ou pontual, por exemplo?
Temos dados de campanhas de marketing ou de atendimento ao cliente que permitam cruzá-las com o histórico de desistências para verificar se elas impactaram na redução destas últimas?
Temos dados de algum tipo de benefício que fornecemos ao cliente para que não desista? Se sim, seria interessante analisar se eles foram eficientes. Se não, por que não lançar um experimento com benefícios para testar o quanto isso impacta na retenção de clientes?
Quase todo o esforço e a qualidade de um projeto de Ciência de Dados estarão relacionados a esse refinamento das questões iniciais e à busca e disponibilidade de bons dados para respondê-las.
É comum que esse refinamento também ocorra de forma iterativa e não linear. Pode-se partir de algumas perguntas, juntar dados, analisá-los e perceber que há informações nos dados que não haviam vindo à tona. Por exemplo, um recorde de cancelamentos em uma única data que distorce uma taxa mais ou menos normal de desistências.
Deve-se voltar a analisar a questão com as pessoas de “negócio” para entender o comportamento dos dados. À medida que se estrutura um experimento ou modelo que vise automatizar um benefício ao cliente, também será necessário ir refinando-o com os “clientes” da solução, as pessoas de negócio.
Talvez se descubra que uma boa classificação dos feedbacks recebidos após a pessoa cancelar revele oportunidades de melhoria que não tinham sido pensadas.
O exercício é infinito e as questões acima são bastante básicas, para fins ilustrativos. Uma empresa orientada por dados provavelmente acompanhará métricas e indicadores constantemente e conseguirá refinamentos muito mais profundos das questões a serem exploradas.
Um modelo que pode ajudar com a elaboração ou qualificação de perguntas de negócio é fornecido pela Microsoft, em um artigo sobre a metodologia Team Data Science Process (TDSP):
se a questão se refere a “quanto” ou a “quantos”, pode-se pensar em um modelo de regressão;
se a questão se refere categorização, pode-se pensar em um modelo de classificação;
se a questão se refere a “qual grupo”, pode-se pensar em agrupamento ou clustering;
se a questão é “se algo é estranho”, pode-se pensar em detecção de anomalia;
se for “qual opção deve ser tomada”, pode-se pensar em um modelo de recomendação.
Outro enquadramento pode auxiliar a saber qual a natureza do problema e como tratá-lo por meio de algoritmos de machine learning, conforme sugere um data scientist sênior da Amazon:
se queremos saber como algo irá impactar em nosso produto, serviço ou negócio, a solução está em design de experimentos, questionários e testes A/B, por exemplo (ou seja, é necessário implementar algo, normalmente para uma amostragem de usuários, e monitorar para saber como se comportará, se é aceitável ou não, viável ou não etc.);
se queremos prever algo (demanda, cancelamentos, falhas de sistemas etc.), cabe aplicar modelos preditivos de machine learning;
se queremos medir o incremento de algo, como evento ou campanha de marketing, cabem modelos de inferência, que consistem em fazer um experimento com um grupo que recebe a campanha e outro que não a recebe, para saber o grau de sucesso (similar a testar a eficácia de uma vacina, por exemplo);
se queremos maximizar ou minimizar algo em relação a outro fator (aumentar a receita em função de promoções ou reduzir tempo de entrega em função de rotas inteligentes), pode-se lançar mão de modelos de otimização, comuns em engenharia e administração de muitas indústrias.
Até o modelo generalista 5W1H, da Gestão de Projetos, que pode acabar negligenciado em ambientes de inovação, pode ajudar a diagnosticar um problema ou pensar em soluções:
What? (O que acontece/aconteceu ou o que queremos que aconteça?)
Why? (Por que acontece/aconteceu ou por que queremos que aconteça?)
When? (Quando acontece/aconteceu ou quando queremos que aconteça?)
Where? (Onde acontece/aconteceu ou onde queremos que aconteça?)
Who? (Quem envolve/envolveu ou quem queremos que envolva?)
How? (Como acontece/aconteceu ou como queremos que aconteça?)
O importante é que business understanding se trata basicamente disso: quebrar grandes questões em parte menores possíveis, precisas, claras e factíveis de serem resolvidas com dados.
É uma etapa bastante aberta, que envolve incertezas, consensos e que precisa ter alguns limites, para que não se caia em divagações sem fim. Tentar partir rapidamente dessa etapa para dados, análise exploratória e modelagem, por outro lado, também pode ser desperdício de tempo e recursos — e, às vezes, modelos perfeitamente construídos que não servem de nada à empresa.
É interessante notar, ainda, que essa busca por precisão deverão acompanhar todo o projeto, desde essa primeira etapa. Talvez haja um limite claro até onde os dados disponíveis permitam avançar. Talvez se reconheça que o projeto é mais difícil do que foi intuído em um primeiro momento e será preciso reelaborar a abordagem ou, quem sabe, abortá-la. São questões que dizem respeito ao negócio.
“[Eu] trabalho nos conjuntos de dados mais estranhos ou excepcionalmente difíceis que nossos clientes trazem. Para mim, isso é como um mistério, onde eu posso ser o detetive, encontrando pistas matemáticas para o que está sob a superfície. A maioria deles eu posso ‘resolver’, mas há alguns em que simplesmente não há o suficiente para continuar, e saber quando passar a um projeto diferente é sempre um desafio. Sempre sinto que, se dedicasse mais algumas horas de trabalho, encontraria a solução. Mas o negócio não está me pagando para seguir buracos de coelho até o fim.” — de um cientista de dados, no Quora.
Tornando “negócio” mais humano
Apesar de acabarmos de falar sobre precisão, clareza e outros critérios para o “entendimento de negócio”, um outro lado dele, na prática, tem pouco a ver com algo exato. É o lado que depende, inevitavelmente, do conhecimento sobre o contexto da empresa, do conhecimento das particularidades do ramo e do mercado em que ela atua e, fundamental, do conhecimento das pessoas que formam a empresa.
A etapa de entender o problema de negócio dependerá muito de quem são as pessoas que estão com aquele problema ou estão pedindo por uma solução, seu nível de compreensão de dados e como conduzem seus processos de trabalho, o que, em escala macro, gera o que chamamos de cultura organizacional.
A melhor “tecnologia” de que dispomos para que essa etapa da Ciência de Dados seja produtiva e assertiva não envolve algoritmos nem nada muito avançado: depende de muita conversa (comunicação), paciência e capacidade de construir parceria e confiança no ambiente de trabalho. Ou seja, soft skills.
Nuances como falta de confiança velada podem colocar um time de data scientists e outro de negócio (também podem ser designers, psicólogos do RH etc.) como se estivessem em lados opostos de uma batalha. Desenvolver confiança, por outro lado, pode fazer o “negócio” confiar nas sugestões, informações e explicações da Ciência de Dados, a ponto de dar-lhe autonomia para que prospecte problemas ativamente e apresente soluções conforme são desenvolvidas.
O que há de “negativo” nisso é que não pode ser treinado ou ensaiado, como programação ou fórmulas estatísticas. São habilidades que só se desenvolvem na lida diária, com questões e pessoas dentro de um ambiente e cultura específicos. Mude esse ambiente e cultura — vá para outra empresa, por exemplo — e o resultado pode ser muito diverso.
Tal aprendizado vem da convivência, da capacidade de se perceber o próprio comportamento dentro dela (autoconhecimento), da postura ao se colocar em explanações e discussões e da habilidade de aprender com os “erros” ou “gafes”, que inevitavelmente irão ocorrer.
Em organizações mais inovadoras, que cresceram baseadas em dados ou que desenvolveram uma cultura de dados, provavelmente o profissional terá acompanhamento no aprendizado, não cairá em projetos críticos de imediato e contará com pessoas seniores ao lado. O desafio pode ser mais em aprender rapidamente e acompanhar as discussões.
Em outros ambientes, onde há menos alinhamento, podem ocorrer mais atritos e dificuldades. Cabe ao profissional entender as circunstâncias e agir conforme as possibilidades, na tentativa de construir relações com pessoas com quem possa colaborar e aprender.
Conhecer o clima organizacional, as pessoas que compõem a empresa e seus níveis de poder e relacionamento interno, aliado a um entendimento da parte técnica (processos de negócio, infraestrutura, dados etc.) fornece um mapa interessante para fazer Ciência de Dados de forma mais eficiente e, por que não, divertida.
O interesse em resolver problemas (entender profundamente o que ocorre para propor e desenvolver soluções), mais do que otimizar algoritmos, pode, inclusive, ajudar a empresa em outros aspectos.
No levantamento de um problema de negócio, o profissional pode perceber que determinados dados poderiam ser melhorados com pequenas correções no processo de negócio, o que geraria benefício a todos, a longo prazo. Pode ajudar a educar pessoas de outras áreas sobre como entender os dados ou colher insights úteis a outros projetos.
Às vezes, o profissional vai perceber facilmente que uma determinada equipe de negócio gosta de reuniões regadas a brincadeiras, “causos” da vida profissional, fatos corriqueiros e que, por mais que consigam intuir um problema ou solução, nem sempre conseguem expressá-los com rigor e precisão como a Ciência de Dados requer.
Um data scientist que souber se relacionar com essa equipe e auxiliar nessa tradução da percepção inexata do negócio para a precisão da Ciência de Dados, pode se tornar mais valorizado por esse talento do que por conhecer os todos os algoritmos de machine learning da moda. Inclusive, para o negócio pouco interessa a tecnologia usada (meio). O importante são os resultados (fim), os objetivos que o negócio atingirá com as soluções desenvolvidas.
Aprender a observar, perguntar e conhecer a fundo o negócio, seus processos e pessoas, desde o início da carreira e em cada empresa por onde o profissional atuará, fornecerá benefícios para sua evolução no “entendimento do negócio” em Data Science, no relacionamento com a organização e na entrega de soluções não só eficientes, mas efetivas.
“Os problemas mais difíceis [em Data Science] são aqueles complicados de medir, como: fazer as perguntas certas, obter suporte e acesso a dados, converter descobertas interessantes em algo prático, comunicar descobertas diferenciadas a um público impaciente e não técnico que pode ter medo de números, matemática e estatísticas, persuadir alguém a tomar ou mudar um curso de ação com base em insights baseados em dados. Ferramentas são apenas ferramentas. Habilidades podem ser aprendidas. Os processos podem ser automatizados… Mas mudar a opinião de alguém é difícil. Principalmente quando esse alguém é mais experiente do que você.” — de outro cientista de dados, no Quora.
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.