Tenho estudado um pouco sobre motivação, principalmente por causa das consultorias que tenho feito. Tenho encontrado todos os dias confirmações de que temos grandes erros acontecendo no meio corporativo. Hoje eu quero falar da medição de performance e seu impacto na motivação e na entrega, e para isso vou começar com um texto que vem do livro “Agile Software Development – The Cooperative Game” do Alistair Cockburn e está disponível no site dele também, onde há um capítulo de exemplo (veja minha review na página de livros indicados).

“Picking Dandelions
Dandelions were beginning to clutter our back yard. Having three children aged 10 and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we’d get rid of dandelions in a few years.
The kids brought in bags of dandelions, and I paid out the cash.
On the third year, I commented to my now 12-year-old, Cameron, that it looked like we had more dandelions than the previous year.
He said, “Sure. Last year I ran around, dancing and waving all the white dandelions around. When Sean asked why I wasn’t just putting them into the bag, I said, ‘I’m planting money for next year!’” ”

Traduzido:

“Pegando dentes-de-leão
Dentes-de-leão estavam se amontoando em nosso quintal. Tendo três filhos com 10 ou nenos anos, eu inventei uma solução brilhante: lhes ofereci um centavo por uma flor amarela e dez centavos por semente de dente-de-leão. Por cinco a dez dólares por ano, pensei que nos livraríamos de dentes-de-leão em poucos anos.
Os garotos trouxeram sacos de dentes-de-leão, e eu paguei em dinheiro.
No terceiro ano, eu comentava com meu filho Cameron, agora com 12 anos, que parecia que tínhamos mais dentes-de-leão que no ano anterior.
Ele disse: "Claro. No ano passado eu corri em volta, dançando e agitando todos os dentes-de-leão. Quando Sean perguntou por que eu não estava só colocando-os dentro do saco, eu disse: ‘Estou plantando dinheiro para o próximo ano!" ”

É um texto curto e divertido, não é? Quem iria esperar esse final de história? Somente quem já está acostumado com os conceitos que vou expor neste post agora. Os conceitos ainda estão um pouco brutos, estou estudando ainda para depurá-los, há livros para comprar, e muito mais estudo a fazer. Este post é um primeiro passo para trazer isso para vocês.

Vamos tentar entender o que aconteceu com Alistair, qual foi o problema que ele teve? Ele estava pagando por entrega, ou seja, por dente-de-leão. Seu filho entendeu isso. Nada mais racional do lado de Alistair do que prever que em pouco tempo estaria livre das plantas. Mas ele não contava que os incentivos dele eram diferentes dos incentivos do seu filho. Para ele, o objetivo era limpar o jardim. Para seu filho, o objetivo era ganhar o máximo de dinheiro possível fazendo algo que o pai pediu. Quem ouvisse a história até a metade nunca saberia que havia uma divergência entre os incentivos de cada um. Eles pareciam idênticos, até o problema aparecer.

O primeiro problema então é a falta de comunicação. O pai deveria ter deixado claro que o objetivo era limpar o jardim.

Ainda assim, há um segundo problema. Mesmo que a comunicação se desse conforme o esperado, isso não significaria que o filho iria sustentar o objetivo do pai, e não o seu. Seus objetivos eram claramente conflitantes, já que para o filho ganhar muito dinheiro sempre deveriam haver muitos dentes-de-leão no jardim.

Vamos fazer um paralelo com a forma com que a indústria de software remunera seus funcionários. Entre os mais comuns estão:

• salário mensal + hora extra,
• salário mensal e hora extra proibida,
• pagamento por hora,
• pagamento por linha de código,
• pagamento por entrega.

Assumindo que os funcionários tem como objetivo ganhar o máximo de dinheiro possível, o que vai acontecer nos cenários onde a remuneração é atrelada ao tempo, como nos casos de salário mensal + hora extra, e pagamento por hora? Se para o funcionário ganhar mais, ele precisa trabalhar mais, então ele vai ter que ter trabalho pra fazer. Isso implica que se ele fizer tudo no horário certo e for pra casa, ele não vai maximizar seu salário. Para reverter isso, ele tem algumas opções: deixar os bugs correrem soltos e depois corrigir na hora extra, inventar funcionalidades desnecessárias ao projeto (goldplatting), inventar trabalho (análises desnecessárias, etc), trabalhar com arquiteturas difíceis de manter, tentar aumentar o escopo do projeto, e por aí vai. Nenhuma destas opções é boa para o projeto, mas são boas para o salário do desenvolvedor. E esses dois casos sozinhos devem ser a maioria do mercado.

Há o caso do pagamento por linha de código. Nesse caso, fica óbvio que o desenvolvedor vai criar a maior quantidade possível de linhas de código. Vai comentar tudo, vai criar declarações desnecessárias, loops que pouco fazem e por aí vai. Já imagine classes de 2 mil linhas e o inferno de manutenção. Pelo menos o pagamento por LoC é raro hoje em dia.

No pagamento por entrega, o objetivo é entregar. Nesse cenário, o desenvolvedor vai focar na entrega. Não vai inventar nada que não esteja focado na entrega, porque se isso acontecer o pagamento dele diminui ou atrasa. O problema é que nesse cenário o desenvolvedor faz a entrega a qualquer custo. Mesmo que para entregar mil reais em valor ele precise destruir dois mil reais. Se ninguém estiver medindo onde os 2 mil reais foram perdidos, então tudo bem. E não imagine que você vai conseguir resolver o problema na engenharia ou no conceito de pronto, porque ele vai dar um jeito de dar a volta nesses conceitos. Exemplo: precisa de testes, ok, vamos fazer testes inúteis, que não tomem tempo. Além disso, ele vai barganhar no custo de cada entrega, dizendo que as coisas são maiores do que são.

Em todos esses casos há ainda o problema do hiperfoco. O desenvolvedor hiperfocado na meta não olha para os lados, não pensa criativamente. E desenvolvimento de software é um trabalho criativo, ou seja, a performance do desenvolvedor vai cair caso você faça ele focar, porque ele não vai conseguir resolver os problemas. Há diversos estudos comprovando isso (vou colocar algumas referências no final).

Sobra somente o caso do salário mensal e hora extra proibida. Nesse caso, o desenvolvedor ganha sempre a mesma coisa, não importa o que faça. A motivação vai ter que vir de outro lugar. Se a empresa não motivá-lo ele vai virar uma pessoa apática, mas pelo menos não vai fazer 70 horas por semana e criar um monte de bugs. Como motivá-lo vai ficar para outro post, tenho coisas a falar sobre isso também.

O que eu quero que vocês levem deste post é: o que é reconhecido é feito. Se você pagar ou valorizar número de testes, espere ver milhares de testes na aplicação, mas não necessariamente testes efetivos. Se você valoriza linhas de código, os programas vão ser gigantescos, e por aí vai, você já entendeu.

“- Mas nem todo mundo quer maximizar o salário a qualquer custo”, vocês certamente dirão. Sim, há pessoas que possuem outros motivadores, mas os problemas que estou levantando acontecem a todo momento. A questão é criar uma cultura que incentive a automotivação, e não a motivação externa, mas, como eu disse, isso é assunto para outro post.

Eu trabalhei um bom tempo com uma metodologia muito interessante, que defendi por um bom tempo, o Balanced Scorecard. Hoje me preocupo muito com o BS em projetos criativos, pelos motivos que já citei. E pior, o BS é público, ou seja, não é só você se medindo, é a empresa inteira te medindo junto. Uma péssima ferramenta para motivar o funcionário. Se o objetivo é medir, meça, mas não divulgue, mantenha os dados na mão do gestor, que vai saber onde há problemas. No momento em que você libera a informação dos valores medidos o funcionário passa a se medir por ela.

Algumas referências interessantes sobre o assunto:

Veja esta palestra do Dan Pink sobre motivação. É de cair o queixo e ele compara o que a ciência sabe e o que as empresas fazem, e como isso não bate. Tem legenda em português:

Veja esta palestra sobre métricas ágeis apresentada no Agile 2009, disponível no InfoQ. Diversos fundamentos são colocados.

Veja o livro “Measuring and Managing Performance in Organizations”, citado na palestra acima. Ainda não li, mas está na minha lista.

E entenda o que um trabalhador do conhecimento quer de uma empresa, nesta thread do .Net Architects.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.