Avalie somente o que importa
Thiago Brito
17 de Agosto de 2020 4 minutos de leitura

É interessante como na nossa área de programação, acabamos medindo coisas que não tem importância nenhuma e que acabam levando a gente para um caminho que mais atrapalha do que ajuda a cumprir os objetivos.

Imagina você avaliar um médico pelo número de cirurgias que ele faz, um juiz pelo número de pessoas que ele condena ou até mesmo o sucesso de uma pessoa unicamente pela quantidade de dinheiro que ela tem?

São métricas que podem fazer com que o resultado final seja um verdadeiro desastre. Com software não é diferente.

Imagino que você já tenha visto ou pensado em extrair métricas para avaliar a performace de alguns times, programadores individuais ou você mesmo através do número de linhas produzidas, cobertura de unit tests, commits realizados, número de tarefas concluídas e poraí vai.

Talvez as métricas façam total sentido para quem faz a coleta, mas se não forem bem combinadas elas tendem a tornar tudo muito disfuncional e não ajudar em nada ao cumprir os objetivos.

O que medir então?

Quando você está pegando a estrada e usando um aplicativo como o Waze ou Google Maps, você tem alguns indicadores interessantes como a direção e quanto tempo falta para você chegar lá. Sendo assim, é fácil entender se você está ou não no caminho certo de acordo com as decisões que você for tomando.

Suas métricas devem ter o objetivo de indicar se estamos na direção certa de entregar um software de qualidade e dentro do esperado pelo cliente ou não.

Sendo assim, métricas de vaidade como número de linhas de código produzidas, números de commits feitos, número de cartões finalizados não trazem qualquer efeito positivo no time.

Seguem algumas métricas que podem ajudar significativamente a mensurar a direção pela qual o seu time está seguindo:

Lead Time

Esta métrica indica quanto tempo uma determinada tarefa leva do momento em que ela é criada até o momento em que é concluída.

A análise desta métrica pode apontar problemas em vários pontos do processo de desenvolvimento. Normalmente, melhorar os indicadores que vou discutir abaixo tem como consequência a redução do Lead Time.

Frequência de Deploy

Com que velocidade as mudanças realizadas pelo desenvolvedor vão pra rua? Quanto mais frequente for o processo de liberação das mudanças para validação dos clientes melhor.

Somente gastar energia melhorando esta métrica já força uma série de processos como Integração Continua, implementação de testes unitários confiáveis e processo de revisão de código.

Pois o ideal mesmo é que, sempre que uma tarefa seja concluída ela já entre no pipeline para ser feito o processo de deploy e esteja disponível ao cliente em questão de minutos.

A não ser que você trabalhe com Hardware ou tenha algum tipo de restrição contratual, não existem motivos para você ignorar este indicador.

Isso tudo faz com que o time esteja sempre preocupado com a saúde do produto como um todo e torna a próxima métrica também muito importante.

Percentual de deploys falhos

A tarefa foi desenvolvida com sucesso, todos os testes passaram e o deploy foi feito, mas algo de errado aconteceu e fez com que o time tivesse que gerar uma correção as pressas ou até mesmo houve a necessidade de fazer um rollback.

A frequência com que isso ocorre deve ser reduzida ao máximo, é ela quem indica que o time está indo no caminho certo com relação a qualidade do código que está sendo produzido.

Número de bugs identificados em produção

Não existe nada pior do que o cliente encontrar um bug no produto, além do desgaste gerado a tendência é que o desenvolvedor já esteja trabalhando em outra tarefa.

Se o bug for crítico, é necessário parar alguém para trabalhar na resolução o mais breve possível e este trabalho é tempo totalmente perdido. E se este bug não for crítico, a tendência é que o Lead Time seja prejudicado.

O desenvolvedor que está resolvendo o bug poderia trabalhar em entregar valor ao cliente, e não corrigir problemas gerados pelo próprio time.

Sendo assim, é repetitivo eu falar da importância em investir tempo capacitando e buscando melhorar a qualidade do codigo do produto é essencial para melhorar este indicador.

Veja que eu não falo nada sobre cobertura de unit tests, nem complexidade ciclomática… nada disso…

Estas são métricas que podem até ajudar a identificar por onde começar a arrumar o seu código. E mesmo assim elas não são muito boas, pois o foco deve ser sempre olhar de fora, ou seja, do ponto de vista do seu cliente para dentro.

Não seria mais simples fazer algumas perguntas como por exemplo:

  • Quais são as funcionalidades mais utilizadas pelos nossos clientes que tem mudanças mais constantes?
  • Dentro destas funcionalidades, quais são mais difíceis de fazer mudanças?
  • Porque estas mudanças são tão difíceis de serem realizadas?
  • Na maioria dos casos, a resposta para todas as questões estão dentro do seu time ou a uma pergunta de distância do seu cliente. Então não é tão dificil assim extraí-las e você vai entender rapidamente onde focar sua energia dentro deste projeto que tem código legado.

    Então é isso, espero que tenha gostado de todos os pontos que eu enumerei e se houver alguma coisa pra complementar, coloque aqui nos comentários. Eu vou ficar muito feliz em saber o que você acha sobre isto.

    Se souber de alguém que está afim de dar aquela turbinada na carreira e entender que este texto é para ele, não esquece de dar uma compartilhada! :-)