Off-topic:Cartão de Ponto e SCRUM

[Raphael Molesim]

Pessoal,

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.

[Phillip Calçado]

Olá,

2009/6/18 Raphael Molesim <raph...@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.

[]s

--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br

[Emmanuel G. Brandão]

Phillip,

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?

Brandão, Emmanuel G.
CSM
msn: egomes...@hotmail.com
http://egomesbrandao.blogspot.com

2009/6/18 Phillip Calçado <pcal...@gmail.com>

[Phillip Calçado]

Oi, Emmanual,

2009/6/18 Emmanuel G. Brandão <egomes...@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.

[Emmanuel G. Brandão]

Phillip,

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.

Brandão, Emmanuel G.
CSM
msn: egomes...@hotmail.com
http://egomesbrandao.blogspot.com

2009/6/18 Phillip Calçado <pcal...@gmail.com>

[André Carlucci]

Aqui a gente não tem cartão de ponto.

 

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...

 

André

 

2009/6/18 Phillip Calçado <pcal...@gmail.com>

--
André Carlucci

[Raphael Molesim]

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?

On 18 jun, 10:19, Phillip Calçado <pcalc...@gmail.com> wrote:
> Olá,
>
> 2009/6/18 Raphael Molesim <rapha...@infoserver.com.br>:

[André Carlucci]

 

Crie uma planilha com todos os dias 8 horas e peça para o funcionário assinar no final de cada mês.

 

2009/6/18 Raphael Molesim <raph...@infoserver.com.br>

--
André Carlucci

[tucaz]

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.

Att.,
Antonio Carlos Zegunis Filho
http://blog.tucaz.net

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.
>

> 2009/6/18 Raphael Molesim <rapha...@infoserver.com.br>

[Leo D]

A empresa é obrigada mesmo a isso?

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.

[Juliano Oliveira]

Alguma empresa Pensamento 2.0 ai por favor? Tô precisando de uma.. hehe

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/18 Leo D <l...@codigofluente.com.br>

[Rodrigo Vieira]

Tucaz,

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


Rodrigo

2009/6/18 tucaz <tuc...@gmail.com>:

[Cássio Rogério Eskelsen]

Pior que são obrigadas sim :(

Cássio Rogério Eskelsen
 

2009/6/18 Leo D <l...@codigofluente.com.br>

[Lobo Junior]

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 :-)

 

Lobo Jr

[Rubens Souza]

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.

 

2009/6/19 Lobo Junior <lobi...@gmail.com>

[Phillip Calçado]

Oi,

2009/6/19 Rubens Souza <souza....@gmail.com>:

> 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?

[Cássio Rogério Eskelsen]

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.

Cássio Rogério Eskelsen
 

[Emmanuel G. Brandão]

Rubens.

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! e Virando a própria 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

Brandão, Emmanuel G.
CSM
msn: egomes...@hotmail.com
http://egomesbrandao.blogspot.com

2009/6/19 Rubens Souza <souza....@gmail.com>

[Emmanuel G. Brandã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?

Brandão, Emmanuel G.
CSM
msn: egomes...@hotmail.com
http://egomesbrandao.blogspot.com

2009/6/19 Cássio Rogério Eskelsen <eske...@gmail.com>

[Allan Clempe]

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

[Jeferson Spencer Chaves]

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.

------------------------------------------------------------
Jéferson Spencer Chaves

2009/6/19 Allan Clempe <allan....@gmail.com>

[Emmanuel G. Brandão]

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

2009/6/19 Jeferson Spencer Chaves <jeferso...@gmail.com>

[Rodrigo Vieira]

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 <egomes...@gmail.com>:

[Allan Clempe]

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: dotnetar...@googlegroups.com

Subject: [dotnetarchitects] Re: Off-topic:Cartão de Ponto e SCRUM

[Rodrigo Vieira]

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)

2009/6/19 Allan Clempe <allan....@gmail.com>:

[Bira]

Pessoal, defendo que o profissional deve ser medido por resultado e
não por hora trabalhada, horário de entrada/saída etc.

Mas... qual o problema com horários?

Vejo que - e não estão dizendo diretamente para as pessoas que estão
nesta thread - que alguns querem trabalhar com times Scrum, Ágeis para
terem mais liberdade, para não precisar chegar cedo no escritório...

Mas, não podemos nos esconder no rótulo "trabalhador do conhecimento",
"empresa 2.0"... só para criar a condição, por exemplo, de acordar 11
horas da manhã todos os dias porque você não gosta de levantar cedo.
Senão, com isto, estaremos "lutando" pelas coisas certas, mas talvez
pelos motivos errados.

Veja, se o projeto/empresa propicia isto, ótimo. Porque nada melhor
que fazer o que gostamos e trabalhar num setup que respeita as
características/necessidades individuais de cada membro do time.

Entretanto, quando estamos atuando numa empresa, estamos representando
um papel. Papel/personagem que a empresa nos paga para representar.
Tanto se trata de uma encenação que não trabalhamos de bermuda, não
bebemos cerveja... Ou seja, em cada ambiente/situação representamos um
papel. Num casamento, por exemplo, pode até ser do nosso irmão,
representamos um papel. Andamos diferente, nos vestimos diferentes.
Neste raciocínio, chegar as 9h00 no escritório pode fazer parte da
representação do seu papel e isto não deve ser encarado de uma forma
tão ruim assim.

Mas, respondendo a questão colocada pelo Rafael Molesim, não vejo o
cartão de ponto como um impedidor para atuação de times ágeis. Não é
tão favorável, mas acho que dá para adaptar e se chegar num
denominador comum. A empresa pode, por exemplo, entender que todo o
time poderá não estar no escritório as 9 de manhã, pois o foco do time
é resultado e não horário de chegada. E o time, por sua vez, também
pode tentar entender um pouco a cultura da empresa e colaborar para
não chegar no escritório 3 horas da tarde.

Acredito que com bom senso de ambas as partes sempre há a
possibilidade de se chegar num consenso. Mas, para a empresa se
predispor a refletir, tem que haver "dor". Ela tem que estar com
muitos problemas em projeto e querendo soluções. Só nestes cenários
teremos chance de quebrar paradigmas.

Eu só estou querendo fazer aqui - em prol da reflexão - um pouco do
papel do Advogado do Diabo. : )


Ubiratan Padilha
Project Manager, CSM, Especialista em Usabilidade
http://www.linkedin.com/in/ubiratanpadilha
http://twitter.com/ubiratanpadilha

On 19 jun, 12:38, Rodrigo Vieira <rodrig...@gmail.com> wrote:
> 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)
>

> 2009/6/19 Allan Clempe <allan.cle...@gmail.com>:

>
>
>
> > 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: dotnetar...@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
>

> > 2009/6/19 Jeferson Spencer Chaves <jefersonspen...@gmail.com>

>
> >> 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.
>
> >> ------------------------------------------------------------
> >> Jéferson Spencer Chaves
>

> >> 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.
>
> >>> At,

> >>> Allan Clempe- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -

[Allan Clempe]

Documentação impecável != Muitos Documentos

O que eu quis dizer é que qualquer alteração feita no decorrer do projeto
tem que ser contantemente atualizado para toda a equipe, distribuida ou não.

At,
Allan Clempe
--------------------------------------------------
From: "Rodrigo Vieira" <rodr...@gmail.com>
Sent: Friday, June 19, 2009 12:38 PM

[Rodrigo Vieira]

Saquei :)

Sobre a questão de times distribuídos, o maior problema que vejo na
minha própria experiência nem é esse negócio de comunicação,
documentação etc..é a questão social e política. É mais fácil mandar
alguém que tá longe fazer um serviço chato, por email, do que
pessoalmente; e a gente perde o bate-papo na cantina, a cervejinha no
fim do expediente etc. Isso é muito importante.

2009/6/19 Allan Clempe <allan....@gmail.com>:

[Rubens Souza]

Ainda de advogado do diabo, o caso é que as empresas, como organização, misturam pessoas com atividades criativas e atividades operacionais. Se você trabalha na TI de uma empresa de grande porte, será muito dificil ter os horarios alternativos, porque o atendimento, que é operacional, precisa do suporte de TI, a infra, que é operacional precisa de TI, o comercial, produtos, marketing,etc., pra não falar nos clientes e fornecedores externos, na diretoria e presidência... quando você olha a empresa como um todo, virtualmente impossível que a TI ou o desenvolvimento tenha horarios muito flexíveis. Talvez numa empresa grande, que tenha uma equipe de inovação tecnológica, seja possivel. Mas é para apenas uma parte da equipe.

 

 

 

 

2009/6/19 Rodrigo Vieira <rodr...@gmail.com>

[Giovanni Bassi]

Raphael,

Bater cartão leva 30 segundos. Na boa, não é impedimento. E o problema não é esse, não é verdade?

Abolir o pagamento de horas pode significar abuso por parte do contratante. Já que está pagando por mês, então pede para todo mundo ficar até tarde todo dia. Já vi isso acontecer. A empresa não tinha pagamento de hora extra, mas tinha muita hora extra. Ok, esse é outro problema, mas é só para deixar claro que o cartão de ponto em si não é o problema.

Por fim, acho que temos que medir entrega, e não horas.

Em resumo: uma empresa equilibrada consegue trabalhar sem isso. De quem depende isso? Da gerência, é claro. Em uma empresa projetizada e ágil, o desenvolvedor não tem gerente de projeto, já que o time é autogerenciado. Mas ainda tem gerente funcional, diretor, etc. Esses são os caras que vão trabalhar para garantir o equilibrio. Vão medir a entrega do time, o amadurecimento, etc. Vão preparar o ambiente para que o time possa ser ágil, pagando cursos, aprovando a compra das ferramentas necessárias, contratando consultores para acompanhar.
Afinal, não adianta botar um bando de desenvolvedor que fala que trabalha ágil e dizer "trabalhem aí, boa sorte". Apesar de isso ser o que acontece com razoável frequência.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/6/18 Raphael Molesim <raph...@infoserver.com.br>

Pessoal,

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.

[Phillip Calçado]

Oi,

2009/6/20 Bira <ubiratan...@gmail.com>:

> Entretanto, quando estamos atuando numa empresa, estamos representando
> um papel. Papel/personagem que a empresa nos paga para representar.

Discordo e pediria demissão de qualquer empresa que me contratasse
para fingir ser algo. A empresa me paga porque precisa do meu
trabalho. Ela -na maioria das vezes- não precisa que eu acorde às 7 da
manhã, pegue o pior horário de engarrafamentos, trabalhe pela manhã
ainda com sono, comece a ficar produtivo às 11 horas, vá para o almoço
e fique lento novamente e á embora encarar 4 horas de engarrafamento.
O que ela precisa é que eu entregue.

> Tanto se trata de uma encenação que não trabalhamos de bermuda, não
> bebemos cerveja... Ou seja, em cada ambiente/situação representamos um
> papel. Num casamento, por exemplo, pode até ser do nosso irmão,
> representamos um papel. Andamos diferente, nos vestimos diferentes.
> Neste raciocínio, chegar as 9h00 no escritório pode fazer parte da
> representação do seu papel e isto não deve ser encarado de uma forma
> tão ruim assim.

Na minha empresa, em boa parte dos meus clientes e na minha empresa
anterior nós bebemos cerveja e vamos de bermuda. Qual o problema
disso?

[Giovanni Bassi]

Philip,

Problema nenhum.
Ainda assim, o que o Ubiratan está dizendo é algo comprovado por diversas teorias psicológicas. Papéis sociais são algo presentes em todos. Você é parceiro de sua esposa, amigo dos seus amigos, funcionário da empresa, filho dos seus pais, pai dos seus filhos, etc, etc, etc... Você até pode dizer que é o mesmo em todas as situações, que é sincero e verdadeiro, e eu acredito. Ainda assim, com seus amigos você de repente solta um palavrão em uma situação que com sua mãe ou sua filha não soltaria. Isso é papel social: você adequa suas atitudes ao papel que está cumprindo naquele momento.
Da absoluta mesma forma, isso é aplicado ao ambiente de trabalho. Cada empresa possui uma cultura, e cada empresa possui uma expectativa dos funcionários baseada nessa cultura que possui. O que você disse é que na empresa em que trabalha a cultura permite bermuda e cerveja. Somente por ela permitir é que você pode ir de bermuda, não porque você usa bermuda no dia a dia e acha que pode, ou quer ser você mesmo. A empresa quer que se lixe para você ser você mesmo. Quer a prova? Pega um notebook da empresa e fala que agora ele é seu, porque você é assim, você pega coisas. Rua. Passe a mão na bunda da secretária e diga que na sua cidade é assim. Rua. São exemplos extremos, mas servem somente para comprovar uma coisa: há limites, impostos pela cultura. E você vai ter que se adequar se quiser trabalhar lá.
O fato de você ter a liberdade de pedir demissão não muda isso absolutamente nada.
(Não estou dizendo que não concordo com a bermuda, muito pelo contrário, já até escrevi sobre isso.)

Com isso claro, voltamos a questão. Quantas empresas ainda vivem no tempo do cartão de ponto? Quantas ainda vivem no tempo em que bermuda é vista como algo até ofensivo? É óbvio, não precisamos trabalhar nelas, mas muitos trabalham, incluindo com certeza alguns dos colegas daqui do grupo. A questão é: como trabalhar isso? Dizer que vai sair resolve o problema, mas só para quem saiu!

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/6/19 Phillip Calçado <pcal...@gmail.com>

[Phillip Calçado]

Oi,

2009/6/20 Giovanni Bassi <gig...@giggio.net>:

> Ainda assim, o que o Ubiratan está dizendo é algo comprovado por diversas
> teorias psicológicas. Papéis sociais são algo presentes em todos. Você é
> parceiro de sua esposa, amigo dos seus amigos, funcionário da empresa, filho
> dos seus pais, pai dos seus filhos, etc, etc, etc... Você até pode dizer que
> é o mesmo em todas as situações, que é sincero e verdadeiro, e eu acredito.
> Ainda assim, com seus amigos você de repente solta um palavrão em uma
> situação que com sua mãe ou sua filha não soltaria. Isso é papel social:
> você adequa suas atitudes ao papel que está cumprindo naquele momento.

Eu não discordei disso. Eu discordo de qu "se trata de uma encenação".
Eu tenho um jeito específico para lidar com meus clientes, com meu
chefe e com parceiros profissionais que é bem diferente do jeito que
trato pessoas num bar. Isto não quer dizer que eu esteja encenando
nada.

> Da absoluta mesma forma, isso é aplicado ao ambiente de trabalho. Cada
> empresa possui uma cultura, e cada empresa possui uma expectativa dos
> funcionários baseada nessa cultura que possui. O que você disse é que na
> empresa em que trabalha a cultura permite bermuda e cerveja. Somente por ela
> permitir é que você pode ir de bermuda, não porque você usa bermuda no dia a
> dia e acha que pode, ou quer ser você mesmo. A empresa quer que se lixe para
> você ser você mesmo. Quer a prova? Pega um notebook da empresa e fala que
> agora ele é seu, porque você é assim, você pega coisas. Rua. Passe a mão na
> bunda da secretária e diga que na sua cidade é assim. Rua. São exemplos
> extremos, mas servem somente para comprovar uma coisa: há limites, impostos
> pela cultura. E você vai ter que se adequar se quiser trabalhar lá.

Não vi onde eu discordei disso -ou onde isso foi falado. Eu em momento
algum falei em abolir regras básicas de conduta, o ponto é que regras
não fazem sentido só por existirem, elas precisam de um sentido para
existir em primeiro lugar.

Ser penalizado por apropriação indébita, como no seu exemplo do
notebook, é algo muito diferente de ser penalizado porque não chegou
às 9 horas da manhã.

> Com isso claro, voltamos a questão. Quantas empresas ainda vivem no tempo do
> cartão de ponto? Quantas ainda vivem no tempo em que bermuda é vista como
> algo até ofensivo? É óbvio, não precisamos trabalhar nelas, mas muitos
> trabalham, incluindo com certeza alguns dos colegas daqui do grupo. A
> questão é: como trabalhar isso? Dizer que vai sair resolve o problema, mas
> só para quem saiu!

Não é só para quem saiu, muito pelo contrário. Creio que muitos aqui
tiveram a experiência de ter alguém muito importante deixando a equipe
e tendo que o substituir. Dada a carência do mercado em mão de obra
qualificada é ingênuo achar que este tipo de coisa não afeta a
empresa.

Um exemplo clássico é o Google. Eu conheço muitas pessoas aqui em
Sydney que deixaram seus empregos e faculdades, empresas e centros de
pesquisa para trabalhar lá. Por que, o salário é melhor? Na verdade o
Google austrália (e o Google Brasil também) possui um salário médio
mais baixo que o do mercado. E mais, meus amigos que trabalham lá
sempre trabalham mais de oito horas por dia -sem hora extra. Por que
eles não ligam? Por que eles chegam no horário que querem.

Como aluém citou antes na thread isto é exatamente o que o Ricardo
Semler fala no seu livro.

[Giovanni Bassi]

Eu tenho um jeito específico para lidar com meus clientes, com meu
chefe e com parceiros profissionais que é bem diferente do jeito que
trato pessoas num bar. Isto não quer dizer que eu esteja encenando
nada.

Chame como quiser. ;)

Dada a carência do mercado em mão de obra
qualificada é ingênuo achar que este tipo de coisa não afeta a
empresa.

Philip, entendo, apóio e pratico. Só que não espere isso da maioria das pessoas. Vamos pedir a todos que deixem seus empregos? Você acha factível que todos que batem cartão sairão dos seus empregos porque estamos dizendo que bater cartão não é legal? Se só deixarmos essa opção, para muitos não deixamos opção nenhuma.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/6/20 Phillip Calçado <pcal...@gmail.com>

[Phillip Calçado]

Oi,

2009/6/20 Giovanni Bassi <gig...@giggio.net>:

> Philip, entendo, apóio e pratico. Só que não espere isso da maioria das
> pessoas. Vamos pedir a todos que deixem seus empregos? Você acha factível
> que todos que batem cartão sairão dos seus empregos porque estamos dizendo
> que bater cartão não é legal? Se só deixarmos essa opção, para muitos não
> deixamos opção nenhuma.

Me desculpe, Giovanni, mas você pode me dizer onde falei isso?

Pelo contrário, meu primeiro email foi:

2009/6/18 Phillip Calçado <pcal...@gmail.com>:

> 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.

E quando falei que peço demissão eu fui bem explícito em dizer que
seria de uma empresa que me force a encenar algo, não sobre folha de
ponto. E mesmo neste caso não sugeri que pessoas o fizessem, apenas
discordei e falei da minha reação.

Não é a primeira vez que você "responde" algo que não falei. Creio que
precisamos melhorar nossa comunicação.

[]s

[Giovanni Bassi]

Não é a primeira vez que você "responde" algo que não falei. Creio que
precisamos melhorar nossa comunicação.

Por "nossa" você quer dizer o que "eu" entendo do que você fala. É isso? E porque a aspas no "responde"? Não foi uma resposta?
Philip, veja bem, não é o que você fala, mas as implicações do que você fala (qualquer um na verdade). Além do mais, a questão de pedir demissão por encenação não é diferente de pedir demissão por obrigar a bater o cartão quando você não concorda. Continuamos deixando muitos sem opção alguma.

Enfim, peguei seu raciocínio e o levei adiante, só isso. Em nenhum momento falei que você disse nada (como você fez comigo agora quando diz que eu respondi algo que você não falou). Não é assim que as conversas evoluem? De qualquer forma, percebo que o foco já foi perdido, você está preferindo dizer que eu coloquei palavras na sua boca, quando eu não fiz isso em nenhum momento. Encerro por aqui.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/6/20 Phillip Calçado <pcal...@gmail.com>

[Raphael Molesim]

Giovanni,

Bater o cartão é rapido sim, mas não é isso o que vejo diáriamente.

Eu vejo pessoas em situações que impedem a batida de cartão, como
reunião em cliente, implantação de sistemas, treinamentos, e outros
diversos motivos. E então estas pessoas levam horas preenchendo uma
folha com as horas que fez cada dia que não passou o cartão. E depois
mais algumas horas para preencher um sistema de apontamento de horas
por projeto.

Ainda assim vejo como impedimento sim, e que seria muito melhor que
alguém que não seja o programador (talvez o SCRUM Master) ao final de
cada interação registrasse as horas trabalhadas que estão no Kanban em
um sistema eletrônico e que isso seja totalmente transparente para o
programador. E que o SCRUM Master registrasse as batidas de ponto
quando o funcionário não pode o faze-lo.

De qualquer jeito, não sou contra o funcionário passar um cartão na
máquina de ponto, sou contra ele perder HORAS preencehendo um planilha
de ponto de exceção e apontando horas em ferramentas eletrônicas. E
sou mais contra ainda na importancia dadas a estas horas, e a forma
como é feito o pagamenta das pessoas.

Ou você acha que todas vez que o funcionário vai preencher alguma
informação de hora a reação dele é "Oba, vou gastar 1 hora agora
atualizando minhas informações de horas, que legal!", dado que estamos
falando de trabalhadores do conhecimento, motivação e sustentabilidade
deve ser a base da sua cultura.

> 2009/6/18 Raphael Molesim <rapha...@infoserver.com.br>

[José Filipe]

A discussão está realmente muito grande (o que já de se esperar, já
que esse assunto sempre gera discussões acaloradas), mas vou tentar
contribuir com a experiência do dia-a-dia..

Somos uma empresa com uma área de desenvolvimento de umas 20 pessoas
que nos próximos meses devem chegar em 70 (hoje estão entrando 15
pessoas). A questão do horário sempre foi problema pois, enquanto
alguns funcionários exerciam um horário "alternativo" outros
trabalhavam suas 8,8h (acho que somos uma das poucas de TI que não
fazem só 8h) e ficavam chateados com os demais.

Enfim, até aí tudo bem, poderíamos simplesmente alinhar que o
resultado seria por entrega e não por horário, e vamos lá. O problema
seria que depois dessa atitude tomada, como eu resolveria os seguintes
pontos?

1. Alguém citou muito bem que quem tem contato com cliente precisa
estar disponível (não vou lembrar o nome agora). Trabalhamos com
contact centers, que por sua vez trabalham das 8h as 22h). Como
garantir que alguém sempre esteja aqui? Sei que uma área de suporte
nível 2 mata o problema, mas é difícil garantir que um profissional
específico não precise ser acessado numa urgência (mais uma vez: é
possível, mas não tão simples);
2. Dá pra exigir a mesma maturidade de um profissional com anos de
casa e de um outro que acabou de ser efetivado como estagiário? Tem
todo o papo que é alinhar e tudo mais, mas a questão é que não existem
tantos profissionais assim no mercado pra que, dada a margem, sempre
que alguém atrasar-se depois de ser advertido a solução seja a
demissão. Turnover custa caro, todos sabem disso;
3. A empresa possui outras áreas, outros cargos, outras filiais. Dando
essa liberdade só pra equipe de Desenvolvimento, a meu ver, abre
margem pra continuidade do "isolamento" dos profissionais de TI. Aí,
quando a área operacional tiver benefícios inéditos, todos ficam putos
do nosso lado. Mas não meio que a mesma coisa?

Enfim, acho que horários flexíveis funcionam bem em empresas cujo
quadro de funcionários seja composto majoritariamente de
desenvolvedores e numa dimensão controlada. Em casos maiores, a não
ser que a culturá ágil e de desenvolvimento esteja extremamente
arraigada na cultura corporativa (uma empresa que surgiu como dev e
expandiu atuação, ou algo do tipo), é bem mais complicado. Pelo menos
para nós não é (mas nós não cumprimos nenhuma das duas premissas da
frase anterior).

Abraços.

José Filipe
http://addwatch.wordpress.com/

[Rodrigo Vieira]

Olá José Filipe,

> 2. Dá pra exigir a mesma maturidade de um profissional com anos de
> casa e de um outro que acabou de ser efetivado como estagiário? Tem
> todo o papo que é alinhar e tudo mais, mas a questão é que não existem
> tantos profissionais assim no mercado pra que, dada a margem, sempre
> que alguém atrasar-se depois de ser advertido a solução seja a
> demissão. Turnover custa caro, todos sabem disso;

Eu acho que dá pra exigir a mesma maturidade sim.

> 3. A empresa possui outras áreas, outros cargos, outras filiais. Dando
> essa liberdade só pra equipe de Desenvolvimento, a meu ver, abre
> margem pra continuidade do "isolamento" dos profissionais de TI. Aí,
> quando a área operacional tiver benefícios inéditos, todos ficam putos
> do nosso lado. Mas não meio que a mesma coisa?
>

O pessoal administrativo/operacional tem que entrar as 8:00, mas tb
qdo dá 17:00 eles desligam o computador, guardam a vassoura etc e vão
pra casa. Já os desenvolvedores chegam mais tarde se quiserem, mas tb
muitas vezes ficam até bem mais tarde, quando estão envolvidos em um
problema e não querem interromper o raciocínio, ou no meio de uma
crise (um servidor que parou de funcionar, um bug crítico, etc). Quem
tem o dever de chegar as 8:00 em ponto tb tem o direito de xispar às
17:00 em ponto. Então pode ser uma questão de deixar claro que essa
flexibilidade do depto de desenvolvimento não é necessariamente um
luxo, e sim uma característica do tipo de trabalho envolvido. Nunca vi
secretária e faxineira tendo que aparecer pra trabalhar num domingo de
sol pq o servidor de bd morreu...

> Enfim, acho que horários flexíveis funcionam bem em empresas cujo
> quadro de funcionários seja composto majoritariamente de
> desenvolvedores e numa dimensão controlada. Em casos maiores, a não
> ser que a culturá ágil e de desenvolvimento esteja extremamente
> arraigada na cultura corporativa (uma empresa que surgiu como dev e
> expandiu atuação, ou algo do tipo), é bem mais complicado. Pelo menos
> para nós não é (mas nós não cumprimos nenhuma das duas premissas da
> frase anterior).
>

Concordo que em grandes empresas e em empresas cujo core business não
seja desenvolvimento é mais difícil. Mas tb acho que muito dos
obstáculos colocados aqui nessa discussão (não necessariamente nessa
sua mensagem, mas na discussão inteira) é baseada nessa desconfiança
que o brasileiro tem dos outros, de achar que, dada qq liberdade, todo
mundo abusa e vira zona. Parece que no Brasil todo mundo é malandro e
preguiçoso até que prove o contrário..triste isso!

- Rodrigo

[Emmanuel G. Brandão]

José,

Quanto a questão de estar disponível eu gosto muito do exemplo comentado no livro do Ricardo Semler, que eu acho que mencionei inclusive aqui nesta thread.
Eles queriam implantar o horário flexível em uma indústria! Muita mais difícil que em um escritório, concordam? Pois lá se alguém no meio do processo estiver faltando, você não consegue dar continuidade e mais, pode causar o dano incrível.
O sindicato se meteu, dizendo que se o horário fosse flexível não teriam controle sobre os 5, 7 ou 15 minutos garantidos de atraso que não podem ser descontados dos funcionários. A comissão formada para discutir como seria esse processo não entrava em acordo e etc...
Então a solução foi que avisaram que: no dia seguinte começa o horário flexível, se você for chegar mais tarde, avise o colega com quem você trabalha para que ele possa te cobrir em alguma eventualidade. (!!)

Simples não? Acho que nós da TI seríamos capaz disso também, certo? Já que corremos atrás de equipes auto-gerenciáveis, já que temos formação melhor, etc...
Acho que tem que se confiar na maturidade dos profissionais, por que nenhuma empresa de TI contrata crianças, são todos profissionais, mas a cultura do comando-controle não deixa os gestores, gerentes, diretores verem os profissionais que eles tem... como profissionais!

Ah! Vão ter os sacanas? Sim... Mas a própria equipe vai filtrar...

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/22 José Filipe <jfn...@gmail.com>

[Ubiratan Padilha]

Philip, quando eu disse insenação leia-se: tenho que me comportar
diferente - muitas vezes - de como, por exemplo, me comportaria num
churrasco na minha casa. Ou não. É a questão do Papel Social citada
pelo Giovanni.

Rodrigo Vieira, claro que nosso trabalho é diferente da secretária e
da faxineira que você falou, mas não é porque somos os "gênios", os
"donos do mundo", que vamos agora ignorar totalmente a cultura da
empresa. Nos (egenheiros de software) trabalhamos mais - muitas vezes
- que os faxineiros, mas também ganhamos bem mais.

Vejam, companheiros desta thread, a minha provocação foi no sentido de
pensarmos também nas culturas das empresas e tentarmos ser um pouco
flexível em nossas convicções para assim conseguirmos aos poucos ir
ganhando a confiança das diretorias das empresas que trabalhamos e
inserir (aos poucos) a cultura ágil. Com um discurso mais radical não
vamos chegar a lugar nenhum. Desta forma, teremos pouquíssimas
empresas que trabalharão, pelo menos no curto/médio prazo, com
conceitos ágeis. E não é isto que queremos, certo? Queremos alastrar a
cultura ágil no mundo dos negócios.

[]'s

Ubiratan

> >http://addwatch.wordpress.com/- Ocultar texto das mensagens anteriores -

[Emmanuel G. Brandão]

Não acho que sejamos os gênios, os donos do mundo... Até por que se fossemos gênios os softwares não dariam pau...
Mas acho que cada tipo de trabalho deve ser tratado de forma diferente, um faxineiro tem horário para cumprir, tem que estar em determinado local, um motorista também, recepcionista, e por aí vai. Infelizmente não são todos que terão o benefício de horário flexível, trabalhar no café da esquina, ...
Agora, se você é consultor, e vai trabalhar 3 meses para uma semana que exige que você chegue as 07:30 da manhã, ou você cumpre, ou não, e procura outra coisa.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/22 Ubiratan Padilha <ubiratan...@gmail.com>

[Juliano Oliveira]

Fugindo do assunto da thread, o conceito de "gênio" não tem nada a ver com software dando pau ou não....

Twitter vive dando pau, mesmo assim, foi idéia de um gênio. Orkut vivia caindo e dando pau, porém, foi o primeiro gênio a criar "comunidades" (não o primeiro, mas o que primeiro fez um sucesso absurdo)... Eric Evans foi um gênio e eles não criou nada... apenas compilou...

Acho que somos gênios sim... desde os novatos até os mais experiêntes... todos são...

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/22 Emmanuel G. Brandão <egomes...@gmail.com>

[Emmanuel G. Brandão]

Uma coisa é criar um conceito, outra é implementá-lo... Mas isso foge do escopo desta thread! Hehehe... :P

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/22 Juliano Oliveira <jul.ol...@gmail.com>

[Ubiratan Padilha]

Usei a expressão "gênio" somente como figura de linguagem. O que quis
dizer é que muitas vezes nos sentimos melhores que os demais
profissionais (pq trabalhamos com algo que muita gente não tem a
mínima idéia do que é e como se faz). Até hoje parte da minha família
não conseguiu entender o que eu faço. :)

O que defendo é bom senso, equilíbrio e flexibilidade. Se não formos
razoáveis não conseguiremos difundir a cultura ágil nas empresas.
Temos que ir aos poucos, pois a quebra de cultura é muito grande, mas
acho totalmente factível de ser implantanda.

Só pra descontrair - e, concordando como o Juliano -, somos gênios
sim, pois trabalhar com desenvolvimento de aplicação está cada vez
mais difícil. =)

[]´s

Bira

On 22 jun, 13:05, Emmanuel G. Brandão <egomesbran...@gmail.com> wrote:
> Uma coisa é criar um conceito, outra é implementá-lo... Mas isso foge do
> escopo desta thread! Hehehe... :P
>
> Brandão, Emmanuel G.
> CSM
> blog.egomesbrandao.net
>

> 2009/6/22 Juliano Oliveira <jul.olive...@gmail.com>

>
>
>
> > Fugindo do assunto da thread, o conceito de "gênio" não tem nada a ver com
> > software dando pau ou não....
> > Twitter vive dando pau, mesmo assim, foi idéia de um gênio. Orkut vivia
> > caindo e dando pau, porém, foi o primeiro gênio a criar "comunidades" (não o
> > primeiro, mas o que primeiro fez um sucesso absurdo)... Eric Evans foi um
> > gênio e eles não criou nada... apenas compilou...
>
> > Acho que somos gênios sim... desde os novatos até os mais experiêntes...
> > todos são...
>
> > []´s
>
> > Juliano Oliveira
> > Analista Desenvolvedor
> > .Net, C#, Actionscript, Flex, NHibernate
> >http://programandoem.net
> > twitter: @juloliveira - skype: juloliveira
>

> > 2009/6/22 Emmanuel G. Brandão <egomesbran...@gmail.com>

>
> > Não acho que sejamos os gênios, os donos do mundo... Até por que se
> >> fossemos gênios os softwares não dariam pau...
> >> Mas acho que cada tipo de trabalho deve ser tratado de forma diferente, um
> >> faxineiro tem horário para cumprir, tem que estar em determinado local, um
> >> motorista também, recepcionista, e por aí vai. Infelizmente não são todos
> >> que terão o benefício de horário flexível, trabalhar no café da esquina, ...
> >> Agora, se você é consultor, e vai trabalhar 3 meses para uma semana que
> >> exige que você chegue as 07:30 da manhã, ou você cumpre, ou não, e procura
> >> outra coisa.
>
> >> Brandão, Emmanuel G.
> >> CSM
> >> blog.egomesbrandao.net
>

> >> 2009/6/22 Ubiratan Padilha <ubiratan.padi...@gmail.com>

> >>> > >http://addwatch.wordpress.com/-Ocultar texto das mensagens
> >>> anteriores -
>
> >>> > - Mostrar texto das mensagens anteriores -- Ocultar texto das mensagens anteriores -

[Rodrigo Vieira]

> Rodrigo Vieira, claro que nosso trabalho é diferente da secretária e
> da faxineira que você falou, mas não é porque somos os "gênios", os
> "donos do mundo", que vamos agora ignorar totalmente a cultura da
> empresa. Nos (egenheiros de software) trabalhamos mais - muitas vezes
> - que os faxineiros, mas também ganhamos bem mais.

Ubiratan, acho que vc est á interpretando a coisa como essa
flexibilidade de horario fosse uma coisa extrema, e beirando o
elitismo. Não é. Mesmo com horário flexível, sem cartão de ponto etc,
90% do time ou mais está no escrit ório todo dia antes das 9:15.
Simples questão de bom-senso e praticidade, além do fato que ninguém
gosta de ir pra casa as 8 da noite.

A diferença é que se alguém algum dia quer ou precisa chegar as 10,
10:30, ninguém tá nem aí, desde que a pessoa não perca um compromisso,
reunião etc, claro.

SObre ser gênio, dono do mundo, etc, talvez essa seja a postura e a
imagem aí na sua empresa, mas graças a deus tal elitismo e imaturidade
não rola no meu time, todo mundo é tratado com o devido respeito.

Tb não concordo que exista uma relação entre ganhar mais e trabalhar
mais, salário deve ser atrelado a habilidades, a quão raro um
profissional é (pra pegar emprestado a idéia que o Giovanni postou no
blog dele), e não pq fulano trabalha mais ou menos.

Vc pede discurso menos radical mas acho que na verdade vc q está
interpretando de forma radical um discurso moderado.

[Rodrigo Vieira]

>
> O que defendo é bom senso, equilíbrio e flexibilidade. Se não formos
> razoáveis não conseguiremos difundir a cultura ágil nas empresas.
> Temos que ir aos poucos, pois a quebra de cultura é muito grande, mas
> acho totalmente factível de ser implantanda.

Nao vi alguém aqui defendendo o contrario! :)

[Rodrigo Vieira]

Saindo numa tangente aqui, uma coisa que notei nesses anos de
profissão é que os caras verdadeiramente gênios que conheci eram os
mais humildes, os mais acessíveis. Qdo o cara sabe muito mesmo do
assunto, ele não precisa tirar onda e não se importa em dividir o que
sabe, pq por mais que a gente aprenda o que ele diz, ele sempre tá 2
ou 3 passos à frente mesmo.. :)

Aí depois disso existem os "semi-gênios" que são os que se acham gênios hehehe

[Juliano Oliveira]

Antes de qualquer opinião minha ao seu comentário, não entendi o que você quis dizer com frases como:

"gênios que conheci eram os mais humildes"

"'semi-gênios' que são os que se acham gênios"

?

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/22 Rodrigo Vieira <rodr...@gmail.com>

[Emmanuel G. Brandão]

Potz pessoal... Discutir Scrum e cartão de ponto já é off-topic, se formos entrar na questão da genialidade...

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/22 Juliano Oliveira <jul.ol...@gmail.com>

[Juliano Oliveira]

Sim, concordo, por isso mesmo não dei continuidade após o meu comentário. Só queria entender o que o Rodrigo quis dizer para eu não interpretar da forma errada.

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/22 Emmanuel G. Brandão <egomes...@gmail.com>

[Rodrigo Vieira]

Bem, to meio receoso de ter levado essa thread muito fora do assunto
original, mas como vc pediu vou explicar melhor:

O que quis dizer é que os caras realmente geniais que eu conheci,
nunca tiveram pose de gênio.
Pra citar um exemplo conhecido: Scott Guthrie. O cara tem um cérebro
de E.T., 30 e poucos anos, vice-presidente da Microsoft, e mesmo assim
quem lê o blog do cara, quem vê ele dando uma entrevista, apresentando
uma conferência, nunca vê uma atitude arrogante dele, ou tirando onda.
Pq ele não precisa disso. Idem para caras como Ted Neward e Anders
Halsjberg, os "top 1%".

Num segundo escalão existem pessoas que são extremamente inteligentes,
mas que infelizmente traduzem isso numa atitude arrogante, foi os que
chamei de "semi-gênios".

Enfim, acho que isso tá off-off-demais, desculpa.

2009/6/22 Juliano Oliveira <jul.ol...@gmail.com>:

[Ubiratan Padilha]

Olá, Rodrigo.

> Tb não concordo que exista uma relação entre ganhar mais e trabalhar
> mais, salário deve ser atrelado a habilidades, a quão raro um
> profissional é (pra pegar emprestado a idéia que o Giovanni postou no
> blog dele), e não pq fulano trabalha mais ou menos.

É claro que não penso que a relação do quanto se ganha está atrelada a
quantidade de horas que alguém fica no escritório. Eu disse que
trabalhamos mais porque muitas vezes temos que estar em pleno domingo
no escritório (alguém comentou isto nesta thread) e porque temos que
estudar muito (o que em algum prisma pode ser intepretado tb como
trabalho). Não estou dizendo que estudar é trabalhar, ok? Mas é fato
que ser engenheiro de software hoje demanda bastante esforço.

> Ubiratan, acho que vc est á interpretando a coisa como essa
> flexibilidade de horario fosse uma coisa extrema, e beirando o
> elitismo. Não é. Mesmo com horário flexível, sem cartão de ponto etc,
> 90% do time ou mais está no escrit ório todo dia antes das 9:15.
> Simples questão de bom-senso e praticidade, além do fato que ninguém
> gosta de ir pra casa as 8 da noite.

Você está falando pela sua empresa e pelo time que trabalha ou por
todo o mercado? Pergunto isto porque vejo muitos profissionais que não
atuam ou não entenderam a real essência da cultura ágil têm a falsa
sensação de que ser ágil é não ter gerente de projeto etc e,
consequentemente, conquistar uma liberdade que muitas vezes não está
atrelada a compromisso etc, coisa que vai contra a cultura ágil, onde
o time é altamente comprometido com a entrega... É claro que um time
Ágil não precisa ter controle de horário, pois eles tem um compromisso
real com a entrega. Mas, é aquela questão da cultura. Acho que deve
haver flexibilidade no começo até a cultura ágil ser realmente
solidificada na empresa. Ou seja, não preciso chegar as 9h00 no
escritório mas tb não dar a entender que posso chegar a qualquer hora
pois meu compromisso é com a entrega. Existe uma cultura na empresa e
devemos tentar nos adequar e fazer simultaneamente a empresa assimilar
a nova cultura.

Veja, não acho que o profissional tem que cumprir rigidamente
horários. Eu escrevi nesta thread que acho que o time deve ser medido
por resultado. Só defendo que neste momento, como tudo isto é muito
novo, devemos ter flexibilidade nas empresas que atuamos. Não dá para
dizer que, por exemplo, com cartão de ponto não podemos ser ágil etc
etc. É claro que a cultura de controle de horário (somente pelo
controle das horas) vai contra a cultura ágil. Mas, não podemos fechar
questões. Temos que flexibilizar o discurso, adaptar, buscar soluções,
ser criativos.

> SObre ser gênio, dono do mundo, etc, talvez essa seja a postura e a
> imagem aí na sua empresa, mas graças a deus tal elitismo e imaturidade
> não rola no meu time, todo mundo é tratado com o devido respeito.

Acho que você não entendeu a minha provocação reflexiva. Quis dizer
sobre "gênio..." para olharmos para nós mesmos. Foi uma provocação
sadia e acho que você levou pro lado pessoal. Muitas vezes para
mudarmos o mundo temos que olhar para nós mesmos. Se nós temos
problemas de auto-estima quando alguém diz: vc se acha um gênio..., é
porque talvez achamos que somos mesmo e não admitimos alguém nos
trazer para o campo da reflexão, para olharmos para o nosso próprio
umbigo. É muito fácil criticar o sistema, as empresas e dizer que é
tão óbvio enxergar que os métodos ágeis são melhores (e eu realmente
acredito que são) e que é inacreditável as pessoas não "comprarem"
nossa proposta de trabalho. Entretanto, só isto não basta. Se não nos
colocarmos no lugar das empresas (da forma que eles nos enxergam
atualmente) será muito difícil entrar no raio de ação. É isto que
estou querendo dizer deste que iniciei nesta thread e talvez esteja
sendo mal interpretado. Estou querendo provocar a nossa comunidade
para a reflexão. Para olharmos para o nosso discurso. Para adaptarmos
as linguagens. Tudo isto para nos aproximar da cúpula das empresas e
difundir nossas idéias.

Temos também que considerar que não é porque na empresa que atuamos os
métodos ágeis funcionam bem e houve uma facilidade de assimilação de
cultura que isto representa a maioria dos cenários das empresas.

Já não estou falando mais diretamente sobre o que você escreveu, ok,
Rodrigo? Estou tratando este comentário como algo mais macro. =)

[]´s

Ubiratan

> > Juliano Oliveira- Ocultar texto das mensagens anteriores -

[Rodrigo Vieira]

>
> Você está falando pela sua empresa e pelo time que trabalha ou por
> todo o mercado?

Como usei o termo "meu time" eu naturalmente estava me referindo a
minha empresa, mas imagino que sua pergunta seja retórica.

>Pergunto isto porque vejo muitos profissionais que não
> atuam ou não entenderam a real essência da cultura ágil têm a falsa
> sensação de que ser ágil é não ter gerente de projeto etc e,
> consequentemente, conquistar uma liberdade que muitas vezes não está
> atrelada a compromisso etc, coisa que vai contra a cultura ágil, onde
> o time é altamente comprometido com a entrega... É claro que um time
> Ágil não precisa ter controle de horário, pois eles tem um compromisso
> real com a entrega. Mas, é aquela questão da cultura. Acho que deve
> haver flexibilidade no começo até a cultura ágil ser realmente
> solidificada na empresa. Ou seja, não preciso chegar as 9h00 no
> escritório mas tb não dar a entender que posso chegar a qualquer hora
> pois meu compromisso é com a entrega. Existe uma cultura na empresa e
> devemos tentar nos adequar e fazer simultaneamente a empresa assimilar
> a nova cultura.
>

Como o nome diz, agilidade é uma cultura, e cultura leva tempo pra se
criar, e não pode ser "instalada" como se instala um novo software.

Dentro desses limites, com certeza não vai ser flexibilidade de
horário o 1o ponto a se mudar na cultura de uma empresa; em um depto
de desenvolvimento não-ágil existem mil coisas que podem e devem ser
ajustados antes que se comece a falar em jogar o cartão de ponto fora.
Flexibilidade de horário acaba tornando-se uma consequência natural de
uma cultura já existente, não dá pra adotar por decreto. Por outro
lado, havendo essa cultura, o resto da empresa vendo na prática que o
time funciona baseado em resultados e não em horas, a aceitação por
flexibilidade é bem mais natural, o time já provou que funciona.

No mais (as partes da sua mensagem que removi), concordo contigo em
termos gerais, acho que talvez a gente venha de direções diferentes
mas nos encontramos no meio-termo, ou seja, concordamos que acima de
tudo há de existir bom-senso e parcimônia na hora de mexer com os
valores e a cultura de uma empresa.

- Rodrigo

[Ubiratan Padilha]

> Como usei o termo "meu time" eu naturalmente estava me referindo a
> minha empresa, mas imagino que sua pergunta seja retórica.

Retórica ou não, eu quis mostrar pra você que da forma que escreveu
(<"SObre ser gênio, dono do mundo, etc, talvez essa seja a postura e a

imagem aí na sua empresa, mas graças a deus tal elitismo e imaturidade

não rola no meu time, todo mundo é tratado com o devido respeito...")
deu a entender que a dificuldade era na empresa que trabalho - o que
não procede. Quis questionar que a dificuldade é vivenciada por muitos
colegas.

> Como o nome diz, agilidade é uma cultura, e cultura leva tempo pra se
> criar, e não pode ser "instalada" como se instala um novo software.

Rodrigo, não quero acreditar que você realmente achou que eu penso (pq
usei no sentido figurado a palavra "instalada") que podemos "instalar"
a cultura ágil como se instala um software.

Da mesma forma que você, acho que viemos de caminhos diferentes. Mas
são visões diferentes convergindo para um mesmo caminho que
transformam o mundo para melhor, certo? =)

Só quero aqui sugerir para todos desta comunidade para não nos
"prendermos" tão fortemente as semânticas das palavras e sim na idéia
geral do comentário. Isto vai contribuir para não perdermos do foco o
assunto principal.

Do mais também concordo em linhas gerais com você.

[]´s

Ubiratan

[Rodrigo Vieira]

>
>> Como o nome diz, agilidade é uma cultura, e cultura leva tempo pra se
>> criar, e não pode ser "instalada" como se instala um novo software.
>
> Rodrigo, não quero acreditar que você realmente achou que eu penso (pq
> usei no sentido figurado a palavra "instalada") que podemos "instalar"
> a cultura ágil como se instala um software.
>

Não, não achei isso, desculpa se dei a entender o contrário. Tava
fazendo uma analogia, pra ajudar a esclarecer o que escrevi depois,
sobre não querermos começar a adotar uma cultura ágil usando
flexibilidade de horário como "bandeira", etc.

[Ricardo Rocha]

Trabalhei numa empresa aqui em Porto Alegre, a qual chamarei de XXX, que surgiu dentro do CPD de uma empresa de calçados. A empresa de calçados resolveu criar uma empresa de informática que prestaria serviços a eles.

Com o passar dos anos a empresa XXX deixou de prestar este serviço e especializou-se em software, mantendo um Data Center para concentrar os dados de um Grupo de Empresas o qual faz parte. Ainda enquanto eu trabalhava lá houve um alteração e o Data Center foi vendido, ficando a empresa XXX focada apenas em Software.

Nós devíamos seguir o horário .. que era das 08:00 as 12:00 e das 13:00 as 18:00. Nas sextas-feiras largávamos as 17:00. Tínhamos 10 minutos de "tolerância" a mais ou a menos, para bater o ponto (através de crachá).

A empresa XXX tinha várias equipes que trabalhavam em diversos projetos com clientes diferentes (ou não). Usávamos Power Builder e atendíamos uma empresa americana. Com o passar do tempo o Coordenador da nossa equipe propos-nos utilziar SCRUM. A equipe era pequena, 8 pessoas. Aceitamos e começamos o processo. A empresa também estava em processo de desenvolvimento dos documentos para implantação de CMMI. Fomos evoluindo o processo, modificando a documentação para deixá-la mais objetiva e completa. Em 1 ano de uso, raramente nos equivocávamos em prazos. As iterações eram de 3 semanas e funcionava muito bem. Tínhamos 1 reunião semanal e o acompanhamento do andamento se dava pelo mural com post-its. Se as coisas não estavam andando (olhando para o mural) fazia-se reuniões extras.

A experiência da equipe foi extremamente positiva do ponto de vista técnico e de aprendizado. grande produtividade e qualidade. Reduzimos os erros de cada iteração a zero. Raramente acontecia do cliente reportar algum erro.

Mas, mesmo com esta evolução dentro da equipe, a empresa não oferecia condições para a liberdade que tanto foi discutido aqui. Nós tínhamos uma equipe forte e quando precisávamos de alguma coisa sempre éramos liberados pelo coordenador sem nenhum tipo de problema. Era só comunicar e estava tudo certo, mas ainda era necessário depois solicitar o acerto do ponto ao RH porque passados 10 minutos do horário não podíamos batar o ponto.

Sempre reclamamos disso a empresa. Tínhamos uma alta produtividade e éramos a única equipe que não precisava fazer horas extras. Era de longe a equipe mais organizada da empresa. Mas mesmo assim a mentalidade organizacional era de empresa com linha de produção (como na sua origem). Essa empresa, apesar de ter um escritório aqui em Porto Alegre (no qual eu trabalhava), tinha sua matriz em Campo Bom .... ela surgiu de um CPD e a mudança de mentalidade não acompanhou o crescimento e amadurecimento nem das equipes e nem do foco.

Sabemos que existe toda questão do cartão ponto por questões de exigências legais. A CLT exige isso (para proteger empregado e empregador) ... mas da mesma forma que há empresas que não pagam horas extras há formas de dar liberdade nos horários. Basta querer.

Como foi dito, o RH poderia arrumar os horários na mão, como fazia quando havia acordo com o Coordenador.

A maior parte dos problemas são por limitações dos administradores. Há várias maneiras de fazer esta transição de "tratamento". Poderia até ser algo a ser "conquistado" após algum tempo de empresa.

Na empresa que trabalho hoje, há um horário núcleo e é válido tanto para os funcionários CLT quanto para os PJ ... entre 07:00 e 19:00 deve-se ter 8 horas trabalhadas. Sendo que OBRIGATORIAMENTE entre 09:00/11:30 e 14:00/17:00 TODOS devem estar na empresa. Então, se eu quiser chegar as 09:00 e sair as 19:00, poderei ... mas o horário núcleo funciona justamente para caso alguém precise resolver problemas ou fazer reuniões ... coisas que não foram agendadas, problemas inesperados, etc. Assim, conseguiram dar certa liberdade e ainda assim manter o controle.

Quando uma empresa deseja fazer algo, ela fará, sendo legal ou não. Coisas assim podem ser acordadas com o sindicato e não trazem problemas a empresa .. livrando-a de processos futuros por o empregado ficar até mais tarde na empresa.

Nosso sonho de liberadade de horário está longe de ser atingido devido a mentalidade das empresas e também a irresponsabilidade de muitos diante da liberdade oferecida. Assim, todos pagam pela irresponsabilidade dos outros. É necessário uma mudança cultural nas empresas e também nos funcionários. Ambos tem culpa sobre nossa realidade de horário profissional.

2009/6/22 Ubiratan Padilha <ubiratan...@gmail.com>

[Rodrigo Vieira]

>
> Na empresa que trabalho hoje, há um horário núcleo e é válido tanto para os
> funcionários CLT quanto para os PJ ... entre 07:00 e 19:00 deve-se ter 8
> horas trabalhadas. Sendo que OBRIGATORIAMENTE entre 09:00/11:30 e
> 14:00/17:00 TODOS devem estar na empresa. Então, se eu quiser chegar as
> 09:00 e sair as 19:00, poderei ... mas o horário núcleo funciona justamente
> para caso alguém precise resolver problemas ou fazer reuniões ... coisas que
> não foram agendadas, problemas inesperados, etc. Assim, conseguiram dar
> certa liberdade e ainda assim manter o controle.

Nas empresas que conheço que têm horário flexível tb é assim: existe
um período em que espera-se que todos estejam presentes, pra marcar
reuniões (planejadas ou emergenciais) etc. No caso do meu trampo
atual, esse horário é de 10 as 15. Acho que nenhuma empresa com
horario flexivel deixaria um camarada entrar no serviço as 5 da tarde
pq o cara ia ser basicamente um fantasma.

E isso vale não só pro time de desenvolvimento, mas tb pra outras
funções em que rigidez de horário não seja obrigatório, por exemplo o
pessoal de RH, do administrativo. Só quem tem hora marcada pra entrar
é suporte, secretaria e limpeza, mas, como disse, eles tb (com todo
direito) saem pontualmente as 17:00, então tudo bem. Imagino que eles
que se consideram sortudos, pq o chefe nunca vai chegar pra eles e
falar "se prepara que hoje tu vais ter que jantar pizza na sala de
reunião" heeheh

[Mauricio Aniche]

Oi,

Eu acredito que desenvolver software é uma atividade que requer criatividade. É uma arte, assim como pintar um quadro ou escrever uma música. Não me lembro quem disse certa vez que "programar é como escrever uma poesia: você tem um conjunto de regras a seguir, mas fora isso, está totalmente livre". Acho que a citação acima é do Richard Gabriel, e com certeza não foram essas palavras que ele usou, mas a idéia é por aí. E ela me agrada muito.

E artistas, para serem criativos, precisam trabalhar em um ambiente totalmente favorável; em um ambiente que proporcione a ela a possibilidade de inovar, de inventar, enfim, de ser criativo. Sem isso, dificilmente ele irá produzir uma "obra de arte".

Mas claro que sem extremismos. Tanto o "artista" quanto a empresa devem ceder em prol da "obra de arte". A empresa deve tentar ao máximo fornecer um ambiente saudável para ele e ele deve... hmm... digamos, não tentar abusar disso! :)

Acho que você deve avaliar o cartão de ponto na sua empresa. As pessoas se sentem confortáveis com ele? Isso está REALMENTE impedindo as pessoas de serem criativas? Em caso afirmativo, acho que você deve trabalhar neste ponto e bolar alguma solução.

Abraços,
Mauricio Aniche
Mestrando em Ciência da Computação
Universidade de São Paulo
www.aniche.com.br

2009/6/22 Rodrigo Vieira <rodr...@gmail.com>

[Emmanuel G. Brandão]

Até acho legal essa comparação com artes, etc... Mas veja, um arquiteto também seria artista, um escritor de livros, um pesquisador químico, e por aí vai. E todos eles seguem horários, prazos, regras, e por aí vai também. A IBM inovou diversas vezes e era uma empresa extremamente conservadora.
Então, eu acho que a arquitetura caminha, inova, modifica e se transforma e isso tudo trabalhando em um escritório, com horário...
As pessoas pensam que liberdade e espaço para inovação é baderna, e faço quando quiser, e por aí vai...
Então apesar de concordar com isso tudo, até onde podemos dosar a liberdade necessária? Até onde é possível dizes que o ambiente não proporcionou tudo o que a pessoa precisava? Acho que não podemos usar o Google como exemplo, é uma empresa que esta muito mais a frente, e para isso ela tem que ter muito dinheiro para investir nas idéias e perder muito até desistir delas...

 
Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/23 Mauricio Aniche <maurici...@gmail.com>

[Juliano Oliveira]

Questão cultural.. simples e apenas questão cultural...

É a mesma coisa que acontece quando o Fábio Camara fala que scrum master é "gerente", que delega, verifica, estima.. bla bla bla... A questão é que na opinião do Fábio Camara a cultura do brasileiro não se pode ter equipes trabalhando sem que haja um gerente, sem que haja um nível de hierarquia, "chefes". O que até certo ponto é verdade (a questão cultural, não do scrum).

Enfim, acho que a visão moderna é que os "artistas" da tecnologia devem e necessitam de condições mínimas para criarem. Já a visão conservadora é que todos devem ser gerenciados, vigiados, terem seus passos logados, etc etc etc... Ainda existem chefes querendo estimar quantas horas o pelego fica no PC trabalhando... ainda existem chefes que querem saber quantas linhas de código o pelego digita por dia...

Concordo com o Maurício... o problema é a cultura brasileira..

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/23 Emmanuel G. Brandão <egomes...@gmail.com>

[Rodrigo Vieira]

2009/6/23 Emmanuel G. Brandão <egomes...@gmail.com>:

> Até acho legal essa comparação com artes, etc... Mas veja, um arquiteto
> também seria artista, um escritor de livros, um pesquisador químico, e por
> aí vai. E todos eles seguem horários, prazos, regras, e por aí vai também. A
> IBM inovou diversas vezes e era uma empresa extremamente conservadora.

Pois é, e agora a IBM, assim como a HP e diversas outras
mega-empresas, são as que mais adotam horários flexíveis,
oportunidades para os empregados trabalharem de casa etc.

Lembro que eu li em 2001 ou 2002 que 40% dos empregados da IBM (EUA e
Europa) trabalhavam de casa pelo menos 1x por semana. Imagina agora
que é fácil ter banda larga etc, deve estar em bem mais.

[Eduardo Miranda]

Não sou muito a favor desta metáfora não. Quantas atividades no seu dia você avaliaria como "arte"? 20%? 10%?

 

Quantas atividades são aplicar conceitos/práticas já conhecidos? Ou seja, é necessário conhecimento, concentração, mas não muita criatividade?

 

Ou seja, no máximo poderíamos nos considerar artezãos.

 

2009/6/23 Mauricio Aniche <maurici...@gmail.com>

[Emmanuel G. Brandão]

Já diz aquela frase de "1% inspiração e 99% transpiração"... Ter uma idéia é uma coisa, mas implementá-lam não é criatividade, é trabalhar em cima dela, muita coisa, muito código você já usou de alguma maneira.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/23 Eduardo Miranda <dud...@gmail.com>

[Juliano Oliveira]

Emmanuel,

"Ter uma idéia é uma coisa, mas implementá-lam não é criatividade"

Como não? A mesma idéia pode ser implementada de diversas maneiras, é necessário avalias diversas variaveis, ambiente, etc etc etc...

A diferença é que um artista que vai pintar uma mulher avalia pincéis, cores, tons, força...
Um musico avalia acordes, escalas, arranjos, sonoridades...

Um poeta palavras mais rispidas, palavras mais emocionantes, tocantes, etc etc etc

É a mesma coisa... software é criatividade pura... é fruto de intelecto... 

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/23 Emmanuel G. Brandão <egomes...@gmail.com>

Já diz aquela frase de "1% inspiração e 99% transpiração"... Ter uma idéia é uma coisa, mas implementá-lam não é criatividade, é trabalhar em cima dela, muita coisa, muito código você já usou de alguma maneira.

[Emmanuel G. Brandão]

Não concordo... Você sempre vai seguir uma linha de raciocínio lógica e estabelecida, a criatividade não esta no software, isso já foi percebido a muito tempo. Antes quando a TI era uma coisa nova podia até enganar as empresas, trazendo a revolução no controle de estoque, em sistema distribuídos pela Web, mas tudo isso é apenas tecnologia. A criatividade esta em como usar esta tecnologia, e não na tecnologia em si.
Quando se te uma idéia inovadora em TI é criativo, partir para a construção é usar tudo o que se sabe de programação para implementá-la.
Igual ao seu exemplo de artistas, o músico usa as regras pré-estabelecidas: notas, compasso, tempo, ritmo; o pintor usa: pincel, noção de 3D, técnicas de pontilhismo, de arte moderna, de abstrato; o poeta palavras e ainda por cima se for um soneto a regra de composição é muito mais rígida. Ou seja, a criatividade esta em juntar tudo isso... E na TI a criatividade esta em resolver algo de negócio, então o programador quando esta
desenvolvendo apenas esta procurando a maneira certa de atingir o objetivo criativo de negócio.
Sim... tudo é fruto do intelecto, até por que nada se cria sozinho, e um operário, por mais que seja repetitiva sua tarefa, tem que ter intelecto para executá-la.
Por isso que eu acho que tem que existir um equilíbrio, não é de qualquer jeito, não é anarquia, etc... O Scrum mesmo é totalmente rígido em algumas coisas, você tem que ser organizado em métodos ágies; tem que ser metódigo e lógico para implantar uma arquitetura, e isso... não é arte.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Leo D]

Também penso que é uma questão cultural. Até por isso perguntei sobre a obrigatoriedade do cartão de ponto no Brasil (que o Cássio gentilmente respondeu que sim, que a empresa deve fazer).

Aqui na Inglaterra eu não lembro de ter visto empresa exigindo horário dos funcionários. É raro.

Não é apenas Google e IBM não. Eu trabalho em uma empresa "anônima", se eu disser o nome vocês não vão reconhecer. Mas nessa empresa não só o horário é flexível, como a filosofia no geral é de "um bom ambiente de trabalho como estratégia para reter talentos". O CEO costuma ir trabalhar de bermudão e sandália, lá na cozinha tem Nintendo Wii que a pessoa pode jogar o quanto quiser, tem mesa de totó (pebolim?) no centro do escritório, "Beer o'clock" com cervejas grátis toda sexta feira, academia de ginástica, etc.
Lá na unidade americana eles vão mais longe ainda, dão uma quantidade infinita de feriados para o funcionário - o contrato diz que a pessoa pode tirar quantos dias de férias quiser no ano.

Obviamente existem prazos, metas, lucro, como em qualquer empresa. Mas acredito que é o bom senso coletivo que permite esse tipo de política.

[]s

[Rodrigo Braga]

Posso te mandar um curriculo? :)

2009/6/23 Leo D <l...@codigofluente.com.br>

--
Att.,
Rodrigo Braga

[Rafael Rosa]

@Leo

Só seria perfeito se trabalhassem com Ruby on Rails :) Caso trabalhem me avisem para onde mando meu CV :)

Atenciosamente,
Rafael Rosa
www.rafaelrosafu.com
www.rubyinside.com.br

[Eduardo Miranda]

Utilizar o intelecto não sinônimo de criatividade.

 

Desenvolver um algoritmo, ou um pedaço de código, é escolher racionalmente entre alternativas com seus prós e contras. Avaliar os benefícios e custos de cada opção e escolher a que te parece mais adequada para o problema.

 

Não consigo pensar em um exemplo que seja de código que eu tenha escrito e pensar "uauu, isto foi criativo!"

 

 

 

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Juliano Oliveira]

O que vocês estão descrevendo é um robo... e eu não sou um robo...

O Scrum é fruto de criatividade...

O DDD é fruto de criatividade...
O Rails é fruto de criatividade...

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/23 Eduardo Miranda <dud...@gmail.com>

[Juliano Oliveira]

criativo
cri.a.ti.vo
adj (criar+ivo) Criador.

criatividade
cri.a.ti.vi.da.de
sf (criativo+i+dade) 1 Qualidade ou estado de ser criativo. 2Capacidade de criar.

Será que ninguém aqui é criativo? Será que nosso trabalho é puramente juntar 1 + 1 e compreender que lógicamente isso é 2. Será que nosso trabalho é tão "bobo" assim que é só decorar alguns bons livros de linguagem, tecnologia, padrões de projeto que assim qualquer um consegue desenvolver ? Não é necessário criatividade? Imaginação?

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Eduardo Miranda]

O que estamos descrevendo é muito longe de ser um robô. Exige conhecimento, análise, decisões entre trade-offs, etc.

 

Scrum não é nem software, então não entendi estar nesta lista.

 

Nas outras duas, DDD e Rails, as idéias são fruto de criatividade, juntar as peças para alcançar algo diferente. Mas a implementação é essencialmente uma atividade de engenharia e não de arte.

 

Rails "nada mais é" do que Active record, um design pattern antigo + scafolding, outra idéia antiga implementada diversas vezes.

 

 

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Eduardo Miranda]

Juliano,

 

Alguém nesta thread afirmou algo sequer parecido com o que você está "criticando"?

 

Eu tenho certeza que não falei.

 

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Rafael Rosa]

Salve,

Sou obrigado a discordar de você Eduardo. Rails é muito mais do que juntar "ActiveRecord, um design patern antigo + scaffold". Essa me parece a opinião de alguém que nunca desenvolveu um projeto inteiro em Rails e não conhece a comunidade em torno da ferramenta. Existem escolhas filosóficas por trás do Rails e do Ruby que vão muito além da engenharia fria, e isso não é discurso de fanboy, é o que os próprios criadores dizem:

Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby - citando Matz, o criador do Ruby - texto completo em http://www.artima.com/intv/ruby.html

..all changed when I found Ruby and a community consisting as much of artists as engineers. People waxing lyrically about beautiful code and its sensibilities. People willing to trade the hard scientific measurements such as memory footprint and runtime speed for something so ephemeral as programmer happiness... - DHH criador do Rails - texto completo em http://www.loudthinking.com/posts/42-we-need-both-engineers-and-artists-in-programming

A comunidade Ruby e Rails pensa em outras coisas além da engenharia fria, assim como parte da comunidade ALT.NET, e essa é a parte que mais gosto na comunidade. Toda essa discussão sobre cartão de ponto ou não já morreu há muito tempo na comunidade, resumida à "faça o que deixar as pessoas felizes e se encaixe na cultura da empresa", simples assim.

[Juliano Oliveira]

Bom,

Você subestima o Rails achando que ele é "nada mais do que Activerecord". Alias, é a melhor implementação desse pattern.

Scrum é um exemplo de "criatividade". Criatividade nada tem a ver se é software ou não... por isso o exemplo do Scrum...

E eu não estou "criticando". Vocês (alguns membros) estão dizendo que o nosso trabalho de desenvolvimento não requer criatividade e eu estou discordando. Seria eu estúpido em "criticar" a opinião de outra pessoa, afinal, opinião é que nem bunda.

Alias, tudo surgiu justamente disso, ao dizerem que "implementação de uma idéia não é criatividade"

A prova de que isso não é verdade, você mesmo disse. Se "a idéia do Activerecord (um pattern)" é a mesma, por quê existem tantas e tantas implementações completamente diferentes do seu uso? Não seria, criatividade?

[Rodrigo Braga]

Acho que o Miranda não quis dizer necessáriamente nesse sentido.

Como ele mesmo comentou... diante de um determinado problema é preciso condições técnicas/gerenciais/... para avaliar N possíbilidades e escolher a que melhor se adequa ao problema, ter sensibilidade o suficiente para optar pela qual trará a melhor relação custo X beneficio.

e eu concordo que isso não é necessáriamente ser criativo... ou ser brilhante.

E se pensarmos em desenvolvimento de software, podemos inclusive ter a seguinte situação; precisamos implementar uma solução X, Beltrano usa injeção de dependência, MVC, DDD... tudo que manda o figurino; enquanto Cicrano "faz nas coxas"... se por debaixo do capô as coisas são diferentes o resultado final pode ser exatemente o mesmo.

Neste caso o Beltrano foi mais criativo? eu acho que não... ele foi mais sensato, sóbrio e estratégico... não necessariamente criativo.

Quando pensamos em aplicativos comercias acho que quase em 99% a coisa se dá por aí mesmo... montamos um quebra cabeça... juntamos N peças pra obtermos determinado resultado.

Criatividade seria o camarada em casa com um algumas gramas de plástico, dois sachês de mostarda e um pouco de silicio, conseguir combinar tudo em novo controlador que permite que ele faça algo novo, ou que pelo menos permita que ele faça algo "velho", de uma forma nova muito melhor... pensando em tecnologia.

o MacGyver por exemplo era um cara criativo, Einsten... Garrincha :)

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

--
Att.,
Rodrigo Braga

[Emmanuel G. Brandão]

Acho que estamos improdutivos por aqui... Vamos ficar chovendo no molhado, queimando campo com chuva, etc... Assim como eu disse ontem, essa thread já comecou como off-topic, e não vai nos levar muito longe...

Mas desafio o pessoal a discutir esse assunto de criatividade em uma rodada (apenas uma, para podermos dicutir outros assuntos em outras rodadadas) de chopp, sábado, após o DNAD.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Juliano Oliveira]

É isso que eu não entendo...

Sob essa ótica, então porque Einstein é criativo? Os números sempre estiveram ai, as lógicas, as integrais, as derivadas, tudo que ele usou estava ai. Se pensarem dessa forma, Einstein não era criativo, era só... Beltrano... ele foi mais sensato, sóbrio e estratégico... não necessariamente criativo...

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira

2009/6/23 Rodrigo Braga <rbr...@gmail.com>

[Juliano Oliveira]

Ótima idéia, só vai faltar mesa ne.. kkk

E só pra constar... já teve tanta off-topic aqui... mais uma... que difereça faz.. e toda discução longa vira off...

[Giovanni Bassi]

Combinadíssimo. É claro que vai rolar um HH depois do DNAD! E o DNADHH vai até tarde.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

[Rodrigo Braga]

Quantos de nós (participantes desta lista) com os mesmos números, lógicas e afins seria capaz de fazer o que ele fez?

Concordo que ele usou "componentes" que já existiam, mas permitiu que "problemas" fossem solucionados de forma diferente, permitiu que muitas coisas tivessem uma nova ótica.

Um outro exemplo, criar uma linguagem de programação de fato requer criatividade... usá-la sem dúvida nem tanto.

Eu concordo que determinadas coisas do nosso dia-a-dia requerem sim alguma criatividade, mas não acho que nosso trabalho seja pautado quase que única e exclusivamente em ser criativo...

Citaram aí a comunidade do Rails que pensa assim e pensa assado, mas sem dúvida muitos dos usuários do Rails apenas usam os recursos; ou será que a maioria esmagadora participa do processo criativo que permitiu que o Rails fosse criado e continuasse evoluindo até hoje?

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

--
Att.,
Rodrigo Braga

[Eduardo Miranda]

Vamos lá.

 

   Eu disse que o Rails é uma porcaria? Não

   Eu disse que o Rails não tem uma comunidade criativa? Não

   Eu disse que o Rails não é um framework extremamente criativo e inteligente? Não

 

O que eu disse foi que a criatividade dele está na elaboração da idéia, em juntar as peças certas e em atender o objetivo de forma inteligente.

 

A implementação dele é obra de criatividade? Aposto que muito pouco, eles usaram design patterns que já existiam de longa data, existem algoritmos mágicos maravilhosos dentro dele? Acredito que não.

 

PS: Rails não é o assunto da thread, portanto este é último email que escrevi sobre isto.

 

2009/6/23 Rafael Rosa <rafael...@gmail.com>

[Eduardo Miranda]

Você subestima o Rails achando que ele é "nada mais do que Activerecord"

 

Quem disse que Rails ruim?!

 

Scrum é um exemplo de "criatividade". Criatividade nada tem a ver se é software

 

Nós estamos discutindo o quão criativa é a atividade de desenvolver software, não isto? Portanto o fato do Scrum ser criativo não é relevante para discussão, pois ele não é resultado de uma atividade de desenvolver software, concorda?

 

E eu não estou "criticando"

O que há de errado em criticar e discordar? Eu não acho nada errado. O que tentei te explicar é que ninguém falou que a atividade de desenvolver software era "boba", simples ou que qualquer um pode desenvolver. Portanto você estava discordando de algo que ninguém falou.

Se "a idéia do Activerecord (um pattern)" é a mesma, por quê existem tantas e tantas implementações completamente diferentes do seu uso?

 

Quem implementou tomou decisões diferentes que levaram a soluções melhores ou piores. Existe criatividade? Sim, mas em um percentual pequeno do trabalho. Existe valor? Imenso, não é só o trabalho criativo que tem valor. Fazer as escolhas certas pode trazer muito valor para o produto final.

 

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Eduardo Miranda]

Apenas complementando

 

Eu teria o maior orgulho de criar (sim neste caso houve atividade criativa, na solução pensada :)) algo tão útil e bem pensado e escutar que é "apenas ..." pois evidencia o que existe de melhor no Rails, que é a sua simplicidade. Nunca perceberia isto como uma crítica, pois adoro simplicidade.

2009/6/23 Rodrigo Braga <rbr...@gmail.com>

[Juliano Oliveira]

Eduardo,

Não coloque palavras "que eu não disse" no meu discurso:

"Quem disse que Rails ruim?!" - Eu não disse, e nem você... eu disse SUBESTIMAR. 

Você constantemente distorce o que outros dizem, assim fica difícil debater.

Encerro por aqui.

[Rafael Rosa]

Rodrigo,

A comunidade Ruby/Rails é diferente das outras que conheci, incluindo a .NET. A maior parte do povo é gado, massa de manobra, como em todo tipo de comunidade, mas há um esforço "vindo dos líderes" para que todos pensem, sejam criativos e participem, é parte do mantra. Isso quer dizer que todos são gênios? Nem de longe, mas a cultura incentiva a criatividade, o prazer, a beleza, o craftsmanship, e isso é muito importante, sob meu ponto de vista pelo menos. Apertadores de botão existem em todos os cantos, mesmo quando não existe um drag-and-drop a mão.

Sinceramente acho a discussão sobre criatividade ou falta dela um tanto inócua, porque acho mais importante como o desenvolvedor se enxerga e entende seu trabalho. Alguns vão vê-lo como uma arte, outros como um jeito de pagar as contas, pouco importa, desde que cada pessoa tenha consciência disso. Essas diferenças se tornam mais relevantes quando juntamos vários desenvolvedores e esperamos que eles trabalhem em harmonia. Eu, por exemplo, não quero trabalhar com gente que programa apenas para pagar as contas, mas tem outros que não querem um idealista como eu por perto, então cada macaco no seu galho.

Eu sei, acredito firmemente, que meu trabalho exige criatividade e técnica, e o faço como um "artesão", amo meu trabalho, em boa parte graças ao Ruby. Sob um ponto de vista humanístico, adoraria que todos sentissem esse prazer, mas sei que isso não é possível. Estou convencido que a visão subjetiva é mais importante que o pensamento externo, porque é dela que extraímos nossas motivações, e isso incluí o efeito que cartão de ponto tem em cada um. Porém, a discussão do cartão já acabou uns 60 posts atrás.

[Eduardo Miranda]

Juliano,

 

Você quer que eu corrija a frase? Então corrigindo

 

Quem subestimou o Rails?

 

Este é meu email original.

 

Nas outras duas, DDD e Rails, as idéias são fruto de criatividade, juntar as peças para alcançar algo diferente. Mas a implementação é essencialmente uma atividade de engenharia e não de arte.
 
Rails "nada mais é" do que Active record, um design pattern antigo + scafolding, outra idéia antiga implementada diversas vezes.

 

Repare que o "nada mais é" está em aspas, justamente para não ser lido literalmente. E em momento nenhum eu afirmo que isto é ruim, ou diminui de alguma maneira o valor do produto final.

 

Eu poderia afirmar que você distorceu o que escrevi, mas prefiro pensar que eu não soube me expressar e você não conseguiu entender corretamente.

 

 

2009/6/23 Juliano Oliveira <jul.ol...@gmail.com>

[Eduardo Miranda]

Rafael,

 

Eu sei, acredito firmemente, que meu trabalho exige criatividade e técnica, e o faço como um "artesão"

 

Os highlights são por minha conta. Você se vê como um artesão, que conhece, e repete, técnicas. Isto faz parte do nosso trabalho, e geralmente toma uma parte grande do seu dia-a-dia.

 

Ser criativo tem seu momento, mas é muito mais em pensar como resolver o problema de melhor forma para o usuário, ou para o aplicação. As vezes isto resulta somente em uma experiência de usuário melhor, as vezes em um process assíncrono orientado a eventos.

 

Depois você vai lá tem que fazer as tarefas "não criativas", fazer a UI, escrever as regras de negócio, escrever o acesso a dados, escrever testes, corrigir bugs, ler mensagens no MSMQ, tratar erros, etc.

 

Isto não é sinônimo de trabalhar para pagar as contas, nem de não ter amor ao que faz. Sabe o que mais amo fazer? Conseguir um código absurdamente simples, que alguém daqui há dez anos seja capaz de ler e entender. Isto é criatividade? Não, mas tem um valor absurdo e não pode ser ignorado.

 

 

 

2009/6/23 Rafael Rosa <rafael...@gmail.com>

[Juliano Oliveira]

Eduardo,

Como disse antes, encerro minha participação nesse debate.

PS: Eu havia escrito uma mensagem com criticas (literalmente criticas) mas preferi apagar e encerrar esse debate para não me indispor e nem indispor outros. Só peço uma coisa a todos no grupo: "Tolêrancia" (no sentido literal mesmo). A mesma tolerância que eu tive ao evitar minhas criticar sobre a tua opinião e apenas para encerrar o debate.

[Mauricio Aniche]

Oi Eduardo,

Não sou muito a favor desta metáfora não. Quantas atividades no seu dia você avaliaria como "arte"? 20%? 10%?

No meu ver boa parte do trabalho de um desenvolvedor de software depende da sua criatividade. Eu nunca criei um software igual ao outro, ou um algoritmo igual ao outro. E para se criar algo novo é necessário criatividade.

O artigo do Richard Gabriel da qual havia citado era esse: http://java.sun.com/features/2002/11/gabriel_qa.html. Gosto muito do artigo.
 

 

Quantas atividades são aplicar conceitos/práticas já conhecidos? Ou seja, é necessário conhecimento, concentração, mas não muita criatividade?

Não entendi o que você quis dizer. O artista também aplica conceitos/práticas próprias durante todo o seu trabalho. O pintor conhece as cores e suas combinações, técnicas de pintura, o músico conhece escalas, instrumentos, o programador utiliza a linguagem de programação, etc, cada um na sua área. Todos eles têm suas ferramentas de trabalho e todos eles precisam de conhecimento e concentração, mas tudo isso sem criatividade não adianta.
 

 

Ou seja, no máximo poderíamos nos considerar artezãos.

Enfim, visões diferentes. Talvez eu seja influenciado por gostar muito de artes. :)

Abraços,
Mauricio Aniche
 

[Rodrigo Vieira]

Essa thread renderia um otimo podcast.. :)

2009/6/24 Mauricio Aniche <maurici...@gmail.com>:

[Eduardo Miranda]

No meu ver boa parte do trabalho de um desenvolvedor de software depende da sua criatividade. Eu nunca criei um software igual ao outro, ou um algoritmo igual ao outro. E para se criar algo novo é necessário criatividade.

Eu vejo algoritmos similares todos os dias. Faço decisões parecidas todos os dias. Foi justamente identificar esta característica da atividade de desenvolver software que levou o Kent Beck a escrever seu livro de patterns de small talk, que mais tarde virou o implementation patterns. Ele começou a identificar e formalizar os padrões pelo quais decidia como implementar um código, por exemplo, como nomear uma classe? Então ele escrevia como ele decidia o nome da classe. Segundo ele, isto o tornou um desenvolvedor melhor e muito mais produtivo.

 

 

Não entendi o que você quis dizer. O artista também aplica conceitos/práticas próprias durante todo o seu trabalho

 

Quero dizer que a maior parte do seu dia é dedicado a tarefas que não exigem criatividade. Exigem conhecimento, expertise, mas não criatividade.

 

 

2009/6/23 Mauricio Aniche <maurici...@gmail.com>

[Rodrigo Vieira]

2009/6/24 Eduardo Miranda <dud...@gmail.com>:

>
> Quero dizer que a maior parte do seu dia é dedicado a tarefas que não exigem
> criatividade. Exigem conhecimento, expertise, mas não criatividade.
>

Talvez um desenvolvedor não precise de criatividade para manter-se
empregado, mas desenvolvedores que além de serem bons tecnicamente tb
são criativos têm mais chance de serem bem-sucedidos. Se tudo fosse
uma questão de aplicar conhecimento automaticamente, todo código
poderia ser gerado por máquinas.

[Eduardo Miranda]

Não acho que uma atividade não criativa seja automaticamente mecânica. Um não é oposto do outro.

 

Muitas vezes tomar decisões racionais baseadas em conhecimento não pode automatizado. E tem bastante valor.

 

Posso pensar em muitas profissões que não são essencialmente criativas, mas também não são robotizadas.

 

Eu já trabalhei como trader de derivativos. Você utiliza conhecimento, "feeling", precisa tomar decisões rapidamente. Existem diversos experimentos de automatizar esta profissão, com aplicativos capazes de tomar decisões de trading. Mas ainda estão longe de conseguir.

 

Um piloto de avião precisa de criatividade? Não em 99% do seu trabalho. Mas isto torna seu trabalho mecânico e sem valor? Também não. Parte de sua atividade já foi automatizada, mas não 100%.

 

 

2009/6/24 Rodrigo Vieira <rodr...@gmail.com>

[Mauricio Aniche]

Oi,

2009/6/24 Eduardo Miranda <dud...@gmail.com>

No meu ver boa parte do trabalho de um desenvolvedor de software depende da sua criatividade. Eu nunca criei um software igual ao outro, ou um algoritmo igual ao outro. E para se criar algo novo é necessário criatividade.

Eu vejo algoritmos similares todos os dias. Faço decisões parecidas todos os dias. Foi justamente identificar esta característica da atividade de desenvolver software que levou o Kent Beck a escrever seu livro de patterns de small talk, que mais tarde virou o implementation patterns. Ele começou a identificar e formalizar os padrões pelo quais decidia como implementar um código, por exemplo, como nomear uma classe? Então ele escrevia como ele decidia o nome da classe. Segundo ele, isto o tornou um desenvolvedor melhor e muito mais produtivo.

Novamente, vejo padrões de projeto como ferramentas que um desenvolver usa. Não é pq tenho uma ferramenta que me ajuda no trabalho, que eu deixo de ser criativo.
 

 

 

Não entendi o que você quis dizer. O artista também aplica conceitos/práticas próprias durante todo o seu trabalho

 

Quero dizer que a maior parte do seu dia é dedicado a tarefas que não exigem criatividade. Exigem conhecimento, expertise, mas não criatividade.

Não sei não. Se pedíssemos pra todos aqui no grupo implementar um determinado algoritmo, duvido que teríamos alguma implementação igual a outra. Se essa atividade exigisse apenas conhecimento e expertise, creio que teríamos todas as implementações iguais, por exemplo. Os algoritmos saem diferentes justamente pq dependem da criatividade de cada um.

Acho que meu conceito de criatividade é diferente do seu.

Já mostrei meu ponto de vista nas respostas/tópicos anteriores e gostei também de conhecer o seu. Mas como disseram, a thread é off-topic e já se estendeu demais. Eu paro por aqui também.

Abraços,
Mauricio Aniche
 

[Eduardo Miranda]

Novamente, vejo padrões de projeto como ferramentas que um desenvolver usa. Não é pq tenho uma ferramenta que me ajuda no trabalho, que eu deixo de ser criativo.

 

Estou me referindo a padrões de implementação, são menores que design patterns. Como nomeio uma classe, como decido o escopo de variável, etc. Se tiver interesse procure o Implementation patterns, do Kent Beck para ter uma idéia (cuidado é em Java, se vc tiver alergia fique longe :) ).

 

Não sei não. Se pedíssemos pra todos aqui no grupo implementar um determinado algoritmo, duvido que teríamos alguma implementação igual a outra.

 

Mas poderiámos definir quais são os melhores por performance, legibilidade ou outros parâmetros objetivos. Será que a criatividade seria fundamental? Talvez se fosse um problema bem diferente do dia-a-dia, mas um problema comum, acredito que não.

 

  

2009/6/24 Mauricio Aniche <maurici...@gmail.com>

[Daniel Fonseca Castro]

Fala Galera,

 

O time que esta cuidando dos Podcast do grupo, montou uma pauta com essa thread,veja a pauta abaixo. 

 

Pauta:

Bate cartão é empecilho para pratica de SCRUM ou qualquer outra
metodologia ágil ?
Horas abertas/fechadas, CLT o que cai melhor com SCRUM?
As equipes e SCRUM são realmente auto-gerenciáveis?
Quanto os diretores e coordenadores influenciam no rendimento da equipe?
Qual a diferença de nível de produtividade de equipes Scrum com cartão de ponto e sem ?
Como o mercado nacional reage com a adoção de metodologias ágeis, sendo que a maioria utiliza-se de horário não flexíveis? Como fica a cabeça do desenvolvedor nesse caso?

 

Gostaria de convidar quatro pessoas para fazer esse podcast, já tenho uma confirmação Giovanni Bassi,  então a pergunta é simples quem esta afim de participar?

 

O podcast será gravado via Skype, o dia e horário serão definidos conforme disponibilidade dos participante, para facilitar peço que envie e-mail direto no meu e-mail!

 

Abraços,

Daniel Fonseca Castro

 

2009/6/24 Eduardo Miranda <dud...@gmail.com>

[Raphael Molesim]

Eu gostaria de participar!

On Jul 1, 8:36 am, Daniel Fonseca Castro

<danielfonsecacas...@gmail.com> wrote:
> Fala Galera,
>
> O time que esta cuidando dos Podcast do grupo, montou uma pauta com essa
> thread,veja a pauta abaixo.
>
> Pauta:
> Bate cartão é empecilho para pratica de SCRUM ou qualquer outra
> metodologia ágil ?
> Horas abertas/fechadas, CLT o que cai melhor com SCRUM?
> As equipes e SCRUM são realmente auto-gerenciáveis?
> Quanto os diretores e coordenadores influenciam no rendimento da equipe?
> Qual a diferença de nível de produtividade de equipes Scrum com cartão de
> ponto e sem ?
> Como o mercado nacional reage com a adoção de metodologias ágeis, sendo que
> a maioria utiliza-se de horário não flexíveis? Como fica a cabeça do
> desenvolvedor nesse caso?
>
> Gostaria de convidar quatro pessoas para fazer esse podcast, já tenho uma
> confirmação Giovanni Bassi,  então a pergunta é simples quem esta afim de
> participar?
>
> O podcast será gravado via Skype, o dia e horário serão definidos conforme
> disponibilidade dos participante, para facilitar peço que envie e-mail
> direto no meu e-mail!
>
> Abraços,
> Daniel Fonseca Castro
>

> 2009/6/24 Eduardo Miranda <duda...@gmail.com>

>
>
>
> >  Novamente, vejo padrões de projeto como ferramentas que um desenvolver
> >> usa. Não é pq tenho uma ferramenta que me ajuda no trabalho, que eu deixo de
> >> ser criativo.
>
> > Estou me referindo a padrões de implementação, são menores que design
> > patterns. Como nomeio uma classe, como decido o escopo de variável, etc. Se
> > tiver interesse procure o Implementation patterns, do Kent Beck para ter uma
> > idéia (cuidado é em Java, se vc tiver alergia fique longe :) ).
>
> >> Não sei não. Se pedíssemos pra todos aqui no grupo implementar um
> >> determinado algoritmo, duvido que teríamos alguma implementação igual a
> >> outra.
>
> > Mas poderiámos definir quais são os melhores por performance,
> > legibilidade ou outros parâmetros objetivos. Será que a criatividade seria
> > fundamental? Talvez se fosse um problema bem diferente do dia-a-dia, mas um
> > problema comum, acredito que não.
>

> > 2009/6/24 Mauricio Aniche <mauricioani...@gmail.com>
>
> >> Oi,
>
> >>  2009/6/24 Eduardo Miranda <duda...@gmail.com>

> >>> 2009/6/23 Mauricio Aniche <mauricioani...@gmail.com>

>
> >>>> Oi Eduardo,
>
> >>>>> Não sou muito a favor desta metáfora não. Quantas atividades no seu dia
> >>>>> você avaliaria como "arte"? 20%? 10%?
>
> >>>>  No meu ver boa parte do trabalho de um desenvolvedor de software
> >>>> depende da sua criatividade. Eu nunca criei um software igual ao outro, ou
> >>>> um algoritmo igual ao outro. E para se criar algo novo é necessário
> >>>> criatividade.
>
> >>>> O artigo do Richard Gabriel da qual havia citado era esse:
> >>>>http://java.sun.com/features/2002/11/gabriel_qa.html. Gosto muito do
> >>>> artigo.
>
> >>>>> Quantas atividades são aplicar conceitos/práticas já conhecidos? Ou
> >>>>> seja, é necessário conhecimento, concentração, mas não muita criatividade?
>
> >>>>  Não entendi o que você quis dizer. O artista também aplica
> >>>> conceitos/práticas próprias durante todo o seu trabalho. O pintor conhece as
> >>>> cores e suas combinações, técnicas de pintura, o músico conhece escalas,
> >>>> instrumentos, o programador utiliza a linguagem de programação, etc, cada um
> >>>> na sua área. Todos eles têm suas ferramentas de trabalho e todos eles
> >>>> precisam de conhecimento e concentração, mas tudo isso sem criatividade não
> >>>> adianta.
>
> >>>>> Ou seja, no máximo poderíamos nos considerar artezãos.
>
> >>>>  Enfim, visões diferentes. Talvez eu seja influenciado por gostar muito
> >>>> de artes. :)
>
> >>>> Abraços,
> >>>> Mauricio Aniche
>

> >>>>>  2009/6/23 Mauricio Aniche <mauricioani...@gmail.com>

> >>>>>>  2009/6/22 Rodrigo Vieira <rodrig...@gmail.com>

[Ubiratan Padilha]

Olá, Daniel.

Eu topo participar do podcast.

[]´s

Ubiratan Padilha
Project Manager, CSM, Especialista em Usabilidade
http://www.linkedin.com/in/ubiratanpadilha
http://twitter.com/ubiratanpadilha


On 1 jul, 08:36, Daniel Fonseca Castro <danielfonsecacas...@gmail.com>
wrote:

> Fala Galera,
>
> O time que esta cuidando dos Podcast do grupo, montou uma pauta com essa
> thread,veja a pauta abaixo.
>
> Pauta:
> Bate cartão é empecilho para pratica de SCRUM ou qualquer outra
> metodologia ágil ?
> Horas abertas/fechadas, CLT o que cai melhor com SCRUM?
> As equipes e SCRUM são realmente auto-gerenciáveis?
> Quanto os diretores e coordenadores influenciam no rendimento da equipe?
> Qual a diferença de nível de produtividade de equipes Scrum com cartão de
> ponto e sem ?
> Como o mercado nacional reage com a adoção de metodologias ágeis, sendo que
> a maioria utiliza-se de horário não flexíveis? Como fica a cabeça do
> desenvolvedor nesse caso?
>
> Gostaria de convidar quatro pessoas para fazer esse podcast, já tenho uma
> confirmação Giovanni Bassi,  então a pergunta é simples quem esta afim de
> participar?
>
> O podcast será gravado via Skype, o dia e horário serão definidos conforme
> disponibilidade dos participante, para facilitar peço que envie e-mail
> direto no meu e-mail!
>
> Abraços,
> Daniel Fonseca Castro
>

> 2009/6/24 Eduardo Miranda <duda...@gmail.com>

>
>
>
> >  Novamente, vejo padrões de projeto como ferramentas que um desenvolver
> >> usa. Não é pq tenho uma ferramenta que me ajuda no trabalho, que eu deixo de
> >> ser criativo.
>
> > Estou me referindo a padrões de implementação, são menores que design
> > patterns. Como nomeio uma classe, como decido o escopo de variável, etc. Se
> > tiver interesse procure o Implementation patterns, do Kent Beck para ter uma
> > idéia (cuidado é em Java, se vc tiver alergia fique longe :) ).
>
> >> Não sei não. Se pedíssemos pra todos aqui no grupo implementar um
> >> determinado algoritmo, duvido que teríamos alguma implementação igual a
> >> outra.
>
> > Mas poderiámos definir quais são os melhores por performance,
> > legibilidade ou outros parâmetros objetivos. Será que a criatividade seria
> > fundamental? Talvez se fosse um problema bem diferente do dia-a-dia, mas um
> > problema comum, acredito que não.
>

> > 2009/6/24 Mauricio Aniche <mauricioani...@gmail.com>
>
> >> Oi,
>
> >>  2009/6/24 Eduardo Miranda <duda...@gmail.com>
>

> >>> 2009/6/23 Mauricio Aniche <mauricioani...@gmail.com>

>
> >>>> Oi Eduardo,
>
> >>>>> Não sou muito a favor desta metáfora não. Quantas atividades no seu dia
> >>>>> você avaliaria como "arte"? 20%? 10%?
>
> >>>>  No meu ver boa parte do trabalho de um desenvolvedor de software
> >>>> depende da sua criatividade. Eu nunca criei um software igual ao outro, ou
> >>>> um algoritmo igual ao outro. E para se criar algo novo é necessário
> >>>> criatividade.
>
> >>>> O artigo do Richard Gabriel da qual havia citado era esse:
> >>>>http://java.sun.com/features/2002/11/gabriel_qa.html. Gosto muito do
> >>>> artigo.
>
> >>>>> Quantas atividades são aplicar conceitos/práticas já conhecidos? Ou
> >>>>> seja, é necessário conhecimento, concentração, mas não muita criatividade?
>
> >>>>  Não entendi o que você quis dizer. O artista também aplica
> >>>> conceitos/práticas próprias durante todo o seu trabalho. O pintor conhece as
> >>>> cores e suas combinações, técnicas de pintura, o músico conhece escalas,
> >>>> instrumentos, o programador utiliza a linguagem de programação, etc, cada um
> >>>> na sua área. Todos eles têm suas ferramentas de trabalho e todos eles
> >>>> precisam de conhecimento e concentração, mas tudo isso sem criatividade não
> >>>> adianta.
>
> >>>>> Ou seja, no máximo poderíamos nos considerar artezãos.
>
> >>>>  Enfim, visões diferentes. Talvez eu seja influenciado por gostar muito
> >>>> de artes. :)
>
> >>>> Abraços,
> >>>> Mauricio Aniche
>

> >>>>>  2009/6/23 Mauricio Aniche <mauricioani...@gmail.com>

> >>>>>>  2009/6/22 Rodrigo Vieira <rodrig...@gmail.com>

> >>>>>>> reunião" heeheh- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -