Caindo na Real

Bem vindos primeira das tradues mundiais

completa do livro 'Getting Real'. Totalmente em
Portugus.

captulo 1 Introduo

captulo 2 A Linha de Largada

captulo 3 Permanea Enxuto

captulo 4 Prioridades

captulo 5 Seleo de Funcionalidades

captulo 6 Processo

captulo 7 A Organizao

captulo 8 Contratando

captulo 9 Design de Interface

captulo 10 Cdigo

captulo 11 Palavras

captulo 12 Precificao e Assinatura

captulo 13 Promoo

captulo 14 Suporte

captulo 15 Ps-Lanamento

captulo 16 Concluso

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 idias 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 signfica 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
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 prevem 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 idia 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

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 em idia amplas. No vamos entedi-lo com

trechos de cdigo detalhados ou truques de css. Vamos
nos manter nas grandes idias e filosofias que dirigem o
processo Caindo na Real.

Esse livro para voc?

Voc um empreendedor, designer, programador ou
marketeiro trabalhando em uma grande idia.
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 idias 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 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 idias
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 idia. 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.

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 idias
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
idias aqui que voc possa tentar usar.
Vocs no inventaram essa idia
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 pretono-branco
Se nosso tom parecer muito convencido, conviva com
isso. Achamos que melhor apresentar idias 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.
Entretanto, isso vai requerer alguma conversa de
vendas. Venda a idia 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. Idias 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 idia, 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

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 paranico. Empresas defensivas e

paranicas 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 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 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 somam-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, 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 de 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 idia para fora
mais cedo em vez de mais tarde outra coisa boa. Um
ms ou dois fora das porteiras devem lhe dar uma boa
idia se voc est em algo slido ou no. Se estiver ser
auto-sustentvel logo e no precisar de dinheiro
externo. Se sua idia 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.
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 auto-financiados. 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 diminue 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.

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.
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 idias
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 idias.

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 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
idias, torn-las lucrativas, vend-las enquanto so lucrativas e ento sair
fora ou diversificar. justamente sobre sugar tudo. Minha idia era:
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)

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 idias 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
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 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 sua idia
tem futuro e, se tiver, voc ter uma base simples e
limpa para progredir.

Lei de Metcalfe e equipes de projeto

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 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 para tudo. Todos no processo podem falar
abertamente e honestamente. Este fluxo livre de idias
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 Idia?

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 idia. Aqui esto as vises
para cada um de nossos produtos:

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

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)

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.

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
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 atenhase 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 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 idias 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
idias 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 deixeo 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.
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.
E o que dizer s pessoas que reclamam quando ns no
adotamos a sua idia? 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 idias 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 aoBasecamp. 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, uma idia simples 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.
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.

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.

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 idias 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.

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
idias, 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

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 idias 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

Da Idia Implementao

V do brainstorm esboos HTML

codificao
Aqui vai o processo que usamos para Cair na Real:
Brainstorm
Traga idias 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
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 idias 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 idias 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.
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
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 idias 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 idias.
(Pessoas que querem que eu assine um contrato de sigilo antes de me
contar a mais simples das idias).
Para mim, idias no valem nada at serem executadas. So apenas
multiplicadores. Execuo vale milhes.
Explicao:

Idia Pssima = -1
Idia Fraca = 1
Idia mais ou menos = 5
Boa Idia = 10
Grande Idia = 15
Brilhante Idia = 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.

A idia mais brilhante, sem nenhuma execuo, vale $20. A idia mais
brilhante necessita de grande execuo para valer $20.000.000.
Esse o motivo porque no quero ouvir idias de outras pessoas. No
estou interessado at ver suas execues.
Derek Sivers, presidente e programador, CD Baby e HostBaby

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 alguma
idia do 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 idias 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.
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.
Tarefas menores e cronogramas menores so mais gerenciveis,
escondem menos requisitos mal entendidos e custam menos para voc
mudar de idia ou 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 uma idia simples 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

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 fusoshorrio. 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.
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 Idias (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

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 idia,
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.

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
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 boa idia sobre 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)

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 mal
com 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.
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 hightech. Normalmente, de qualquer maneira so apenas
divas. Um empregado mediano, mas feliz melhor do
que um expert que fica grunhindo.
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.
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 idia. 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, a idia para Blinksale. Ter a
maioria da Interface de Usurio (UI, 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 idia, 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.

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.
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 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 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 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 de idia sem ter que mudar milhes de
linhas de cdigo.

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 idia,
no tome nenhuma ao por uma semana, e ao final veja
se a idia ainda 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 contrapropostas
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

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 ajudlo a se manter em um modelo de menos software.
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).

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 a idia de 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...
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 nova idia surge, 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.
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 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 tratavamse de meros atrasadores tentando frear o processo (e que geralmente
estas pessoas no tinham nada a contribuir no design, nem qualquer idia
inovadora 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
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 idia. 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 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
uma idia de 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 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 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 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
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-dascmeras 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 idias 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.
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 emails 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

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
idias:

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 idias 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
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 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.
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 idias com software. Enquanto grandes
empresas precisam lidar com afunilamentos de
burocracia, podemos rapidamente implementar novas
idias 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

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
idia. 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?)

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 chefstrabalhando 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
seuschefs 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.
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 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

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 tudomais-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.

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
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.
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?
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 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.
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 sua idia original pode no ser sua
melhor idia.

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 a idia certa, 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 idia. Qualquer um tem um primo que
um web designer. Qualquer um pode escrever um blog.
Qualquer um pode contratar algum para grudar algum
cdigo.
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 idias 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 idias 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

Claro, Caindo na Real sobre construir grandes

softwares. Mas no h razo para parar por a. Pegue
essas idias 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!