O pior programador que eu conheço
(dannorth.net)- Uma equipe de consultoria de um Big Bank tentou medir a produtividade individual por histórias concluídas/pontos de história, e Tim Mackinnon tirava repetidamente nota 0 nessa métrica
- O motivo de a nota ser 0 não era falta de trabalho, mas sim porque ele não assumia histórias em seu próprio nome e passava a maior parte do dia em programação em par
- Com desenvolvedores menos experientes, em vez de dar respostas diretas, ele promovia o aprendizado com perguntas socráticas; com os seniores, buscava junto soluções melhores a partir de perspectivas diferentes
- A equipe trabalhava de forma mais eficaz, produtiva e alinhada quando Tim estava junto, e o gerente acabou descartando discretamente a métrica de produtividade individual enquanto mantinha Tim no time
- Medir contribuições individuais de forma isolada pode reduzir a 0 contribuições como as de Tim; por isso, a produtividade deve ser vista pelo impacto no negócio e pelo fluxo em nível de equipe
O “programador nota 0” criado por métricas individuais
- Um time de um Big Bank adotou métricas individuais de desempenho para avaliação de performance e desenvolvimento dos profissionais
- O gerente evitou métricas fáceis de manipular, como linhas de código ou quantidade de bugs, e escolheu medir histórias concluídas ou pontos de história, por considerar que representavam valor de negócio
- Como cada pessoa colocava seu nome nas histórias em uma ferramenta parecida com o Jira, era fácil criar métricas individuais de produtividade
- A pontuação de Tim Mackinnon não era apenas baixa: era literalmente 0 toda semana e em toda iteração
- O gerente achava que Tim deveria ser retirado do time e substituído por alguém que realmente “entregasse” histórias, mas o líder técnico se recusou
O que Tim realmente entregava
- Tim não assumia histórias em seu próprio nome; em vez disso, trabalhava todos os dias em pairing com diferentes membros da equipe
- Ao trabalhar com desenvolvedores menos experientes, deixava que eles próprios conduzissem e os guiava com cuidado até a solução
- Não impunha respostas nem forçava um caminho
- Criava momentos de aprendizado com perguntas como “what if”, “how else” e Socratic questions
- Com desenvolvedores seniores, trabalhava de forma mais próxima de uma co-criação ou sparring, aplicando visões de mundo diferentes ao problema para chegar a resultados que seria difícil imaginar sozinho
- Em vez de entregar software diretamente, Tim desenvolvia a equipe que entrega software
- O time inteiro passava a atuar com mais eficácia e produtividade
- Trabalhava de forma mais alinhada e mais tolerante
- A experiência de trabalhar junto também se tornava mais prazerosa
- Quando o gerente vinha observar a equipe, Tim estava sempre junto de outra pessoa fazendo “o trabalho dela”, e o resultado tinha melhor qualidade e menor tempo até a entrega de valor
- No fim, o time manteve Tim e escolheu responsabilidade da equipe em vez de métricas individuais de produtividade
- Passou a acompanhar e celebrar o impacto de negócio entregue à organização por essa unidade de alta performance
Onde a produtividade deve ser observada
- Medir produtividade continua sendo necessário e, para haver responsabilidade, o ideal é ter impacto de negócio mensurável
- Dinheiro economizado
- Dinheiro gerado
- Dinheiro protegido
- Se for difícil medir impacto direto no negócio, também é possível usar métricas substitutas de negócio
- Em sistemas adaptativos complexos, a própria premissa de medir isoladamente a contribuição de uma única pessoa fica abalada
- As métricas DORA não medem a contribuição de um pistão individual, mas sim como o sistema de trabalho funciona
- Podem ser vistas como indicadores de cultura de Westrum
- Também podem ser vistas como métricas de como mudanças técnicas fluem para produção
- Métricas individuais podem reduzir a 0 a contribuição real de pessoas como Tim, e é mais adequado observar desempenho em nível de equipe e fluxo em nível de sistema
1 comentários
Comentários do Hacker News
Há uns 20 anos, trabalhei em uma empresa de software de médio porte que vendia apps desktop para Mac e Windows. A equipe tinha, em sua maioria, experiência apenas com Mac e ainda estava aprendendo Windows, então a versão para Windows tinha muitos problemas.
Na época eu era conhecido como especialista em Windows, então fui contratado para melhorar essa versão e ajudar a equipe a se familiarizar com programação para Windows.
A primeira parte do meu dia era, em geral, como “visitas domiciliares”: eu passava pelas salas de outros desenvolvedores para fazer pair programming, investigar bugs e discutir boas práticas da Windows API. Mais tarde, um colega perguntou “como você consegue ter tanto tempo sobrando?”.
Alguns meses depois, na avaliação, recebi o comentário de que “a produtividade não está no nível esperado, especialmente considerando que a produtividade do restante da equipe aumentou recentemente”, e eu achava que esse era justamente o motivo pelo qual tinham me contratado.
Compartilhar conhecimento é o maior benefício que você pode oferecer a outros desenvolvedores, mas as pessoas que escolhem esse caminho recebem recompensa de menos.
Sem desenvolvedores assim, não chegaríamos nem perto do mundo de software que temos hoje; mesmo que não recebam agradecimento direto, eles claramente têm valor.
Todas as tarefas de reparo tinham a mesma prioridade, mas a dificuldade variava. Como passei um mês aprendendo e ninguém mais queria fazer, assumi o conserto de estações-base; demorava mais, mas era muito mais importante para a operação.
Na reunião de fim de mês, apareceu um gráfico de pizza de utilização, e eu pareci muito pior do que os seniores experientes.
Foi ali que aprendi por que os seniores escolhiam só as tarefas rápidas e fáceis, e que política interna existia; no fim, foi até bom ter tido um chefe ruim logo no começo da carreira.
Meu novo chefe admitiu que, na minha primeira avaliação, tinha originalmente preparado um plano de melhoria de desempenho, mas o descartou depois que nos mudamos para um escritório aberto e ele viu pessoas fazendo fila para pedir minha ajuda, e que eu não mandava ninguém embora.
Perder meu lugar com divisórias foi um pouco irritante, mas esse episódio me fez ver escritórios abertos de forma positiva.
Claro que hoje não trabalho mais em escritório nenhum e não pretendo aceitar de novo um trabalho que não seja remoto.
Só depois que uma reputação é construída é que você consegue mudar alguma coisa; antes disso, é difícil.
Gente demais otimiza pelo “time” e acaba demitida ou passada para trás em promoções por causa da percepção negativa da liderança; por outro lado, quem conquista uma boa reputação nos critérios que a empresa valoriza no momento muitas vezes tem mau comportamento tolerado por bastante tempo.
A pessoa saiu logo para um lugar melhor, passou a dedicar menos tempo aos outros para se alinhar às métricas de desempenho da empresa, ou conseguiu convencer alguém alto o suficiente no organograma de que tinha sido contratada justamente para esse papel?
Isso me lembra uma história do Bell Labs.
Alguém calculou quais eram os funcionários mais produtivos por algum critério, como número de patentes, e descobriu que muitos deles almoçavam com a mesma pessoa.
Essa pessoa em si não tinha alta produtividade individual, mas estava sempre fazendo perguntas profundas e persuasivas, tornando os colegas mensuravelmente mais produtivos.
Os advogados do departamento de patentes do Bell Labs tentavam encontrar um princípio organizacional que explicasse por que algumas pessoas eram mais produtivas, e a única coisa em comum era que os funcionários com muitas patentes costumavam almoçar ou tomar café da manhã com frequência com o engenheiro eletricista Harry Nyquist.
Nyquist não dava ideias concretas; ele fazia as pessoas se abrirem e pensarem e, acima de tudo, fazia boas perguntas.
Grupos de pessoas têm uma estrutura delicada, e um bom clima de equipe e boas perguntas podem melhorar a situação de forma invisível.
Caso contrário, é difícil receber uma remuneração justa.
Eu não acredito.
Em uma empresa em que trabalhei por alguns anos, quem não produzia 10 pontos por semana virava alvo de melhoria de desempenho, fosse júnior ou sênior
Passei por várias equipes, e dava para perceber imediatamente como cada time media pontos só pelo nível de estresse dos desenvolvedores
As equipes que tentavam medir pontos de boa-fé ficavam estressadas, a maioria mostrava sinais de burnout e trabalhava 60 horas por semana
Já as equipes que tratavam o sistema como um jogo e entendiam que era uma tarefa impossível davam aos tickets a maior pontuação possível ou os quebravam em tickets pequenos para continuar acumulando pontos, e eram felizes, sem estresse
Naquele ambiente, seguir as regras era uma estratégia de trouxa; quando eu finalmente pedi demissão, 7 engenheiros sênior da empresa saíram também em até 4 meses
O objetivo é dividir histórias com grande incerteza e risco em histórias que possam ser realizadas de forma constante e sem estresse
Não estou dizendo que aquele emprego pareça bom, mas os desenvolvedores que acharam que estavam jogando com o sistema, em geral, parecem ter agido do modo que o Scrum tenta incentivar
Só que forçar um mínimo de pontos por semana e incentivar a inflação de pontos é uma gestão horrível
Porque extraiu mais trabalho das mesmas pessoas do que teria extraído sem pressão
Um antigo chefe dizia abertamente que “contratava pessoas para queimá-las” a fim de concluir projetos, e planejava que bastava elas serem úteis por 6 meses
Se alguém aguentasse o estresse e a baixa remuneração e continuasse, para a empresa era como um bônus; eu também não aguentei por muito tempo
Se não terminasse tudo naquela semana, marcavam o ticket como concluído e abriam o trabalho restante como um bug novo
“Quando uma métrica se torna uma meta, ela deixa de ser uma boa métrica”
Em alguns lugares, mais importante do que a produtividade pura rumo ao objetivo era o gestor saber o que podia esperar
Quem presumiu boa-fé talvez tenha achado que a diretoria também agia de boa-fé, mas muitos projetos são criados com base em wishful thinking ou com prazos artificialmente curtos para “motivar” as pessoas
Esse estresse talvez não tenha criado muito valor além da satisfação emocional do gestor
Quando o desempenho de engenheiros de software é avaliado por pessoas não técnicas, os resultados podem ser dramáticos
Meu amigo “Tommy” era um profissional de TI excelente em redes e, poucas semanas depois de entrar em uma empresa estatal de energia, teve de reconstruir toda a rede com equipamentos modernos, incluindo todos os prédios da sede
A empresa queria terceirizar, mas, ao ver o custo estimado pelo departamento financeiro, Tommy ficou chocado e disse que conseguiria fazer internamente, precisando apenas dos equipamentos físicos — roteadores, switches, cabos — e de 2 pessoas para cuidar do cabeamento
Em poucas semanas, ele terminou o trabalho por menos de um décimo do orçamento inicial, mas tudo que recebeu foi um “obrigado, bom trabalho” verbal do chefe
É bem amargo ser um profissional de TI numa época em que chefes antiquados não entendem o valor real
Depois, Tommy poderia entrar como contratado e receber uma remuneração extra
Um desenvolvedor realmente brilhante com quem trabalhei escrevia código excelente, mas também escrevia código horrível que precisava ser jogado fora imediatamente, e os dois aspectos faziam dele alguém ótimo para trabalhar
O valor do código bom dispensa explicação, e é possível que eu ainda esteja usando código dele hoje
Mas ele também era excepcional em situações de emergência
Quando um cliente estava completamente parado e talvez a culpa fosse nossa, ele aparecia na hora, entendia rapidamente o problema e escrevia e instalava depressa um código espaguete sujo que fazia o cliente voltar a operar
Era um código feio de doer os olhos, impossível de commitar ou refatorar, mas evitava a crise imediata enquanto alguém depois resolvia direito
Eu até admirava mais essa segunda habilidade, porque, acima de tudo, era uma competência rara; e ele simplesmente era uma boa pessoa, então todos gostavam dele
Ainda assim, termino as coisas rapidamente, e meu código esquisito já salvou o dia várias vezes ao resolver emergências ou ganhar propostas
Tenho dificuldade de me comunicar com desenvolvedores “perfeccionistas”; para eles, se o código não foi projetado o suficiente, ele parece não ter valor mesmo quando entendem que velocidade é necessária
É claro que eles provavelmente pensam o oposto sobre mim
Hoje criamos reuniões semanais para aliviar o problema, e isso está funcionando bem
O mais difícil é decidir que tipo de abordagem é adequada quando não é uma emergência, mas o cronograma está apertado e a especificação é pouco clara; pelo menos agora decidimos em conjunto
Não é impossível aprender sozinho, mas a abordagem de memorizar problemas e soluções comuns a ponto de conseguir digitá-los mecanicamente é realmente angustiante para mim
A menos que você seja dono da empresa, sempre será avaliado pelo valor aparente
Se o empregador não consegue ver visualmente o seu valor, é improvável que você sobreviva ali
Um sistema de desempenho plenamente meritocrático seria o ideal, mas, se outra pessoa controla sua contratação ou avaliação, o sucesso depende 100% de como essa pessoa enxerga você
Essa percepção nasce da aparência externa, tenha ela ou não valor real para a empresa
O que estou falando aqui não é de habilidade de programação nem de valor real, mas de contratação e avaliação; também há muita gente produtiva que sabe administrar bem a própria reputação
Pessoalmente, quero que os seniors da equipe realmente façam o trabalho difícil
Ajudar os juniores a trabalhar também é bom, mas tarefas difíceis e complexas que um júnior, por falta de conhecimento, experiência e habilidades interpessoais, não consegue fazer ainda exigem alguém experiente
Nenhuma programação em par consegue substituir isso completamente
É preciso evitar uma situação em que funcionalidades de baixo valor são implementadas muito bem, mas o trabalho de alto impacto e alta prioridade não é concluído porque as pessoas mais experientes estão ajudando as menos experientes com coisas como escrever testes unitários
O fato de ter sido atribuído a um júnior não significa, por padrão, que seja um problema fácil; caso contrário, como seria possível fazer um engenheiro crescer?
Nem todos os seniores devem gastar tempo com mentoria e colaboração com juniores, mas ter algumas pessoas assim na equipe funciona como um multiplicador de força e beneficia a equipe inteira
Mesmo que a empresa não soubesse disso na contratação, se ele encontrou um nicho útil, ela deveria ter transformado isso em uma função oficial
Ele era um coach; se tivesse sido contratado para esse papel, tudo bem, mas se quisessem um coach provavelmente teriam contratado um separadamente
Há funcionalidades difíceis que um júnior não consegue concluir mesmo com tempo infinito, porque ele ainda não tem as habilidades, e essas habilidades levam anos para surgir
Às vezes a ajuda de um sênior é necessária, mas, se por causa disso o sênior não consegue criar nada, isso tem pouco sentido para a empresa
Funcionalidades difíceis devem ser dadas a alguém suficientemente sênior; se quiser desenvolver um júnior, divida com ele as partes mais fáceis desse trabalho e peça que o sênior explique o que está fazendo
A atitude de Tim de ajudar todo mundo é excelente, mas também é estranho que os outros programadores precisem de tanta ajuda a ponto de Tim não ter tempo algum para produzir seus próprios resultados
O problema não está em Tim, e sim na gestão, que achou aceitável uma estrutura em que especialistas precisam sempre de ajuda e um Tim, quase como voluntário, está sempre disponível para ajudar
Se um dos seniores tivesse feito direito desde o início, um júnior deveria conseguir modificá-lo
Se foi esse sênior que construiu e, ainda assim, a estrutura o torna difícil e complexo, fica a dúvida de por que ele é chamado de sênior
Ainda assim, o trabalho de todos os seniores não pode se resumir a ajudar juniores
Hoje em dia é difícil ser esse tipo de pessoa
Tudo é tão centrado em resultados visíveis que pessoas assim facilmente entram na lista de cortes, e já passei por isso diretamente
Team players, mentores e arquitetos de software estão sendo cada vez mais empurrados para o lado, enquanto coders que despejam muito código ocupam espaço
Mesmo que a dívida técnica faça a capacidade de entregar funcionalidades e manter o sistema cair com o tempo, gestores gostam de desenvolvedores que escrevem de forma consistente mais de 5000 linhas por semana, independentemente das funcionalidades realmente lançadas ou do número de bugs
Como tech lead e engenheiro que já gerenciou projetos complexos, alguém que escreve mais de 2000 linhas de código por semana me assusta
Isso dá mais de 100 mil linhas de código por ano, e é preciso pensar na complexidade desnecessária
É bem provável que a mesma funcionalidade pudesse ser implementada em 10 mil linhas, com menos bugs e na metade do tempo, mas aí seriam só 380 linhas por semana, e o gestor não gostaria
Tendo a ver desenvolvedores que produzem milhares de linhas como pessoas que não pensam com profundidade suficiente na direção de longo prazo do projeto, e sinto que a maior parte desse código está mais próxima de código descartável
O Google institucionalizou isso em certa medida com a função de Tech Lead, e espera-se que esse engenheiro atue mais como multiplicador de força e mentor do que como contribuinte individual
Nem sempre funciona como projetado, talvez funcione só raramente, e o TL pode acabar preso em coordenação de pessoas, planejamento e discussões pequenas, sem conseguir trabalhar como engenheiro
Ainda assim, a intenção da função é boa
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
A ideia de medir tudo e agir com base nos números que se consegue obter existe desde o século XIX
Gestores repetem as mesmas práticas desde então, e os resultados têm saído de forma bastante estável do mesmo jeito
O dono de uma empresa em que trabalhei por pouco tempo queria reescrever o serviço web do zero a cada seis meses para acompanhar os frameworks web mais recentes e as modas do momento
Se aparecesse um herói das 5000 linhas por semana, ele o teria contratado na hora
Em projetos de manutenção, às vezes passo uma semana sem escrever uma única linha, ou até passo a semana inteira reduzindo o número de linhas de código
Excelente
No remo, existe um treinamento chamado seat racing, em que se colocam e retiram pessoas de várias combinações de oito lugares para encontrar a combinação mais rápida
A força individual também é uma métrica, mas quem entra no barco de competição é decidido pela velocidade da equipe
No fim, é raro que a combinação mais rápida seja simplesmente formada pelos oito mais fortes; muitas vezes há uma ou duas pessoas “mágicas” que, mesmo sem parecerem melhores no papel, tornam qualquer barco mais rápido quando entram nele
Elas melhoram sutilmente o equilíbrio, o ritmo e a força dos outros
Alguns treinadores não aceitam isso de bom grado e resistem, reduzindo o número de vitórias como consequência
É muito parecido com equipes de software e, no fim, o que importa é a combinação e o resultado
Quando me pedem para orientar sobre “liderança técnica”, sempre digo para observar com atenção os funcionários do tipo facilitador
A ajuda deles torna outros funcionários mais produtivos e eficazes, e algumas pessoas obtêm maior satisfação profissional em ajudar os outros a fazerem um ótimo trabalho do que em realizar algo incrível diretamente e ficar com todo o crédito
Essas pessoas muitas vezes recebem pontuações baixas, mas, se você as perde, há uma queda líquida na produtividade da equipe
Por isso, tento dar ferramentas para distinguir entre quem de fato não é produtivo e quem manifesta sua produtividade por meio do sucesso dos outros
Nunca é bom medir apenas uma métrica e gerenciar com base nela
Porque quem manipula a métrica “vence”, e esse comportamento acaba levando a promoções
Eu também disse isso à liderança do Google, mas Laszlo respondeu: “Este é o sistema que temos e ele não é perfeito, mas vamos seguir com ele. Trabalhar dentro dele ou não é escolha sua”
Só aquela reunião já foi suficiente para entender se a alta liderança queria ou não criar um ambiente de engenharia melhor
Muitos gerentes novos, especialmente aqueles que antes eram engenheiros contribuidores individuais, acham que manter os “melhores” membros e dispensar os “ruins” melhorará tanto o moral quanto a produção da equipe
Mas o “melhor” que eles entendem se baseia nos critérios pelos quais faziam bem seu trabalho anterior, não nos critérios de gestão de pessoas
Por isso, tendem a preferir pessoas com habilidades e hábitos parecidos com os seus e a subestimar pessoas com habilidades e hábitos diferentes
É sempre interessante ver o momento em que os olhos deles se arregalam ao perceber isso
A política de juros zero aumentou funções como diretores sêniores que gerenciam quadros do Jira e listas de tarefas, e deixou em falta as pessoas capazes de fazer o trabalho de verdade
Não sou contra a ideia de que possa haver pessoas que facilitem a produtividade dos outros, mas, no fim, para algo ser concluído, esses “outros” são necessários
Caso contrário, a organização necrosa