Como dar mais agilidade nas entregas do time de Data Science
Quando começamos a trabalhar com ciência de dados, queremos ser ágeis igual as pessoas desenvolvedoras, mas podemos usar as mesmas técnicas que elas para sermos ágeis nos nossos projetos?
Se preferir, veja a versão em inglês, com pequenas atualizações.
No começo, quando o nosso time era pequeno, usávamos um Kanban e éramos bastante felizes. Contudo, depois de alguns meses o time foi crescendo e os stakeholders queriam saber melhor os prazos e o que faríamos para concluir os nossos projetos. Tivemos uma conversa com equipes de Data Science de outras empresas e decidimos mudar a nossa estratégia e passar a usar o Scrum.
Utilizamos Scrum por vários anos, mas com o passar do tempo eu percebi que o time não estava feliz. Tínhamos diversos problemas:
- os Pull Requests demoravam muito para serem corrigidos, mesmo que a história fosse super pequena;
- nunca (ou quase nunca) todas as cientistas conseguiam cumprir a sprint;
- os refinings demoravam muito tempo e depois de algumas conversas com stakeholders, as coisas mudavam e todo o tempo do refining era perdido;
- o time sempre subestimava os tempos e tamanhos de cada história e, com isso, os stakeholders começaram a não confiar nos nossos prazos e achar que o time era muito lento;
- não era fácil dar o tamanho de uma história que tem caráter exploratório e que, além disso, pode acabar resultando em um modelo ruim ou uma análise que não era o que faltava para melhorarmos o desempenho do modelo.
Antes de explicar em mais detalhes a nossa mudança, preciso esclarecer como trabalhamos na Creditas. O time de Data Science é um Chapter, logo estamos inseridos em algumas Tribos e trabalhamos junto de outros times para alcançar os objetivos dessas Tribos. Uma cientista normalmente lidera um projeto dentro da Tribo e as outras pessoas do time ajudam, dando ideias durante as dailies ou outras cerimônias. Em alguns momentos, é possível que duas pessoas trabalhem em um mesmo projeto, mas o mais comum é uma pessoa por projeto com o suporte das demais.
Eu achava que só porque o time usava um framework ágil, o time era ágil. Na verdade, ser ágil é responder a mudanças mais do que seguir um plano e os problemas que foram citados acima nos fizeram buscar uma nova forma de gerenciar os projetos em Data Science.
A grande mudança é que deixamos de tentar resolver todos os problemas levantados no início do projeto com a primeira versão e passamos a trabalhar em validar uma única hipótese por vez e ir criando novas versões production-ready a cada nova hipótese validada. As principais mudanças foram:
- Trabalhar com pequenas versões que poderiam ir para produção ao final do processo. As versões são priorizadas pelo maior problema que os stakeholders estão sofrendo no momento;
- O uso de soft deadlines para aumentar a criatividade do time e trazer mais previsibilidade das entregas para os stakeholders;
- O review da pesquisa é muito importante, mas era um dos maiores consumidores de tempo do projeto. Movemos essa etapa para o final.
Vou detalhar um pouco mais de cada uma dessas etapas abaixo.
Pequenas versões
A primeira versão do projeto é um MVP e depois novas versões são criadas. Dar o nome de MVP a versão baseline ajuda a alinhar as expectativas dos stakeholders e ajuda as cientistas a fazerem a menor iteração possível de um projeto que ajude a resolver o problema.
Uma das primeiras coisas que fazemos é a Compreensão do Problema e, para facilitar essa etapa, que também chamamos de Discovery, usamos o Machine Learning Canvas (ML Canvas). Usamos o ML Canvas para alinhar os objetivos principais do projeto com todas as pessoas que serão impactadas por ele. Com a pandemia, uma coisa bacana que mudamos foi o uso do Miro para realizarmos um brainstorm com todos os envolvidos e entendermos vários aspectos do projeto que vamos começar. Em breve, teremos um artigo sobre como usamos o ML Canvas com mais detalhes aqui no nosso Medium, então fique de olho!
Durante o canvas conseguimos entender os principais problemas dos stakeholders, quais bases de dados poderíamos utilizar e já conseguimos definir um MVP e ter uma ideia de quais serão as próximas versões. Digo ter uma ideia, pois após a etapa de avaliação do MVP tudo pode mudar e está tudo bem, faz parte do ciclo de vida de um projeto de Data Science ter algum grau de incerteza sobre os próximos passos.
Uma pessoa que nos ajuda bastante nas definições das versões também é a Business Partner. Ela é a pessoa especialista naquela área que iremos atuar e também o ponto focal para nos ajudar a tirar dúvidas de negócio e ajudar a priorizar novas versões. A Business Partner, garante que as entregas e as descobertas estejam alinhadas com os problemas que ela enfrenta no dia a dia. A cientista mantém um acompanhamento semanal com essa pessoa para garantir constantes feedbacks do projeto.
Soft deadlines
Passamos a usar um Kanban com as fases do ciclo de vida de um projeto de Data Science, muito similar ao CRISP-DM, que contém 6 etapas. Cada uma das etapas possui um soft deadline que acompanha uma reunião de alinhamento (ou Checkpoint, como chamamos) com os stakeholders do projeto. Isso é muito bom pois, anteriormente com reuniões recorrentes sem uma agenda específica, não tínhamos resultados consolidados para apresentar e agora podemos apresentar os resultados alinhados com o final de uma etapa, agregando muito mais valor para todos os presentes no Checkpoint.
O soft deadline também traz uma certa flexibilidade para a cientista: ela pode fazer tudo o que ela quiser/achar necessário para resolver o problema até aquela data e, em caso de erro de planejamento, ainda existe material para ser apresentado no Checkpoint e coletar feedback dos stakeholders para reduzir o escopo da versão ou pensar em realizar diferentes experimentos.
Os deadlines são soft pois eles não indicam que ao final de fato aquela etapa estará 100% concluída, eles são definidos pela cientista no início do projeto e algumas vezes logo nesse início, o alto grau de incerteza torna difícil dar um prazo bom e preciso para a finalização da EDA (sigla para Exploratory Data Analysis), que é a etapa na qual fazemos as análises dos dados que potencialmente serão utilizados na modelagem. Após o Discovery e início da preparação dos dados para EDA, já é possível agendar o Checkpoint com os stakeholders.
As datas da figura podem te impressionar e a verdade é que nem sempre eles são realidade, especialmente no caso de projetos que nunca foram feitos e que podem ter alta complexidade na etapa de preparação de dados. Contudo, já notamos melhorias em projetos que não estão mais em MVP e/ou que possuem uma etapa de preparação de dados mais conhecida por outras pessoas — nesses casos uma versão pode ficar pronta em 4 semanas.
Ter uma reunião de alinhamento com os stakeholders logo após a EDA é bastante benéfico pois nos ajuda a dar visibilidade ao trabalho do time de Data Science e também a garantir que estamos alinhados quanto aos próximos passos do projeto.
Review no final da versão
Como um dos nossos maiores problemas era o tempo de revisão da pesquisa, mudamos essa etapa para o final da versão do projeto. Você pode estar pensando que isso cria um monstro gigante de código a ser revisado — e você está correta. A grande vantagem aqui é que a pessoa que vai revisar todo o projeto vai ter uma visão de negócio muito mais precisa do que as diferentes pessoas que revisavam as diversas histórias (de apenas algumas partes do projeto) anteriormente. Em Data Science, o código no fundo é uma pesquisa e consiste de classes e métodos, mas também de Jupyter Notebooks e insights que vieram dos gráficos/dados. Ver a avaliação de um modelo sem ver a EDA deixava algumas lacunas na contribuição que as pessoas poderiam dar umas para as outras e agora isso já não existe mais.
Por causa do grande tempo gasto para essa etapa de revisão, apenas uma cientista avalia a pesquisa da outra e para os demais é opcional. É muito importante que após a avaliação uma pessoa seja a responsável por essa tarefa e também dê um deadline para ela, caso contrário voltamos a ter o grande problema de revisões que travam projetos completos.
A revisão do projeto aumenta bastante o conhecimento do time e faz com que a transição de uma pessoa para outra área seja facilitada. Quer saber mais sobre como fazemos a revisão usando o Github? Dá uma olhada nesse artigo que eu escrevi há algum tempo atrás.
Desafios e o que continuamos fazendo
Para manter a colaboração entre cientistas alta, estendemos consideravelmente o tempo das dailies. As nossas reuniões diárias contém coisas que antes só eram discutidas no PR (e só quem via o PR poderia ajudar a pessoa) e comumente tem compartilhamento de insights, códigos e problemas um pouco mais detalhados do que a daily que fazíamos anteriormente e durava apenas 15 minutos. A grande desvantagem é o tempo — ainda estamos trabalhando para entender como podemos otimizar essa cerimônia (uma das coisas que fazemos é deixá-la logo antes do almoço assim as pessoas têm fome e são mais sucintas hehehe).
Seguimos tendo as retrospectivas, que é uma boa oportunidade para contribuirmos com algo que está dando certo em um projeto e pensarmos em melhorias para o Chapter como um todo. Elas seguem sendo dos últimos 15 dias, mesmo que não tenha tido nenhuma entrega de valor durante o período.
Essa metodologia que usamos aqui é uma adaptação do que é apresentado neste artigo. Nele, para facilitar as evoluções do projeto é utilizado o Kanban com um checklist dos próximos passos. Ainda não conseguimos utilizar o Kanban dessa maneira nos nossos projetos, mas já tivemos uma imensa melhora em deadlines e alinhamentos com os stakeholders e a revisão no final de uma iteração trouxe mais flexibilidade para a cientista explorar e retomar algumas fases (como voltar para a EDA pós feature engineering), algo que era mais difícil de fazer quando tínhamos uma (ou várias) história para cada etapa. Esse processo tem funcionado bem para nós e, por isso, ainda não testamos outra estratégia. Acredito que cada time terá as suas particularidades e se adapta melhor a um ou outro framework.
E o seu time de Data Science? Utiliza algum framework como o que usamos aqui na Creditas? Como tem sido a sua utilização? Comente aqui embaixo para evoluirmos juntos!
Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa Tripulação! Você pode conferir nossas vagas aqui.
