“Faça uma rápida busca no Google e procure por “medir a produtividade do desenvolvedor de software”, e você vai encontrar um monte de nada. Sério, nada”. Nick Hodges, Medição da produtividade do desenvolvedor.

Até agora, todos nós sabemos que não temos como medir a produtividade do programador. Não há nenhuma maneira clara para medir se os programadores estão fazendo um trabalho melhor ou mais rápido, ou para comparar a produtividade entre as equipes. Sabemos que as estrelas em um time de desenvolvimento são aqueles em quem podemos confiar para entregar o produto e aqueles que estão lá lutando. E nós também sabemos que, se uma equipe está ruim, vai arrastando consigo seus membros. Mas como é que vamos provar isso? Como podemos quantificar essa questão?

Todos os tipos de problemas e coisas estúpidas podem acontecer quando você tenta medir a produtividade do programador. Mas vamos fazê-lo de qualquer maneira.

Se estamos escrevendo mais código, temos de ser mais produtivos

Desenvolvedores são pagos para escrever código. Então, por que não medimos a quantidade de código que eles escrevem – ou quantas linhas de código são entregues? Porque nós sabemos desde a década de 1980 que essa é uma péssima maneira de medir a produtividade.

Linhas de código não podem ser comparadas entre linguagens (é claro), ou mesmo entre os programadores que utilizam a mesma linguagem em trabalhos de diferentes tipos ou na sequência de diferentes estilos. É por isso que os Pontos de Função foram inventados – em uma clara tentativa de padronizar e comparar o tamanho do trabalho em diferentes ambientes. Parece bom, mas os Pontos de Função não fizeram sucesso nos ambientes de trabalho, e provavelmente nunca farão, uma vez que poucas pessoas sabem como eles funcionam, como calculá-los e como devem ser usados​​.

O problema fundamental é que a medição da produtividade por linhas de código (Pontos de Função ou outros derivados) não faz qualquer sentido. Muito do trabalho realmente importante no desenvolvimento de software, ou mais precisamente o trabalho mais importante de fato, envolve pensar e aprender – e não apena digitar.

Os melhores programadores gastam muito tempo entendendo e resolvendo problemas difíceis, ou ajudando outras pessoas a entender e resolver problemas difíceis, em vez de apenas digitar código aleatório. Eles encontram maneiras de simplificar o código e eliminar problemas. E o monte de código que eles escrevem não vai mostrar de forma alguma como resolveram determinado problema, testaram alternativas e construíram protótipos funcionais, para finalmente chegar a uma solução.

“As falhas nessas medidas são óbvias, se considerarmos os resultados ideais: o menor número de linhas de código possível para resolver um problema, e a criação de processos comuns e simplificados e as interações com clientes que reduzem a complexidade em sistemas de TI. Nossos desenvolvedores mais produtivos são aqueles que encontram formas engenhosas para evitar escrever código demais e inútil”. Jez Humble, The Lean Enterprise.

Este é claramente um daqueles casos em que o tamanho não é documento.

Estamos ganhando mais dinheiro, por isso devemos trabalhar melhor

Poderíamos tentar medir a produtividade em um nível elevado usando rentabilidade ou retorno financeiro sobre o que cada equipe está entregando, ou alguma outra medida de negócios, como quantos clientes estão usando o sistema – se os desenvolvedores estão trazendo mais dinheiro para o negócio (ou poupando dinheiro), eles devem estar fazendo algo certo.

Usar medidas financeiras parece ser uma boa ideia em nível executivo, especialmente agora que “cada empresa é uma empresa de software “. Essas são medidas organizacionais que os desenvolvedores devem compartilhar entre si, mas mesmo assim elas não são eficazes, ou são falhas como medida de produtividade do desenvolvedor. Há muitos fatores comerciais que estão fora do controle da equipe de desenvolvimento. Alguns produtos ou serviços são bem sucedidos, mesmo que os desenvolvedores entreguem um péssimo trabalho, e mesmo que a equipe faça um grande trabalho. Concentrar-se na redução de custos, em particular, leva muitos gestores a cortar custos de desenvolvimento e tentar “fazer mais com menos”, em vez de investir em melhorias reais de produtividade.

E como Martin Fowler aponta, existe um lapso de tempo, especialmente em grandes organizações – por vezes pode levar meses ou anos para que os resultados financeiros reais apareçam a partir de um projeto de TI, ou da melhoria da produtividade.

Temos de procurar em outro lugar para encontrar métricas de produtividade significativas.

Estamos trabalhando cada vez mais rápido, então devemos estar ficando mais produtivos

A medição da velocidade de desenvolvimento – velocidade no Agile – parece uma outra maneira de medir a produtividade no nível da equipe. Afinal de contas, o ponto principal do desenvolvimento de software é entregar software funcionando. Quanto mais rápido a equipa o entrega, melhor.

Mas a velocidade (o quanto de trabalho foi feito, medido em pontos do histórico, pontos característicos ou dias ideais que a equipe deve entregar um produto em um determinado período de tempo) é realmente uma medida de previsibilidade, e não de produtividade. Velocidade se destina a ser utilizada por uma equipe para medir a quantidade de trabalho que ela pode assumir, para calibrar suas estimativas e planejar o trabalho futuro.

Uma vez que a velocidade de uma equipe tenha se estabilizado, é possível medir as variações de velocidade dentro da equipe como uma medida relativa da produtividade. Se a velocidade da equipe está em desaceleração, isso poderia ser um indicador de problemas na equipe ou no projeto do sistema. Ou podemos usar a velocidade para medir o impacto de melhorias em processos, para ver se as práticas de criação de novas ferramentas ou novos aplicativos realmente tornam o trabalho da equipe consideravelmente mais rápido.

Mas você vai ter que explicar as mudanças para a equipe, conforme pessoas entrem e saiam dela. E terá que se lembrar de que a velocidade é uma medida que só faz sentido dentro de uma equipe, e não se pode comparar a velocidade entre equipes distintas que fazem produtos diferentes, embora isso não impeça as pessoas de tentar.

Algumas empresas usam a ideia de um histórico de referência conhecida para que todas as equipes em um projeto possam compreender e utilizar para basear suas estimativas de produtividade. Enquanto não é dada muita liberdade para as equipes sobre como formam suas estimativas, e como as equipes estão trabalhando no mesmo projeto ou programa com as mesmas restrições e premissas, somente você pode ser capaz de fazer uma comparação grosseira da velocidade entre elas. Mas Mike Cohn adverte que

“ao menor indício de que as velocidades das equipes estão sendo comparadas, haverá um gradual, mas consistente decréscimo de desempenho”.

ThoughtWorks explica que a velocidade <> produtividade em seu último Technology Radar:

“Nós continuamos a ver as equipes e organizações igualando velocidade e produtividade. Quando usada corretamente, a velocidade permite a incorporação do “tempo de ontem” no processo de planejamento de iteração interna de uma equipe. A chave aqui é que a velocidade é uma medida interna para uma equipe, ou seja, é apenas uma estimativa da capacidade para determinada equipe naquele determinado momento. Organizações e gerentes identificam a velocidade interna junto com a produtividade externa para definir metas de produtividade, esquecendo-se de que o que realmente importa é software funcionando sendo produzido. Tratar a velocidade como produtividade leva a comportamentos improdutivos da equipe que otimizam essa métrica à custa da qualidade do trabalho real”.

Basta ficar ocupado

Um gerente diz saber como medir a produtividade:

“Nós simplesmente ficamos ocupados. Se estamos ocupados trabalhando como maníacos, podemos olhar para os problemas de forma mais realista e corrigi-los para seguir em frente”.

Nesse caso, você mediria – e otimizaria – o tempo do ciclo de tarefas, assim como é feito em Lean Manufacturing.

O tempo do ciclo de tarefas é o tempo de resposta ou a alteração do tempo de espera a partir de quando a empresa pede algo para uma determinada data, essa tarefa chega a suas mãos e você pode vê-lo trabalhando – é algo com que a empresa se ​​preocupa e que todos podem ver e medir. E uma vez que você começa a olhar de perto, resíduos e atrasos vão aparecer sempre que você medir o tempo de espera e o tempo ocioso, valor agregado versus valor não agregado, trabalho e eficiência do ciclo do processo (tempo de valor agregado/tempo total do ciclo).

“Isso tudo não é importante para definir a produtividade, ou mesmo para medi-la. É muito mais importante para identificar atividades não-produtivas e conduzi-las de forma a causarem menos impacto”. Erik Simmons, Intel.

As equipes podem usar o método Kanban para monitorar – e limitar – trabalhos em andamento e identificar os atrasos e gargalos. O Mapeamento do Fluxo de Valor ajuda a entender os passos, filas, atrasos e fluxos de informações que precisam ser otimizados. Para ser eficaz, você tem que olhar para o processo de ponta a ponta, a partir de quando os pedidos são feitos até quando são entregues, inclusive enquanto estão em execução, para otimizar o caminho inteiro e não apenas o trabalho em desenvolvimento. Isso pode significar a mudança de como a empresa prioriza tarefas, como as decisões são tomadas e até mesmo quem toma as decisões.

“Em quase todos os casos que vimos, fazer um bloco dos processos mais eficientes terá um efeito mínimo sobre o valor do fluxo global. Como retrabalho e tempos de espera são alguns dos maiores contribuintes para o tempo global gasto para entrega, a adoção de processos “ágeis” dentro de uma única função (como o desenvolvimento) geralmente tem pouco impacto sobre o fluxo global de valor e, portanto, sobre os resultados dos clientes”. Jezz Humble, The Lean Enterprise.

O lado negativo de igualar a velocidade de entrega com a produtividade? A otimização para ciclo de tempo/velocidade de entrega por si só pode levar a problemas a longo prazo, porque incentiva as pessoas a pensar em curto prazo para cortar custos assumindo uma dívida técnica.

Estamos escrevendo software melhor, por isso temos de ser mais produtivos

“O paradoxo é que, quando os gerentes se concentram apenas na produtividade, melhorias a longo prazo são raras. Por outro lado, quando os gerentes se concentram na qualidade, a produtividade melhora continuamente”. John Seddon, citado em The Lean Enterprise.

Sabemos que a correção dos erros mais tarde acaba custando mais caro. Quer se trate de 10x ou 100 + x, isso realmente não importa. E que projetos com menos bugs são entregues mais rápido – pelo menos até um ponto de retorno decrescente para os sistemas de segurança crítica e ciclo de vida crítico.

E nós sabemos que os custos de bugs e erros de software para o negócio podem ser significativos, assim como os custos de retrabalho no desenvolvimento e os custos de manutenção e suporte. E ainda há os custos diretos para o negócio: o tempo de inatividade, as violações de segurança, perda de IP, clientes perdidos, ações judiciais, ou seja, insucesso empresarial.

É fácil medir se você está escrevendo software bom ou ruim, de acordo com a densidade de defeitos. Os defeitos, incluindo vulnerabilidades de segurança, escapam ao ambiente de produção. Podemos também utilizar métricas de uma análise estática da base de código, usando ferramentas como SonarQube.

E nós sabemos como escrever um bom software – ou deveríamos saber a esta altura. Mas a qualidade do software é suficiente para definir a produtividade?

DevOps – medir e melhorar o desempenho da TI

Equipes DevOps que constroem/mantêm e operam sistemas de apoio estendem a produtividade do desenvolvimento em operações. Elas medem a produtividade em duas dimensões: velocidade de entrega e qualidade.

Mas DevOps não está limitado a apenas a construção e entrega de código – em vez disso, olha para as métricas de desempenho para a entrega de serviços de TI end-to-end:

1. Vazão de entrega: frequência de deployment e tempo de espera, maximizando o fluxo de trabalho em produção.
2. Qualidade de serviço: taxa de mudanças que falharam e MTTR.

Não é apenas uma questão de entrega de software mais rápida ou melhor. São dev e ops trabalhando juntos para oferecer serviços melhores e mais rápidos, estabelecendo um equilíbrio entre mover muito rápido ou tentar fazer muito em um momento, a excessiva burocracia e o excesso de cautela resultando em desperdício e atrasos. Dev e ops precisam dividir a responsabilidade e a prestação de contas para o resultado, e para medir e melhorar a produtividade e qualidade.

Como assinalei em um artigo anterior, isso torna métricas operacionais mais importantes do que as métricas de desenvolvedores. De acordo com estudos recentes, o sucesso em alcançar essas metas leva a melhorias no sucesso do negócio: não só a produtividade, mas o market share e a rentabilidade.

Medir os resultados, não as perdas

Em The Lean Enterprise, Jez Jumble fala sobre a importância de medir a produtividade e o resultado – medir as coisas que são importantes para o resultado da organização – e não as perdas.

“Não importa quantas histórias serão concluídas se não atingir os resultados que seu negócio se propõe a atingir”.

Pare de tentar medir a produtividade dos desenvolvedores individuais. É um desperdício de tempo.

Todo mundo sabe quem são os melhores desenvolvedores. Aponte-os na direção certa e os mantenha felizes.

Todo mundo sabe quais são as pessoas que estão lutando. Leve-as na direção certa e as ajude para que obtenham sucesso.

Todo mundo sabe quem não se encaixa na equipe. Tire-os da equipe.

Medir e melhorar a produtividade na equipe ou na organização vai lhe dar retornos muito mais significativos.

Quando se trata de produtividade, foque-se em:

1. Medir coisas que importam – coisas que vão fazer a diferença para uma equipe ou para uma organização. Medidas que são claras, importantes e que não são fáceis de serem medidas.
2. Use métricas para o bem, não para o mal – para conduzir a aprendizagem e aperfeiçoamento, não compare o resultado entre equipes ou classifique as pessoas.

“Eu posso ver por que medir a produtividade é tão sedutor. Se pudéssemos fazer isso, poderíamos avaliar software muito mais fácil e objetivamente do que podemos agora, lembrando que métricas incorretas só pioram as coisas”. Martin Fowler, CannotMeasureProductivity.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/01/we-cant-measure-programmer-productivity.html