- Erros comumente cometidos ao medir a produtividade de desenvolvedores
- Problemas na medição de insumos
- Depender de insumos ou esforço, como ‘horas de trabalho’, incentiva comportamentos equivocados
- Por exemplo, se a cultura da empresa valoriza e recompensa o tempo passado na frente da tela, os desenvolvedores podem despejar tempo nisso, mas é difícil garantir a qualidade do trabalho
- Em ambientes mais tóxicos, isso pode se deteriorar em uma competição para ‘chegar mais cedo e sair mais tarde’
- Problemas na medição de resultados
- Os piores indicadores, como linhas de código ou número de commits, entram nessa categoria
- Desenvolvedores conseguem escrever grandes volumes de linhas de código muito rapidamente, então medir isso é fácil
- Todos os indicadores de resultado precisam ser entendidos dentro do contexto
- Problemas na medição de resultados e impacto
- O desafio desses dois indicadores é entender ‘quanta responsabilidade é da equipe de DevOps’
- Ao medir o aumento da receita do negócio, é impossível atribuir isso apenas à responsabilidade dos desenvolvedores
12 comentários
Assustador. Acho que deve haver uma diferença entre a perspectiva do gerente e a de quem está na prática do trabalho,,
Parece exatamente a parte em que LLM é necessário.
Há um aspecto em que o sentido que o texto quer transmitir acaba se enfraquecendo por não apresentar uma alternativa. Concordo com a afirmação de que a quantidade de entregas deve ser excluída da medição de resultados, mas não posso concordar que o tempo de trabalho deva ser completamente excluído da medição de insumos, porque isso não condiz com a realidade. De qualquer forma, como o tempo passa enquanto se realiza trabalho intelectual, acredito que ele necessariamente precisa ser considerado na tomada de decisões.
Acho mais fácil de entender e mais eficiente discutir a produtividade de desenvolvedores depois de medir indicadores antecedentes como
progresso total = (número de requisitos atendidos / horas de trabalho)Ultimamente, tendo a olhar esse tipo de texto de forma um pouco crítica, porque acho que a conclusão a que as pessoas acabam chegando ao ler textos assim é optar por não fazer gestão nenhuma. Independentemente de qual métrica se use para gerenciar, no fim surgem problemas parecidos. Além disso, quando uma métrica passa a ser usada para competição ou comparação entre pessoas ou equipes, aparecem efeitos colaterais. Por isso, não se deve gerenciar com apenas uma única métrica; é necessário acompanhar também métricas complementares, e acredito que elas devem ser usadas para ajudar a própria equipe a melhorar por conta própria.
O que vocês acham de medir isso pela quantidade de PRs enviados em unidades significativas?
Na verdade, há uma grande empresa coreana que mede desempenho pela quantidade de linhas de código escritas snif snif
kk eu também já vi isso.
O cara ficava subindo commit só pra mudar nome de variável.. haha
Parece que é um ambiente em que não se faz code review, né?
kkk, até o revisor de código também precisa passar por revisão de código, né?
Estão se ajudando mutuamente mesmo..
kkkkkk ai...
olá mundo infernal ;)
É isso mesmo, aquela medição de produtividade por LOC de que eu só ouvia falar? 😳😳😳