Platão

Platão considerava mais importante filosofar sobre as formas do triângulo do que observar o mundo à sua volta. Isso se dava porque ele considerava o mundo natural inferior ao mundo das idéias.

Aristóteles

Aristóteles, discípulo de Platão, deixou sua marca na história da ciência, porque discordou do seu mestre. Ele foi um dos primeiros a ir contra o desprezo filosófico pelo mundo natural.

Aristóteles dedicou à natureza uma atenção metódica e um requintado registro de suas observações.

Também usou sua lógica recém codificada para estudar a causa de cada coisa que observava e assim dar-lhe uma explicação racional e consistente. A partir dele a observação científica ganhou seu caráter particular, que a diferencia do olhar apenas curioso com que os homens sempre contemplaram o mundo. A observação científica é metódica, ou seja, segue um método, regras que definem o que, como e quando observar de modo a obter o máximo de informação e aprendizado sobre o que se observa.

Mas faltava algo no modo de fazer ciência de Aristóteles. A observação metódica e a conclusão racional, por si só, não garantem uma explicação correta sobre as causas e mecanismos dos fenômenos, uma vez que não podemos ter certeza se todos os fatores que influenciam o fenômeno em questão foram devida e corretamente observados e analisados.

É aqui onde entra Galileu. Com sua atitude, Galileu introduzia ao método científico uma de suas mais indispensáveis características – não basta uma boa observação e explicação de um fenômeno, é preciso que experimentos metódicos validem esta observação e explicação.

Galileu Galilei

Com Galileu a ciência ganhou um requisito a mais, agora ela se tornou experimental. O conhecimento a partir dele é obtido de modo empírico, ou seja, pela observação e experimentação do que percebíamos na natureza.

Foi com esta convicção que Galileu desafiou outro dogma aristotélico, a idéia vigente na época de que a Terra era o centro do universo e que o sol e as estrelas giravam em torno dela (geocentrismo). Esta idéia não era de Galileu, pois já havia sido anteriormente proposta de modo elaborado por Copérnico e Kepler. Porém com suas experimentações ele conseguiu comprovar a falha na teoria geocentrica e apesar de ser silenciado na época pela autoridade da inquisição, suas idéias permaneceram até hoje e cada pessoa que trabalha em uma instituição de ensino superior atualmente deve ter pelo menos a consciência que todo esse formato atual de ver o mundo foi bastante influenciado por Galileu.

Depois disso o homem passou a tomar consciência que o mundo não gira em torno dele, que não passamos de poeira se formos comparados com o universo a nossa volta, que dependemos de diversos fatores que muitas vezes nem imaginamos para continuarmos vivos.

Depois dessa introdução vamos ao que interessa. Se não passamos de poeira cósmica então vamos pelo menos ter uma noção do que a poeira é capaz, seja no ambiente de uma instituição acadêmica ou na sociedade em geral.

Devemos lembrar que uma única partícula de poeira, pode danificar todo o sistema de armazenamento do disco rígido.

Vamos fazer uma analogia dessa partícula de poeira com os egos super-inflados dos profissionais que não sabem o verdadeiro significado do título e se deixam levar por aparência, estatus e se escondem atrás dos cargos (eu falo sobre isso no meu post: caindo na real sobre a carreira ).  Para piorar ainda mais a situação, existem algumas pessoas com espírito de porco, que não se esforçam para criar uma visão sistêmica (falo sobre visão sistêmica no post: chega de tanta reclamação)  e participativa. Esse tipo de pessoa só sabe reclamar de tudo ao redor e não faz nada para melhorar o que está ao seu lado.

Esse tipo de profissional tem a mesma característica nociva que a poeira tem quando está presente dentro do HD. Quando esse tipo de profissional é valorizado em qualquer instituição, o ambiente fica poluído, injusto e e desumano. Assim como Galileu teve que admitir coisas que ele sabia que não era verdade na inquisição, esse sistema passa a idolatrar profissionais por meio de métodos que não são comprovados empiricamente. Esse formato está preso à lógica aristotélica de que basta que faça sentido ou que tenha lógica para ser comprovado, deixando a experimentação de lado.

Atrazos podem acontece em um país devido essa visão míope, sem experimentação. Um caso aqui no Brasil é a tentiva de regulamentar a profissão de analista de sistemas , dizendo que só poderá ser exercída por quem tiver passado pela faculdade da área de tecnologia (ciência da computação e afins). Lembrando que houveram também outras tentativas.

Isso é um retrato da visão aristotélica ainda presente. Se colocarmos as idéias de Galileu para funcionar, facilmente detectaremos que entre os maiores profissionais da informática, estão os que estudaram por conta própria (autodidatas), que não se identificaram com o sistema engessado das universidades e também profissionais de diversas outras áreas como Física, Matemática e Engenharia (Esse argumento de profissionais de outras áreas e outros argumentos são detalhados nessa carta).

Uma lei dessa é um atrazo para o País, pois nivela por algo que não comprova capacitação e comprometimento profissional (título), nivela na maior parte das vezes por baixo e isso é um retrossesso.

Agora vamos voltar a falar um pouco mais sobre a poeira.

Se individualmente somos compovadamente insignificantes comparados ao que existe ao nosso redor então a única coisa que poderá nos fortalecer e nos dá um propósito maior é que as nossas relações sejam baseadas no respeito, na consciência de que não somos perfeitos, na consciência de que temos que fazer algo para mudar para melhor os ambientes em que frequentamos. Agindo dessa forma encontramos uma parte do sentido da nossa existência que tanto buscamos e passamos a nos sentir integrados, úteis e finalmente humanos.

Uma analogia que podemos fazer é uma duna na praia, um só grão de areia não poderia dar conta. A única forma de se conseguir a beleza natural de uma duna é por meio de milhoes de grãos em conjunto.

Dunas de Genipabu - Fonte: Sônia Furtado

Colocando esse paradigma para a instituição de ensino significa que todos os integrantes da instituição devem ser tratados primeiro como seres humanos e segundo pelas tarefas que estão executando. Você pode está pensando:  Cadê o título? O título não entra nesse paradigma, pois estamos usando o método de experimentação iniciado por Galileu. Então vamos continuar a discussão sobre experimentação.

Apesar do título servir para contratação no nosso país. Devemos nos lembrar do principal papel de uma instituição de ensino: preparar os estudantes para o futuro.

Baseado nessa premissa iremos detectar de forma contínua se os professores com os maiores títulos estão realmente preparando os alunos, construindo uma relação baseada na liderança, na participação ativa dos alunos, enfim, criando um formato mais humano de aprendizado.

Fazendo esse experimento podemos detectar até que ponto aquele profissional realmente está vestindo a camisa da instituição e está contribuindo para o seu crescimento. Passaremos do formato aristotélico de “Tenho o título portanto sou bom e o universo gira em torno de mim”. Para “Consegui minha titulação, porém isso quer dizer que agora minha responsabilidade com relação as pessoas e o ambiente ao meu redor aumenta, tenho que me comportar com respeito, tendo consciência de que sozinho não sou nada e preciso orientar as pessoas ao meu redor para que possamos crescer em conjunto.”

No exemplo que coloquei anteriormente da lei dos profissionais de informática, fica claro que ela não tem base na experimentação e tudo que não puder ser comprovado por experimentação é duvidoso e pode ser prejudicial para a nossa sociedade. No caso da lei é óbvio que ela nivelaria os profissionais de informática de nosso país por baixo, colocando gente incompetente (Obs.: Nem todos são incompetentes, o argumento é que o título não garante competência) para assumir cargos só porque elas possuem um pedaço de papel que não condiz com a realidade, já que a realidade só pode ser comprovada com a experimentação, aquela mesma que Galileu nos deixou de presente.

Quero repetir agora o título do post: Vamos honrar Galileu! Isso quer dizer vamos honrar suas idéias e questionar idéias enlatadas, vamos nos permitir e só aceitar algo depois de experimentações. Vamos tomar consciência que não passamos de poeira, que um único ser quando age de forma mesquinha, pode causar danos a todo um ambiente de trabalho, sociedade, mas que nossas forças em conjunto pode nos impulsionar para nosso crescimento como seres humanos.

Why the lucky stiff

Para finalizar quero repetir aqui uma frase do “why the lucky stiff” ou simplesmente _Why, que é um artista e um excelente programador, tiradas do seu twitter que foi deletado:

When you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

Quando você não cria coisas você acaba definido por seus gostos ao invés de suas habilidades. Seus gostos só reduzem sua visão e excluem pessoas. então crie.

Páginas pesquisadas:

História da ciência parte 1
História da ciência parte 2

Quero deixar bem claro que o vídeo de Richard é infinitamente melhor do que esse humilde post.

Eu apenas assisti ao vídeo algumas vezes, me foquei na imagem abaixo (última imagem do vídeo), e comecei a escrever o que vinha na minha mente a respeito dessas palavras-chave. Não é uma tradução do vídeo, é a minha forma de ver as palavras-chave que levam ao sucesso.

8 segredos do sucesso. Créditos para Richard St. John

Fique agora com o texto:

Vamos imaginar o sucesso como um percurso do ponto A para o ponto B.

Acabei de levantar da cama no ponto A e quero ser bem sucedido. O que devo fazer?

Nada começa sem boas IDÉIAS. Empresas e profissionais bem sucessidos começaram com boas idéias. Só que é preciso mais porque idéia sem ação é sonho. É preciso colocar a mão na massa! Sucesso é um sonho que se torna realidade e alimenta novos sonhos.

Já tenho boas idéias, mas tenho que me olhar no espelho um pouco para ter a certeza que no longo prazo eu ainda vou continuar trabalhando nessas idéias com empolgação. Se não houver PAIXÃO pela idéia, não haverá energia suficiente para mantê-la. Faça o que você gosta, que o dinheiro virá como consequência. Caso não possa fazer isso, lute até que você consiga fazer o que gosta. Somente o ato de lutar já dá satisfação.

Já sei o que eu quero e tenho paixão por isso, então vamos ver o que devo fazer durante a jornada:

Eu preciso ser muito BOM no que eu faço, para se destacar dos demais. Bom o suficiente para que ninguém me imite no curto prazo.

Para chegar a essa eficiência é preciso TRABALHAR duro, pois é a única forma de chegar lá e se manter lá. Já vi muitos casos de filhos que assumiram as empresas do pai sem esforço algum e deixaram a empresa com dívidas.

Não posso simplesmente executar as tarefas e ir dormir. Eu devo EMPURRAR minha mente e meu corpo para frente sempre, estar aberto a experimentações, procurando pontos de vistas diferentes, estar com uma mente sã em um corpo são.

No meio de tanta tarefa e informação é preciso manter o FOCO para continuar no rumo certo. Muitas vezes é preciso filtrar as informações e acompanhar somente o que for essencial, o ruído deve ser eliminado.

Em quase 100% dos casos você não terá frutos da noite para o dia. O seu objetivo será modificado e aperfeiçoado durante a jornada. O caminho está cheio de altos e baixos e é preciso PERSISTÊNCIA para suportar a estrada acidentada.

No início era só uma idéia e a paixão por torná-la real. Durante o processo utilizamos vários mecanismos para chegarmos ao objetivo, mas, de nada adianta se outras pessoas não gostarem do que estou fazendo. É preciso ter algo que alimente esse sistema e torne-o coletivamente sustentável. Esse ingrediente que falta é gostar de SERVIR. Gostar de servir implica em olhar e tratar o ser humano como um ser humano e não como uma fonte de dinheiro. Quando você gosta de servir, todo seu esforço será focado para algo que mudará o meio que você vive ou uma pequena parte dele para melhor. A partir daí seu sistema ganha vida própria, essa vida eu chamo de sucesso e finalmente chegamos ao pontos B.

por http://www.flickr.com/photos/52636849@N00/

O fato ocorreu em um colégio de ensino médio. Já vi a mesma cena em colégios públicos e privados: Certo dia, um professor do quadro escolar teve que faltar e por esse motivo uma professora teve que assumir a responsabilidade de dar aula em 2 turmas no mesmo horário.

A professora entrou na sala do 1º ano e fez o seguinte acordo: “Pessoal, eu terei que continuar a aula no 2º ano, mas vou deixar uma atividade com vocês e ninguém pode sair da classe. Quando eu retornar vocês poderão ir para casa mais cedo”.

Quando a professora retornou, percebeu que tinha 3 alunas na porta da sala, então ela pediu para que elas voltassem para o local delas e falou para a turma que, como eles não tinham cumprido o acordo de ficarem quietos em seu locais, todos teriam que ficar na sala a tarde inteira. Um aluno ainda questionou: “Professora, mas quem desobedeceu foram elas, porque teremos que pagar pelo erro delas”. A professora respondeu de volta: “Somente elas desobedeceram, mas meu acordo foi com todos vocês, e os demais que não estavam na porta erraram por omissão”. A conversa finalizou e todos os alunos foram punidos por causa de um erro cometido por 3 alunas.

Não entrarei no juízo de valor de apontar se a atitude foi ou não errada. Já que perante as leis vigentes, cada instituição é livre, dentro dos princípios morais, de utilizar regras e instruções próprias, para que possam dar conta de seus objetivos com efetividade.

Vou concentrar meus argumentos somente nas possíveis conseqüências que a atitude acima pode causar nos alunos em curto ou longo prazo.

Os adolescentes, em sua fase escolar, na maioria ainda são dependentes dos pais ou de algum familiar, é obvio que não se trata de pessoas autônomas, que podem responder pelos próprios atos. O bom senso universal e as leis do estado partem do ponto de vista de que eles precisam passar por um estágio de amadurecimento e instrução até que estejam prontos para conviver ativamente na sociedade.

A escola em certo sentido é um microuniverso que servirá como auxiliar para o amadurecimento dos jovens. E como todo microuniverso terá suas normas, regras de conduta, processos e etc. Só que, é muito importante que esse microuniverso seja o máximo possível coerente com a realidade externa (mundo externo à escola) para que o aluno possa ter uma preparação que não gere desconfortos quando, no futuro tiver que se deparar com a vida real do mercado de trabalho.

O que podemos constatar é que a atitude da professora de punir todos devido ao erro de uma minoria, não existe no macro-universo da vida real. Qualquer ambiente de trabalho no qual o aluno vá fazer parte no futuro segue no geral o seguinte padrão: “Elogios públicos, punições individuais e em particular”.

O ambiente produtivo do trabalho é sábio ao adotar esse paradigma, pois quando ocorre punições em público e pior ainda punições para todos em detrimento de uma minoria cria um clima de tensão e desconfiança no grupo, que pode chegar ao ponto de influenciar na saúde mental e emocional dos integrantes e conseqüentemente diminuindo produtividade, que é o objetivo geral de toda empresa. Já o outro quesito que é elogios públicos. Cria um clima de satisfação para o indivíduo que recebeu o elogio e também um clima geral de competitividade sadia, que é quando todos sabem que quem fizer um pouco mais, poderá ser o próximo a receber o elogio ou o aumento de salário. Claro que existem exceções a essa regra e determinadas empresas exageram nesse paradigma ao ponto da regra ser produtividade a qualquer custo, mas onde quero chegar é que essa é a regra em vigor e tem funcionado bem em uma boa parte dos casos.

Voltando para os alunos. Há uma tendência muito forte que eles sintam problemas de adaptações à futura entrada no mercado de trabalho, devido ter assimilado situações em sua fase de amadurecimento que não fazem parte dessa nova realidade. É uma mudança muito brusca. Não é gradual, nem complementar. É um paradigma oposto. Isso pode influenciar consequentemente na produtividade e na satisfação de ser útil para a sociedade. O ex-aluno pode criar fantasmas e equívocos como “todo aquele tempo a escola serviu pra que?”.

É importante relembrar que a professora deve ter autonomia e essa atitude foi coerente com a autonomia que ela deve ter, portanto o que foi feito mesmo que equivocado não deve ser motivo para qualquer reclamação com relação a atitudes passadas da professora. O que quero ressaltar aqui é um ponto de vista diferenciado que se passar a ser adotado poderá contribuir ainda mais com o papel da escola e poderá evitar várias situações constrangedoras nas classes e também evitar vários problemas de adaptações futuras dos alunos às regras da sociedade extraclasse.

Agora, será que ter autonomia significa fazer do jeito que a individualidade quiser? Será que não é importante que essa autonomia esteja baseada em princípios para um bem maior? Para criar um clima de justiça e equilíbrio na sala? Para preparar os jovens com normas coerentes com o dia-a-dia que ele enfrentará no futuro? Se olharmos minuciosamente para a atitude da professora de punir em público e fazer com que a maioria pagasse pelo erro de uma minoria, podemos ver que ela criou uma regra que nem sequer ela própria segue, caindo no ditado “Faça o que eu digo, mas não faça o que eu faço”, que contribui ainda mais para criar o ambiente hostil. Da mesma forma que ela corrigiu o aluno que reinvidicou justiça (punição somente para quem descumpriu a ordem) dizendo que o acordo dela foi com a classe. Ela também fez um acordo com o estado, na verdade um acordo contratual, e o acordo é o mesmo para ela e para todos os outros professores da instituição e de outras instituições. Só que quando um professor faz algo de errado a instituição não pune todos os professores pelos defeitos de um único, o punido é somente o que praticou o erro.

Ela afirmou também que os demais alunos foram punidos pela omissão. Um dos alunos disse que não iria fazer inimizade por causa disso. Essa atitude do aluno foi no mínimo sábia. Cada aluno está no mesmo nível hierárquico, por isso são chamados de alunos. Além de nenhum deles ter nenhum privilégio com relação ao outro, eles ainda estão em fase de amadurecimento das relações, então em boa parte dos casos não terão o bom senso necessário para lidar com as situações diversas gerando o mínimo de conflitos possíveis. É para isso que existe o professor, que além da instrução, ele é o responsável para criar o clima de equilíbrio e diminuir os conflitos internos da sala.  O aluno utilizou o senso de sobrevivência que todos humanos possuem, pois deduziu que ele ainda iria conviver por muitos anos com o outro aluno, e com o professor conviveria somente em momentos isolados. Outra possibilidade é que os alunos que desobedeceram tivessem um porte físico maior e por isso poderiam exercer algum tipo de influência abusiva sobre os demais alunos, conseqüentemente, por senso de defesa, preferiram se calar. O que nos leva para outro ditado: “Manda quem pode e obedece quem tem juízo”. A professora quando julgou por omissão, na verdade exigiu uma tarefa muito perigosa para a saúde emocional e mental dos alunos, pois essa tarefa de intervir no que o outro está fazendo estando no mesmo nível que o outro cria um palco para gerar conflitos, desde simples da sala de aula, até perigosíssimos como cobranças por dívidas a pessoas com má índole.

Tecnicamente a omissão foi da professora, já que a tarefa coerente que ela poderia ter feito seria a punição dos que realmente erraram. E por bom senso os que não disseram nada ela relevaria, pois eles estão somente exercendo o direito deles de sobreviver no microuniverso heterogênio da convivência humana. Ela se omitiu, pois colocou uma tarefa que era para ela fazer ao invés dos alunos. Omitiu-se por pregar uma atitude que sequer ela pratica no ambiente de trabalho que prega punições individuais. Omitiu-se porque as pessoas que servem de espelho para outras devem está constantemente procurando aprimoramento para que seu trabalho seja o mais eficiente e eficaz possível. Se não preparar o jovem para o futuro pelos limites da estrutura de cada colégio, que pelos menos não atrapalhe. É preciso evitar situações onde os alunos possam executar tarefas e receber conceitos que tirem sua criatividade, que dificulte a atuação de forma ativa no futuro dos mesmos na sociedade. Omitiu-se também porque só procurou ver o problema pelo ponto de vista dela, se ela conversasse um pouco mais com o aluno que reinvidicou punição somente para quem errou, poderia detectar talvez que o aluno não se manifestou porque além de está no mesmo nível político do outro, fisicamente fosse de porte menor o que poderia ser uma desvantagem em um confronto direto. Não somente a professora se omitiu, mas a instituição também se omitiu, pois está ajudando a propagar esse conceito equivocado que pode até aniquilar com o progresso de diversos alunos que ainda estão caminhando até chegar à fase autônoma.

Não queria chegar nesse nível de argumentos, mas vou colocar somente para reflexão: Da mesma forma que as pessoas de bem, não pagam pelos erros dos ladrões, estupradores, pessoas de má índole, pessoas que prejudicam as outras. Os alunos no micro-universo da sala de aula, também não merecem ser julgados por erros de uma minoria que não seguiram as regras da instituição.

Cabe aos professores, aos coordenadores, aos diretores, repensar essas atitudes na sala de aula, para que a escola possa aprimorar o seu papel de preparar os jovens para o futuro, ou em última instância, de pelo menos não atrapalhar o jovem em sua caminhada.

por: www.flickr.com/photos/kamshots/

• acidentes causados por falar no celular enquanto dirigimos.
• pressão alta, que é uma doença facilmente tratável, mas desde que façamos checkups para detectar
• tapetes em casa de idosos em que o escorregão pode ser fatal, entre outras coisas que vocês podem ver lendo a reportagem.

Agora volto para o tema do nosso post: será que, de forma semelhante aos acidentes fatais, perdemos clientes por causas que podem ser facilmente evitadas?

Vou compartilhar com vocês alguns casos que passei recentemente:

1. Aluguei um apartamento e o encontrei em condições deploráveis, aleguei que não tinha condições de continuar no apartamento, mas o dono do prédio não devolveu o calção e ainda falou que o problema era meu. Sorte minha que o corretor viu o meu prejuízo e fizemos um acordo em que ele me devolveu uma parte justa do dinheiro, ficarei eternamente grato a esse corretor, me viu primeiro como ser humano e consequente como cliente.
2. Aluguei outro apartamento e fui muito bem atendido. A secretária me falou que eu receberia o contrato em no máximo uma semana e por debaixo da porta. Passou-se quase o prazo do aluguel (1 mês) e eu precisei pegar o contrato na imobiliária.
3. Eu pedi por telefone uma água mineral de marca X  e o mercadinho mandou marca Y, para não ser indelicado aceitei, só que eles repetiram o mesmo erro pela segunda vez.
4. Chamei um taxi que faz viagens inter-municipais e o taxista não podia naquele dia, mas me indicou outro taxista que podia. Esse outro me ligou e falou que quando chegasse perto do meu bairro ligava para eu avisar a ele os pontos de referências. Só que, ele deu só um toque de telefone e na segunda vez quando atendi a ligação foi a cobrar, desliguei na mesma hora. Por fim fez uma ligação normal e finalmente me pegou no local que avisei.
5. Entrei em uma loja em um shopping center e uma atendente repetiu pelo menos umas 4 ou 5 vezes se eu queria fazer o cartão da loja, claro que ela era paga para conseguir mais pessoas aderindo e não para atender bem e me dar o que eu estava precisando.

Para prosseguirmos, vou colocar alguns pontos que Edmour Saiani coloca como essenciais em seu livro Ponto de Referência, para tomarmos como parâmetros:

• ótimo atendimento e oferecer o que o cliente realmente esteja precisando
• prioridade sempre nas pessoas e nos serviços que possam ser úteis para essas pessoas
• gostar de servir e ver o cliente satisfeito ao invés de querer dinheiro a qualquer custo.
  

O outro parâmetro que posso colocar são dos princípios imutáveis e atemporais que devemos ter para ganharmos confiança e enfrentemos as diversidades diárias, eles já foram citados no meu post sobre o review do livro Reinventando você de Carlos Alberto Júlio:

Justiça, coragem, serviço, humildade, integridade, dignidade humana, contribuição, crescimento, empowerment, alinhamento de idéias e criação de valor.

Por motivos didáticos vou resumir todos esses valores com a expressão: Gostar de servir. Já que quem gosta de servir e é reconhecido por suas ações, com certeza possuem todas essas características e as deixam transparecer no seu dia-a-dia. Gostar de servir é uma foto da essência do ser, não é algo superficial.

Agora vamos voltar para as situações e detectar a intensidade delas:

• O primeiro caso é o mais grave, o apartamento em um estado inabitável e o dono com sua visão imediatista perdeu um cliente pelo resto da vida, além de ganhar uma fonte de propaganda negativa também pelo resto da vida.
• O segundo caso, a atendente criou todo um clima de sonho, de ótimo serviço e não cumpriu com o prometido, me deixando frustrado por algo que seria facilmente resolvido, somente entregar o contrato no local e período que foi combinado. Porém ela percebeu a falha e contornou, sem que eu falasse nada, com serviços diferenciados, quando resolveu um problema que estava tendo com energia de imediato. Ela conseguiu me reconquistar.
• O terceiro caso, a loja de conveniência se “queimou” por R$3,50, que é o valor da águar mineral. Não custava nada dizer que não tinha. O dono preferiu seguir a linha do “se colar colou”. O resultado é que eu facilmente fui atráz de outra loja que vendia a marca de água que eu queria.
• O quarto caso, ficou claro que o taxista estava querendo economizar a qualquer custo fazendo a ligação à cobrar. Essa é provavelmente a última viajem que faço com ele.
• O quinto caso, a moça não tinha culpa, o sistema da empresa a obrigava a seguir metas que são muito prejudiciais para própria empresa. Eu acho que se eu for bem atendido, tiver serviços adicionais e for conquistados pela empresa, naturalmente vou querer procurar esse cartão da empresa. Eles estão colocando a “carroça na frente dos bois” e isso gera problema no longo prazo.

Claro que trata-se de pouquíssimos casos (5 exemplos). Ao invés de uma pesquisa de 20 anos como Jan Garavaglia fez. Portanto é impossível dar uma resposta definitiva e efetiva.Quem sabe eu consiga, no futuro saber opiniões mais detalhadas com Edmour Saiany, Fred Alecrim (faz parte do time da Ponto de Referência em Natal-RN) ou com Carlos Alberto Julio.

Mas o que já podemos constatar nesses casos é que podemos perder clientes por relapsos, esquecimentos e também por causas mais graves que estão na essência do ser humano. Nesses 5 exemplos a maior parte foram falhas graves em que faltava valores essenciais como honestidade, compromisso, respeito e profissionalismo. Resumindo faltou o gostar de servir.

Mesmo em tão poucos casos é possível fazer boas escolhas. Eu, se tivesse na condição de empregador, contrataria:

• a moça que cometeu falhas superficiais, mas contornou com serviços uteis.
• o corretor que me chamou para negociar uma saída que ficasse justa para os dois, pois ele também tinha saído no prejuízo.
• a moça que me ofereceu o cartão. Não contrataria de imediato, mas daria uma chance já que a culpa maior é do sistema que ela é obrigada a seguir. É possível que se o sistema for modificado ela também modifique se coincidir com sua essência.

A essência do ser não muda do dia para a noite, portanto o importante é contratar o sorriso (Walt Dysney), ou a generosidade e a gana (Edmour Saiani) e treinar as técnicas para eliminar os problemas superficiais, os lapsos, equivocos e falta de conhecimento.

Obs: Esse post é além de inspirador, muito esclarecedor, faz com que coloquemos novamente nossos pés onde eles precisam estar, que é no chão. Mas mostra também que podemos conseguir diversas coisas legais tomando as decisões certas e fazendo a única ação benéfica e sustentável do mundo da programação que é de ler, escrever e compartilhar código. Se algum trecho da tradução poderia ficar melhor podem mandar sugestões de mudança, o texto original você encontra aqui, fiquem agora com o texto traduzido:

Oi a todos, sou Chris Wanstrath, e vou te ensinar como se tornar um desenvolvedor Rails famoso. Um Ruby rock star. Um programador ninja. Não é difícil, apenas foque-se como um raio laser e tenha um pouco de paciência.

Devo dizer de antemão de que você não precisa se preocupar com qualquer habilidade de programação ou dez mil horas de prática. Isso não importa – é fácil de falsificar.

Então! A primeira coisa que você precisa é um blog. Mas não de qualquer blog. Você precisa de um blog com personalidade. Não importa se a personalidade do blog seja compatível com a sua própria personalidade.

A parte mais importante de qualquer blog é o nome. Claramente. Não pode ser “blog de João”. Ou talvez possa -, é que poderia ser retrô neste momento. Mas você entende o que quero dizer. Não escolha um nome que não te deixe feliz, pois se você fizer a escolha certa, você nunca vai ouvir o final da mesma. (o nome pode ser bom, mas se não te deixa feliz você acaba deixando de lado). É como escolher um nome de uma banda. Ou dando um nome para uma criança. Certifique-se de que é algo que as pessoas irão lembrar.

E tente não se tornar demasiado Railsy. Isso é limitante – faça o seu próprio. É o seu blog, apesar de tudo.

Eu não deveria ter de dizer esse próximo passo, eu odeio dizer isso, mas tenho que dizer: nunca use um template de blog default. Isso é um tiro no próprio pé.

Veja por quê: você eventualmente publicará conteúdos de qualidade no seu blog. Não de imediato, não se adiante. Mas você vai escrever alguns posts realmente bons. Eles serão linkados no Hacker News e Reddit, eles serão “tweetados” e guardados no delicious, e, se tiver sorte, você receberá uma menção em um ou dois podcast.

A primeira vez que alguém visitar o seu blog, se o conteúdo é bom o suficiente, ele aprecia isso. Talvez ele adicione aos favoritos dele. Em seguida, ele passará ao próximo item no leitor de feed.

A segunda vez que a mesma pessoa visitar o seu blog, se o design é único e a personalidade brilha através do conteúdo, ele vai lembrar. “Ei. Eu estava aqui antes. Foi bom!”

Agora não sei exatamente quantos posts de qualidade você vai precisar porque vai depender de cada indivíduo. Alguns se conectam imediatamente. Eles não têm vergonha. Outros são mais lentos – eles fazem você trabalhar por isso. Três, quatro, talvez cinco posts maravilhosos antes deles se conectarem. Mas eles vão conectar.

A idéia aqui é associação – se o seu blog usa um template sem identidade, ninguém vai lembrar que eles estiveram lá antes. Que leram um bom post nele. Você está lutando uma batalha difícil.

Gaste tempo com o design. Talvez contratar alguém, faça alguns favores para um amigo designer, não sei, você vai descobri.

E quando você fizer isso, você terá um nome matador e um design elegante. Bom começo.

Agora para as personalizações. A barra lateral, o cabeçalho. Essas coisas essenciais.

Se você vai colocar uma lista de blogs que você gosta na barra lateral, e eu não colocaria, você tem que ter muito cuidado. Se os blogs são muito populares, as pessoas vão pensar que você é um “Maria vai com as outras”. Se eles são muito desconhecidos, eles podem pensar que você está com má companhias. É melhor estar seguro e ignorar completamente a coisa toda.

Na verdade eu só mantenho a barra lateral escassa, muito escassa. Sem tag clouds ou comentários recentes ou posts recentes. Talvez apenas o arquivo, que cria uma lista mensal. Listar os projetos de interesse pode ser bom.

Ah, e seu endereço de email. As pessoas vão querer enviar email para você.

Mas como eu disse, escasso. Não se distraia do seu conteúdo.

E nunca use anúncios Google – você vai eventualmente querer aderir a uma rede de anúncios patrocinados. Os anúncios do Google apenas desvalorizam o bem (blog).

O cabeçalho é importante porque é a primeira coisa que as pessoas veem. Uma foto sua é provavelmente melhor. Algo especial. Mas se você não pode encaixá-la no cabeçalho, a barra lateral funciona igualmente bem. Lembre-se: as pessoas têm de reconhecer você, saber que você é o João de “blog de João”.

Quanto ao conteúdo, você precisa decidir sobre o seu perfil. Você deve fazer uma lista de dez ou mais famosos desenvolvedores Rails, talvez em uma planilha, e escolha um adjetivo que descreva cada perfil deles. Vá até a lista escolha a combinação que funciona para você. Lúdico e espontâneo? Profissional e inspirador? Ofensivo e verborrágico? Escolha duas características que você acha que pode ter sucesso. Escreva elas. Este é agora é o perfil de seu blog.

A etapa final, antes de blogar, são as regras. Você precisa estabelecer diretrizes para o seu blog, as regras sobre o conteúdo. Se Hashrocket começa a falar de Scala, você pode aderir a controvérsia? Você pode postar sobre o grande e novo cliente Twitter que você baixou? E sobre suas experiências com o Android SDK? Você está centrado no código, a comunidade, suas observações, ou truques esotéricos?

(Eu ficaria longe de truques esotéricos como competência central mas ocasionalmente entregue-se ao desejo a fim de manter a sua credibilidade. Mas isso é só comigo.)

A coisa importante sobre as regras é que ajudam a estabelecer a coerência. Você não quer postar sobre uma elegante biblioteca uma vez e nunca mais mencioná-la novamente. Isso confunde as pessoas. Eles desejam algo estruturado.

Dê isso a eles.

Ok, com tudo o que disse, podemos começar a blogar. Mas não estamos realmente blogando ainda. Estamos apenas praticando. Todo dia você precisa escrever um post. Não importa sobre o que. Ninguém vai lê-los. Mas você precisa práticar a escrita e aperfeiçoar seu tom. Dê ao seu blog uma personalidade.

O que postar? Qualquer coisa. Em vez de apenas fazer um Gist seu belo pedaço de código, post sobre isso no seu blog. Adicione uma pequena história de fundo.Mas não fale continuamente sobre ela. A menos, claro, que seja o seu tom, seu perfil.

A grande coisa sobre como iniciar um novo blog é que você pode voltar atrás e olhar para antigos Gists,  plugins antigos que você escreveu, tarefas rake malucas, e fingir que eles são totalmente novas. Escreva. Faça um post. Trata-se de algo novo para qualquer outra pessoa.

Outro truque bom é olhar o que outros blogueiros estão fazendo, bibliotecas populares ou técnicas que foram pioneiras e melhorar as mesmas. Dessa forma eles fazem a maior parte do trabalho, mas porque você fez um pouco melhor, você pode conseguir alguma atenção deles.

Fale sobre testes. Lamente a falta de alguma coisa. Talvez até mesmo inicie algum problema com o código de outro blogueiro. Ele não funciona para você, por isso é uma porcaria.

Após algumas semanas podemos começar a fazer algo sério. Mas, entretanto, o que você vai fazer sobre a sua conta no Twitter?

Você tem uma, certo? Bem, você não vai querer “tweetar” negligentemente postagens do seu blog – Isso é um enorme fora. E você não quer “tweetar” que você apenas começou um blog, porque não há nada lá e é uma oportunidade perdida.

Em vez disso você poderia mudar o design do seu Twitter (o pano de fundo, cores dos links, tudo isso) para corresponder ao seu blog. Faça-os cumprimentar um ao outro. Enfeite-o para o sucesso. E seja legal.

Dessa forma você não está apenas sendo um desenvolvedor Rails aleatório, você é o autor de “blog de João”. Você é que é João. Certifique-se que o seu avatar tem o seu rosto, também.

Na verdade, por que não usa seu Photoshop e faz um daqueles backgrounds sociais para a sua conta Twitter? Você sabe o que estou falando – com todos os links que você pode apenas ler e certamente pode não clicar. Esses fundos permite que as pessoas conheçam sua idéia de negócios e como encontrá-lo de forma conveniente.

Suas mensagens do Twetter provavelmente seguirão o tom do blog, mas, e esta é a parte divertida, aqui você pode quebrar as regras. Permita que as pessoas saibam algo sobre você. Como num reality show.

De qualquer forma, vamos adiante. Você está de pé, você está “twettando”, você está “blogando”, você está se sentindo bem. Hora de atacar.

Sua primeira postagem que você realmente acha que é bom, ponha-o lá fora. “twette” sobre ele, publique-o em sites de notícias sociais, lute para conseguir uma relação no Rubyflow. faça isso de manhã cedo em um dia da semana, horário padrão da costa leste (USA e Canadá), porque as pessoas adoram se refrescar com Reddit no trabalho.

Mas não esperem muito. Não há tal coisa como sucesso em uma noite. Temos ainda muito trabalho a fazer. Uma forma de obter visitantes e leitores é liberar códigos simples, úteis de forma resumida e diretamente em um post do blog. Mostre às pessoas o problema, mostre a solução, diga como instalá-lo e forneça um meio para fazer o download.

Outra forma é discurso retórico. Mas você tem que fazer isso muito.

No que diz respeito à identificação e liberação de código útil e simples, não se gasta muito tempo pensando nisso. siga seu dia, sua rotina normal, mas mantenha um olho para as coisas que te deixa aflito. Coisas que deixam seus colegas aflitos.

Um idiota mecheu no seu código de produção? Repetição e erro tendem a ser práticas seguras? Bug na autenticação do plugin que você está usando?

Mantenha os olhos abertos e, quando você identificar um ponto de aflição, algo que provoca atrito no seu fluxo de trabalho, anote. Armazene em algum lugar.

Mais tarde naquela noite você pode se servir com um copo de vinho, talvez um copo de uísque, sentar-se no sofá e escrever uma solução. Mantenha a solução simples e certifique-se de que você pode completar a biblioteca ou o plugin em uma noite. Em seguida, escreva uma post no blog e publique.

Limpar e repetir.

Se algo te causa dor, provavelmente causa dor em outra pessoa também. Somos todos desenvolvedores Rails  com tarefas muito similares. Bem, a maioria de nós.

Eventualmente, você vai tirar a sorte grande: algo simples que poucas pessoas querem usar. Mantenha-o, aceite patches, e siga em frente.

A medida que você ganhar mais confiança, você pode começar a procurar problemas e soluções mais ambiciosas. Você conseguirá um reconhecimento melhor.

Agora você está pronto para o circuito de conferências. RubyConfs locais, encontros em sua cidade, e no Santo Graal, RailsConf (No Brasil: Rails Summit Latin America). Abrace um projeto sério e fale sobre ele. Publique o progresso da atualizações. Mas não se esqueça de manter o seu tom e seguir as regras. Vá para os coffe brakes e conheça pessoas. Permita que eles saibam que você é o João de blog do João. Nunca tire seu crachá.

Continue postando com consistência. A maioria das pessoas não sabem a diferença entre prolífico e profundo. ambas as palavras compartilham muitas letras. Eles apenas querem algo interessante para ler, e muito disso.

Acompanhe o que todos estão dizendo sobre as seus posts no Twitter, delicious, e FriendFeed. Você não tem que responder, mas eu buscaria freqüentemente seus posts em todos estes serviços. Verifique algumas vezes em um dia.

Se você contribuir para Rails em si, que é enorme. Outros desenvolvedores famosos de Rails vão começar a notá-lo. Mesmo com comentários em blogs – especialmente os dez na sua lista. Você manteve essa planilha, certo?

Uns poucos meses disso e você estará assinando autógrafos, beijando bebês, indo a boates caras – vivendo uma boa vida.

Todo mundo vai saber o seu nome. Editoras estarão te enviando livros, pedindo-lhe para escrever no blog sobre eles. Você será convidado para falar em conferências. Será reconhecido na rua. Recrutadores vão ocupar toda sua caixa de entrada. Coisas que você disser serão significativas. Seu blog será patrocinado. Talvez você até escreva seu próprio livro.

E, claro, você vai ter de sair com os famosos. Agora você é um deles, depois de tudo.

Parabéns.

O problema é que ser programador Rails famoso não é o mesmo que ser um bom programador Rails. Qualquer pessoa pode se tornar um programador Rails famoso. Faça todas as coisas que eu disse. Boom, garanto que funciona.

Pessoalmente, eu olho para os bons programadores. Eles não se preocupam com a sua contagem de subscrição do RSS, eles blogam como complemento. Pessoas que não estão preocupadas com quantos seguidores no Twitter  possuem e trabalham nos seus projetos todas as semanas, porque adoram fazer isso. Que contribuíram para o Rails por anos por paixão e não são excessivamente preocupados com a divulgação de suas vidas.

Pessoas que se preocupam com código, primeiro e acima de tudo.

Há sempre conversas sobre colocar apelidos em IRC ou Twitter nos crachás das conferências, assim você pode identificar as pessoas que você conheceu on-line, mas nunca pessoalmente. Porque é que simplesmente não ignoramos isso e colocamos em seu lugar o projeto favorito que você tenha contribuído?

“Você contribuiu para Rack? Isso é ótimo, eu amo Rack. Talvez possamos ser amigos.”

“Você trabalhou na Webrat? Pode por favor explicá-lo a mim?”

Pense sobre isso – você conhece as pessoas envolvidas no seu favorito RubyGem? Seu plugin mais usado?

Eles são provavelmente as pessoas que você vai querer estar junto delas.

Código, estou compreendendo, é o fio comum que une os desenvolvedores. Não é pelo blog ou mensagens de erro propositais (trolling) ou pela procrastinação, e sim porque nós amamos o código.

Trata-se de leitura, escrita, e compartilhamento de código.

E quanto mais eu blogo, envio mensagens falsas (troll), e procrastino, penso que o código me trouxe a fortuna maior. O maior retorno sobre o investimento com o menor risco.

Depois que saí da faculdade, eu trabalhava com PHP em uma loja fazendo aplicações de logísticas de entrega. Éramos os intermediários entre transportadores independentes e as grandes empresas como a Kmart. Os transportadores deveriam se registrar no nosso site, dizer que iam estar em Delaware no dia 3 de maio, e que eles estão a caminho de Denver, em seguida, eles obtém informações sobre transferências ao longo do percurso escolhido. Eles poderão, em seguida pedir um preço maior no trasporte ou aceitar o valor estipulado, tudo através de nós.

Foi uma aplicação bastante complexa e duas coisas que estavam faltando: controle de versão e constantes. Não havia controle de versão, de modo que você tem coisas como main2.php e compute_radius_of_from_shipment7.php espalhados ao redor. Junto com as versões de 0 a 6 desse mesmo arquivo, no mesmo diretório. Verdadeiramente doloroso.

Não havia constantes e nenhuma configuração, de modo que o código-fonte estava preenchido com números mágicos. Se quiser fazer um ajuste em qualquer um dos nossos algoritmos, você tinha que encontrar o código que fez o processamento e alterar alguns números de forma manual. Esperávamos esperançosamente que os números estivessem corretos.

Naturalmente, a primeira coisa que fiz foi institucionalizar o Subversion. Rei dos sistemas de controle de versão.

A segunda coisa que fiz foi extrair os números mágicos e colocá-los em arquivos de configuração. Na época, nós faziamos códigos em PHP que acessavam arquivos de configuração .ini. A maior parte do que se precisava era suportado, e eu estava encantado porque o PHP vem com uma biblioteca que acessa e entende arquivos .ini.

Este sistema funcionou bem, mas quando eu comecei mexer com Rails Eu fiquei encantado com o YAML. Tão limpo, tão poderoso. Havia o Syck, uma extensão em C escrita por _why, mas era apenas isso: uma extensão C. Eu não sabia muito sobre carregamento de código C em PHP, e ainda menos sobre como fazer isso em nossos servidores de produção.

Então eu comecei a escrever um parser YAML em PHP, no meu próprio tempo. Como uma homenagem a Syck, eu a chamei de Spyc – SPYC – uma Simples Php Yaml Classe. Foi meu primeiro parser, era stateful (mantinha o estado no decorrer da utilização). Não dei suporte a tudo do YAML, mas ele suportava as principais funcionalidades – dumping e o load. As partes boas.

Me debrucei nele e em pouco tempo estávamos utilizando YAML com grande sucesso na minha empresa. Naturalmente, eu fiz o upload do código para o SourceForge. Rei dos hosts de código-fonte. Meu amigo designer fez uma página e no primeiro mês Spyc foi um enorme sucesso. Eu juro que tinha, pelo menos, 70 downloads. SETENTA!

Isso foi um grande negócio.

Avançou rápido cerca de nove meses: o meu teletrabalho de telecomunicações virou um trabalho de verdade, e eu concordei em ir para Nova Jersey. Eu embalei meu carro, disse adeus, conduzi onze horas para Hackensack, trabalhei um dia no escritório, percebi que todos os meus colegas de trabalho eram completos puxa-sacos, entrei no meu carro e dirigi onze horas de volta para Ohio.

E é isso, eu era um desempregado que abandonou a faculdade sem terminar os estudos.

Não foi tão ruim – Passei muito tempo na piscina naquele verão. E eu passei muito tempo aprendendo Ruby e Rails.

Eu até comecei freelancer novamente. Afinal, eu estava totalmente qualificado. Eu tinha 8 anos de experiência de programação – Fiz algumas QBasic, quando eu tinha 12 anos. Eu estava certo que aquilo contava.

Mas verão acabou e eu precisava descobrir o que eu ia fazer com minha vida.

Como tinha sorte, no meio desse tempo, o web site de vídeo game GameSpot estavam contratando. E eu precisava de um emprego.

Eu não tinha idéia de onde era São Francisco ou o que os caras do GameSpot estavam procurando, mas eu fiz a requisição. Criei um novo currículo e fiquei a noite toda trabalhando no tema da carta. Até o momento em que eu tinha terminado, era uma página longa e bastante convincente.

Nela eu prometi me mudar para a Califórnia no dia seguinte, levando nada além de meu violão e Xbox comigo. Minha família ia me perder, mas eu estava pronto para sair, e eu estava faminto para mostrar ao mundo o que eu podia fazer. Pronto para aprender com os mestres.

A entrevista por telefone correu bem, eles gostavam que eu estava por dentro do mundo Macs e Ruby, e eu obviamente consegui o trabalho. A primeira vez que pus os pés na Califórnia foi quando eu voei para para procurar um apartamento com meu pai.

Minha experiência profissional não foi o que fez com que eu conseguisse o trabalho. Eu tenho certeza que a minha carta tinha algo a ver com isso, mas a minha curta carreira na logística de transporte foi menos que glamourosa. Eu só tinha uma coisa para mostrar a GameSpot – Spyc. Meu código foi livremente disponibilizado, tinha sido usado em produção, e funcionou. Eles podem fazer o download e brincar com ela, ou checá-la online. Independentemente de pensarem que era bom ou não, eles poderiam dizer que era limpo e bem organizado. Bom, talvez não, mas eu tinha um site e 70 downloads.

Consegui o emprego no GameSpot, na minha opinião o primeiro grande passo no caminho que me trouxe aqui, foi graças ao código. Código que eu escrevi principalmente para me divertir, para coçar minha própria coceira.

Então isso foi muito legal, e eu achei singular, até que aconteceu de novo. Enquanto eu estava trabalhando na GameSpot, fui fazendo mais e mais Ruby em paralelo. Eu tinha um projeto Rais open souce chamado Ozimodo, péssimo servidor de FTP denominado ftpd.rb (que eu usei como forma de aprender sobre threading), e um DSL parser de linha de comando chamado Choice. Para Choice, eu tinha um suite de testes completa (eu escrevi essa suite para aprender TDD) e uma homepage criada por RDoc no Rubyforge.

Quando CNET, mãe da empresa GameSpot, adquiriu Chowhound, eles decidiram reescrever o site em Rails. A partir do zero. Clássico. Eles trouxeram dois programadores Rails da Wayfaring.com e foram à procura de outro. Então me encontraram.

Mais tarde eu descobri o meu site RDoc, RubyGem, e a suite de testes provou aos caras da Wayfaring que eu era um “verdadeiro” programador Ruby. Eles queriam alguém animado com essas coisas, e eu certamente era.

Aquele foi um grande momento, porque paguei a minha viagem para a RailsConf 2006.

Conversas sobre código.

Se você não tem quaisquer projeto nesse momento, você deve gastar algum tempo aqui começando algo novo. Algo faça sentido para você, mas que ainda não tenha ao seu redor. Uma ideia que tem estado flutuando.

Ou basta encontrar alguém que esteja haqueando e perguntar no que eles estão trabalhando. Talvez seja interessante o suficiente para pular dentro.

Se você deseja criar o seu próprio negócio, o código é a maneira perfeita para encontrar cofundadores e funcionários. Eu sempre me sinto mal por tipos de empresas que postam em fóruns perguntando sobre a melhor forma de encontrar um cofundador ou CTO. Não por causa do tipo de négocios deles – que todos temos de viver com as nossas decisões -, mas porque eu não acho que isso seja um problema.

Conheci todas as outras pessoas do GitHub através de código: PJ através Chowhound, Tom através do seu trabalho open source, Scott por causa de sua quase irritante variedade de bibliotecas Git baseadas Ruby, e Tekkub pelo seu domínio da seção Lua do site.

Na CNET, encontramos pessoas realmente talentosas, tanto através de fonte aberta e projetos locais.

E todos que você conheceu aqui que você não conhecia antes da conferência, tecnicamente, é conhecido através de código.

GitHub não tornou-se popular em virtude do Git. Ele pode ter ajudado, mas não foi o principal catalisador.

GitHub se popularizou porque ele lida com código. Compartilhando, encontrando, e contribuindo com código.

Rubyforge e Sourceforge não são focados no código. Eles nunca foram.

Na verdade, ainda ontem Sourceforge passou por um redesign na sua homepage. Eles tem pesquisa no Twitter e projetos populares ali, frente e centro. Elegante. Então eu cliquei um pouco.

O primeiro projeto que cliquei, Ares Galaxy, é o número sete na lista top dez. O visualizador CVS disse que não possui quaisquer arquivos. Então eu acho que você pode simplesmente baixar um tarball. O que é bom.

O segundo projeto que eu cliquei era o número cinco da lista, 7-Zip. Ele não tem sequer um link para um visualizador de código fonte.

Sem código.

Eu percebi que fazia muito tempo que não criava um projeto no Sourceforge, então eu decidi fazer isso. Lembro-me que é doloroso, mas este é um novo redesign.

A primeira página é constituída por cinco radio buttons, um campo Nome do Projeto, um campo Nome Unix, um textarea para descrição pública, e um textarea para Notas adicionais. A área de notas é carinhosamente fornecida para que você possa justificar ao pessoal do SourceForge porque deve ser permitida a criação de um projeto. E, claro, você não pode continuar sem dar a eles uma razão que contenha pelo menos 200 caracteres.

Penso que é uma loucura – a maioria dos dias tenho problemas com 140 caracteres.

Além disso, há um aviso na parte superior que diz que você precisa armazenar software open source.

Depois de preenchidos todos os campos e que você clicou em ‘Next’ você é convidado a escolher uma licença open source. Há oito licenças listadas, juntamente com uma opção “outros” e, em seguida, um link para documentação sobre open source e escolher uma licença. Eu escolhi MIT.

Na página três você pode atribuir a seu projeto pelo menos cinco categorias. As opções de categorias são coisas como, “Linguagem de programação Ruby”, “User Interface DirectX”, ou “Desenvolvimento Status Beta”.

Eu escolhi quatro muito facilmente, mas teve problemas com a quinta, finalizava com, “Tema Religião e Filosofia New Age”.

Muito apropriado, se você pensar nisso.

Na última página você é convidado a ler sobre o que significa open source, sobre os termos de serviço do site, em seguida submete o projeto para aprovação.

Após o envio aparece uma tela de agradecimento e um pedido para você esperar de um a três dias úteis.

Eu, obviamente, tenho interesse em desaprovar um site competidor, mas este formulário de inscrição é uma das razões para termos começado o GitHub. Uma vez que você tenha uma conta, criar um repositório GitHub é, penso eu, simples:

Pedimos nome do projeto, uma breve descrição, e a URL do projeto. abaixo desses três campos tem dois radio buttons: esse projeto é público ou privado? A única coisa necessária é o nome do projeto. Você pode mudar qualquer um dos campos mais tarde. Não há nenhum processo de aprovação e você pode imediatamente começar a compartilhar código.

Entre decidir compartilhar o seu código e realmente compartilhar o seu código, SourceForge fornece um formulário de inscrição de quatro páginas e um a três dias de espera.

Mas sua documentação em software open source afirma: “A essência do modelo de desenvolvimento Open Source é a criação rápida de soluções dentro de um processo aberto, ambiente colaborativo”.

Correto.

Aqui está a minha sugestão para SourceForge:

Devem cortar o processo de inscrição para uma única página, remover os 200 caracteres do pedido “por favor hospedem o meu projeto”, serem mais favoráveis com relação a categorização, sugerir uma licença de fonte aberta para você, então permitir que altere qualquer destas coisas depois que seu projeto seja criado.

Eles também devem tornar a criação de projeto instantânea e passa-lo através de um filtro de spam ou ter funcionários remunerados para fazerem vistorias manualmente e aprovarem cada projeto em vez olhar para a lista dos projetos recentemente criados e assinalarem os que parecem suspeitos.

Parece-me que todos os passos necessários e formulários são apenas cerimônia, retardando você e fazendo você perder tempo com algo diferente do que você realmente deseja realizar. Eles agregam valor? Certamente que não.

E se há uma coisa que eu aprendi com Rails, é deixar o inferno fora do caminho e permitir que as pessoas concentrem-se na tarefa em questão.

Reduzir atrito.

Primeira lei de Newton do movimento, faz duas afirmações: um objeto em repouso tende a permanecer em repouso e um objeto em movimento tende a permanecer em movimento. É muitas vezes referida como a lei da inércia.

E inércia, para quem não se lembra ou não teve aula de física, é a tendência do objeto resistir a mudanças no seu estado de movimento.

Se você chutar uma bola, ela vai diminuindo a velocidade até parar. Mas ela não quer parar. O Atrito criado pelo movimento ao longo do solo e do ar reage contra a bola, conspirando para pará-la a todo o custo.

Quanto mais você remover atrito, o avanço da bola vai continuar e vai demorar muito mais tempo para parar.

Esta ideia de atrito, é muito parecida com o inverso da produtividade. Ser produtivo significa obter coisas feitas de forma eficiente e eficaz. Atrito impede de você fazer essas coisas, atrasa você, conspira contra você, é uma perda de energia.

E muitas vezes, o atrito custa seu dinheiro.

Poucos meses antes da segunda RailsConf Deixei Chowhound e a CNET para iniciar uma empresa de consultoria com Hyett PJ. Sabíamos como codificar, pensávamos que sabiamos como blogar, mas não sabíamos nada sobre como iniciar um negócio.

Então, fizemos algumas pesquisas. Aparentemente, existem empresas que você pode pagar para criar um negócio para você. Muito oficialmente. Eles até mesmo enviam-lhe uma pasta para documentos de couro com o nome da sua empresa bordado sobre nela.

E existem pessoas que você pode pagar para fazer a sua contabilidade. Nós vamos chamá-los “contadores”.

Estes são dois dos mais importantes investimentos que você pode fazer quando se inicia um novo negócio: profissionais que lidam com a papelada e que manipulam os números.

E não só porque eles sabem o que estão fazendo.

Você ia querer pagar 100 dólares por hora para um contador inexperiente? Porque se seu preço de consultoria é 100 dólares por hora e você faz sua própria contabilidade é exatamente o que está acontecendo.

Mesma coisa para a criação de um negócio. Todo o tempo que você gasta pesquisando, preenchendo papelada, formulários, dirigindo para Sacramento para encontrar um tabelião – é acrescentado e torna-se caro se você fizer tudo sozinho.

A menos, claro, que seu tempo seja sem importância. Mas você está aqui, portanto, isso não é verdade.

Como seu tempo não é inútil, isso significa repetição, trabalho entediante e duro, e todos os custos excessivos de configuração custam seu dinheiro. Bem, e custam seu tempo. O tempo é muito importante, também.

Acho que uma parte essencial de ser um bom programador é a capacidade de identificar estes pontos negativos e removê-los, para agilizar o processo.

Rack, por exemplo, é ótimo porque ele torna a interface com os servidores web tão fácil.

Git branching(ramificação) e merging(mesclar) são sempre apontados como a razão da escolha.

Nós todos amamos Rails porque faz a maior parte das coisas tediosas irem embora.

E testar é famoso porque, bem, bugs e designs ruins são horríveis.

Portanto, vamos seguir esses exemplos. Vamos criar mais projetos que cocem uma coceira ou aliviem alguma dor. Vamos parar a obsessão sobre qual framework de teste usar e começar a obsessão por constuir sites que resolvam problemas. Vamos parar de discutir sobre linguagens e continuar aprimorando a nossa favorita. Vamos parar de criar longos tutoriais para obter assinantes RSS e começar a contribuir para a documentação oficial.

Vamos nos concentrar mais no código e menos nas conversas. Mais nas informações sobre a comunidade e menos sobre nós mesmos.

Na verdade, acho que já estamos no caminho certo. O Ruby Heroes Awards é uma grande idéia e são dadas para as as pessoas certas. Sites como o Rubyflow e até mesmo o Twitter torna mais fácil do que nunca encontrar projetos novos e interessantes. Calendar About Nothing torna simples encontrar programadores apaixonados e dar uma olhada no que estão trabalhando, enquanto RailsCasts e DocRails são alguns dos melhores esforços de documentação em qualquer comunidade.

Então, sim. Queremos mais disso.

Afinal, nós queremos realmente ser estrelas de rock como Kid Rock ou Axl Rose? Pessoas que são famosamente irresponsáveis – que têm reputações degradante para os seus fans e notoriedade para o seu planeta que é do tamanho do próprio ego?

Acho que eu prefiro trabalhar com e ser um bom desenvolvedor.

Obrigado.

Aconteceu quando fui comprar minha quentinha para almoçar. No local onde moro tem pelo menos uns 4 restaurantes ou churrascarias próximos que fornecem quentinhas. Só que há uma insuperável, que é a de uma galeteria, um local até mais simples, mas em termos de qualidade da comida fica em primeiro lugar.

O problema é que quando cheguei o dono falou que tinha acabado a comida. Daí me virei frustrado e já ia planejando que demoraria a voltar novamente lá. Quando de repente um rapaz veio me avisar que o dono estava me chamando. Ele falou que tinha acabado o macarrão e perguntou se podia substituí-lo por arroz de leite. Eu gostei da idéia pois sabia que era uma comida bem feita. No final acabei aceitando e me deliciando com o almoço.

Agora vamos as comparações:

Esse é um caso isolado, onde já tenho uma relação de confiança com a galeteria pelo histórico de qualidade e sabor nas refeições. Por isso na hora que fui convidado a voltar eu pensei um pouco e vi que valia a pena.

Porém, hoje em dia muita gente consegue fazer coisas de qualidade, o único diferencial que existe é no atendimento de qualidade.

No caso que aconteceu comigo os funcionários da galeteria ao invés de dizer que não tinha mais quentinha eles poderiam logo no início dizer que estava faltando um dos elementos e perguntasse se eu aceitaria(justamente o que ocorreu depois). Eles acabaram cometendo esse pecado, que no meu caso não foi mortal, mas nos dias de hoje esses pequenos detalhes é que fazem a diferença, já que o cliente pode pegar o produto com qualidade equivalente em outro local. No caso da internet. Ele pode pegar um produto em uma promoção especial a um clique de distância.

Um grande abraço a todos e para os empresários fica o seguinte parágrafo:

Vamos pensar também nos detalhes, pois é nos detalhes que o cliente passa a se identificar e a indicar para os amigos. O cliente não vai atraz somente de algo para matar a fome. Ele vai atraz de uma comida de qualidade entregue de uma forma que não possa ser feita melhor em outro local. Um mal atendimento poderá deixar até o gosto da comida mais amargo!

A minha experiência com primeira linguagem foi em 1997 com Pascal que foi uma linguagem criada em 1970 por Niklaus With com o objetivo principal de encorajar o uso do código estruturado (principalmente para o ensino).

Vamos ver um pequeno exemplo de teste lógico em Pascal:

program Testelogico;

var a,b:integer;

uses crt;

begin
   clrscr;
   writeln ('Digite um número para A');
   readln (a);
   writeln ('Digite o número para B');
   readln (b);

   if (a = b) then
       writeln ('A é igual a B')
   else
       if (a < b) then
           writeln ('B é maior que A')
       else
           writeln ('A é maior que B');
end.

Podemos perceber nesse código a necessidade de aprendizado de vários conceitos voltados para a própria estrutura da linguagem ao invés de se focar no problema. Como exemplo temos a exigência dos parênteses e o ponto e vírgula no final de bloco, além da regra clássica: antes de else não se usa ponto e vírgula, pois o ponto e vírgula é utilizado para finalizar blocos de programação.

Ruby é uma linguagem criada por Yukihiro Matsumoto, projetada para programação em grande escala unido de codificação rápida. Vamos ver o mesmo exemplo anterior feito em Ruby:

print "Entre com o valor de A:"
a = gets

print "Entre com o valor de B:"
b = gets

if a == b
   print "A é igual a B"
elsif a < B
   print "B é maior que A"
else
    print "A é maior que B"
end

Além da quantidade de código diminuir tornando-o mais simples, a curva de aprendizado também tende a ser menor, pois agora não temos mais que garantir regras voltadas para a estrutura da linguagem. o bloco if-else faz o que tem que ser feito sem precisar está se preocupando se está faltando ou não ponto e vírgula.

Podemos ver um exemplo ainda mais convincente com estruturas de repetição com final conhecido. Vejam um exemplo em Pascal que mostra 10 vezes na tela a palavra “teste”:

Program repeticao

var
   i : integer;

begin

   for i:= 1 to 10 do
       writeln("teste");

end

Para fazer esse exemplo simples precisei seguir a burocracia de criar o nome do programa criar a variável e só depois criar a rotina. Vamos ver no Ruby o mesmo exemplo:

10.times do
  puts "teste"
end

Ou ainda:

10.times { puts “teste” }

Deu para perceber a simplificação absurda do código no Ruby? Em algumas rotinas assemelha-se a criação de um texto em inglês (linguagem humana). Ao invés de precisar saber que a repetição será a variação do valor de uma variável i de 1 a 10, simplesmente peço para imprimir 10 vezes a palavra “teste”.

Aliando essa simplicidade à característica de ser totalmente orientada a objetos. Além de, junto com o framework rails permitir a utilização profissional no desenvolvimento de sistemas web. Já acho que são argumentos suficientes para aposentar de vez o Pascal (ainda bastante utilizado no ambiente acadêmico e em cursos técnicos como primeira linguagem de programação complementando a disciplina de algoritmos) e seguir com uma linguagem simples, produtiva, de utilização geral e até divertida como o Ruby.

Lembrando que estou sugerindo como primeira linguagem, para depois continuar com ela ou não. Sempre que possível é muito importante aprender outras linguagens para obter outros pontos de vista.

Um grande abraço e até o próximo Pense nisso!

A revista National Geographic Brasil de julho 2007 veio com uma matéria sobre Inteligência Coletiva, que falava do comportamento de pássaros, abelhas, formigas e peixes que estavam sendo estudados e também aplicados no trabalho, no aeroporto, na internet e eu diria também no desenvolvimento de software com objetivo de facilitar e otimizar processos.

No caso do formigueiro, a colônia é capaz de resolver problemas impossíveis para cada formiga individualmente, como por exemplo, achar o caminho mais curto para a melhor fonte de comida. Se individualmente elas são estupidas, coletivamente são ágeis e eficientes, fenômeno denominado de “inteligência de enxame”.

Uma característica muito importante no formigueiro é o fato de ninguém está no comando, e a colônia funciona muito bem, mesmo sem ter um sistema de controle. O funcionamento da colônia é baseado em diversas interações entre as formigas, cada qual seguindo regras práticas muito simples sendo a comunicação por meio do toque e odor (ferormônio).

Outro fato interessante ocorre num enxame de abelhas que mesmo havendo desacordos frequentes sobre os lugares onde formar nova colmeia, elas sempre escolhem o melhor local. Chegando a essa decisão por avaliações independentes e algum tipo de votação. Novamente é um trabalho coletivo descentralizado. A abelha rainha possui a única função de pôr ovos.

Esse comportamento das formigas já é extensamente aproveitado na computação na área de otimização combinatória através do algoritmo “colônia de formigas” que é utilizado para descobrir a melhor rota para coleta de lixo em uma cidade, transporte de combustíveis a partir de poços de petróleo espalhados geograficamente, com objetivo de diminuir o tempo do serviço, diminuir o gasto com combustível, evitar que o caminhão passe mais de uma vez pela mesma rua, entre outros problemas.

Comparando um pouco esses princípios da inteligência coletiva podemos identificá-los em práticas do Extreme Programing como a do “Código Coletivo” onde todas as classes e métodos pertencem à equipe e caso seja necessário qualquer integrante poderá modificá-lo sem ter que pedir permissão, mas para garantia de segurança só é possível o uso pleno dessa prática se a equipe investir na criação de testes automatizados.

Fazendo analogia com as comunicações simples das formigas o XP utiliza-se das práticas de “programação em pares” e de “Reunião em pé“, em que o conhecimento poderá ser dividido e propagado para todos os integrantes da equipe garantindo dessa forma a prática do código coletivo e evitando o risco de determinada rotina ou código fique sem manutenção devido a falta de algum desenvolvedor por motivo de doença. Nesse caso logo outro assume pois já tem uma noção do funcionamento do código. As reuniões garantem o andamento correto do desenvolvimento sem correr o risco de fugir do que foi priorizado em planejamento.

Existe várias outros valores, princípios e práticas no XP, que juntos acabam tornando o desenvolvimento mais produtivo, mas algo importante deve ser reforçado: para o funcionamento efetivo cada integrante da equipe deve estar comprometido e assumir as responsabilidades. Isso deve ficar bem claro, senão acaba voltando para outras práticas hierarquizadas em que o desenvolvedor fica esperando que o gerente de projeto lhe dê algo para fazer.

É bem semelhante à coletividade das abelhas, formigas e peixes que sozinhos são prezas fáceis e não conseguem realizar tarefas complexas, mas em conjunto, cada qual fazendo sua parte, conseguem realizar tarefas que até hoje facinam os pesquisadores da área.

Bom, fico por aqui e até o próximo “pense nisso!”.

Há alguns anos venho acompanhando algumas discussões sobre que sistema operacional usar e nesse post vou tentar mostrar um ponto de vista diferenciado para, quem sabe, servir como referência para a tomada de decisões de gestores de informática, mas meu objetivo é somente de propor discussões e reflexões.

Antes de chegar ao tema proposto quero que vejam a imagem abaixo:

Ela representa a realidade das primeiras interfaces para os usuários, que eram com cartões perfurados em que o sistema dizia ao usuário o que ele deveria fazer, ou seja, as regras de utilização eram impostas devido ao limite de tecnologia da época. Se as regras não fossem estritamente seguidas ocasionava problemas que acarretariam um extenso retrabalho.

No decorrer dos anos a tecnologia e a interface foi sendo aperfeiçoada até chegarmos nas atuais que é bem representado pela imagem abaixo onde a interface passou a se adaptar cada vez mais ao usuário.

Nesse período de adaptação, auxiliado por uma oportunidade única de mercado, que não foi desperdissada, fez com que a interface do windows da Microsoft se tornasse sinônimo de interface desktop no imaginário da maioria dos usuários, o mesmo fenômeno ocorreu com o word que se transformou em sinônimo de editor de texto.

Com o passar do tempo, foi criado um sistema de código aberto, chamado Linux, que passou a ser mais uma opção de utilizar como recurso nas empresas, como também o broffice writer que é um editor de texto gratuíto e de código aberto.

Não vou me prender a detalhes técnicos de ambos sistemas operacionais, pois meu foco aqui é na relação entre as pessoas, gestores e funcionários.

Como falei a pouco, na hora do gestor decidir que plataforma adotar, entre outras opções ele pode tomar decisões voltadas para o o recurso(estrutura, sistema) ou voltada para as pessoas.

Quando ele foca no recurso ele tem as duas opções Windows e Linux, mas quando foca nas pessoas a situação é um pouco diferente como vou mostrar a seguir:

Estou tendo uma experiência, não como gestor, mas como integrante de uma equipe, que está adotando softwares gratuítos para texto e planilha, no caso o broffice. Tenho percebido no decorrer dos 2 últimos anos a insatisfação dos usuários por ter que utilizar uma interface na qual não estavam acostumados, além de alguns problemas de formatação devido a utilização do formato do word editado no broffice.

A decisão de mudar para broffice foi a maneira sensata de passar a utilizar softwares legalizados, já que tinhamos uma incidência do editor proprietário sem licenças para utilizar. Mas nossa maior preocupação foi de não ser em hipótese alguma algo imposto. O sistema foi instalado porque era legal e gratuito, mas caso o setor quisesse realmente o office da Microsoft ele teria total liberdade de solicitar a compra de uma cópia legal no orçamento anual.

Tive também uma experiência familiar. No computador de minha casa deixei o windows, mas como editor de texto instalei somente o broffice e poucos meses depois minha mãe perguntou porque que eu tinha instalado esse programa e não o word, pois ela estava tendo muita dificuldade, durante meses seguidos. Na época eu só utilizava o writer (broffice) e devido meu egoísmo disse para ela que eu só poderia ajudar a resolver algum problema se fosse no broffice, no word não seria possível. Mas depois de algum tempo refletindo, acabei deixando o egoísmo infantil de lado e instalando o word que causou uma mudança instantânea na performance, produtividade e satisfação dela e que consequentemente me deixou feliz também.

Então gestor te fasso a pergunta: como você que ser lembrado quando seu tempo de liderança terminar?

Dependendo da decisão que você tomar poderá ser lembrado de uma das seguintes formas:

1. Cháves, ditador, quando fechou a emissora de televisão infligindo com a liberdade de expressão da Venezuela. Que no caso de uma gestão de informática serve como metáfora para uma imposição de softwares que irão gerar insatisfação dos seus funcionários, trazendo desconforto na utilização pelo excesso de esforço em reaprender a utilizar a interface imposta(linux e broffice) ao invés da intuitiva que nesse caso seria o conjunto windows e office.
2. Spielberg que trabalha com a criação de sonhos no imaginário dos espectadores, que acabam refletindo, se emocionando, facinando-se com os diversos temas sem o risco de imposições e sim com toda a liberdade e satisfação. No caso do nosso público alvo seria a utilização do windows com office (Microsoft), pois como já estão assimilados no imaginário desse público, o esforço será focado nas rotinas e problemas setoriais, aumentando dessa forma a produtividade e garantindo a satisfação do usuário.

Porém, quando o contexto é diferente, a classificação pode se inverter, como o caso desse anúncio de vagas para desenvolvedor e designer promovido pela visie, no qual foi divulgado o perfil necessário para ocupar o cargo. Nesse caso foi criado um sonho de fazer parte de uma equipe que vem se consolidando no mercado brasileiro no decorrer do anos para tipos específicos de usuário, novamente repito nada de imposição até aqui. Esse sonho agora é voltado para Linux e linguagens de programação de código aberto (atitude “Spielberg”). Um exemplo de atitude “Cháves” seria um anúncio fictício de vagas para pessoas com experiência de programação na plataforma windows e quando chegasse lá fosse totalmente o oposto.

Agora vocês podem me perguntar: E sempre será assim?
Para tentar responder quero que vocês analisem abaixo a pesquisa do Datafolha “Top mind 2006″ com o produto margarina:

Conseguem perceber a evolução da Qualy no decorrer dos anos. Isso com certeza foi consequência de um trabalho muito bem elaborado, inovador e consistente de maketing e publicidade. Como dá para notar não foi da noite para o dia nem muito menos forçando o consumidor a usar. Foi conquistando pouco a pouco com campanhas e slogans inovadores como “Qualidade de vida é com Qualy”.

Agora eu que pergunto. O que é que a comunidade do linux tem feito para esquecer um pouco o código e o produto e se preocupar mais no software do ponto de vista do negócio e mercado e tentar consolidar a marca junto a novos usuários?

Se tem feito algo ou não, o que tomo como referência é o seguinte fato:
Segundo pesquisa da Positivo, 75% dos consumidores que compraram computador com Linux trocaram por Windows em até 3 meses.

Enquanto essa situação não modificar, a melhor opção voltada para usuários de escritório será windows com pacote office porque a utilização do linux, por mais que a interface se aproxime em semelhança da do windows, atualmente ainda gera desconforto e a sensação de algo forçado para os usuários que já tem problemas suficientes para se preocupar.

Claro que no dia-a-dia o gestor enfrentará problemas de orçamento curto, mas mesmo assim ele deverá pensar muito bem antes de utilizar linux com broffice, pois terá que gastar com treinamento e paciência devido as reclamações que inevitavelmente aparecem e também a curva de aprendizado que será maior do que seria no windows.

Bom fica aí a seguinte frase pra pensar:

Vamos criar ambientes empolgantes para os funcionários, ou usuários (jeito “Spielberg”) ao invés de criar barreiras geradas por imposições que podem acabar despertando insatisfação e diminuição da produtividade na equipe (jeito “Cháves”).

Até o próximo “pense nisso!”

Um abraço a todos.

Bom, como vocês podem perceber não coloquei nem vou colocar link para páginas que explicam sobre POG, pois trata-se de práticas que realmente são inúteis para um desenvolvedor, mas caso queiram ler com o intuito de distração, ou divertimento sem tomar como referência profissional, podem colocar o termo no google ou na wikipedia que encontrarão algo.

Vejam a definição de gambiarra citada por Rodrigo em sua dissertação de Mestrado.

“Gambiarra é o nome dado informalmente ao procedimento necessário para a configuração de um artefato improvisado. O termo também costuma ser usado para definir o artefato em si.”

Ele também mostra que é preciso compreender tal atitude como um raciocínio projetivo imediato, determinado em situações momentâneas além de associa-lo culturalmente ao chamado jeitinho brasileiro.

Já sei, agora vocês querem saber o que é que isso tem a ver com a prática do XP.

É exatamente isso que vocês pensaram! Não tem absolutamente nada a ver! XP não é improviso, não é um jeitinho e definitivamente não é gambiarra!

O XP são um conjunto de práticas consolidadas que visa tornar o desenvolvimento de software mais dinâmico, incremental, com maior velocidade de resposta, com mudanças freqüentes e sempre com participação ativa do cliente e usuários.

Ele segue com princípios contrários a outras práticas mais tradicionais, devido ao gargalo formado pelo excesso de documentação e dificuldade de comunicação efetiva entre os diversos responsáveis pelo desenvolvimento. Que terminavam com muita freqüência entregando software com prazo extrapolado e muitas vezes com cliente insatisfeito, que quando não falava pelo menos pensava na seguinte frase: “Não é nada disso que eu estava querendo!”.

Ao invés de separar a equipe por funções diferenciadas: analista, gerente de projeto, programadores, etc, cada integrante deve estar envolvido em todo o processo do desenvolvimento de um software, da reunião para decidir o que deverá ser feito, de uma análise para definir como será feito, criação do teste (TDD), criação do módulo escolhido (interface que o usuário poderá testar para dar seu feedback). Essa forma de deixar o profissional ficar a par de todo o processo, deixando-o muito bom no específico ato criativo de programar e também possibilitando uma visão geral foi inspirado na metodologia da Toyota.

Na década de 40 a Toyota precisava encontrar fomas de produzir automóveis com maior agilidade e qualidade e ao mesmo tempo reduzindo os custos. Foi assim que criou a chamada Produção Enxuta e aperfeiçoou por décadas, hoje é conhecida como just in time.

O quinto e o sétimo princípio básico do método se chama “delegar poder à equipe” e “Ver o Todo” respectivamente. Eles partem do princípio que para ampliar ao máximo a qualidade é necessário obter os detalhes corretamente e a pessoa mais adequada para isso são as que efetivamente executam o trabalho, no popular “põem a mão na massa”. Coordenando com isso a uma constante verificação do todo, o conjunto final deve ser sempre mais importante que um componente específico, o que gera a necessidade de cada integrante estar além de sua especificidade tomando decisões também em níveis de análise e projeto.

Utilizando desses e de outros princípios, a Toyota conseguiu em abril de 2007 a marca história e simbólica de ultrapassar a General Motors(GM) na venda mundial de automóveis.

Em sua palestra sobre XP utilizando a interface do Treina Tom, Vinícius Teles mostrou um slide com a foto de Jack Järkvik que é o Vice-Presidente da Ericsson na suécia e que ele falava do quanto a empresa ganhava dinheiro no decorrer dos anos. Muito dinheiro, mas muito dinheiro mesmo! Falou também que Jack apontou para a tela que mostrava as práticas do XP e disse que tudo isso que estava sendo exposto no evento sobre XP eles já utilizavam desde a década de oitenta, que conseqüentemente foi o que fez com que eles ganhassem muito dinheiro.

Peço então aos que ainda acham que XP é gambiarra que perguntem aos dirigentes da Toyota e da Ericsson se os processos deles são gambiarra e acho que terão uma resposta muito interessante. E ainda dou uma dica, Vinícius falou que o Vice-Presidente da Ericsson em sua palestra tinha uma postura bem arrogante. Aqui em baixo tá a foto dele para vocês terem uma noção:

Mas ainda acredito bastante na liberdade de expressão, pois foi justamente por isso que consegui ter contato com novos conceitos e tenho também confiança que alunos, profissionais ou pessoas antenadas vão saber detectar a diferença entre um comentário superficial, sem valor, e um comentário melhor elaborado, que aliás é um dos princípios da academia, que repassa conceitos científicos e filosóficos para o cidadão obter mais ferramentas além do conhecimento do senso comum, que é importante, mas quando lidamos com ambientes de produção, ele sozinho não dá conta do domínio do problema.

Mas aí algum profissional pode me questionar, mas o RUP tem dado certo em instituições como Banco do Nordeste e não é uma metodologia ágil.

Não estou aqui me desfazendo de nenhum outro processo, só estou afirmando tecnicamente e historicamente que o XP é um processo válido, consolidado e tem gerado resultados bons, inclusive em grandes empresas. Sou a favor que o aluno tenha contato com diversas abordagens e no fim tome a decisão de tentar seguir a que mais se aproxime das suas expectativas e princípios. Confirmo novamente que a desburocratização do processo de comunicação que é praticado no XP torna o ambiente mais dinâmico, menos entediante e mais saldável para essa geração que não se identifica muito com exagero de hierarquias e processos burocráticos, para pessoas que gostam de priorizar o software e não o exagero de documentos.

Com relação a documentação, sempre há a dúvida se é feita ou não no XP. Sim é feita mas como complemento, somente o necessário, depois da iteração terminada e mostrado algum resultado para o cliente (interface do software) e ele afirmar que é realmente o que ele procura. A própria classe, se for bem feita é facilmente compreendida por um desenvolvedor experiente, que já pode ser considerado um documento que nunca fica desatualizado. Mas sabemos que também é importante dependendo da complexidade do software complementar com por exemplo um diagrama de classes ou um diagrama ER para obter facilmente uma visão geral do sistema, mas eles são utilizados primeiramente para planejar (tentar encontrar as melhores combinações em um nível de abstração mais alto) e consequentemente como documentação. Outro fator que complementa a documentação são os testes automatizados TDD (Desenvolvimento Orientado a Teste) que no caso específico dos testes unitários são rotinas para verificar se determinada classe terá um funcionamento adequado ou não, dando uma garantia melhor para que seja evitado falhas. Para garantir a integridade dessas práticas voltadas “mais para o software menos para os documentos”, utiliza-se as técnica de refatoração com o objetivo de deixar o código cada vez mais simples, sem modificar a execução e programação em pares que consegue diminuir a quantidade de falhas que um programador individualmente poderia cometer além de propagar o conhecimento sobre o software de uma forma que se torne responsabilidade de cada membro da equipe, não somente de indivíduos isolados.

Para fechar digo também que as práticas do XP não devem ser tomadas como imposições necessárias para obter sucesso. Elas podem e devem ser modificadas dependendo do contexto, podem ou não ser usadas em conjunto. Elas devem ser tomadas como princípios que podem ser aprimorados.

Bom, fico por aqui, até o próximo “Pense nisso”.
Para saber mais sobre XP e metodologias ágeis acessem os seguintes links:

• 
  Dissertação de Vinicius Teles e um extenso material de divulgação do XP e suas práticas
• Podcasts tudoquequerosaber sobre desenvolvimento ágil
• podcast da improvit sobre Extreme Programing
• Podcast da Cooperativa de Desenvolvimento Ágil de Software – Agilcoop