Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado 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?
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?
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?
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?
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 é 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.
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.
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á.
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 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.
É 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.
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.
Interessante o interesse das pessoas nesta discussão! Muitos comentários! Parabéns Rafael Nunes e todos os envolvidos!
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.
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.
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.
'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....
'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.
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.
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á.
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.
é o que eu sempre digo.... programador é ARTISTA.. ahhahahaha
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
Os papéis de Desenvolvedor e de Analista de teste foram distanciados no modelo tradicional de desenvolvimento e, agora, as práticas ágeis buscam aproximá-los em prol de software em funcionamento.
Apresentamos aqui os principais conceitos vistos no workshop de Ash Maurya sobre a aplicabilidade prática do Lean Canvas
Na quarta parte da série sobre equipes de alto desempenho veremos como identificar os acontecimentos em uma equipe que sai da fase de Conflitos e entra na fase de Normatização.
Ash Maurya, um dos maiores especialistas em Lean Startup falou com exclusividade ao InfoQ Brasil sobre a aplicabilidade do Lean e como seus conceitos contribuem com empreendimentos e equipes ágeis.
Conheça um guia prático, proposto por Esther Derby, para diagnosticar a eficácia de equipes, usando mapas mentais como referência, além de entender o perigo de equipes disfuncionais,
Esther Derby aposta os riscos em se transformar estimativas em um cronograma; e Allan Kelly apresenta pesquisas indicando ser impossível prever o tempo para se realizar uma atividade.
Martin Odersky, criador do Scala, discute o futuro da linguagem, trata da questão de quebra de compatibilidade binária e faz comparações com F# e Java.
Anil Gaur da Oracle fala sobre o cronograma para o Java EE 7, APIs para computação em nuvem, ferramentas e suporte a PaaS.
22 comentários
Acompanhar Discussão Responder