Medir o trabalho dos desenvolvedores é diferente das funções tradicionais, pois cada novo recurso, correção de bug ou refatoração não é o mesmo e tem diferentes níveis de complexidade. Este artigo aborda algumas maneiras mais antigas e melhores de medir a produtividade do desenvolvedor.

Personagem do desenvolvedor

O papel gira em grande parte em torno da resolução de problemas onde a solução nem sempre está à vista, com o fardo adicional de manter o quadro existente. A menos que o problema seja uma repetição de experiências anteriores, os desenvolvedores precisarão de um ambiente livre de distrações para resolvê-lo.

Agora, existem diferentes tipos de desenvolvedores, mas se estamos falando de alguém cujo trabalho é adicionar novos recursos, corrigir bugs e participar nas decisões de arquitetura, então a persona acima se encaixa bem. De qualquer forma, os desenvolvedores trabalham em um estado de fluxoe as interrupções afetam a produtividade.

O jeito antigo

Ingressos JIRA

Algumas organizações contam com o JIRA como gerenciador de tarefas, onde os recursos e bugs solicitados são inseridos como tickets. Aquele que fecha mais tickets em um período de tempo é certamente o mais produtivo, certo?

Talvez, talvez não. Esses tickets ignoram completamente a complexidade de cada item, portanto tratá-los como iguais cria uma percepção errada. As pessoas que lidam com ingressos mais fáceis estariam no topo das paradas, enquanto o restante está caindo nos mais difíceis.

Mas assim como adicionamos prioridades aos tickets, talvez pudéssemos estimar a complexidade também? Isso adiciona mais observabilidade, mas as estimativas de não engenheiros estarão erradas na maioria das vezes.

Algo como adicionar um “simples menu suspenso” pode se transformar em algo importante se entrar em conflito com a configuração atual ou exigir a resolução de dívidas tecnológicas anteriores para prosseguir. Talvez você pudesse pedir a um engenheiro que escrevesse tickets precisos, mas isso seria uma perda de tempo precioso do desenvolvedor. A resolução do JIRA ou de tickets de qualquer tipo não é um bom indicador no final.

Pontos de história

Os pontos da história são uma medida de tempo para desenvolver um recurso em relação a outros recursos. A estimativa no desenvolvimento de software é uma das coisas mais difíceis e os pontos da história poderiam ter sido ótimos, mas apenas pioraram as coisas.

Muitas empresas hoje os usam como medida de produtividade, e as equipes são julgadas por quantos pontos conquistaram no sprint atual e Deus me livre se foi menor que o anterior. Isso efetivamente promove a manipulação do sistema e o fornecimento de estimativas mais longas, anulando o propósito.

Reuniões de progresso

Em princípio, parece uma boa ideia um gestor perguntar como você está e se você tem algum obstáculo, mas, na realidade, reuniões regulares de progresso são realmente boas para desperdiçar o tempo de todos e desviar o foco do trabalho real para as próprias reuniões.

Muitas vezes, o resultado de uma reunião é uma reunião de acompanhamento, então, eventualmente, ficamos em um ciclo sem fim à vista. Não ajuda que a ansiedade da reunião seja algo comum em que as pessoas não conseguem se concentrar no trabalho até que a reunião termine.

O Novo Caminho

Medir a produtividade na engenharia sempre foi um desafio, mas anos de pesquisas e pesquisas desenvolveram métricas que podem fornecer informações valiosas sobre o desempenho da sua equipe e ajudar a identificar bloqueadores ocultos e sinais de esgotamento. Estes são chamados Métricas DORA (veja em Entrega de software) e foram desenvolvidos pela equipe de pesquisa e avaliação de DevOps do Google.

A entrega de software é medida essencialmente por quatro métricas principais:

• Prazo de entrega da mudança: com que rapidez estamos avançando?
• Frequência de implantação: com que frequência estamos avançando para a produção?
• Porcentagem de falhas na alteração: Quão confiáveis ​​são nossas implantações?
• Tempo de recuperação de implantação com falha: com que rapidez nos recuperamos?

Essas métricas fornecem observabilidade instantânea de sua equipe e contêm várias submétricas para análises profundas, se necessário. A equipe DORA elabora um relatório anual para acompanhar como a indústria está usando essas métricas, suas médias, impacto e muito mais. 2025 é a versão mais recente mas se concentra muito no desenvolvimento assistido por IA. Você pode verificar o Versão 2021 para obter uma visão geral do desenvolvimento tradicional.

Medindo métricas DORA e muito mais

Em organizações compactas com um pequeno conjunto de desenvolvedores, não é necessário usar ferramentas para medir a produtividade de sua equipe, mas à medida que sua equipe cresce, faça o mesmo para acompanhar. É aqui que você pode utilizar ferramentas de observabilidade que medem métricas DORA, como Swarmia, LinearB e Codemetria.

Mencionarei especialmente o Codemetrics aqui, pois ele tem o preço mais barato por assento, além do fato de que estive envolvido com ele por algum tempo no início. (divulgação completa)

A etapa e a decisão mais difícil é conceder algumas permissões de visualização para selecionar parte do repositório do seu código, mas essas ferramentas usam metadados de solicitações pull para calcular todas as estatísticas para que seu código permaneça invisível e seguro.

Você também pode editar e organizar que tipo de métricas deseja acompanhar para garantir que você tenha a visualização que está funcionando para você. Além de rastrear métricas DORA, Codemetrics também tem vantagens adicionais, embora qualquer coisa relacionada ao código-fonte exija acesso a ele para análise, mas estas são desativadas por padrão.

Se você nunca experimentou esses tipos de ferramentas antes, seria uma boa ideia ver se elas atendem às suas necessidades de negócios. Eles sempre vêm com uma demonstração ou teste gratuito, então você só continua se funcionar.