O controle de horas é besteira? A experiência do Github diz que sim

por Rafael Nunes em 19 Ago 2011 |

Zach Hokman, um dos desenvolvedores de uma das ferramentas mais conhecidas na comunidade de desenvolvimento de software, o Github, fez um post polêmico, que foi destacado no Hacker News está rendendo ótimos comentários e discussões. O post trata da filosofia e do ambiente de trabalho do Github, e de como não há controle de horas da equipe de desenvolvimento. Tem como base principalmente uma crítica aos princípios apresentados na monografia de Frederic Taylor, "Os principios da administração científica", a obra seminal do Taylorismo. 

Hokman defende que o desenvolvimento de software é um trabalho criativo, e não tem relação nenhuma com trabalhos repetitivos e mecânicos, como se tenta impor no modelo de fábrica (para o qual o Taylorismo foi muito bem-sucedido). Sendo um trabalho principalmente intelectual, o desenvolvimento requer que as pessoas estejam "mentalmente saudáveis" para o cumprimento de suas tarefas. Por isso, são valorizadas as horas em que conseguem ser realmente produtivos, sejam horas comerciais impostas pelas empresas, ou qualquer outra hora do dia ou da noite.

O número de horas trabalhado são uma ótima maneira de medir produtividade em várias indústrias, mas não na nossa. Desenvolver em uma startup é uma experiência muito diferente de trabalhar em uma fábrica. Não se pode simplesmente aumentar as horas dedicadas à solução de um problema e esperar que seja resolvido mais rapidamente. O código é um empreendimento criativo. O desenvolvedor deve estar com a mente e atitude certas e adequadas, para criar código de qualidade.

No Github, os membros da equipe têm a possibilidade de trabalhar de onde desejarem (de casa, do escritório etc.), e quantas horas forem necessárias para o cumprimento de suas tarefas. Cada funcionário faz seu próprio horário. Segundo Hokman, um dos papeis da empresa é incentivar os seus desenvolvedores a serem o mais produtivos possível: o Github não força uma agenda de trabalho que os obrigue a cumprir horários, independentemente de serem ou não produtivos com essa agenda. 

No caso do GitHub, um pouco paradoxalmente, esta flexibilidade resulta em mais horas de trabalho produtivo, e consequentemente em mais resultados:

Ao se permitir horários flexíveis, cria-se uma atmosfera em que os funcionários podem estar motivados e satisfeitos com seu trabalho. No final, isso pode levar a mais horas de trabalho, e horas de trabalho mais produtivas. O trabalho em finais de semana se mistura com dias úteis, dias misturam-se com noites. Isso porque nenhuma parte do trabalho parece trabalho.

A defesa desse modelo de gerenciamento, segundo o autor, se deve ao fato de que controlar as horas dos desenvolvedores é, para quem os gerencia, uma ilusão de que quantidades de horas trabalhadas.

Lembre da última vez em que você estava deprimido ou chateado. Qual era seu nível de produtividade? Agora recorde a última vez em que estava verdadeiramente produtivo. Código saindo voando dos seus dedos, não somente em quantidade, mas com qualidade. Quando se está com a mentalidade e atitude corretas, seu melhor dia de programação pode equivaler a semanas de pressionamento frustrado de teclas.

O modelo é adotado por muitas empresas fora do Brasil, principalmente startups, possibilitando um ambiente mais livre para quem desenvolve, porém está longe de ser uma realidade brasileira.

Você é a favor de tal modelo? Acredita que funciona ou funcionaria no Brasil?

Conteúdo editorial relacionado

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

Concordo! by Leandro Bitencourt

Só a pressão que o desenvolvedor assimila tendo que chegar por várias vezes o número de horas restantes para finalizar a tarefa, minha opinião, limita a capacidade criativa gerando código de baixa qualidade e insatisfação. É melhor você executar uma tarefa com todo o seu empenho? Ou, executar uma tarefa por imposição?

Re: Concordo! by Eder Magalhaes

Interessante o ponto de vista, mas vale a ressalva que nesse caso trata-se de uma startup.
Agora, e as empresas "maiores"?
Como prestadores de serviços: qual a visão de nossos clientes em relação a essa forma de trabalho?

Legal, mas... by Rodrigo Ramos Couto

Cara, sou da mesma idéia do autor, mas ainda fico com algumas questões.

Tipo, no cado do gitHub, a equipe de desenvolvimento tem uma data limite para a entrega de uma nova versão?

Fico olhando no meu caso, trabalho numa empresa que presta serviços de desenvolvimento de software para outras empresas, então para a empresa que contratou o desenvolvimento, quando um contrato é vendido, existe uma data para entrada em produção e isso inevitávelmente acaba prescionando os desenvolvedores.

Então ai me questiono. Será que isso é aplicável em todos os casos?

Concordo by Jeff Prestes

O único detalhe é que a equipe tem de saber o objetivo comum - se há uma equipe deve haver sinergia. E o pessoal tem de ter responsabilidade com as datas de entregas. O demais só atrapalha a produtividade.

Primeiro ... by Robson de Almeida

Primeiro é preciso "colocar as pessoas certas no barco".
Você só vai conseguir trabalhar desta forma com uma equipe que consiga se organizar. Tudo vai depender de quem faz parte desta equipe e, em grande parte, de como esta equipe é liderada.

Acho que esta forma de desenvolvimento/trabalho pode ser aplicada em qualquer projeto. Mesmo àqueles que possuem um contrato rígido com uma data de entrega preestabelecida. Se você tem uma data para entrega, esta data é um objetivo comum de toda equipe. E conquistar este objetivo, como eu disse, depende muito das pessoas que estão no time e, ainda mais, de quem lidera a equipe.

Tão importante quanto saber quem colocar no time, é saber quem retirar.

Re: Legal, mas... by Breno Martinusso

Na minha opinião sim!

Eu por exemplo trabalho com base em prazos estipulados pelo governo. Não cumprindo os prazos acarretam em multas para os clientes.
Até no caso do governo, mesmo quando o prazo dado não é muito amigável, não deixa de ser possível.
Com profissionais competentes isso é valido ao meu ver.

No serviço público, infelizmente, isso não funciona by Davi Shibayama

Na maior parte dos órgãos do serviço público brasileiro isso não funciona. O servidor público padrão não tá se lixando pra código limpo, de qualidade, baixo acoplamento, alta coesão, boas práticas de engenharia etc. Nada disso. Ele tá mesmo é de olho no relógio esperando dar a hora de cair fora. A única honrosa exceção talvez seja o Serpro, e olhe lá.

Re: No serviço público, infelizmente, isso não funciona by Aldisney Martins

Esta cultura tem que estar no DNA da empresa para funcionar, muitas ainda não estão preparadas e não confiam em seus funcionários, para deixá-los livres.
Já trabalhei em uma empresa que o horário nunca importou e eu acabava trabalhando muito mais.
Atualmente, até consigo esta flexibilidade na empresa que estou, mas acho que ainda não está 100% aceito isto aqui, a presença física ainda conta muito.

Concordo by Emerson Jose Morgado Brito

Concordo com o autor, é aplicável, porem ainda não é a realidade no brasil, tenho boas experiências com práticas similares utilizadas com metodologias ágeis, ainda não utilizamos um horário tão flexível, mas o resultado é visível.

Cadeiras diferentes... by Rafael Nunes

É realmente bem complicado dizer se a coisa funciona ou não. Tudo depende de que lado você está.
Por exemplo, na cadeira do dono da empresa, de quem paga a conta no final do mês, é muito complicado você fazer um investimento(em um software, em uma equipe de desenv) sem saber o quanto irá gastar, e quanto tempo isso irá levar.
Mas na cadeira de quem desenvolve, é difícil ser produtivo e criativo, tendo pressões e prazos te limitando.

Como diz o budismo, 'A virtude está no meio', o difícil é achar o meio termo para isso.

Concordo que devemos ficar atentos... by Josue Silva

Lendo o post do Zach, prefiro encarar que a hipótese primária NÃO É dizer se controle de horas é besteira ou não. A verdadeira questão, creio eu, que deveria estar sendo discutida é: "Devo usar o controle de horas e os resultados obtidos por esse controle para DEDUZIR indicadores de produtividade?"
Entendo que esta perspectiva é TOTALMENTE diferente.
Partindo disso, concordo que avaliar os resultados de um "trabalho" criativo através do número de horas é uma análise fria e sem credibilidade.

Movimento nos comentários by yara senger

Interessante o interesse das pessoas nesta discussão! Muitos comentários! Parabéns Rafael Nunes e todos os envolvidos!

Seria o ideal mas... by Wendel Silva

Acredito que tudo em excesso faz mal, um equilíbrio entre a flexibilidade de horários e a presença física na empresa além de definições de metas e recompesas é bastante válido para extrair o potencial criativo.

Interessante é... by Vitor Queiroz

Então, acho que estamos ainda acostumados com o paradigma industrial de produção
Funciona com startups porque o modelo de negócio delas já nasceu assim e proporciona essa liberdade.
Como nas demais situações do mundo de software ainda pensamos "old school" ou seja, prazos e horas controladas fica dificil ver isso funcionando.
Mas toda mudança gera desconforto, se hoje não funciona não significa que não devamos tentar, afinal se no modelo atual não funciona então o modelo atual tem que mudar. E isso só acontece de uma forma... mostrando resultados que comprovem que essa liberdade é melhor
Ou seja... tem que dar a cara pra bater.

Controle de horas + horário flexível by Cristina Orthmann

Também compartilho da mesma ideia de que a produtividade do desenvolvedor depende do seu estado de espírito, por isso concordo com horários flexíveis, trabalho remoto, etc. Mas esta facilidade no horário não significa que a empresa não terá um controle de horas, o tempo estimado de desenvolvimento na minha opinião deve ser informado pelo desenvolvedor e este tempo deve ser controlado para que não tenhamos atrasos.

Re: Controle de horas + horário flexível by Rafael Nunes

'Tempo estimado' para mim também é outra questão que no desenvolvimento de software, é uma arte abstrata.
Como estimar o tempo de trabalho criativo, ou estimar a solução de um problema que você ainda não sabe como resolver....

Re: Controle de horas + horário flexível by Rafael Nunes

'Tempo estimado' no desenvolvimento de software também é quase que uma arte abstrata.
Como estimar tempo de um trabalho criativo, ou estimar o tempo que levará a solução de um problema que você ainda não sabe como irá resolver.

Re: Legal, mas... by Pablo Leary

O problema é a empresa que se sujeita ao cliente. Se sujeita ao cliente por que quem vendeu foi o gerente , encaminhando o contrato para os diretores e cios. A alta hierarquia fica super contente. Agora o trabalho sujo fica para as hierarquias inferiores que precisam trabalham a qualquer hora e momento sacrificando seu bem estar em prol da suas contas particulares. E assim o gera um ciclo vicioso. Essa é minha experiência que já trabalhei em fábrica e software e agências de publicidade. E no final das contas quem fica com o lucro do projeto são as hierarquias superiores. Eu imagino que nas startups de fora a mentalidade é outra.

É aplicável aqui se conseguirmos agir contra os gerentes e diretores com mentalidade de pura exploração .Não fazer, sempre estimar prazos maiores, exigir qualidade de vida. Se todos fazem isso eles cedem.

Precisamos de desenvolvedores com coragem para quebrar o ciclo vicioso by Pablo Leary

Todos os dias sou obrigado a me deslocar da minha para o serviço. Moro em são paulo, uma cidade que sofre a precariedade do transporte público e vias de acesso. Eu me pergunto : Porque eu não posso trabalhar em casa ?

Todas as vezes que eu faço a proposta, dificilmente eu consigo um sim . Isso porque estamos distante de agir somente em prol do resultado. Gostamos de hierarquias, social no serviço e explorar. A mentalidade de exploração perdura desde a escravidão. Mentalidade sadista que não tem nenhuma relação com produção de software.

A mudança vem dos que se sentem explorados, dos desenvolvedores descontentes com o modelo de trabalho imposto no Brasil. Precisamos flexibilizar, mais de que forma ? Se a maioria não se sujeitar naturalmente as empresas cedem. Para isso precisamos da maioria.

Esse modelo é viável e vai funcionar no Brasil. Estamos atrasados em relação a isso mais vamos chegar lá.

Re: Controle de horas + horário flexível by Cristina Orthmann

Rafael, concordo que estimar horas em projetos de P&D é muito difícil, mas não é impossível desde que você tenha todas as regras de negócio bem definidas. Para os projetos que não necessitam de P&D, isto é totalmente possível. Existem diversas ferramentas de estimativas (pontos por caso de uso, pontos por função, opinião de especialista, etc.) que podem nos ajudar nesta tarefa tão desafiadora.

programador é artista by Carlos Eduardo

é o que eu sempre digo.... programador é ARTISTA.. ahhahahaha

Re: Controle de horas + horário flexível by Rafael Nunes

Já usei todas elas também, e nunca vi nenhuma funcionar, exatamente porque tentam mensurar uma atividade não-mensurável.
E 'todas' as regras de negócio bem definidas é outra utopia, em todo projeto que participei, as regras mudam com o tempo(o que acho absolutamente natural, afinal, o mundo e o mercado muda), e o software precisa mudar também

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

22 comentários

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
 InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade