Ao longo da história o que não faltaram foram iniciativas – fracassadas – para medir a produtividade de desenvolvedores. Quantidade de linhas de código, pontos por função e os mais recentes Story Points são algumas das tentativas de mensurar a produtividade de um desenvolvedor.
A questão é que a atividade de desenvolvimento de software é muito complexa e medi-lá pode trazer problemas para sua organização, tanto para você quanto para o seu time de desenvolvimento.
Esses problemas são alguns dos maiores fatores de turnover por parte de programadores, segundo eles, uma gestão que não conhece de fato as minúcias do desenvolvimento de software acaba gerando um desconforto para ambos os lados, pois o gerenciamento é feito como se fosse uma atividade operacional e muito focada no imediatismo.
E é exatamente por isso que resolvi criar esse post, aqui vou tentar dar algumas dicas para melhor avaliar o trabalho de um desenvolvedor sem ter que recorrer a medição de produtividade ou comparação com outras pessoas.
Vamos lá?
Escrever mais código não significa ser mais produtivo
Um dos maiores erros dos gestores no mundo de tecnologia é achar que quanto mais códigos um desenvolvedor escreve mais produtivo ele é.
Como ja sabemos, quantidade de linhas de código não tem relação nenhuma com produtividade, pois um código com menos linhas pode ser tão ou mais eficaz que um código com mais linhas.
Além de que códigos não podem ser comparados, pois cada pessoa pode ter uma linha de raciocínio diferente.
Mais horas de trabalho não traz mais produtividade ao desenvolvedor
Outro grande erro de muitas empresas, acreditar que a quantidade de tempo que uma pessoa passa na frente de um computador trabalhando tem relação com a sua produtividade.
Quantas vezes você ficou travado por horas em um problema, e quando foi tomar uma água ou foi ao banheiro voltou com uma solução?
Esse tipo de situação é comum na vida de um programador. Pois a natureza do nosso trabalho é criativa e não operacional.
Dessa maneira, medir a produtividade do desenvolvedor por horas trabalhadas pode trazer mais problemas do que resultados positivos.
Cuidado com a falsa sensação de velocidade
Medir a velocidade de um time pode parecer uma maneira de medir a produtividade de um time, afinal, se ele está indo mais rápido, significa que está sendo mais produtivo, correto?
Não. Já citamos diversas vezes aqui nesse blog, o problema da falsa sensação de velocidade. Essa, que pode ser criada por uma falta de qualidade no código, ou por alguma ocasionalidade da entrega, como mal entendimento de um requisito.
Essa sensação só vai piorar as entregas do seu time no médio e longo prazo, então tome muito cuidado com ela.
Então como medir a produtividade de um desenvolvedor?
Não meça. Pare de medir produtividade individual, mais importante que isso são as métricas do seu negócio e do seu time.
No âmbito de negócio, meça a qualidade das entregas, assertividade de resolução de problemas e frequência de lançamento.
No de time, existem ótimas métricas ágeis para visualizar como o seu time esta se desempenhado, porém, é importante lembrar que essas métricas são para ter mais previsibilidade e assertividade nas entregas, não para medir produtividade.
Dê mais liberdade para o seu time, e acompanhe os resultados.
Quando você da a direção certa para pessoas boas, o time obtém sucesso. E naturalmente os que não estão se esforçando ou que não tem interesse são expurgados do time.
Para finalizar, termino com um pensamento que me marcou muito do livro A Startup Enxuta do Eric Ries:As empresas estão mais preocupadas se o seu software vai sair no prazo e custo esperado, que se esquecem do que realmente mais importa, se aquilo resolve de fato, algum problema.
Qualquer dúvida, deixe aqui nos comentários que respondemos o mais rápido possível! 🙂
