http://gettingreal.37signals.com/GR_por.

php (em 11 de junho de 2012)

Caindo na Real
Bem vindos primeira das tradues mundiais completa do livro 'Getting Real'.
Totalmente em Portugus.

Introduo captulo 1

O que Caindo na Real?

Quer construir uma aplicao web de sucesso? Ento hora de Cair na Real. Caindo na
Real o menor, mais rpido e melhor caminho para construir software.

Caindo na Real sobre pular todas as coisas que representam a realidade (cartas,
grficos, caixas, setas, esquemas, wireframes, etc.) e realmente construir a coisa
real.
Caindo na Real menos. Menos massa, menos software, menos funcionalidades,
menos papis, menos tudo que no essencial (e a maioria do que voc pensa
ser essencial realmente no ).
Caindo na Real permanecer pequeno e ser gil.
Caindo na Real inicia com a construo da interface, ou seja, as telas reais que
as pessoas iro utilizar. Comea com as experincias reais dos clientes,
construindo a partir disso para trs. Dessa forma voc obtm a interface
adequada antes de obter um software errado.
Caindo na Real sobre iteraes e baixar os custos da mudana. Caindo na Real
tem tudo a ver com lanamento, refinamento e melhorar constantemente, o que o
torna o caminho perfeito para software baseado em web.
Caindo na Real entrega exatamente o que os clientes precisam e elimina
qualquer coisa que no precisam.

Os benefcios de Caindo na Real

Caindo na Real entrega melhores resultados porque o fora a lidar com os problemas
reais que est tentando resolver em vez de suas ideias sobre esses problemas. Ele o fora
a lidar com a realidade.

Caindo na Real pula especificaes funcionais e outras documentaes transitrias em

favor de construir telas reais. Uma especificao funcional para ingls ver, uma iluso
de um acordo, enquanto uma pgina web pronta realidade. isso que seus clientes
iro ver e usar. isso que importa. Caindo na Real o leva l mais rpido. E isso
significa que est tomando decises de software baseado na coisa real em vez de noes
abstratas.

Finalmente, Caindo na Real a maneira que se encaixa idealmente para software

baseado em web. O modelo convencional de entregar software em uma caixa e ento

1
esperar um ano ou dois para entregar uma atualizao est desaparecendo. Diferente de
software instalado, aplicaes web podem evoluir constantemente de maneira diria.
Caindo na Real abre essa vantagem por tudo que ele vale.

Como Escrever Software Vigoroso

Escrita vigorosa concisa. Uma sentena no deve conter palavras desnecessrias, um

pargrafo no deve conter sentenas desnecessrias, pela mesma razo que desenhar no
deve ter linhas desnecessrias e uma mquina no deve ter partes desnecessrias. Isso
requer no que o escritor torne todas as sentenas curtas ou evite todos os detalhes e
trate os assuntos apenas em tens, mas sim que cada palavra fale.

De "Os Elementos de Estilo" de William Strunk Jr.

Sem mais gordura

Da forma antiga: um processo comprido, burocrtico, estamos-fazendo-isso-para-
proteger-nossas-bundas. O resultado tpico: software gorduroso, esquecvel, vazando em
mediocridade. Eca.

Caindo na Real se livra de ...

Cronogramas que levam meses ou mesmo anos
Especificaes Funcionais Utpicas
Debates de Escalabilidade
Reunies de equipe interminveis
A "necessidade" de contratar dzias de funcionrios
Nmeros de verses sem sentido
Planejamentos cristalinos que preveem o futuro
Opes de preferncia interminveis
Suporte terceirizado
Testes de usurio irreais
Papelada intil
Hierarquia de cima-para-baixo

Voc no precisa de toneladas de dinheiro ou uma equipe enorme ou um ciclo de

desenvolvimento longo para construir grandes softwares. Essas coisas so ingredientes
para aplicaes lentas, esfumaadas, que no mudam. Caindo na Real usa o caminho
oposto.

Nesse livro lhe mostraremos ...

A importncia de ter uma filosofia
Por que se manter pequeno uma coisa boa
Como construir menos
Como ir de ideia realidade rapidamente
Como montar sua equipe
Por que voc deve fazer design de dentro para fora
Por que escrever to crucial
Por que voc deve fazer menos que sua concorrncia

2
 Como promover sua aplicao e espalhar a palavra
Segredos para um suporte de sucesso
Dicas de como manter o momento depois do lanamento
... e muito mais

O foco emideiaamplas. No vamos entedi-lo com trechos de cdigo detalhados ou

truques de css. Vamos nos manter nas grandes ideias e filosofias que dirigem o processo
Caindo na Real.

Esse livro para voc?

Voc um empreendedor, designer, programador ou marketeiro trabalhando em uma
grande ideia.

Voc percebe que as velhas regras no se aplicam mais. Distribui seu software em cd-
roms a cada ano? Que 2002. Nmeros de verso? Jogue pela janela. Voc precisa
construir, lanar e refinar. Ento recomece e repita.

Ou talvez voc ainda no esteja a bordo do desenvolvimento gil e estruturas de

negcios, mas est louco para aprender mais.

Se isso soa como voc, ento esse livro para voc

Nota: enquanto este livro enfatiza em construir aplicaes web, um monte de ideias so
aplicveis para atividades que no so de software tambm. As sugestes sobre equipes
pequenas, prototipao rpida, esperar iteraes e muitas outras apresentadas aqui
podem servir como um guia seja se estiver comeando um negcio, escrevendo um
livro, fazendo o design de um site web, gravando um lbum ou fazendo uma variedade
de outras coisas. Uma vez que comear Caindo na Real em uma rea de sua vida, ver
que esses conceitos podem ser aplicados para uma ampla variedade de atividades.

Sobre a 37signals
O que fazemos
37signals uma pequena equipe que cria software simples e focado. Nossos produtos o
ajudam a colaborar e se organizar. Mais de 350 mil pessoas e pequenos negcios usam
nossas aplicaes web para fazer suas coisas. Jeremy Wagstaff, do Wall Street Journal,
escreveu os produtos da 37signals so ferramentas maravilhosamente simples,
elegantes e intuitivas que fazem uma tela de Outlook parecer um equivalente em
software de uma cmara de tortura. Nossos aplicativos nunca pe voc no pau de arara.

Nosso modus operandi

Acreditamos que software muito complexo. Funcionalidades demais, botes demais,
coisa demais para aprender. Nossos produtos fazem menos do que a concorrncia

3
intencionalmente. Construmos produtos que funcionam de forma mais esperta, que
parecem melhor, que lhe permitem fazer suas coisas e so mais fceis de usar.

Nossos produtos
At a data de publicao desse livro, temos cinco produtos comerciais e um framework
open source de aplicaes web.

Basecamp vira a cabea de gerenciamento de projetos. Em vez de tabelas Gantt,

grficos engraadinhos e planilhas lotadas de estatsticas, Basecamp oferece painis de
mensagens, listas de tarefas, cronograma simples, escritas colaborativas e
compartilhamento de arquivos. At agora, centenas de milhares concordam que a
melhor maneira. Farhad Manjoo, da Salon.com disse que Basecamp representa o futuro
de software na Web.

Campfire traz um simples chat em grupo para o contexto de negcios. As empresas

conhecidas entendem quo valioso um chat persistente em tempo real pode ser.
Mensagens instantneas convencionais so timas para conversas entre duas pessoas,
mas so miserveis para 3 ou mais pessoas de uma s vez. Campfire resolve esse
problema e muito mais.

Backpack a alternativa para aqueles confusos, complexos organize sua vida em 25

simples passos gerenciadores de informaes pessoais. A tirada de Backpack com
pginas, anotaes, lista de tarefas e avisos via telefones celulares / e-mail so ideias
inovadoras em uma categoria de produtos que sofre com o status quo. Thomas Weber,
do Wall Street Journal disse que o melhor produto na sua classe e David Pogue, do
New York Times o chamou de uma ferramenta de organizao muito legal.

Writeboard deixa voc escrever, compartilhar, revisar e comparar texto, sozinho ou com
outros. a alternativa refrescante dos gordurosos processadores de texto que so demais
para 95% do que voc escreve. John Gruber, da Daring Fireball disse Writeboard deve
ser a aplicao web mais clara e simples que j vi. O guru de Web, Jeffrey Zeldman
disse as mentes brilhantes da 37signals fizeram novamente.

Ta-da List mantm todas as suas listas de tarefas juntas e organizadas online. Mantenha
as listas para voc ou compartilhe com outros para fcil colaborao. No existe jeito
mais fcil de terminar suas coisas. Mais de 100 mil listas e perto de 1 milho de tens
foram criadas at agora.

Ruby on Rails, para desenvolvedores, um framework web completo, open source para
escrever aplicao para o mundo real rapidamente e facilmente. Rails toma conta do
trabalho pesado para que voc possa focar na sua ideia. Nathan Torkington, do imprio
editorial OReilly disse que Ruby on Rails incrvel. Us-lo como assistir a um filme
de kung-fu, onde uma dzia de frameworks maus se preparam para atacar o novato
apenas para apanharem de uma variedade de formas imaginativas. No tem como no
gostar dessa citao.

Voc pode encontrar mais sobre nossos produtos e nossa companhia no nosso site web
em www.37signals.com.

4
Avisos, Condies e outros Ataques
Antecipados
Apenas para tirar isso do caminho, aqui esto nossas respostas para algumas
reclamaes que ouvimos de vez em quando:

Essas tcnicas no funcionaro para mim

Caindo na Real (Getting Real) um sistema que funcionou excelentemente para ns.
Dito isso, as ideias nesse livro no se aplicaro a todos os projetos abaixo do Sol. Se
estiver construindo um sistema de armas, uma usina de controle nuclear, um sistema
bancrio para milhes de clientes ou outro sistema crtico vital/financeiro, voc ir latir
a algumas de nossas atitudes. V em frente e tome precaues adicionais.

E no precisa ser uma proposio do tipo tudo ou nada. Mesmo que no possa abraar
Caindo na Real completamente, devem existir pelo menos algumas ideias aqui que voc
possa tentar usar.

Vocs no inventaram essa ideia

No estamos afirmando que inventamos essas tcnicas. Muitos desses conceitos esto
por a de uma forma ou de outra h um bom tempo. No fique nervoso de ler algum de
nossos conselhos e isso o lembrar de alguma coisa que j leu mais ou menos em algum
weblog ou algum livro publicado 20 anos atrs. definitivamente possvel. Essas
tcnicas no so todas exclusivas da 37signals. Apenas estamos dizendo como ns
trabalhamos e o que tem feito sucesso para ns.

Vocs levam tudo para uma viso muito preto-no-

branco
Se nosso tom parecer muito convencido, conviva com isso. Achamos que melhor
apresentar ideias de maneira enftica do que ser escorregadio sobre isso. Se parecer
grosseiro ou arrogante, que assim seja. Preferimos ser provocativos do que diluir tudo
com isso depende Claro, haver momentos quando essas regras preciso ser
esticadas ou quebradas. E algumas dessas tticas podem no se aplicar sua situao.
Use seu julgamento e imaginao.

Isso no funcionar dentro da minha empresa

Acha que voc grande demais para Cair na Real (Getting Real)? Mesmo a Microsoft
est Caindo na Real (e duvidamos que voc seja maior do que eles).

Mesmo que sua empresa funcione tipicamente com cronogramas de longo prazo e com
grandes equipes, ainda existem maneiras de Cair na Real. O primeiro passo quebrar
em pequenas unidades. Quando existem pessoas demais envolvidas, nada acontece.
Quanto mais enxuto voc for, mais rpido e melhor as coisas acontecem.

5
Entretanto, isso vai requerer alguma conversa de vendas. Venda a ideia do processo
Caindo na Real na sua empresa. Mostre a eles esse livro. Mostre a eles os resultados
reais que voc pode atingir em menos tempo e com equipes menores.

Explique que Caindo na Real uma maneira de baixo risco, baixo investimento para
testar novos conceitos. Veja se voc pode se separar da nave-me em um projeto menor,
como prova de conceito. Demonstre resultados.

Ou, se quiser ser corajoso, v silenciosamente. Voe abaixo do radar e demonstre

resultados reais. Essa foi a forma que a equipe da Start.com usou na Microsoft. Eu
observei a equipe da Start.com trabalhar. Eles no pedem permisso, disse Robert
Scoble, Technical Evangelist da Microsoft. Eles tem um chefe que fornece cobertura
area. E eles mordem um pequeno pedao de cada vez, fazem isso e respondem a
feedback.

Lanando Start.com da Microsoft

Em uma grande empresa, processos e reunies so normais. Muitos meses so gastos

em planejamento de funcionalidades e discutindo detalhes com a finalidade de todos
alcanarem um acordo sobre o que a coisa certa para o cliente.

Essa pode ser a forma certa para softwares de prateleira, mas com a web ns temos uma
incrvel vantagem. Apenas lance! Deixe o usurio lhe dizer se a coisa certa ou no. Ei,
voc pode corrigir e lanar na web no mesmo dia, se quiser! No existe palavra mais
forte do que do cliente resista presso de se engajar em longas reunies e discusses.
Apenas lance e prove seu ponto.

Mais fcil falar do que fazer isso implica:

Meses de planejamento no so necessrios.

Meses escrevendo especificaes no so necessrios especificaes devem ter as
fundaes pregadas e os detalhes entendidos e refinados durante a fase de
desenvolvimento. No tente fechar todos os pontos abertos e pregar cada detalhe antes
de comear a desenvolver.

Lance menos funcionalidades, mas de qualidade.

Voc no precisa usar a forma big bang com todo novo lanamento e amontoados de
funcionalidades. D aos usurios pedaos minsculos que eles possam digerir.

Se existirem pequenos bugs, lance to logo tenha os cenrios principais pregados e

disponibilize as correes dos bugs gradualmente depois disso. Quanto mais rpido
tiver o feedback do usurio, melhor. Ideias podem soar timas no papel, mas na prtica
acabam sendo menos do que boas. Quanto mais cedo descobrir sobre pontos
fundamentais que esto errados com uma ideia, melhor.

Uma vez que voc estiver iterando rapidamente e reagindo ao feedback dos clientes,
estabelecer uma conexo com eles. Lembre-se que o objetivo ganhar o cliente
construindo o que eles querem.

Sanaz Ahari, Gerente de Programa da Start.com, Microsoft

6
A Linha de Largada captulo 2

Construa Menos
Faa menos que sua competio
O senso comum diz que para vencer seus competidores, voc precisa estar um passo a
frente. Se eles possuem quatro funcionalidades, voc precisa de cinco (ou 15, ou 25). Se
eles gastam X, voc precisa gastar XX. Se eles tm 20, voc precisa 30.

Este tipo de estratgia, a Guerra Fria de estar um passo a frente, leva a uma briga sem
fim. Trabalhar assim caro, defensivo e paranoico. Empresas defensivas e paranoicas
no pensam para frente, eles pensam apenas no passado. Elas no lideram, elas seguem.

Se voc quer construir uma empresa que segue, este livro no para voc.

Mas ento, e ai? A resposta menos. Faa menos que a concorrncia para desbanc-los.
Resolva os problemas simples, deixe os problemas cabeludos, difceis e desesperadores
para os outros. Ao invs de estar um passo a frente, esteja um passo atrs. Ao invs de
se superar, tente manter-se dentro do seu potencial.

Veremos o conceito de menos durante o livro, mas para os iniciantes, menos significa:

Menos funcionalidades
Menos opes/preferncias
Menos pessoas e estrutura empresarial
Menos reunies e abstraes

Qual o Seu Problema?

Construa software para voc mesmo
Uma grande maneira de escrever software comear resolvendo seus prprios
problemas. Voc ser o pblico-alvo e saber o que importante e o que no . Isso lhe
d um bom adiantamento na entrega de um produto fora de srie.

A chave aqui entender que no est sozinho. Se estiver tendo problemas, provvel
que centenas de milhares de outras pessoas esto no mesmo barco. Esse seu mercado.
No foi fcil?

Basecamp se originou em um problema: como uma empresa de design, precisvamos de

uma maneira simples de comunicar nossos clientes sobre os projetos. Comeamos
fazendo isso atravs da extranet dos clientes, que atualizvamos manualmente. Mas
modificar o HTML na mo toda vez que o projeto precisava ser atualizado
simplesmente no estava funcionando. Esses sites de projetos sempre pareciam ficar

7
travados e eventualmente eram abandonados. Era frustrante porque nos deixava
desorganizados e deixava os clientes no escuro.

Ento comeamos a procurar outras opes. Ainda assim cada ferramenta que
encontrvamos ou 1) no fazia o que precisvamos ou 2) era gorda de funcionalidades
que no precisvamos como cobrana, controles estritos de acesso, planilhas, grficos,
etc. Sabamos que deveria haver uma maneira melhor ento decidimos construir nossa
prpria.

Quando resolvemos nossos prprios problemas, criamos uma ferramenta que nos
apaixona. E paixo a chave. Paixo significa que realmente a usaremos e cuidaremos
dela. E essa a melhor maneira de fazer os outros se sentirem apaixonados sobre ela
tambm.

Arranhando sua prpria coceira

O mundo de Cdigo Aberto abraou esse mantra h muito tempo eles chamam de
arranhando sua prpria coceira. Para os desenvolvedores de cdigo aberto, significa
que tero as ferramentas que querem, entregues da maneira que querem. Mas os
benefcios vo mais a fundo.

Como designer ou desenvolvedor de uma nova aplicao, voc precisa encarar centenas
de micro-decises todos os dias: azul ou verde? Uma tabela ou duas? Esttica ou
dinmica? Abortar ou recuperar? Como tomamos essas decises? Se for algo que
reconhecemos como importante, poderamos perguntar. O resto, chutamos. E todos
esses chutes constroem um tipo de dbito em nossas aplicaes uma rede
interconectada de coisas que assumimos.

Como um desenvolvedor, detesto isso. O conhecimento de todas essas bombas-relgio

em pequena escala nas aplicaes que escrevo soma-se ao meu stress. Desenvolvedores
de cdigo aberto, arranhando suas prprias coceiras, no sofrem isso. Porque eles so
seus prprios usurios, eles sabem a resposta correta para 90% das decises que
precisam tomar. Acho que uma das razes que as pessoas chegam em casa aps um
dia duro de trabalho de codificao e ainda trabalham com cdigo aberto: relaxante.

Dave Thomas, The Pragmatic Programmers

Nascido da necessidade

Campaign Monitor realmente nasceu na necessidade. Por anos nos frustramos com a
qualidade das opes de marketing por e-mail que existiam por a. Uma ferramenta
fazia x e y, mas nunca z, a prxima tinha y e z, mas simplesmente no podia ter x
direito. No podamos vencer.

Decidimos liberar a agenda e comear a construir nossa ferramenta de marketing por e-

mail dos sonhos. Conscientemente decidimos no olhar para o que os outros estavam
fazendo e em vez disso construir algo que fizesse nossas vidas, e a de nossos clientes,
um pouco mais fceis.

Depois descobrimos que no ramos os nicos que estavam infelizes com as opes que
existiam. Fizemos algumas modificaes ao software de forma que qualquer empresa de
design pudesse us-lo e comeamos a espalhar a palavra. Em menos de seis meses,

8
milhares de designers estavam usando Campaign Monitor para enviar informativos por
e-mail para eles mesmos e seus clientes.

David Greiner, fundador, Campaign Monitor

Voc precisa se importar sobre isso

Quando voc escreve um livro, precisa de mais do que uma histria interessante. Precisa
ter um desejo de contar a histria. Precisa investir pessoalmente de alguma maneira. Se
vai viver com alguma coisa por dois anos, trs anos, o resto de sua vida, precisa se
importar sobre isso.

Malcolm Gladwell, autor (de Algumas Finas Fatias de Malcolm Gladwell)

Financie Voc Mesmo

Dinheiro de fora plano B
A primeira prioridade de muitas empresas iniciantes adquirir fundos de investidores.
Mas lembre-se, se nos viramos para gente de fora para fundos, teremos que responder a
eles tambm. Crescem expectativas. Investidores querem seu dinheiro de volta e
rapidamente. O fato triste que dinheiro entrando nem sempre significa a construo de
um produto de qualidade.

Atualmente no preciso muito para comear. Hardware barato e uma boa parte de
grandes softwares de infra-estrutura so cdigo aberto e de graa. E paixo no vem
com uma etiqueta de preo.

Ento faa o que puder com o dinheiro que tem em mos. Pense muito e determine o
que realmente essencial e o que pode viver sem. O que pode fazer com trs pessoas
em vez de dez? O que pode fazer com R$ 40 mil em vez de R$ 200 mil? O que pode
fazer em trs meses em vez de seis? O que pode fazer se puder manter seu emprego e
construir sua aplicao nas horas vagas?

Restries foram a criatividade

Dirija com recursos limitados e ser forado a contar com restries mais cedo e mais
intensamente. E isso uma coisa boa. Restries dirigem inovao.

Restries tambm o foram a liberar sua ideia para fora mais cedo em vez de mais
tarde outra coisa boa. Um ms ou dois fora das porteiras devem lhe dar uma boa ideia
se voc est em algo slido ou no. Se estiver ser autossustentvel logo e no precisar
de dinheiro externo. Se sua ideia estiver furada, hora de voltar prancheta de desenho.
Pelo menos sabe disso agora em vez de meses (ou anos) para frente. E pelo menos pode
voltar atrs mais facilmente. Planos de sada se tornam bem complicados quando
investidores esto envolvidos.

9
Se estiver criando software apenas para fazer um dinheiro rpido, isso vai aparecer. Um
retorno rpido bem improvvel. Ento foque em construir uma ferramenta de
qualidade que voc e seus clientes podero viver com por um bom tempo.

Dois caminhos

[Jake Walker comeou uma companhia com dinheiro de investidores (Disclive) e um

sem (The Show). Aqui ele discute as diferenas entre os dois caminhos.]

A raz de todos os problemas no foi conseguir dinheiro, mas tudo que veio junto com
ele. As expectativas so simplesmente mais altas. As pessoas comeam tomando
salrios e a motivao para construir e depois vender, ou encontrar outra maneira para
os investidores iniciais terem seu dinheiro de volta. No caso da primeira empresa,
simplesmente comeamos a agir como se fssemos muito maiores do que realmente
ramos sem necessidade

[Com The Show] percebemos que poderamos entregar um produto muito melhor com
menos custo, apenas com mais tempo. E apostamos com um pouco de nosso prprio
dinheiro que as pessoas iriam esperar por mais qualidade em vez de velocidade. Mas a
empresa se manteve (e provavelmente continuar sendo) uma operao pequena. E
desde esse primeiro projeto, estamos totalmente autofinanciados. Com apenas um pouco
de criatividade de nossos fornecedores, nunca mais realmente precisamos colocar muito
de nosso prprio dinheiro na operao. E a expectativa no era de crescer e vender, mas
de crescer por crescer e continuar se beneficiando disso financeiramente.

Um comentrio de Signal vs. Noise

Fixe o Prazo e o Oramento, Flexibilize o

Escopo
Lance dentro do prazo e do oramento
Aqui vai uma maneira fcil de lanar dentro do prazo e do oramento: mantenha-os
fixos. Nunca jogue mais tempo ou dinheiro em um problema, apenas diminua o escopo.

Existe um mito que diz o seguinte: podemos lanar no prazo, no oramento e no escopo.
Isso quase nunca acontece e quando acontece a qualidade normalmente sofre.

Se no puder encaixar tudo dentro do prazo e oramento planejados ento no aumente

o tempo e o custo. Em vez disso, puxe o escopo para trs. Sempre existe tempo para
adicionar coisas mais tarde o mais tarde eterno, o agora est voando.

Lanar alguma coisa grande que est um pouco menor em escopo do que o planejado
melhor do que lanar alguma coisa medocre e cheio de buracos porque precisou atingir
uma janela mgica de prazo, oramento e escopo. Deixe a mgica para Houdini. Voc
tem um negcio de verdade para administrar e um produto real para entregar.

10
Aqui vo os benefcios de fixar o prazo e oramento e manter o escopo flexvel:

Priorizao

Precisaremos descobrir o que realmente importante. O que vai chegar ao

lanamento inicial? Isso fora uma restrio que o pressionar a tomar decises
difceis em vez de ficar hesitando.

Realidade

Configurar expectativas a chave. Se tentar fixar o prazo, oramento e escopo,

no ser capaz de entregar com um alto grau de qualidade. Claro, provavelmente
poder entregar alguma coisa, mas alguma coisa o que realmente quer
entregar?

Flexibilidade

A habilidade de mudar a chave. Ter tudo fixado torna as mudanas difceis.

Injetar flexibilidade de escopo apresentar opes baseadas em sua experincia
real de construir o produto. Flexibilidade seu amigo.

Nossa recomendao: abaixo o Escopo. melhor fazer meio-produto do que um

produto meia-boca (mais sobre isso depois).

Um, dois, trs ...

Como um projeto chega a estar um ano atrasado? Um dia de cada vez.

Fred Brooks, engenheiro de software e cientista da computao

Tenha um Inimigo
Pegue uma briga
Algumas vezes a melhor maneira de saber como sua aplicao deve ser saber o que ela
no deve ser. Descubra o inimigo da sua aplicao e voc acender uma luz para onde
precisa ir.

Quando decidimos criar um software de gerenciamento de projetos, sabamos que

Microsoft Project era o gorila na sala. Em vez de temer o gorila, o usamos como
motivador. Decidimos que Basecamp seria algo completamente diferente, o anti-Project.

Entendemos que gerenciamento de projetos no sobre tabelas, grficos, relatrios e

estatsticas sobre comunicao. Tambm no sobre um gerente de projetos
sentando l no alto e distribuindo um plano de projetos. sobre todos assumindo
responsabilidades juntos para fazer o projeto funcionar.

11
Nossos inimigos eram os Gerentes de Projetos Ditadores e as ferramentas que eles
usavam para chicotear. Queramos democratizar o gerenciamento de projetos faz-lo
de forma que todos fizessem parte (incluindo o cliente). Projetos se do melhor quando
todos assumem propriedade coletiva do processo.

Quando chegou a vez do Writeboard, sabamos que haviam competidores l fora com
toneladas de funcionalidades. Ento decidimos enfatizar em um ngulo sem frescura.
Criamos uma aplicao que permite s pessoas compartilhar e colaborar nas ideias de
maneira simples, sem incomod-las com funcionalidades no-essenciais. Se no era
essencial, deixamos de fora. E em apenas trs meses depois do lanamento, mais de 100
mil Writeboards foram criados.

Quando comeamos no Backpack nosso inimigo era estrutura e regras rgidas. As

pessoas devem ser capazes de organizar suas informaes de sua prpria maneira no
baseado em uma srie de telas pr-formatadas ou uma montanha de campos de edio
obrigatrios.

Um bnus que voc recebe em ter um inimigo uma mensagem de marketing muito
clara. As pessoas esto cheias de conflitos. E tambm entendem um produto
comparando-o com outros. Com um inimigo escolhido, voc est enviando uma histria
que eles querem ouvir. No s eles vo entender seu produto melhor e mais rpido, mas
vo tomar um lado. E essa uma maneira garantida de chamar a ateno e acender uma
paixo.

Agora, com tudo isso dito, tambm importante no ficar muito obcecado com a
concorrncia. Analise demais outros produtos e voc vai comear a limitar sua maneira
de pensar. D uma olhada e v em frente para sua prpria viso e suas prprias ideias.

No siga o lder

Marketeiros (e todos os seres humanos) so bem treinados para seguir o lder. O instinto
natural descobrir o que funciona para a concorrncia e ento tentar super-los em ser
mais barato que seu competidor que compete no preo, ou mais rpido que seu
competidor que compete na velocidade. O problema que uma vez que o consumidor j
comprou a histria de algum e acredita nessa mentira, persuad-lo a mudar a mesma
coisa que persuad-lo a admitir que estava errado. E as pessoas odeiam admitir que esto
erradas.

Em vez disso, voc deve dizer uma histria diferente e persuadir os ouvintes que sua
histria mais importante do que a histria que eles acreditam atualmente. Se sua
competio mais rpida, voc deve ser mais barato. Se eles vendem a histria de
sade, voc deve vender a histria da convenincia. No apenas o posicionamento
cartesiano x/y do tipo Somos mais baratos, mas uma histria real que
completamente diferente da histria que j foi contada.

Seth Godin, autor/empresrio (de Seja um Mentiroso Melhor)

Qual o problema chave?

Uma das maneiras mais rpidas de se colocar em problemas olhar o que seus
competidores esto fazendo. Isso foi especialmente verdade para ns na BlinkList.
Desde que lanamos houveram cerca de 10 outros servios de bookmarking social que

12
foram lanados. Algumas pessoas at comearam a gerar planilhas online com
comparaes funcionalidade a funcionalidade.

Entretanto, isso pode rapidamente levar ao erro. Em vez disso, permanecemos focados
na figura maior e continuamos nos perguntando, qual o problema chave que estamos
tentando resolver e como podemos resolv-lo.

Michael Reining, co-fundador, MindValley & Blinklist

No Deveria ser uma Rotina

Sua paixo ou falta de vo aparecer
Quanto menos sua aplicao se tornar uma rotina para construir, melhor ser. Mantenha
pequena e gerencivel para que possa realmente apreciar o processo.

Se sua aplicao no o excita, algo est errado. Se est trabalhando nela apenas para
ganhar dinheiro, isso vai aparecer. Da mesma forma, se voc se sentir apaixonado pela
aplicao, tambm vai aparecer no produto final. As pessoas conseguem ler nas
entrelinhas.

A preseno de paixo

Em design, onde o significado normalmente e controversamente subjetivo ou

dolorosamente indecifrvel, poucas coisas so mais aparentes e lcidas do que a
presena de paixo. Isso verdade seja quando o design do produto o agrada ou o deixa
frio; em ambos os casos difcil no detectar o investimento emocional das mos que o
construram.

Entusiasmo se manifesta prontamente, claro, mas indiferena igualmente inesquecvel.

Se seu compromisso no vem com paixo genuna para o trabalho s mos, isso se torna
um vazio que quase impossvel de conciliar, no importa o quo elaborado ou atrativo
o design.

Khoi Vinh, Subtraction.com

A padaria

Os negcios americanos neste momento realmente so sobre desenvolver ideias, torn-

las lucrativas, vend-las enquanto so lucrativas e ento sair fora ou diversificar.
justamente sobre sugar tudo. Minhaideiaera: aprecie cozinhar, venda seu po, as pessoas
gostam disso, venda mais. Mantenha a padaria indo porque voc est fazendo boa
comida e as pessoas esto felizes.

Ian MacKaye, membro da Fugazi e um dos donos da Dischord Records

(da Salon.com People | Ian MacKaye)

13
Permanea Enxuto captulo 3

Menos Massa
Quanto mais enxuto for, mais fcil para mudar
Quanto mais massa tiver um objeto, mais energia necessria para mudar sua direo.
uma verdade tanto para o mundo dos negcios como para o mundo fsico.

Quando falamos em tecnologias web, mudanas devem ser fceis e baratas. Se voc no
puder mudar rapidamente, perder terreno para algum que possa. por isso que voc
deve optar por menos massa.

Massa aumenta com...

Contratos de longo prazo
Excesso de pessoas
Decises permanentes
Reunies sobre outras reunies
Processos Burocrticos
Inventrio (fsico ou mental)
Priso em hardware, software e tecnologia
Formatos proprietrios de dados
Passado mandando no futuro
Planejamentos de longo prazo
Polticas de escritrio

Massa se reduz com...

Pensamentos just-in-time
Equipes com membros multi-tarefa
Abraar limitaes, sem aument-las
Menos software, menos cdigo
Menos funcionalidades
Equipes pequenas
Simplicidade
Interfaces reduzidas
Produtos de cdigo aberto
Formatos de dados abertos
Uma cultura aberta que torna fcil admitir erros

Menos massa permite mudar de direo rapidamente. Voc pode reagir e evoluir. Pode
focar em boas ideias e derrubar as ruins. Pode ouvir e responder a seus clientes. Pode
integrar novas tecnologias agora em vez de mais tarde. Ao invs de um avio de cargas,
voc dirige um pequeno bote. Aproveite esse fato.

Por exemplo, vamos imaginar uma empresa enxuta e com menos massa, que construiu
um produto com menos cdigo e menos funcionalidades. Do outro lado est uma
empresa massuda que tem um produto significativamente com mais software e mais

14
funcionalidades. Ento, digamos que uma nova tecnologia como Ajax ou um novo
conceito como tags apaream por a. Quem estar apto a adaptar seu produto mais
rpido? A equipe com mais software e mais funcionalidades, com um planejamento de
12 meses ou a equipe com menos software, menos funcionalidade e com um processo
mais organico do tipo vamos focar no que realmente precisamos agora?

Obviamente a empresa com menos massa est em uma posio melhor para se ajustar s
demandas reais do mercado. A empresa com mais massa ainda estar discutindo as
mudanas, ou empurrando-as junto ao processo burocrtico, enquanto a empresa com
menos massa j haver feito a troca. A empresa com menos massa est dois passos
frente enquanto a empresa com mais massa ainda est tentando entender como andar.

Negcios rpidos, geis, e com menos massa podem rapidamente mudar seu modelo de
negcios, produtos, funcionalidades e mensagem de marketing. Eles podem cometer
erros e corrig-los rapidamente. Podem mudar suas prioridades, misturar produtos e
focar. E, mais importante, podem mudar sua maneira de pensar.

Diminua seu Custo de Mudana

Permanea flexvel reduzindo os obstculos mudana
A mudana sua melhor amiga. Quanto mais caro for para fazer uma mudana, menos
chances ela ter de ser realizada. Se seus competidores podem mudar mais rpido, voc
se encontra em enorme desvantagem. Se a mudana for cara demais, voc est morto.

a que manter-se enxuto realmente ajuda. A capacidade de mudar num piscar de olhos
algo que equipes pequenas tm por natureza, e que grandes equipes nunca conseguiro
ter. nisto que os grandes invejam os pequenos. O que poderia levar semanas com uma
equipe grande em uma mega-corporao pode levar apenas um dia em uma organizao
pequena e enxuta. Essa vantagem no tem preo. Mudanas rpidas e baratas so a arma
secreta dos pequenos.

E lembre-se: Mesmo com todo o dinheiro, marketing e pessoas do mundo voc no

pode comprar a agilidade de ser pequeno.

Emergencia

A emergencia um dos princpios fundamentais da agilidade, e a coisa mais prxima

da magia pura. Propriedades emergenciais no so projetadas ou vm prontas, elas
simplesmente acontecem como um resultado dinmico do resto do sistema.
Emergencia vem do Latim da metade do sculo 17, que significa ocorrncia no
prevista. Voc no pode planej-la ou agend-la, mas pode cultivar um ambiente em
que a deixe ocorrer, se beneficiando dela.

Um exemplo clssico de emergncia est no comportamento dos bandos de pssaros.

Uma simulao de computador pode usar apenas trs regras simples (parecidas com
no colida-se com outros) e de repente voc tem comportamento complexo quando o
bando vai batendo as asas graciosamente pelos cus, se remodelando em torno de

15
obstculos e assim por diante. Nenhum desses comportamentos avanados (como se
remodelar na mesma forma ao redor de obstculos) especificado pelas regras; eles
emergem da dinmica do sistema.

Regras simples, como na simulao dos pssaros, leva a comportamentos complexos.

Regras complexas, como com leis tributrias na maioria dos pases, levam a
comportamentos estpidos.

Muitas prticas comuns de desenvolvimento de software tem o infeliz efeito-colateral

de eliminar qualquer chance de comportamento emergente. A maioria das tentativas de
otimizao amarrando alguma coisa muito explicitamente reduz a extenso e escopo
de interaes e relacionamentos, que a origem da emergencia. No exemplo do bando
de pssaros, assim como sistemas bem-desenhados, so as interaes e relacionamentos
que criam os comportamentos interessantes.

Quanto mais amarramos as coisas, menos espao deixamos para uma soluo criativa e
emergente. Seja tanto travando requisitos, antes de serem bem entendidos ou
otimizando o cdigo prematuramente, como inventando navegaes e cenrios de fluxo
de trabalho complexas, antes de deixar o usurio final usar o sistema, o resultado o
mesmo: um sistema exageramente complicado e estpido ao invs de um sistema limpo
e elegante que aproveita a emergencia.

Mantenha pequeno. Mantenha simples. Deixe acontecer.

Andrew Hunt, The Pragmatic Programmers

Os Trs Mosqueteiros
Use uma equipe de trs para a verso 1.0
Para a primeira verso da sua aplicao, comece com apenas trs pessoas. Este o
nmero mgico que lhe dar fora de trabalho suficiente sem lhe tirar o dinamismo e a
agilidade. Comece com um desenvolvedor, um designer e um varredor (algum que
possa transitar entre ambos os mundos).

Claro, um desafio desenvolver uma aplicao com poucas pessoas. Mas se voc
possuir a equipe certa, esta ser valorosa. Pessoas talentosas no precisam de recursos
infinitos. Elas prosperam no desafio de trabalhar com restries e usam a criatividade
para resolver problemas. Falta de recursos humanos fora-o a lidar com sacrifcios mais
cedo, o que timo. Far voc entender suas prioridades mais cedo do que mais tarde. E
voc estar apto para comunicar-se sem ter constantemente que se preocupar se est
deixando algum de fora.

Se voc no pode desenvolver sua primeira verso com apenas trs pessoas, ento ou
voc precisa de pessoas diferentes ou diminuir sua verso inicial. Lembre-se, tudo bem
voc lanar sua primeira verso pequena e consistente. Voc rapidamente perceber se
suaideiatem futuro e, se tiver, voc ter uma base simples e limpa para progredir.

Lei de Metcalfe e equipes de projeto

16
Deixe a equipe to pequena quanto possvel. A lei de Metcalfe, O valor de um sistema
de comunicao cresce aproximadamente ao quadrado do nmero de usurios do
sistema, tem um corolrio quando se trata de equipes de projeto: A eficincia da equipe
aproximadamente o inverso do quadrado do nmero de membros na equipe. Estou
comeando a achar que trs pessoas timo para a verso 1.0 de um produto Comece
por reduzir o nmero de pessoas que voc planeja incluir na equipe, e ento reduza um
pouco mais.

Marc Hedlund, entrepreneur-in-residence na OReilly Media

O fluxo da comunicao

A comunicao flui mais facilmente em equipes pequenas do que em grandes. Se voc

a nica pessoa no projeto, comunicao simples. O nico caminho de comunicao
entre voc e o cliente. Com o aumento do nmero de pessoas em um projeto, aumenta
tambm o nmero de caminhos de comunicao. E no aumenta de forma aditiva, como
o nmero de pessoas, aumenta de forma multiplicativa, proporcional ao quadrado do
nmero de pessoas.

Steve McConnell, Chief Software Engineer na Construx Software Builders Inc.

(de: Less is More: Jumpstarting Productivity with Small Teams)

Abrace as Restries
Deixe as limitaes lhe guiar para solues criativas
Nunca h suficiente para dar a volta. Sem tempo suficiente. Sem dinheiro suficiente.
Sem pessoal suficiente.

Isso uma coisa boa.

Em vez de se desesperar com essas restries, aceite-as. Deixe que elas o guiem.
Restries incentivam inovao e foram o foco. Em vez de tentar remov-las, use-as
em seu benefcio.

Quanto a 37signals estava desenvolvendo o Basecamp, ns tnhamos muitas limitaes.

Tnhamos:

Uma empresa de design para administrar

Trabalhos para clientes j existentes
Uma diferena de 7 horas (O David estava programando na Dinamarca e o resto
de ns nos Estados Unidos)
Uma equipe pequena
Nenhum finaciamento externo

Ns sentimos a depresso sem suficiente. Ento mantivemos nossos pratos pequenos.

Dessa maneira s poderamos colocar at onde coubesse. Pegvamos grandes tarefas e

17
quebrvamos em pedaos menores que atcavamos um de cada vez. Nos movemos
passo a passo e priorizamos no caminho.

Isso nos forou a chegar com solues criativas. Baixamos nosso custo de mudana
construindo sempre menos software. Demos s pessoas apenas as funcionalidades
suficientes para resolver seus problemas do seu jeito e ento saamos do caminho. A
diferena de tempo e distncia entre ns nos tornou mais eficientes na nossa
comunicao. Em vez de nos encontrarmos em pessoa, comunicvamos exclusivamente
via mensagens instantneas e e-mail, o que nos forava a ir direto ao ponto rapidamente.

Restries normalmente so vantagens disfaradas. Esquea investimento externo,

longos ciclos de lanamento e resolues rpidas. Em vez disso, trabalhe com o que
voc tem.

Combata a destruio

O que j foi descrito como elegncia bizarra provavelmente melhor descrito como
funcionalidade destrutiva, como um fungo em uma planta ele gradualmente elabora a
embaa a verdadeira forma do produto enquanto drena suas energias. O antdoto para
funcionalidade destrutiva , claro, o prazo final restritivo. Isso resulta em
funcionalidades serem descartadas por causa do tempo que levaria para implement-las.
Normalmente o caso que as funcionalidades mais teis levam a maior parte do tempo
para implementar. Portanto a combinao da destruio e do prazo final gera software
como conhecemos e amamos, formado de grande quantidade de funcionalidades inteis.

Jef Raskin, autor (de Por que Software como )

Table of contents | Essay list for this chapter | Next essay

Seja Voc Mesmo

Diferencie-se das companhias maiores sendo amigvel
e pessoal
Muitas pequenas empresas cometem o erro de tentarem atuar grande. como se elas
entendessem seu tamanho como uma fraqueza que precisa ser encoberta. Muito ruim.
Ser pequeno pode realmente ser uma grande vantagem, especialmente quando isto
representa comunicao.

Pequenas empresas gostam de menos formalidades, menos burocracia e mais liberdade.

Menores empresas so mais prximas dos clientes por padro. Isto significa que
elas podem se comunicar com seus clientes de forma mais direta e pessoal. Se a
empresa pequena, pode-se usar uma linguagem familiar ao invs de jargo. Seu site e
seu produto podem ter uma voz humana ao invs de soar como um zumbido
corporativo. Ser pequeno significa poder falar com os clientes, e no se submeter a
eles.

H tambm vantagens na comunicao interna em pequenas empresas. Voc pode

dispensar formalidades. No h necessidade de processos rduos e mltiplas assinaturas

18
para tudo. Todos no processo podem falar abertamente e honestamente. Este fluxo livre
de ideias uma das grandes vantagens de ser pequeno.

Seja orgulhoso, desafiadoramente sincero

Embora voc possa pensar que um cliente pode ser logrado por exageros no nmero de
empregados em sua companhia ou na amplitude de suas ofertas, os espertos, aqueles
que realmente quer, sempre percebero a verdade seja por intuio ou deduo. De
forma embaraosa, Eu fiz parte de mentiras como essa no passado, e nenhuma dessas
situaes resultou algo que importasse para os negcios: relaes duradouras, com
significado e mutuamente benficas com pessoas que possuem uma necessidade real
pelos servios oferecidos. O melhor caminho deveria ser orgulhoso, desafiadoramente
sincero sobre o tamanho exato e a amplitude da companhia.

Khoi Vinh, Subtraction.com

Sempre disponvel

No importa em qual negcio voc est, um bom servio ao cliente tornou-se o maior
requisito que qualquer cliente estabelecer. Ns demandamos isso dos servios que
usamos ento por que com nossos clientes seria diferente? Desde o comeo ns
deixamos fcil e transparente para nossos clientes contatar-nos por toda e qualquer
questo que tiverem. Em nosso website ns listamos um grande nmero de ferramentas
gratuitas que redireciona para nossos celulares e nossos cartes de visita listam os
nmeros de cada um de ns. Ns enfatizamos para nossos consumidores que eles
podem nos contatar a qualquer hora independente do problema. Nossos clientes
apreciam esse nvel de confiana ningum jamais abusou deste servio.

Edward Knittel, Diretor de Vendas e Marketing, KennelSource

Prioridades captulo 4

Qual a Grande Ideia?

Diferencie-se das grandes empresas sendo pessoal e
amigvel
Explicitamente defina a viso principal da sua aplicao. O que a sua aplicao
defende? Do que se trata? Antes de comear o design ou a codificao de qualquer coisa
voc precisa saber o propsito do seu produto a viso. Pense grande. Para que ele
existe? O que o torna diferente de outros produtos similares?

A viso ir guiar suas decises e o manter em um caminho consistente. Sempre que

houver um ponto duvidoso, pergunte, Estamos nos mantendo coerentes viso?

A viso deve ser breve tambm. Uma sentena deve ser o suficiente para espalhar a
ideia. Aqui esto as vises para cada um de nossos produtos:

19
 Basecamp: Gerenciamento de Projetos comunicao
Backpack: Junte as pontas soltas da vida
Campfire: Chat em grupo ao invs de Mensagens Instantneas ruins
Ta-da List: Competindo com os post-its
Writeboard: Word coisa demais

Com o Basecamp, por exemplo, a viso era Gerenciamento de Projetos

comunicao. Sentimos fortemente que comunicao efetiva em um projeto leva
propriedade coletiva, ao envolvimento, ao investimento e ao momento. Traz todos
mesma pgina trabalhando em direo a um objetivo comum. Sabamos que se
Basecamp pudesse atingir isso, todo o resto entraria na linha.

A viso nos levou a manter o Basecamp o mais aberto e transparente possvel. Em vez
de limitar a comunicao para dentro da empresa, demos acesso aos clientes tambm.
Pensamos menos sobre permisses e mais sobre encorajar todos os participantes a tomar
parte. A viso o motivo porque pulamos painis, grficos, tabelas, relatrios,
estatsticas e planilhas e ao invs disso focamos na prioridade da comunicao como
mensagens, comentrios, listas de tarefas e compartilhamento de arquivos. Tome a
grande deciso sobre a viso logo no comeo e todas as pequenas decises futuras se
tornam muito mais simples.

Filosofia do Quadro Branco

Andy Hunt e eu uma vez escrevemos um sistema de transaes de carto de dbito. Um

grande requisito era que o usurio de um carto de dbito no deveria ter a mesma
transao aplicada sua conta duas vezes. Em outras palavras, no importa que tipo de
falha pudesse acontecer, o erro deveria ir para o lado de no processar a transao em
vez de processar e duplic-la.

Ento, escrevemos isso no nosso quadro-branco compartilhado em letras grandes: Erros

a favor dos usurios.

Isso se juntou a outra meia-dzia de mximas. Juntas, elas guiaram todas aquelas
decises complicadas que se fazem quando se constri algo complexo. Juntas, essas leis
deram forte coerncia interna e grande consistncia externa nossa aplicao.

Dave Thomas, The Pragmatic Programmer

Faa um Mantra

Organizaes precisam de pontos-guia. Precisam de linhas gerais; funcionrios

precisam saber a cada dia quando acordam porque esto indo trabalhar. Essas linhas
devem ser curtas e doces, e bem compreensivas: Por que voc existe? O que o motiva?
Chamo isso de mantra uma descrio de trs ou quatro palavras de porque voc existe.

Guy Kawasaki, autor (de Make Mantra)

Ignore os Detalhes logo no Comeo

20
Trabalhe do grande para o pequeno
Somos loucos por detalhes.

O espao entre objetos

O espao perfeito entre linhas
A cor perfeita
As palavras perfeitas
Quatro linhas de cdigo em vez de sete
90% vs 89%
760px vs 750px
$39/ms vs $49/ms

Sucesso e satisfao esto nos detalhes

Entretanto, o sucesso no a nica coisa que encontrar nos detalhes. Tambm

encontrar estagnao, desacordo, reunies e atrasos. Essas coisas podem acabar com a
moral e diminuir suas chances de sucesso.

Quantas vezes se encontrou travado em um nico design ou elemento de cdigo por um

dia inteiro? Quantas vezes se deu conta de que o progresso que fez hoje no foi
progresso real? Isso acontece quando voc foca nos detalhes cedo demais no processo.
H tempo suficiente para ser um perfeccionista. Apenas faa isso mais tarde.

No se preocupe com o tamanho da fonte do cabealho na primeira semana. Voc no

precisa empregar o tom perfeito de verde na segunda semana. No precisa mover em
trs pixels o boto de submeter na terceira semana. Apenas coloque as coisas na
pgina por enquanto. Ento use. Garanta que funciona. Mais tarde voc pode ajustar e
aperfeioar.

Os detalhes se revelam ao se usar o que est construindo. Voc ver o que precisa de
mais ateno. Sentir o que est faltando. Saber quais crateras pavimentar porque
ficar sempre caindo nelas. quando precisa prestar ateno, e no antes.

O Diabo est nos Detalhes

Quase me cansei da atitude entre nos detalhes imediatamente depois de tomar

algumas aulas de desenho Se comear a desenhar os detalhes imediatamente pode ter
certeza que o desenho ser uma droga. De fato, voc est perdendo completamente o
ponto.

Voc deve comear pegando as propores corretas da cena toda. Ento rascunha os
grandes objetos na sua cena, indo at os menores. O rascunho deve ser bem vago nesse
ponto. Ento pode proceder sombreando, o que consiste em dar volume vida. Voc
comea com apenas trs tons (claro, mdio, escuro). Isso d um rascunho de tons.
Ento, para cada poro do seu desenho reavalia trs tons e os aplica. Faa isso at os
volumes aparecerem (requer mltiplas iteraes) ...

Funciona do grande para o pequeno. Sempre.

Patrick Lafleur, Creation Object Inc. (de Signal vs. Noise)

21
S um Problema Quando um
Problema
No desperdice tempo com problemas que voc ainda
no tem
Voc precisa realmente se preocupar em escalar para 100.000 usurios hoje se vai levar
dois anos para chegar l?

Voc tem mesmo que contratar oito programadores se hoje voc s precisa de trs?

Voc precisa realmente de 12 servidores top-de-linha agora se d para rodar em dois por
um ano?

Apenas se vire
As pessoas costumam gastar tempo demais logo de cara tentando resolver problemas
que elas ainda nem tm. No faa isso. Poxa, ns lanamos o Basecamp sem a
habilidade de cobrar os clientes! Como o produto cobrado mensalmente, sabamos que
teramos um intervalo de 30 dias para dar um jeito. Usamos aquele tempo para resolver
problemas mais urgentes e ento, aps o lanamento, enfrentamos a cobrana. Deu certo
(e nos forou a adotar uma soluo simples, sem firulas desnecessrias).

No esquente com uma coisa at que voc tenha de fato que faz-lo. No desenvolva
demais. Aumente hardware e software de sistema conforme necessrio. Se ficar lento
por uma ou duas semanas no ser o fim do mundo. Apenas seja honesto: explique para
os seus clientes que voc est passando por dores de crescimento. Eles podem no ficar
empolgados mas apreciaro a franqueza.

Resumo da pera: Tome decises s no momento necessrio, pois a voc ter acesso
informao real de que precisa. Entrementes voc estar em condies de prestar
ateno s coisas que requerem cuidado imediato.

Contrate os Clientes Certos

Encontre o nicho de mercado para seu aplicativo e
concentre-se somente nele
O cliente nem sempre tem razo. A verdade que voc ter que separar quem certo e
quem errado para seu aplicativo. A boa notcia que a Internet torna mais fcil do
que nunca encontrar as pessoas certas.

22
Se voc tentar agradar todo mundo, no ir agradar
ningum
Quando ns desenvolvemos o Basecamp, focamos nosso marketing em firmas de
design. Por restringir nosso mercado desta forma, ficou mais fcil atrair clientes
passionais que, por sua vez, iriam evangelizar o produto. Saiba para quem seu aplicativo
realmente se destina e foque-se em agradar este pblico.

A Melhor Deciso Que J Tomamos

A decisio de direcionar o Campaign Monitor estritamente para o mercado de web

design foi a melhor escolha que j fizemos. Ela nos permitiu identificar facilmente
quais recursos seriam genuinamente teis e, mais importante, quais recursos deixar de
fora. No s atramos mais clientes por mirar em um grupo menor de pessoas, como
todos esses clientes tinham necessidades similares que tornavam nosso trabalho muito
mais fcil. H um monte de recursos no Campaign Monitor que seriam inteis para
qualquer um exceto um web designer.

Focar um nicho de mercado tambm torna muito mais fcil divulgar seu software.
Agora que temos um pblico bem definido, podemos fazer anncios em lugares da web
que este pblico freqenta, publicar artigos que eles podem achar interessantes e em
geral formar uma comunidade em torno do produto.

David Greiner, fundador, Campaign Monitor

Escale mais Tarde

Voc ainda no tem um problema de escalabilidade
Conseguirei escalar minha aplicao quando milhes de pessoas comearem a us-
la?

Quer saber? Espere at que isso acontea de fato. Se voc tiver um nmero gigante de
pessoas sobrecarregando seu sistema, magnfico! Que timo problema para se ter. A
verdade que a maioria esmagadora das aplicaes web nunca alcanar esse estgio. E
mesmo se voc comear a ser sobrecarregado isto tipicamente no uma questo de
tudo ou nada. Voc ter tempo para ajustar-se e responder ao problema. Alm disso,
depois de lanar voc ter mais dados reais e benchmarks que podem ser usados para
descobrir as partes que precisam ser revisadas.

Por exemplo, ns rodamos o Basecamp em um nico servidor durante o primeiro ano.

Por termos iniciado com uma configurao simples, conseguimos implementar em uma
nica semana. Ns no comeamos com um aglomerado de 15 computadores nem
gastamos meses nos preocupando com escalabilidade.

Tivemos problemas? Alguns. Mas tambm descobrimos que a maior parte do que
temamos, como um breve perodo de lentido, no era o fim do mundo para os clientes.
Desde que voc mantenha as pessoas informadas, e seja honesto sobre a situao, elas

23
entendero. Em retrospecto, somos contentes por no termos atrasado o lanamento em
meses para criar a configurao perfeita.

No comeo, priorize construir um produto slido em vez de obsecar-se com

escalabilidade ou fazendas de servidores. Crie uma grande aplicao e depois se
preocupe com o que fazer quando ela se tornar animalmente bem-sucedida. Do
contrrio voc o corre o risco de desperdiar energia, tempo e dinheiro se prendendo a
algo que nunca acontecer.

Acredite ou no, o maior problema no escalar, chegar ao ponto de ter de faz-lo.

Sem o primeiro problema, voc no ter o segundo.

Voc ter que revisar de qualquer jeito

A verdade que todo mundo tem problemas de escalabilidade, ningum lida com a
transio de zero para alguns milhes de usurios sem revisar quase todos os aspectos
do design e arquitetura da aplicao.

Dare Obasanjo, Microsoft (de Scaling Up and Startups)

Faa Software que tem Opinio

Seu aplicativo deve tomar partido
Algumas pessoas defendem que o software deve ser agnstico. Dizem que arrogante
da parte dos desenvolvedores limitar a funcionalidade ou ignorar pedidos de novos
recursos. Dizem que o software deve ser sempre o mais flexvel possvel.

Para ns isso papo-furado. O melhor software traz consigo uma viso. O melhor
software toma partido. Quando algum usa um software, no est procurando apenas
recursos, est procurando uma abordagem. Est procurando uma viso. Decida qual
sua viso e atenha-se a ela.

E lembre, se no gostarem da sua viso h um monte de outras vises por a. No corra

atrs de quem voc nunca ir contentar.

Um timo exemplo o projeto original do wiki. Ward Cunningham e seus amigos

deliberadamente desproveram o wiki de muitos recursos que no passado eram
considerados parte indispensvel da colaborao de documentos. Em vez de atribuir
cada mudana do documento a uma pessoa determinada, eles removeram muito da
representao visual de propriedade. Eles tornaram o contedo atemporal e destitudo de
ego. Eles decidiram que no importava quem escreveu o contedo ou quando ele foi
escrito. E isso fez toda a diferena. Essa deciso despertou nas pessoas um senso de
comunidade e foi pea-chave no sucesso da Wikipdia.

Nossos aplicativos trilharam um caminho parecido. Eles no tentam ser todas as coisas
para todas as pessoas. Eles tm uma atitude. Eles vo atrs de clientes que so no fundo

24
parceiros. Eles tm apelo para as pessoas que partilham de nossa viso. Ou se est do
lado de dentro ou se est do lado de fora.

Seleo de Funcionalidades captulo 5

Meio, No Meia-Boca
Faa meio produto e no um produto meia-boca
Cuidado com a viso faz-tudo no desenvolvimento de uma aplicao web. Considere
todas as boas ideias que aparecerem ao longo do processo e voc acabar apenas com
uma verso meia-boca do seu produto. O que voc realmente precisa montar meio
produto que detone.

Atenha-se ao que verdadeiramente essencial. Boas ideias podem ser tiradas da gaveta.
Pegue tudo que voc acha que seu produto deve ser e corte pela metade. Remova
funcionalidades at que voc obtenha apenas o essencial. E ento, repita o processo.

Comeamos o Basecamp apenas com a seo de mensagens. Ns sabamos que isso era
o corao do aplicativo, ento, de incio, ignoramos as milestones, listas de tarefas e
outros itens. Isso nos permitiu embasar as decises futuras no uso real e no em
palpites.

Comece com um aplicativo simples e inteligente e deixe-o ganhar impulso. S ento

pense em adicionar coisas fundao slida que voc j construiu.

Isso Simplesmente No Importa

Apenas o essencial
Nossa resposta favorita pergunta porque voc no fez isso ou porque voc no fez
aquilo? sempre: Porque isso simplesmente no importa. Essa afirmao representa
o que torna genial um produto. Descobrir o que importa e deixar de fora o resto.

Quando lanamos o Campfire, ns recebemos essas perguntas das pessoas que usavam
o produto pela primeira vez:

Porque marcar o horrio apenas a cada 5 minutos? Porque no marcar a hora de

cada linha do batepapo? Resposta: Porque no importa. Com que frequncia voc
precisa ter controle de uma conversa segundo a segundo, ou mesmo minuto a minuto?
Certamente no 95% do tempo. Marcar o horrio a cada 5 minutos so suficientes
porque qualquer outra frequncia mais especfica no importa.

25
Porque vocs no permitem negrito ou itlico ou formatao colorida nos
batepapos? Resposta: Porque no importa. Se voc necessita enfatizar algo, use a boa
e velha trava de maisculas ou coloque alguns * em volta da palavra ou frase. Essas
solues no requerem nenhum software adicional, suporte tcnico, capacidade de
processamento ou curva de aprendizado. Alm disso, formatao de texto num simples
batepapo baseado em texto no importa.

Porque vocs no mostram o total de pessoas na sala? Resposta: Porque no

importa. O nome de todos est listado, ento voc sabe quem est a, que diferena faz
saber se h 12 ou 16 pessoas? Se isso no muda o seu comportamento ento isso no
importa.

Seria legal ter essas coisas? Claro. Elas so essenciais? Elas realmente importam? No.
Por isso foram deixadas de fora. Os melhores designers e os melhores programadores
no so os com as melhores habilidades, ou os dedos mais geis, ou os que podem
assoviar e chupar cana com o Photoshop ou sua plataforma preferida, e sim aqueles que
podem determinar o que no importa. a onde os ganhos reais so feitos.

A maior parte do tempo que voc gasta perdido em coisas que no importam. Se voc
puder cortar o tempo pensando no que no importa, voc atingir nveis de
produtividade que voc jamais imaginou.

Comece com No
Faa com que as funcionalidades dem duro para ser
implementadas
O segredo de criar meio produto ao invs de um produto meia-boca dizer no.

Cada vez que voc diz sim para uma funcionalidade, voc est adotando um filho. Voc
tem que levar seu beb atravs de toda uma cadeia de eventos (exemplo: design,
implementao, testes etc.). Uma vez que est funcionalidade est l, voc est preso a
ela. Apenas tente remov-la e veja o quo irados ficaro os clientes.

No concorde com tudo

Faa com que cada funcionalidade d duro para ser implementada. Ponha cada uma
delas prova e mostre que uma sobrevivente. como no filme O Clube da Luta.
Voc deveria considerar apenas funcionalidades que estejam dispostas a ficar
aguardando na porta por trs dias para serem aceitas.

por isso que voc tem que comear com um no. Cada novo pedido de funcionalidade
que vem at ns ou de ns encontra um no. Ns ouvimos mas no agimos. A
resposta inicial agora no. Se o pedido continua a aparecer, ento sabemos que
hora de um olhar mais profundo. Somente ento ns comeamos a pensar na
funcionalidade de fato.

26
E o que dizer s pessoas que reclamam quando ns no adotamos a sua ideia? Lembre-
os do porque eles gostam da aplicao em primeiro lugar. Voc gosta dele porque ns
dizemos no. Voc gosta dele porque ele no faz outras 100 coisas. Voc gosta dele
porque ele no tenta agradar a todos sempre.

Ns no queremos milhares de funcionalidades

Steve Jobs deu uma pequena apresentao sobre o iTunes Music Store para um pessoal
de uma gravadora independente. Minha fala favorita nesse dia foi quando as pessoas
insistiam em levantar a mo perguntando, Ele faz [x]?, Voc planeja adicionar [y]?.
Finalmente Jobs disse, Calma, calma abaixem seus braos. Ouam: Eu sei que vocs
tem milhares de ideias de funcionalidades bacanas para o iTunes. Ns tambm. Mas no
queremos milhares de funcionalidades. Isso seria horrvel. Inovao no dizer sim
para tudo. dizer NO para tudo exceto as funcionalidades mais cruciais.

-Derek Sivers, presidente e programador, CD Baby e HostBaby

(from Diga NO por padro)

Custos Ocultos
Exponha o preo das novas funcionalidades
Mesmo que uma funcionalidade passe o estgio do no, voc ainda precisa expor seus
custos ocultos.

Por exemplo, fique de alerta com loops de funcionalidades, ou seja, funcionalidades que
levam a mais funcionalidades. Ns recebemos pedidos para adicionar uma aba de
reunies ao Basecamp. Parece simples at que voc examine com mais cautela. Pense
em todos os diferentes itens que uma aba de reunies precisaria: localizao, hora, sala,
pessoas, convites por e-mail, integrao com o calendrio, documentao de suporte,
etc. Isso sem mencionar que ns teramos que modificar as imagens de promoo, as
pginas do tour, pginas do faq/ajuda, contrato de prestao de servio e mais. Antes
que voc note, umaideiasimples pode ser tornar uma dor de cabea enorme.

Para cada nova funcionalidade voc precisa

1. Dizer no.
2. Forar a funcionalidade a provar seu valor.
3. Se no novamente, pare aqui. Se sim, continue
4. Esboce as telas/UI.
5. Crie as telas/UI.
6. Programe-as.
7-15. Teste, aperfeioe, teste, aperfeioe, teste, aperfeioe
16. Cheque para ver se o texto da ajuda precisa ser modificado.
17. Atualize o tour do produto (se necessrio).
18. Atualize a cpia de marketing (se necessrio).
19. Atualize o Termo de Prestao de Servio (se necessrio).
20. Cheque se alguma promessa foi quebrada.
21. Cheque se a estrutura de custos foi afetada.

27
 22. Publique.
23. Cruze os dedos.

Voc Pode Lidar com Isso?

Crie algo que voc possa gerenciar
Se voc lanar um programa de filiao, voc teria os sistemas prontos para fazer a
contabilidade e os pagamentos? Talvez seria melhor voc deixar as pessoas ganhar
descontos nas suas taxas de filiao ao invs de escrever, assinar e enviar cheques todos
os meses.

Voc consegue dar 1 GB de espao de graa, s porque o Google d? Talvez voc deva
comear pequeno, em 100 mb, ou ceder espao apenas para as contas pagantes.

Concluso: Crie produtos e oferea servios que voc possa gerenciar. fcil fazer
promessas. bem mais dficl mant-las. Tenha certeza de que, seja l o que voc fizer,
seja algo que voc possa realmente sustentar organizacional, estratgica e
financeiramente.

Solues Humanas
Crie softwares voltados para conceitos gerais e
incentive as pessoas a criar suas prprias solues
No force convenes. Ao invs disso, faa seu software de modo generalista, assim
todos podem encontrar suas prprias solues. D s pessoas s o suficiente para
resolver os problemas delas ao modo delas. E ento saia do caminho.

Quando criamos a Ta-da List, ns intencionalmente omitimos uma srie de coisas. No

h como designar uma tarefa para algum, no h como marcar uma data de trmino,
no h como categorizar os itens, etc.

Ns mantivmos a ferramenta limpa e sem frescuras deixando as pessoas serem

criativas. As pessoas descobriram como resolver seus problemas sozinhas. Se elas
quisessem adicionar uma data para uma tarefa, elas poderiam inserir (Prazo: 7 de Abril
de 2006) na frente do item. Se elas quisessem categorizar, poderiam simplesmente
colocar [Livros] na frente do item. Ideal? No. Infinitamente flexvel? Sim.

Se tentssemos criar software para, especificamente, cuidar desses casos, ns estaramos

o tornando menos til para todos os casos onde essas preocupaes no se aplicam.

28
Faa o melhor trabalho que voc puder com a raiz do problema e ento saia de fininho.
As pessoas vo encontrar suas prprias solues e convenes dentro de sua estrutura
geral.

Esquea Pedidos de Funcionalidades

Deixe os clientes informarem o que importante
Os clientes querem absolutamente tudo. Eles viro com uma avalanche de pedidos de
funcionalidades. D uma olhada nos fruns de nossos produtos; A categoria pedido de
funcionalidade sempre sobrepuja as com larga vantagem.

Ns vamos ouvir sobre essa pequena funcionalidade extra ou no pode ser difcil ou
no seria fcil colocar isso ou vai levar apenas uns segundos para inser-la ou se
voc adicionar isso, eu pagaria o dobro e assim por diante.

Claro que no podemos culpar as pessoas por pedir funcionalidades. Ns as

encorajamos e queremos ouvir o que elas tem a dizer. A maior parte das funcionalidades
que inserimos em nossos produtos comearam como sugestes de nossos clientes. Mas,
como dissemos antes, sua primeira resposta deve ser um no. Ento o que voc faz com
todos esses pedidos? Onde voc os guarda? Como voc os gerencia? Voc no faz
isso. Voc apenas os l e ento os joga fora.

Sim, leia, jogue fora e esquea-os. Pode soar como heresia mas os realmente
importantes iro, com certeza, reaparecer. Esses so os nicos que voc precisa se
lembrar. Esses so os realmente esseciais. No se preocupe em organizar e guardar cada
pedido que aparecer. Deixe seus clientes serem sua memria. Se a funcionalidade for
realmente necessria, eles te lembraro at que voc no consiga esquecer.

Como ns chegamos essa concluso? Quando ns lanamos o Basecamp ns

colocvamos todos os pedidos de novas funcionalidades em uma lista de tarefas. A cada
repetio de um pedido, ns marcvamos com um I extra ( II, III ou IIII etc). Ns
imaginvamos que um dia iramos revisar a lista e trabalhar indo das mais para as
menos populares.

Mas a verdade que nunca olhamos para a lista novamente. Ns j sabamos o que
precisava ser feito porque nossos clientes nos lembravam constantemente fazendo
sempre os mesmos pedidos. No havia necessidade de uma lista ou grupos de anlise,
porque tudo estava acontecendo em tempo real. Voc no pode esquecer o que
importante quando voc lembrado todos os dias.

E mais uma coisa: S porque x pessoas pedem algo, no significa que voc tem que
inclu-la. Algumas vezes melhor apenas dizer no e manter sua viso de produto.

29
Segure as Rdeas
Pergunte o que as pessoas no querem
A maior parte das enquetes e pesquisas sobre software so focalizadas em o que as
pessoas querem num produto. Qual funcionalidade voc acha que est faltando?, Se
voc pudesse adicionar mais uma nica coisa, o que seria?, O que tornaria esse
produto mais til para voc?

E o outro lado da moeda? Porque no perguntar o que as pessoas nao querem? Se voc
pudesse remover algo, qual seria? O que voc no usa? O que mais te atrapalha?

Mais no a resposta. Algumas vezes o maior favor que voc pode fazer para os
clientes deixar algo de fora.

Inovao aparece quando dizemos no

[Inovao] aparece quando dizemos no 1000 coisas para termos certeza que no
estamos seguindo o caminho errado ou tentando fazer coisas demais. Ns estamos
sempre pensando em novos mercados para entrar, mas somente dizendo no para isso
que voc pode se concentrar no que realmente importa.

Steve Jobs, CEO, Apple (de A Semente de Inovao da Apple)

Processo captulo 6

Corra para Rodar o Software

Pegue algo real e ponha-o para rodar rapidamente
Rodar o software a melhor maneira de fazer acontecer, rena sua equipe e jogue fora
ideias que no funcionam. Esta deve ser sua prioridade nmero um.

No tem problema fazer menos, pular detalhes e encontrar atalhos em seus processos se
o levarem a software que funciona mais rpido. Uma vez l, voc ser recompensado
com perspectivas significativamente mais precisas de como proceder. Histrias,
rascunhos de estrutura e mesmo prottipos html so apenas aproximaes. Software
rodando real.

Com software real rodando todos ficam perto da compreeno e do acordo. Voc evita
argumentos acalorados sobre esboos e pargrafos que no resolveriam nada de
importante. Voc percebe que coisas que considerava triviais so na verdade bem
cruciais.

Coisas reais levam a reaes reais. E assim que voc chega verdade.

30
As coisas reais levam ao acordo

Quando um grupo de pessoas diferentes tentam encontrar o que harmonioso suas

opinies tendem a convergir se eles esto rascunhando coisas reais em larga escala.
Claro, se esto fazendo um esboo ou gerando ideias, no vo concordar. Mas se voc
comea fazendo coisas reais, tendem a chegar a um acordo.

Christopher Alexander, Professor de Arquitetura

(de Contrastando Conceitos de Harmonia na Arquitetura)

Faa Funcionar o Mais Rpido Possvel

Eu no lembro de nenhum projeto de software que estive envolvido grande ou

pequeno que tenha tido sucesso em termos de prazos, custos ou funcionalidades que
tenha comeado com um longo perodo de planejamento e discusso, e sem
desenvolvimentos concorrentes. simplesmente muito fcil e s vezes divertido, jogar
o precioso tempo fora inventando funcionalidades que acabam sendo desnecessrias ou
que no sero implementveis.

Isso se aplica a qualquer tipo de desenvolvimento e chegar a alguma coisa real e

rodando um mantra fractal. Isto no se aplica apenas a projetos como um todo, pelo
menos igualmente aplicvel ao desenvolvimento de componentes de pequena escala,
dos quais a aplicao feita.

Quando h trabalho de implementao de um componente chave, desenvolvedores

querem entender como vai ou no trabalhar em conjunto com suas partes da aplicao e
iro geralmente tentar us-lo assim que puderem. Mesmo que a implementao no
esteja perfeita ou completa no incio, estas colaboraes prematuras normalmente levam
a interfaces bem definidas e funcionalidades que fazem exatamente o que se espera
delas.

Matt Hamer, desenvolvedor e gerente de produtos, Kinja

Enxague e Repita
Trabalhe por iteraes
No espere fazer certo na primeira vez. Deixe a aplicao crescer e se apresentar a voc.
Deixe ela mutar e envolver. Com softwares baseados na web no h necessidade de
entregar a perfeio. Projete as telas, use-as, analize-as e ento comece de novo.

Ao invs de querer tudo certo desde o incio, o processo iterativo lhe permite continuar
tomando decises informadas no percurso. Voc ainda ter uma aplicao ativa e
rodando rapidamente, desde que no fique obcecado em atingir a perfeio logo de cara.
O resultado um feedback e um guia real sobre o que requer sua ateno.

Iteraes levam liberao

31
Voc no precisa almejar a perfeio na primeira tentativa se sabe que isto ser feito de
novo mais tarde. Saber que revisitar problemas um grande motivador para apenas
lanar as ideias e ver se voam.

Talvez voc seja mais esperto do que eu

Talvez voc seja BEM mais esperto do que eu.

Isto totalmente possvel. De fato, isto provvel. De qualquer maneira, se voc

como a maioria das pessoas, ento como eu, tem problemas imaginando aquilo que no
consegue ver e tocar.

Seres humanos so extremamente bons em responder a coisas do ambiente. Ns

sabemos entrar em pnico quando um tigre entra na sala e como limpar tudo depois de
uma enchente devastadora. Infelizmente somos terrveis em planejar adiante, em
compreender ramificaes das nossas aes e em priorizar as coisas que realmente tem
importncia.

Talvez voc seja um dos poucos indivduos que consegue manter isto tudo em sua
cabea. Isto realmente no interessa.

Web 2.0, o mundo que comeamos assumindo que todo mundo j usa a web, d
permisso a desenvolvedores espertos colocarem essas fraquezas humanas a trabalhar
para elas. Como? Permitindo que seus usurios lhes contem o que pensam enquando
ainda h tempo de fazer algo a respeito.

E esta ltima frase explica porque voc deve desenvolver desta maneira e como pode
querer promover/lanar.

Torne sua histria direta. Garanta que as peas funcionem. Ento lance e revise.
Ningum to esperto quanto todos ns juntos.

Seth Godin, autor/empreendedor

Daideia Implementao
V do brainstorm esboos HTML codificao
Aqui vai o processo que usamos para Cair na Real:

Brainstorm
Traga ideias tona. O que este produto ir fazer? Para o Basecamp, ns olhamos para
nossas prprias necessidades. Queramos publicar atualizaes de projeto. Queramos
participao dos clientes. Sabamos que projetos tinham datas-chave. Queramos
centralizar arquivos para que as pessoas pudessem revisar coisas antigas com facilidade.
Queramos ter uma viso da figura maior, uma vista area do que estava acontecendo

32
com todos os nossos projetos. Juntas, estas premissas e algumas outras, serviram como
nossa fundao.

Esse estgio nao sobre os mnimos detalhes. sobre grandes questes. O que a
aplicao precisa fazer? Como saberemos quando ser til? O que exatamente faremos?
Isso sobre ideias de alto nvel, nao discusses no nvel dos pixels. Nesse estgio, esses
tipos de detalhe simplesmente no tm sentido.

Papel de Padeiro
Esboos so rpidos, sujos e baratos e exatamente como voc quer comear. Desenhe
coisas. Rabisque coisas. Caixas, crculos, linhas. Arranque as ideias da cabea para o
papel. O objetivo nesse ponto deve ser converter conceitos em designs grosseiros de
interface. Esse passo apenas sobre experimentao. No h respostas erradas.

Crie telas HTML

Faa uma verso HTML dessa funcionalidade (ou seo, ou fluxo, se for mais
apropriado). Pegue algo real e publique para que todos possam ver como fica na tela.

Para o Basecamp, primeiro fizemos a tela de postar mensagens, ento a tela de editar
mensagens e a coisa prosseguiu da.

No escreva nenhum cdigo de programao ainda. Apenas faa um prottipo em html

e css. A implementao vem depois.

Codifique
Quando o prottipo parecer bom e demonstrar o suficiente das funcionalidades
necessrias, v em frente e conecte o cdigo de programao.

Durante todo esse processo, se lembre de permanecer flexvel e esperar mltiplas

iteraes. Voc deve se sentir livre para jogar fora qualquer parte entregvel de qualquer
passo particular e comear novamente se ela se mostrar lixo. natural passar por esse
ciclo mltiplas vezes.

Evite Preferncias
Decida sobre os pequenos detalhes para que seus
clientes no precisem
Nos deparamos com uma deciso difcil: quantas mensagens inclumos em cada pgina?
A primeira inclinao pode ser em dizer, Vamos apenas tornar isso uma preferncia
onde as pessoas possam escolher 25, 50 ou 100. Entretanto, essa a forma mais
simples. Apenas tome a deciso.

33
Preferncias so uma maneira de evitar tomar decises
difceis
Em vez de usar nossa experincia para escolher o melhor caminho, deixamos nas mos
dos clientes. Pode parecer que estamos fazendo um favor a eles mas apenas estamos
lhes dando mais trabalho (e provavelmente eles j so ocupados o suficiente). Para os
clientes, telas de preferncia com uma quantidade infinita de opes so uma dor de
cabea, no uma bno. Clientes no deveriam ter que pensar sobre cada nfimo
detalhezinho no coloque esse peso sobre eles quando deveria ser sua
responsabilidade.

Preferncias tambm so ms porque criam mais software. Mais opes requerem mais
cdigo. E tambm ainda tem todo o teste extra e design que precisamos fazer. E ainda
vamos acabar com permutaes de preferncias e telas que nunca usaremos. Isso
significa bugs que no sabemos a respeito: layouts quebrados, tabelas explodindo,
problemas estranhos de paginao, etc.

Tome a deciso
Tome as decises simples no lugar dos clientes. o que fizemos no Basecamp. O
nmero de mensagems por pgina 25. Na pgina de resumo, as ltimas 25 so
mostradas. Mensagens so ordenadas em ordem cronolgica reversa. Os cinco projetos
mais recentes so mostrados no painel. No existem opes. o jeito que tem que ser.

Sim, podemos tomar uma deciso ruim. Mas e da? Se fizermos isso, as pessoas vo
reclamar e nos dizer sobre isso. Como sempre, podemos ajustar. Cair na Real
justamnete sobre ser capaz de mudar em tempo real.

Preferncias Tm um Custo

No fim das contas preferncias tem um custo. Claro, algumas preferncias tambm tm
benefcios importantes e podem ser funcionalidades de interface cruciais. Mas cada
um tem um preo e temos que considerar cuidadosamente seu valor. Muitos usurios e
desenvolvedores no entendem isso e acabam com muito custo e pouco valor por seus
dlares de preferncias acho que se formos duramente disciplinados sobre ter bons
padres Que Apenas Funcionam, em vez de adicionar preferncias folgadamente, isso
naturalmente leva a interface de usurio como um todo na direo certa.

Havoc Pennington, lder tcnico, Red Hat (de Software Livre e boas interfaces de
usurio)

"Feito !"
Decises so temporrias ento faa a escolha e siga em
frente

34
Feito. Comece a pensar nisso como uma palavra mgica. Quando algo est feito
significa que algum objetivo foi atingido. Uma deciso foi tomada e podemos seguir em
frente. Feito significa que estamos construindo momento.

Mas espere, e se ferramos e tomamos a deciso errada? Tudo bem. Isso no cirurgia
de crebro, uma aplicao web. Como estamos dizendo, provavelmente teremos que
rever funcionalidades e ideias mltiplas vezes durante o processo de qualquer forma.
No importa quanto planejamos, com certeza estaremos meio errados de qualquer jeito.
Ento no faa essa coisa de pausa para anlise. Isso apenas desacelera o progresso e
compromete a moral.

Em vez disso, avalie a importncia de seguir em frente. Entre no ritmo de tomar

decises. Tome uma deciso rpida e simples e ento retorne e mude se no funcionar.

Aceite que decises so temporrias. Aceite que erros vo acontecer e entenda que no
tem nada demais enquanto estivermos fazendo correes rapidamente. Execute,
construa momento, e siga em frente.

Seja um Executador

to engraado quando ouo sobre pessoas protegendo tanto suas ideias. (Pessoas que
querem que eu assine um contrato de sigilo antes de me contar a mais simples das
ideias).

Para mim, ideias no valem nada at serem executadas. So apenas multiplicadores.

Execuo vale milhes.

Explicao:

Ideia Pssima = -1
Ideia Fraca = 1
Ideia mais ou menos = 5
Boaideia= 10
Grandeideia= 15
Brilhanteideia= 20

Nenhuma execuo = $1
Execuo Fraca = $1.000
Execuo mais ou menos = $10.000
Boa Execuo = $100.000
Grande Execuo = $1.000.000
Brilhante Execuo = $10.000.000

Para fazer negcios, voc precisa multiplicar os dois.

Aideiamais brilhante, sem nenhuma execuo, vale $20. Aideiamais brilhante necessita
de grande execuo para valer $20.000.000.

Esse o motivo porque no quero ouvir ideias de outras pessoas. No estou interessado
at ver suas execues.

Derek Sivers, presidente e programador, CD Baby e HostBaby

35
Teste ao Ar Livre
Teste sua aplicao com uso do mundo real
No h substituto para pessoas reais usando sua aplicao de maneiras reais. Pegue
dados reais. Receba feedback real. Ento aprimore baseado nessa informao.

Testes de usabilidade formais so muito duros. Configuraes de laboratrio no

refletem a realidade. Se ficarmos sobre os ombros de algum, teremos algumaideiado
que est funcionando ou no mas as pessoas normalmente no agem bem de frente para
as cmeras. Quando outra pessoa est olhando, as pessoas so especialmente mais
cuidadosas para no cometer erros sendo que erros so exatamente o que estamos
procurando.

Em vez disso, lance verses beta para alguns poucos selecionados dentro da prpria
aplicao real. Faa com que usem as funcionalidades do beta ao lado das
funcionalidades lanadas. Isso ir expr essas funcionalidades a dados reais das pessoas
e a fluxos verdadeiros. E a que teremos resultados reais.

Alm disso, no tenha uma verso de lanamento e outra beta. Elas devem ser sempre a
mesma coisa. Uma verso beta separada s receber uma leve navegao. A verso real,
com algumas funcionalidades beta misturadas, recebero o fluxo de uso completo.

O Livro Beta

Se desenvolvedores esto nervosos liberando seus cdigos, ento editores e autores

esto assustados lanando seus livros. Uma vez que o livro est fixo no papel, visto
como uma coisa cabeluda mudar (na verdade no , mas percepo e lembranas de
problemas com velhas tecnologias ainda persistem na indstria). Ento, editores passam
por vrios problemas (e custos) tentando fazer os livros ficarem certos antes de serem
lanados.

Quando escrevi o livro Agile Web Development With Rails, houve muita demanda
entre os desenvolvedores: nos d o livro agora queremos aprender Rails. Mas eu ca
no pensamento de um editor. No est pronto ainda, eu dizia. Mas a presso da
comunidade e trocas de ideias com David Heinemeier Hansson mudaram minha forma
de pensar. Lanamos o livro em formato pdf cerca de 2 meses antes de ficar completo.
Os resultados foram espetaculares. No apenas vendemos um monte de livros, mas
recebemos feedback muito feedback. Configurei um sistema automatizado para
capturar os comentrios dos leitores, e no final tivemos quase 850 relatos de erros de
digitao, erros tcnicos e sugestes para novo contedo. Quase todos encontraram seu
caminho para o livro final.

Foi uma situao ganha-ganha: consegui entregar um livro muito melhor e a

comunidade teve acesso antecipado a algo que eles queriam. E se voc est numa
corrida competitiva, ter algo antecipado ajuda as pessoas a se comprometerem com voc
e no com sua competio.

36
Dave Thomas, The Pragmatic Programmers

Faa isso rpido

1. Decida se vale a pena fazer, e se for:

2. Faa rpido No perfeito. Apenas faa;
3. Grave. Faa upload. Publique;
4. Veja o que as pessoas acham.

Embora eu esteja sempre relutante em adicionar novas funcionalidades s coisas,

quando tenho aquele momento "isso!" de deciso de que alguma coisa vale a pena fazer,
normalmente est no ar no website algumas horas depois, com falhas mas lanado,
deixando o feedback guiar o futuro dos refinamentos nele.

Derek Sivers, presidente e programador, CD Baby e HostBaby

Encolha Seu Tempo

Quebre
Estimativas que esticam em semanas ou meses so fantasias. A verdade que
simplesmente no sabemos o que vai acontecer daqui tanto tempo frente.

Ento encolha seu tempo. Continue quebrando seu cronograma em pedaos menores.
Em vez de um projeto de 12 semanas, pense nele como 12 projetos semanais. Em vez
de chutar tarefas que levam 30 ou mais horas, quebre em pedaos mais realistas de 6 a
10 horas. Ento proceda, um passo de cada vez.

A mesma teoria se aplica para outros problemas tambm. Voc est enfrentando um
problema to grande que no cabe na sua cabea? Quebre. Continue dividindo os
problemas em pedaos cada vez menores at que voc seja capaz de diger-los.

Tarefas Menores e Cronogramas Menores

Desenvolvedores de software so uma espcie especial de otimistas: quando

apresentados a uma tarefa de programao, eles pensam, Isso ser fcil! No vai levar
tanto tempo, afinal de contas.

Ento, d trs semanas a um programador para completar a enorme tarefa, e ele gastar
duas semanas e meia procrastinando, e ento uma programando. O atraso no
cronograma provavelmente encontrar os requisitos errados, porque a tarefa se mostrou
mais complexa do que parecia. Alm disso, quem vai lembrar o que foi acordado entre a
equipe trs semanas atrs?

D a um programador uma tarde para codificar um mdulo pequeno, especfico e ele vai
devor-lo, pronto para ir para o prximo.

37
Tarefas menores e cronogramas menores so mais gerenciveis, escondem menos
requisitos mal entendidos e custam menos para voc mudar deideiaou refazer.
Cronogramas menores mantm os desenvolvedores engajados e lhes d mais
oportunidades para aproveitar um senso de conquista e menos razes para pensar, oh,
eu tenho tempo suficiente para fazer isso. Por ora, vou terminar de categorizar minhas
msicas no meu iTunes.

Gina Trapani, desenvolvedora web e editora da Lifehacker, o guia da produtividade

e software

Fatores Verdadeiros

Da prxima vez que algum o pressionar por uma resposta exata a uma questo
desconhecida seja sobre uma data de entrega, o custo final do projeto ou o volume de
leite que caberia no Grand Canyon apenas comece tirando o ar da sala: diga, "Eu no
sei".

Longe de danificar sua credibilidade, isso demonstra o cuidado que voc trs sua
tomada de decises. Voc no est dizendo palavras apenas para parecer esperto. Isso
tambm nivela o campo de jogo reformulando a questo como uma conversa
colaborativa. Sabendo quo exata sua estimativa precisa ser (e porque), voc pode
trabalhar junto para desenvolver um entendimento compartilhado sobre os verdadeiros
fatores por trs dos nmeros.

Merlin Mann, criador e editor da 43folders.com

Resolva Aquele Problema Que Est Te Encarando na Cara

Minha coisa absolutamente favorita que acontece na web em tempos recentes o

lanamento e adoo do atributo "nofollow" ("no siga"). Ningum falou sobre isso de
antemo. No houve conferncias ou comits onde um bando de gente poderia debater a
semntica ou natureza gramatical. Nenhuma RFC que poderia tornar umaideiasimples
em um pedao de XML de 20 linhas que eu teria que ler de cabo a rabo apenas para
entender como us-lo, e ento no usar porque eu no teria certeza se estava formatado
para a verso .3 ou 3.3b

simples, efetivo, forneceu uma opo s pessoas que queriam uma opo e isso
muito mais importante ao lidar com uma populao da web que no se importa com
especificaes ou deferncias.

Algumas vezes resolver os prximos vinte problemas no to til ou prudente quanto

resolver aquele um que est nos encarando diretamente na nossa cara. No foi apenas
uma pequena vitria contra o SPAM (todas as vitrias contra SPAM so pequenas), mas
uma vitria para aqueles de ns que apreciam os resultados simples e diretos sobre ser
um desenvolvedor web.

Andre Torrez, programador e VP de Engenharia na Federated Media Publishing

A Organizao captulo 7

38
Unidade
No quebre em reas
Muitas empresas separam design, desenvolvimento, redao, suporte e marketing em
reas isoladas. Enquanto a especializao tem suas vantagens, tambm cria uma
situao em que os funcionrios s enxergam seus prprios mundos ao invs da
aplicao web como um todo.

Integre sua equipe ao mximo para que exista um dilogo contnuo em todas as etapas
do processo. Faa um sistema de verificaes e balanos. No deixe que coisas se
percam nas transcries. Tenha redatores trabalhando com designers. Faa com que os
desenvolvedores tenham cincia dos pedidos de suporte.

Melhor ainda, contrate pessoas com mltiplos talentos, que podem atuar em diversas
frentes. O resultado final ser um produto mais harmonioso.

Tempo Sozinho
Pessoas precisam de perodos sem interrupes para
terminar o trabalho
37signals est espalhada por quatro cidades e oito fusos-horrio. De Provo, Utah a
Copenhagen, na Dinamarca, cinco de ns estamos oito horas distantes. Um dos efeitos
positivos de se ter oito horas de diferena o tempo em que podemos ficar sozinhos.

Apenas 4 a 5 horas por dia estamos trabalhando juntos. Em algumas horas, a equipe
norte-americana est dormindo enquanto David, que est na Dinamarca, est
trabalhando. Nas horas restantes, estamos trabalhando enquanto David est dormindo.
Isso nos d meio dia juntos e meio dia sozinhos.

Adivinhe qual a parte do dia em que somos mais produtivos? O tempo em que estamos
sozinhos. E isso no nenhuma surpresa. Muitas pessoas preferem trabalhar logo de
manhzinha ou tarde da noite nas horas em que no so incomodados.

Quando voc tem um longo perodo em que no incomodado, consegue se concentrar.

E concentrado se mais produtivo. quando voc no tem que dividir a cabea com
outros assuntos ou tarefas. quando no se interrompido para responder algo, ou
procurar alguma coisa, ou enviar um email, ou responder mensagens instantneas. O
tempo sozinho onde progressos de verdade acontecem.

Se concentrar leva tempo. E exatamente por isso que a interrupo seu maior
inimigo. como pegar no sono profundo no se entra no sono profundo do nada, tem
que se deitar, dormir e ento entrar no sono profundo. Qualquer interrupo o fora a
comear tudo de novo. O sono profundo onde a mgica do sono acontece de verdade.
A concentrao onde a mgica da produtividade acontece de verdade.

39
Estabelea uma regra: faa que metade do dia seja de horas onde voc fica sozinho. Das
10 da manh at s 2 da tarde, ningum pode falar com ningum mais (exceto durante o
almoo). Ou ento, faa com que a manh ou a tarde seja o seu tempo para ficar
sozinho. O importante que o perodo seja contnuo para evitar interrupes que matam
sua produtividade.

Um perodo de tempo sozinho significa largar o vcio da comunicao. Durante o tempo

que ficar sozinho, esquea as mensagens instantneas, ligaes telefnicas, reunies.
Evite qualquer conversa por e-mail que exija respostas imediatas. Em resumo: cale a
boca e trabalhe.

Se Concentrando

Todos sabemos que profissionais sbios trabalham melhor entrando no clima, tambm
chamado de se concentrar, onde ficam totalmente concentrados em seus trabalhos e
completamente desligados dos seus ambientes. Eles perdem a noo do tempo e
produzem muito mais atravs de concentrao absoluta o problema que muito
fcil perder a concentrao. Barulho, telefonemas, sada para o almoo, ter que dirigir
por 5 minutos pra comer um po de queijo e interrupes por colegas de trabalho
especialmente interrupes por colegastudo te tira da zona de concentrao. Se voc
parar por 1 minuto para responder a uma pergunta de um colega de trabalho, e isso tirar
sua concentrao o suficiente para levar meia hora pra voltar a ser produtivo novamente,
sua produtividade geral est em srios problemas.

Joel Spolsky, desenvolvedor de software, Fog Creek Software

(de De Onde Essas Pessoas Tiram Essas Ideias (No Originais)?)

Reunies So Txicas
No tenha reunies
Voc precisa mesmo de reunies? Reunies geralmente acontecem quando um conceito
no est claro o suficiente. Ao invs de recorrer a uma reunio, tente simplificar o
conceito, para que voc possa discut-lo rapidamente por email ou IM ou Campfire. O
objetivo evitar reunies. Cada minuto que voc gasta em uma reunio um minuto
que voc poderia estar trabalhando.

No existe nada mais txico produtividade do que uma reunio. Aqui vo alguns
motivos:

Elas quebram seu trabalho dirio em pequenos perodos, que acabam por
quebrar o fluxo do trabalho
Elas geralmente tratam apenas de palavras e conceitos abstratos, no de coisas
reais (como um trecho de cdigo ou algum detalhe do design de interface)
Elas geralmente tratam de uma pequena quantidade de informaes por minuto
Elas quase sempre tem uma pessoa que inevitavelmente vai fazer com que todos
percam o tempo com assuntos no relacionados
O assunto principal vai embora muito facilmente

40
 Freqentemente tem pautas to vagas que ningum tem certeza do assunto
principal
Requerem uma preparao prvia, que quase ningum faz

Em casos em que reunies so realmente necessrias (faa disso um raro evento), siga
estas regras simples:

Coloque um alarme pra 30 minutos. Assim que ele tocar, a reunio acabou.
Ponto final.
Chame o menor nmero de pessoas possvel.
Nunca tenha uma reunio sem uma pauta bem clara.

Tenha menos reunies

Existem muitas reunies. Fazer reunies que no fazem sentido uma tarefa
improdutiva. S agende uma reunio quando voc tem um assunto muito importante
para discutir e voc quer ou precisa de uma ideia, aprovao ou aval. Mesmo assim,
resista bravamente tentao de convidar todo mundo no desperdice o tempo das
outras pessoas sem necessidade.

Lisa Haneberg, autora (de No Deixe as Reunies Ditarem as Regras!)

Quebre-as

Conforme o projeto cresce, o acrscimo de pessoas diminui a produtividade. Uma das

razes mais interessantes o aumento do nmero de canais de comunicao. Duas
pessoas podem falar entre si; um canal de comunicao nico. Trs pessoas tem trs
canais de comunicao; 4 tem 6. Na verdade, o crescimento dos canais exponencial
Logo, memorandos e reunies vo acabar consumindo o tempo todo.

A soluo clara: quebre as equipes em unidades pequenas, autnomas e

independentes, para reduzir os canais de comunicao.

Da mesma forma, quebre os programas em unidades pequenas. Uma grande parte do

problema vm de dependncias externas (variveis globais, dados passados entre
funes, hardware compartilhado, etc), encontre um jeito de quebrar o programa para
eliminar ou minimizar as dependncias entre as unidades.

Grupo Ganssle (de Mantenha Pequeno)

Procure e Celebre Pequenas Vitrias

Entregue algo hoje
A coisa mais importante em desenvolvimento de software motivao. Motivao
localizadase voc no est motivado pelo que est trabalhando neste instante, as
chances de que isso no saia to bom so grandes . Na verdade, isso provavelmente vai
ficar ruim.

41
Ciclos de entregas longos e demorados so assassinos de motivao. Eles separam
muito o tempo entre as comemoraes. Por outro lado, conquistas rpidas que voc
pode comemorar so grandes motivadores. Se voc deixar que as entregas demorem a
acontecer, voc estar matando a motivao. E isso pode matar o produto.

Portanto, se voc est no meio de um ciclo de entrega que demora meses, dedique um
dia por semana (ou a cada duas semanas) para pequenas vitrias. Pergunte-se o que ns
podemos fazer e entregar em 4 horas?. E ento, faa isso. Este tipo de trabalho poderia
ser ...

Uma funcionalidade simples

Um pequeno ajuste a algo que j existe
Reescrever algum texto de ajuda, que reduz o nmero de pedidos de suporte
Em alguns formulrios, remova alguns campos que voc no precisa

Quando conseguirem esta vitria de 4 horas, voc vai encontrar a comemorao. E isso
constri a moral, aumenta a motivao e assegura que a equipe est na direo certa.

Contratando captulo 8

Contrate Menos e Contrate Mais Tarde

Adicione devagar para andar rpido
No existe necessidade de ficar grande logo ou depois de algum tempo. Mesmo se
voc tem acesso s 100 melhores pessoas, no bom tentar contrat-las todas de uma
vez. Voc no conseguir fazer tanta gente assim assimilar a cultura da sua empresa.
Voc ter problemas no treinamento, disputas pessoais, problemas de comunicao,
pessoas indo em direes opostas e muito mais.

Portanto, no contrate. Falando srio, no contrate. Procure outra sada. O trabalho est
to puxado assim a ponto de voc realmente precisar de mais gente? Porqu voc
mesmo no faz? Voc pode resolver o problema com algum software ou uma mudana
nas prticas?

Toda vez que Jack Welch, antigo CEO da GE, precisava demitir algum, ele no
contratava algum de imediato para substitu-la. Ele queria ver por quanto tempo a GE
poderia sobreviver sem aquela pessoa e sem aquele cargo. Claro, no estamos
incentivando ningum a demitir pessoas para testar esta teoria, mas ns achamos que
Jack acertou em algo: Voc no precisa de tanta gente quanto voc pensa.

Se no tem outro jeito, ento pense em contratar. Mas voc deve saber exatamente o que
precisa, apresentar os candidatros ao trabalho e mostr-los o tipo de sofrimento voc
quer que eles tenham.

Lei de Brooks

42
Adicionar pessoas a um projeto de software atrasado vai atras-lo ainda mais.

Fred Brooks

Programao e Requiem de Mozart

Um nico bom programador trabalhando em uma nica tarefa no tem excesso de

coordenao ou comunicao. Cinco programadores trabalhando na mesma tarefa
precisam se coordenar e se comunicar. E isso toma muito tempo O problema em usar
muitos programadores medianos ao invs de alguns bons programadores que, no
importa o tempo que eles tomem, o resultado nunca vai ser to bom quanto o que os
bons programadores vo produzir. Cinco Antonio Salieris no vo produzir um
Requiem, de Mozart. Nem se trabalhassem por 100 anos.

Joel Spolsky, desenvolvedor de software, Fog Creek Software (de Acertando as Notas
Maiores)

Chute os Pneus
Trabalhe com possveis funcionrios na base do teste
antes
Uma coisa olhar o portflio, curriculum, exemplo de cdigo ou trabalhos anteriores.
Outra coisa efetivamente trabalhar com algum. Sempre que possvel, faa um test-
drive com possveis novos membros da equipe.

Antes de contratar algum, passe a ele um pequeno projeto antes. Vamos ver como ele
assume o projeto, como ele se comunica, como ele trabalha, etc. Trabalhar com algum
conforme ele faa o design ou codifique algumas telas vai te dar uma boaideiasobre a
pessoa. Voc ver rapidamente se a pessoa ou no o que voc precisa.

O tempo de trabalho para este projeto pode ser pequeno. Mesmo que sejam 20 ou 40
horas, melhor do que nada. Se o tempo ou no suficiente, isso se tornar bvio. Em
todo caso, ambos os lados se livraro do risco e dor de cabea testando antes.

Comece com pouco

Faa um pequeno teste no comeo. No jogue todo o trabalho para a pessoa de uma vez.
D a seu novo [assistente virtal] um ou outro projeto de teste e veja como a qumica se
desenvolve. Neste comeo, mais fcil de detectar problemas em potencial. Deixe claro
de que este um perodo de experincia.

Suzanne Falter-Barns, autora/especialista em criatividade

(de Como Encontrar e Manter o Assistente Virtual Perfeito)

43
Aes, No Palavras
Julgue potenciais contrataes de tecnologia em
contribuies open source
O mtodo tradicional de contratao para cargos tcnicosbaseados em faculdades,
curriculums, etc. falho por diversas razes. Realmente importa onde a pessoa
formada ou suas notas? Podemos confiar mesmo em um curriculum ou indicao?

Open source uma ddiva para aqueles que precisam contratar tcnicos. Com open
source, pode-se checar o trabalho e contribuies de algumpra bem ou malcom
um bom intervalo de tempo.

Isso significa que voc pode julgar pessoas pelas aes ao invs de apenas palavras.
Voc pode tomar decises com base no que realmente importa:

Qualidade do trabalho
Muitos programadores falam bonito, mas afinam na hora do vamos ver. Com
open source, voc consegue ver com detalhes as prticas e conhecimentos de
programao de uma pessoa.
Perspectiva cultural
Programar tomar decises. Muitas delas. Decises so tomadas com base na
cultura, nos valores e em ideais. Veja as decises especficas feitas por um
candidato enquanto est programando e testando, e veja seus argumentos na
comunidade para ver se o candidato est dentro do que a empresa espera. Se no
se encaixa na empresa, as decises podem parecer erradas.
Nivel de paixo
Por definio, envolvimento em projetos open source requerem um nvel
mnimo de paixo. Se no, porque outro motivo a pessoa perderia tempo na
frente de um monitor? O tamanho do envolvimento em movimentos open source
mostra quanto um candidato realmente se importa com programao.
Porcentagem de finalizao
Toda a inteligncia, toda a cultura e paixo no se transformam em software de
valor se o candidato no consegue termin-lo. Infelizmente, muitos
programadores no terminam seus projetos. Ento, procure a exceo. Contrate
aquele que consegue sair pela porta e est disposto a fazer as trocas pragmticas
que o trabalho exige.
Lado social
Trabalhar com algum por um bom perodo de tempo, durante tanto as horas de
stress e descontrao e altos e baixos vo mostrar a verdadeira personalidade do
candidato. Se algum no tem modos ou um lado socivel, deixe-os de lado.

Quando estamos falando de programadores, somente contratamos pessoas que ns

conhecemos atravs do open source. Ns acreditamos que se adotarmos qualquer outro
mtodo, estamos sendo irresponsveis. Contratamos Jamis porque ns gostamos de seus
releases e participao na comunidade Ruby. Ele se superou em todas as reas que
acima. No precisamos verificar mais nada, j que ns pudemos julg-lo com base no
que realmente importa: qualidade do seu trabalho.

44
E no se preocupe se as atividades extra-curriculares roubarem o foco e paixo do
trabalho dirio dos funcionrios. Como diz aquele velho ditado: se quer algo feito, pea
pessoa mais ocupada que voc conhece. Jamis e David so dois dos maiores
contribuidores do Rails e ainda conseguem dirigir tecnicamente a 37signals. Pessoas
que amam programar e terminar seus projetos so exatamente o tipo de pessoa que voc
quer em sua equipe.

Paixo open source

O que voc mais quer de um novo funcionrio paixo pelo que ele faz, e no h jeito
melhor de mostrar isso do que a trllha de comprometimento em projetos open source.

Jarkko Laine, desenvolvedor de software

(de Reduza o risco, contrate de open source)

Procure Indivduos Equilibrados

Procure por generalistas que aprendem rpido em vez
dos especialistas limitados
Nunca contrataremos algum que seja um arquiteto de informao. simplesmente
especfico demais. Com uma equipe pequena como a nossa, no faz sentido contratar
pessoas com um conjunto de conhecimento to limitado.

Equipes pequenas precisam de pessoas que possam vestir diferentes chapis.

Precisamos de designers que saibam escrever. Precisamos de programadores que
entendam de design. Todos devem ter noo de como arquitetar informao (seja l o
que isso signifique). Todos precisam ter mentes organizadas. Todos precisam saber se
comunicar com clientes.

E todos precisar querer e serem capazes de diminuir a marcha pela estrada. Tenha em
mente que equipes pequenas eventualmente precisam mudar de direo rapidamente.
Queremos algum que possa se ajustar, aprender e fluir ao contrrio de um p-na-lama
que s consegue fazer uma coisa.

Voc No Pode Falsificar Entusiasmo

V com feliz e mediano em vez de frustrado e grande
Entusiasmo. um atributo que simplemente no se pode falsificar. Quando chega a
hora de contratar, no pense que precisa de um guru ou uma celebridade high-tech.
Normalmente, de qualquer maneira so apenas divas. Um empregado mediano, mas
feliz melhor do que um expert que fica grunhindo.

45
Encontre alguem entusiasmado. Algum em quem possa confiar para fazer as coisas
quando deixado sozinho. Algum que sofreu em uma empresa grande, devagar e deseja
um novo ambiente. Algum que est excitado para construir o que voc est
construindo. Algum que odeia as mesmas coisas que voc. Algum que mal consegue
esperar para subir a bordo do seu trem.

Pontos extras por fazer perguntas

Observe se um candidato em potencial faz muitas pergumtas sobre seu projeto.

Programadores apaixonados querem entender um problema to bem quanto possvel e
rapidamente iro propor solues potenciais e melhorias, o que leva a muitas perguntas.
Perguntas esclarecedoras tambm revelam um entendimento de que seu projeto poderia
ser implementado de milhares de maneiras diferentes e essencial detalhar o mais
explicitamente quanto for possvel como voc imagina sua aplicao web funcionando.
medida que vai cavando nos detalhes, voc desenvolver um senso se a pessoa bem
aculturada.

Eric Stephens, BuildV1.com

Artesos de Palavras
Contrate bons escritores
Se est tentando decidir entre poucas pessoas para preencher uma posio, sempre
contrate o melhor escritor. No importa se essa pessoa um designer, programador,
marketing, vendedor ou o que for, essa habilidade leva a escrever mais efetivamente e
concisamente cdigo, design, emails, mensagens instantneas e mais.

Isso porque ser um bom escritor mais do que apenas palavras. Bons escritores sabem
como se comunicar. Eles tornam as coisas mais fceis de entender. Eles podem se
colocar no lugar dos outros. Eles sabem o que omitir. Eles pensam claramente. E essas
so as qualidades que voc precisa.

Uma Mente Organizada

Boas habilidades de escrita so um indicador de uma mente organizada que capaz de

arranjar informao e argumentos de uma maneira sistemtica e tambm ajudar (no
fazer) outras pessoas a entender as coisas. Isso aparece no cdigo, comunicao pessoal,
mensagens instantneas (para aqueles colaboradores de longa distncia) e at esses
conceitos exotricos como profissionalismo e confiana.

Dustin J. Mitchell, developer (de Signal vs. Noise)

Escrita Clara leva a Pensamento

Escrita clara leva a pensamento claro. Voc no sabe o que sabe at tentar expressar
esse conhecimento. Boa escrita em parte uma questo de carter. Em vez de fazer o
que fcil para voc, faa o que mais fcil para seu leitor.

46
Michael A. Covington, professor de cincias da computao da Universidade da
Gergia
(de Como Escrever mais Claramente, Pensar mais Claramente e aprender Material
Complexo mais Facilmente)

Design de Interface captulo 9

Primeiro a Interface
Desenhe a interface antes de comear a programar
Muitos aplicativos comeam com a mentalidade de programar primeiro. Isso uma m
ideia. Programao o componente mais pesado de construir em um aplicativo,
significando ser o mais caro e mais difcil de mudar. Ao invs disso, comece
desenhando primeiro.

Design relativamente leve. Um esboo de papel barato e fcil de mudar. Rascunhos

HTML so relativamente simples de modificar (ou jogar fora). Isso no verdade na
programao. Desenhar antes deixa voc flexvel. Programar primeiro prende voc e
gera custos adicionais.

Outra razo para projetar primeiro que a interface o seu produto. O que as pessoas
vem o que voc est vendendo. Se voc somente rabiscar uma interface no final, os
buracos vo aparecer.

Ns comeamos pela interface para que possamos ver como o aplicativo ser desde o
comeo. Este ser constantemente revisado no decorrer do processo. Isso faz sentido?
fcil de usar? Ele resolve um problema de imediato? Existem perguntas que voc s
poder realmente responder quando voc lidar com telas reais. Desenhar antes deixa
voc flexvel e o leva para essas respostas no processo mais cedo do que mais tarde.

A Caneta Laranja que Iniciou Blinksale

Assim que eu me toquei da minha frustao com o software de cobranas de prateleira,

eu decidi desenhar como eu gostaria que minha soluo de cobrana funcionasse. Eu
retirei uma caneta laranja, porque era a nica em mos naquela noite e tive
aproximadamente 75 por cento da UI desenhada em algumas horas. Eu mostrei para
minha esposa, Rachel, que estava passando roupa no momento, e perguntei, O que
voc acha? E ela respondeu com um sorriso, Voc precisa fazer isso. Pra valer.

Nas duas semanas seguintes eu refinei o design, e criei quase todos os prottipos HTML
estticos para a primeira verso do que se tornaria Blinksale. Ns nunca fizemos
wireframes alm daqueles rabiscos de caneta laranja, e chegando direto no design
HTML nos ajudou a ficar excitados sobre o quo/como real o projeto estava tornando,
mesmo que ns realmente no sabamos o que estvamos comeando.

Uma vez que os prottipos do HTML foram terminados, ns apresentamos ao nosso

desenvolvedor Scott, aideiapara Blinksale. Ter a maioria da Interface de Usurio (UI,

47
User Interface em ingls) projetada anteriormente foi extremamente benfico em
diversos nveis. Primeiramente, demos a Scott uma viso real e um clareamento para
onde ns iramos. Era muito mais do que apenas uma ideia, ele era real. Em seguida, ele
nos ajudou a medir exatamente quanto do esforo e tempo seria necessrio para tornar o
design/projeto em uma aplicao funcionando. Quando voc est amarrado
financeiramente um projeto, quanto mais cedo voc pode predizer exigncias do
oramento melhor. O projeto de UI tournou-se nossa marca de nvel para o escopo
inicial do projeto. Finalmente, o projeto do UI serviu como um guia para nos lembrar
sobre o que a aplicao era quando progredamos mais no desenvolvimento. Enquanto
nos era tentador adicionar caractersticas novas, ns no poderamos simplesmente
dizer, Certo, vamos adicionar isso! Tivemos que voltar para trs ao projeto e
perguntar a ns mesmos onde essa caracterstica nova iria, e se no tivesse um lugar,
no seria adicionada.

Josh Williams, fundador, Blinksale

Design de Epicentro
Comece do ncleo da pgina e construa para fora
Design de epicentro foca na verdadeira essncia da pgina o epicentro e ento
constri para fora. Isso significa que, no comeo, voc ignora as extremidades: a
navegao/menus, rodap, cores, barra lateral, logotipo, etc. Em vez disso, voc comea
o epicentro e faz o design das peas de contedo mais importantes primeiro.

Seja qual for a pgina ela no pode viver sem seu epicentro. Por exemplo, se estiver
fazendo o design de uma pgina que mostra a publicao de um blog, a publicao por
si o epicentro. No as categorias na barra lateral, no o cabealho no topo, no o
formulrio de comentrios embaixo, mas a unidade de publicao de mensagem do
blog. Sem essa unidade de publicao, a pgina no a publicao de um blog.

Somente quando essa unidade est completa voc comearia a pensar no segundo
elemento mais crtico da pgina. Ento, depois desse segundo elemento mais crtico, se
moveria para o terceiro, e assim por diante. Isso design de epicentro.

Design de epicentro evita o tradicional modelo "vamos construir a moldura ento jogar
o contedo dentro". Nesse processo, o formato da pgina construda, ento a
navegao includa, ento as "coisas" de marketing so inseridas e ento, finalmente, o
ncleo da funcionalidade, o verdadeiro propsito da pgina, enfiado em um espao
qualquer que tenha sobrado. um processo de trs para frente que tira o que deveria ser
a prioridade principal e deixa isso para o fim.

Design de Epicentro vira esse processo e permite que voc foque no que realmente
interessa no dia um. Essenciais primeiro, extras em segundo. O resultado uma tela
mais amigvel, focada e usvel para os clientes. Alm disso, permite que voc comece o
dilogo entre designer e desenvolvedor logo de cara em vez de esperar por todos os
aspectos da pgina carem na linha primeiro.

48
Soluo de Trs Estados
Faa design para os estados regular, branco e erro
Para cada tela, voc precisa considerar trs estados possveis:

Regular
A tela que as pessoas vem quando tudo est funcionando bem e sua aplicao
preenchida com dados.
Branco/Vazio
A tela que as pessoas vem quando esto usando a aplicao pela primeira vez,
antes de dados serem inseridos.
Erro
A tela que as pessoas vem quando alguma coisa d errado.

O estado regular trivial. a tela onde voc vai gastar a maior parte do tempo. Mas no
se esquea de investir tempo nos outros estados tambm (veja os artigos seguintes para
mais sobre isso).

A Tela em Branco
Supere as expectativas com uma primeira experincia
convincente
Ignorar o estado de superfcie branca um dos maiores erros que voc pode cometer. O
estado branco a primeira impresso de sua aplicao e voc nunca ter uma segunda ...
bem, voc sabe.

O problema que quando se faz o design da interface de usurio, normalmente ela est
preenchida de dados. Designers sempre preenchem os desenhos com dados. Cada lista,
cada publicao, cada campo, cada canto e espacinho tem coisa dentro. E isso significa
que a tela parece pronta e funciona muito bem.

Entretanto, o estado natural da aplicao vazia de dados. Quando algum se cadastra,

eles comeam com uma tela em branco. Muito parecido com um weblog, cabe a eles
popularem o visual geral no toma forma at as pessoas colocarem seus dados:
publicaes, links, comentrios, horas, informao de barra lateral ou o que for.

Infelizmente, o cliente decide se a aplicao vale a pena pelo estado inicial de sua tela
em branco o estado onde h a menor quantidade de informao, design e contedo
sobre o qual julgar a utilidade geral da aplicao. Quando voc falha no design
adequado deste estado em branco, as pessoas no sabem o que esto perdendo porque
tudo est faltando.

49
Mesmo assim a maioria dos designers e desenvolvedores ainda subestima esse estado.
Eles falham em gastar um bom tempo no design de telas vazias porque quando eles
desenvolvem/usam a aplicao, esta j est cheia de dados que eles colocaram para
propsitos de testes. Eles nem mesmo encontram a tela em branco. Claro, eles podem
fazer o login como uma nova pessoa algumas vezes, mas a maioria das vezes gastam
nadando em uma aplicao que est cheia de dados.

O que voc deve incluir em uma tela em branco que ajuda?

Use como uma oportunidade de inserir pequenos tutoriais e caixas de ajuda.

D uma foto da tela final como exemplo da pgina populada com dados para que
as pessoas saibam o que esperar (e porque devem ficar por l).
Explique como comear, como a tela vai ficar exatamente, etc.
Responda as perguntas-chave que visitantes de primeira viagem fazem: O que
esta pgina? O que fao agora? Como essa tela vai ficar quando estiver cheia?
Supere as expectativas e ajude a reduzir frustraes, intimidaes e a confuso
em geral.

Primeiras impresses so cruciais. Se voc falhar em fazer o design de uma tela em

branco bem pensada, criar impresso negativa (e falsa) da sua aplicao ou servio.

Voc Nunca Ganha uma Segunda Chance ...

Outro aspecto da interface do Mac OS X que acho que foi tremendamente influenciado
por [Steve] Jobs a configurao e primeira experincia. Acho que Jobs sabe muito
bem da importncia das primeiras impresses ... Acho que Jobs olha para a primeira
experincia e pensa, pode ser apenas um milionsimo da experincia geral de um
usurio com a mquina, mas o milionsimo mais importante, porque o primeiro
milionsimo, e isso supera suas expectativas e impresses iniciais.

John Gruber, autor e desenvolvedor web (de Entrevista com John Gruber)

Torne-se Defensivo
Faa Design para quando as coisas derem errado
Vamos admitir: As coisa vo dar errado online. No importa o quo cuidadoso voc
faa o design de sua aplicao, no importa quanto teste fizer, os clientes ainda vo
encontrar problemas. Ento como voc gerencia essas quedas inevitveis? Com design
defensivo.

Design defensivo como direo defensiva. Da mesma maneira como motoristas devem
estar sempre atentos para estradas escorregadias, motoristas imprudentes e outros
cenrios perigosos, construtores de sites devem procurar constantemente por pontos de
problema que causem confuso e frustrao aos visitantes. Um bom site defensivo por
criar ou quebrar a experincia do cliente.

Poderamos encher um livro separado com todas as coisas que temos a dizer sobre
design defensivo. De fato, j fizemos. "Design Defensivo para a Web" o ttulo e um

50
grande recurso para qualquer um que queira aprender como melhorar telas de erros e
outros pontos crticos.

Lembre-se: Sua aplicao pode funcionar muito bem 90% do tempo. Mas se voc
abandonar seus clientes no momento em que mais precisam, improvvel que eles se
esqueam disso.

Contexto Sobre Consistncia

O que faz sentido aqui pode no fazer sentido al
As aes devem ser botes ou links? Depende da ao. O calendrio deve ser visto em
forma de lista ou em grade? Depende de onde ele ser visto e quo longo o perodo
exibido. Todo link de navegao global deve estar em todas as pginas? Voc precisa
mesmo de uma caixa de busca em todo lugar? Voc precisa do mesmo rodap em cada
pgina? A resposta: Depende.

Isto porque contexto mais importante que consistncia. Tudo bem ser inconsistente se
o seu design faz mais sentido dessa maneira. Fornea s pessoas apenas o que importa.
Oferea a eles o que eles precisam e livre-se de tudo o que no for necessrio. melhor
ser correto do que ser consistente.

Inconsistncia Inteligente

Consistncia no necessria. Por muitos anos, estudantes de Design foram ensiados

que consistncia na interface uma das regras-chave no design. Talvez isso sirva pra
software, mas na Web, no verdade. O que importa na Web que, em cada pgina, os
usurios possam fcil e rapidamente avanar para o prximo passo no processo.

Na Creative Good, ns chamamos isso de inconsistncia inteligente: certeza de que

cada pgina no processo d ao usurio precisamente o que eles precisam naquele ponto
do processo. Adicionar elementos navigacionais suprfluos, s porque so consistentes
com o restante do site, pura bobagem.

Mark Hurst, fundador da Creative Good e criador da Goovite.com

(de O Paradigma da Pgina)

Direitos Autorais Design de Interface

Cada palavra importa
Direitos Autoriais Design de Interface. Grandes interfaces so escritas. Se voc pensar
que cada pixel, cada cone, cada fonte importa, ento precisa acreditar que cada palavra
importa. Quando est escrevendo sua interface, coloque-se sempre no lugar da pessoa

51
que est lendo sua interface. O que eles precisam saber? Como voc pode explicar
suscintamente e claramente?

Voc etiqueta um boto como Submeter ou Salver ou Atualizar ou Novo ou Criar? Isso
Direito Autoral. Voc escreve trs sentenas ou cinco? Explica com exemplos gerais
ou com detalhes? Etiqueta seu contedo como Novo ou Atualizado ou Atualizado
Recentemente ou Modificado? Ser Existem novas mensagens: 5 ou Existem 5 novas
mensagens ou 5 ou cinco ou mensagens ou publicaes? Tudo isso importa.

Voc precisa falar a mesma linguagem que sua audincia tambm. S porque est
escrevendo uma aplicao web no significa que pode sair por a com jargo tcnico.
Pense sobre seus clientes e pense sobre o que significam aqueles botes e palavras para
eles. No use acrnimos ou palavras que a maioria das pessoas no entende. No use
linguagem interna. No parea como um engenheiro falando com outro engenheiro.
Mantenha curto e doce. Diga o que precisa e no mais.

Boa escrita bom design. rara a exceo de palavras no acompanharem o design.

cones com nomes, campos de formulrios com exemplos, botes com etiquetas,
instrues passo a passo em um processo, uma explicao clara das suas polticas de
reembolso. Tudo isso design de interface.

Uma Interface
Incorpore funes administrativas em interfaces
pblicas
Telas administrativas as telas usadas para gerenciar preferncias, pessoas, etc. tem
uma tendncia de parecer um lixo. Isso porque a maioria do tempo de desenvolvimento
gasto na aparncia pblica das interfaces.

Para evitar a sndrome da tela-administrativa-lixo, no construa telas separadas para

lidar com funes administrativas. Em vez disso, construa essas funes (isto , editar,
adicionar, deletar) na interface regular da aplicao.

Se tiver que manter duas interfaces separadas (isto , uma para o pessoal regular outra
para administradores), ambas vo sofrer. Em efeito, voc acaba pagando a mesma taxa
duas vezes. Voc forado a se repetir e isso significa que voc aumenta as chances de
ficar desleixado. Quanto menos telas tiver, menos ter para se preocupar e melhor as
coisas saem.

Sem Interface Separada

A aplicao tudo. Qualquer coisa pode ser modificada, adicionada ou ajustada

diretamente atravs da rea de gerenciamento da aplicao. Isso nos permite ver
exatamente o que nossos clientes vem para ajud-los atravs de qualquer problema ou
questes que tiverem. E nossos clientes no precisam se preocupar em fazer login em
uma interface separada para fazer tarefas diferentes. Em um minuto podem estar lidando

52
com compromissos para seus clientes e no prximo minuto poderiam estar adicionando
um novo empregado. Eles no podem ser incomodados pulando entre aplicaes
diferentes, e mantendo a interface consistente eles so capazes de se adaptar aplicao
ainda mais rpido.

Edward Knittel, Diretor de Vendas e Marketing , KennelSource

Cdigo captulo 10

Menos Software
Mantenha seu cdigo o mais simples possvel
bastante razovel pensar que um software com o dobro de cdigo seria apenas duas
vezes mais complexo. Mas na verdade, medida que se aumenta a quantidade de
cdigo, a complexidade do software tende a crescer exponencialmente. Cada
pequena adio, cada nova interdependncia, cada nova preferncia amplia o efeito
cascata. Adicione cdigo desenfreadamente sua aplicao, e antes que voc perceba,
voc ter criado uma grande e desgovernada bola de neve.

A melhor maneira de se enfrentar a complexidade com menos cdigo. Menos software

significa menos funcionalidades, menos cdigo, menos desperdcio.

A chave est em repensar qualquer problema difcil que venha a necessitar de uma
grande quantidade de componentes para ser solucionado em um problema mais fcil,
que requeira muito menos. Voc pode acabar no solucionando exatamente o mesmo
problema, mas tudo bem. Resolver 80% do problema original despendendo 20% do
esforo uma vitria e tanto. O problema original raramente to crtico de forma a
realmente merecer cinco vezes mais esforo em sua soluo.

Menos software a melhor maneira para aposentar a sua bola de cristal. Em vez de
tentar prever problemas futuros, lide apenas com os problemas de hoje. Por qu? A
maioria dos medos que voc tem a respeito do futuro raramente tornam-se reais. No
perca seu tempo tentando solucionar estes problemas-fantasma.

Desde o incio, desenvolvemos nossos produtos ao redor do conceito de pouco software.

Sempre que possvel, simplificamos os problemas mais difceis. E descobrimos que a
soluo para problemas mais simples no somente mais fcil de implementar e
suportar, como tambm de entender e usar. tudo parte de uma estratgia para
diferenciar-se dos competidores: em vez de focar-se em produtos que fazem mais,
construimos produtos que fazem menos.

Menos software mais fcil de se gerenciar.

Menos software reduz a quantidade de cdigo e isso significa
menor carga de trabalho de manuteno (e uma equipe mais feliz).
Menos software reduz os custos de mudana, de forma que voc pode adaptar-se
rapidamente. Voc pode mudar deideiasem ter que mudar milhes de linhas de
cdigo.

53
 Menos software resulta em menos bugs.
Menos software significa menos suporte.

A escolha de quais funcionalidades incluir ou omitir tambm tem muito a ver com a
quantidade de software. No tenha medo de dizer no a solicitaes de funcionalidades
difceis de se implementar. A menos que elas sejam absolutamente essenciais,
economize tempo, esforo e muita confuso deixando-as de fora.

V devagar, tambm. Quando surgir uma nova ideia, no tome nenhuma ao por uma
semana, e ao final veja se aideiaainda parece to brilhante. O tempo extra em banho
maria geralmente ajudar seu crebro a pensar em uma soluo mais simples.

Encoraje programadores a pensar em contra-propostas

O que se deseja ouvir : A maneira como voc sugeriu levar 12 horas para ser
implementada. Mas h um jeito de fazer que vai levar s uma hora. No vai fazer x, mas
vai fazer y.. Deixe o software dizer "no".. Encoraje os programadores a lutarem
pelo que eles pensam ser a melhor maneira.

Tambm busque por alternativas a ter que escrever mais software. Seria possvel mudar
um fluxo de telas de modo que elas sugiram uma rota alternativa para os usurios que
no requeira mudanas no modelo do software? Por exemplo, seria possvel sugerir que
as pessoas faam upload de imagens de um tamanho especfico, em vez de ter que
manipular as imagens no lado do servidor?

Para cada nova funcionalidade de sua aplicao, pergunte-se se no existe uma maneira
de se produzir o mesmo resultado e que no requeira tanto software. Escreva apenas o
cdigo que precise, e nada mais. Sua aplicao acabar bem mais magra e saudvel.

NO existe cdigo mais flexvel do que NENHUM cdigo!

O segredo do bom projeto de software no estava em saber o que codificar; estava em

saber o que NO codificar. Estava em saber o que deixar de fora! Estava em perceber
quais os pontos que necessitariam de mais flexibilidade e quais no, e ento deixar
espao para futuras mudanas, em vez de tentar expandir mais e mais o design.

Brad Appleton, engenheiro de software

(de There is No CODE that is more flexible than NO Code!)

Complexidade no aumenta linearmente com o tamanho

A regra mais importante da engenharia de software tambm a menos conhecida: a

complexidade no cresce linearmente com o tamanho Um programa de 2000 linhas
requer mais do dobro do esforo de desenvolvimento que um programa com a metade
do seu tamanho.

The Ganssle Group (de Keep It Small)

Otimize para Felicidade

54
Escolha ferramentas que estimulem e motive o seu time
Um programador feliz um programador produtivo. por isso que ns otimizamos
para felicidade e voc deveria fazer o mesmo. No escolha as ferramentas e prticas
baseado simplesmente no padro do mercado ou mtricas de desempenho. Avalie os
atributos intangiveis: a ferramenta foi criada com paixo, orgulho e dedicao?. Voc
seria feliz trabalhando neste ambiente oito horas por dia?

Isto especialmente importante quando voc estiver escolhendo uma linguagem de

programao. Apesar da percepo do pblico sobre o conterio, elas no so criadas
iguais. Enquanto qualquer linguagem pode produzir qualquer tipo de aplicao, as
melhores para o caso no seriam somente possveis ou aceitveis, elas seriam
prazeirosas e revigorantes. simplesmente tornar os pequenos detalhes do trabalho
dirio mais divertidos.

A felicidade tem um efeito em cascata. Programadores felizes trabalham da maneira

correta. Eles escrevem cdigos simples e de fcil leitura. Eles abordam o problema de
uma maneira elegante, expressiva e de fcil entendimento. Eles se divertem.

Ns encontramos o ecstasy da programao na linguagem Ruby e o passamos adiante

atravs do nosso framework, Rails. Ambos compartilham do mesmo objetivo de
otimizar para humanos e sua felicidade. Ns o aconselhamos a dar uma chance a essa
combinao.

Resumindo, sua equipe necessita trabalhar com ferramentas de que eles gostem. Ns
citamos exemplos no contexto de linguagens de programao, mas o conceito se aplica
aplicaes, plataformas, e praticamente a tudo. Escolha a fuso que deixa as pessoas
excitadas. Voc vai criar mais motivao e excitao e consequentemente um melhor
resultado.

Os tipos de engenheiros que voc quer

O motivo nmero um de eu ter escolhido Ruby on Rails para criar nossa aplicao a
sua elegncia, produtividade e a beleza de sua arquitetura. Ele tem a tendncia de atrair
o tipo de engenheiros que se preocupam com esse tipo de coisa exatamente o tipo de
engenheiros que voc quer no seu time, porque eles criam softwares atrativos, elegantes
e produtivos que voc precisa para ganhar o mercado.

Charles Jolley, Diretor gerencial da Nisus Software (de Signal vs. Noise)

O Cdigo Fala
Oua quando seu cdigo diz "no"
Oua seu cdigo. Ele oferecer sugestes. Ele ir dizer "no". Ele lhe dir onde ficam as
armadilhas. Ele ir sugerir novas maneiras de fazer as coisas. Ele ir ajud-lo a se
manter em um modelo de menos software.

55
Uma nova funcionalidade est requerendo semanas de tempo e milhares de linhas de
cdigo? Isso seu cdigo lhe dizendo que provavemente existe uma maneira melhor.
Existe uma maneira simples de codificar alguma coisa em uma hora em vez de uma
maneira complicada que consumir dez horas? Novamente, esse seu cdigo o guiando.
Oua.

Seu cdigo pode gui-lo a consertos que so baratos e leves. Preste ateno quando um
caminho mais fcil emerge. Claro, a funcionalidade que fcil de fazer pode no ser
exatamente a mesma que voc originalmente tinha em mente, mas e da? Se funciona
bem o suficiente e lhe d mais tempo para trabalhar em outra coisa, um ganhador.

Oua

No se preocupe com o design, se ouvir seu cdigo um bom design vai aparecer ... Oua
as pessoas tcnicas. Se eles esto reclamando sobre a dificuldade de fazer mudanas,
ento leve essas reclamaes a srio e lhes d tempo para consertar as coisas.

Martin Fowler, Cientista Chefe, ThoughtWorks (de Is Design Dead?)

Se Programadores Fossem Pagos para Remover Cdigo ...

Se programadores fossem pagos para remover cdigo do software em vez de escrever

novo cdigo, seria muito melhor.

Nicholas Negroponte, Professor de Tecnologia de Mdia no MIT

(de And, the rest of the (AIGA Conference) story)

Gerencie Dbitos
Pague a seu cdigo e as "contas" de design
Normalmente pensamos em dbito na forma de dinheiro mas ele vem em outras formas
tambm. Voc pode facilmente construir cdigo e dbito de design.

Grude junto alguns cdigos ruins que so funcionais mas ainda assim um pouco
cabeludos e estar construindo dbito. Jogue junto um design que bom o suficiente
mas no realmente bom e estar se endividando novamente.

No tem problema fazer isso de vez em quando. De fato, s vezes uma tcnica
necessria que o ajuda a chegar mais rpido ao esquema Caia-Na-Real-RPIDO. Mas
voc ainda precisa reconhec-lo como dbito e pag-lo em algum ponto limpando o
cdigo cabeludo ou redesenhando aquela pgina mais ou menos.

Da mesma forma que voc deve regularmente colocar de lado uma parte do seu salrio
para impostos, regularmente coloque uma parte do seu tempo para pagar seu cdigo e
dbito de design. Se no fizer isso, apenas estar pagando juros (consertando grudes)
em vez de pagar o montante (e movendo-o adiante).

56
Abra as Portas
Publique dados para o mundo via RSS, APIs, etc.
No tente prender seus usurios. Deixe que eles possam ter acesso a suas informaes
quando quiserem, da forma que preferirem. Para tal, voc precisa deixar de lado
aideiade manter os dados de seus usurios trancados a sete chaves. Em vez disso, deixe
que a informao flua. Garanta o acesso informao atravs de feeds RSS. Oferea
APIs que permitam a terceiros construir aplicaes integradas sua. Tais atitudes
tornaro a vida dos usurios mais conveniente e expandiro as possibilidades do que sua
aplicao capaz de fazer.

No passado, as pessoas acostumaram-se a pensar nos feeds RSS apenas como uma boa
maneira de se agregar contedo de sites de blogs e sites de notcia. Contudo, os feeds
so mais poderosos que isto. Eles tambm podem permitir ao usurio manter-se
atualizado sobre mudanas internas aplicao sem a necessidade de logar-se repetidas
vezes. Atravs do site do Basecamp, por exemplo, o usurio pode cadastrar sua url em
um agregador de RSS e assim receber notificaes de mensagens de projetos, listas de
tarefas e objetivos sem a necessidade de conectar-se constantemente ao site em busca de
informaes atualizadas.

APIs permitem que desenvolvedores construam plugins adicionais sua aplicao, que
geralmente agregam valor ao seu produto. Por exemplo, a API disponibilizada pelo
Backpack foi utilizada pela Chipt Productions na construo de um widget para o Mac
os X. A pequena aplicao permite aos usurios adicionar e editar lembretes, listagens
de items e muito mais a partir de seus desktops. Muitos usurios apontaram o widget
como uma tima ferramenta, e alguns mesmo apontaram-no como um fator decisivo na
escolha da utilizao do Backpack.

Outros bons exemplos de empresas que liberaram dados como uma maneira de
conseguir um efeito bumerangue:

A API do Google Maps permitiu o surgimento de toda sorte de pequenas

aplicaes que recuperam dados de outras fontes (ex.: uma listagem de
apartamentos) e os exibem em um mapa.
Linkrolls oferece aos usurios exibir seus ltimos bookmarks do del.icio.us em
seu prprio site.
O Flickr permite que outros negcios acessem as suas APIs comerciais, de
forma a permitir aos usurios comprar livros de fotos, posters, backups em DVD
e selos. O objetivo manter as portas completamente abertas e permitir o maior
nmero possvel de possibilidades de utilizao de suas fotos, diz Stewart
Butterfield, do Flickr.

Um Widget Faz a Diferena

Quando a 37signals lanou o Backpack, h algum tempo atrs, minha primeira

impresso foi er... bem...

57
Ocorreu mais ou menos na poca em que a Chipt Productions lanava um widget
Backpack para o Sistema Operacional Tiger que parecia interessante demais para
passar despercebido com isso dei uma segunda olhada no Backpack. O resultado?
Uma grande diferena.

Hoje, sempre que uma novaideiasurge, abro o widget, digito e salvo e pronto.
Recebo algum e-mail com algo que devo fazer? Abro o widget, digito e salvo e
pronto. O widget tornou-se um tipo de bloco de notas indispensvel, que instalo em
todo Mac que uso. E por se tratar de uma aplicao totalmente web, no h necessidade
de nenhum tipo de controle de verso ou sincronizaao de dados apenas a fluidez de
digitar-se dados sem ter que se preocupar em saber para onde os dados foram, nem
como acess-los mais tarde.

Todd Dominey, fundador, Dominey Design

(de Trying on Backpack)

Palavras captulo 11

No H Nada de Funcional em uma

Especificao Funcional
No escreva um documento de especificaes
funcionais
Estas plantas baixas de projeto geralmente acabam por descrever algo completamente
diferente do produto final. A vai o motivo:

Especificaes funcionais so fantasias

Especificaes no refletem a realidade. Uma aplicao no real enquanto seus
desenvolvedores no comearem a construo; seus designers comearem a traar a
desenh-la; os usurios comearem a testa-la e experimentar o produto. Especificaes
funcionais so apenas palavras em papel

Especificaes funcionais so apenas uma forma de

acalmar os nimos.
Elas servem para fazer com que todos sintam-se envolvidos e felizes com o projeto e
embora a sensao de segurana seja reconfortante, ela no traz nenhum benefcio ao
desenvolvimento. Estas especificaes nunca tocam nos pontos mais crticos do projeto
ou mesmo avaliam seus custos, fatores que nunca devem ser esquecidos na construo
de uma grande aplicao.

58
Especificaes funcionais apenas levam iluso de um
acordo
O fato de um punhado de pessoas concordarem sobre alguns pargrafos de texto no
implica em dizer que todos chegaram a um entendimento comum: todos podem estar
lendo o mesmo texto, mas chegando a concluses completamente diferentes. Estas
diferenas inevitavelmente aparecem no decorrer do projeto: Espere, no era isso que
eu tinha entendido. Hein? No foi assim que ns descrevemos. Sim, foi isso que
concordamos voc aprovou que fosse desse jeito!. Voc sabe a encrenca que .

Especificaes funcionais foram a tomada das

decises mais importantes justamente quando se tem o
mnimo de informaes sobre o todo.
normal saber-se pouco sobre qualquer coisa antes de comear a construo. Quanto
mais se avana no projeto, quanto mais se usa o produto, mais se entende sobre ele.
neste ponto em que as decises deveriam ser feitas quando se tem mais informao,
no menos.

Especificaes funcionais geram excesso de

funcionalidades
No h impeditivos na fase de especificao. No h custo nenhum em adicionar mais
um tpico a uma lista de requisitos. Voc pode agradar aos crticos mais chatos do
projeto adicionando especificao aquela funcionalidade de estimao que eles tanto
gostariam de ver implementada. E no fim das contas, a equipe acabar desenvolvendo
uma aplicao que satisfar uma lista de requisitos em uma folha de papel no seres
humanos. E assim voc acabar com um site sobrecarregado, com um milho de abas,
menus e opes espalhadas por uma pgina indecifrvel.

Especificaes funcionais no deixaro que voc

evolua, mude ou rearranje
Cada funcionalidade acordada e aprovada. Mesmo que voc perceba durante o
desenvolvimento que esta funcionalidade uma m ideia, no h mais nada que possa
ser feito. Especificaes no ajudaro a lidar com a realidade quando o
desenvolvimento comear, e tudo mudar de uma hora para a outra.

Ento o que deve ser feito em vez de uma especificao funcional? Comece por uma
alternativa mais breve, que possa transformar-se mais rapidamente em algo real.
Escreva uma pgina descrevendo o que a aplicao precisa fazer. Use linguagem
coloquial e faa isso rpido. Se voc precisar de mais de uma pgina para explicar o
conceito, ento ele provavelmente muito complexo. Este processo de especificao
no deve tomar mais que um dia.

Comece ento a construo da interface ela ser o substituto da sua especificao

funcional. Desenhe alguns esboos rpidos em papel, ento comece a transformar o
esboo em cdigo HTML. Diferentemente de pargrafos de texto abertos a

59
interpretao, a interface da aplicao um corpo comum, que tenta representar ao
mximo a verso desejada da aplicao sem interpretaes subjetivas.

A confuso tende a desaparecer quando todos comeam a usar as mesmas telas.

Construa uma interface que permita que todos naveguem, usem e sintam a aplicao
antes mesmo de comear a se preocupar com o cdigo de back-end. Coloque-se na pele
do usurio o mximo possvel.

Esquea as especificaes congeladas e imutveis. Elas foram a tomada de decises

importantes muito cedo no processo. Pule a etapa de especificao funcional e
mantenha o custo das mudanas em baixa e a flexibilidade em alta.

Especificaes inteis

Uma especificao um documento quase que completamente intil. Eu nunca vi

uma especificao detalhada o suficiente para que seja til e precisa ao mesmo tempo.

E eu j vi muito lixo construdo com base em especificaes. Desenvolver com base em

especificaes a pior maneira de se escrever software, pois por definio, trata-se de
programar para satisfazer uma teoria, no a realidade.

Linus Torvalds, Criador do Linux (from: Linux: Linus Sobre Especificaes)

Enfrente os atrasadores de projeto

Eu cheguei concluso de que muitas das pessoas que insistiam em uma lista extensiva
de requisitos antes de comear qualquer design tratavam-se de meros atrasadores
tentando frear o processo (e que geralmente estas pessoas no tinham nada a contribuir
no design, nem qualquerideiainovadora para compartilhar).

Todo nosso melhor trabalho foi feito com alguns conceitos na cabea sobre melhorar o
site, alguns prottipos rpidos (estticos), pequenas alteraes no design e, enfim, com a
construo de um prottipo funcional com dados reais. Aps nos prepararmos com esse
prottipo, geralmente tnhamos um projeto real em curso e um bom resultado.

Mark Gallagher, desenvolvedor de intranets corporativas (de Signal vs. Noise)

No Faa Documentos Mortos

Elimine a papelada desnecessria
Evitar especificaes funcionais um bom comeo, mas no tudo: necessrio evitar
o excesso de papelada em todo o projeto. A menos que um documento v efetivamente
transformar-se em algo real, ele no deve ser escrito.

Construa, no escreva. Se voc precisar explicar alguma coisa, tente construir um

prottipo em vez de redigir um longo documento. Uma interface de verdade ou um

60
prottipo tende a seguir caminho em direo a um produto real. Um punhado de folhas
de papel, por sua vez, somente seguir caminho rumo a uma lixeira.

Se um documento provavelmente nunca evoluir para um design real, no se preocupe

em escrev-lo. Se o intuito de um documento transformar-lo em um modelo, v em
frente.

Documentos que existem separadamente da aplicao so inteis. Eles no levaro a

lugar nenhum. Todos os esforos de projeto devem ser usados na evoluo do produto
real. Se um documento congelado antes de se tornar uma pea real, ele est morto.

Ningum nunca ir l-lo

Eu sequer consigo lembrar quantas especificaes ou documentos de requerimentos de

negcio ficaram de escanteio, juntando poeira enquanto minha equipe de
desenvolvimento codificava, discutia problemas, fazia perguntas e conduzia testes de
usabilidade ao longo de nossos projetos. Tambm j trabalhei com desenvolvedores que
desperdiaram horas escrevendo longos e minuciosos emails ou documentos de padres
de codificao que sempre acabaram no sendo lidos por ningum.

Aplicaes web no avanam graas a um grande punhado de documentos. O

desenvolvimento de software um processo em constante evoluo e que envolve
iteraes e decises rpidas, medida que problemas imprevisveis aparecem pelo
caminho. Nada disso pode ou deveria ser registrado em folhas e folhas de papel.

No desperdie seu tempo escrevendo aquele longo e visionrio documento: ningum

ir l-lo. Console-se com o fato de que, se o seu produto tiver espao o suficiente para
crescer adequadamente, no final ele nem de longe parecer com qualquer coisa que voc
tenha escrito sobre ele.

Gina Trapani, desenvolvedora web e editora do Lifehacker, o guia de produtividade e

software

Me Conte uma Histria Rpida

Escreva histrias, no detalhes
Sempre que faltarem palavras para explicar uma nova funcionalidade ou conceito, deve-
se escrever uma pequena histria sobre a ideia. Sem entrar em detalhes tcnicos ou de
design, a histria deve ser escrita para humanos como que em um dilogo qualquer
com outras pessoas.

A histria to pouco precisa ser um ensaio elaborado. Um punhado de orientaes sobre

o fluxo das coisas geralmente suficiente. Ainda melhor se for possvel contextualizar a
histria com um punhado de projetos de telas.

Ao se expressar novos conceitos atravs de histrias, deve-se pensar na experincia, em

vez de perder-se em detalhes. Focar na estratgia, no na ttica. As tticas aparecero

61
uma vez que a aplicao comece a ser construda. At aqui, tudo que se deseja uma
histria capaz de iniciar uma discusso, e colocar o projeto no trilho certo.

Use Palavras de Verdade

Use texto real em vez de lorem ipsum
O clssico Lorem ipsum dolor um amigo fiel de muitos designers. Textos falsos, de
enchimento, ajudam a ter umaideiade como o design ficar, uma vez finalizado. Mas a
utilizao de textos de enchimento pode ser perigosa, tambm.

O lorem ipsum muda a forma como o texto visualizado no todo. Ela reduz o contedo
textual do site a um mero elemento visual uma forma de texto em vez do que ele
realmente deveria ser: informaes valiosas que devero ser lidas e/ou digitadas. A
utilizao de textos de enchimento acaba por esconder as inevitveis variaes que
aparecero uma vez que informaes reais sejam utilizadas. Ela dificulta a percepo de
como o design realmente se comportar quando dados reais forem digitados. Textos de
enchimento so um abismo entre o design e a realidade.

So precisos dados reais para que se possa definir o tamanho ou forma de certos
campos. So precisos dados reais para perceber como tabelas iro se expandir ou
contrair. So precisos dados reais para visualizar a aplicao.

Palavras relevantes devem ser usadas o mais cedo possvel. Se o site requerer entrada de
dados, dados reais devem ser fornecidos. Mais que isso, os dados devem ser realmente
digitados no somente copiados e colados de outra fonte. Se o sistema solicitar um
nome, utilize um nome real. Se solicitar uma cidade, utilize uma cidade real. Se solicitar
a digitao de uma senha e sua confirmao, digite duas vezes.

Claro que muito mais fcil percorrer todos os formulrios e preencher os campos com
lixo (asdsadklja 123usadfjasld snaxn2q9e7), de forma a percorr-los rapidamente.
Mas estes dados no so reais. No isso que os clientes faro. No sbio testar o
sistema atravs de um atalho, enquanto os usurios sero forados a tomar o caminho
mais longo. Quando apenas se digitam dados falsos com a velocidade de uma
metralhadora, perde-se a percepo de como realmente se preenche tais formulrios.

Fazer como os usurios fariam uma maneira de entend-los melhor. E uma vez que
eles sejam entendidos, uma vez que se sinta o que os usurios sentem, sua equipe
construir uma interface melhor.

Lorem Ipsum Lixum

Quando o design deixa de levar em considerao como o contedo do site deveria ser,
o impacto sobre o resultado final grande. O significado das pginas se perde por ser
apenas texto; o entendimento comprometido por ningum perceber que o tal texto
deve estar ali supostamente para ser lido. Oportunidades so perdidas porque o texto
lorem ipsum usado no lugar de texto real no sugere novas oportunidades ou

62
funcionalidades. E se o texto to desnecessrio e no est ali para ser usado, podemos
ento apenas substitu-lo por um adorvel espao em branco.

Tom Smith, designer e desenvolvedor (de Eu Odeio Lorem Ipsum e Usurios Lorem
Ipsum)

D Personalidade a Seu Produto

Qual o tipo de personalidade do seu produto?
Produtos devem ser pensados como se fossem pessoas. Que tipo de pessoa seu produto
deve ser? Educada? Divertida? Sria? Relaxada? melhor que ela seja lembrada como
uma aplicao confivel ou excessivamente segura? As a know-it-all? Modesta?
Simptica?

Uma vez decididida a personalidade da aplicao, tais caractersticas devem ser sempre
lembradas durante a construo do produto. Elas devem ser usadas para guiar a
construo da interface, a escolha das funcionalidades e at mesmo o texto de copyright.
Sempre que qualquer mudana for feita aplicao, deve-se pensar primeiro se tal
mudana se adequa personalidade da aplicao.

Cada produto tem uma voz e ela fala com os clientes 24 horas por dia.

Precificao e Assinatura captulo 12

Amostra Grtis
D alguma coisa de graa
um mundo barulhento l fora. Para que as pessoas o notem no meio da multido, d
alguma coisa de graa.

Empresas espertas sabem que dar brindes uma excelente maneira de fisgar clientes.
Veja a Apple. Eles oferecem o software iTunes de graa de forma a gerar demanda para
o iPod e a loja de msica iTunes. No mundo offline, as lojas fazem a mesma coisa. A
Starbucks diz que uma nova compra estimulada para cada cinco amostras de bebidas
que eles do aos clientes. Nada mau.

Para ns, Writeboard e Ta-da list so aplicativos completamente grtis que usamos para
colocar as pessoas no caminho para usar nossos outros produtos. Adicionalmente,
sempre oferecemos algum tipo de verso grtis de todos os nossos aplicativos.

Queremos que as pessoas experimentem o produto, a interface, a utilidade do que

construmos. Uma vez fisgados, eles so muito mais propensos a atualizar para um dos

63
planos pagos (que permitem mais projetos ou pginas e d acesso a funcionalidades
adicionais como upload de arquivos e encriptao de dados com SSL).

Pedacinhos

Faa pedacinhos: crie ofertas especializadas, pequenas para que os clientes mordam.
Subdivida pelo menos um produto ou servio em pedacinhos que so baratos, fceis ou
divertidos.

Ben McConnell e Jackie Huba, autores do Church of the Customer Blog

(de What is customer evangelism?)

D Sua Msica de Maior Sucesso

Considere doar uma de suas msicas (por lbum) como download gratuito promocional
para o mundo para ser como um trailer de cinema como o single de sucesso enviado
ao rdio a msica que faz as pessoas quererem comprar sua msica.

No se preocupe com pirataria dessa msica. Deixe as pessoas tocarem, copiarem,

compartilharem. Tenha a confiana que, se o mundo a ouviu, iro pagar por mais.

Derek Sivers, presidente e programador, CD Baby e HostBaby (de Free Promo

Track)

Fcil entrar, fcil sair

Torne assinatura e cancelamento processos indolores
Torne simples o processo de assinar e cancelar o seu servio.

Se eu sou um cliente que quero usar seu aplicativo, espero que seja um processo indolor
e bvio. Providencie um boto de assinatura grande, claro, que pula e coloque-o em
cada pgina do seu website de marketing. Anuncie s pessoas como fcil: Da
assinatura ao login em apenas 1 minuto!

Sempre deve existir uma opo grtis para que os clientes possam experimentar o
aplicativo sem entrar com informaes de carto de crdito. Alguns de nossos
competidores requerem uma ligao de retorno, um compromisso, ou uma senha
especial para poder experimentar seus produtos. Qual o problema disso? Ns
deixamos qualquer um experimentar nossos aplicativos de graa a qualquer hora.

Mantenha o formulrio de assinatura o mais curto possvel. No pergunte coisas que

no precisa e no jogue um longo e assustador questionrio nas pessoas.

Os mesmos princpios permanecem verdadeiros para o processo de cancelamento. No

queremos prender as pessoas dentro de nosso produto. Ao mesmo tempo que
sentimos muito quando as pessoas decidem cancelar suas contas de Basecamp, nunca
fazemos desse processo algo intimidante ou confuso. Cancele minha conta um link

64
to claro quanto o dia na pgina da conta da pessoa. No deve existir nenhum e-mail a
ser enviado, formulrio especial a ser preenchido ou questes a serem respondidas.

E tambm garanta que as pessoas possam levar seus dados se decidirem sair. Ns
garantimos que os clientes possam facilmente exportar todas as mensagens e
comentrios em formato XML a qualquer momento. So seus dados e eles devem poder
fazer com eles o que quiserem.

Isso crucial porque dar s pessoas o controle de suas prprias informaes constri
confiana. Estamos lhes dando uma ponte para suas ilhas de dados. Permitimos que
saiam sem nenhum prejuzo se encontrarem uma oferta melhor. a coisa certa a se
fazer e isso gera boa vontade.

Sair com Facilidade

No segure usurios contra suas vontades. Se querem sair, deixe-os pegar todo o
contedo que criaram enquanto estiveram no seu website e sairem de graa
Temos que deixar as portas abertas e focar em manter nosso cliente alimentado, de
forma que ele queira voltar, em vez de voltar porque est preso.

Charlie O'Donnell, analista, Union Square Ventures

(de 10 Steps to a Hugely Successful Web 2.0 Company)

Coelho Bobinho, Truques so para

Crianas
Evite contratos de longa durao, taxas de assinatura,
etc.
Ningum gosta de contratos de longa durao, taxas de cancelamento ou cobranas para
abertura de conta. Ento, evite tais cobranas. Nosso produto cobrando na forma de
assinatura mensal. No existe contrato de tempo mnimo de utilizao e pode-se
cancelar a assinatura a qualquer momento, sem penalidades. E no existem, nunca,
quaisquer taxas de adeso.

No tente encontrar modos alternativos de conseguir mais dinheiro. Faa por merec-
lo.

Batendo de Leve
Reduza o impacto das ms notcias com avisos prvios
e tratamento privilegiado

65
Voc precisa divulgar uma m notcia aos usurios como um aumento de preos? Faa
o anncio o mais indolor possvel, dando aos usurios um aviso prvio. Considere
tambm a possibilidade de um perodo de bnus, isentando usurios antigos por um
certo perodo de tempo. Estes usurios so seu ganha-po, e seu interesse faz-los
sentirem-se valorizados, no explorados.

Promoo captulo 13

Lanamento de Hollywood
V de Trailer para a Prvia para o Lanamento
Se uma aplicao lanada numa floresta e no h ningum l para us-la, ela faz
barulho? O ponto aqui que se fazemos o lanamento da nossa aplicao sem nenhum
tipo de anncio antecipado, as pessoas no sabero sobre ela.

Para construir euforia e antecipao, v com um lanamento holywoodiano: 1) Trailer,

2) Prvia e 3) Lanamento.

Trailer
Alguns meses antes do tempo, comece soltando dicas. Faa as pessoas saber no que est
trabalhando. Publique um logotipo. Publique sobre o desenvolvimento no seu blog.
Mantenha-se vago mas plante a semente. Alm disso levante um website onde poder
coletar e-mails das pessoas interessadas.

Nesse estgio, devemos comear a seduzir gurus e insiders. Essas so as pessoas que
esto frente. So os formadores de opinio. Apele para suas vaidades e status como
pontos-fora-da-curva. Diga-lhes que esto tendo uma breve prvia exclusiva. Se um site
como Boing Boing, Slashdot ou Digg criam links para sua aplicao, ter um monte de
trfego e seguidores. Mais ainda, seu page rank no Google subir tambm.

Prvia
Algumas semanas antes do lanamento, comece a demonstrar funcionalidades. D
acesso por-trs-das-cmeras s pessoas. Descreva o tema do produto. Para o Basecamp,
publicamos fotos de tela e marcamos os alertas, milestones e outras funcionalidades.

Tambm diga s pessoas sobre as ideias e princpios por trs da aplicao. Para o
Backpack, publicamos nosso manifesto antes do lanamento. Isso levou as pessoas a
pensar e falar sobre a aplicao.

Tambm podemos oferecer algum tipo de ingresso especial para algumas poucas
pessoas para que possam comear a usar a aplicao antes do tempo. Ainda ganhamos o
benefcio de ter pessoas testando como beta enquanto sentem aquele brilho especial que
todos de vanguarda sentem.

66
E novamente, encoraje as pessoas a se cadastrar para termos uma fundao de e-mails a
ser usado no lanamento. Quando lanarmos nossa aplicao, teremos milhares de e-
mails para pingar, o que uma grande ajuda para ganhar trao.

Lanamento
hora do lanamento. Agora as pessoas podem realmente ir ao cinema e ver nossa
aplicao. Envie e-mails para aqueles que se cadastraram. Lance seu site de marketing
completo. Espalhe a palavra tanto quanto possvel. Faa blogs criarem links para voc.
Publique sobre seu progresso: quantas pessoas se cadastraram? Que
atualizaes/refinamentos foram feitas? Entre no embalo e mantenha-se nele.

A Estrada para o Dia do Lanamento

To logo soubemos que Blinksale iria acontecer, comeamos a soltar alguns trailers em
nossa lista de e-mails. Essas eram as pessoas que pediram para receber informao de
ns sobre nosso projeto. Esses so nossos fs, se quiser chamar assim. Se voc j tem
permisso para falar para um grupo de pessoas, esse o melhor lugar para comear.

A segunda coisa que fizemos foi conseguir permisso para falar a mais pessoas sobre
nosso produto. Umas seis semanas antes do lanamento do Blinksale pusemos uma
pgina de trailer em nosso site que proclamava a chegada de uma maneira mais fcil de
enviar faturas online. A pgina dava informao apenas suficiente para construir
excitao e suspense, sem entregar detalhes sensveis que precisavam se manter
confidenciais. Prominentemente mostrado na pgina estava um formulrio de cadastro
para um newsletter, pedindo no mais do que um e-mail (mantenha-se simples) para que
os interessados pudessem ser notificados quando o produto fosse lanado.

Espalhamos a palavra para cerca de uma dzia de amigos e colegas que achamos que se
interessaram pelo produto e eles comearam a espalhar a palavra sobre a pgina de
trailer atravs de seus blogs e websites. Dentro de alguns dias, tivemos milhares em
nossa lista de e-mails. Essas eram pessoas extremamente importantes pessoas que
estavam pedindo para saber mais sobre nosso produto e que queriam saber quando
lanaramos.

Finalmente, cerca de duas semanas antes do lanamento, convidamos vrios amigos,

colegas e gurus da indstria para nos ajudar nos testes beta do Blinksale. Isso nos
permitiu colocar o produto na frente de pessoas que sentimos que poderiam se
beneficiar dele que poderiam nos ajudar a espalhar a palavra sobre o produto quando
lanssemos. importante notar que no foramos ningum a escrever sobre o produto.
Simplesmente queramos que fosse visto e que falassem sobre ele quando fosse lanado.
No fim, se for construir euforia dessa maneira, melhor ter certeza que seu produto faz
o que diz. Caso contrrio, como nuvens sem chuva.

Quando o dia do lanamento chegou, enviamos e-mails para nossa lista, notificamos
nossos amigos dos blogs e encorajamos o pessoal do teste beta a falar o que realmente
acharam. E para nossa grande alegria, o esforo pagou grandes dividendos. Logo depois
do lanamento dezenas de milhares visitaram nosso site e milhares deles se cadastraram
para usar o produto.

Josh Williams, fundador, Blinksale

67
Um Poderoso Site Promocional
V do Trailer para a Prvia para o Lanamento
A melhor ferramenta promocional um grande produto. A palavra vai se espalhar se
tivermos uma aplicao que as pessoas acham realmente til.

Ainda assim, precisamos de um bom site promocional tambm. O que devemos incluir
nesse site? Algumas ideias:

Apresentao: Explique sobre a aplicao e seus benefcios.

Turismo: Guie as pessoas pelas vrias funcionalidades
Fotos de tela e vdeos: Mostre s pessoas como sua aplicao realmente se
parece e como us-la.
Manifesto: Explique a filosofia e ideias por trs dela.
Estudos de Caso: D exemplos reais que mostram o que possvel.
Euforia: Frases testimoniais de clientes, revises, imprensa, etc.
Frum: Oferea um local para membros da comunidades se ajudarem uns aos
outros.
Precificao e Assinatura: Leve as pessoas aplicao o mais rpido
possvel.
Weblog: Blogs mantm seu site atualizado com notcias, dicas, etc.

Cavalgue pela Onda dos Blogs

Blogar pode ser mais efetivo do que propaganda (e
muito mais barato)
Propaganda caro. E calcular a eficcia de vrios tipos pode acabar sendo ainda mais
caro do que a propaganda em si. Quando no tiver o tempo ou o dinheiro para ir pela
rota tradicional de propaganda, em vez disso considere a promoo-via-blog.

Comece criando um blog que no apenas fale sobre seu produto mas oferece bons
conselhos, dicas, truques, links, etc. Nosso blog Signal vs. Noise recebe milhares de
leitores nicos por semana graas aos pedaos que ajudam, informam e so
interessantes e s anedotas que publicamos quase diariamente.

Ento, quando chegou a hora de promover nosso primeiro produto, Basecamp,

comeamos l. Liberamos a palavra sobre o SvN e ela comeou a se espalhar. Pessoas
como Jason Kottke, os BoingBoingers, Jim Coudal e uma variedade de pessoas com
blogs populares ajudaram a crescer a visibilidade e as coisas fluram.

Ta-da Lists outro grande exemplo do poder do marketing baseado em blogs.

Lanamos Ta-da com uma nica publicao no Signal vs. Noise e algumas semanas

68
depois ela foi mencionada em mais de 200 blogs e mais de 12 mil pessoas se
cadastraram para suas prprias contas Ta-da. Palavra sobre Backpack se espalhou ainda
mais rpido. Dentro de 24 horas do lanamento, mais de 10 mil haviam se cadastrado.

Solicite Antecipadamente
Consiga euforia antecipada e cadastros acontecendo o
mais rpidos possvel
J falamos sobre isso mas vale a pena repetir: consiga algum tipo de site no ar e comece
a coletar e-mails o mais depressa quanto for possvel. Pegue seu nome de domnio e
coloque um logotipo e talvez uma sentena ou duas que descreva, ou pelo menos d
dicas sobre o que sua aplicao far. Ento deixe as pessoas dar seus endereos de e-
mail. Agora voc est no caminho de ter uma fundao de pessoas prontas e esperando
para serem notificadas no seu lanamento.

Promova Atravs da Educao

Compartilhe seu conhecimento com o mundo
Quando um professor aparece como competidor no programa americano de perguntas e
respostas, Jeopardy, o apresentador Alex Trebek comenta que uma nobre profisso.
Ele est certo. Existe definitivamente alguma coisa maravilhosa e recompensadora
sobre dividir seu conhecimento com os outros. E quando o assunto que est
ensinando sua aplicao, ela serve um duplo propsito: Voc pode dar alguma
coisa de volta comunidade que o suporta, e marcar uma boa exposio
promocional ao mesmo tempo.

Como uma tcnica de promoo, educao um jeito sutil de ter seu nome e o nome
de seu produto na frente de mais pessoas. E em vez de uma aproximao dura de
vendas do tipo compre este produto, voc est conseguindo ateno fornecendo um
servio de valor. Isso cria euforia positiva que tcnicas tradicionais de marketing no
conseguem igualar. Pessoas que voc educa se tornaro seus evangelistas.

Educao pode vir de diversas formas. Publique dicas e truques no seu site que as
pessoas iro querer compartilhar com os outros. Fale em conferncias e fique at depois
para se encontrar e agradecer os participantes. Conduza sesses prticas de
demonstrao para que fs curiosos possam aprender mais e falar com voc ao vivo. D
entrevistas para publicaes. Escreva artigos que compartilhem informaes teis. E
escreva livros. ;)

Um exemplo de nossa prpria histria a Tcnica do Amarelo que Desvanesce, um

mtodo que inventamos para sutilmente iluminar uma rea que recentemente mudamos

69
em nossa pgina. Escrevemos uma publicao sobre isso na Signal vs. Noise. Essa
publicao circulou e trouxe milhares e milhares de visitas pgina (at hoje est
fazendo um grande trfego).

A publicao funcionou tanto no nvel educacional quanto promocional. Uma lio foi
aprendida e muitas pessoas que nunca saberiam sobre nossos produtos foram expostos a
eles. Outro exemplo: durante nosso desenvolvimento de Ruby on Rails, decidimos
tornar a infra-estrutura como cdigo aberto. Acabou sendo um movimento sbio.
Demos alguma coisa de volta comunidade, construmos boa vontade, ganhamos
reconhecimento para nossa equipe, recebemos respostas teis e comeamos a receber
correes e contribuies de programadores por todo o mundo.

Ensinar tem tudo a ver com bom karma. Pagamos antecipadamente. Ajudamos os
outros. Ganhamos alguma promoo saudvel. E podemos at mesmo nos sentir mais
nobres. Portanto, o que voc sabe que o mundo gostaria de ouvir?

Pague Antecipadamente

A seo de artigos e dicas em nosso blog uma das mais populares de nosso site. Passar
nosso conhecimento sobre marketing por e-mail garante que nossos clientes tirem o
mximo de nosso software. Se eles podem fornecer um servio melhor a seus clientes,
mais provvel que tenham mais negcios, que por sua vez cria mais negcios para ns
todos ganham.

Dividir gratuitamente nosso conhecimento tambm ajuda a nos posicionar como

especialistas na indstria e refora nossos relacionamentos com os clientes atuais. Eles
sabem que nos importamos sobre qualidade do nosso trabalho. Finalmente, recebemos
montanhas de trfego direcionado a partir de sites de pesquisa e bloggers que dividem
nossos artigos com seus leitores. Essas so pessoas que nunca teriam ouvido falar de
nosso software se no tivssesmos escrito esse artigo.

David Greiner, fundador, Campaign Monitor

Comida-Funcionalidade
Eles esto famintos por isso ento sirva-os
Funcionalidades novas ou interessantes so uma grande maneira de gerar euforia para
sua aplicao. Grupos de interesse especiais amam mastigar comida de
funcionalidade e cuspir de volta comunidade. Tudo bem, essa foi uma analogia no
muito boa mas voc entendeu o ponto.

Por exemplo, usando Ruby on Rails, uma nova plataforma de desenvolvimento,

geramos uma tonelada de ateno para o Basecamp dentro da comunidade de
desenvolvedores.

Os elementos Ajax que usamos em nossa aplicao recebeu montanhas de euforia e at

mesmo levou a revista Business 2.0 a nomear a 37signals um competidor chave em
Ajax junto com grandes nomes como Google, Yahoo, Microsoft e Amazon.

70
Outro exemplo: Bloggers tomaram nota do suporte RSS do Basecamp j que foi um dos
primeiros exemplos de negcios com RSS.

Integrao com iCal, uma funcionalidade menor primeira vista, nos levou s notcias
em uma tonelada de sites relacionados a Mac, que caso contrrio provavelmente nunca
teriam mencionado nossa aplicao.

Equipes pequenas tem uma perna maior na integrao de novas ideias com software.
Enquanto grandes empresas precisam lidar com afunilamentos de burocracia, podemos
rapidamente implementar novas ideias e ganhar ateno por us-las.

Cavalgar junto com as tecnologias mais recentes e que mais fazem barulho um jeito
efetivo e barato de construir euforia. Dito isso, no v adicionando a mais recente e
obscura tecnologia apenas para ganhar mais ateno. Mas se estiver usando alguma
coisa nova e merecedora de ateno, v em frente e anuncie isso para grupos de
interesses especiais.

Monitore Seus Logs

Estude seus logs para monitorar a euforia
Voc precisa saber quem est falando sobre voc. Cheque seus logs e encontre de onde
est vindo a euforia. Quem est com links para voc? Quem est falando mal de voc?
Que blogs listados no Technorati, Blogdex, Feedster, Del.icio.us and Daypop esto
quentes na sua trilha?

Descubra e ento faa sua presena ser sentida. Deixe comentrios nesses blogs.
Agradea as pessoas por publicarem links. Pergunte se eles querem ser adicionados
sua lista avanada especial para que estejam entre os primeiros a saber sobre
lanamentos futuros, atualizaes, etc. Colete elogios e crie uma pgina de euforia no
seu site. Testemunhos so uma grande maneira de promover sua aplicao uma vez que
elogios dos outros mais confivel para a maioria das pessoas.

Se os comentrios so negativos, ainda assim preste ateno. Mostre que est ouvindo.
Responda s crticas com reflexo. Algo do tipo: Agradecemos as opinies mas
fizemos dessa forma porque .. ou Voc levantou um ponto importante e estamos
trabalhando nisso. Voc ir amaciar a crtica e colocar um rosto humano em seu
produto. incrvel como um comentrio bem refletido em um blog pode dissolver
pessoas negativas e mesmo transformar quem reclamava em evangelistas.

Vendas Internas Pr-Ativas

71
Promova oportunidades de atualizao dentro de sua
aplicao
Todo mundo sabe ser agudo no site de marketing. Mas as vendas no devem parar l. Se
tiver um plano de preos por nveis (ou uma verso livre de sua aplicao), no se
esquea de chamar para oportunidades de atualizao de dentro do produto.

Diga as pessoas que voc remover as barreiras se atualizarem. Por exemplo, no

Basecampo no se pode enviar arquivos se tiver uma conta grtis. Quando algum tentar
enviar um arquivo, no simplesmente negamos. Explicamos porque o envio de arquivos
no est disponvel e os encorajamos a atualizar para uma verso paga alm de explicar
porque essa uma boa ideia. A mesma aproximao usada para encorajar clientes j
existentes a atualizar para uma conta de nvel maior quando chegam ao mximo de seu
plano atual.

Clientes existentes so suas melhores apostas de vendas. No se sinta envergonhado em

tentar repetir negcios com pessoas que j conhecem e usam seus produtos.

Nome-Gancho
D um nome sua aplicao que seja fcil de lembrar
Um grande erro que muitas pessoas fazem pensar que o nome de sua aplicao precisa
ser ultra-descritiva. No se preocupe em escolher um nome que vividamente descreva o
propsito de sua ferramenta; isso normalmente leva apenas a um nome genrico e
esquecvel. Basecamp um nome melhor do que algo como Centro de Gerenciamento
de Projetos ou ProjectExpress. Writeboard melhor do que CollaborEdit.

Alm disso, no foque muito em grupos ou comits para o processo de nomeao.

Escolha um nome curto, que pegue, seja memorvel e ento v com ele.

E no se preocupe se no conseguir o nome de domnio exato que quer. Voc sempre

pode ser criativo e chegar perto com um pouco mais de letras (ex. backpackit.com ou
campfirenow.com).

Fcil o Melhor

Ser que a indstria de tecnologia no percebe que pensar em nomes que peguem e que
sejam auto-explicativos os beneficiariam da mesma maneira em ltima instncia? Eles
venderiam mais do que quer que seja, porque no assustariam os consumidores que
pensam que esto sendo mantidos fora do club high-tech por um punhado de
engenheiros arrogantes. A tecnologia avanaria mais rpido tambm. O novo produto
seria mais fcil de descrever, mais fcil de usar e mais fcil de comprar o que, para as
empresas, significa mais fcil de vender.

David Pogue, colunista, New York Times (de O que h no nome de um produto?)

72
Suporte captulo 14

Sinta a Dor
Derrube as paredes entre suporte e desenvolvimento
No negcio de restaurantes, existe uma enorme diferena entre aqueles que trabalham
na cozinha daqueles que esto na linha de frente lidando com clientes. importante
para ambos os lados entender e simpatizar com o outro. por isso que escolas de
culinria e restaurantes normalmente tero chefs trabalhando como garons para que a
equipe da cozinha possa interagir com clientes e ver como realmente estar na linha de
frente.

Muitas empresas desenvolvedoras de software tem uma diviso similar. Designers e

programadores trabalham na cozinha enquanto o suporte lida com clientes.
Infelizmente, isso significa que chefs de software nunca ouvem o que o cliente
realmente est dizendo. Isso problemtico porque ouvir clientes a melhor maneira de
se ligar nas partes fortes e fracas do seu produto.

A soluo? Evite construir paredes entre seus clientes e a equipe de

desenvolvimento/design. No terceirize o suporte a seus clientes. Faa voc mesmo o
suporte. Voc e sua equipe inteira, devem saber o que seu cliente est dizendo. Quando
seu cliente est incomodado, voc precisa saber disso. Voc pecisa ouvir as
reclamaes. Voc precisa ficar incomodado tambm.

Na 37signals, todos os e-mails de suporte so respondidos pessoalmente pelo pessoal

que realmente construiu o produto. Por que? Primeiro, isso fornece melhor suporte aos
clientes. Eles esto recebendo uma resposta diretamente do crebro de algum que
construiu a aplicao. Alm disso, isso nos mantm em contato com a pessoa que usa
nossos produtos e com os problemas que esto encontrando. Quando esto frustrados,
ns ficamos frustrados. Podemos dizer sinceramente que eu sinto sua dor.

Pode ser tentador se apoiar em anlises estatsticas para revelar seus pontos
problemticos. Mas estatsticas no so como vozes reais. Voc precisa eliminar a maior
quantidade possvel de atravessadores entre voc e as vozes reais de seus clientes.

As linhas de frente so onde a ao est. V at l. Faa seus chefs trabalharem como

garons. Leia e-mails de clientes, oua suas frustraes, escute suas sugestes e aprenda
com elas.

Corte fora os intermedirios

Quase todo desenvolvimento do Campaign Monitor, suporte e marketing so feitos por

duas pessoas. Mesmo que fssemos forados a expandir a equipe, nunca separaramos a
equipe suporte do time de desenvolvimento. Quando respondemos pessoalmente cada
requisio, nos foramos a nos colocar no lugar de nossos clientes e vemos as coisas de
sua perspectiva.

73
 importante entender porque seus clientes precisam de alguma coisa, no apenas o que
eles precisam. Esse contexto normalmente tem um impacto direto em como desenhamos
alguma coisa. Corte fora os intermedirios. muito mais fcil dar a seus clientes o que
querem quando possvel ouv-los diretamente.

Discuti essa configurao com muitas pessoas e a primeira resposta normalmente

voc no deveria contratar um estagirio para lidar com seu suporte? Ponha-se no
lugar de seu cliente. Se quiser um bife cozinhado do seu jeito, voc preferiria falar com
o motoboy ou o chef que ir cozinh-lo?

David Greiner, fundador, Campaign Monitor

Treinamento Zero
Use ajuda em contexto e FAQs para que seu produto
no precise de um manual ou treinamento
Voc no precisa de um manual para usar o Yahoo! ou Google ou Amazon. Ento por
que voc no pode construir um produto que no requer manual? Se esforce para
construir uma ferramenta que requer treinamento zero.

Como fazer isso? Bem, como mencionamos antes, voc comea mantendo tudo simples.
Quanto menos complexa for sua aplicao, menos precisar ajudar as pessoas sem
necessidade. Depois disso, uma grande maneira de suporte pr-ativo usando ajuda em
contexto e FAQs em potenciais pontos de confuso.

Por exemplo, oferecemos suporte pr-ativo na tela que permite as pessoas a fazer
upload de seus logotipos ao Basecamp. Algumas pessoas experimentaram um problema
onde continuavam vendo um logotipo antigo por causa do cache do browser. Ento,
prxima rea de envie seu logotipo, adicionamos um link a um FAQ que instrua os
clientes a forar um recarregamento de seus browsers para ver o novo logotipo. Antes
de fazermos isso recebamos 5 e-mails por dia sobre esse problema. Agora, no
recebemos nenhum.

Resposta Rpida
Tempo rpido de atendimento em consultas de suporte
devem ser prioridade mxima
Os clientes se alegram quando voc responde suas questes rapidamente. Eles esto to
acostumados a respostas enlatadas que aparecem dias depois (se muito), que voc pode
realmente se diferenciar dos concorrentes oferecendo uma resposta bem pensada,
imediatamente. Durante o horrio comercial, respondemos 90% de nossos e-mails de

74
requisio de suporte dentro de 90 minutos e normalmente dentro de meia hora. E as
pessoas amam isso.

Mesmo que no tenha uma resposta perfeita, diga alguma coisa. Voc pode comprar boa
vontade com uma resposta entregue rapidamente de forma aberta, honesta. Se algum
est reclamando sobre um problema que no pode ser consertado imediatamente, diga
algo como ouvimos o que est dizendo e estaremos trabalhando nisso no futuro.
uma grande maneira de diluir uma situao potencialmente negativa.

Clientes gostam de coisas diretas e normalmente mudam de irritados para educados se

responder rapidamente e de maneira direta.

Um Exrcito de Muitos

Como pode uma equipe pequena de apenas trs desenvolvedores criar um produto
inovador e competir com sucesso com os caras grandes? A resposta alistar um
numeroso exrcito.

Lembre-se no primeiro dia que seus clientes so seu patrimnio mais importante e que
so absolutamente vitais para o sucesso de longo prazo; portanto trate sua comunidade
de usurios como a realeza. A maneira de competir com os caras grandes comeando
pequeno e prestando ateno a cada um de seus clientes.

seu cliente o primeiro que ir alert-lo de bugs, o primeiro que ir alert-lo de

necessidades que no foram cumpridas e so seus primeiros clientes que carregaro a
bandeira e espalharo sua mensagem.

Isso no significa que seu produto tenha que ser perfeito quando for lanado. Muito pelo
contrrio, lance cedo e freqentemente. Entretanto, quando seus clientes encontrarem
bugs, garanta o envio de uma resposta rpida agradecendo pela sua informao.

Os clientes no esperam que seu produto seja perfeito e no esperam que todas as suas
funcionalidades sero implementadas. Entretanto, esperam que esteja ouvindo e
mostrando que se importa. Essa uma rea onde a maioria da grandes empresas mostra
um grande descaso, portanto desenvolva um senso de comunidade cedo.

Na Blinklist, cada um dos e-mails de cliente respondido, normalmente dentro da

primeira hora (a menos que estejamos dormindo). Tambm temos um frum online e
garantimos que cada postagem e comentrio seja entendido.

Igualmente importante, todos os nossos desenvolvedores recebem o feedback dos

clientes e so participantes ativos nos frums de discusso online. Dessa maneira
estamos, lentamente mas, certamente construindo uma comunidade ativa e leal na
BlinkList.

Michael Reining, co-fundador, MindValley & Blinklist

Amor spero

75
Esteja preparado para dizer no a seus clientes
Quando falamos de requisio de funcionalidades, o cliente nem sempre est certo. Se
adicionssemos cada uma das coisas que nossos clientes pediram, ningum iria querer
nossos produtos.

Se fssemos obedecer cada choro de nossos clientes, o Basecamp teria: gerenciamento

de tempo completo, cobrana completa, cronograma de reunies completo, sistema de
calendrio completo, sistema de dependncia de tarefas completo, chats via mensagens
instantneas completo, funcionalidade de wiki completo, e tudo-mais-que-puder-
imaginar completo.

Ainda assim, a requisio nmero 1 que recebemos nas pesquisas com os clientes
manter o Basecamp simples

Aqui vai outro exemplo: Apesar de algumas reclamaes, decidimos no suportar o

Internet Explorer 5 (IE5) em nossos produtos. Isso era 7% do mercado que estvamos
endereando. Mas decidimos que era mais importante nos preocupar com os outros
93%. Consertar bugs e testar para IE5 simplesmente no valia a pena. Em vez disso
fizemos um produto melhor para todo o resto.

Como uma empresa de desenvolvimento de software, voc precisa agir como um filtro.
Nem tudo que todo mundo sugere a resposta correta. Consideramos todas as
requisies mas o cliente nem sempre est certo. Haver tempos em que voc precisar
simplesmente deixar algum irritado. Cest la vie.

Relacionado a isso, crtico que voc, enquanto empresa de desenvolvimento, ame seu
produto. E voc no ama seu produto se estiver cheio de um monte de coisas com as
quais no concorda. Essa outra justificativa para vetar requisies de clientes que no
acredita que sejam necessrias.

Em Frum Afinado
Use frums ou chats para deixar os clientes se
ajudarem
Frum e chats de grupo baseados na web so uma grande maneira de deixar clientes
fazerem perguntar e ajudar uns aos outros. Eliminando o intermedirio esse voc
voc fornece uma linha aberta de comunicao e economiza seu tempo no processo.

Em nossos fruns de produtos, os clientes publicam dicas e truques, requisies de

funcionalidades, histrias e mais coisas. Ns aparecemos de tempos em tempos para
oferecer assistncia, mas os fruns so principalmente um lugar para a comunidade se
ajudar e compartilhar experincias com o produto.

Voc ficar surpreso com quantas pessoas querem se ajudar.

76
Publique suas burradas
Coloque as ms notcias l fora e fora do caminho
Se alguma coisa vai errado, diga s pessoas. Mesmo que elas nem tenham visto.

Por exemplo, Basecamp ficou fora do ar uma vez por algumas horas no meio da noite.
99% de nossos clientes nunca saberiam, mas ainda assim publicamos uma notificao
de sada do ar inesperada no nosso blog Everything Basecamp. Achamos que nossos
clientes mereciam saber.

Aqui vai uma amostra do que publicamos quando alguma coisa vai errado: Nos
desculpamos pela sada do ar nessa manh tivemos problemas de banco de dados que
causaram grandes lentides e sadas do ar para algumas pessoas. Consertamos o
problema e estamos tomando precaues para garantir que isso no acontea novamente
Obrigado pela sua pacincia e, mais uma vez, nos desculpem pela sada do ar.

Seja to aberto e transparente quanto for possvel. No mantenha segredos ou se

esconda. Um cliente informado seu melhor cliente. Mais do que isso, voc perceber
que a maioria dos seus deslizes nem so to ruins assim, na interpretao de seus
clientes. Eles normalmente esto felizes em lhe dar um pouco de respiro enquanto
souberem que est sendo honesto com eles.

Uma observao sobre entregar notcias, ruins ou boas: quando notcias ruins chegam,
abra tudo de uma vez. Boas notcias, por outro lado, devem ser desenroladas aos
poucos. Se puder prolongar as boas vibraes, faa isso.

Seja gil, Direto e Honesto

Pode soar estranho, mas o cenrio de melhor caso quando a prpria empresa relata as
ms notcias. a pr-atividade que previne sua empresa de ser colocada em uma
posio fraca e defensiva.

Greg Sherwin, Vice Presidente de Tecnologia de Aplicao, CNET, e Emily Avila,

Diretora, Calypso Communications (de A Primer for Crisis PR)

Ps-Lanamento captulo 15

Um Ms para melhorias
Lance uma grande atualizao 30 dias aps o
lanamento

77
Uma atualizao rpida mostra embalo. Mostra que estamos ouvindo. Mostra que temos
mais cartas na manga. Nos d uma segunda onda de burburinho. Reafirma os bons
sentimentos do comeo. Nos d alguma coisa sobre o que falar e para que os outros
possam publicar nos blogs.

Saber que uma rpida atualizao est chegando tambm nos faz focar nos componentes
mais cruciais de antes do lanamento. Em vez de tentar espremer mais algumas coisas,
podemos comear aperfeioando apenas o conjunto principal de funcionalidades. Ento
podemos lanar o produto no mundo real. Uma vez l fora podemos comear a receber
opinies de volta dos clientes e saberemos que reas precisam de mais ateno.

Esse estilo de um-passo-de-cada-vez funcionou bem para o Backpack. Lanamos o

produto bsico primeiro e ento, algumas semanas depois, adicionamos funcionalidades
como Backpack Mobile para computadores portteis e tags uma vez que essas coisas
eram o que os clientes nos disseram que mais queriam.

Mantenha os Posts Chegando

Mostre que seu produto est vivo mantendo um blog
operacional do desenvolvimento do produto aps o
lanamento
No pare de blogar depois de lanar. Mostre que seu produto uma criatura viva
mantendo um blog dedicado e atualizado freqentemente (pelo menos uma vez por
semana, e com mais freqncia se puder).

Coisas a incluir:

Faq (Perguntas e Respostas Freqentes)

How-tos (Instrues passo-a-passo)
Dicas & Truques
Novas Funcionalidades, atualizaes e correes
Burburinho/Imprensa

Um blog no mostra apenas que seu aplicativo est vivo, mas faz sua empresa parecer
mais humana. Novamente, no tenha medo de manter o tom da conversa amigvel e
pessoal. s vezes, equipes pequenas sentem que precisam soar grandes e ultra-
profissionais o tempo todo. quase como uma verso de negcios do Complexo de
Napoleo. No sue a camisa soando pequeno. Deleite-se com o fato de conseguir
conversar com os clientes como amigos.

Est Vivo

Um blog com atualizaes frequentes sobre um produto o melhor indicador de que

essa aplicao web est com desenvolvimento ativo, um produto adorado e que existe
uma luz acesa em casa. Um blog abandonado de um produto um sinal de um produto
abandonado e diz que as pessoas responsveis esto dormindo no ponto.

78
Mantenha as conversas andando com seus usurios no blog de seu produto e seja
transparente e generoso com as informaes que compartilha. Deixe a filosofia de sua
empresa brilhar. Link e discuta abertamente sobre concorrentes. D dicas de
funcionalidades chegando e mantenha os comentrios abertos para opinies de retorno.

Um produto vivo uma coisa que fala e escuta seus usurios. Um blog frequentemente
atualizado sobre um produto promove transparncia, um senso de comunidade e
lealdade com a marca. Publicidade extra e de graa so bnus.

Como editora da Lifehacker, eu vasculho constantemente os blogs de produtos que amo

como os blogs de produtos do Google, Flickr, Yahoo, Del.icio.us e 37signals. Eu sou
muito mais propensa a mencion-los do que aplicaes web que apenas enviam
propaganda de imprensa unidirecional do nada e no mantm uma conversa aberta com
seus usurios e fs.

Gina Trapani, desenvolvedora web e editora da Lifehacker, o guia de produtividade e

software

Melhor, no Beta
No use beta como uma desculpa
Ultimamente parece que tudo est em um estgio beta permanente. Isso um
escapismo. Um interminvel estgio beta indica aos clientes que no estamos realmente
comprometidos a liberar um produto finalizado. Isso diz, use, mas se no estiver
perfeito, no nossa culpa.

Beta repassa a conta ao cliente. Se no estamos confiantes o suficiente sobre nosso

lanamento ento como podemos esperar que o pblico esteja? Tudo bem com betas
privados. Betas pblicos so grandes bobagens. Se no est bom o suficiente para o
consumo pblico ento no o d ao pblico para consum-lo.

No espere seu produto atingir a perfeio. Isso no vai acontecer. Assuma

responsabilidade sobre o que est lanando. Coloque para fora e chame de lanamento.
Do contrrio, est apenas dando desculpas.

Beta no tem Sentido

Culpe o Google, e outros, por causar problemas como esse. Agora, usurios foram
treinados por um monte de desenvolvedores a achar que beta realmente no significa
nada.

Mary Hodder, arquiteta de informao e designer de interao (de The Definition of

Beta)

Todo o Tempo

Sou apenas eu ou estamos todos em beta, o tempo todo?

79
Jim Coudal, fundador, Coudal Partners

Bugs: cada caso cada caso

Priorize seus bugs (e at mesmo ignore alguns deles)
S porque descobrimos um bug em nosso produto no significa que hora de entrar em
pnico. Todo software tem bugs apenas um fato da vida.

No precisamos corrigir cada bug instantaneamente. A maioria dos bugs incmoda,

no destrutiva. Incmodos podem ser tolerados um pouco. Bugs que resultam em erros
que no parecem certos ou outras pequenas indicaes podem ser colocadas de lado
de maneira segura por enquanto. Se um bug destri seu banco de dados, no entanto,
obviamente precisamos corrig-lo imediatamente.

Priorize seus bugs. Quantas pessoas so afetadas? Quo ruim o problema? Esse bug
merece ateno imediata ou pode esperar? O que podemos fazer agora mesmo que ter
o maior impacto para o maior nmero de pessoas? Algumas vezes adicionar uma nova
funcionalidade pode ser mais importante para seu aplicativo do que corrigir um bug
existente.

Finalmente, no crie uma cultura de medo ao redor de bugs. Bugs acontecem. No fique
constantemente procurando algum para culpar. A ltima coisa que queremos um
ambiente onde bugs so varridos para baixo do tapete em vez de discutidos abertamente.

E lembre-se do que dissemos antes sobre a importncia da honestidade: se clientes

reclamam sobre um bug, seja direto com eles. Diga-lhes que notaram o assunto e esto
lidando com ele. Se no forem resolv-lo imediatamente, diga porque e explique que
est focando em reas do produto que afetam um nmero grande de pessoas.
Honestidade a melhor poltica.

Cavalgue para Fora da Tempestade

Espere at que as reaes impulsivas causadas por
mudanas cessem antes de tomar uma atitude
Quando balanamos o barco, haver ondas. Depois de apresentar novas funcionalidades,
mudar a poltica ou remover alguma coisa, reaes impulsivas, s vezes negativas, vo
transbordar.

Resista vontade de entrar em pnico ou mudar rapidamente as coisas em resposta.

Paixes se acendem no comeo. Mas se cavalgarmos para fora desse perodo inicial de
24 a 48 horas, as coisas provavelmente vo se resolver sozinhas. A maioria das pessoas
respondem antes de realmente ir fundo e usar seja l o que foi adicionado (ou se

80
acostumarem com o que foi retirado). Ento sente-se, absorva tudo e no faa nenhum
movimento at que algum tempo tenha se passado. A sim voc ser capaz de oferecer
uma resposta mais adequada.

Tambm se lembre que reaes negativas so quase sempre mais altas e mais passionais
do que as positivas. De fato, voc pode acabar ouvindo somente vozes negativas quando
a maioria da sua base de usurios est feliz com a mudana. Garanta que no estar
dando um passo para trs toa em uma deciso necessria, mas controversa.

Fique Esperto com os Vizinhos

Assine feeds de notcias sobre seus concorrentes
Assine feeds de notcias (news feeds) sobre ambos seu produto e de seus concorrentes (
sempre sbio conhecer os caminhos de seus inimigos). Use servios como PubSub,
Technorati, Feedster e outros para se manter atualizado (para palavras-chave, use nomes
de empresas e produtos). Com RSS, essa informao em constantes mudanas ser
entregue diretamente a voc, e assim estar sempre preparado.

Cuidado com o Monstro da Gordura

Mais maduro no precisa significar mais complicado
Da forma como as coisas progridem, no tenha medo de resistir gordura. A tentao
ser para aumentar. Mas no precisa ser desse jeito. S porque alguma coisa fica velha e
mais madura, no precisa significar que tem que ficar mais complicada.

No precisamos nos tornar 'canetas de outro planeta que escrevem de ponta-cabea'.

Algumas vezes est timo ser apenas um lpis. No precisamos ser canivetes suos.
Podemos apenas ser uma chave-de-fenda. No precisamos construir um relgio de
mergulho que suporta at 5 mil metros se seus clientes so amantes da terra que apenas
querem saber que horas so.

No infle to somente para inflar. assim que aplicativos ganham gordura.

Novo nem sempre significa melhorado. Algumas vezes existe um ponto onde devemos
apenas deixar o aplicativo ser como .

Esse um dos benefcios-chave de construir software baseado em web em vez de

software tradicional de desktop. Produtores de software de desktop como Adobe, Intuit
e Microsoft precisam lhe vender novas verses todo ano. E como no podem
simplesmente lhes vender a mesma verso, precisam justificar o custo adicionando
novas funcionalidades. onde comea a gordura.

81
Com software baseado em web e um modelo de assinatura, as pessoas pagam uma
mensalidade para usar o servio. No precisamos ficar vendendo com a adio de mais
e mais e mais, apenas precisamos providenciar um servio contnuo de valor.

Siga o Fluxo
Esteja aberto a novos caminhos e mudanas de direo
Parte da beleza de uma aplicao web sua fluidez. No a empacotamos em uma caixa,
entregamos e ento esperamos anos para o prximo lanamento. Podemos refinar e
mudar na medida em que avanamos. Esteja aberto ao fato que suaideiaoriginal pode
no ser sua melhor ideia.

Veja o Flickr. Ele comeou como um jogo online para mltiplas pessoas chamado "O
Jogo que Nunca Acaba" (The Game Neverending). Seus criadores logo entenderam que
o aspecto de compartilhamento de fotos do jogo era um produto mais plausvel do que o
prprio jogo em si (que foi eventualmente engavetado). Esteja pronto para admitir erros
e mudar o curso.

Seja um surfador. Observe o oceano. Descubra onde as ondas grandes esto quebrando
e ajuste-se de acordo.

Concluso captulo 16

Liguem seus Motores

Feito!
Tudo certo, voc conseguiu! Se tudo deu certo est psicologicamente preparado para
comear Caindo na Real com sua aplicao. Realmente nunca houve uma poca melhor
para fazer grandes softwares com recursos mnimos. Com aideiacerta, paixo, tempo e
habilidade, o cu o limite.

Alguns pensamentos de concluso:

Execuo
Qualquer um pode ler um livro. Qualquer um pode chegar com uma ideia. Qualquer um
tem um primo que um web designer. Qualquer um pode escrever um blog. Qualquer
um pode contratar algum para grudar algum cdigo.

82
A diferena entre voc e qualquer um ser quo bem voc executa. Sucesso tem tudo a
ver com uma grande execuo.

Para software, isso significa fazer um monte de coisas certas. Voc no pode somente
ter uma boa escrita mas falhar em entregar as promessas na sua prosa. Design limpo de
interface no vai dar certo se seu cdigo cheio de gambiarras. Uma grande aplicao
no vale nada se promoo pobre significa que ningum saber sobre ela. Para pontuar
grande, precisa combinar todos esses elementos.

A chave balano. Se for longe demais em uma direo, est caminhando para o
fracasso. Constantemente procure seus pontos fracos e foque neles at estar nivelado.

Pessoas
Vale a pena enfatizar a coisa que achamos que o ingrediente mais importante quando
falamos em construir uma aplicao web de sucesso: as pessoas envolvidas. Mantras,
designs de epicentro, menos software e todas essas ideias maravilhosas no vo
realmente importar se no tiver as pessoas certas a bordo para implement-las.

Voc precisa de pessoas que so apaixonadas pelo que fazem. Pessoas que se importam
pela seu artesanato e que realmente acham que um artesanato. Pessoas que se
orgulham do seu trabalho, independentemente da recompensa monetria envolvida.
Pessoas que suam nos detalhes mesmo que 95% das pessoas nem saibam distinguir as
diferenas. Pessoas que querem construir alguma coisa grande e no se conformam com
menos. Pessoas que precisam de pessoas. Ok, no necessariamente essa ltima coisa
mas no iramos resistir no jogar um pouco de Streisand na mistura. De qualquer
forma, quando encontrar essas pessoas, segure-se nelas. No final, as pessoas da sua
equipe faro ou quebraro seu projeto e sua empresa.

Mais Que Apenas Software

Tambm vale a pena notar que o conceito de Caindo na Real no se aplica apenas a
construir aplicaes web. Uma vez que voc comea a tocar nas ideias envolvidas, as
encontrar em todos os lugares. Alguns exemplos:

Foras de Operaes Especiais, como os Boinas Verdes ou Navy Seals usam

equipes pequenas e entrega rpida para atingir tarefas onde outras unidades so
grandes demais ou lentas demais para cumprir.
Os White Stripes abraam restries seguindo uma frmula simples: duas
pessoas, msicas enxutas, baterias infantis, manter o tempo de estdio ao
mnimo, etc.
O iPod da Apple se diferencia da concorrncia no oferecendo funcionalidades
como rdio FM embutido ou gravador de voz.
No futebol americano, jogadas rpidas ajudam a ganhar terreno rapidamente,
eliminando a burocracia das jogadas ensaiadas.
Ernest Hemingway e Raymond Carver usavam linguagem simples e limpa e
ainda assim entregavam impacto mximo.
Shakespeare revelou, nas limitaes dos sonetos, poemas lricos de catorze
linhas em pentmetro imbico.
E assim por diante

83
Claro, Caindo na Real sobre construir grandes softwares. Mas no h razo para parar
por a. Pegue essas ideias e tente aplic-las em diferentes aspectos de sua vida. Voc
pode acabar atingindo resultados interessantes.

Mantenha Contato
Nos deixe saber como Caindo na Real funcionou para voc. Mande e-mail para
gettingreal [at] 37signals [ponto] com.

Alm disso, mantenha-se atualizado sobre as ltimas ofertas da 37signals visitando

Signal vs. Noise, nosso blog sobre Caindo na Real, usabilidade, design e um monte de
outras coisas.

Obrigado por ler e boa sorte!

37signals Resources
37signals site
Signal vs. Noise weblog
Basecamp Web-based project collaboration
Campfire Web-based group chat for business
Backpack Web-based information organizer
Writeboard Web-based collaborative writing
Ta-da List Web-based dead-simple to-do lists
Ruby on Rails Open-source web application framework

Traduo
Organizao: Fabio Akita

Agradecimentos aos seguintes tradutores: Herval Freire, Juraci Krohling Costa,

Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo Kochenburger

E tambm aos revisores: Mateus Del Bianco, Diogo Bispo, Davis Zanetti Cabral,
Gustavo Cardoso, Ricardo Augusto

84