Uma pesquisa realizada em 1908 pelos psicólogos Robert Mearnes Yerkes e John Dodson Dillingham acabou tornando-se conhecida pela alcunha de “Lei de Yerkes-Dodson”. Demonstra que nossa performance é afetada positivamente pelo estado de estímulos ambientais, mas isso tem um teto.
Esta respeitada e influente pesquisa já foi utilizada e validada em diferentes contextos, desde chão de fábrica ao dia-a-dia de executivos. Creio que é fácil para qualquer um imaginar uma equipes de desenvolvimento de Software, onde muita pressão gera muita dívida técnica e erros.
Yerkes e Dodson apresentaram um modelo sobre a influência positiva causada por níveis de pressão (estímulos), até um limite que varia de acordo com o tipo de tarefa, desde as mais simples até as que exigem assimilação, entendimento, montagem de cenários e tomada de decisão.
A pesquisa registrou uma diferença nesta curva quando o desempenho medido diz respeito a tarefas mais ou menos complexas. As tarefas menos complexas exigem e suportam mais pressão, as tarefas mais complexas comprometem-se cedo quando há sobre o executor muita pressão.
Até certo ponto, melhoramos nossa performance enquanto sobem os níveis de estímulos mentais, com metas, desafios, pressão, mas se estressar demais ou por muito tempo, esta curva passa a cair. A lógica é conhecida, pois os erros e falta de planejamento tornam-se uma bola de neve.
Em tarefas simples é possível estressar mais (lembrando o filme o chefe e a esteira em que Chaplin tem que apertar parafusos no filme Tempos Modernos). Quanto mais simples a tarefa, mais eu converto a pressão em resultado até o teto, isso acontece em menor escala nas complexas.
Yerkes-Dodson para TI
Em TI, onde lemos “excitação” devemos interpretar como pressão por prazos, orçamento apertados, desafios, inovação, problemas, etc. Aqui chega o ponto onde sou obrigado a perguntar: Em qual das curvas será que boa parte das tarefas de desenvolvimento de software se enquadram?
- Tarefas Simples – exige atenção, acesso a memória rápida, aplicação de boas práticas, um mínimo de previsibilidade e risco moderado.
- Tarefas Complexas – exige atenção dividida, memória de trabalho, encadeamento de tomadas de decisão, multitarefa e adaptabilidade.
Mais uma teoria da psicologia que após um século de estudos empíricos ajuda a explicar o porque dos excesso de bugs, dívida técnica crescente, falta de qualidade, sistemas que passam a ser encarados como legados minutos após serem entregues dada a falta de qualidade de código.
Uma situação retratada sob diferentes abordagens no modelo “Cynefin” e no “Job Strain Model” de Karasek, teorias que contribuem para nosso entendimento e argumentação sobre a qualidade e o passivo que geramos, que na correria as empresas insistem em taxar como inevitáveis.
Um estudo recente (2009) na Universidade de Oklahoma, fundamentado na “Lei de Yerkes-Dodson”, foi desenvolvido com o título de “Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort”. Ele concluiu que para manter um nível benéfico de "excitação" em projetos de SW requer a cooperação entre clientes e equipes de desenvolvimento para focarem na melhor forma de potencializar o trabalho e os resultados de forma sustentável. Também concluiram que o orçamento é mais crítico que o tempo para a maioria dos projetos de software.
Mas de nada adianta pesquisar, teorizar, comprovar, saber e continuar fazendo mais do mesmo. É como um chefe que pergunta quanto tempo para fazer um software e os desenvolvedores afirmam 4 meses, o chefe responde dizendo que eles só tem 2 meses e os desenvolvedores respondem dizendo que nem começaram e o projeto já não deu certo, pois está atrasado 2 meses. A solução para este paradoxo é entregar qualquer coisa e enquanto se discute o que houve e porque não deu certo (?), vai-se "arrumando" por mais 2 meses até ficar pronto.
Diferencial competitivo em produtos digitais tem a ver com qualidade, com o nível de acoplamento às necessidades do cliente e usuário, o uso de boas práticas de desenvolvimento em um processo desenhado a partir de métodos ou modelos racionais de execução com foco em eliminação de desperdícios e otimização de valor.
Remar contra esta maré é no mínimo arriscado!
Deixe aqui uma opinião ou pensamento e até breve \o/