Andei pensando em algumas alterações que seriam necessárias na cultura
da empresa para uma atuação efetiva de SCRUM.
E me deparei com a cultura do cartão de ponto, onde as pessoas são
obrigadas a passar um crachá em uma máquina que registra os horários
de entrada e saída do funcionário.
E por sua vez este registro é utilizado para controlar o tempo que o
funcionário trabalhou, assim dando o direito a empresa de realizar
descontos no salário do funcionário caso não tenha cumprido 8 horas
diariamente, e também garantindo o direito do funcionário cobrar horas
extras pelos registros com tempo superior as 8 horas.
Isso também envolve preenchimento de folha de ponto para horários não
registradas por alguma anormalidade, e em algumas empresas existe
também um sistema de apontamento de horas por projeto. Assim o
funcionário tem que lidar com horas duas vezes: uma com a folha de
ponto que registra os horários e outra com o sistema que registra
horas trabalhadas por projeto.
Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de
controle vá totalmente contra os princípios ágeis e a idéia de
trabalhador do conhecimento. Pois isso acaba desmotivando o
funcionário e fazer ele gastar tempo com uma coisa que ele não deveria
gastar, atuando assim como um impedimento do projeto.
> Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de > controle vá totalmente contra os princípios ágeis e a idéia de > trabalhador do conhecimento. Pois isso acaba desmotivando o > funcionário e fazer ele gastar tempo com uma coisa que ele não deveria > gastar, atuando assim como um impedimento do projeto.
Isso não é apenas contra métodos ágeis, é contra princípios econômicos básicos. Simplificando o problema, este esquema está recompensando não o esforço ou a produtividade mas sim o número de horas que alguém gasta em uma tarefa. Você não precisa trabalhar, não precisa entregar, só precisa estar lá na hora marcada.
Isto dito, não existe nenhum grande impedimento em se implantar uma metodologia ágil neste cenário. Eu já tive diversos casos assim e o maior problema não era a folha de ponto em si e sim o fato que os funcionários faziam corpo mole.
Você diz isso em relação a uma contratação PJ com horas em aberto, pois
existem até contratos PJ com horas fechadas.
Mas e com relação a CLT, você ve algum empedimento em trabalhar com
metodologia ágil?
Qual sua opinião sobre as formas de contratação hoje, aqui no Brasil, e a
forma com que o funcionário é motivado financeiramente a participar
ativamente?
> 2009/6/18 Raphael Molesim <rapha...@infoserver.com.br>:
> > Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de
> > controle vá totalmente contra os princípios ágeis e a idéia de
> > trabalhador do conhecimento. Pois isso acaba desmotivando o
> > funcionário e fazer ele gastar tempo com uma coisa que ele não deveria
> > gastar, atuando assim como um impedimento do projeto.
> Isso não é apenas contra métodos ágeis, é contra princípios econômicos
> básicos. Simplificando o problema, este esquema está recompensando não
> o esforço ou a produtividade mas sim o número de horas que alguém
> gasta em uma tarefa. Você não precisa trabalhar, não precisa entregar,
> só precisa estar lá na hora marcada.
> Isto dito, não existe nenhum grande impedimento em se implantar uma
> metodologia ágil neste cenário. Eu já tive diversos casos assim e o
> maior problema não era a folha de ponto em si e sim o fato que os
> funcionários faziam corpo mole.
2009/6/18 Emmanuel G. Brandão <egomesbran...@gmail.com>:
> Mas e com relação a CLT, você ve algum empedimento em trabalhar com > metodologia ágil?
Não, e eu tenho um exemplo brasileiro. A Globo.com só contrata pessoal por CLT e mesmo antes de adotar metodologias ágeis os melhores times lá sempre tiveram horários muito diferentes do que normalmente se é exigido.
Apesar das leis australianas não serem tão ortodoxas quanto as brasileiras como consultor eu fico à disposição do cliente. No caso do meu cliente atual ele deixou bem claro que quer que todos cheguem as nove e saiam as cinco porque seus funcionários possuem eta cultura e eles não querem que nós os "estraguemos". Num outro projeto recente que participei em Melbourne o cliente não ligava para horário. Movemos nossos stand-ups para 16:30 porque era o único tempo durante o dia em que estávamos todos acordados e juntos.
O importante é medir as coisas certas. Um dos melhores desenvolvedores do meu time na Globo.com só chegava no trabalho meio-dia e ficava lá até cinco da manhã. É claro que a pressão para dar uma chamada de atenção no cara era imensa mas ao mesmo tempo eu tinha que lembrar que este desenvolvedor é tão bom que ele literalmente reimplementou a pilha SOAP em Perl em uma noite. Desde que ele estivesse presente pelo menos por quatro horas para participar das atividades do time eu não me importava que horas ele chegava nem saia.
Eu também concordo inteiramente com o seu último parágrafo, se o cara produz
bem, esta disponível quando precisa, não me importa onde, quando, por que
ele esta, importa é a contribuição do cara para o time.
O problema fica por conta do nosso protetorismo governamental. Com relação a
esse cara, que deveria ser CLT também, como se lidava com questão das horas
trabalhadas? Extras? Sindicato? etc... O último deveria ajudar, mas piorava
mais a situação para alguém que quer e trabalha, como a do desenvolvedor que
você citou.
Acho que o melhor da nossa profissão é que temos uma certa liberdade, não
precisamos estar, normalmente, fixos a um horário, e nem fixos físicamente.
Trabalhei em uma empresa que tinha um caso idêntico, mas lá alguns eram
sócios, então com relação a direitos trabalhista não tinha problema. E eu
trabalhei em uma empresa de Jaraguá do Sul em SC, de cultura alemã, que 7:45
eu tinha que estar sentado na minha mesa, levantar ao meio-dia e voltar às
13 do almoço, e eu era terceiro.
Você tem que se adaptar, não tem jeito, o cliente quer assim.
> 2009/6/18 Emmanuel G. Brandão <egomesbran...@gmail.com>:
> > Mas e com relação a CLT, você ve algum empedimento em trabalhar com
> > metodologia ágil?
> Não, e eu tenho um exemplo brasileiro. A Globo.com só contrata pessoal
> por CLT e mesmo antes de adotar metodologias ágeis os melhores times
> lá sempre tiveram horários muito diferentes do que normalmente se é
> exigido.
> Apesar das leis australianas não serem tão ortodoxas quanto as
> brasileiras como consultor eu fico à disposição do cliente. No caso do
> meu cliente atual ele deixou bem claro que quer que todos cheguem as
> nove e saiam as cinco porque seus funcionários possuem eta cultura e
> eles não querem que nós os "estraguemos". Num outro projeto recente
> que participei em Melbourne o cliente não ligava para horário. Movemos
> nossos stand-ups para 16:30 porque era o único tempo durante o dia em
> que estávamos todos acordados e juntos.
> O importante é medir as coisas certas. Um dos melhores desenvolvedores
> do meu time na Globo.com só chegava no trabalho meio-dia e ficava lá
> até cinco da manhã. É claro que a pressão para dar uma chamada de
> atenção no cara era imensa mas ao mesmo tempo eu tinha que lembrar que
> este desenvolvedor é tão bom que ele literalmente reimplementou a
> pilha SOAP em Perl em uma noite. Desde que ele estivesse presente pelo
> menos por quatro horas para participar das atividades do time eu não
> me importava que horas ele chegava nem saia.
Todo mundo é CLT e na prática não tem hora-extra. Não tem hora-extra pq
ninguém trabalha mais que 8 horas.
Ninguém conta se você trabalhou 8 horas tb.
Pra gente, se você fizer o que falou que ia fazer no sprint está bom. Se
você não vai dar conta, a reunião diária está aí pra isso.
Desenvolvedor que trabalha mais que 8 horas acaba produzindo mais bug que
código limpo. Se o cara chega de ressaca na empresa eu mando pra casa
dormir. Se ele não está 100% aqui, melhor não estar.
Na Alemanha em nenhum lugar que trabalhei também pedia cartão de ponto. Isso
que a CGI por exemplo tem milhares de funcionários, e na prática lá eu
chegava qualquer horário e ia embora qualquer horário. Se meu gerente não
ligasse, ninguém se importava.
Acho que cartão de ponto funciona muito bem e é necessário em atividades
mecânicas, mas nosso campo é puramente intelectual e horas de trabalho não
querem dizer muita coisa...
> 2009/6/18 Emmanuel G. Brandão <egomesbran...@gmail.com>:
> > Mas e com relação a CLT, você ve algum empedimento em trabalhar com
> > metodologia ágil?
> Não, e eu tenho um exemplo brasileiro. A Globo.com só contrata pessoal
> por CLT e mesmo antes de adotar metodologias ágeis os melhores times
> lá sempre tiveram horários muito diferentes do que normalmente se é
> exigido.
> Apesar das leis australianas não serem tão ortodoxas quanto as
> brasileiras como consultor eu fico à disposição do cliente. No caso do
> meu cliente atual ele deixou bem claro que quer que todos cheguem as
> nove e saiam as cinco porque seus funcionários possuem eta cultura e
> eles não querem que nós os "estraguemos". Num outro projeto recente
> que participei em Melbourne o cliente não ligava para horário. Movemos
> nossos stand-ups para 16:30 porque era o único tempo durante o dia em
> que estávamos todos acordados e juntos.
> O importante é medir as coisas certas. Um dos melhores desenvolvedores
> do meu time na Globo.com só chegava no trabalho meio-dia e ficava lá
> até cinco da manhã. É claro que a pressão para dar uma chamada de
> atenção no cara era imensa mas ao mesmo tempo eu tinha que lembrar que
> este desenvolvedor é tão bom que ele literalmente reimplementou a
> pilha SOAP em Perl em uma noite. Desde que ele estivesse presente pelo
> menos por quatro horas para participar das atividades do time eu não
> me importava que horas ele chegava nem saia.
> > Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de
> > controle vá totalmente contra os princípios ágeis e a idéia de
> > trabalhador do conhecimento. Pois isso acaba desmotivando o
> > funcionário e fazer ele gastar tempo com uma coisa que ele não deveria
> > gastar, atuando assim como um impedimento do projeto.
> Isso não é apenas contra métodos ágeis, é contra princípios econômicos
> básicos. Simplificando o problema, este esquema está recompensando não
> o esforço ou a produtividade mas sim o número de horas que alguém
> gasta em uma tarefa. Você não precisa trabalhar, não precisa entregar,
> só precisa estar lá na hora marcada.
> Isto dito, não existe nenhum grande impedimento em se implantar uma
> metodologia ágil neste cenário. Eu já tive diversos casos assim e o
> maior problema não era a folha de ponto em si e sim o fato que os
> funcionários faziam corpo mole.
> > > Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de
> > > controle vá totalmente contra os princípios ágeis e a idéia de
> > > trabalhador do conhecimento. Pois isso acaba desmotivando o
> > > funcionário e fazer ele gastar tempo com uma coisa que ele não deveria
> > > gastar, atuando assim como um impedimento do projeto.
> > Isso não é apenas contra métodos ágeis, é contra princípios econômicos
> > básicos. Simplificando o problema, este esquema está recompensando não
> > o esforço ou a produtividade mas sim o número de horas que alguém
> > gasta em uma tarefa. Você não precisa trabalhar, não precisa entregar,
> > só precisa estar lá na hora marcada.
> > Isto dito, não existe nenhum grande impedimento em se implantar uma
> > metodologia ágil neste cenário. Eu já tive diversos casos assim e o
> > maior problema não era a folha de ponto em si e sim o fato que os
> > funcionários faziam corpo mole.
Esse lance de horas e uma faca de dois gumes. Para abolir esse tipo de
controle voce deve mudar o pensamento para metas e objetivos ao inves
de esforco. Mas ai eh que comeca o problema. Se voce combina um
objetivo e nao alcanca o objetivo certamente o pessoal vai falar que
nao deu certo pq vc nao trabalhou todas as horas que eram necessarias
e bla bla bla.
Eh complicado, mas quando todo mundo tem confianca na equipe a coisa
tende a fluir melhor independente do sistema utilizado.
> > > > Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de
> > > > controle vá totalmente contra os princípios ágeis e a idéia de
> > > > trabalhador do conhecimento. Pois isso acaba desmotivando o
> > > > funcionário e fazer ele gastar tempo com uma coisa que ele não deveria
> > > > gastar, atuando assim como um impedimento do projeto.
> > > Isso não é apenas contra métodos ágeis, é contra princípios econômicos
> > > básicos. Simplificando o problema, este esquema está recompensando não
> > > o esforço ou a produtividade mas sim o número de horas que alguém
> > > gasta em uma tarefa. Você não precisa trabalhar, não precisa entregar,
> > > só precisa estar lá na hora marcada.
> > > Isto dito, não existe nenhum grande impedimento em se implantar uma
> > > metodologia ágil neste cenário. Eu já tive diversos casos assim e o
> > > maior problema não era a folha de ponto em si e sim o fato que os
> > > funcionários faziam corpo mole.
Acho que como convencer a empresa a mudar talvez não seja o ponto. Sei que na prática existem dezenas de variáveis envolvidas em uma decisão de mudar de emprego, mas a solução para quem está infeliz trabalhando na empresa de Pensamento 1.0 acaba sendo caçar uma nova oportunidade, quando for viável.
O mercado de talentos vai regular naturalmente essa equação. As empresas flexíveis e com Pensamento 2.0 vão ficar com os melhores desenvolvedores.
> Acho que como convencer a empresa a mudar talvez não seja o ponto. Sei
> que na prática existem dezenas de variáveis envolvidas em uma decisão de
> mudar de emprego, mas a solução para quem está infeliz trabalhando na
> empresa de Pensamento 1.0 acaba sendo caçar uma nova oportunidade,
> quando for viável.
> O mercado de talentos vai regular naturalmente essa equação. As empresas
> flexíveis e com Pensamento 2.0 vão ficar com os melhores desenvolvedores.
> > Dado que a empresa é obrigada a registrar os horários de entrada e
> > saída dos funcionários, por diversos motivos trabalhistas
> > Como fazer isso sem interromper o trabalho do funcionário? Ou seja,
> > sem que ele perca tempo alimentando sistemas ou folhas de ponto.
> > Dado que um funcionário fez menos de 8 horas, como convencer uma
> > pessoa do Pensamento 1.0 que ela não deve descontar no salário da
> > pessoa?
Acho que isso pode ocorrer se o deficit de horas for enorme, o que
normalmente não é o caso. Mesmo em empresas sem cartão de ponto etc a
média de horas trabalhadas acaba flutuando muito perto de 8h/dia, a
médio prazo. E se alguém estiver abusando, nada que uma conversa não
resolva.
Quanto aos objetivos, o negócio é tentar quebrá-los em unidades
menores: se um desenvolvedor assume um compromisso de fazer terminar
algo em 3 meses, pode rolar mesmo uma tentação em dar uma morcegada no
começo. Se a gente quebra isso em iterações de 1 ou 2 semanas, a coisa
muda de figura. No máximo ele vai poder dar uma morcegada na segunda
de manhã :D
> Esse lance de horas e uma faca de dois gumes. Para abolir esse tipo de
> controle voce deve mudar o pensamento para metas e objetivos ao inves
> de esforco. Mas ai eh que comeca o problema. Se voce combina um
> objetivo e nao alcanca o objetivo certamente o pessoal vai falar que
> nao deu certo pq vc nao trabalhou todas as horas que eram necessarias
> e bla bla bla.
> Eh complicado, mas quando todo mundo tem confianca na equipe a coisa
> tende a fluir melhor independente do sistema utilizado.
> On Jun 18, 12:52 pm, André Carlucci <andrecarlu...@gmail.com> wrote:
>> Crie uma planilha com todos os dias 8 horas e peça para o funcionário
>> assinar no final de cada mês.
>> > Dado que a empresa é obrigada a registrar os horários de entrada e
>> > saída dos funcionários, por diversos motivos trabalhistas
>> > Como fazer isso sem interromper o trabalho do funcionário? Ou seja,
>> > sem que ele perca tempo alimentando sistemas ou folhas de ponto.
>> > Dado que um funcionário fez menos de 8 horas, como convencer uma
>> > pessoa do Pensamento 1.0 que ela não deve descontar no salário da
>> > pessoa?
>> > > > Sei que SCRUM não fala sobre isso, contudo acredito que este tipo de
>> > > > controle vá totalmente contra os princípios ágeis e a idéia de
>> > > > trabalhador do conhecimento. Pois isso acaba desmotivando o
>> > > > funcionário e fazer ele gastar tempo com uma coisa que ele não deveria
>> > > > gastar, atuando assim como um impedimento do projeto.
>> > > Isso não é apenas contra métodos ágeis, é contra princípios econômicos
>> > > básicos. Simplificando o problema, este esquema está recompensando não
>> > > o esforço ou a produtividade mas sim o número de horas que alguém
>> > > gasta em uma tarefa. Você não precisa trabalhar, não precisa entregar,
>> > > só precisa estar lá na hora marcada.
>> > > Isto dito, não existe nenhum grande impedimento em se implantar uma
>> > > metodologia ágil neste cenário. Eu já tive diversos casos assim e o
>> > > maior problema não era a folha de ponto em si e sim o fato que os
>> > > funcionários faziam corpo mole.
> Acho que como convencer a empresa a mudar talvez não seja o ponto. Sei
> que na prática existem dezenas de variáveis envolvidas em uma decisão de
> mudar de emprego, mas a solução para quem está infeliz trabalhando na
> empresa de Pensamento 1.0 acaba sendo caçar uma nova oportunidade,
> quando for viável.
> O mercado de talentos vai regular naturalmente essa equação. As empresas
> flexíveis e com Pensamento 2.0 vão ficar com os melhores desenvolvedores.
> > Dado que a empresa é obrigada a registrar os horários de entrada e
> > saída dos funcionários, por diversos motivos trabalhistas
> > Como fazer isso sem interromper o trabalho do funcionário? Ou seja,
> > sem que ele perca tempo alimentando sistemas ou folhas de ponto.
> > Dado que um funcionário fez menos de 8 horas, como convencer uma
> > pessoa do Pensamento 1.0 que ela não deve descontar no salário da
> > pessoa?
Essa inversão de valores é que é complicada. O objetivo é fazer software bem feito e entregar ou o objetivo é manter a galera por 8 horas no trabalho.
Eu me preocuparia de verdade se existe um trabalho energizado:
- se a equipe está comprometida; - se as estimativas são reais; - se o escopo está sendo cumprido e bem.. enfim qualidade desejada.
Como cumprimos os sprints ? Usando as horas que a equipe tem. Se tá todo mundo feliz cliente, developers... eu dava até folga pro cara numa sexta e depois eu justificava a liberação :-)
Sendo meio advogado do diabo, mas o horario flexivel funciona em times
pequenos.
É muito dificil em uma empresa com 90 ou mais funcionários se adotar esse
tipo de politica. Imagina se o pessoal do café resolve vir só 11 da manhã?
hehehe ou o pessoal da higiene, vir só depois do meio dia?
Já trabalhei em projetos com equipes de até 20 pessoas, num único projeto,
em que não havia tantas restrições quanto a horário, porque havia o turno da
noite também. Ai tinha gente que entrava 11 da manhã e saia 9 da noite,
gente que chegava 2 da tarde e saia 10 da noite e assim por diante, mas
possivel apenas porque estavam todos em um único grande projeto. Quando
chegou a hora de entregar e operar o projeto, e ai entrou em cena o contato
mais direto com os usuários, fornecedores externos, investidores, etc.,
caimos no horário convencional.
Um outro problema com o horario livre x produtividade é que, infelizmente,
boa parte das pessoas não está pronta pra esse nível de liberdade, e abusam.
E o gerenciamento de custos de projeto, também fica mais dificil.
> Essa inversão de valores é que é complicada. O objetivo é fazer software
> bem feito e entregar ou o objetivo é manter a galera por 8 horas no
> trabalho.
> Eu me preocuparia de verdade se existe um trabalho energizado:
> - se a equipe está comprometida;
> - se as estimativas são reais;
> - se o escopo está sendo cumprido e bem.. enfim qualidade desejada.
> Como cumprimos os sprints ? Usando as horas que a equipe tem. Se tá todo
> mundo feliz cliente, developers... eu dava até folga pro cara numa sexta e
> depois eu justificava a liberação :-)
> Sendo meio advogado do diabo, mas o horario flexivel funciona em times > pequenos. > É muito dificil em uma empresa com 90 ou mais funcionários se adotar esse > tipo de politica. Imagina se o pessoal do café resolve vir só 11 da manhã? > hehehe ou o pessoal da higiene, vir só depois do meio dia?
Como alguém falou antes existe uma diferença enorme entre trabalho criativo e repetitivo. Seus exemplos não são de trabalho criativo.
> Já trabalhei em projetos com equipes de até 20 pessoas, num único projeto, > em que não havia tantas restrições quanto a horário, porque havia o turno da > noite também. Ai tinha gente que entrava 11 da manhã e saia 9 da noite, > gente que chegava 2 da tarde e saia 10 da noite e assim por diante, mas > possivel apenas porque estavam todos em um único grande projeto. Quando > chegou a hora de entregar e operar o projeto, e ai entrou em cena o contato > mais direto com os usuários, fornecedores externos, investidores, etc., > caimos no horário convencional.
Bom, pelo visto seu projeto seguiu uma metodologia bem waterfall. Antes de entrar no ponto de horário de trabalho talvez fosse melhor rever a metodologia primeiro. E não necessariamente para alguma metodologia ágil, basta algo iterativo para começar -lembrando que waterfall é um anti-pattern desde sua concepção.
> Um outro problema com o horario livre x produtividade é que, infelizmente, > boa parte das pessoas não está pronta pra esse nível de liberdade, e abusam. > E o gerenciamento de custos de projeto, também fica mais dificil.
Se você não confia que um empregado possui maturidade suficiente para controlar uma coisa simples como seu horário de trabalho como você confia a ele a construção de sistemas que processam milhões de reais todo dia?
Eu conheço uma empresa que possui uma contradição tremenda: por um lado ela usa a tal da Metanóia que tem principios de auto-gestão, etc, mas por outro lado, usa cartão ponto e tem NetEye instalado nos micros para monitorar o que a galera faz. De modo geral, vejo que o brasileiro não está preparado para isso, nem trabalhadores, nem empregradores. Os trabalhadores normalmente confundem liberdade e auto-gestão com "posso fazer o que eu quero". Por outro lado, empregadores não estão preparados para que, caso o trabalhador termine as tarefas antes do prazo, ele seja recompensado com isso. Normalmente a recompensa é mais trabalho.
Existe um porém no seu exemplo, pessoas que são ligadas à alguma atividade
fixa, não podem ter horários flexíveis: telefonista, tem o horário do
atendimento e precisa estar do lado do aparelho de telefone (desconsidere
telefone por IP); pessoal da limpeza, tem que estar no local e limpar
durante o horário de uso dos outros; operário de uma indústria
automobilística, não pode quebrar a linha de produção e por aí vai.
Agora, analistas, desenvolvedores, DBA's, admin de rede, e afins; podem
ficar em casa e trabalhar, pode ter flexíbilidade, porém vão ter que cumprir
horários como todo mundo, no caso de uma reunião, eles não poderiam deixar
de ir, concorda?
Esse cenário não é restrito ao nosso mundo, na indústria, anos atrás antes
desse pessoal cool da informática surgir, já existiam casos de sucesso. Os
exemplos estão nos livros Você esta
louco!<http://www.submarino.com.br/produto/1/1672779/voce+esta+louco%21:+uma...>e
Virando
a própria mesa<http://www.submarino.com.br/produto/1/168336/virando+a+propria+mesa>,
ambos fantásticos mesmo para quem não é gerente, administrador de empresa. O
primeiro mostra mais coisas criativas, o segundo parece mais administrativo,
mas ambos são simples e legais de ler. Quem referencio o Ricardo Semler, o
autor, foi o Akita na palestra que ele deu no último encontro Locaweb, veja
a partir do slide 177, daqui http://tr.im/oZP1
> Sendo meio advogado do diabo, mas o horario flexivel funciona em times
> pequenos.
> É muito dificil em uma empresa com 90 ou mais funcionários se adotar esse
> tipo de politica. Imagina se o pessoal do café resolve vir só 11 da manhã?
> hehehe ou o pessoal da higiene, vir só depois do meio dia?
> Já trabalhei em projetos com equipes de até 20 pessoas, num único projeto,
> em que não havia tantas restrições quanto a horário, porque havia o turno da
> noite também. Ai tinha gente que entrava 11 da manhã e saia 9 da noite,
> gente que chegava 2 da tarde e saia 10 da noite e assim por diante, mas
> possivel apenas porque estavam todos em um único grande projeto. Quando
> chegou a hora de entregar e operar o projeto, e ai entrou em cena o contato
> mais direto com os usuários, fornecedores externos, investidores, etc.,
> caimos no horário convencional.
> Um outro problema com o horario livre x produtividade é que, infelizmente,
> boa parte das pessoas não está pronta pra esse nível de liberdade, e abusam.
> E o gerenciamento de custos de projeto, também fica mais dificil.
> Essa inversão de valores é que é complicada. O objetivo é fazer software
>> bem feito e entregar ou o objetivo é manter a galera por 8 horas no
>> trabalho.
>> Eu me preocuparia de verdade se existe um trabalho energizado:
>> - se a equipe está comprometida;
>> - se as estimativas são reais;
>> - se o escopo está sendo cumprido e bem.. enfim qualidade desejada.
>> Como cumprimos os sprints ? Usando as horas que a equipe tem. Se tá todo
>> mundo feliz cliente, developers... eu dava até folga pro cara numa sexta e
>> depois eu justificava a liberação :-)
Não acho que seja uma contradição a empresa deixar um monitoramento ligado,
monitorar é uma coisa, agora o gerente vir no fim do mês com uma folinha
dizendo "você ficou 21 horas na internet, vamo maneirar" é complicado. O
desenvolvedor produziu? Entregou no prazo? O cliente esta satisfeito? Então
por que cargas d'agua você vai irritar o cara por 21 horas? Eram sites
racistas, pornográficos, balela total? As vezes não! As vezes o cara só esta
lendo sobre uma linguagem funcional por que quer dar uma pequena pausa...
Não pode?
Quanto ao problema com os brasileiros, é complicado mesmo, aqui o espírito
de equipe, de confiança, de trabalho é diferente de um alemã, eu vi isso na
prática. Mas se o objetivo não é ter equipes auto-gerenciaveis? Então você
tem que dar toda a liberdade para o cara, e monitorar... Se extrapolar e não
estiver contribuindo com as atividades do time, você dá um aviso, se
continuar, você dá "tapa na cara" e mostra a realidade pro cara...
Continuou? Poxa, você realmente que esse cara na sua equipe?
Diferentemente do exemplo do Phillip, em que o cara extrapolava no horário,
mas cumpria o necessário.
No e-mail anterior eu comentei dos livros do Ricardo Semler, ele tem uma
frase muito boa: "Estamos preparados para trabalhar as sextas-feira a noite,
domingo a tarde... Mas não estamos preparados para irmos no cinema
terça-feira depois do almoço!". Quem aqui já fez isso?
> Eu conheço uma empresa que possui uma contradição tremenda: por um lado
> ela usa a tal da Metanóia que tem principios de auto-gestão, etc, mas por
> outro lado, usa cartão ponto e tem NetEye instalado nos micros para
> monitorar o que a galera faz.
> De modo geral, vejo que o brasileiro não está preparado para isso, nem
> trabalhadores, nem empregradores. Os trabalhadores normalmente confundem
> liberdade e auto-gestão com "posso fazer o que eu quero". Por outro lado,
> empregadores não estão preparados para que, caso o trabalhador termine as
> tarefas antes do prazo, ele seja recompensado com isso. Normalmente a
> recompensa é mais trabalho.
Vou colocar alguns pontos que também devem ser considerados:
1 - Profissionais que trabalham diretamente com o cliente devem ter ciência dos horários que o mesmo trabalha, não seria nada legal o cliente ligar as 10 horas e o funcionário nunca está disponivel.
2 - Profissionais que influênciam na produtividade, como coordenadores, devem estar presentes quando os funcionários precisarem, assim o trabalho fica mais produtivo tendo em vista que os problemas são solucionados assim que vão surgindo.
3 - Se estivemos falando de programadores, esses sim acho que deve trabalhar por metas e não horário. Em meus casos de experiência, quando se bonifica de alguma forma por metas cumpridas, em 99% dos casos há um grande ganho de produtividade.
At,
Allan Clempe
From: Cássio Rogério Eskelsen Sent: Friday, June 19, 2009 8:51 AM
To: dotnetarchitects@googlegroups.com Subject: [dotnetarchitects] Re: Off-topic:Cartão de Ponto e SCRUM
Eu conheço uma empresa que possui uma contradição tremenda: por um lado ela usa a tal da Metanóia que tem principios de auto-gestão, etc, mas por outro lado, usa cartão ponto e tem NetEye instalado nos micros para monitorar o que a galera faz.
De modo geral, vejo que o brasileiro não está preparado para isso, nem trabalhadores, nem empregradores. Os trabalhadores normalmente confundem liberdade e auto-gestão com "posso fazer o que eu quero". Por outro lado, empregadores não estão preparados para que, caso o trabalhador termine as tarefas antes do prazo, ele seja recompensado com isso. Normalmente a recompensa é mais trabalho.
Concordo bastante com o Allan pq se precisa ter um envolvimento direto com cliente ou resolução de problemas quando eles são criados o empregado deve estar disponível.
Outro ponto que foi dito é que dá pra ter liberdade de trabalhar em casa. Isto é outro ponto mas que é bom o empregado estar disponível é verdade.
Os meus últimos 50 centavos são que se estamos usando métodos ágeis, daí sim seria melhor que equipe estive toda junta (no horário e geograficamente) porque uma coisa é você conversar pelo e-mail ou mensageiro e outra é no face à face.
> Vou colocar alguns pontos que também devem ser considerados:
> 1 - Profissionais que trabalham diretamente com o cliente devem ter ciência > dos horários que o mesmo trabalha, não seria nada legal o cliente ligar as > 10 horas e o funcionário nunca está disponivel. > 2 - Profissionais que influênciam na produtividade, como coordenadores, > devem estar presentes quando os funcionários precisarem, assim o trabalho > fica mais produtivo tendo em vista que os problemas são solucionados assim > que vão surgindo. > 3 - Se estivemos falando de programadores, esses sim acho que deve > trabalhar por metas e não horário. Em meus casos de experiência, quando se > bonifica de alguma forma por metas cumpridas, em 99% dos casos há um grande > ganho de produtividade.
OK... Mas não quer dizer que não funcione com equipes distribuídas! Existem
até casos de sucesso, o Alexandre Magno comentou no treinamento de Scrum.
É só saber se comunicar direito...
> Concordo bastante com o Allan pq se precisa ter um envolvimento direto com
> cliente ou resolução de problemas quando eles são criados o empregado deve
> estar disponível.
> Outro ponto que foi dito é que dá pra ter liberdade de trabalhar em casa.
> Isto é outro ponto mas que é bom o empregado estar disponível é verdade.
> Os meus últimos 50 centavos são que se estamos usando métodos ágeis, daí
> sim seria melhor que equipe estive toda junta (no horário e geograficamente)
> porque uma coisa é você conversar pelo e-mail ou mensageiro e outra é no
> face à face.
>> Vou colocar alguns pontos que também devem ser considerados:
>> 1 - Profissionais que trabalham diretamente com o cliente devem ter
>> ciência dos horários que o mesmo trabalha, não seria nada legal o cliente
>> ligar as 10 horas e o funcionário nunca está disponivel.
>> 2 - Profissionais que influênciam na produtividade, como coordenadores,
>> devem estar presentes quando os funcionários precisarem, assim o trabalho
>> fica mais produtivo tendo em vista que os problemas são solucionados assim
>> que vão surgindo.
>> 3 - Se estivemos falando de programadores, esses sim acho que deve
>> trabalhar por metas e não horário. Em meus casos de experiência, quando se
>> bonifica de alguma forma por metas cumpridas, em 99% dos casos há um grande
>> ganho de produtividade.
Minha empresa usa métodos ágeis, com equipe distribuída em 4 países e
3 fusos, e funciona bem. MSN, SharedView e Skype funcionam que é uma
beleza!
Acho que funciona ainda melhor com equipes ágeis pois as metodologias
ágeis permitem o auto-gerenciamento; mesmo eu estando longe
fisicamente da empresa, a cada 2 semanas eu termino uma iteração e
todo mundo vê o que eu fiz mesmo, não dá pra sair muito do trilho,
viajar na maionese etc.
2009/6/19 Emmanuel G. Brandão <egomesbran...@gmail.com>:
> OK... Mas não quer dizer que não funcione com equipes distribuídas! Existem
> até casos de sucesso, o Alexandre Magno comentou no treinamento de Scrum.
> É só saber se comunicar direito...
> Brandão, Emmanuel G.
> CSM
> blog.egomesbrandao.net
>> Concordo bastante com o Allan pq se precisa ter um envolvimento direto com
>> cliente ou resolução de problemas quando eles são criados o empregado deve
>> estar disponível.
>> Outro ponto que foi dito é que dá pra ter liberdade de trabalhar em casa.
>> Isto é outro ponto mas que é bom o empregado estar disponível é verdade.
>> Os meus últimos 50 centavos são que se estamos usando métodos ágeis, daí
>> sim seria melhor que equipe estive toda junta (no horário e geograficamente)
>> porque uma coisa é você conversar pelo e-mail ou mensageiro e outra é no
>> face à face.
>> 2009/6/19 Allan Clempe <allan.cle...@gmail.com>
>>> Vou colocar alguns pontos que também devem ser considerados:
>>> 1 - Profissionais que trabalham diretamente com o cliente devem ter
>>> ciência dos horários que o mesmo trabalha, não seria nada legal o cliente
>>> ligar as 10 horas e o funcionário nunca está disponivel.
>>> 2 - Profissionais que influênciam na produtividade, como coordenadores,
>>> devem estar presentes quando os funcionários precisarem, assim o trabalho
>>> fica mais produtivo tendo em vista que os problemas são solucionados assim
>>> que vão surgindo.
>>> 3 - Se estivemos falando de programadores, esses sim acho que deve
>>> trabalhar por metas e não horário. Em meus casos de experiência, quando se
>>> bonifica de alguma forma por metas cumpridas, em 99% dos casos há um grande
>>> ganho de produtividade.
Em equipes distribuidas tem que ter um pessoal que faz o meio de campo, para que tenha sempre uma comunicação contínua entre uma equipe e outra. A documentação também tem que ser impecável, para cada equipe saiba exatamente os limites de suas responsabilidades.
Que funciona, com certeza funciona, mas tem que tomar uma série de cuidados para que a coisa não vire uma "massaroca" : )
From: Emmanuel G. Brandão Sent: Friday, June 19, 2009 11:40 AM
To: dotnetarchitects@googlegroups.com Subject: [dotnetarchitects] Re: Off-topic:Cartão de Ponto e SCRUM
OK... Mas não quer dizer que não funcione com equipes distribuídas! Existem até casos de sucesso, o Alexandre Magno comentou no treinamento de Scrum.
É só saber se comunicar direito...
Concordo bastante com o Allan pq se precisa ter um envolvimento direto com cliente ou resolução de problemas quando eles são criados o empregado deve estar disponível.
Outro ponto que foi dito é que dá pra ter liberdade de trabalhar em casa. Isto é outro ponto mas que é bom o empregado estar disponível é verdade.
Os meus últimos 50 centavos são que se estamos usando métodos ágeis, daí sim seria melhor que equipe estive toda junta (no horário e geograficamente) porque uma coisa é você conversar pelo e-mail ou mensageiro e outra é no face à face.
Vou colocar alguns pontos que também devem ser considerados:
1 - Profissionais que trabalham diretamente com o cliente devem ter ciência dos horários que o mesmo trabalha, não seria nada legal o cliente ligar as 10 horas e o funcionário nunca está disponivel.
2 - Profissionais que influênciam na produtividade, como coordenadores, devem estar presentes quando os funcionários precisarem, assim o trabalho fica mais produtivo tendo em vista que os problemas são solucionados assim que vão surgindo.
3 - Se estivemos falando de programadores, esses sim acho que deve trabalhar por metas e não horário. Em meus casos de experiência, quando se bonifica de alguma forma por metas cumpridas, em 99% dos casos há um grande ganho de produtividade.
Concordo que a comunicação tem que ser muito boa. Por exemplo todo
mundo tem que estar no MSN ou Skype o tempo todo, pra poder responder
a qq pergunta, ajudar a decidir qq coisa na hora, sem burocracia.
Agora, qto a "documentação impecável", não sei não. Seja em time
distribuído ou local, em geral, documento demais só serve pra ficar
defasado e perder tempo. Em geral um time que precisa de documento
demais é porque está se comunicando de menos, IMHO (não estou falando
de documentação para os clientes e outros stakeholders, claro)
> Em equipes distribuidas tem que ter um pessoal que faz o meio de campo, para
> que tenha sempre uma comunicação contínua entre uma equipe e outra. A
> documentação também tem que ser impecável, para cada equipe saiba exatamente
> os limites de suas responsabilidades.
> Que funciona, com certeza funciona, mas tem que tomar uma série de cuidados
> para que a coisa não vire uma "massaroca" : )
> From: Emmanuel G. Brandão
> Sent: Friday, June 19, 2009 11:40 AM
> To: dotnetarchitects@googlegroups.com
> Subject: [dotnetarchitects] Re: Off-topic:Cartão de Ponto e SCRUM
> OK... Mas não quer dizer que não funcione com equipes distribuídas! Existem
> até casos de sucesso, o Alexandre Magno comentou no treinamento de Scrum.
> É só saber se comunicar direito...
> Brandão, Emmanuel G.
> CSM
> blog.egomesbrandao.net
>> Concordo bastante com o Allan pq se precisa ter um envolvimento direto com
>> cliente ou resolução de problemas quando eles são criados o empregado deve
>> estar disponível.
>> Outro ponto que foi dito é que dá pra ter liberdade de trabalhar em casa.
>> Isto é outro ponto mas que é bom o empregado estar disponível é verdade.
>> Os meus últimos 50 centavos são que se estamos usando métodos ágeis, daí
>> sim seria melhor que equipe estive toda junta (no horário e geograficamente)
>> porque uma coisa é você conversar pelo e-mail ou mensageiro e outra é no
>> face à face.
>> 2009/6/19 Allan Clempe <allan.cle...@gmail.com>
>>> Vou colocar alguns pontos que também devem ser considerados:
>>> 1 - Profissionais que trabalham diretamente com o cliente devem ter
>>> ciência dos horários que o mesmo trabalha, não seria nada legal o cliente
>>> ligar as 10 horas e o funcionário nunca está disponivel.
>>> 2 - Profissionais que influênciam na produtividade, como coordenadores,
>>> devem estar presentes quando os funcionários precisarem, assim o trabalho
>>> fica mais produtivo tendo em vista que os problemas são solucionados assim
>>> que vão surgindo.
>>> 3 - Se estivemos falando de programadores, esses sim acho que deve
>>> trabalhar por metas e não horário. Em meus casos de experiência, quando se
>>> bonifica de alguma forma por metas cumpridas, em 99% dos casos há um grande
>>> ganho de produtividade.
