o que importa é o que interessa

Sobre aquele caso de ontem, a coisa continua melhorando.

Hoje um dos líderes de desenvolvimento daquele certo grupo, daquela certa corporação, não apenas aceitou o desafio do diretor, como assinou embaixo. Para adicionar mais “tempero à disputa” — nas palavras do mesmo — ele incrementou o desafio para seu time, para que cada um de seus desenvolvedores conserte mais do que 5 bugs até a próxima segunda-feira, que é a meta que ele espera atingir ele mesmo.

Ele até gastou tempo fazendo um gráfico pizza no Excel.

Como você sabe, nada bate a eloqüência de um gráfico pizza na hora de representar uma fração simples.

Uma imagem vale por mil palavras — desculpe se não fiz um gráfico pizza para facilitar a compreensão desta idéia; você terá que se esforçar um pouco.

É claro, tudo isso é uma situação hipotética, imagine. O que você pensou?

Afinal, qualquer um que tenha lido qualquer livro sobre gerência de projetos de software sabe que é uma péssima idéia avaliar desenvolvedores pelo número de bugs que eles resolvem, pois isso cria um incentivo perverso que apenas resultará em mais bugs. E você nem precisa que seus desenvolvedores sejam particularmente maliciosos ou trapaceiros, pelo contrário, eles podem ser os mais bem intencionados e profissionais do mundo, basta que você incentive os resultados errados.

Por exemplo, imagine um desenvolvedor hipotético nesta situação hipotética — vamos chamá-lo de... er... Telles.

Esta semana Telles consertou três bugs. Para cada um Telles criou também um teste automatizado, para verificar o conserto. Testes automatizados não são necessários para declarar o conserto feito, e tomam tempo para criar, mas, a longo prazo, são uma solução muito barata e eficiente para garantir a qualidade do produto.

Hoje Telles consertou outro bug. Ele não tinha dúvida de que a melhor opção seria criar um teste automatizado para acompanhar o conserto... até o momento em que o diretor e o líder fizeram o desafio pressionando por números. Agora Telles não tem dúvida de que a melhor opção é consertar o bug o mais rápido possível e seguir em frente. Afinal, de nada adianta investir em qualidade futura se ele não conseguir uma boa avaliação de performance agora. Telles não está sendo particularmente maligno ou trapaceiro — afinal, a criação de testes automatizados é opcional. Ele está apenas reagindo aos incentivos e condições presentes.

Ironicamente, porque a qualidade não tende a melhorar, os bugs continuarão vindo em grande número, o que apenas confirmará a decisão que o diretor e o líder tomam agora: “Se não tivéssemos pressionado por números daquela vez, hoje teríamos ainda mais bugs para consertar”.

Ainda bem que é uma situação... coff-coff... hipotética.