Viagens, opiniões e afins

Conversando que a gente se entende

Um dos grandes problemas atuais de TI que encontro é a questão da comunicação. Quando esta falha,  tudo falha… mesmo se as outras partes envolvidas estejam “bem feitas”. Sem comunicação, não existe um troca eficiente, a interação entre os membros se perde, há desinformação, entre outros efeitos… sem comunicação não existe possibilidade de time, existe apenas um amontoado de gente trabalhando num mesmo projeto ou atividade.

Antes de mais nada, gostaria de dizer que, quando falo em comunicação,  estou tratando em seu significado mais amplo : comunicação são as conversas, os emails, os quadros de aviso,  as reuniões, os post it na parede… Enfim, ela é tudo que visa a troca de conhecimento ou ideias e informações.  Ao dar bom dia a uma pessoa que trabalha com você, você está se comunicando; ao enviar um mensagem via mensageiros instantâneos (gtalk, msn, yahoo, etc) você está se comunicando.  Muito apenas consideram a parte formal  da comunicação e esquecem que a parte informal é de suma importância.  Se este “bom dia” não acontece, você como líder, pode estar em apuros.

Do pouco que já rodei por aí, já presenciei e participei de diversas situações onde uma comunicação falha, acabou com toda a equipe.  Um dos casos que gosto de citar é de uma empresa onde trabalhei que, o pessoal não tinha uma boa interação e as raras vezes que essa acontecia era para “sacanear”alguém. Isso gerou um desconforto tamanho na equipe, que aos poucos, as pessoas que eram o alvo das brincadeiras ou que não se sentiam confortável com aquilo foram ficando insatisfeitas. Resultado: projeto ruim,  projetos atrasados, etc. Antes que alguém pergunte: “Será possível que um problema pessoal interfira tanto no resultado? Cade o profissionalismo ?”. Não pode esquecer que somos seres humanos e não vulcanos ( momento start trek) … Nossas emoções influenciam diretamente nosso desempenho, ainda mais a nós que somos latinos.

pessoas não conversam

Continuando a história… a comunicação que a principio não tinha nenhuma relação com o desenvolvimento em si, estava causando muitos problemas. Infelizmente não houve solução, as pessoas saíram, e a equipe dissolveu-se.

Bem , se algo que não tem ligação com o dia a dia de projeto já causou um estrago como na história acima, imagine quando falamos de comunicação que fala exatamente do projeto? Se ela for mal feita, o projeto corre sério risco de não dar certo.

Outra história que conto, é de um ex chefe meu que tinha a mania de não expor com clareza o que ele queria, nem explicar de forma clara os requisitos das funcionalidades que eram para ser feitas.  Nas muitas vezes que discuti com ele, exatamente por causa disso, sempre repetia uma frase: “Ainda não sei ler mente, mas quem sabe com o tempo”.  Um requisito mal explicado é pior  ou igual pior que um requisito não dito. Não foram poucas as vezes que o pessoal da equipe acabou implementando funcionalidades incoerentes com o desejado pelo cliente; foi obrigada a refazer tudo por não estar de acordo “como deveria ser” (como se soubessémos por leitura de mente); e por essa estrada o dia a dia seguia.

Mas os problemas não estão somente na parte verbal da comunicação. Acredito, na minha pouca experiência, na maioria  dos casos os grandes problemas estão nas outras comunicações que acabam  esquecidas.  Com a moda de adoção de metodologias ágeis, a questão da comunicação ganhou uma certa importância, mas maior parte dos casos que vejo e ouço de meus amigos, há uma preocupação com a interação verbal, mas esquecem das não verbais (avisos, emails,  alertas, etc) . Pode parecer até uma contrasenso em nossa era, mas parece que estamos cada vez mais nos comunicando pior!  Documentos mais escritos, pouco domínio da lingua, entre outras coisas, dão margem para interpretações equivocadas e com isso perda de tempo por parte do time com implementações incorretas, por exemplo.

afogado em post its

Não sou a favor de um revisor de português para cada empresa, mas sou sinceramente a favor de pessoas que usem bem o meio de comunicação delas.  Não adianta querer escrever um livro para explicar algo por email, nem um frase.  Tem que se dosar, e procura tirar o melhor de cada. Além disso, essa comunicação não verbal, tem que ser intuitiva, leve, fluidica e permitir uma interação entre a mensagem e o espectador.  Gramática correta, ortografica correta, coerencia e coesão,  sintaxe … tudo isso facilita a leitura e deixa a coisa direta e clara.  Canso de ver aberrações em emails de pessoas de cargos de relevancia que no final acabam indo para lixeiras contendo um aviso importante por erros de escrita grosseiros ( erros de uso de “mim”, “amostrar” ao invés de mostrar, falta de pontuação, estrangerismo em excesso – os jobs file executam em multthreading com forks de flocks vibration poles – e por ai vai ). Fazer o simples, escrever simples, “famoso feijão com arroz”, funciona na maioria dos casos.

Por isso que quadros de post its podem ser excelentes ferramentas, mas cuidado para não abusar da coisa.  Ter a preocupação de pensar nas cores, letras, tamanho de fonte,  são coisa extremamentes válidas e garante um bom retorno no objetivo de comunicar, porém isso sempre fica num segundo plano e na maioria dos casos ignorado.

Bem amigos, enquanto não tivermos evoluído o suficiente para termos telepatia e ler mentes, ou algo parecido, vamos depender, e muito, da comunicação.  Por isso trate-a com carinho em seus projetos e dedique um tempo para trabalhá-la de forma a ser a melhor coisa o possível e verá que os ganhos vão pagar cada sacrificio feito nesse sentido.

Uma das coisa que me incomondam bastante é toda vez que vou iniciar um projeto, e tenho que montar um ambiente de desenvolvimento, perco horas e mais horas para completar a tarefa. Tudo porque, na maioria das empresas para as quais trabalhei, trabalho e trabalharei,  nunca tem um processo automatizado e padronizado de montagem de ambiente.  Sei que isso pode soar um tanto burocrático e o pessoal que odeia qualquer coisa que possa virar papel vai dizer que isso é uma heresia, mas acredito que é um mal necessário.
Para a grande parte das pessoas que começam numa nova empresa, projeto, etc, a rotina sempre a mesma :  horas baixando instaladores,  horas instalando tudo (pior se for em windows, pois as vezes tem que dar reboot na máquina), mais um monte de outras horas para configurar, criar usuários, baixar código, entender como funciona o build, e por aí se vão dias de trabalho gerando zero de valor agregado para o cliente.  O mais esquisito, que mesmo sendo isso um mega prejuízo para o projeto – uma pessoa consumindo horas do projeto sem fazer “nada” , não existe nenhum movimento para mudar essa realidade.
Não estou falando de processos ultra-automatizados que lê mentes e pelo jeito que você diz bom dia monta a sua máquina,  estou falando de coisas simples, como padronizar, repositórios internos de instalações e bibliotecas, uso de produtos que automatizem build e tarefas repetitivas, etc.  Estou falando também de, no caso de empresa maiores,  uma imagem de ambiente (backup) padronizada para que quando um novo desenvolvedor chegue, basta comprar um novo computador, baixar a imagem e configurar.
Não faltam ferramentas, produtos e soluções no mercado que podem ajudar a qualquer um a resolver isso. Em aplicações java, temos o maven (maven.apache.org) que pode cobrir muito bem quase toda o problema:  ele pode montar o projeto, instalá-lo, baixar as bibliotecas, configurar ambiente, compilar e fazer build, etc; além dele existe a opção de escrever em ant (ant.apache.org)  diversos scripts para automatizar build de aplicação, montagem de ambiente, etc. Em Ruby,  aqui não muito minha praia, acredito que existe o gems e o rake que facilitam bem esse trabalho.  Para os passo não cobertos por essas ferramentas, existem outras.  Em última instancia, pode ser colocado como uma história do sprint ( ou uma tarefa de backlog) e assim criar um programa que faça isso (bash, bat, cmd ,etc).
A questão mais importante é que exista algo padronizado e de preferencia automatizado, fazendo que se perca o mínimo de tempo possível com tarefas que não agregam valor ao cliente que está pagando.  A ideia é exatamente de não perder tempo com coisas que não geram retorno: atividades repetitivas, processos  que podem ser automatizados e outras coisas, maximizando o foco na funcionalidade.

Ultimamente é mais do que batido famosos artigos comparando linguagens e com conclusões um tanto radicais do tipo : “A linguagem B é melhor que C pois é mais produtiva”; “A linguagem P não escala”; “A linguagem Z é mais fácil e tem tudo que é necessário já integrado”; etc.  As questões que coloco frente a essas publicações são: Existe escolha perfeita ? Será que os contextos usados são justos, ou seja, permitem uma comparação em igualdade? Dá para comparar ou isso é apenas uma discussão como “sexo dos anjos”? Recentemente a discussão ganhou mais força com uma recente divulgação, não oficial, de que os desenvolvedores da Google estão sendo desencorajados a usarem Python em novos projetos [1]  .Na troca de emails, a decisão é justificada no fato que, o senso comum dentro da empresa acredita que o Python, dado o crescimento e escala das aplicações atuais, não responderia de forma satisfatória.

Java foi inventada na década de 90 (sua primeira versão foi por volta de 1995) e sua origem é bastante interessante e pouco conhecida do público em geral.  Java, antes chamada por Grosling de OAK (Carvalho em inglês), foi criada com objetivo permitir a comunicação entre diversos equipamentos, que não somente o computador. Nesses projeto, a intenção não era de criar um nova linguagem e sim uma tecnologia de convergência. Por um capricho do destino, as empresas não gostaram tanto e não compraram a ideia.

Nesse mesmo período a internet começava a se tornar o sucesso de hoje.  Com um crescimento rápido e em pouquíssimo tempo uma grande interativa estava se formando. Era exatamente este tipo de conectividade que a equipe de Grosling propunha. A ligação foi imediata e partiram para adaptar a OAK para esse novo possível uso. Assim nascia a primeira versão de Java. Ela foi totalmente concebida dentro do objetivo de “trafegar” em ambientes heterogêneos. Seu primeiro momento de sucesso veio do uso dos Applets (aplicações java que rodavam dentro do navegador através de uso de plugin) que deu um tom dinâmico ao, até então, estático hiper texto (html).  Daí por diante a adoção e crescimento do Java foi meteórico e hoje temos esse cenário onde ela é a principal tecnologia usada por grandes empresas em seus sistemas.

O interessante dessa história, é que durante muito tempo do início da linguagem, Java era considerada ruim. Isso mesmo ruim: muitos afirmavam que sua natureza multi-plataforma, sendo interpretada, a tornava lenda e muito pesada, pois consumia muita memória dos pobres PCs da época (antigamente memória e disco eram caros). Não foram poucos artigos escritos que afirmavam que, num ambiente corporativo, Java jamais seria aplicável  pois sobrecarregava demais o equipamento e não era escalável (lembra alguma coisa não). Tais problema realmente existiam, como por exemplo, a questão das strings, do tempo de interpretação, o problema do AWT (biblioteca para aplicações desktop), etc.

A questão que várias investimentos e esforços, ao longo do tempo, foram feitos para que a linguagem fosse melhorando e se tornando mais robusta e perfomática. Primeiro foi a adoção completa do bytecode, hotspot, melhoria constantes no algoritmo de garbage collector(coletor de lixo – parte responsável por retirar da memória os objetos que não estão mais em uso), api de threads, melhorias significativas na parte Desktop, e por aí seguem as mudanças. Hoje já estamos na sua sexta versão e em breve virá a sétima. A linguagem que temos atualmente é completamente diferente daquela lançada em 1995 embora ainda guarde muita da filosofia e arquitetura.

Claro que paralelamente as sucessivas melhoras, os próprios computadores e servidores evoluíram muito também. Hoje é normal termos máquinas pessoais com mais de 2Gb de memória e discos rígidos de 500 Mb. Se pensarmos em servidores, a um custo bastante acessível é possível adquirir equipamentos de até 64 Gb de memória, 4 processadores, 64 Bits, etc. Isso logicamente tem um impacto: não tem grande relevância o uso de memória ou cpu por uma linguagem, guardando as devidas proporções, é claro.

Bem fato é que Java é usada amplamente em diversas empresas e representa um parcela significativa do mercado de desenvolvimento. Graças a sua natureza “gratuita”, porém não aberta – mais adiante isso será melhor abordado – uma grande comunidade em seu entorno se formou, facilitando a sua adoção e incrementando a experiência do desenvolvedor com bibliotecas, frameworks, ferramentas, etc.

Porém dado o seu sucesso e sua ampla adoção, parece que Java passou de herói para vilão:  as pessoas mais revolucionárias afirmam que ela é ruim, muito presa, evolui lentamente, extensiva demais, pouco produtiva, etc. Não faltam quadros comparativos de classes Java que fazem algo e outro com código da linguagem B que faz a mesma coisa com bem menos linhas.  Não faltam blogs com artigos dizendo que Java não livre e que é corporativa, que não possui uma sintaxe clara e legível. E por vão outros exemplos.

Duas “linguagens” e suas comunidades se destacam: Ruby e Python. O interessante que ambas, inclusive, surgiram antes do Java.  Seus pontes fortes são sua alta produtividade através de abstrações em alto níveis, sintaxe doce (suggar sintaxe) – um forma de escrever sem grandes amarrações (ponto-virgula, chaves, etc) e extremamente legível -  e natureza dinâmica (podemos alterar o comportamento dos objetos, funções e módulos em tempo de execução de forma ultra simples – meta classes é um exemplo). Outro aspecto relevante é o fato dela serem, realmente open source – software livre : ambas são mantidas e evoluídas pela comunidade não existindo uma entidade, diretamente, responsável por controlá-las.

A primeira questão que fica é : será possível comparar Java a Ruby ou Java a Python ? Dependo do contexto e das métricas.  Podemos dizer que, considerando a sintaxe legíveis e concisas, Java  “perde” pois tem uma escrita mais rígida, formal e menos “humana”. Exemplo

Ruby

10 times do put “Andre Fonseca” end

Java

for (int i = 0, i < 10, i++){

System.out.println(“Andre Fonseca”);

}

Porém essa “fraqueza” do Java lhe confere característica que em outro quesito a torna mais interessante escolha que as demais. Se agora considerarmos, questões como consumo de memória e recursos de máquinas, um código Java ganha com uma boa margem dos demais. Mesmo pensando em Cloud Computing, onde um aumento de demanda pode ser resolvido com acréscimo de máquina, Java parece se mostrar economicamente melhor pois precisa de menos máquina para atender a uma mesmo disponibilidade.

Sendo assim uma conclusão que podemos chegar seria que grande parte das comparações e suas conclusões são inúteis e pouco esclarecedoras. Cada um aborda no contexto que favorece a sua preferida e no final todas são melhores do que as demais, em algum aspecto que seja.

Outra coisa que é extremamente vaga é quando se afirma que “tal coisa não escala” .   O fato de um aplicação ser capaz de aguentar um crescimento de acesso ou uso está muito mais ligada a sua arquitetura do que na tecnologia usada.  Se fosse assim, todas aplicações de massa (sites, portal de jornais, twitter, etc) deveriam ser feitas em assembly pois assim seriam ultra otimizadas.  Um bom exemplo é que vários sites e/ou ferramentas de grande acesso foram feito em Ruby ou Python e funcionam perfeitamente (com alguns problemas que são normais).

A segunda pergunta é se existe uma escolha perfeita e definitiva. Diante a tudo dito até aqui, fica fácil concluir que a resposta coerente seria NÃO . Existe sim, uma escolha coerente com o contexto do desenvolvedor, usuário, recursos, etc.  Qualquer aplicação pode ser feita em Java ou Ruby ou Python, cada uma terá seus pontos fracos e fortes. Cabe ao desenvolvedor colocar tudo isso de forma ponderada e ver quem lhe trará mais lucro frente ao objetivo almejado.

De forma conclusiva e de acordo com os fatos expostos, fica claro que não existe comparação definitiva, nem justa, pois sempre dependerá do contexto e do objetivo desejado. Além disso, Java começou lenta e ruim e foi melhorando com o uso, sugestões da comunidade, entre outras coisas, nada impede que um mesmo esforço ocorra em Ruby e Python e daqui a alguns anos elas estejam tão “corporativas” quanto Java é hoje.

Hoje, numa das lista de discussão por que participo, um dos integrantes postou uma pergunta que recebeu de uma outra pessoa (confuso isso, não).  A pergunta ou relato, era que ele trabalhava antes numa pequena empresa onde tinha um ambiente amigável, livre para experimentar, que era reconhecido, etc. Por motivos não revelados, disse que saiu dessa empresa e foi para outra empresa, desta vez, grande. Lá, sentiu um clima completamente diferente:  as pessoas pouco amigáveis,  pouco espaço para inovar ou usar algo mais novo e por aí seguia em sua lamúria. Por fim terminou perguntando qual era a melhor: Pequena ou grande empresa ?

Essa é uma pergunta nada simples de responder pois envolve muita mais do que um simples “é esta ou aquela” , depende muito do contexto e do que a pessoa que está perguntando quer para a vida profissional (e pessoal também) . Isso porque, para uns uma grande empresa com suas características é o objetivo e para outros pode ser justamente oque ele não quer. E isso, para aumentar a dificuldade, pode mudar ao longo da vida e de outros fatores como filhos, casamentos, etc.

Mas, como diz Maquiavél em seu livro “O Príncipe”, devemos sempre nos posicionar pois neutralidade não é uma boa coisa.  Por isso, ai vai uma tentativa de responder algo que jugo justo e bom para a pergunta do rapaz.

Pequenas empresas, por incrível que isso soe aos seus ouvidos, elas são pequenas (imagino as pessoas rindo agora). Por serem pequenas, elas não tem margem para ter gorduras em seus orçamentos, otimizando ao máximo o uso de seus recursos e pessoas.  Com isso alguns aspectos, que acredito sejam relevantes, aparecem:

• o dono da empresa está ali do seu lado e convive com a realidade de todos os “setores” da empresa. Logo o reconhecimento dele pelo trabalho realizada é mais simples de ser feito ou notado

A distancia entre os funcionários e o dono da empresa é praticamente nula. Muitas empresa, inclusive, o dono faz parte da equipe. Assim, devido a esta convivencia estreita, fica mais fácil para ele estar a par de tudo que acontece e de verificar, in loco, o comportamento de seus contratos. Não existe intermediário, não existe gerente que tenha a sua visão pessoal da coisa… o dono está ali na cadeira do lado vendo o seu rendimento e dedicação.

Isso pode ser bom, como ruim ao mesmo tempo. Por esta ao lado ele pode reconhecer o esforço mais rápido;  o lado ruim que isso gera um desgaste que pode, por besteira, levar a um julgamente precipitado.

• O fato de serem pequenas e possuirem esta estrutura “magra”, elas são extremamente ágeis: mudam de direção com maior facilidade e são mais amigáveis a novidades de processo, tecnologia, etc.
• Não existe muita margem para setorizar as coisas, logo todos acabam fazendo um pouco de tudo:

Não existe uma área para cuidar dos servidores, outra para testar e por ai vai … existe o cara que é desenvolvedor que por vezes vai meter a mão no servidor e acertar a configuração do servidor de email, acerto o banco de dados, instalar o JBoss, etc. Isso dá uma “liberdade” muito grande para inovar e experimentar já que você que vai cuidar de tudo isso mesmo.

Para as grandes empresa posso dizer que:

• Devido a seu imenso tamanho, o dono da empresa não tem como estar ao seu lado, com isso, o reconhecimento da empresa é feito pelo seu “chefe” direto. Com isso, é muito comum encontrar dentro delas realidade diversas pois o clima, processo, e outras coisa de um setor depende do seu gerente (coordenador ou qualquer outro nome que queira)
• Empresas grandes precisam de diretrizes e culturas rigidas, senão ficará uma loucura internamente. Por isso, são pouco tolerantes as novidades, principalmente tecnologicas. Tudo tem que ser aprovado por comites que nem sempre (99% do casos) são formados por pessoas com interesse de fazer algo.
• Tudo é setorizado pois, devido a quantidade de coisas não tem como o desenvolvedor fazer um pouco de cada, como nas pequenas empresas. Isso é bom pois acaba tendo especialistas em assuntos e a oportunidade de aprender é grande mas por outro lado a liberdade de fazer algo diferente é menor.
• As chances de se destacar são poucos pois a visibilidade é pouca. Por isso existe grande competição interna, tendo pouca margem para um ambiente amigavel.

Eu particularmente estou num momento que prefiro empresas pequenas a médias. Nelas existe maior flexibilidade e maior espaço para desenvolver o trabalho que quero: crescer, aprender, inovar e etc.
Empresas grandes por outro lado, tem mais força para investir no profissional por meio de cursos, formações internas, palestras e etc. Além disso, dentro de empresas grandes, você tem muita gente com quem pode juntar para aprender.
Tudo depende do que quer para sua vida nesse momento.

Outra coisa importante: Quem faz o seu ambiente é você.

Por isso, se as coisas estão ruins, transforme-as. Pelo menos tente. Converse com o seu pessoal, promova encontros fora do trabalho para quebrar o gelo… Divulgue material das coisas que você acha interessante… Divulgue eventos…. Mostre que existe um outro jeito interessante de fazer as coisa que dá resultado. Faça um protótipo e mostre para o seu chefe. Transforme a realidade a sua volta. Caso isso funcione depois de um certo tempo (este tempo você decide pela sua disposição) ai sim saia e vá para lugar melhor, mas saira de cabeça erguida pois tentou fazer do mundo um lugar melhor.