Quando tudo o que você faz é intangível, como você deve medir? Isso pode ser medido?

Definir e medir a produtividade do programador é algo como uma grande baleia branca na indústria de software. É a base de um enorme investimento, a proposição de valor de inúmeras startups e uma das partes mais difíceis da descrição do cargo de um gerente de engenharia ou CTO. É também uma fonte de ansiedade para desenvolvedores em todos os níveis de experiência: como saber se está fazendo o suficiente, dentro e fora do horário? Quando tudo o que você faz é intangível, como você deve medir? Isso pode ser medido? Neste artigo, discutirei as maiores armadilhas da medição da produtividade e algumas maneiras de fazer isso bem.

No desenvolvimento de software, como em qualquer outro campo, muitas pessoas pensam na produtividade em termos de entradas e saídas. Um desenvolvedor em tempo integral trabalha 40 horas por semana por um salário médio de $ 107.510 por ano nos Estados Unidos. Horas e salários são entradas visíveis e facilmente quantificáveis. O desenvolvedor então produz recursos de software, documentação, implantações e / ou correções de bugs em uma base recorrente. Essas são saídas. Se os desenvolvedores são tão simples quanto o software que imaginamos que estão escrevendo, aumentar sua produtividade deveria ser tão simples quanto pedir-lhes para trabalhar mais horas ou pagar salários mais altos. Claro, este é um conto de fadas. Nem os desenvolvedores nem o software funcionam assim.

Os problemas de medição de entrada

“Horas trabalhadas” é uma das várias métricas falsas usadas como proxy do desempenho no trabalho. Menciono isso primeiro porque é um default frequentemente não examinado, um caminho de menor resistência. Se uma empresa não evita fazê-lo intencionalmente, mais cedo ou mais tarde se deteriorará em um ambiente de apenas algumas horas. Fora de uma pandemia em que o trabalho remoto é a norma, os sintomas de um ambiente de apenas algumas horas são fáceis de reconhecer. O horário de trabalho é visto como inegociável e a presença no escritório é vista como prova de que alguém está a trabalhar. Qualquer pessoa que tenta sair do escritório algumas horas mais cedo é recebida com hostilidade (às vezes tão abafada quanto algumas sobrancelhas levantadas, às vezes mais descarada). Qualquer pessoa que trabalha até tarde da noite ou chega no fim de semana é considerada uma pessoa de alto desempenho. Os incentivos dessa cultura de "último a sair da academia" são lamentáveis: os desenvolvedores são pressionados a passar mais e mais de suas vidas no trabalho, sem nenhuma outra maneira de demonstrar seu valor e levados a prestar atenção apenas secundária ao resultado do trabalho. Conforme o tempo passa, o local de trabalho se torna cada vez mais um lugar onde todos estão trabalhando, mas nada está sendo feito.

Os problemas não param por aí. Se presumirmos que todo trabalho é um “trabalho positivo” - isto é, que todo trabalho representa progresso em direção a uma meta - então estamos enganados. Os desenvolvedores que trabalharam exaustos, distraídos ou doentes tendem a estar familiarizados com o conceito de “trabalho negativo”: trabalho tão mal feito que deve ser desfeito ou compensado mais tarde, aumentando assim em vez de diminuir a quantidade de trabalho restante. O desenvolvimento de software é um trabalho complexo, abstrato e atencioso e, portanto, hipersensível ao estado mental do desenvolvedor. Ou seja, existem entradas ocultas em jogo: ansiedade, depressão, esgotamento, toxicidade no trabalho, luto, microagressões e uma centena de outras coisas que podem reduzir ou inverter a produtividade individual em um determinado dia. Se a cultura da empresa exige muitas horas semana após semana, ou mesmo apenas oito horas por dia sem flexibilidade ou tempo de férias, os desenvolvedores inevitavelmente gastarão tempo fazendo trabalhos negativos: eles literalmente farão menos ficando até tarde do que se tivessem ido para casa mais cedo . E devido ao cansaço, eles farão menos no dia seguinte também.

Por outro lado, um ambiente de apenas horas não é o pior cenário. Há um espectro de justiça sobre isso: se dois desenvolvedores trabalham o mesmo número de horas, há uma dimensão clara na qual eles são iguais. Nenhum deles parece estar relaxando, nenhum deles parece estar fazendo mais do que sua parte justa. Se eles produzem menos do que o esperado, bem, pelo menos eles investem seu tempo. E a métrica de “horas trabalhadas” não incentiva explicitamente o código ruim como algumas métricas fazem. Portanto, embora seja uma métrica ruim e até mesmo funcione contra a produtividade em muitas situações, há métricas muito piores que devemos discutir.

Considere a outra entrada óbvia para o desenvolvimento de software: dinheiro. Uma ou duas vezes, brincando, sugeri a meu gerente que a produtividade deveria ser medida pelo salário e, se meu salário dobrasse, eu produziria código no nível de um arquiteto de software de classe mundial. Claro, você sabe intuitivamente que isso é ridículo. Pagar mais dinheiro a alguém não os torna imediatamente mais produtivos (embora, indiretamente e em uma escala limitada, possa ). Ainda assim, em minha mente, dinheiro e horas pertencem à mesma categoria: não apenas insumos, mas auxiliares, apenas gerando produtividade de forma tênue. Um é fornecido pelo empregador, o outro pelo empregado, mas essa troca é acessória para a criação de software útil.

Para encurtar a história, medir entradas é uma técnica deficiente porque o desenvolvimento de software não é uma equação e o código não pode ser construído por linha de montagem. Então, vamos falar sobre saídas.

As armadilhas da medição da produção

Aqui, talvez contra a intuição, encontramos muitas das piores métricas no mundo do desenvolvimento de software. Alguns caíram na armadilha de pensar que a saída do trabalho de desenvolvimento de software são linhas de código ou confirmações no controle de versão. Certamente, eles fazem parte do processo, mas são mais como subprodutos do que resultados. Estritamente falando, uma linha de código que não resolve um problema é pior do que nenhum código. Portanto, medir a produtividade de um desenvolvedor pela quantidade de código que ele contribui é como medir uma usina de energia pela quantidade de resíduos que eles produzem ou medir o Congresso por quantos projetos de lei eles aprovam; é tangencial ao valor real.

O que é pior, jogar essas medições é trivialmente fácil. Um desenvolvedor que é pago por linha de código pode facilmente ganhar o salário de um ano inteiro em um único dia, sem criar qualquer valor de negócio. A maioria dos desenvolvedores adota uma abordagem mais sutil, mas mesmo assim, você deve ter cuidado com o que deseja.

Quando uma medida se torna uma meta, ela deixa de ser uma boa medida.

~ Lei de Goodhart

Os desenvolvedores, em geral, entendem isso - e ainda, embaraçosamente, ainda tendemos a usar commits e linhas de código como penas de pavão proverbiais. Nossos olhos se arregalam quando lemos que o Google (significando todos os produtos da marca Google, a partir de 2015) abrange mais de dois bilhões de linhas de código , ou que a equipe do Windows faz mais de 8.400 pushes de código por dia , mesmo sabendo que nenhum deles o que torna o Google ou o Windows útil. Às vezes, a comunidade até produz um disparate como este:

(À parte, parabenizo a pessoa cujo gráfico de contribuição este é por construir um hábito diário de codificação, e também por tirar um dia de folga de vez em quando. Ambos são sinais positivos para mim, embora eu não fosse assim tanto quanto dizer que esta pessoa é produtiva sem um olhar muito mais profundo em sua história de contribuição.)

Em qualquer caso, podemos adicionar essas medidas à nossa lista de proxies ineficazes. Medir a produtividade em termos de bugs corrigidos, tarefas concluídas ou recursos enviados é igualmente fútil, embora um pouco mais difícil de jogar. Se o objetivo é corrigir mais bugs, os desenvolvedores podem escrever software intencionalmente com bugs e, em seguida, escrever uma infinidade de correções; ou, para atingir o objetivo oposto, eles podem reduzir a contagem de bugs escrevendo recursos o mais lentamente possível. Se o objetivo é distribuir recursos, eles podem escrevê-los de forma rápida e ingênua, resultando em software lento e mal funcional; se o objetivo é terminar tarefas, toda a equipe pode dissolver-se na política, à medida que cada desenvolvedor ataca pelos mais fáceis (ou mais superestimados). Uma boa equipe pode ser capaz de ignorar suas medidas e apenas trabalhar,

Algumas organizações, em uma demonstração de profunda paranóia, instalam spyware nos computadores de seus funcionários para rastrear as minúcias de seu trabalho momento a momento com artefatos como movimentos do mouse, pressionamentos de teclas e capturas de tela. Não está claro para mim como qualquer funcionário pode fazer um trabalho criativo sob esse tipo de escrutínio. Espero que a maioria dos desenvolvedores pare imediatamente. Mas, como acontece com as medidas discutidas acima, a falha mais óbvia desta é que ela não captura nada realmente significativo para a empresa ou seus clientes. Você disciplinaria um desenvolvedor altamente produtivo porque ele gasta muito tempo no Reddit ou não move o mouse o suficiente? Você promoveria um desenvolvedor porque ele passa muito tempo digitando no Visual Studio, mesmo que seja difícil de trabalhar? Aparentemente, alguns gerentes sim, mas espero que a maioria de nós seja mais inteligente do que isso.

Medir a produtividade no nível certo

Agora que você foi avisado sobre as piores medidas que pode ficar tentado a usar, vamos falar sobre algumas boas. Infelizmente, o desempenho individual raramente pode ser medido além de um estado binário de "este membro da equipe contribui" ou "este membro da equipe não contribui". E não pode ser medido à distância. 

Uma equipe de desenvolvimento de software não é um grupo de indivíduos isolados trabalhando sozinhos; A produção de trabalho de cada membro da equipe é uma função da produção de trabalho de todos os seus colegas de equipe, para não mencionar várias interações significativas não mensuráveis ​​ao longo do dia. As interdependências e nuances do trabalho individual são muito complexas para serem medidaspor um observador externo. Por exemplo, alguns membros da equipe são multiplicadores de força para o restante da equipe - eles podem não realizar muito por conta própria, mas seus colegas seriam significativamente menos produtivos sem sua ajuda e influência. Indivíduos como esse são uma arma secreta de organizações de engenharia eficazes, mas sua produtividade não pode ser medida em uma escala individual. Outros membros da equipe podem não produzir muitos recursos, mas agem como “zeladores de código”, testando, limpando e refatorando cuidadosamente o código onde quer que estejam, para que seus colegas de equipe possam desenvolver recursos de maneira mais rápida e indolor. Sua produtividade como indivíduos também é impossível de medir, mas seu efeito na produtividade da equipe é exponencial. Mesmo para programadores que fornecem regularmente novos recursos, produtividadetende a variar muito no curto prazo , sufocando os esforços para rastreá-lo com qualquer especificidade. Por razões como essa, é melhor deixar o desempenho individual para que os colaboradores individuais avaliem em si mesmos e entre si.

O desempenho da equipe , por outro lado, é muito mais visível. Talvez a melhor maneira de rastrear seja perguntando: essa equipe produz software útil de forma consistente em uma escala de tempo de semanas a meses? Isso ecoa o terceiro princípio do Agile : “Entregue software funcional com frequência, de algumas semanas a alguns meses, com preferência para a escala de tempo mais curta.” Uma equipe que produz software útil regularmente é produtiva. Uma equipe que não deve ser questionada por que não. Geralmente, há razões legítimas para a falta de produtividade; a maioria das equipes improdutivas deseja ser produtiva e as equipes mais produtivas desejam ser mais produtivas.

A produtividade da equipe pode ser medida em uma escala organizacional com observações simples e holísticas. E uma vez que os colegas de equipe tendem a estar bem cientes das contribuições uns dos outros (sejam mensuráveis ​​ou não), quaisquer falhas graves na produtividade individual podem ser descobertas por meio de bons hábitos organizacionais, como entrevistas individuais frequentes entre os gerentes e seus diretos relatórios; reunir regularmente feedback honesto e anônimo; e encorajando cada membro da equipe a exercer responsabilidade pessoal, relatando suas realizações e assumindo a responsabilidade por suas falhas.

Há muitas coisas aqui que dependem de seres humanos, em vez de gráficos de tendências e dados brutos. Este é um fato inevitável do software: é muito mais sobre humanos do que uns e zeros, e sempre foi. Ferramentas de rastreamento de produtividade e programas de incentivo nunca terão um impacto tão grande quanto uma cultura positiva no local de trabalho. E quando a responsabilidade e a comunicação saudável são incorporadas a esse tipo de cultura, os momentos críticos para a produtividade se tornam rapidamente visíveis para as pessoas mais capazes de lidar com eles.

Muitas organizações usam a velocidade como métrica preferida para a produtividade da equipe e, quando bem feito, pode ser uma ferramenta útil para compreender o processo de desenvolvimento de software. Velocidade é uma medida agregada de tarefas concluídas por uma equipe ao longo do tempo, geralmente levando em consideração as próprias estimativas dos desenvolvedores da complexidade relativa de cada tarefa. Ele responde a perguntas como "quanto trabalho esta equipe pode fazer nas próximas duas semanas?" A resposta básica é “tanto quanto eles fizeram nas últimas duas semanas”, e a velocidade é o contexto para essa afirmação. É uma medida de planejamento, não uma medida retrospectiva, e qualquer pessoa que tentar atribuir incentivos a ela descobrirá que sua precisão evapora sob pressão (para mais informações, consulte The Nature of Software Development por Ron Jeffries). Compreender a velocidade de uma equipe, departamento ou empresa pode ser fundamental, pois você prioriza o desenvolvimento de recursos, define expectativas com os clientes e planeja o futuro de seus produtos.

Não há medida útil que opere em um grão mais fino do que "tarefas multiplicadas pela complexidade". Medir commits, linhas de código ou horas gastas codificando, como algumas ferramentas fazem, não é mais útil em uma escala de equipe do que em uma escala individual. Simplesmente não há relação entre o número de artefatos de código que uma equipe produz, ou a quantidade de tempo que gasta neles, e o valor de suas contribuições.

Muitas organizações prosperam sem quaisquer medidas rígidas e rápidas. Em organizações onde o software útil é bem compreendido como a meta e o resultado medido principal (embora difícil de quantificar) do trabalho de desenvolvimento e as entradas são correspondentemente despriorizadas, há implicações profundas e de longo alcance. Os desenvolvedores têm liberdade para fazer seu melhor trabalho, quando e onde forem mais produtivos. Isso pode ou não parecer um 9 para 5. Alguns farão, por preferência ou necessidade, a maior parte de seu trabalho de manhã cedo e tarde da noite. Outros trabalharão em pedaços estranhos: uma hora aqui, mais algumas horas ali. Alguns trabalharão em casa, alguns no escritório e outros na estrada. Este é um recurso, não um bug. Enfatiza a verdadeira produtividade em vez de tentar encaixá-la em uma heurística observável,pessoas com deficiência . Muito tem sido escrito e dito sobre os benefícios de Ambientes de Trabalho Apenas para Resultados (ROWE), trabalho remoto, redução do tempo gasto em reuniões e horários flexíveis; cada um deles é apenas uma manifestação de medidas de produtividade inteligentes.

Tem sido dito que você obtém o que mede . Portanto, você deve medir apenas o que realmente deseja - se pode ou não ser desenhado como um gráfico de linha. Para alguns, pode ser frustrante fazer ou gerenciar um trabalho que não pode ser reduzido a um número. Mas com um trabalho tão matizado e abstrato quanto o desenvolvimento de software, quanto mais nos entrincheiramos nos detalhes, mais derrotamos nossos próprios objetivos. Software útil é nosso objetivo, e não devemos nos conformar (ou medir) menos.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.