Medir a produtividade de uma equipe de software parece uma exigência básica de gestão, e Murilo Moura Alencar, board member e Tech, People & Game Strategist, examina que justamente por isso tantas empresas escolhem o indicador errado. Linhas de código escritas, número de tarefas fechadas, pontos entregues por semana. São números fáceis de coletar e de colocar num painel. O problema começa quando elas se tornam meta.
O economista britânico Charles Goodhart deu nome a esse efeito: quando uma medida se torna um alvo, deixa de ser uma boa medida. Em equipes de tecnologia, a regra se confirma com uma regularidade impressionante. A seguir, por que o erro se repete e o que costuma funcionar melhor.
O que acontece quando o número vira meta?
Uma empresa passa a premiar os desenvolvedores que fecham mais tarefas no mês. Em poucas semanas, o número dispara. As tarefas grandes passam a ser quebradas em pedaços cada vez menores, os problemas difíceis ficam para depois e ninguém quer assumir a investigação demorada de um defeito que afeta clientes.
O painel mostra uma equipe mais produtiva, mas clientes percebem o contrário. As pessoas não agiram de má-fé. Apenas responderam, de forma racional, ao que estava sendo recompensado. O indicador mediu o esforço de parecer produtivo, e não o valor entregue.
Por que o erro se repete?
A tentação é compreensível. As diretorias querem saber se o investimento em tecnologia está rendendo, e o trabalho de uma equipe de software é pouco visível para quem está fora dela. Números simples oferecem uma sensação de controle que conversas e avaliações qualitativas não dão.
Murilo Alencar aponta que o erro está em medir a atividade individual, quando o que importa é o resultado do sistema. Um desenvolvedor que passa o dia ajudando três colegas a destravar um problema pode não fechar nenhuma tarefa e, ainda assim, ter sido a pessoa mais produtiva da equipe. Nenhuma contagem individual captura esse tipo de contribuição.
Indicadores que olham para o fluxo
Uma alternativa amplamente adotada vem das pesquisas do programa DORA, reunidas no livro Accelerate, de 2018. Os estudos identificaram quatro indicadores associados ao bom desempenho de equipes de software: frequência de entregas, tempo entre o início de uma mudança e sua chegada ao cliente, taxa de falhas causadas por essas mudanças e tempo para restaurar o serviço quando algo dá errado.
Esses números têm uma vantagem importante, pois medem a equipe como um todo e equilibram velocidade e estabilidade. Acelerar entregas à custa de mais falhas aparece imediatamente no painel, o que dificulta manipular um indicador sem prejudicar outro.
Números abrem conversas, não encerram
Mesmo os melhores indicadores precisam de contexto. Uma queda na frequência de entregas pode indicar um problema ou simplesmente um período dedicado a reduzir dívida técnica. Sem conversa, o número vira sentença.
Na visão de Murilo Moura Alencar, a combinação mais saudável junta poucos indicadores de fluxo, acompanhados ao longo do tempo, com a percepção de quem está no dia a dia, incluindo a satisfação da própria equipe. Pessoas esgotadas podem sustentar bons números por alguns meses, mas raramente por anos. Quando elas deixam a empresa, levam junto um conhecimento que nenhum painel registrava.
Medir para aprender, não para vigiar
A escolha de um indicador comunica o que a empresa valoriza. Conforme ressalta Murilo Moura Alencar, contar linhas de código diz às pessoas que volume importa mais do que qualidade. Nesse contexto, acompanhar o tempo até o cliente comunicar que o que importa é resolver problemas reais.
Por isso, antes de montar um painel, vale perguntar que comportamento aquele número vai estimular quando as pessoas souberem que estão sendo avaliadas por ele. Se a resposta não for o comportamento desejado, significa que o problema não está na equipe, mas sim na régua. E trocar a régua costuma exigir menos esforço do que corrigir, depois, os hábitos que ela criou.
