Foto de leinestein
Rails 3.0 é como pôneis e arco-íris! Ele irá fazer o seu jantar e dobrar a sua roupa. Vocês irão se perguntar como era possível viver antes disso. É a melhor versão do Rails que nós já fizemos!
Agora é sério, isso é algo realmente bom. Todas as boas ideias que a equipe do Merb trouxeram desde que se juntaram ao projeto estão lá, isso inclui um foco mais agnóstico ao framework, um código mais magro e rápido e um monte de saborosas APIs. Se você está vindo para o Rails 3.0 a partir do Merb 1.x, você deve reconhecer várias dessas APIs. Se você está vindo do Rails 2.x, você vai adorar isso também.
Mesmo se você não der a mínima para nenhuma das nossas limpezas internas, o Rails 3.0 também estará nas suas graças. Temos um monte de novos recursos e APIs melhoradas. Nunca houve uma época melhor para ser um desenvolvedor Rails.
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
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 dia a dia como de aplicativos de larga escala. Matz começou a trabalhar no Ruby em 1993, porque queria uma linguagem que o tornasse mais produtivo ao mesmo tempo que fosse divertida de usar. Embora inicialmente tenha se tornado mais popular no Japão, Ruby tem conquistado programadores no mundo todo.
Em 24 de setembro de 2003, Bill Venners se encontrou com Yukihiro Matsumoto na conferência JAOO em Aarhus, na Dinamarca. Nesta entrevista, que foi publicada em várias partes no site Artima.com, Yukihiro Matsumoto discute a filosofia por trás da arquitetura do Ruby, as características da linguagem e como tornar-se um programador melhor. Neste capítulo inicial, Matz filosofa sobre a imperfeição no design, o perigo da ortogonalidade, a concessão de liberdade com regras, o princípio da menor surpresa e a importância do ser humano no trabalho da máquina.
Não existe uma linguagem perfeita
Bill Venners: Dave Thomas, co-autor do livro “Programming Ruby: A Pragmatic Programmer’s Guide” me disse que você não acredita que uma linguagem de programação possa deve ser perfeita. Por que não?
Yukihiro Matsumoto: Desenvolvedores querem criar a linguagem de programação perfeita. Eles querem poder dizer: “Veja, a minha linguagem é perfeita. Com ela você pode fazer qualquer coisa”. Mas é simplesmente impossível conceber uma linguagem perfeita, porque existem duas maneiras de se olhar para uma linguagem de programação. Uma maneira é olhar para o que pode ser feito com essa linguagem. A outra é observar como nos sentimos usando essa linguagem – como nos sentimos durante o tempo que estamos programando.
De acordo com a teoria da completude de Turing, tudo que uma linguagem Turing-complete pode fazer teoricamente pode ser feito por qualquer outra linguagem Turing-complete, mas de um jeito diferente. Você pode fazer tudo em Assembler, mas ninguém quer programar em Assembler. Do ponto de vista do que você pode fazer, entretanto, as linguagens diferem entre si – mas as diferenças são limitadas. Por exemplo, Python e Ruby fornecem quase o mesmo poder para o programador.
Em vez de enfatizar o “o que”, eu quero enfatizar o “como”: Como nos sentimos durante a programação. Essa é a principal diferença da arquitetura do Ruby em relação as outras linguagens. Enfatizo a sensação em “como” eu me sinto usando Ruby. Eu não trabalho para tornar o Ruby perfeito para todos, porque você tem sentimentos diferentes dos meus. Nenhuma linguagem pode ser perfeita para todos. Eu tentei fazer Ruby perfeito para mim, mas talvez ele não seja perfeito para você. A linguagem perfeita para Guido van Rossum é provavelmente o Python.
Ortogonal vs Harmonioso
Bill Venners: Dave Thomas alegou também que se eu pedir para você adicionar ao Ruby um recurso que é ortogonal, você não vai fazê-lo. O que você quer é algo que seja harmonioso. O que isto significa?
Yukihiro Matsumoto: Eu acredito que a coerência e a ortogonalidade são ferramentas de design, não o objetivo principal do projeto.
Bill Venners: O que significa ortogonalidade neste contexto?
Yukihiro Matsumoto: Um exemplo de ortogonalidade é adicionar qualquer recursinho ou sintaxe à linguagem. Por exemplo, C++ suporta parâmetros com valores padrão e também sobrecarga de funções com base em parâmetros. Ambos os recursos são bons para se ter em uma linguagem, mas devido ao fato desses recursos serem ortogonais, você pode aplicar ambos ao mesmo tempo. O compilador sabe exatamente o que fazer nesse caso. Se houver ambigüidade, o compilador irá sinalizar um erro. Mas se eu olhar para o código, vou precisar aplicar a regra com o meu cérebro. Eu preciso adivinhar como funciona o compilador. Se eu estiver correto, e for inteligente o suficiente, isto não será nenhum problema. Mas se eu não for inteligente o suficiente, e eu realmente não sou, isto causará muita confusão. O resultado será inesperado para uma pessoa comum. Este é um exemplo de como ortogonalidade pode ser ruim.
Bill Venners: Em outras palavras, as características ortogonais irão funcionar, uma vez que o compilador as entende e executa o programa. Mas é difícil para um programador compreender o funcionamento quando está olhando para o código, porque ele precisa descobrir como essas duas coisas funcionam juntas.
Yukihiro Matsumoto: Características ortogonais, quando combinadas, podem explodir em complexidade.
Bill Venners: Qual é a alternativa? O que seria mais harmonioso?
Yukihiro Matsumoto: Basta escolher uma das duas funcionalidade para colocar na linguagem. Você não precisa fazer tudo o que vier a sua cabeça. Você deve escolher apenas um desses recursos, mesmo que ambos sejam bons.
Liberdade e conforto
Bill Venners: Uma das filosofias da comunidade Python é fornecer uma e apenas uma maneira de fazer as coisas. Se você fornecer cinqüenta maneiras diferentes de fazer a mesma coisa, então você está fornecendo conveniências para quem está escrevendo o código. Cada programador terá a liberdade de escrever do jeito que preferir. Mas o problema não é com quem escreve, mas com a pessoa que está lendo o código. Você pode adotar uma forma de escrever o seu código e o programador do lado pode adotar uma outra forma. Assim, quem está lendo precisa estar familiarizado com todos as maneiras possíveis de se realizar aquela tarefa, não apenas a sua maneira favorita de codificar. Esse é o dilema do design. A comunidade Python parece preferir uma única abordagem, mas Ruby parece oferecer várias maneiras de se fazer a mesma coisa.
Yukihiro Matsumoto: Ruby herdou a filosofia do Perl de ter mais de uma maneira de fazer a mesma coisa. Eu herdei essa filosofia de Larry Wall, que é o meu herói atualmente. Eu quero que os programadores Ruby sejam livres. Eu quero dar-lhes a liberdade de escolher. As pessoas são diferentes. As pessoas tem diferentes critérios. Mas se há uma maneira melhor entre as várias alternativas, quero encoraja-la, tornando-a mais confortável. Então é isso que eu tentei fazer. Talvez um código Python seja um pouco mais legível. Qualquer um pode escrever utilizando o mesmo estilo em Python com a finalidade de deixar o código mais fácil de ler, talvez. Mas a diferença de uma pessoa para outra é tão grande, que prover apenas um caminho é de pouca ajuda mesmo se você estiver usando Python, eu acho. Eu prefiro dar tantas maneiras quanto for possível, mas incentivar ou orientar os usuários a escolher a melhor maneira, se ela existir.
Alegria
Bill Venners: Em um artigo introdutório sobre Ruby, você escreveu: “Para mim, o propósito da vida é, em parte, ter alegria. Programadores geralmente se sentem felizes quando podem concentrar-se na parte criativa da programação, assim Ruby foi projetado para fazer programadores felizes.” Como pode o Ruby fazer programadores felizes?
Yukihiro Matsumoto: Você quer aproveitar a vida, não é? Se você pudesse terminar seu trabalho rapidamente e de uma forma divertida, seria muito bom, não é? Esse é o propósito da vida, em parte. Sua vida será melhor.
Eu quero resolver os problemas que encontro no cotidiano usando computadores, então preciso escrever programas para eles. Usando Ruby, quero me concentrar nas coisas que faço, não nas regras mágicas da linguagem, como começar com um public something something void something para imprimir na tela: “Olá mundo”. Eu só quero dizer print "this!". Eu não quero todas estas palavras-chave envoltas em magia. Eu só quero me concentrar na tarefa. Essa é a idéia básica. Então, eu tenho tentado fazer um código Ruby conciso e sucinto.
Bill Venners: Permitir que os programadores escrevam código que é conciso e sucinto é uma maneira de fazê-los felizes.
Yukihiro Matsumoto: Sim, para que eles possam se concentrar no problema. As vezes as pessoas anotam pseudo-código em uma folha de papel. Se esse pseudo-código pudesse ser executado diretamente em seus computadores, seria muito bom, não seria? Ruby tenta ser assim, como esse pseudo-código sendo executado. O pessoal do Python também diz o mesmo.
Bill Venners: Sim, o pessoal do Python diz que o Python é um pseudo-código executável. O que mais tem no Ruby que faz os programadores felizes?
Yukihiro Matsumoto: No nosso cotidiano como programadores, processamos muito texto. Então, eu tentei trabalhar duro em processamento de textos, ou seja, na classe string e expressões regulares. As expressões regulares são incorporadas a linguagem e estão prontas para o uso. Também precisamos interagir muito com o sistema operacional. Ruby pode executar chamadas ao sistema Unix e para a maioria das funções da API do Windows. Isso aumenta o poder e a utilizade do sistema operacional no ambiente da linguagem interpretativa. Então você pode fazer a administração de sistemas e a programação diária de processamento de textos. É isso que faço na maior parte do tempo, então eu trabalhei duro em fazer isto funcionar bem.
Bill Venners: Então, basicamente, Ruby me permite aproveitar mais a minha vida, porque faz com que eu termine o meu trabalho mais rápido ao mesmo tempo que o torna mais divertido?
Yukihiro Matsumoto: Ele me ajuda a fazer isso. Não tenho certeza se Ruby funciona para você, mas eu espero que sim.
O Fator Humano
Bill Venners: Em uma entrevista, você disse: “Não subestime o fator humano. Embora estejamos em frente a um computador, eles são apenas máquinas. Estamos trabalhando para humanos, com humanos.” O que você quer dizer com isso?
Yukihiro Matsumoto: Imagine que você está escrevendo um e-mail. Está na frente do computador. Está operando o computador, clicando em um mouse e digitando em um teclado, mas a mensagem será enviada a um outro ser humano através da internet. Então você está trabalhando com um computador, mas o objetivo é sempre um ser humano. A maioria das tarefas que fazemos são para seres humanos. Por exemplo, um cálculo de impostos é a contagem de números que indicam quanto o governo pode retirar de dinheiro da minha carteira, mas o governo é composto por seres humanos.
A maioria de nossas tarefas estão relacionadas com seres humanos. Assim, quando programamos podemos tanto pedir ao computador para trabalhar para um ser humano, como podemos descrever nossos pensamentos de uma forma tão clara que até mesmo uma máquina possa executar. No primeiro caso, fazemos o computador trabalhar para o ser humano, o alvo é um ser humano atrás de um computador. No segundo caso, expressamos nossos pensamentos com clareza suficiente para ser compreendido e executado por computadores, a intenção é expressa por cérebros humanos e o resultado é calculado por um computador. Assim, em ambos os casos, o objetivo aqui é sempre o ser humano.
Bill Venners: O que é mais importante sobre este tipo de mentalidade? Você diz: “Não subestime o fator humano.” Por quê?
Yukihiro Matsumoto: Computadores não se importam se eu estou fazendo algum esforço para me comunicar com eles ou se é fácil de se comunicar com eles. Eles não se importam se eu coloquei uma seqüência de instruções em um arquivo e mandei executá-las ou se eu estou utilizando uma linguagem de alto nível para gerar essas instruções. Computadores não se importam. Nós nos preocupamos com os seres humanos. Muitas vezes as pessoas, especialmente engenheiros de informática, focam nas máquinas. Eles pensam: “Ao fazer isso, a máquina irá trabalhar mais rápido. Ao fazer isso, a máquina irá funcionar mais eficazmente. Ao fazer isso, a máquina irá fazer alguma coisa qualquer”. Eles estão se concentrando em máquinas. Mas, na verdade precisamos nos concentrar no ser humano, sobre como os seres humanos se preocupam com a programação ou como operam um aplicativo na máquina. Nós somos os mestres. As máquinas são nossos escravos.
Bill Venners: Pelo menos por enquanto.
Yukihiro Matsumoto: Pelo menos por enquanto, até chegarmos na era dos Exterminadores.
O princípio da menor surpresa
Bill Venners: Em uma entrevista, você disse “eu projetei o Ruby para minimizar a minha surpresa. Fiquei muito espantado quando as pessoas ao redor do mundo me disseram que Ruby reduzia a sua surpresa e aumentava a sua alegria ao programar. Agora eu tenho certeza que programadores pensam da mesma maneira no mundo todo.” Por que o principio da menor surpresa?
Yukihiro Matsumoto: Na verdade, eu não fiz a alegação de que Ruby segue o princípio da “menor surpresa”. Alguém sentiu que o design do Ruby segue esta filosofia, então eles começaram a dizer isso. Não foi eu quem inventou isto, na verdade.
Eu queria minimizar minha frustração durante a programação, assim como eu quero minimizar o meu esforço na programação. Esse era o meu principal objetivo na elaboração de Ruby. Eu queria me divertir enquanto programava. Depois de lançar o Ruby e muitas pessoas ao redor do mundo tomarem conhecimento da linguagem, eles começaram a dizer que se sentiam assim como eu me sinto. Eles começaram a citar esta frase sobre o princípio da menor surpresa. Mas, na verdade, isto é muitas vezes mal interpretado.
Bill Venners: Como isto é mal interpretado?
Yukihiro Matsumoto: Cada um possui um passado único. Alguns podem vir do Python, outros podem vir de Perl, e podem ser surpreendidos por diferentes aspectos da linguagem. Então, eles vêm até mim e dizem: “Fiquei surpreso com esta característica da linguagem, assim o Ruby viola o princípio da menor surpresa”. Espere. Espere. Esse princípio não vale apenas para você. O princípio da menor surpresa, também é o principio da minha menor surpresa. Mesmo programadores experientes podem ser surpreendidos. Por exemplo, eu era um programador C++ antes de começar a projetar o Ruby. Eu programei em C++ exclusivamente por dois ou três anos. E após todo este tempo programando em C++, eu ainda me surpreendia.
Atualização (20/01/2010 13:05):
Depois de publicar esse artigo descobri que o Fábio Akita já havia traduzido essa entrevista a alguns anos atrás. Assim, seguem os links para a parte 2, parte 3 e parte 4 da entrevista. Divirta-se!
Não tenho o habito de ler os artigos de Jeff Atwood, talvez por já ter discordado de um grande número deles, mas este em particular achei muito interessante. Embora os oito níveis descritos abaixo representem a realidade de uma forma muito simplificada, acho que são interessantes para nos fazer pensar. Segue a tradução:
Já ouviu a clássica pergunta “onde você se imagina daqui há 5 anos?” em uma entrevista de emprego?
Você quer detonar, naturalmente! Ou pelo menos se tornar o equivalente a uma estrela do rock em desenvolvimento de software. Este não é o tipo de pergunta onde se espera receber uma resposta séria – outra pergunta desta mesma categoria seria “qual é o seu maior defeito?”
Mas particularmente acho que este pergunta é um pouco diferente e merece ser seriamente considerada. Não para o benefício do entrevistador, mas para seu próprio benefício.
A pergunta “onde você se vê em cinco anos” já é uma espécie de clichê e a maioria das pessoas tem uma resposta na ponta da língua preparada para eventuais entrevistas. Mas esta pergunta levanta algumas preocupações mais profundas: qual é o caminho potencial para uma carreira de desenvolvedor de software? Claro, somos apaixonados pela nossa profissão e estamos muito felizes com isso. Mas você ainda estará sentado em frente a um computador programando quando estiver com 50 anos? Com 60 anos? Qual é o melhor resultado possível na carreira de um programador que aspira ser… bem, um programador?
E se eu lhe dissesse que há oito níveis de programadores?
8. Programador Imortal
Este é o nível mais alto. Seu código sobreviveu e transcendeu a sua morte. Você é uma parte do registro histórico permanente da computação. Outros programadores estudam o seu trabalho e as coisas que você escreveu. Você pode ter ganhado um Prêmio Turing, redigido trabalhos influentes ou inventado uma ou mais coisas fundamentais para a área de tecnologia que afetaram o curso da programação como a conhecemos. Você não apenas tem uma entrada na Wikipédia – mas há sites inteiros dedicados a estudar a sua vida e obra.
Muito programadores, embora tenham tentado, nunca atingiram esse nível.
Exemplos: Dijkstra, Knuth, Kay
7. Programador Bem-sucedido
Neste nível encontram-se programadores que além de serem muito conhecidos também criaram uma empresa – talvez até mesmo algumas empresas – em torno de seu código. Estes programadores conseguiram a verdadeira liberdade: a liberdade de decidir por si próprio em que querem trabalhar. E podem compartilhar esta liberdade com seus colegas programadores.
Este é o nível que a maioria dos programadores aspiram chegar. Chegar a este nível muitas vezes depende mais das habilidades em negócios do que em programação.
6. Programador Famoso
Este também é um bom lugar para se estar, desde que você tenha um emprego.
Você é famoso nos círculos de programação. Mas ser famoso não significa necessariamente que você pode transformar isto em lucro e sustentar-se. Ser famoso é bom, mas bem-sucedido é melhor. Você provavelmente trabalha para uma grande e conhecida empresa de tecnologia, uma influente empresa de pequeno porte ou é membro de uma equipe em uma startup. De qualquer maneira, outros programadores já ouviram falar de você, e você está tendo um impacto positivo na área.
5. Programador Profissional
Você tem uma carreira bem sucedida como um desenvolvedor de software. Suas habilidades são valorizadas e você não tem muita dificuldade para encontrar um bom emprego. Seus colegas de trabalho o respeitam. Toda empresa na qual você já trabalhou se tornou melhor e foi enriquecida de alguma forma pela sua presença.
Mas onde você vai chegar?
4. Programador Mediano
Neste nível, você já é um programador bom o suficiente para perceber que você não é um grande programador. E você nunca poderia ser.
Talento na maioria das vezes tem pouco a ver com fazer sucesso. Você pode ser muito bem sucedido se tiver habilidades nos negócios e souber lidar com pessoas. Se você é um programador mediano, e ainda assim consegue sobreviver nesta área, então você é talentoso, mesmo que não necessariamente no ato de codificar.
Não se sinta mal com isto. Taleto é mais raro do que você imagina. Não há nada de errado com a falta de talento. Seja ousado. Descubra em que você é bom, e persiga isto. Seja agressivo.
3. Programador Amador
Um programador amador gosta de codificar e normalmente eles são estudantes promissores ou estagiários, talvez estejam contribuindo para projetos de código aberto, criando aplicativos “just for fun” ou desenhando web sites em seu tempo livre. Seu código e ideias demonstram entusiasmo e que eles tem um bom futuro pela frente.
Ser um amador é uma coisa boa; partindo deste nível pode-se subir rapidamente para se tornar um programador profissional.
2. Programador Desconhecido
É o típico programador comum. Apenas um recurso. Competente (na maioria das vezes), mas normal. Provavelmente trabalha para uma grande e anônima megacorporação. É apenas um funcionário, programar não faz parte da sua vida. Também não há nada de errado com isso.
1. Programador Ruim
Pessoas que de alguma maneira entraram na área de desenvolvimento de software sem um pingo de habilidade ou capacidade. Tudo o que tocam se transforma em dor e sofrimento para os seus colegas programadores – com a possível exceção de outros maus programadores, onde falta ainda a habilidade rudimentar obrigatória para perceberem que eles estão trabalhando com um outro programador ruim.
Esta é talvez, a marca registrada de todos os maus programadores. Essas pessoas simplesmente não possuem nenhuma habilidade para escreverem código, mas de alguma maneira é isto o que fazem.
Estes níveis não são totalmente sérios. Nem todos os programadores aspiram continuar fazendo isto por toda a sua carreira. Mas é esclarecedor considerar o que um programador poderia realizar em dez, vinte ou trinta anos – talvez mesmo uma vida inteira. Quais são os programadores notáveis que você mais admira? O que eles fizeram para merecer a sua admiração?
Em suma, o que você quer fazer com sua vida?
Olhando de fora, as vezes parece que certas empresas ou produtos simplesmente fazem muito sucesso de uma hora para outra, sem nenhum aviso prévio. Na realidade, raramente funciona desse jeito. Pelo menos não para nós.
Cinco anos atrás, quando lançamos o Basecamp, acho que tinhamos menos de 2 mil pessoas assinando o nosso RSS Feed. Adicione a este valor mais algumas pessoas que acessam o site diariamente sem assinar o feed e teremos uma audiência de mais ou menos 5 mil leitores.
Para os padrões atuais, isto é muito pouco! E esta audiência foi conseguida com muito suor no decorrer de alguns anos. Mas era o que tínhamos no momento e foi o suficiente para lançar uma série muito bem sucedida de produtos.
No entanto, não foi o suficiente para nos levar ao topo do dia para noite. Para obter os níveis de hoje, temos contado com a juros compostos desta audiência. Todos os anos, um fluxo constante de novos leitores e clientes se juntam ao bando, enquanto conseguimos manter a maior parte dos leitores antigos.
É por isso que fico extremamente irritado quando alguém diz: “isto só funciona para vocês porque vocês já tiveram um enorme sucesso com seus produtos anteriores”. Esse “enorme sucesso” foi construído cliente a cliente, leitor a leitor. Ninguém nos deu isto de presente. O que estamos compartilhando com vocês é exatamente como chegamos lá e esperamos que nossas experiências e descobertas o ajude a chegar onde você quer estar também.
Então, pare de pensar que você não pode chegar lá porque você não tem uma audiência enorme agora. Comece a criar esta audiência hoje. Comece a juntar pessoas que estão interessadas no que você tem a dizer. Então, em alguns anos, você estará rindo do seu sucesso do dia para noite.
Eu havia planejado um artigo mais técnico para esta semana, mas infelizmente não consegui terminá-lo a tempo. Então vai mais uma tradução de um artigo bem interessante do blog Signal vs. Noise:
Quanto cobrar por seus produtos na internet?
Mattijs perguntou:
Estou desenvolvendo um produto para a internet e está chegando a hora em que será necessário criar uma tabela de preços para este produto. Problema: Não sei nem por onde começar! Fiz algumas pesquisas que mostraram uma ampla gama de produtos semelhantes com regimes de preços totalmente diferentes. Quando a 37signals estava desenvolvendo o Basecamp, como é que vocês definiram os seus preços?
Quando sentamos para decidir os preços do Basecamp pela primeira vez em fevereiro de 2004, decidimos usar os seguintes preços: $9, $19, $39 e $59. Não houve muita ciência por trás disso. Simplesmente perguntamos a nós mesmos:
1. Quanto eu pagaria?
2. Estes números soam bem?
Quanto eu pagaria?
Penso que esta é a pergunta mais importante. Se você está projetando um produto que você vai usar, então é justo perguntar quanto você aceitaria pagar se você fosse comprá-lo de alguém. Os números que surgiram pareciam justos e razoável. 9 dólares era um bom preço inicial enquanto 59 dólares parecia um ótimo preço para o plano mais caro. Já mudamos estes preços, mas esses números funcionaram bem para um produto que ainda era desconhecido no mercado.
Esta linha de pensamento acabou mudando um pouco nosso conceito quando estávamos decidindo os preços de nosso outro produto, o Campfire. Originalmente o preço seria de 5 dólares por chat no Campfire. A ideia era que as pessoas pudessem criar uma sala temporária no Campfire para coincidir com uma reunião ou conferência telefônica. Sentimos que cobrar $5/reunião/ligação seria um preço interessante.
Mas então pensamos um pouco mais sobre isso. Perguntamos a nós mesmos se realmente pegaríamos o cartão de crédito para pagar $5 por algo que usaríamos somente por alguns minutos? Nós decidimos que provavelmente não faríamos isso. Isso mudou todo o foco do produto. A ideia de chats temporários se foi e surgiu então a ideia de uma sala de chat persistente que nunca se fecharia. Então, nós adotamos uma tabela de preços similar a do Basecamp, com o sistema de mensalidades. Estamos confiantes de que tomamos a melhor decisão.
Estes números soam bem?
Há um grande lado psicológico e emocional quando falamos de preços. Um amigo que trabalhava no Wal-Mart, uma vez me disse que lá um preço nunca terminava com um 9. Eles sempre terminavam em 8 (ou 6 ou 4) ou qualquer outro diferente de 9. Eles querem que o cliente saiba que o Wal-Mart está sempre trabalhando duro para diminuir nem que seja um centavo do preço dos produtos – daí o incomum 8 no lugar do familiar 9.
Não adotamos nenhuma regra para decidir nossos preços. Talvez devêssemos adotar uma, mas não fizemos. Nossa linha de preços no Basecamp é de $12, $24, $49, $99 e $149. Estamos mantendo esses preços em vigor por alguns anos e gostamos da combinação. Eles soam bem. Cada nível é praticamente o dobro do nível anterior, mas nós entregamos mais do que o dobro em benefícios.
Por exemplo, no Basecamp Basic ($24/mês), o cliente pode criar até 15 projetos e tem 3GB para armazenamento de arquivos. No Basecamp Plus ($49/mês), o cliente pode criar até 35 projetos (mais do dobro do nível básico) e tem 10GB para armazenamento de arquivos (mais de três vezes o nível básico). Portanto, o preço é o dobro, mas os benefícios são mais do que o dobro. Este padrão persiste em todos os nossos planos de preços.
Você pode mudar os preços, se precisar
Lembre-se que se você decidiu por um preço errado, você pode fazer correções ocasionalmente. Nós fizemos uma grande alteração nos preços do Basecamp e uma alteração menor nos preços do Backpack. Os preços do Backpack mudaram quando lançamos a versão multi-usuário. Reduzimos principalmente os preços dos planos maiores e diminuímos a diferença entre o preço do primeiro nível para o segundo nível (que costumava ser de $5 -> $9, mas foi alterado para $5 -> $7).
A alteração do preço pode ser um pouco dolorosa no curto prazo, mas se você fizer a sua parte, aumentando os benefícios junto com o preço, alertando seus clientes com bastante antecedência sobre o aumento (uns 90 dias, vamos dizer), considerar a possibilidade de manter os preços anteriores para os clientes mais antigos e manter o seu preço justo, a alteração de acontecer sem maiores problemas.
Inicialmente o artigo que se segue seria uma tradução de “The benefits of a monthly recurring revenue model in tough economic times” [Signal vs. Noise], mas como tive de fazer muitas adaptações ao texto durante a tradução, não dá para dizer que é uma tradução literal.
Foto de TomCosta
Empresas como a 37signals vendem seus produtos utilizando um modelo de assinatura mensal. Também dão às pessoas 30 dias para fazerem uma avaliação gratuita dos produtos antes de cobrar a primeira mensalidade.
Acredito que este modelo funciona muito bem na maior parte do tempo, e que ele funciona especialmente bem em tempos difíceis. Nos momentos de crise, obviamente as pessoas procuram gastar menos. Compreender como as pessoas fazem para diminuir os seus gastos pode ajudar muito na hora de escolher o melhor modelo de negócio para os seus produtos.
Existem muitos modelos de negócio para softwares. Aqui estão alguns dos mais populares:
* Freeware
* Freeware, suportado por anúncio
* Um único pagamento adiantado, recebendo atualizações grátis
* Um único pagamento adiantado, com atualizações pagas
* Assinatura anual
* Assinatura mensal
Cortando gastos novos antes de cortar gastos velhos
Eliminar novos gastos é muito mais fácil do que eliminar gastos correntes. Nas horas difíceis a primeira coisas que as pessoas fazem, é simplesmente tentar não adquirir mais dividas, deixando de lado qualquer coisa que possa gerar novos gastos.
Por exemplo, se elas estivem avaliando a compra de um software novo, elas provavelmente irão colocar essa avaliação em espera. Se até agora elas sobreviveram sem este serviço, então poderão continuar sobrevivendo sem comprá-lo. Se uma grande atualização está para vir elas poderão ignorá-la ou simplesmente descarta-la nestas situações.
Mas se eles já estão pagando por um serviço que já utilizam, eles provavelmente irão continuar usando esse serviço. Podem até mudar para um plano mais barato ou tentar negociar o preço, mas se eles consideram este software como algo muito útil, existe uma chance muito alta deles continuarem pagando por isto.
O problema com o modelo de um único pagamento
O problema com o modelo de um pagamento único é que uma vez que o cliente paga por seu produto, acabou. Em tempos difíceis, quando as pessoas congelam novos gastos, você terá mais dificuldade para adquirir novos clientes, o que também significa menos dinheiro entrando. E em casos extremos, você pode simplesmente não adquirir nenhum novo cliente, o que significa nenhuma nova receita. Portanto, se você ficar três meses sem novos clientes, você não terá novas receitas por três meses. Se você não tiver uma boa reserva e esta seca durar realmente uns três meses, existe uma chance bem grande de você quebrar.
O benefício da assinatura anual
Assinaturas anuais são boas porque você ainda tem o potencial de gerar receitas em uma base regular, sem a necessidade de adquirir novos clientes. No entanto, como renovações anuais são inicialmente mais caras que renovações mensais, seus clientes podem pensar duas vezes na hora de renovar a assinatura. E mesmo se estiverem dispostos a renovar, provavelmente tentarão negociar o preço e ameaçarão deixar o serviço se você não oferecer um bom negócio para eles. Eles podem estar blefando, mas em tempos difíceis é especialmente arriscado perder um cliente.
O benefício das assinaturas mensais
Já que novas despesas são cortadas antes das despesas antigas, você poderá ficar um bom tempo sem obter novos clientes. Mas com um modelo de assinatura mensal você ainda estará ganhando à partir do seu rendimento mensal regular com seus clientes existentes.
Se você tem 5000 clientes pagando R$ 10,00 por mês, você estará recebendo R$ 50.000 de receita todo mês, mesmo sem adquirir nenhum novo cliente. E mesmo que alguns clientes cancelem o serviço afim de cortar seus custos, você ainda receberá algum dinheiro todo mês. Fluxos de caixa a partir de assinaturas mensais estão entre os fluxos mais previsíveis que você pode encontrar.
Outro benefício da assinatura mensal é que o custo inicial para novos clientes é menor. Uma assinatura anual pode vir a ser mais barato do que uma assinatura mensal, mas o valor inicial em uma assinatura anual pode assustar muita gente em tempos de crise econômica. As pessoas querem poupar seu dinheiro, e taxas anuais podem fazer isso, mas elas estão pensando a curto prazo e não a longo prazo. Gastos de curto prazo reinam em tempos difíceis, razão pela qual as assinaturas mensais são mais seguras para todos os envolvidos.
Que tal um combo?
Algumas empresas oferecem uma combinação de planos. Planos mensais, anuais ou mesmo assinaturas vitalícias. Mas independente do conjunto de opções, acho que nunca deve-se descartar a opção de uma assinatura mensal.
Apenas um lembrete
As ideias acima não são baseadas em um estudo minucioso do assunto, mas funcionam como um lembrete de que as formas de pagamento que você oferece para seus clientes pode ter um efeito significativo sobre a viabilidade do seu negócio, pelo menos enquanto a crise estiver por aí.
Foto de KS Girl
Antes de iniciar esta tradução eu quero deixar claro que não sei se concordo com tudo o que o artigo expressa, mas achei que é um ponto de vista interessante, então vale a tradução para quem sabe iniciar uma discussão. Segue a tradução:
Converse com alguém que dirige um negócio bem sucedido e pergunte-lhe: “Quando foi a última vez que você olhou para o seu plano de negócios?”. É muito provável que ele nem se lembre onde o deixou.
O artigo “Três Start-Ups, um ano depois” [NY Times] apresentou alguns exemplos de como o plano de negócios original pouco importa uma vez que você está realmente fazendo alguma coisa.
Tina Ericson recentemente encerrou a sua loja online de camisetas, Mamaisms Gear, em Wilmington, NC, sobrecarregada pela tensão que isto estava gerando no seu trabalho corporativo. “Parece que foi ontem que estávamos discutindo os nossos planos para conseguir $100.000 em receita no primeiro ano”, disse a Sra. Ericson. “Cometemos alguns erros bem caros.”…
Ela previu vendas em 2008 no valor de US $100.000 pela Mamaisms Gear, que pretendia oferecer uma ampla linha de camisetas e outros produtos “A minha mãe diz” com slogans como “Pare de chorar.” Ela também comentou sobre criar um site para mulheres e iniciar uma empresa de consultoria para a indústria de serviços financeiros…
Mas, até Junho, com o baixo crescimento econômico, todos os três empresários tiveram de moderar as suas ambições. A Sra. Ericson já tinha abandonado seus planos de criar uma comunidade para mulheres na Internet e de iniciar uma empresa de consultoria para se concentrar no marketing da sua boutique de camisetas.
As outras duas empresas mencionadas no artigo ainda estão na ativa, mas também tiveram de repensar completamente os seus planos originais. Elas tiveram de mudar o foco, serviços, salários, parcerias, etc..
Claro, você pode culpar a economia. Mas este tipo de coisa faz parte do curso, mesmo quando as coisas estão indo bem. Empresas, assim como exércitos, sempre precisam se ajustar aos campos de batalha. Se em um ano estas empresas já estavam tão longe da projeção inicial, imagine o quão inútil seria uma projeção para os próximos três (ou cinco) anos.
Isto suscita a seguinte questão: Por que fazer um plano de negócios se ele é obviamente uma fantasia que não tem nada a ver com a realidade? Se estas projeções são apenas alguns números pescados no ar, porquê perder tempo dando atenção a eles? Se iludir, de forma alguma vai beneficia-lo.
Parece que a maioria das pessoas escrevem planos de negócios, apenas porque eles pensam que supostamente devem ter um. Alguns dizem que um plano de negócios é o que uma empresa “real” precisa, assim pode-se seguir adiante e começar a fazer um monte de merda. É aí que a realidade acontece e toda a merda vai para o ventilador.
Claro, pensar sobre o futuro pode ajudar. Mas documentar, e manter isto como um tipo de plano é tolice. A verdade é que você não vai saber o que fazer até que você esteja realmente fazendo isso.
Este texto é uma tradução do artigo “When was the last time you looked at your business plan?” escrito por Matt Linderman.
Foto de Joi
Para ser verdadeiramente inspirado por um grande trabalho, é preciso saber que você está fazendo a diferença. Que você está adicionando algo de valor ao universo. Que você é parte de algo que fará a diferença e que você tem um papel significativo nisso.
Para fazer a diferença você não precisa estar fazendo algo necessariamente grande. Você não tem de estar à procura da cura para o câncer. Mesmo uma garçonete de uma lanchonete do bairro pode estar fazendo a diferença. O fundamento é que seus esforços seriam perdidos e seus clientes teriam uma sensação de perda se você parasse de fazer o que você está fazendo.
Se o que você estiver fazendo não tiver um propósito, o prazer no seu trabalho acabará e você sentirá um vazio. Eu vivi essa sensação mais de uma vez. Eu trabalhava com ferramentas, técnicas e até mesmo com pessoas que eu gostava, mas o fim não justifica a viagem.
Você só pode se esconder nas sombras dessas circunstancias até o momento em que sua paixão começa a sumir. Você só pode desculpar sua falta de impacto sobre o mundo com “mas é muito dinheiro” ou “pelo menos estamos fazendo de forma ágil” ou mesmo “desta forma eu posso continuar usando Rails” até que a lista de histórias se repita e tudo comece a soar igual.
Lembre-se que seu tempo é limitado. Quando você descobrir que só está comendo alimentos sem calorias, olhará seu rosto pálido no espelho e verá que pode ser difícil de se reconhecer.
Lembro-me de acordar com esta cara um dia, há muito tempo atrás, e pensar que “o mundo estaria exatamente igual se eu não estivesse por aqui nos últimos seis meses”. É um sentimento terrível de arrependimento.
Mas a boa notícia é que nunca é tarde demais para fazer alguma coisa. Eu abriria mão de uma atmosfera aconchegante no trabalho e da oportunidade de utilizar uma ferramenta que gosto de usar se o preço for ter de fazer um trabalho que simplesmente não importa. Você também deveria fazer isso.
Este texto é uma tradução de um artigo do blog Signal vs. Noise.
Quando você estiver contratando, procure por pessoas que gerenciem a si mesmas.
O que isto significa? Um gerente de si mesmo é alguém que tem as suas próprias metas e às executa. Eles não precisam ser direcionados o tempo todo. Eles não precisam de check-ins diários. Eles fazem o que um gerente faria – definem o tom, atribuem tarefas, determinam o que precisa ser feito, etc – mas fazem isto por si e para si.
Essas pessoas te livram do trabalho de supervisão. Elas definem sua própria direção. Quando você os deixá sozinho, eles o surpreendem com o quanto fizeram. Elas não precisam de muitas instruções ou supervisão.
Como você pode detectar essas pessoas? Olhe para a sua história. Eram auto-suficientes em empregos anteriores? Já definiram seu papel antes? Já iniciaram seu próprio site ou empresa antes? Ou inventaram sua própria maneira de fazer as coisas? Encontre alguém com iniciativa e com um espírito empreendedor florescendo. E então, alimente este espirito.
Você quer alguém que é capaz de construir algo à partir do nada. Quando você encontrar essas pessoas, elas liberarão o resto de sua equipe para trabalhar mais e gerenciar menos.
Este texto é uma tradução de um artigo do blog Signal vs. Noise.
Esta semana estou trocando o telhado da minha casa. Eu pesquisei, fiz cotações, escolhi uma empresa e eles já estão trabalhando nisso agora.
Eles estão trabalhando nisto há dois dias até agora, mas já fui surpreendido por duas vezes. Isto me fez lembrar de como é importante definir as expectativas de seus clientes.
Dia um
Eles arrancaram o telhado antigo. Você não pode ver o céu, são apenas telhas velhas, o teto ainda está lá. Eu não tinha ideia da bagunça que isto iria fazer no piso superior da minha casa. Lascas de pintura, poeira do telhado caindo através de algumas fissuras e a remoção das claraboias. Acho que eu deveria ter previsto que isto aconteceria, mas eu nunca tinha feito isto antes.
Teria sido ótimo se a empresa dissesse…
“Ei, quando arrancarmos o telhado antigo pode ser que caia alguma poeira preta e lascas da pintura no piso superior. Talvez você queira cobrir seus móveis ou outras coisas de valor para o caso de isto acontecer.”
Dia dois
Estão queimando alguma coisa lá fora. Eu não sabia que teriam de queimar algo. Eu estava trabalhando em casa e imaginando como seria o cheiro de ácido queimado e de fumaça pela casa. Agora eu sei como é.
Teria sido ótimo se eles dissessem…
“Ei, hoje vamos trabalhar com tochas e materiais tóxicos. Um pouco de fumaça e gases podem entrar na casa durante este processo. Talvez seja melhor você sair de casa, enquanto estivermos fazendo isso.”
Dia três
Não tenho a menor ideia do que vem a seguir. O que acontecerá amanhã? Eles não dizem nada, apenas fazem e então você descobre.
Seria muito bom se no final de cada dia eles dissessem…
“Ei, até agora terminamos AB e C. Amanhã vamos fazer D. Assim você já saberia o que esperar.”
Definir as expectativas é a chave
Eu confio no trabalho deles, mas a experiência tem sido amarga pela falta de expectativas. Bastaria me dar uma ideia do que iria acontecer hoje e amanhã e nossa experiência seria significativamente melhor.
Eu confio no trabalho deles, mas a experiência tem sido amarga pela falta de expectativas
Este texto é uma tradução de um artigo escrito por Jason Fried para o blog Signal vs. Noise.
gabriela em 
biker solitario em 