Métricas Tóxicas: o que você não deve usar

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.

Métricas Moldam Comportamentos

Métricas Moldam Comportamentos

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

Veja outros artigos:

Por |2018-09-16T17:47:15+00:0014 de junho, 2018|Cultural, Gestão, Negócio, Product Owner, Scrum Master|

Sobre o Autor:

Eu sou um desenvolvedor de software que passou por todas as etapas de TI. Comecei em 1998 com a manutenção de microcomputadores. Em 2000, tornei-me um programador e, desde então, desempenhei o papel de desenvolvedor, analista de sistemas, gerente de projeto, Scrum Master, Product Owner, gerente funcional e Agile Coach. Também vivi diversos modelos de desenvolvimento de software. Comecei com o cascata (programadores e analistas em salas separadas), participei de dois times de implantação de RUP, um de implantação de CMMI e outro de MPS-BR e por fim um com as melhores práticas do PMBOK. Descobri os Métodos Ágeis em 2009. Os resultados que obtive utilizando-os foram tão incríveis que resolvi adotar os valores e princípios ágeis não só na vida profissional, como também na vida pessoal. Nos últimos quatro anos, fui professor auxiliar no desenvolvimento do software Ágil na Universidade Federal do Rio de Janeiro e pai da Mari. Em 2015, tornei-me o Gerente de Desenvolvimento de Software no Tribunal Regional Eleitoral do Rio de Janeiro. Ao longo do tempo, percebi que tinha adquirido algum conhecimento e experiência interessantes na adoção de Ágil. Alguns colegas me chamaram para atuar como Agile Coach na K21, gostaram dos resultados e, desde então, me dedico a essa nova carreira.

5 Comments

  1. Vichy 15/06/2018 em 21:49 - Responder

    Gostei do artigo! Parabéns

  2. Ingredy 18/06/2018 em 15:57 - Responder

    Parabéns pelo artigo! Aproveitei bastante a leitura.

  3. Marcelo Medeiros 25/06/2018 em 13:22 - Responder

    E quais seriam exemplos de métricas saudáveis em sua visão?

  4. […] comentamos neste post e como elas podem ajudá-lo a tomar melhores decisões. Também escrevemos algumas métricas que devem ser evitadas para não intoxicar o ambiente da sua […]

Deixar Um Comentário