se você está usando um bom rastreador de tickets (como Jira, da Atlasian) e passou algum tempo inserindo todas as diferentes categorias, histórias de usuários, níveis de urgência corretamente e com o acordo de seus companheiros de equipe, calculando essas métricas (e mais) são incrivelmente fáceis.
Em um projeto anterior, usamos o Jira para gerenciar nossas listas de bugs / tarefas / tarefas e, no final, nos mostrou que a maior causa de atrasos e problemas acabou sendo práticas de gerenciamento ineficientes.
Estranhamente, quando essas informações foram divulgadas, de repente nos disseram que não usaríamos mais o Jira e que um novo produto seria trazido para substituí-lo.
Nesse meio tempo, todas as solicitações de dados a serem passadas por Jira precisavam ser enviadas à equipe de gerenciamento, e nosso acesso direto foi removido.
O que não foi notado foi que, como parte do cálculo das estatísticas, a equipe de desenvolvedores tinha Jira cutucando dados em um gancho da web, e esse gancho da web era usado para passar dados para um ponto final em alguns servidores internos, onde tínhamos código que criava esses relatórios automaticamente.
Começamos a monitorar o gancho da Web e descobrimos que, mesmo sabendo que o Jira não era mais usado, ele permaneceu vivo por um período considerável de tempo (mais de 6 meses para ser exato) e o abuso por parte da alta gerência foi simplesmente desenfreado com uso incorreto.
Claro, não precisa ser algo tão complexo quanto Jira.
Se você deseja uma solução de baixo rendimento, pode usar uma planilha do Google Docs e a API de notificação do GDocs para rastrear tarefas / tickets / bugs / solicitações de recursos etc.
O próprio GDocs agora pode emitir ganchos da web e todo tipo de coisa.
Junte isso ao Git e / ou Github e a alguns ganchos que são acionados quando o código é confirmado no seu repositório, e você tem um sistema de distribuição doméstica razoavelmente eficiente, capaz de registrar uma quantidade surpreendente de dados.
Em geral, no entanto, de 100% da vida útil natural de um produto, a divisão entre desenvolvimento greenfield e manutenção é geralmente 20/80, a maior parte do custo no ciclo do ALM (Application Lifetime Management) é gasto com custos de manutenção e suporte.
Não existe tempo demais para consertar bugs, porque simplesmente não é possível escrever código sem bugs.
Boas políticas de teste e integração contínua reduzirão o déficit, mas você nunca o erradicará completamente.
Qualquer um que acredite no contrário (IMHO) não tem conhecimento suficiente para fazer um julgamento preciso ou é cego (o caso mais comum) sobre o quão difícil é realmente escrever software.
Se o seu gerente está disposto a fazê-lo, e alguns deles estão, então você pode sugerir que ele o acompanhe por um dia, para que ele possa ver exatamente o que você faz e como o faz.
Iv'e trabalhou em algumas empresas onde esse tipo de trabalho foi incentivado ativamente, com funcionários de nível superior acompanhando funcionários de níveis inferiores e vice-versa, pode ser uma experiência de aprendizado muito, muito boa para ambas as partes envolvidas.