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.
Você pode escutar este artigo! Clique no player abaixo!
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:
