Talvez a pior herança da era industrial seja a noção de controle do tempo. Os gestores sentem uma forte necessidade de medir algo, e o “tempo gasto numa tarefa” torna-se um objeto poderoso e brilhante ao qual é difícil resistir. Assim, muitas vezes as equipes são obrigadas a monitorar quanto tempo leva para corrigir cada bug ou concluir tarefas individuais. Esses tempos são então comparados entre os desenvolvedores para fornecer alguma medida de produtividade e um meio de determinar o sucesso. Um tempo médio mais baixo para correção de bugs é bom, certo? Ou é?
A pior métrica de todas
O controle do tempo dos desenvolvedores de software é – em uma palavra – horrível. Não existem dois bugs iguais, e desenvolvedores inexperientes podem ser capazes de corrigir rapidamente muitos bugs fáceis, enquanto desenvolvedores mais experientes, que geralmente enfrentam problemas mais desafiadores, demoram mais. Ou talvez o desenvolvedor júnior receba um bug que ele não consegue resolver? Pior ainda, o controle do tempo incentiva os desenvolvedores a tentar manipular o sistema. Quando estão preocupados com o tempo que uma tarefa pode levar, podem evitar aquelas que podem demorar mais do que a “estimativa” e todo tipo de atividades “não produtivas”.
Não precisamos admitir que não há como determinar quanto tempo uma determinada unidade de trabalho de software deve ou levará? Ter que prestar contas de cada minuto do dia apenas cria maus incentivos para economizar. Também pode fazer com que um desenvolvedor inteligente e capaz se sinta ansioso ou preocupado por demorar “muito” para resolver problemas desafiadores que deveriam ser uma “mudança fácil e de uma linha”.
