Restrições


Outro dia saindo do trabalho, cruzei com uma mulher parada na frente da catraca/ponto eletrônico da empresa. Achei que ela estava lá simplesmente batendo papo com a recepcionista. Quando passei pela catraca, ouvi ela dizendo “Só mais dois minutos e eu posso passar…”.

Pra bom entendendedor….

Na hora me lembrei de um email que recebi, daqueles estilo corrente, com o tema “Como fingir que está trabalhando”. Basicamente dava dicas do estilo sempre andar com ar apressado e de preferência com várias pastas na mão mesmo que só pra ir ao banheiro, ou deixar a mesa sempre bagunçada, ou sempre deixar o telefone tocar várias vezes antes de atender, e coisas do gênero.

Confesso que eu mesmo já fiz várias coisas dessas.

Fato é que o dia a dia de uma empresa sempre tem duas componentes curiosas: funcionários fingindo que trabalham e chefes fazendo de tudo pra restringir qualquer coisa na esperança de aumentar a produtividade. Quanto mais se restringe pra aumentar a produtividade, mais se finge que se trabalha. Vira um grande teatro. E esse teatro aumenta porque muitas vezes, mesmo que você não tenha nada pra fazer, precisa fingir que está fazendo pra não ser mal visto. Me lembro que uma vez, em uma época de transição de projetos e má organização geral da empresa, fiquei mais de uma semana sem nenhuma tarefa a ser feita. Mesmo assim, se chegasse às 9 em vez de 8h30, pessoas me olhavam com ar de reprovação. Voltar pra casa mais cedo era impensável, mesmo se estivesse a 5 horas na frente do meu computador esperando por uma tarefa e não havia nenhuma num horizonte de 5 dias. E eu passava meu dia inventando tarefas pra não morrer de tédio absoluto. A maioria sem nenhuma ligação com a empresa.

Eu acredito que em ambiente de desenvolvimento de software, controle por ponto, restrições horárias, proibições de acesso a sites e coisas do gênero são a pior coisa que se pode fazer para tentar manter produtividade. Entendo que elas sejam necessárias em alguns casos específicos: restrições de acesso no meu entender são válidas apenas para ambientes que requerem alta segurança, e horários estritos são necessários para pessoas que trabalham com atendimento ao cliente. Mas quando se está desenvolvendo um produto, boa parte do trabalho é solitário, e a meu ver depende muito de inspiração.

E inspiração depende de momento. Tem gente que funciona melhor de manhã, tem gente que funciona melhor a tarde, e outros a noite. Tem gente que prefere trabalhar regularmente 5 horas por dia em vários dias, e conheço pessoas que trabalham por batch: 30 horas ininterruptas. Ou as vezes estamos em dias cheios de problemas pessoais, e as coisas não andam. Daí surge a necessidade de fingir.

Quando falo que sou contra restrições e afins, muitos me falam que o que eu quero é oba-oba, não trabalhar, etc. Muito pelo contrário, eu quero trabalhar e não ter que fingir que estou trabalhando. Mas quero trabalhar no meu ritmo. E como conciliar o meu ritmo com o da empresa ? Metas bem definidas e que devem ser cumpridas. Do ponto de vista do desenvolvimento de um software, uma vez que os requisitos estão bem definidos e cada desenvolvedor sabe o que deve ser feito, pouco importa em qual horário é feito, ou se foi feito em 30 horas seguidas de programação ou em blocos de 5 horas ao longo de 6 dias. Importa que esteja pronto na data, e feito com qualidade. Em termos de quantidade de trabalho, com certeza um sistema de metas agressivas com horários muito flexíveis pode ser muito mais efetivo do que um sistema de horários estritos.

H á alguns meses participei do processo seletivo de uma gigantesca empresa de software multinacional. No meu ponto de vista, uma das melhores. Ao final da entrevista, pude fazer perguntas sobre a empresa. Obviamente perguntei como era o esquema de horários e afins. A resposta foi que por exigência do Ministério do Trabalho, os funcionários tinham que bater ponto (contratação CLT), mas que o ponto era totalmente fantasia. Os desenvolvedores poderiam chegar na hora que preferissem, fazer seu horário, eventualmente trabalhar de casa, eventualmente trabalhar mais em certos dias para não trabalhar em outros. As únicas restrições eram em relação a reuniões de projeto (poucas segundo o entrevistador) e em relação à data de entrega do código. E a coisa simplesmente funciona.

Acho realmente que o melhor modo de estimular a produtividade é instigando o interesse dos colaboradores, estimulando a participação ativa no processo de delineamento de requisitos, oferencedo problemas interessantes a serem resolvidos, e criando um ambiente que estimule a pesquisa por novas tecnologias e idéias. Em outras palavras: acho que oferecer um ambiente cheio de restrições apenas aperfeiçoa a capacidade de teatro dos colaboradores.

Para terminar, sugiro um teste: ofereça a um desenvolvedor que goste do que faz um problema computacional interessante a ser resolvido, determine um deadline e instale-o em uma máquina com MSN/ICQ/GoogleTalk e Orkut liberado. Aposto que em 99% dos casos ele irá esquecer a existência de todos esses sites/programas enquanto o problema não for resolvido.