Métricas ágeis para times de pesquisa e desenvolvimento

Independente da sua posição em um time de desenvolvimento de software e de qual processo vocês utilizam para a construção do produto ou projeto, invariavelmente você vai se ver, em algum momento, numa discussão sobre desempenho e métricas de desenvolvimento.

"O que pode ser medido pode ser melhorado"

Peter Drucker, um dos grandes homens da administração moderna, comentou sobre a importância da medição — em qualquer que seja o contexto — para a melhoria. E desde que o processo de desenvolvimento de software surgiu, as métricas para melhorar este processo apareceram também.

Durante minha vida neste meio, já passei por diversas destas discussões sobre métricas. Foram papos desde pontos de função e hora-homem (sinta-se feliz caso não saiba sobre o que são esses termos) passando por discussões sobre velocidade, até sobre discussões a respeito de lead time e throughput.

E este tema é bem polêmico. Primeiro porque o sistema de indicadores precisa mostrar quantitativamente “aquilo que precisa ser visto”, e não apenas “aquilo que queremos ver”. No livro Lean Startup, Eric Ries define isto como métrica de vaidade — quando uma métrica não reflete diretamente o desempenho do produto. Um exemplo disto é quando um time se direciona pelo número de curtidas da pagina numa rede social, ao invés do número de usuários ativos únicos ou compras recorrentes. Isso pode parecer simples, mas não é.

Outra disfunção envolvendo métricas, é quando elas são aplicados como ferramentas que enxergam e simplificam o time como um número. Com isso, acabam sendo utilizadas como mecanismos de cobrança e criando conflitos destrutivos dentro e fora do time. Como quando o time passa a medir o número de entregas individuais dos seus elementos ou o número de bugs que cada um gera na aplicação.

Uma pegadinha também relacionada ao tema, é a relação entre eficiência e eficácia. Enquanto o primeiro resume-se em ter um fluxo de trabalho e um ferramental que permitam entregas constantes, com qualidade e com um desperdício mínimo, o segundo está relacionado a saber priorizar as iniciativas corretamente com a finalidade de resolver os problemas.

Mas falando do lado de cá da força… Existem outros muitos materiais que mostram como enxergar as métricas de uma maneira correta. Alguns que recomendo são: How To Not Destroy your Agile Team with Metrics, Métricas Ágeis: O que Lead Time e o Throughput revelam para nós, os livros Métricas Ágeis — Obtenha melhores resultados em sua equipe, Agile in Actions e Actionable Agile Metrics for Predictability.

Nos times de desenvolvimento em que pude atuar, utilizamos várias métricas que foram úteis para os contextos. Já tive a oportunidade de usar velocidade (baseada em pontos do poker planning e em histórias — quando já tínhamos um tamanho padrão), burn-up, burn-down, BCP (algo semelhante ao BVP da Taller) throughput, lead time, histograma e Cumulative Flow Diagram (CFD), entre outros. Porém, neste último ano estou atuando em times de pesquisa, focado no trabalho de cientistas e engenheiros de dados, e venho enfrentando diversos dilemas de como medir a evolução e desempenho destes times.

Como medir e quais as métricas mais aderentes quando estamos falando de times de pesquisa, inovação disruptiva e técnicas de machine learning? E ainda mais complexo, como medir a evolução destes times?

As métricas ágeis vem evoluindo significativamente quando se fala de times de desenvolvimento (sejam eles de produto ou operação), mas o trabalho exploratório e investigativo de um cientista de dados ou pesquisador corporativo é um desafio a parte.

Uma tarefa de pesquisa de um algoritmo, experimentação e exploração em um certo contexto é mais desafiador do que uma nova feature de um produto: possui uma imprevisibilidade maior e o resultado pode ser o descarte da hipótese antes mesmo de validá-la em produção — como ver que a aplicação de redes bayesianas não se aplicam ao contexto de predição de demanda, ou que o minhash aplicado ao título de produto não gera boas similaridades de produtos.

No contexto dos times que venho atuando, iniciamos o uso de throughput e lead time no time. Mas as oscilações que estes números apresentavam não caracterização necessariamente a evolução ou não do time. A mediana do lead time (ou mesmo o percentil) aumentar pois enfrentamos um período de longas pesquisa de algoritmos para solucionar um problema complexo, não reflete necessariamente em uma perda de desempenho do time. Ou mesmo o throughput médio de uma demanda usando reconhecimento de imagens a partir de descritores não dava a previsibilidade sobre uma demanda de montagem de modelo preditivo usando técnicas de série temporal.

Estes pontos apareceram diversas vezes no contexto do time. As discussões sobre o desempenho não coincidam com os números do time — e para os dois lados: as vezes o time se sentia mais produtivo e outras menos do que os números apontavam. Afinal, pra que mapeamos e extraímos métricas que não são aderentes pra gente? Não estávamos vendo uma conexão clara entre as métricas e nosso sentimento de desempenho.

Foi então que nos deparamos com Hypothesis-Driven Development e passamos a utilizar o número de hipóteses validadas como métrica do time — ao invés de histórias de usuário. As hipóteses nos auxiliaram com uma das nossas dores, pois nos dava uma liberdade maior do descarte de uma pesquisa. Dessa forma, passamos a medir o número de hipóteses que testávamos por período e o número de tarefas de desenvolvimento dos projetos.

Portfólio do time de dados

Isso fez com que tivéssemos um equilíbrio maior entre pesquisa e descoberta e o desenvolvimento das atividades conhecidas dos projetos que estávamos tocando. Então, quando o throughput semanal tinha uma queda, conseguíamos ver o esforço de pesquisa aumentar.

Porém, nos fez pensar sobre aquela pegadinha de eficiência versus eficácia. Afinal, o que seria um time de alta performance de pesquisa? O que pesquisa mais ou o que entrega mais resultados em produção? É aquele que testa mais hipóteses ou o que vai mais fundo nos problemas?

Pra gente — leia-se o que faz sentido pra gente no nosso contexto e que não necessariamente fará para o seu — o que importa é usar a tecnologia para uma finalidade bem exclusiva: resolver problemas de negócio. No nosso entendimento as nossas pesquisas, nossos dados e nossos aprendizados têm a finalidade de melhorar o nosso negócio e que nada adianta termos o melhor algoritmo ou modelo se não forem destinados a resolver um problema da empresa.

Então, faltava um integrante vital nas nossas avaliações de desempenho e passamos a utilizar também métricas de negócio como parâmetro para o time. Hoje acompanhamos basicamente dois tipos de métricas, mas com algumas tropicalizações. Medimos nosso lead time e throughput semanal (separando como classes de serviço atividades de pesquisa e desenvolvimento) e as métricas do nosso negócio.

Assim, conseguimos realizar um equilíbrio entre o quanto pesquisar e quanto desenvolver. Também conseguimos enxergar quanto de esforço técnico (visualizando através das métricas de desenvolvimento) estamos levando para mostrar valor (visualizando através das métricas de negócios).

Com este equilíbrio, tivemos uma visão mais sistêmica e trouxemos o negócio para o nosso dia a dia. E pudemos enxergar as oportunidades de aplicar ainda mais pesquisa e desenvolvimento.