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 fariam 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 &e