No artigo Métricas – Como medir a agilidade do seu time falamos do porquê e de como medir um time ágil utilizando as 4 Áreas de Domínio da Agilidade. Ali escrevemos uma das nossas frases favoritas e que é um aviso: Métricas moldam comportamentos. Esse aviso é importante, pois temos que ter muito cuidado com métricas que podem ser insignificantes ou até mesmo atrapalhar nosso trabalho. Neste artigo escreveremos sobre as métricas tóxicas que contaminam o ambiente de trabalho e reduzem a agilidade e a motivação do time.
Medir o indivíduo
Algo que não é incomum encontrarmos em empresas é a medição dos indivíduos do time. Já vimos quadros com coisas do tipo: Total de tarefas entregues por Fulano, quantidade de bugs corrigidos por Beltrano. Já vimos até foto de “Funcionário do Mês” que foi a pessoa que entregou mais funcionalidades na Sprint. A princípio parece uma métrica boa, pois irá estimular as pessoas a entregarem mais e mais. Como se fossem vendedores de loja tentando bater metas.
O problema é que estamos falando de ambientes complexos e trabalhadores do conhecimento. Saber compartilhar informações e ajuda mútua é fundamental para que o produto seja desenvolvido e aperfeiçoado pelo time. A medição individual estimula a competição e reduz a cooperação. Se eu sou medido por entregar tarefas, funcionalidades ou corrigir defeitos, eu não tenho tempo para parar e ajudar algum membro do time. Também não tenho tempo para parar e avaliar se estamos atingindo os objetivos de negócio ou se o produto realmente satisfaz as necessidades de meus usuários e clientes.
Comparar Times
Outro erro comum é tentar utilizar métricas para comparar times que atuam em produtos e contextos diferentes. Por exemplo, imagine dois times, sendo que um é responsável pelo portal de vendas e o outro é o responsável pela assistência ao cliente e ambos utilizam o Net Promoter Score (NPS) para avaliar a satisfação do usuário. Comparar o NPS desses dois times não é uma boa ideia, pois quando o cliente compra um produto ele está bem humorado e satisfeito com a aquisição. Já quando alguém entra em contato com a assistência ao cliente é porque algo não está bem. Pode ser que o problema seja justamente no portal de vendas como falta de informação, pedidos errados, etc. Todavia o reflexo acaba atingindo negativamente o NPS do atendimento ao cliente.
Comparação de times com User Story Points
Utilizar User Story Points (Pontos por História de Usuário) ou qualquer outra métrica de esforço para comparar performance entre times é uma abominação. A não ser que você queira ser enganado, não faça isso em hipótese alguma. O propósito dessa estimativa é fazer com que o time descubra qual a velocidade do time e que isso o auxilie a discutir e negociar quais histórias entrarão e quais ficarão de fora da próxima Sprint.
Comparar as especialidades do time
Também já estive em outra comparação com efeitos nefastos. Foi um time em que os desenvolvedores do aplicativo para Apple competiam com os desenvolvedores do aplicativo para a Google. As notas na App Store e Google Play eram a medida primária desse embate. Resultado, os desenvolvedores não se ajudavam por nada. Na verdade, quando juntos, um ficava de costas para o outro. Pareciam que iam começar um duelo.
Isso quer dizer que se a nota de um aplicativo na App Store for muito alta e a nota na Google Play for muito baixa eu não devo levar isso em consideração?
De forma alguma, as notas são importantes para medir a satisfação dos seus clientes. Ao invés de utilizá-las para promover competição, use-as para promover a cooperação. Por exemplo: o que nós sabemos e fazemos que uma nota seja alta em uma loja de aplicativos e baixa na outra? Como os desenvolvedores juntos podem encontrar uma forma de melhorar a experiência do usuário na loja com a nota mais baixa? São os mesmos tipos de cliente? E por aí vai.
Métricas da vaidade
Há algum tempo, recebi um e-mail de uma empresa dizendo o quanto alguns dos seus aplicativos eram bem-sucedidos. Eles tinham atingido a marca de milhões de downloads. Por curiosidade resolvi ver os números desses aplicativos na Google Play e me deparei com uma cena bem ruim. A nota média dos aplicativos era 2,7 e a quantidade de pessoas que ainda tinham instalados mal chegava aos milhares. As pessoas baixavam os aplicativos, viam que não era o que elas esperavam, davam uma nota ruim e desinstalavam dos seus smartphones.
Como descrito por Eric Ries no livro “A Startup Enxuta”, a quantidade de downloads normalmente é uma métrica de vaidade. Ela sozinha indicava que a empresa estava muito bem, mas, na verdade, a taxa de rejeição (que não é uma métrica de vaidade) era superior a 90%.
Outras métricas da vaidade podem ser: Número de visitantes no site, número de usuários registrados, quantidade de login na aplicação, quantidade de acessos, etc.
Use métricas que permitam identificar cenários e tomar ações de negócio. Nesse artigo falamos de algumas delas.
Medir coisas demais
Já passei por empresas com uma quantidade enorme de números indicadores. O tempo gasto com medição, avaliação, suporte e análise era muito grande e os resultados pequenos. O custo de manutenção dessas métricas pesavam mais do que os benefícios que elas traziam.
Suas métricas devem visar sempre tomada de ação. Medir só por medir, não faz sentido. É aumento de custo desnecessário.
Deixar de medir uma das áreas da agilidade.
No texto Métricas – Como medir a agilidade do seu time escrevemos sobre a importância de medir cada área da agilidade. Medir uma e ignorar a outra é um sinal de que o time quebrará em breve. Alguns exemplos que já passamos:
- Eficácia sem Qualidade: O time entregava muito e dava um retorno significativo à empresa. Porém a qualidade era muito baixa, muitos bugs por entrega e pouquíssimos testes automatizados. Com o tempo essa qualidade ruim cobrou seu preço e o time tornou-se extremamente ineficaz.
- Eficiência sem Eficácia: Time entregava bastante com Sprints semanais. O problema é que a quantidade de usuários e o retorno eram ridiculamente baixos.
- Eficácia e Eficiência sem Atmosfera: Um time que entregava muito, dava muito retorno a empresa, porém os membros queriam se matar. Reuniões Diárias e Retrospectivas já tinham sido abolidas e com tempo as pessoas começaram a ir embora do time. Resultado, a eficácia e a eficiência despencaram.
- Qualidade sem eficiência ou eficácia: Uma empresa tinha como métrica a quantidade de erros em produção. Quanto menor, melhor. O problema é que o “campeão” também era o campeão da NÃO entrega.
Conclusão
Métricas sempre vão mudar o comportamento das pessoas, escolha-as muito bem para não intoxicar o seu produto ou empresa.
Quer saber mais desse assunto?
Veja nossos treinamentos relacionados
- Métricas de eficiência do Time no treinamento de Kanban
- Como motivar e gerenciar um time sem recorrer a métricas tóxicas no treinamento de Management 3.0
Veja outros artigos:
Perguntas frequentes
Por que medir a produtividade individual de membros de um time ágil é ruim?
Medir o desempenho individual em ambientes complexos estimula a competição e reduz a cooperação entre os membros do time. Quando as pessoas são avaliadas por entregas individuais, como tarefas ou bugs corrigidos, elas deixam de ajudar os colegas e não dedicam tempo para avaliar se o produto atende às necessidades dos usuários e aos objetivos de negócio.
É recomendado comparar a performance de diferentes times usando User Story Points?
Não. Utilizar User Story Points ou qualquer métrica de esforço para comparar times é um erro, pois o propósito da estimativa é ajudar cada time a descobrir sua própria velocidade e negociar o escopo da Sprint. Além disso, times atuam em contextos e produtos diferentes, o que torna comparações diretas inadequadas e enganosas.
O que é uma métrica de vaidade no desenvolvimento de produtos e softwares?
Uma métrica de vaidade é um indicador que isoladamente demonstra sucesso, mas não reflete o verdadeiro impacto no negócio nem apoia tomadas de decisão. Exemplos incluem número de downloads, acessos ou cadastros de usuários. Esses dados podem mascarar problemas graves, como uma alta taxa de rejeição ou insatisfação dos clientes com o aplicativo.
Quais são os riscos de ignorar alguma das áreas do domínio da agilidade?
Ignorar uma das áreas da agilidade compromete o desempenho do time a longo prazo. Focar em eficácia sem qualidade gera excesso de bugs e retrabalho. Priorizar entregas sem atmosfera de trabalho saudável causa saída de profissionais e queda de produtividade. Além disso, ter métricas sem foco em tomada de ação apenas gera custos e processos desnecessários.
Pronto pra dar o próximo passo?
Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.
Ver cursos K21