Eu acho que você está misturando suas preocupações. E não há nada no lado que você precise mudar.
A produtividade é uma indicação de quão rapidamente um projeto será concluído. Os gerentes de projeto e todos os outros gostam de saber quando o projeto será entregue. Produtividade maior ou mais rápida significa que veremos o projeto entregar mais cedo.
A taxa de erros não está vinculada à produtividade, mas ao tamanho do projeto. Por exemplo, você pode ter N
bugs por Y
linhas de código. Não há nada nessa métrica que diga (ou se preocupe!) A rapidez com que essas linhas de código são escritas.
Para unir isso, se você tiver maior produtividade, sim, "verá" os erros sendo gravados mais rapidamente. Mas você teria esse número de bugs de qualquer maneira, já que está ligado ao tamanho do projeto.
Se houver algo, maior produtividade significa que você terá mais tempo no final do projeto para caçar esses bugs ou o desenvolvedor será mais rápido em encontrar os bugs que eles criaram. 1
Para abordar os aspectos mais pessoais da sua pergunta.
Se o seu chefe está olhando estritamente para o número de erros que você produz, ao contrário da taxa de erros que você produz, uma sessão educacional está em ordem. Número de bugs criados é sem sentido sem uma taxa de apoio.
Para levar esse exemplo ao extremo, diga ao seu chefe que eu quero dobrar seu salário. Por quê? Eu criei absolutamente nenhum bug em seu projeto e, portanto, sou um programador muito superior ao seu. O que? Ele vai ter um problema que eu não tenha produzido uma única linha de código para beneficiar o seu projeto? Ah Agora temos uma compreensão de por que a taxa é importante.
Parece que sua equipe tem as métricas para avaliar os erros por ponto de história. Se nada mais, é melhor do que ser medido pelo número bruto de bugs criados. Seus melhores desenvolvedores devem estar criando mais bugs porque estão escrevendo mais código. Peça ao seu chefe que jogue fora esse gráfico ou, pelo menos, jogue outra série atrás dele mostrando quantos pontos da história (ou qualquer valor comercial que você meça), juntamente com o número de erros. Esse gráfico contará uma história mais precisa.
1 Este comentário em particular atraiu muito mais atenção do que pretendia. Então, vamos ser um pouco pedantes (surpresa, eu sei) e redefinir nosso foco nessa questão.
A raiz desta questão é sobre um gerente olhando para a (s) coisa (s) errada (s). Eles estão analisando os totais brutos dos erros quando deveriam estar considerando a taxa de geração versus o número de tarefas concluídas. Não vamos ficar obcecados em medir contra "linhas de código" ou pontos de história, complexidade ou qualquer outra coisa. Essa não é a questão em mãos e essas preocupações nos distraem da questão mais importante.
Como estabelecido nos links pelo OP, você pode prever um certo número de bugs em um projeto puramente pelo tamanho do projeto sozinho. Sim, você pode reduzir esse número de bugs por meio de diferentes técnicas de desenvolvimento e teste. Mais uma vez, esse não era o ponto dessa questão. Para entender essa questão, precisamos aceitar que, para um projeto de tamanho e uma metodologia de desenvolvimento, veremos um determinado número de bugs quando o desenvolvimento estiver "completo".
Então, vamos finalmente voltar a este comentário que alguns completamente incompreendidos. Se você atribuir tarefas de tamanho comparável a dois desenvolvedores, o desenvolvedor com uma taxa de produtividade mais alta concluirá a tarefa antes da outra. O desenvolvedor mais produtivo terá, portanto, mais tempo disponível no final da janela de desenvolvimento. Esse "tempo extra" (em comparação com o outro desenvolvedor) pode ser usado para outras tarefas, como trabalhar nos defeitos que percorrerão um processo de desenvolvimento padrão.
Nós temos que considerar o OP como sendo mais produtivo do que outros desenvolvedores. Nada dentro dessas afirmações implica que o OP ou outros desenvolvedores mais produtivos estão sendo negligenciados em seu trabalho. Apontando que haveria menos bugs se eles gastassem mais tempo com o recurso ou sugerindo que a depuração não faz parte desse tempo de desenvolvimento, e que o que foi perguntado é uma falha. Alguns desenvolvedores são mais rápidos do que outros e produzem um trabalho de qualidade comparável ou melhor. Novamente, veja os links que o OP coloca em sua pergunta.