30/01/2010 em AkitaOnRails.com

[Off-Topic] Empresas, Pessoas, Sucesso

Adoro o vídeo Wear Sunscreen, acho que eu vi pela primeira vez em 2003 ou 2004 e ela ficou para mim como um “aviso”, algo a se lembrar de vez em quando. As partes que mais gosto são:

“Tenha cuidado com quais conselhos você aceita, mas seja paciente com quem lhes dá conselhos. Conselho é uma forma de nostalgia, distribuí-lo é uma forma de pescar o passado do lixo, limpá-lo, pintar sobre as partes feias e reciclá-lo por mais do que vale.”

Outra parte importante:

“Talvez você se case, talvez não, talvez você tenha filhos, talvez não, talvez você se divorcie aos 40, talvez você dance a dança da galinha no seu 75o aniversário de casamento. Não importa o que faça, não se parabenize demais ou se critique demais. Suas chances são de 50%, assim como as de todo mundo.”

Relembrei dessa parte lendo o livro What the Dog Saw, do Malcolm Gladwell, no capítulo onde ele fala sobre outro autor que eu gosto, o Nassim Taleb, que escreveu o excelente Fooled by Randomness. Esse capítulo, por acaso está no blog do Gladwell e esse é o trecho que me chamou a atenção:

“Para Taleb, então, a questão de porque alguém foi um sucesso no mercado financeiro era vexatório. Taleb consegue fazer os cálculos de cabeça. Suponha que existiam 10 mil gerentes de investimento por aí, o que nem é um número grande, e que a cada ano metade deles, totalmente por sorte, ganharam dinheiro e que metade deles, totalmente por azar, perderam dinheiro. E suponha que a cada ano os perdedores saiam do mercado, e o jogo é refeito com os que sobraram. Ao final de 5 anos, haveriam 330 pessoas que ganharam dinheiro e cada um desses anos, e depois de 10 anos, sobrariam 9 que ganharam dinheiro em cada ano, seguidamente, totalmente por sorte. Niederhoffer, como Buffett e Soros, era um homem brilhante. Ele tinha um Ph.D em economia pela Universidade de Chicago. Ele iniciou a idéia de que por análise matemática rígida de padrões no mercado um investidor poderia identificar anomalias lucrativas. Mas quem poderia dizer que ele não era um dos 9 sortudos? E quem poderia dizer que no 11o ano Niederhoffer não seria um dos azarados, que de repente perderia tudo, que de repente, como se diria em Wall Street, ‘se ferrou’?”

O artigo é longo, mas vou poupá-los dos detalhes: Victor Niederhoffer literalmente ‘se ferrou’, em outubro de 1997. Perdeu praticamente tudo.

O Milagre da Apple

Em 1997, a Apple era considerada praticamente fora do mercado, com uma linha de produtos ruins, péssima imagem, marketshare em declínio, enormes prejuízos. Foi quando Steve Jobs retornou.

Em 2009, a Apple é uma das empresas mais admiradas do mundo, seu valor de mercado se multiplicou dezenas de vezes, demonstra lucros extraordinários, a marca é uma das mais reconhecidas e adoradas do mundo, seus produtos são invejados por toda a indústria.

Essa é a história do CEO da Década, do iMac, para o iPod, para o iPhone e agora o iPad. Todos nós adoramos histórias como essa. Imaginar que um grande cérebro, um gênio, um herói, pode sozinho dobrar uma indústria inteira a seus pés. 12 anos ininterruptos de sucesso.

Eu também adoro essa história, ela me fascina desde a década de 90, conheço essa história toda desde quando ela começou em 1976, o Macintosh em 1984, a Pixar em 1995, o grande retorno em 1999, o iPod de 2001, o iTunes de 2003, o iPhone de 2007. Mas não consigo deixar de tentar imaginar o quanto disso foi pura sorte e quando amanhã será o dia da grande virada para o azar – claro, espero que não aconteça, mas a história mostra que é uma questão de tempo.

As Receitas Mágicas

A coisa que eu acho mais engraçado é quantos “analistas”, “especialistas”, “gurus”, gostam de citar histórias como a da Apple, de Warren Buffet ou dos Victor Niederhoffer da vida como os detentores de “Receitas Mágicas para o Sucesso”.

Existe toda uma indústria que vai de psicólogos, MBAs, Ph.Ds, economistas, etc com toneladas de livros, análises, traçando as rotas das grandes pessoas ou empresas de sucesso, tentando encontrar o que elas tem em comum e a partir daí entregar procedimentos que “garantidamente” o levarão ao sucesso.

É uma tarefa fácil: se der certo, a fórmula funciona; se não der certo, foi você quem não seguiu a fórmula corretamente. Não tem como errar.

Estou cansado de ouvir: “nós devemos seguir esse caminho, porque é assim que a empresa XXX, de grande sucesso, está fazendo.” Mal sabem eles que muito disso pode ser pura sorte. E sorte é algo incontrolável, totalmente dependente da situação onde ela aconteceu, e que é impossível replicar quando se quer.

Num mundo caótico, é impossível replicar 100% de todas as milhões de variáveis que levaram a um fenômeno. Nós conseguimos enxergar, em retrospectiva, muitos dos fatores macro, mas jamais saberemos todos os micro-fatores que influenciaram no resultado, portanto é fútil tentar. Podemos sim, aprender com erros, mas acho muito difícil aprender com acertos, especialmente o tipo de acerto que leva uma Apple a sair da quase-falência em 1997 para o estrelato em 2009. Nem todos os maiores super-computadores do mundo seriam suficientes para analisar todas as variáveis envolvidas.

Admirar os grandes sucessos é um bom exercício. Isso nos inspira a tentar coisas diferentes ou a rever nossos pontos de vista e nisso encontro um exercício saudável.

Mas é burrice fazer citações ou tentar imitar os outros. “Vamos fazer X porque esse guru de sucesso disse.” Isso é cegueira, é não saber o que está fazendo, é não entender que só porque alguém está fazendo sucesso, isso não foi devido a pura sorte. Independente do que muitos podem achar: que foi por suor, por esforço próprio, por mérito 100% da sua perspicácia e inteligência. Como Taleb diz, pode parecer uma heresia dada a nossa cultura voltada a “suor = sucesso”, mas infelizmente é como as coisas funcionam no mundo. Espécies animais evoluem ou se extinguem baseadas em pura aleatoriedade. O Homo Sapiens está aqui por pura chance. É um fato a se aceitar.

E mais ainda: análises em retrospectiva são muito perigosas. Depois do acontecido é extremamente simples traçar um caminho para trás e ver a maioria dos passos que foram tomados. Mas o truque é que no passado, no momento onde era necessário tomar a decisão, nós não temos como saber o desenrolar da história. Portanto não podemos comparar o crítico de hoje que diz “ah, mas você deveria ter feito Y.” com o decisor de outrora, que não detinha o conhecimento futuro. Pior ainda: análises retrospectivas não servem como receitas para o futuro, porque o conjunto de variáveis e circunstâncias será totalmente outro.

Histórias heróicas fazem parte do nosso folclore, da nossa cultura, eu já falei sobre isso no artigo O Poder do Mito: Redux e recomendo dar uma olhada se ainda não leram.

Dado tudo isso um dos perigos, é o bom e velho analysis paralysis, onde queremos avaliar o máximo possível todas as variáveis que podemos conseguir antes de tomar qualquer decisão. Aceite que você nunca terá todas elas, e independente do volume de variáveis que conseguir analisar, suas chances de acerto não melhoram tanto assim. Como eu disse antes:

“Não importa o que faça, não se parabenize demais ou se critique demais. Suas chances são de 50%, assim como as de todo mundo.”

Isso tudo dito, o que uma pessoa ou empresa deve fazer? “Satisfazer os clientes?” Não, isso é somente um aspecto do negócio. “Entregar bons produtos?” Também não, isso é apenas mais um aspecto. O que você faz no meio do caminho lhe dará ou não sustentabilidade, mas não confunda as coisas. O propósito é apenas um. Um marketeiro lhe dirá que o principal é “satisfazer o cliente”, um engenheiro de produção lhe dirá que o propósito é “aumentar a produtividade”, um investidor lhe dirá que o objetivo é “aumentar o valor da sua empresa”, um cientista de computação lhe dirá que o objetivo é “criar tecnologias inovadoras”, um sociólogo lhe dirá que é “fazer uma diferença no mundo”, etc.

O propósito de uma empresa é “ganhar dinheiro de forma sustentável”. Apenas isso.

Obs: Não estou afirmando que tudo é derivado apenas de sorte, claro que não. Estou dizendo que é inútil tentar discernir isso de casos passados, e especialmente pior em tentar usar isso de modelo para o futuro, justamente por causa dessa incerteza.


26/01/2010 em MouseOver Studio

Indexação de documentos em JRuby com ActiveLucene

ActiveLucene é uma interface para o Lucene similar com a interface do ActiveRecord e/ou ActiveModel. Isso quer dizer que você pode gerar um scaffold numa aplicação Rails, ir no modelo, trocar ActiveRecord::Base por ActiveLucene::Document e tudo deveria continuar funcionando, com a diferença do modelo estar sendo salvo num índice do Lucene e não num banco de [...]

21/01/2010 em Vinicius Ebersol

jQuery TOOLS

jQuery TOOLS é uma biblioteca super completa que facilita muito a criação de tarefas hoje comuns, veja as demos dos recursos dessa biblioteca: Tabs; Tooltips; Overlay – Screenlocker para popups; Expose – Serve para destacar elementos da página; Scrollable – entre outras coisas serve para fazer galerias de imagens bem legais; Flash embed – uma espécide de SWF Object que já [...]

20/01/2010 em Nome do Jogo

A Filosofia do Ruby

Já faz um tempo que eu tenho planejado traduzir essa excelente entrevista de Bill Venners com Yukihiro Matsumoto. Finalmente conseguir finalizar a primeira parte. Yukihiro Matsumoto, ou “Matz” como ele é conhecido online, é o criador da linguagem de programação Ruby. Ruby é uma linguagem orientada a objetos adequada tanto para a escrita de scripts do [...]

20/01/2010 em MouseOver Studio

Logs com cores no Signal

Faz uns dias foi adicionado no Signal o suporte a mostrar os logs dos builds com cores. Caso estejam utilizando o Cucumber, deverão garantir que ele seja executado com a opção –color ou -c. Caso estejam utilizando o RSpec, a variável de ambiente RSPEC_COLOR devera estar setada como true. Com as opções mencionadas, os respectivos comandos irão criar [...]

11/01/2010 em Simples Ideias. Por Nando Vieira.

Documentando projetos com RDoc - PDF Grátis!

E está no ar mais um PDF da série HOWTO, desta vez abordando o RDoc, marcação de documentação para códigos escritos em Ruby. O RDoc é utilizado por quase todos os grandes projetos como Ruby on Rails e RSpec, dentre muitos outros. Este guia de 17 páginas mostra como utilizar o RDoc, com muitos exemplos de [...]

06/01/2010 em Nome do Jogo

Entendendo os métodos load e require por dentro

Você sabe explicar a diferença entre as duas linhas abaixo? require "my_library" load "my_library.rb" Se você já trabalhou ao menos um pouco com Ruby, então sabe que load é útil quando se deseja executar o código de um arquivo enquanto require é utilizado para importar uma biblioteca para dentro do código do seu programa. Esta definição está correta, mas [...]

28/12/2009 em Nome do Jogo

Retrospectiva 2009

O ano começou muito bem para os leitores deste blog. No finalzinho de 2008, logo após o lançamento do Rails 2.2, eu havia publicado em parceria com o site EnvyCasts, o meu segundo livro em um pacote especial com um screencast produzido por Gregg Pollack e Jason Seifer. No primeiro mês do ano eu disponibilizei [...]

24/12/2009 em Nome do Jogo

Classes são Módulos no Ruby

Qual é a diferença entre uma classe e um módulo no Ruby? Nenhuma, uma classe é um módulo no Ruby. Não acredita em mim? Class.is_a?(Module) # => true Agora que você já confia em mim, posso explicar com um pouco mais de calma. O que são módulos? Um módulo pode ser definido de forma grosseira como uma coleção de [...]

18/12/2009 em MouseOver Studio

Resumo das novas funcionalidades no Inploy

Após ter anunciado o Inploy faz aproximadamente 2 meses, varias pessoas tem colaborado com ele e feito que ganhe mais funcionalidades, as quais vou expor nesse post. Antes de mais nada, queria agradecer a essas pessoas pelas contribuições: Andy Shen Carlos Brando Douglas Campos Erik Dahlstrand Joris Trooster Josh Owens Se você atualizar hoje o Inploy e não fizer mais nada, as funcionalidades [...]

18/12/2009 em Simples Ideias. Por Nando Vieira.

Criando eventos recorrentes com Recurrence

Recurrence é uma biblioteca criada para gerar eventos recorrentes de maneira simples. Eu criei essa gem há tempos, mas nunca escrevi nada sobre ela. Eis que muitas pessoas começaram a me mandar e-mails perguntando como utilizá-la e chegou a hora de fazer um artigo mostrando seu uso na prática. A primeira coisa que você precisa fazer [...]

11/12/2009 em Simples Ideias. Por Nando Vieira.

7 coisas que você precisa conhecer no RSpec

O RSpec é um framework bastante completo e, por isso mesmo, muitas coisas são desconhecidas por grande parte dos desenvolvedores. Neste artigo, você conhecerá 7 coisas que irão mudar a maneira como você utiliza o RSpec. Subject O RSpec possui um método muito útil chamado subject, que retorna uma instância da classe que está sendo utilizada como [...]

02/12/2009 em MouseOver Studio

Integrando o Signal com CCMenu

Após ter anunciado o Signal no meu blog em inglês, recebi um feedback muito bom do Raphael, perguntando se planejava adicionar um feed compatível com o CCMenu. Achei muito interessante a funcionalidade e hoje, para poder integrar o Signal com o CCMenu (OS X) ou CCTray (Windows), basta apontar para a URL http://host/projects/status.xml e selecionar o [...]

07/11/2009 em Simples Ideias. Por Nando Vieira.

Ceará on Rails 2009: Testando Rails apps com RSpec

Acabei de fazer minha apresentação no Ceará on Rails, que foi um excelente evento! Se você não pode comparacer, pode ver os slides Gostaria de agradecer aos comentários positivos e, principalmente, aos organizadores. Keep on rockin’!

28/10/2009 em MouseOver Studio

Integração contínua simples de verdade com Signal

Signal é um servidor de integração continua criado em Rails que na minha opinião pega as melhores funcionalidades dos concorrentes e une elas numa aplicação bem simples de utilizar. Quando comecei a trabalhar com Rails, o primeiro servidor de integração continua que experimentei foi o CruiseControl.rb. O CC.rb foi escrito sobre Rails e o que mais [...]

Página 1Página 2Página 3Página 4Página 5Página 6