16 pontos por GN⁺ 2025-03-24 | 5 comentários | Compartilhar no WhatsApp
  • Este texto explica como uma tentativa de medir a produtividade da equipe acabou fracassando
  • Foi decidido introduzir métricas de desempenho individual para avaliação pessoal e desenvolvimento
    • Métricas como linhas de código ou número de bugs foram descartadas por serem fáceis de manipular; em vez disso, decidiu-se medir o desempenho por story points ou número de histórias entregues

O desempenho de Tim Mackinnon era ‘0’

  • O desempenho de todos os membros da equipe foi medido por meio de ferramentas de medição de produtividade da equipe (Jira etc.)
  • A pontuação de desempenho de Tim era 0 → porque ele não registrou nenhum story point
  • Como o desempenho de Tim era 0, o gerente exigiu que Tim fosse substituído

Por que Tim Mackinnon não aparecia como alguém com desempenho

  • Tim não assumia histórias diretamente
  • Em vez disso, ele se concentrava em programação em par com os colegas da equipe
    • Trabalhando com desenvolvedores menos experientes, ele os levava a resolver problemas
    • Em vez de resolver diretamente, ajudava a chegar à solução por meio de perguntas
    • Com desenvolvedores sêniores, refletia junto sobre os problemas e aprimorava as soluções
  • Tim não escrevia código diretamente, mas melhorava o desempenho geral da equipe

A verdadeira contribuição de Tim Mackinnon

  • A contribuição de Tim não podia ser medida por uma pontuação individual de desempenho
  • Graças a Tim, a produtividade de toda a equipe e a qualidade do código melhoraram
  • Quando Tim trabalhava junto, era possível obter resultados melhores e mais rápidos

Mudança para um modelo de avaliação pela produtividade da equipe

  • A contribuição de Tim foi explicada ao gerente, e ele teve a oportunidade de observá-la
  • Depois de confirmar que o desempenho de toda a equipe havia melhorado, abandonou-se a medição de desempenho individual
  • O modelo de avaliação foi alterado de desempenho individual para desempenho da equipe e impacto nos negócios

Resumo (tl;dr)

  • A produtividade deve ser medida por resultados de negócio (por exemplo, redução de custos, geração de receita etc.)
  • Em sistemas complexos, medir o desempenho individual não faz sentido
  • DORA Metrics e afins são ferramentas para medir o desempenho do sistema, não a contribuição individual
  • Se surgir a oportunidade de trabalhar com Tim Mackinnon, não a desperdice

5 comentários

 
bus710 2025-03-26

Na verdade, quando se passa do nível sênior e chega ali a algo como engenheiro staff, você vai ficando cada vez mais distante do código que é implantado em produção no dia a dia.... Em vez disso, parece que passa a dedicar muito mais tempo a orientar pessoas seniores e juniores. Também tem que ouvir as reclamações dos gerentes.... E, quando surge algum problema, te chamam de todo lado para apresentar soluções....

O trabalho acaba sendo mais ou menos assim, então é impossível quantificar isso com tickets do Jira e pontuação.

 
castedice 2025-03-24

Como tech lead, faço bastante esse tipo de trabalho. Tentar quantificar com base em story points é parecido, mas, felizmente, como a empresa não é tão grande, inclusive os executivos e os demais membros da equipe reconhecem qual é o meu papel, então por enquanto não parece estar surgindo nenhum problema.
Se a organização crescer, acho que também vou precisar pensar em formas de quantificação.

 
kallare 2025-03-24

Achei que já tinha visto essa história em algum lugar... mas é um texto de 2023.
O mesmo texto já tinha sido publicado há 2 anos: https://pt.news.hada.io/topic?id=10680

 
crawler 2025-03-24

Você parece alguém como o GitHub Copilot....

 
GN⁺ 2025-03-24
Opiniões do Hacker News
  • Medir a produtividade de desenvolvedores individuais é absurdo. Medir linhas de código ou story points é o oposto de produtividade. O importante é que o desenvolvedor gere mais valor com menos código

    • É importante medir resultados de negócio, mas é difícil atribuí-los a um desenvolvedor específico
    • No fim, é melhor reconhecer que não há como escapar de julgamentos subjetivos
  • Descobriram uma forma de resolver problemas colocando o nome do Tim no ticket. Os membros da equipe vão ajudar de bom grado

    • Métricas de produtividade não são totalmente inúteis. Ao olhar a proporção entre PRs e tickets do Jira dentro do time, dá para supor quem é a liderança técnica
  • Fico feliz que Tim tenha permanecido no time e ajudado a conduzir o processo na direção certa. É preciso ter um gestor que saiba ouvir

    • Os OKRs isolam os desenvolvedores. OKRs baseados no indivíduo, em vez do time, causam problemas
    • Resolver problemas leva tempo. Por causa dos OKRs, não era possível receber ajuda
  • É estranho um modelo em que um programador só ajuda os outros e não tem trabalho individual

    • Seria mais saudável se Tim também trabalhasse nas histórias junto com os outros e pedisse ajuda ao grupo quando precisasse
    • Se o time for muito desequilibrado, Tim deveria assumir um papel de mentor
  • É estranho que Tim não faça trabalho individual. Para maximizar a produtividade do time, é preciso equilíbrio entre contribuição individual e colaboração em equipe

    • Tim pode ter sido paciente demais e desperdiçado tempo
  • Se Tim não estiver contribuindo com o time, eu diria para ele começar o trabalho e entregar histórias. É bom que Tim ajude os outros, mas ele também precisa fazer o próprio trabalho

  • Nem tudo precisa virar atividade em grupo. Se um desenvolvedor mediano não consegue entregar funcionalidades sem a ajuda constante do Tim, há um problema no time

    • Desenvolvimento de software exige tempo tanto para trabalho individual quanto para trabalho em grupo
  • Os melhores times sempre têm alguém como o Tim. A ajuda do Tim se espalha para os outros, e o time inteiro cresce

    • Quando um desenvolvedor fica travado, tenta resolver sozinho e, se necessário, pede ajuda
  • Medir a produtividade de desenvolvedores por story points não é uma boa ideia. Havia um desenvolvedor chamado Zero que não recebia histórias, mas ajudava o time

    • O gestor entendia a importância do Zero. Quando ele não estava, às vezes até adiavam releases importantes
  • É difícil quantificar o valor do suporte. Mas o suporte é essencial. É preciso confiar que as lideranças saibam julgar isso corretamente