codificando.com

Quem não se lembra do comercial da Oi sobre bloqueio de celulares que fez bastante barulho?

O bloqueio as vezes faz parte da vida do Desenvolvedor de Software. Em muitas empresas que trabalhei, tive que conviver com alguns. Foram eles:

• Bloqueio da Internet (Parece mentira, mas trabalhei num lugar onde somente algumas equipes tinham acesso a internet)
• Bloqueio de Instant Message
• Bloqueio de email (Não dava pra acessar o Gmail)
• Bloqueio do Internet Banking
• Bloqueio de alguns sites (Eu não conseguia acessar alguns blogs importantes)
• Bloqueio do Telefone (Não dava nem pra ligar pra casa e em algumas empresas nem telefone na mesa tinha)
• Bloqueio da estação de trabalho (Como que um desenvolvedor que não pode instalar nada no seu computador consegue trabalhar?)
• Bloqueio da Impressora (Tinha senha especial pra imprimir)

Depois de sofrer bastante com esses bloqueios eu me interessei em saber o motivo que leva muitas empresas a trabalhar dessa forma. Apesar do argumento deles ser furado, vou listar o que eu ouvi de diversas pessoas:

• Perda de produtividade (segundo eles, as pessoas perdem muito tempo com coisas inúteis na internet e telefone)
• Falta de foco dos funcionários (Pessoas se desconcentravam facilmente com o IM e outros)
• Desperdício de recursos da empresa. (Gente imprimindo e usando o telefone demasiadamente)

Depois disso, passei a observar o comportamento das pessoas pra ver como cada um se resolvia com essa série de bloqueios. Eis o que percebi:

• A ausência da Internet gerava falta de produtividade, pois os desenvolvedores não conseguiam pesquisar algumas coisas, não tinham forum de discussão e não se mantinham atualizados lendo alguns blogs de tecnologia
• A ausência do Instant Message impedia que um desenvolvedor pedisse ajuda a algum colega que já tenha trabalhado com ele para solucionar um determinado problema.
• A falta do email fazia com que houvessem notebooks com internet móvel espalhados pela empresa para que o pessoal conseguisse ler seus emails.
• A impossibilidade de instalação de softwares na máquina do desenvolvedor fazia com que o mesmo perdesse mais tempo que o necessário para resolver determinados problemas.
• Muitos criaram seu prórpio jeito de burlar isso tudo (Proxys anônimos, senha de admin das máquinas escondido, mais tempo de almoço pra telefonar e imprimir em lan-houses)

E o pior: Essas empresas PERDERAM ÓTIMOS PROFISSIONAIS.

Atualmente eu trabalho numa empresa onde não tem dessas coisas. Aqui nossa internet é totalmente liberada, podemos usar o telefone sem problemas, enviar email a vontade, pagar nossas contas e até mesmo usar o Instant Message (MSN, Yahoo, ICQ, Gtalk), que é considerado por muitos um absurdo.

A conclusão que eu cheguei foi que não importa o que a empresa faça, se o desenvolvedor não quiser trabalhar, ele vai dar um jeito de faze-lo, mesmo que seja burlando as coisas ou simplesmente levando um livrinho e passando o dia lendo na sua mesa.

O que a sua empresa precisa é contratar profissionais de verdade e não pessoas que simplesmente querem um emprego, pois quem quer realmente trabalhar, usa esses recursos a favor da empresa e não contra.

Para aumentar a produtividade e diminuir os custos, recomendo ainda introduzir alguma filosofia de trabalho ágil na sua empresa.

Quem ama não bloqueia !!!

Faz alguns meses que os gujeiros Rodrigo Yoshima e Carlos Villela blogaram sobre o uso errado da tecnologia numa fábrica de pastas de dentes. Para resolver o problema de caixas vazias que passavam desapercebidas numa linha de produção, a empresa comprou uma ultra-mega-power solução que ainda acabou atrapalhando os trabalhadores da fábrica. Mas os próprios trabalhadores se encarregaram de comprar um ventiladorzinho de 20 dólares e dispensar o mega equipamento.

Quem é Brasileiro e principalmente presenciou as corridas de nossos grandes pilotos de Fórmula 1, provavelmente ainda acompanha a categoria, mesmo que exporadicamente. Eu, criado em uma família muito ligada a esportes, com forte inclinação para F1(por que será que meu nome é Emerson? Alguém consegue advinhar? rs), continuo acompanhando os campeonatos, na esperança de que um brasileiro novamente seja campeão mundial.

Eis que no primeiro GP noturno da história da F1 a Ferrari atrapalhou Felipe Massa durante o seu pit-stop com um equipamento ultra moderno que foi desenvolvido para substituir o tradicional pirulito, durante os pit-stops. Esse pirulito foi utilizado por mais de 20 anos e que sempre se mostrou adequado. O novo equipamento fica posicionado em uma altura acima da cabeça do piloto, o que dificulta a visualização em caso de uma nova instrução para parar. O piloto brasileiro perdeu uns 30 segundos pois a mangueira de combustível rompeu-se e sua corrida foi comprometida, inclusive comprometendo a possibilidade de conquiista do campeonato. No pit-stop seguinte, na mesma corrida, a Ferrari voltou a usar o pirulito e no GP seguinte, aposentou de vez a sua engenhoca.

Uma das filosofias que mais gosto para Desenvolvimento de Software nos tempos atuais é KISS. Eu até hoje não sei o motivo de querermos fazer as coisas de forma complicada ao invés de simplificar (eu mesmo já errei muito nisso). Note que simples não significa sem qualidade, mas fazer o suficiente que possa atender a necessidade. As metodologias ágeis da moda como SCRUM / XP falam muito sobre isso. A prática de TDD também tem esse foco, quando prega que devemos fazer o código mais simples possível que atenda a necessidade em questão. E não poderia me esquecer do tão importante princípio de Baby Steps, utilizado em tudo isso que mencionei anteriormente.

Eu sinceramente acho que esse problema é inerente do ser humano e nós é que devemos nos doutrinar pra não cair nessa besteira.

Nesses últimos 2 dias, estive presentei no Rails Summit Latin américa. A organização do evento está de parabéns, principalmente o Fabio Akita, que conseguiu trazer pessoas chave da comunidade Rails mundial. As únicas coisas que senti falta foi uma camiseta do evento e a tradicional livraria, essa última eu tolerei pois ganhei um livro na palestra do Danilo Sato

Até a próxima …

Amanhã estarei presente no Rails Summit Latin América em São Paulo.

O Evento promete ser bem legal, principalmente por ser o primeiro evento de Rails desse porte a ser realizado aqui no Brasil (se não me engano, rs).

Espero que esse evento ajude a alavancar ainda mais o desenvolvimento Ruby/Rails aqui no Brasil e que em breve esse mercado esteja tão aquecido quanto o mercado de Java.

Até amanhã então