Os métodos ágeis de trabalho alcançaram diferentes áreas e profissões, sendo uma delas a de desenvolvimento de software. Apesar de não ser a primeira coisa que vem à cabeça quando pensamos em ciência de dados, muitos cientistas de dados trabalham de forma semelhante a pessoas desenvolvedoras de software, seja confeccionando pequenas rotinas de programação ou participando da elaboração do produto em si. Dessa forma, alguns tradeoffs que surgem ao longo da carreira desses profissionais também surgem na de cientistas de dados.
Um tradeoff particularmente relevante no dia a dia de trabalho é o que diz respeito ao desenvolvimento de códigos focados no curto versus longo prazo e como isso se relaciona com a metodologia ágil. Suponha que uma empresa meça a produtividade de um time com base no número de entregas e que use o Scrum para seus desenvolvimentos. A cada sprint (ou ciclo de desenvolvimento), um código é possivelmente gerado, testado e colocado no ar. Pode-se esperar que, com o tempo, esse time priorize a velocidade ao custo de manutenção de longo prazo dos códigos.
A conta é relativamente simples: com mais entregas, o time se torna mais produtivo e é recompensado por isso, agradando a todos. Assim, desenvolvimentos rápidos, com foco principal na entrega e não no custo de manutenção, parecem mais vantajosos num primeiro momento. Com o passar do tempo, a equipe acumula códigos e, naturalmente, surgem os temidos bugs.
Bugs são praticamente inevitáveis (mesmo que se tenha o melhor departamento de Quality Assurance) e deixam claro o quanto o time se preparou para isso durante o desenvolvimento. Se a equipe foi acumulando dezenas de códigos escritos de forma rápida, relacionando-os sem uma estrutura bem desenhada, criou-se uma bomba com dezenas de fios emaranhados e, quando surgirem os bugs, a decisão do fio a ser cortado se tornará uma tarefa árdua.
Vamos esclarecer melhor esse ponto trazendo exemplos do dia a dia. Quantas pessoas desenvolvedoras nunca se depararam com a decisão de, ao surgir um bug, colocar um condicional (o famoso "if") no código para solucionar tal problema? Esse hábito gera soluções e entregas rápidas, mas torna o código cada vez menos inteligível. Outro exemplo comum é abrir mão de boas práticas (como uma função bem documentada internamente) para agilizar a entrega.
Nos exemplos acima, a pessoa desenvolvedora que gerou as rotinas é, provavelmente, a mais indicada para fazer a manutenção do código com maior fluidez. Note que isso gera alta dependência de alguns indivíduos do time, o que pode ser muito prejudicial para a empresa na ausência desses funcionários.
Mas, então, por que não priorizamos desenvolvimentos focados no longo prazo? Acredito que a resposta resida justamente nesse tradeoff de produtividade gerado entre desenvolvimentos de curto e longo prazo. O aumento da produtividade (medido em termos de entregas por determinado período de tempo) beneficia e eleva o moral do time no curto prazo, além de possivelmente trazer resultados interessantes em termos de receita para a empresa. No médio/longo prazo, a produtividade do time cai, os bugs levam cada vez mais tempo para serem corrigidos e, em algum momento, a equipe deixa de criar para somente fazer a manutenção em desenvolvimentos antigos.
Então, afinal, como conciliamos metodologia ágil com uma produtividade estável no longo prazo? A melhor ferramenta para isso é termos objetivos claros, caminhos bem traçados e um time rigoroso em relação à qualidade dos desenvolvimentos. Com objetivos claros e passos detalhados, o time se motiva, pois observa que aos poucos se aproxima do objetivo final, a pressão da entrega por ciclo de desenvolvimento (muitas vezes relacionada à metodologia ágil) é aliviada e se abre espaço para a discussão de melhores caminhos, sabendo que decisões de hoje podem afetar colegas de trabalho amanhã.
Longe de ser fácil, essa tarefa parece ser o grande desafio de gestores de times de ciência de dados, especialmente se aliarmos a isso a necessidade de viabilizarmos o funcionamento da empresa com a geração de receita. É necessário criar pilares sólidos para a construção de novas rotinas, algoritmos e procedimentos, beneficiando a todos.
Matheus Sesso Gay, Auto ML & Time-Series Lead na 4intelligence.
