Sempre achei importante ter o trabalho medido, como disse Edwards Demings. Mas não posso negar que criar metas baseadas em indicadores sempre me deixou com uma pulga atrás da orelha. E como vamos explorar as métricas sugeridas pelo livro “Accelerate”, com uma série de posts, não poderia deixar de compartilhar pulguinha com você. Por isso a conversa de hoje será sobre métricas de engenharia e a lei de Goodhart.
Edwards Deming: O que não pode ser medido, não pode ser gerenciado.
Uma frase como essa só poderia sair da boca de um estatístico. Afinal, ele convive com números o dia inteiro. O mundo concreto, entretanto, provou que ele estava certo. É muito importante que qualquer análise (quer do estado atual ou preditiva) tenha uma base de sustentação numérica. Somos seres passionais, e não raramente os sentimentos afetam a nossa percepção.
Um gráfico de burn-down, por exemplo, pode revelar o risco de você conseguir (ou não) entregar uma sprint até a data acertada. Um time pode prometer entregar uma certa quantidade de histórias, mas se essa quantidade não tem relação com o throughput do time, dificilmente essa percepção está correta.
Números nos ajudam no diagnóstico do cenário atual, além de apontar possíveis caminhos de melhoria. Além disso são ferramentas importantes para projetar o futuro, construindo estratégias para evitar ou tornar possível essa projeção. E é aí que eu começo a ficar incomodado com os números.
O incômodo
Não é incomum você olhar para um painel de gestão, acompanhando indicadores, e apontar para aquele que está mais defasado. Tomemos uma métrica fácil de extrair: A cobertura de código (code coverage). Sabemos que baixa cobertura pode influenciar diretamente na qualidade do código, na manutenabilidade e na quantidade de retrabalho. Portanto, é bom subirmos o code coverage.
Gradualmente subimos a meta dos times. Primeiro 60%, depois 75%, depois 90%. E surpreendentemente vemos esses números crescerem. Não sem dificuldade, mas crescem. Também percebemos que, cada vez que subimos a régua, alguns projetos ficam orbitando a meta estabelecida. E ao fazer um zoom nos projetos, percebemos que alguns estão com 100% de cobertura de código.
Você não sente um incômodo com projetos 100% cobertos de testes? Eu fico. E muito! Os projetos que já olhei com esse número, geralmente estão com problemas na configuração de exclusão de análise, ou pior ainda: Quando você olha o código de testes, você encontra um famigerado `Assert.True(true);`.
Os números foram atingidos, é bem verdade. Mas a que custo?
A Lei de Goodhart
Recentemente descobri que esse meu incômodo não era apenas fruto das minhas neuras com qualidade. E mais do que isso, descobri que alguém, com muito mais embasamento do que eu, havia observado estudado e catalogado esse mesmo fenômeno. Só a área de conhecimento que era uma pouco diferente. Eu conheci a lei de Goodhart.
No original ela diz:
“Qualquer regularidade estatística observada tende a entrar em colapso quando a pressão é colocada sobre ela para fins de controle.”
Goodhart, Charles (1981). Problems of Monetary Management: The U.K. Experience. Rowman & Littlefield. Anthony S. Courakis (ed.), Inflation, Depression, and Economic Policy in the West: 111–146
Com isso, Goodhart queria dizer que quando um Governo coloca pressão sobre um indicador, esse indicador deixa de ser confiável na medida em que ele pode ser manipulado para atingir a sua meta a todo custo.
Um exemplo de comprovação dessa lei seria o de uma fábrica de pregos que, quando pressionada a atingir uma meta de quantidade, produzia pregos pequenos e disfuncionais mas em grande quantidade. E quando pressionada a atingir uma meta por peso, produzia pregos grandes e pesados. Algo muito próximo ao exemplo dado do code coverage.
Então Edwards Deming estava errado?
Óbvio que não. A necessidade de ter números para basear a gestão, está mais do que comprovada na prática. Assim como a lei de Goodhart pôde ser amplamente verificada, tanto em sistemas econômicos quanto no nosso próprio trabalho. Embora aparentemente antagônicas, as duas proposições estão corretas. O erro está em como olhamos os números.
Não olhe para apenas um número
Os números mentem. Logo, não podemos olhar para apenas um indicador e entrar em desespero ou relaxar. Indicadores precisam ser contextualizados quando analisados. O seu código pode estar passando em todos os verificadores de qualidade do Sonarqube. O que seria um indicador muito positivo. Mas se o TTM (Time To Marketing) está alto (o indicador está ruim), provavelmente você não tem um código realmente bem escrito em mãos.
Indicadores devem traduzir resultados
No exemplo que demos, a relevância atribuída ao code coverage era devida aos fatores de manutenabilidade do código, retrabalho e qualidade. Ao invés de estabelecer metas diretas para cobertura, talvez seria mais interessante focar nos resultados que esse indicador pode trazer. E desta forma, talvez você tem a oportunidade descobrir se estava olhando para o indicador certo, visando o resultado esperado.
Indicadores refletem a cultura
Os indicadores refletem, também, possíveis descompassos com a cultura de uma empresa. Uma companhia que se pretende ser reconhecida pela qualidade dos produtos que entrega, não pode ter indicadores de qualidade baixos. Particularmente entendo que cultura não se corrige com metas. Ajustes culturais exigem revisão de processos e, de certa forma, uma “catequização” desses valores. Quando a cultura for boa, os indicadores também serão bons.
Na teoria, a prática é diferente.
É muito fácil para mim – e pra qualquer livro – descrever regras e dizer o que você deve ou não fazer. Apesar de acreditar em tudo o que escrevi até aqui, antes de sair dizendo “Ah, não vou mais me preocupar/estabelecer metas sobre indicadores por conta de lei de Goodhart”, pense um pouco no momento em que está o seu projeto ou a sua empresa.
Podem existir motivos legítimos, que justifiquem e te levem a “cair” na lei de Goodhart. E não há problemas nesse caso. O que importa é que você esteja ciente dos caminhos para os quais as suas decisões podem levar você e sua empresa. Em uma estratégia a longo prazo, esta pode ser apenas uma das etapas para a construção de uma cultura de qualidade.
Agora que você detém o instrumental teórico, podemos conhecer as métricas de engenharia, guiados por um olhar mais crítico. Bora?
Parece que já vi isso em algum lugar, talvez no mesmo – atual – que você. “Quando você olha o código de testes, você encontra um famigerado `Assert.True(true);`.” tive que me segurar pra não rir muito alto. Passar por códigos com 100% de cobertura é diferenciado. Vale uma pipoca e um refri gelado.