Como medir a produtividade do desenvolvedor

Usando um sistema para fornecer uma visão imparcial do desempenho do desenvolvimento

A produtividade do desenvolvedor é algo muito difícil de medir objetivamente e fica mais difícil com o tamanho da empresa. Encontrar um indicador preciso do desempenho do desenvolvedor, que é quantificável, é o santo graal da gestão de TI em grandes organizações.

A medição de produtividade do desenvolvedor, hoje, é, em sua maioria, subjetiva. Os gerentes têm uma vaga sensação da capacidade de uma pessoa para produzir e eles avaliam o desenvolvedor, em grande parte com base em sua capacidade de cumprir prazos. Este tipo de medida não quantificável tem, entre outros aspectos negativos, o efeito colateral de mascarar graves problemas da equipe de desenvolvimento. Há pouca compreensão pela cadeia de gestão em como tudo está sendo realizado, em quem é o membro da equipe mais valioso, e de onde os gargalos derivam. As coisas só pioram quando um mandato é enviado para outra área dizendo que a produtividade deve aumentar em X% este ano. Se você não tem métrica para medir e você não tem nenhuma linha de base para começar, como é que você espera medir o sucesso ou fracasso?

Eu não sei qual é a resposta para criar um sistema de medida para os desenvolvedores, que funcione e seja puramente objetivo. Se eu soubesse eu provavelmente seria um milionário. Houve uma infinidade de táticas tentando adicionar dados concretos para os esforços de desenvolvimento, tais como linhas de código escritas (chega a dar arrepio), versão de controle de confirmar dados, análise de código automatizado, e assim por diante. Estes métodos tendem a sofrer do mesmo problema, eles podem ser facilmente manipulados. Se o trabalho de alguém ou uma promoção depende de uma métrica desse tipo, você pode apostar que eles vão escrever o código voltado para impulsionar essa métrica, fazendo sentido ou não. Até que alguém descubra um sistema mensurável que não é facilmente manipulado e que produz métricas úteis e precisas, por quê não começar por melhorar a medida subjetiva?

Se você é um gerente atento, você vai ver o nível de qualidade do código de seus desenvolvedores observando o número de problemas resultantes e o esforço necessário para corrigir os bugs. Se um bug é causado por um erro de digitação ou simples descuido de lógica menor, é muito melhor do que uma seção inteira de código que precisa ser reescrita devido a um problema estrutural maciço, por exemplo. Baseando-se nisso, se o desenvolvedor geralmente entrega o que é pedido dentro do prazo ou antes, você pode combinar esse conhecimento com a taxa de erro e gravidade do erro que você vê ao longo do tempo . Da mesma forma, se o desenvolvedor está consistentemente atrasado em suas entregas, você combina isso com o número de bugs e sua gravidade para formar uma forma quase consistente de mensuração, ainda que subjetiva. Usando essas duas medidas em conjunto, se tem, obviamente, dados melhores do que usando uma só. Se alguém é consistentemente atrasado em suas entregas, mas tem muito menos bugs, pode-se dizer que eles são tão ou mais produtivos do que outro desenvolvedor que entrega a tempo, mas com um maior número de bugs, etc.

A maneira que eu meço um pouco mais objetivamente, e do jeito que eu já vi isso feito em grupos maiores em trabalhos anteriores, é quebrar as coisas em unidades de trabalho com restrições de tempo definidos. A unidade de trabalho pode ser um projeto inteiro, ou pode ser um recurso ou componente de um projeto maior, ou mesmo uma tarefa simples ou correção de bug. Você atribui um trabalhador a uma unidade de trabalho e impõe um período de tempo para o trabalho. Quando o período de tempo expirar, você avalia o resultado. É aí que começa a ficar subjetivo, mas você pode pelo menos ter ganho de métricas sobre o trabalhador em relação a uma unidade de trabalho e intervalo de tempo.

Depois de uma unidade de trabalho estar completa, essa unidade é ligada ao trabalhador que a completou. Se novas unidades de trabalho resultarem desse trabalho (bugs), você pode encaminhar isso de volta para o trabalhador e priorizar unidade de trabalho para adicionar às métricas. Eventualmente, isso deve mostrar a eficiência de curto e longo prazo do trabalhador. Para obter esclarecimentos adicionais, você pode empregar Planning Poker ou simplesmente fazer sua própria estimativa de uma unidade de nível de trabalho de dificuldade para o uso em suas métricas naquela unidade de trabalho/ desenvolvedor. Ao acompanhar essas estimativas, o delta resultante da estimativa, e os dias adicionais ou pontos da história resultantes de erros, você vai construir uma métrica mensurável para fazer a sua medição subjetiva mais qualificada.

Depois de uma unidade de trabalho estar completa, essa unidade é ligada ao trabalhador que a completou. Se novas unidades de trabalho resultarem desse trabalho (bugs), você pode encaminhar isso de volta para o trabalhador e priorizar unidade de trabalho para adicionar às métricas. Eventualmente, isso deve mostrar a eficiência de curto e longo prazo do trabalhador. Para obter esclarecimentos adicionais, você pode empregar Planning Poker ou simplesmente fazer sua própria estimativa de uma unidade de nível de trabalho de dificuldade para o uso em suas métricas naquela unidade de trabalho/ desenvolvedor. Ao acompanhar essas estimativas, o delta resultante da estimativa, e os dias adicionais ou pontos da história resultantes de erros, você vai construir uma métrica mensurável para fazer a sua medição subjetiva mais qualificada.

Ter alguma forma de medição imparcial é importante. Vai identificar pontos problemáticos na melhoria de organização e unidade. Equipes vão melhorar ao estimar esforços quando o desempenho puder ser medido. Quando as coisas ficarem difíceis, vai ajudar com as decisões difíceis. Quando as coisas estiverem boas, vai justificar aumentos e promoções. Afinal, você não quer esses tipos de coisas dependendo da opinião, preconceito ou preferência de um indivíduo.

Quais são algumas outras maneiras de adicionar dados mensuráveis para codificação de desempenho? O que você viu que tem funcionado bem ou falhou miseravelmente?