O trade-off entre agilidade e rigor em Data Science
O que cabe ao negócio e quais métodos a Ciência de Dados tem amadurecido para combinar velocidade e precisão em experimentos e na entrega de produtos de dados
Exemplo hipotético, mas do dia a dia da Ciência de Dados. O negócio sonha com a implantação de um modelo preditivo que marketing, vendas e atendimento irão utilizar para perfilar clientes de um produto. A Ciência de Dados se empolga e acorda que, no quadrimestre, estará com uma solução pronta.
Quase um ano depois, data scientists ainda estão trabalhando além do expediente, junto de engenheiros e devops, para tentar igualar a precisão do modelo em produção com o que foi conseguido em simulações. O sonho do negócio já virou pesadelo com prejuízos: tempo gasto e clientes potencialmente perdidos.
Não faltam relatos de empresas sem cultura de dados madura, de equipes de Data Science inexperientes ou de excesso de confiança de ambas as partes que resultam em projetos demorados, desorganizados e ineficientes.
É um trade-off complicado equilibrar a pressa do negócio, otimista ou preocupado com a receita, e o rigor que a Ciência de Dados requer para garantir significância estatística em experimentos ou para atingir a precisão necessária em modelos de machine learning.
No pior dos cenários, situações como essas colocam negócio e dados em trincheiras opostas, com os primeiros acusando os segundos de enrolados e detalhistas e os segundos rotulando os primeiros de apressados e sem noção das dificuldades.
Pelo fato de a Ciência de Dados envolver mais incerteza do que o desenvolvimento de software tradicional, é necessário que ambos os lados joguem limpo, com transparência, acerca de expectativas, cronogramas e viabilidade técnica.
Mais do que Engenharia, onde é possível prever de antemão o que será construído, Data Science tem muita ciência experimental envolvida, onde hipóteses podem não se sustentar e modelos podem ser apenas representações limitadas da realidade.
O que fazer em casos como esses? Jogar a toalha e reconhecer que não há como conciliar velocidade e rigor? Brigar para que a Ciência de Dados ganhe um assento e tenha voz de comando junto do negócio, aliviando-lhe as pressões e cobranças?
Ou existem saídas que permitem harmonia entre a busca por resultados rápidos sem abrir mão de disciplina e cuidados que abordagens quantitativas requerem?
O que cabe ao negócio
Antes de limpeza de dados, análises exploratórias e performance de modelos, há aspectos em que a Ciência de Dados pode e deve opinar, mas que não cabe só a ela resolver: infraestrutura e a cultura de dados da organização e, ainda, se a vocação da empresa é pesquisa, produtos de dados ou ambos.
Infraestrutura de dados é toda a parte de armazéns e repositórios de dados, sua arquitetura e governança, o que permite ter dados organizados e de qualidade, acessíveis e recuperáveis a qualquer tempo, para responder desafios de negócio.
Cultura de dados é algo que depende das pessoas da organização. É como elas conhecem, geram e utilizam dados no dia a dia, a fim de contribuir com a governança da infraestrutura de dados. Até porque não adianta fazer input de lixo, captar informações pela metade, sem processos minimamente formalizados, e querer que Engenharia e Ciência de Dados resolvam depois. Seria o mesmo que tirar foto ruim e achar que o Photoshop fará milagres.
Vocação em pesquisa é quando o negócio é centrado em inferência estatísticas e testes A/B, por exemplo. AirBnb e Booking, como vimos em “Devemos muito aos Testes A/B”, são exemplos de empresas que fazem muitos experimentos, já que operam em larga escala e precisam conhecer o comportamento de seus vários clientes (viajantes e hóspedes em férias ou a negócios, por exemplo).
Empresas maiores podem ter setores dedicados exclusivamente a isso, o que permite mais rigor, método e menos problemas com prazos apertados ou multitarefa. Pesquisas podem resultar em relatórios ou papers e nem sempre geram implementação de alguma solução automatizada por algoritmos.
Vocação para produtos de dados, uma onda em startups e empresas atuais orientadas por dados, é a junção de testes automatizados com algoritmos de machine learning para recomendação, otimização de jornada do cliente, envio de promoções e personalização de opções. Ou, então, para a entrega de dashboards e outras soluções analíticas automatizadas no âmbito interno do negócio. Muitas empresas atuais empregam profissionais nessa empreitada.
O tratamento que o negócio dá a cada um desses aspectos é crucial para que se consiga aliar velocidade e precisão. Não é uma conta que fecha facilmente e precisa de acompanhamento e ajustes constantes para funcionar de forma azeitada.
O negócio precisa de uma certa maturidade no trato e entendimento de seus dados para que projetos de Ciência de Dados se tornem processos. Também é preciso ter uma compreensão das particularidades envolvidas na pesquisa, que pode envolver mais rigor, e em produtos de dados, que podem requerer mais etapas e iteração até resultados satisfatórios.
Om Deshmukh, um diretor sênior de Ciência de Dados em uma fintech, tem um bom artigo, “A Data Science Leader’s Guide to Managing Stakeholders”, no Analytics Vidhya, que ajuda a entender como agilizar a Ciência de Dados, sem perder o rigor, de forma transparente com os interessados do negócio. Apesar de ser específico para lideranças em Ciências de Dados, o artigo é útil para entender particularidades da área aplicada a negócios.
Segundo ele, equipes de ciência de dados devem trabalhar coletivamente com equipes de atendimento ao cliente (caberia aqui design de experiência do usuário, também) e com a equipe executiva. O objetivo é captar o que o negócio busca com precisão, assim como manter essas outras equipes atualizadas e familiarizadas sobre o trabalho da Ciência de Dados, em especial suas exigências e restrições.
Esclarecer e educar que soluções devem começar pequenas e que podem não são “perfeitas” (dependem de monitoramento e melhoria contínua) é um dos primeiros pontos a serem tratados.
Outro é fazer o negócio ao menos ter compreensão sobre rigor. Em estatística ou no aprendizado de máquina, é comum ouvir que se atingiu 76%, 85% ou 94% de precisão. Saber explicar isso é necessário para não passar a impressão de que, por não ser 100%, algo está errado ou não é confiável.
O outro conselho do lado do negócio é colocar a “Inteligência Artificial” em pratos limpos, explicar suas particularidades e exigências. Ele fala em separar o que chama de “IA do consumidor” de “IA corporativa”.
Para Deshmukh, há muita diferença entre algoritmos de recomendação de amigos em redes sociais ou de filmes na Netflix, o que ele chama de “IA do Consumidor”, onde erros não causarão danos significativos ao negócio, de “IA críticas”, que irão perfilar clientes, conceder crédito, avaliar seu histórico financeiro ou conferir placas de veículos que passam por um determinado local, como o armazém de uma fábrica ou uma barreira policial.
Erros nesses domínios podem custar muito caro ao negócio, em termos de perda de clientes e até ações judiciais. Ou seja, requerem muito mais rigor do que pressa.
Por fim, ele comenta o que cabe à própria Ciência de Dados. Diz que é necessário que a equipe seja lembrada, com frequência, a sair apenas do playground dos algoritmos e de otimizações e sempre ter em mente o problema de negócio e os cuidados necessários.
[...] se esperarmos que a solução seja perfeita, podemos acabar com uma solução perfeita, mas tarde demais. Ou pior, perfeito para resolver um problema que tem apenas um valor extra marginal — Om Deshmukh.
A criação de alguma proteção (ambientes, momentos etc.) para que a equipe possa se concentrar em tarefas técnicas e analíticas, sem estar em contato o tempo todo com pedidos e prazos, também é recomendável para um bom andamento do trabalho.
Adam Waksman e Elliot Waldrom, do Foursquare, em artigo “How Data Scientists Can Balance Practicality and Rigor”, no Towards Data Science, comentam o equilíbro entre pragmatismo (que dá velocidade) e rigor em equipes de dados.
“Uma abordagem eficaz para escalonar a tecnologia nesses ambientes [startups] deve incorporar uma combinação de métodos que sejam rigorosos, interpretáveis, defensáveis e alinhados aos negócios” — Adam Waksman e Elliot Waldrom.
Para eles, ser pragmático é “impactar o negócio”. Dados e modelos não devem ser pensados a não ser em estreita conexão com as perguntas e objetivos do negócio, para evitar desperdícios de tempo e recursos.
Também destacam que soluções convencionais em pesquisa ou desenvolvimento de algoritmos, notadamente acadêmicas, não servem muito bem aos negócios.
O que sugerem é adaptar abordagens do Agile, já estabelecido no desenvolvimento de software tradicional, para a Ciência de Dados. Em especial, recomendam começar com modelos simples de pesquisa ou de produto de dados e ir repetindo abordagens alternativas incrementais para qualificá-los com o tempo.
Apesar de parecer fácil, usar Agile é um tópico exigente e que tem seus prós e contras, como aprofundaremos na próxima sessão.
Cassie Kozyrkov, cientista chefe de Decisão no Google, em artigo “Data Science’s Most Misunderstood Hero”, também na Towards Data Science, sugere que pode ser uma boa compreender a importância de especialidades separadas em equipes de dados, sem a busca de “full-stacks” ou “unicórnios” três-em-um, que reúnam qualidades de estatísticos, analistas e engenheiros de aprendizado de máquina. A tríade, segundo ela, pode equilibrar a busca por rigor, desempenho e velocidade.
“Estatísticos trazem rigor, engenheiros de ML trazem desempenho e analistas [business analytics] trazem velocidade” — Cassie Kozyrkov.
Ou seja — e ela é do Google, o que lhe dá alguma propriedade para falar, dado a escala em que a empresa opera — uma equipe com conhecimentos diversificados, um trabalho essencialmente de time, é uma saída para o dilema entre pressa e cuidados.
Kozyrkov tem muitos artigos sobre os desafios da Ciência de Dados em negócios. Em um deles, no Hackernoon, ela chega a propor a divisão da Ciência de Dados em dez — dez! — especializações. Talvez seja algo muito mais acessível ao Google do que a muitas outras empresas, mas pode ser um caminho que a área acabará tomando no futuro, à medida que a complexidade aumenta.
Para ela, também deve haver compreensão sobre a mentalidade de quem vem da Estatística, sobre os engenheiros de Machine Learning e sobre o pessoal de Business Analytics. Seus conselhos e opiniões são diretos e fortes.
Sobre estatísticos, que podem ser ótimos para pesquisa, inferência e testes A/B rigorosos:
[...] estatísticos são a sua melhor proteção contra se enganar em um mundo incerto. Para eles, inferir algo descuidadamente é um pecado [...]
O que a maioria das pessoas não percebe é que os estatísticos são essencialmente epistemólogos. Uma vez que não há mágica que produza certeza da incerteza, seu papel não é produzir a verdade, mas sim uma integração sensata de suposições palatáveis com as informações disponíveis.
Quanto a engenheiros de Machine Learning, ela diz que é importante entenderem quanto tempo demoram para “tunar” modelos:
[...] especialistas em aprendizado de máquina sabem que não encontrarão a solução perfeita em um livro didático. Em vez disso, eles se envolverão em uma maratona de tentativa e erro. Ter uma ótima intuição de quanto tempo eles levarão para tentar cada nova opção é uma grande vantagem e é mais valioso do que um conhecimento íntimo de como os algoritmos funcionam (embora seja bom ter os dois) — Cassie Kozyrkov.
Sobre os business analytics, que, segundo ela, podem se sentir “especialistas menores” do que data scientists, Kozyrkov os defende como os melhores profissionais para negócios em estágio inicial, onde a necessidade não é fazer inferências em grandes bases de usuários ou desenvolver sistemas sofisticados de IA, mas, primeiro, entender o próprio negócio.
Os melhores analistas [business analysts] são codificadores ultrarrápidos que podem navegar em vastos conjuntos de dados rapidamente, encontrando e revelando insights em potencial mais rápido do que aqueles outros especialistas.
Onde os estatísticos e o pessoal do ML são lentos, os analistas são um turbilhão de inspiração para tomadores de decisão e outros colegas de ciência de dados.
[...] os analistas são os herdeiros mais prováveis do trono de decisão.
Este e outros artigos de Kozyrkov tratam muito do fenômenos (comum nos EUA, onde a oferta de profissionais é maior) de empresas que empregam PhDs de domínios ultra-acadêmicos, como Física Teórica, sem que o negócio entenda de si mesmo, o que traz menos entrosamento e mais lentidão aos projetos de dados.
No livro “Agile Data Science 2.0”, de 2017, Russell Jurney é mais incisivo e diz que equipes de ciência de dados devem ser montadas a dedo com algumas características:
deve ter generalistas em vez de especialistas (se possível profissionais que dominem mais de uma área ao mesmo tempo, o que dá flexibilidade ao time);
devem ser pequenas;
devem usar ferramentas de alto nível (computação em nuvem, plataformas como serviços), que permitem um processo mais suave de trabalho; e
devem fazer compartilhamento contínuo e iterativo de “trabalho intermediário”, mesmo que esteja inacabado.
Assim como Waksman e Waldrom, Jurney também diz que ambiente adequado influencia na agilidade da Ciência de Dados.
Isso tudo é sobre o negócio. Sem infraestrutura e cultura de dados minimamente estabelecida, há muito mais trabalho de engenharia de dados e mudança de mentalidade a fazer (talvez o Excel ou o Google Planilhas ainda seja suficiente por um tempo) do que se preocupar com Ciência de Dados ou ML em produção.
Mas digamos que isso já foi superado, que a startup está em crescimento ou a empresa já amadureceu, e o profissional entrou com o carro rodando.
Maior complexidade, mais processos, muito mais níveis de comunicação e especialização, também impactam em menor agilidade. Na mesma linha, maior escala, criticidade, mais soluções em produção, requerem mais rigor.
Como equilibrar todos os pratos dentro da própria Ciência de Dados?
O que cabe à Ciência de Dados
Por ser uma disciplina bastante nova, forjada na prática e que requer muita criatividade e raciocínio analítico ao mesmo tempo — ou seja, não é um processo que você implanta e ele funciona como uma esteira de linha de produção —, a Ciência de Dados ainda aprimora o que seria mais eficiente em combinar rigor estatístico com agilidade de negócios.
Às vezes, infelizmente, só se descobre o “como fazer” depois de muita e tentativa e erro, noites em claro tentando entender porque o modelo em batalha não performa como nas simulações ou, para piorar, cara feia e perda de confiança de pessoas do negócio por prazos mal estimados.
“Esses caras são tão bons em estatística e matemática que mal conseguem calcular o prazo do trabalho deles”, pode ser a piada cochichada no negócio.
A solução mais comum é adaptar princípios da Metodologia Ágil, do desenvolvimento de software, para o mundo dos dados. Há vários relatos e até livros sobre a experiência.
O que é possível depreender deles é que nem tudo são flores, mas, com disciplina e trabalho em equipe, é possível deixar o negócio mais saciado e trabalhar com alguma tranquilidade.
Vamos começar pelos pontos negativos, até porque as restrições ajudam a entender os benefícios. Antes, porém uma palavrinha sobre waterfall.
A metodologia “em cascata”, muito comum nas indústrias de bens físicos (por exemplo, a automotiva, já que não é possível entregar um carro sem as rodas ao cliente e incrementá-las depois), por um tempo pareceu a receita para Data Science, como se não houvesse alternativas.
A mentalidade de experimentos que muitos profissionais herdaram da academia e o rigor até excessivo levaram a pesquisas ou a produtos de dados feitos do começo ao fim sem interação ou exposição a outras áreas.
O fato de a Ciência de Dados não se encaixar no desenvolvimento de software tradicional (e este, muitas vezes, não entendê-la) facilitou o trabalho em silos, com Data Science habitando seu mundo até se certificar que uma solução funcionava, o que era um convite à otimização sem fim e a busca de modelos perfeitos só em teoria.
A evolução dos negócios, a competição e a necessidade de retorno sobre investimentos que o capital de risco impôs obrigou a mudanças.
A Ciência de Dados teve de deixar de lado o que o negócio chamaria de “nerdice” e aprender a ser pragmática, mesmo que a pesquisa tivesse precisão abominável a estatísticos ou a aplicação de ML fosse entregue em código macarrônico.
Eis, então, as descobertas dos problemas. Primeiro, a Ciência de Dados não é “determinística”, passo a passo, como o desenvolvimento de software. É muito mais difícil projetar e antever o que será construído para depois construí-lo.
Com método, ferramentas e time capacitado, o desenvolvimento de software consegue entregar código de forma incremental e rotineira, o que está no espírito do Scrum e outros processos de entrega contínua.
A Ciência de Dados se via em confusão: não há como mandar uma pesquisa por partes e ir melhorando-a com o tempo e não faria sentido acoplar um sistema de ML mal feito em alguma aplicação, até pelo trabalho que esse acoplamento exigiria.
Para piorar, data scientist ainda codificavam em R, enquanto o desenvolvimento trabalhava em Java ou C++. Quando muito, chegava alguém com Python (dominante hoje), que, ainda assim, podia ser mal visto por desenvolvedores habituados a linguagens tipadas e de alto desempenho. Não foram fáceis aqueles primeiros dias.
A lista de contras segue. Como o artigo “Using Agile Methodologies in Data Science” e o e-livro “Agile Data Science with R”, de Edwin Thoen (sim, ele criou uma metodologia para entrega ágil de Data Science em R!) destacam, a pesquisa pode ser difícil de encaixar em métodos ágeis.
Isso porque ela não é um processo linear e, sim, circular, em que você explora dados, testa hipóteses, valida, constrói modelo estatístico e, a partir deste, reitera o mesmo processo, até refinar cada etapa e ter modelos mais precisos.
“Simplesmente não podemos garantir que um modelo estatístico ou algoritmo de aprendizado de máquina será aprimorado em duas semanas, porque não sabemos se as hipóteses que vamos testar levarão a alguma coisa. Se tivéssemos nos comprometido com um conjunto de tarefas por um período de tempo fixo do qual não podemos nos desviar, ficaríamos mais lentos porque não poderíamos agir diretamente com base nos insights recém-adquiridos.” — Edwin Thoen.
Alcançar precisão em experimentos e testes estatísticos é outro porém. Você pode atingir determinado grau de precisão (75% ou 85%) com um teste rodando durante um período, mas para que se atinja alguns pontos percentuais a mais, você precisa aumentar a amostra, o que, em se tratando de produtos de dados, significa manter os testes rodando por mais tempo.
Quanto tempo a mais? Nem sempre se sabe, talvez semanas, meses. Então, para-se o teste e joga-se o experimento no lixo? Aceita-se a precisão baixa (com os riscos envolvidos)? Ou deixa-se o teste rodando mais tempo, mesmo se saber se atingirá a precisão desejada? Agora, explique isso para o negócio, que está na expectativa de resultados rápidos.
Outra dificuldade é que o caráter iterativo, de Q&A (Questions e Answer) em que a Ciência de Dados faz explorações e constrói aplicações, popularizada pelo Jupyter Notebook e RStudio, dificilmente resulta em software adequado para ser implantado em produção.
O data scientist, então, deve aprender a entregar solução em conformidade com o que o desenvolvimento especifica. Outro caminho é que a solução seja traduzida para que um desenvolvedor a reconstrua de forma escalável, talvez até em linguagem de programação diferente. Ou seja, gargalos a mais.
Há ainda as divergências de amostras de dados usadas em simulações, quando se está preparando um experimento ou fazendo um protótipo de produto de dados, e os dados recebidos em pesquisas ou processados por algoritmos já em produção.
Às vezes, percebe-se que os dados do mundo real trazem mais complicações que aqueles usados em testes e simulações, o que requer trabalho constante de acompanhamento. E não há como se livrar desse risco, apenas colocá-lo em limites aceitáveis.
Parece que o jeito é jogar a toalha, mas há saídas. A primeira delas é um conselho de Cassie Kozyrkov, já citada, quando fala de business analytics, e que ela reformula em outro artigo, “Rethinking Fast and Slow in Data Science”, no Hackernoon:
“Aqui está o truque mental: permita que sua abordagem seja desleixada no início e queime um pouco de seu tempo, energia e dados iniciais [...]” — Cassie Kozyrkov.
Como fazer isso? As dicas que ela dá são:
usar dados de baixa qualidade (amostras pequenas, dados sintéticos, e amostra não aleatória para obter insights sobre o próprio processo de coleta de dados;
começar com modelos aproximados ou mesmo com algoritmos ruins, que pelo menos fornecem um ponto de partida, em vez de perder tempo com a melhor solução;
fazer comparações múltiplas em vez de escolher um único teste de hipóteses; e
permitir-se jogar coisas fora e tentar novas abordagens rápidas.
A coisa fica mais séria em experimentos críticos, como em saúde, por exemplo. Mas para mostrar que também há saídas, Kozurkov cita Yotam Dreschslet, da BrainQ, startup que fornece equipamento baseado em IA para identificar padrões em ondas cerebrais e fornecer tratamento eletromagnético a pacientes com problemas neurológicos — inovação com cara de ficção científica.
Em “Running Agile Machine Learning Experiments”, Dreschslet relata alguns dos aprendizados, já que pesquisa médica envolve regulamentações e muita seriedade em experimentos, ainda mais em se tratando de questões neurológicas. Definitivamente, não é como recomendar filmes ou produtos.
Documentação rigorosa e um processo de priorização de experimentos, entre todos os possíveis, ajudou a empresa a só investir e conduzir testes que são seguros e viáveis, em vez de atirar para todos os lados.
Os componentes de experimentos também foram modularizados para serem reaproveitados. Tudo isso torna falhas menos graves. E mesmo se elas ocorreram, há processo de detecção e aprendizado rápidos, por meio de determinados padrões.
É claro que a empresa tem a vantagem de ser data-driven em sua essência, ou seja, os dados praticamente dirigem o negócio, o que torna não só mais fácil de pensar em métodos o tempo todo, mas absolutamente crítico e necessário.
Edwin Thoen, em seu e-livro, fala que o uso de quadros de tarefas como kanban, em vez de processos como o Scrum, também facilita um trabalho ágil em dados.
A adoção da prática de user stories é outra recomendação, além de se contar com um Product Owner de dados (hoje já está se popularizando o Data Product Management). O papel desse profissional é priorizar tarefas e setar visão, no caso de produtos de dados, o que orquestra o trabalho dos cientistas e os libera para focar no que interessa.
As demais dicas que ele dá são voltadas a código em R e não cabe detalhar aqui, mas podem servir a quem quiser uma visão mais abrangente da experiência.
Um modelo mental que parece mais robusto é o de Jurney, em Agile Data Science 2.0. Ele elenca sete pontos que descreve como o “Manifesto Ágil de Data Science”:
Iterar, iterar, iterar: tabelas, gráficos, relatórios, previsões.
Envie a produção intermediária. Mesmo experimentos fracassados têm resultados.
Experimentos de protótipo em vez de tarefas de implementação.
Integre a opinião “tirânica” de dados na gestão de produtos.
Escale para cima e para baixo na pirâmide de valor dos dados.
Descubra e persiga o caminho crítico para um produto matador.
Descreva o processo, não apenas o estado final.
Um resumo de cada ponto no primeiro capítulo do livro, que é público.
Entretanto, o que Jurney traz de mais interessante e o que chama de “Pirâmide de Valor dos Dados”, um modelo mental baseado na Pirâmide de Necessidades Humanas de Maslow, reproduzida abaixo.
O objetivo da pirâmide é hierarquizar o que deve ser atacado e priorizado conforme se avança e se itera em entregas da Ciência de Dados:
O primeiro nível, o pipeline, é onde estão os dados. É preciso ter o encanamento de dados funcionando para que a Ciência de Dados faça seu trabalho.
A segunda camada é de gráficos e tabelas que exibem dados e permite entendê-los em termos de quantidades, qualidades e características.
A terceira é a de relatórios, em que os dados são sumarizados em informações úteis.
A quarta camada é de previsões — elas exigem que as camadas abaixo sejam satisfeitas, o que ajuda a entender onde se precisa chegar e, se ocorrerem, onde procurar erros.
A quinta camada é onde os algoritmos de machine e de deep learning estão fazendo o trabalho, como sugerir rotas de trânsito, recomendar produtos, perfilar usuários ou até guiar empilhadeiras em depósitos da Amazon.
“O foco está em documentar o processo analítico em oposição ao estado final ou produto que buscamos. Isso nos permite ser ágeis e enviar conteúdo intermediário à medida que escalamos iterativamente a pirâmide de valor dos dados para buscar o caminho crítico para um produto matador.” — Russell Jurney.
Resumindo e indo além
A combinação de rigor com agilidade pode ser entendida como uma busca por eficiência em métodos de trabalho e na comunicação entre as partes interessadas.
A comunicação é essencial na interação da Ciência de Dados e negócios. Ambos precisam se aproximar e entender, minimamente, a língua um do outro, para que ou a pressa ou a insegurança não falem mais alto.
É benéfico, como se viu, a Ciência de Dados expor e explicar seu trabalho e permitir um acompanhamento em tempo real do que está sendo feito e até das dificuldades. Isso ajuda a educar outras áreas sobre suas particularidades.
Dentro da própria Ciência de Dados, uma mentalidade mais aberta a soluções “boas o suficiente” e não “perfeitas” é o caminho para se evitar o rigor e polimento excessivo de experimentos e algoritmos.
Uma boa dica é delimitar bem o que será feito e começar com o mínimo necessário. Resolvida uma parte, pode-se incrementá-la com novas entregas, especialmente em se tratando de produtos de dados.
Aprender algumas das metodologias e especificações de trabalho do desenvolvimento de software é útil, até porque data scientists estarão bastante próximos de devs no dia a dia. Mais importante, porém, é saber o que funciona para a empresa onde se está, já que as práticas podem mudar de uma para outra.
Um pouco de paciência pode ser necessária com projetos complexos. Estabelecer processos e organização na Ciência de Dados ajuda a suavizar o trabalho e a focá-lo nos problemas realmente difíceis.
Como diria James Clear, autor de Atomic Habits, em um de seus boletins semanais:
“Precisamos redefinir ‘trabalho árduo’ para incluir ‘raciocínio árduo’. [...] Normalmente, o trabalho mais difícil é pensar em uma maneira melhor de fazê-lo.” — James Clear.
O Data Science Project Management, por fim, também tem conteúdos úteis sobre agilidade na Ciência de Dados. “Agile Data Science” possui um roteiro completo e “Is Agile a Fit for Data Science?” tem tabelas que ajudam a pensar em fatores pessoas e de projetos que podem facilitar ou dificultar um trabalho ágil na área.
O assunto seguirá amadurecendo e é provável que, aos poucos, sejam encontrados processos um tanto mais “universais”, facilmente transpostos de um negócio a outro. Estamos na juventude da Ciência de Dados e há muito a consolidar no campo, principalmente em termos de processos.
Melhorias passam por debate e consensos. Então, fiquem à vontade para estender o assunto nos comentários, contribuir com outras experiências ou mesmo sugerir novos temas que gostariam de ver tratados aqui na Newsletter. Iremos levar os insights em conta para as próximas edições.
A quem se interessar, fica o convite para conhecer também nossa Newsletter sobre Product Management e UX Design. Como Data Science acaba se relacionando com essas áreas, pode haver insights de lá que sejam interessantes aqui. O texto da semana (01/07/2021), por coincidência, usa a pirâmide de Maslow, citada acima.
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.