OpenArch's Blog

Lendo o artigo “James Shore: O Declínio e a Queda do Agile” no InfoQ, me veio a mente um fato que se passou, ou está passando, em uma empresa de software brasileira.

A empresa resolveu, depois de algum tempo utilizando metodologias tradicionais de desenvolvimento de software, adotar a metodologia ágil, especificamente o tão difundido SCRUM.
Todos adoraram a idéia no início. Porém, depois de um tempo, notaram que a mudança foi boa somente para a empresa. O que aconteceu de errado?

A mudança para a tão esperada metodologia ágil veio, neste caso, para “inglês ver” e para cortar custos nos projetos. Os atuais e futuros clientes ficariam satisfeitos em ver seu fornecedor de projetos de software utilizando metodologias modernas, que estão “bombando” no mercado. Além disso, vários cargos e subdivisões foram extintas, acabando com o “plano de carreira” dos funcionários e aumentando a diferença salarial entre funcionários de um mesmo cargo. O que feito desta forma, gera muita concorrência interna e conflitos desnecessários.

Outro fator que não agradou muita gente foi o fato dos desenvolvedores ficarem agora diretamente ligados aos clientes, seja através de reuniões, e-mail, instant messengers ou telefone. Nem todo desenvolvedor e muito menos os clientes estão prontos para este contato direto. Mesmo utilizando metodologia ágil um filtro mínimo entre os desenvolvedores e os cliente é necessário para melhorar a produtividade da equipe.

O que mais tenho medo nisso tudo é um dos fatos que o James Shore aponta em seu artigo.

Então, infelizmente, muitos auto-intitulados projetos Ágeis fracassarão. Eles estão fracassando neste momento. E eventualmente Agile recebá a culpa, e ela passará, como todas as novidades eventualmente passam.

O artigo completo pode ser lido aqui.

Recentemente visitando uma empresa para uma entrevista de trabalho, não pude de deixar de perceber que, em todas as salas por onde passei – conheci praticamente toda empresa, menos a diretoria e os banheiros – haviam câmeras de segurança! Fiquei pensando se seriam estas, para evitar furtos, ou ate mesmo assaltos. Será mesmo?! Circuito interno de TV dentro da empresa de TI, situada em um prédio que, já conta com sistema de catracas, seguranças e circuito interno de TV nos corredores e elevadores?!

Já soube de casos onde, os programadores de uma empresa são monitorados pela IDE onde seus códigos são escritos! Caso o programador fique muito tempo sem “digitar” – porque este deve ser o trabalho, passar do papel para o computador a 120 bpm – sem justificativa, era questionado e/ou penalizado.

Temos também outro tipo de controle, bem mais simples, pontos eletrônicos, relógio de ponto e ate mesmo folha de papel com assinatura. Onde os funcionários mostram que estão dentro da empresa durante o período de trabalho. Muito útil para empresas de TI, concordam?

E ainda existem as empresas onde, não existe isso de ponto, controle de log, ou monitoramento físico. Nestas empresas, o funcionário é cobrado pela qualidade do trabalho desempenhado. Seria isso um devaneio ou uma realidade utópica criada por comunistas?

Inspirado nisso e no post do Corélio, faço as seguintes perguntas:

Onde você trabalha e onde gostaria de trabalhar?

A)

B)

C)

D)

Lembrando que me refiro a empresas de TI e outras, onde o tempo não é necessariamente a melhor forma de mensurar o trabalho realizado.

“Aquele que não tem confiança nos outros, não lhes pode ganhar a confiança.” — Lao-Tsé

O Corélio postou recentemente uma ótima maneira de avaliar em qual dos níveis de qualidade está a “fábrica de software” ou local de trabalho de nós, desenvolvedores de software.

Fiz o teste, a pontuação que consegui foi 2. Ou seja, já estou baixando o filme “Tempos modernos”.

Em alguns casos, este instrumento de lucratividade, que são muitas das nossas “fabricas de softwares”, pode se virar contra a empresa, se tornando um setor deficitário e gerador de prejuízo para a empresa. E isso se deve aos pontos chaves que o Corélio colocou no teste. Como a insatisfação e esgotamento das horas extras excessivas. A falta de treinamento que geram muitos bugs nos produtos e serviços, etc.

Clique aqui para ir direto ao post.