37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Cair na Realidade



Introdução capítulo 1

O que é Cair na Realidade?

Quer construir uma aplicação web de sucesso? Então está na hora de Cair na Realidade. Cair na Realidade é o mais curto, mais rápido e melhor caminho para construir software.

Os benefícios de Cair na Realidade

Cair na Realidade entrega resultados melhores porque o força a lidar com os problemas reais que está a tentar resolver em vez de lidar com as suas ideias sobre esses problemas. Ele força-o a lidar com a realidade.

Cair na Realidade salta as especificações funcionais e outras documentações transitórias em favor de construir ecrãs reais. Uma especificação funcional é para inglês ver, uma ilusão de um acordo, enquanto uma página web pronta é a realidade. É isso que os seus clientes irão ver e usar. É isso que importa. Cair na Realidade leva-o lá mais rápido. E isso signfica que está a tomar decisões de software baseado na coisa real em vez de noções abstractas.

Finalmente, Cair na Realidade é uma aproximação que se encaixa perfeitamente no software baseado em web. O modelo da velha escola de entregar software numa caixa e esperar um ano ou dois para entregar uma actualização está a desaparecer. Ao contrário do software instalado, as aplicações web podem evoluir constantemente de maneira diária. Cair na Realidade abre essa vantagem por tudo que ela vale.

Como Escrever Software Vigoroso

A escrita vigorosa é concisa. Uma frase não deve conter palavras desnecessárias, um parágrafo não deve conter frases desnecessárias, pela mesma razão que desenhar não deve ter linhas desnecessárias e uma máquina não deve ter peças desnecessárias. Isso requer não que o escritor torne todas as frases curtas ou evite todos os detalhes e trate os assuntos por pontos, mas sim que cada palavra fale.

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


Sem mais gordura

Da forma antiga: um processo comprido, burocrático, estamos-a-fazer-isso-para-proteger-a-nossa-pele. O resultado típico: software gordo, sem interesse, a escorrer mediocridade. Blargh.

Ao Cair na Realidade livra-se de ...

Você não precisa de toneladas de dinheiro ou uma equipa enorme ou um ciclo de desenvolvimento longo para construir grande software. Estas coisas são ingredientes para aplicações lentas, obscuras, que não mudam. Cair na Realidade usa o caminho oposto.

Neste livro mostrar-lhe-emos ...

O foco é em ideias amplas. Não vamos aborrecê-lo com trechos de código detalhados ou truques de css. Vamos manter-nos nas grandes ideias e filosofias que dirigem o processo Cair na Realidade.

Este livro é para si?

Você é um empreendedor, designer, programador ou 'marketeiro' a trabalhar numa grande ideia.

Você percebe que as velhas regras não se aplicam mais. Distribui seu software em cd-roms a cada ano? Que 2002. Números de versão? Atire pela janela fora. Você precisa construir, lançar e refinar. Então recomece e repita.

Ou talvez você ainda não esteja a bordo do desenvolvimento ágil e estruturas de negócios, mas está louco para aprender mais.

Se isso lhe soa a si, então este livro é para si

Nota: enquanto este livro enfatiza em construir aplicações web, um monte de ideias são aplicáveis para actividades que não são de software também. As sugestões sobre equipas pequenas, prototipagem rápida, esperar iterações e muitas outras apresentadas aqui podem servir como um guia seja se estiver a começar um negócio, a escrever um livro, a desenhar um site web, a gravar um álbum ou a fazer uma variedade de outras coisas. Depois de começar a Cair na Realidade numa área da sua vida, verá que estes conceitos podem ser aplicados a uma ampla variedade de atividades.



Sobre a 37signals

O que fazemos

37signals é uma pequena equipa que cria software simples e focado. Os nossos produtos ajudam-no a colaborar e a organizar-se. Mais de 350 mil pessoas e pequenos negócios usam as nossas aplicações web para fazer as suas coisas. Jeremy Wagstaff, do Wall Street Journal, escreveu “os produtos da 37signals são ferramentas maravilhosamente simples, elegantes e intuitivas que fazem uma tela de Outlook parecer um equivalente em software de uma câmara de tortura”. As nossas aplicações nunca o deixam entalado.

O nosso modus operandi

Acreditamos que o software é muito complexo. Funcionalidades a mais, botões a mais, coisas a mais para aprender. Os nossos produtos fazem menos do que a concorrência – intencionalmente. Construímos produtos que funcionam de forma mais inteligente, que parecem melhor, que lhe permitem fazer as suas coisas e são mais fáceis de usar.

Os nossos produtos

Na data de publicação deste livro, temos cinco produtos comerciais e uma framework open source de aplicações web.

Basecamp transforma radicalemente a gestão de projectos. Em vez de gráficos de Gantt, engraçadinhos e tabelas cheias de estatísticas, Basecamp oferece paineis de mensagens, listas de tarefas, cronogramas simples, escritas colaborativas e partilha de ficheiros. 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 negócios. As empresas conhecidas entendem quão valioso um chat persistente em tempo real pode ser. Mensagens instantâneas convencionais são óptimas para conversas entre duas pessoas, mas são miseráveis para 3 ou mais pessoas de uma só vez. Campfire resolve esse problema e muitos mais.

Backpack é a alternativa para aqueles confusos, complexos “organize a sua vida em 25 simples passos” organizadores de informações pessoais. A aproximação de Backpack com páginas, anotações, lista de tarefas e avisos via telemóveis / e-mail são ideias inovadoras numa 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 organização “muito boa”.

Writeboard deixa-o escrever, compartilhar, rever e comparar texto, sozinho ou em grupo. É a alternativa refrescante dos gordurosos processadores de texto que são demais para 95% do que você escreve. John Gruber, da Daring Fireball disse “Writeboard deve ser a aplicação 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 mantém todas as suas listas de tarefas juntas e organizadas on-line. Mantenha as listas para si ou compartilhe com outros para fácil colaboração. Não existe maneira mais fácil de terminar as suas coisas. Mais de 100 mil listas e perto de 1 milhão de itens foram criadas até agora.

Ruby on Rails, para desenvolvedores, é uma framework web completa e open source para desenvolver aplicações para o mundo real rapida e facilmente. Rails toma conta do trabalho pesado para que você possa focar-se na sua ideia. Nathan Torkington, do império editorial O’Reilly disse que “Ruby on Rails é incrível. Usá-lo é como assistir a um filme de kung-fu, onde uma dúzia de frameworks maus se preparam para atacar o novato apenas para apanharem de uma variedade de formas imaginativas”. Não há como não gostar dessa citação.

Pode ler mais sobre os nossos produtos e a nossa empresa no nosso site web em www.37signals.com.



Avisos, Condições e outros Ataques Antecipados

Apenas para tirar isso do caminho, aqui estão nossas respostas para algumas reclamações que ouvimos de vez em quando:

“Essas técnicas não funcionarão comigo”

Cair na Realidade é um sistema que funcionou excelentemente para nós. Dito isto, as ideias nesse livro não se aplicarão a todos os projectos existentes na Terra. Se estiver a construir um sistema de armas, uma fábrica de controlo nuclear, um sistema bancário para milhões de clientes ou outro sistema crítico vital/financeiro, você irá contra a nossa atitude de "deixa correr". Vá em frente e tome precauções adicionais.

E não precisa de ser uma proposição do tipo tudo ou nada. Mesmo que não possa abraçar Cair na Realidade completamente, devem existir pelo menos algumas ideias aqui que você possa tentar usar.

“Vocês não inventaram essa ideia”

Não estamos a afirmar que inventamos estas técnicas. Muitos destes conceitos estão por aí de uma forma ou de outra há muito tempo. Não fique nervoso ao ler algum de nossos conselhos e isso o lembrar alguma coisa que já leu mais ou menos em algum weblog ou algum livro publicado há 20 anos atrás. É definitivamente possível. Estas técnicas não são todas exclusivas da 37signals. Apenas dizemos como nós trabalhamos e o que tem resultado para nós.

“Vocês levam tudo para uma visão muito preto-no-branco”

Se o nosso tom parecer muito convencido, conviva com isso. Achamos que é melhor apresentar ideias de maneira enfática 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 precisão ser esticadas ou quebradas. E algumas dessas tácticas podem não se aplicar à sua situação. Use o seu julgamento e imaginação.

“Isso não funcionará dentro da minha empresa”

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

Mesmo que a 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 seco for, mais rápido – e melhor – as coisas acontecem.

Entretanto, isso vai requerer alguma conversa de vendas. Venda a ideia do processo Cair na Realidade na sua empresa. Mostre-lhes este livro. Mostre-lhes os resultados reais que pode atingir em menos tempo e com equipas menores.

Explique que Cair na Realidade é uma maneira de baixo risco, baixo investimento para testar novos conceitos. Veja se pode separar-se da nave-mãe num projecto mais pequeno, 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 equipa da Start.com usou na Microsoft. “Eu observei a equipa da Start.com trabalhar. Eles não pedem permissão”, disse Robert Scoble, Technical Evangelist da Microsoft. “Eles tem um chefe que fornece cobertura aérea. E eles mordem um pequeno pedaço de cada vez, fazem isso e respondem a feedback”.

Lançando Start.com da Microsoft

Numa grande empresa, os processos e as reuniões são normais. Muitos meses são gastos em planeamento de funcionalidades e discutindo detalhes com a finalidade de todos alcançarem 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 nós temos uma incrível vantagem. Apenas lance! Deixe o utilizador final dizer-lhe se é a coisa certa ou não. Ei, pode corrigir e lançar na web no mesmo dia, se quiser! Não existe palavra mais forte do que do cliente – resista à pressão de se envolver em longas reuniões e discussões. Apenas lance e prove seu ponto.

Mais fácil falar do que fazer – isso implica:

Meses de planeamento não são necessários.
Meses a escrever especificações não são necessários – as especificações devem ter as fundações definidas e os detalhes entendidos e refinados durante a fase de desenvolvimento. Não tente fechar todos os pontos abertos e definir cada detalhe antes de começar a desenvolver.

Lance menos funcionalidades, mas de qualidade.
Não precisa de usar a forma big bang em todos os novos lançamentos e amontoados de funcionalidades. Dê aos utilizadores finais pedaços minúsculos que eles possam digerir.

Se existirem pequenos bugs, lance tão logo tenha os cenários principais definidos e disponibilize as correções dos bugs gradualmente depois disso. Quanto mais rápido tiver o feedback do utilizador final, melhor. Ideias podem soar óptimas no papel, mas na prática acabam por ser menos do que boas. Quanto mais cedo descobrir sobre pontos fundamentais que estão errados com uma ideia, melhor.

Quando estiver a iterar rapidamente e a reagir ao feedback dos clientes, estabelecerá uma ligação 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 Partida capítulo 2

Faça Menos

Faça menos do que sua competição

O senso comum diz que para vencer os seus competidores, você precisa de estar um passo à frente. Se eles possuem quatro funcionalidades, você precisa de cinco (ou 15, ou 25). Se eles gastam X, você precisa de gastar XX. Se eles têm 20, você precisa de 30.

Este tipo de estratégia, a Guerra Fria de estar um passo à frente, leva a uma luta sem fim. Trabalhar assim é caro, defensivo e paranóico. As empresas defensivas e paranóicas não pensam para a frente, pensam apenas no passado. Elas não lideram, seguem.

Se você quer construir uma empresa que segue, este livro não é para você.

Mas, e então? A resposta é menos. Faça menos do que a concorrência para os vencer. Resolva os problemas simples, deixe os problemas complicados, difíceis e desesperadores para os outros. Em vez de estar um passo à frente, esteja um passo atrás. Em vez de se superar, tente manter-se dentro do seu potencial.

Veremos o conceito de menos durante o livro, mas para os que agora se iniciam, menos significa:



Qual é o seu problema?

Construa software para si mesmo

Uma grande maneira de escrever software é começar por resolver os seus próprios problemas. Você será o público alvo e saberá o que é importante e o que não é. Isso dar-lhe-á um bom avanço na entrega de um produto fora de série.

A chave aqui é entender que não está só. Se tiver problemas, é provável que centenas de milhares de outras pessoas os tenham também. É esse o seu mercado. Não foi fácil?

Basecamp teve origem num problema: sendo nós uma empresa de design precisávamos de uma maneira simples de comunicar com os nossos clientes sobre os projectos. Começamos a fazê-lo através da extranet dos clientes, que atualizávamos manualmente. Mas modificar o HTML manualmente de cada a vez que o projecto precisava de ser actualizado simplesmente não funcionava. Esses sites de projectos pareciam ficar sempre congelados e eventualmente eram abandonados. Era frustrante porque deixava-nos desorganizados e deixava os clientes às escuras.

Então começamos a procurar outras opções. Ainda assim cada ferramenta que encontrávamos ou 1) não fazia o que precisávamos ou 2) era gorda em funcionalidades que não precisávamos – como cobrança, controlos restritos de acesso, tabelas, gráficos, etc. Sabíamos que deveria haver uma maneira melhor então decidimos construir a nossa própria.

Quando resolvemos os nossos próprios problemas, criamos uma ferramenta que nos apaixona. E a paixão é a chave. A paixão significa que realmente a vamos usar e cuidar dela. E essa é a melhor maneira de fazer os outros sentirem-se também apaixonados por ela.

Coçar a sua própria comichão

O mundo de Código Aberto abraçou esse mantra há muito tempo – eles designam-na por “coçar a sua própria comichão”. Para os desenvolvedores de código aberto, significa que terão as ferramentas que querem, entregues da maneira que querem. Mas os benefícios vão mais a fundo.

Como designer ou desenvolvedor de uma nova aplicação, você precisa encarar centenas de micro-decisões todos os dias: azul ou verde? Uma tabela ou duas? Estática ou dinâmica? Abortar ou recuperar? Como tomamos essas decisões? Se é algo que reconhecemos como importante, poderíamos perguntar. O resto, chutamos. E todos esses chutos constroem um tipo de débito nas nossas aplicações – uma rede interligada de coisas que assumimos.

Como um desenvolvedor, detesto isso. O conhecimento de todas essas bombas-relógio em pequena escala nas aplicações que escrevo somam-se ao meu stress. Desenvolvedores de código aberto, arranhando as suas próprias comichões, não sofrem isso. Porque eles são os seus próprios utilizadores finais, eles sabem a resposta correcta para 90% das decisões que precisam de tomar. Acho que é uma das razões porque as pessoas chegam a casa após um dia duro de trabalho de codificação e ainda trabalham com código aberto: é relaxante.

— Dave Thomas, The Pragmatic Programmers

A necessidade aguça o engenho

Campaign Monitor realmente nasceu na necessidade. Durante anos frustramo-nos com a qualidade das opções de marketing por e-mail que existiam por aí. Uma ferramenta fazia x e y mas nunca z, a próxima tinha y e z mas simplesmente não podia ter x direito. Não podíamos vencer.

Decidimos libertar algum tempo na agenda e começar a construir nossa ferramenta de marketing por e-mail dos nossos sonhos. Conscientemente decidimos não olhar para o que os outros estavam a fazer e em vez disso construir algo que tornasse as nossas vidas, e a dos nossos clientes, um pouco mais fáceis.

Depois descobrimos que não éramos os únicos que estavam infelizes com as opções que existiam. Fizemos algumas modificações ao software de forma que qualquer empresa de design pudesse usá-lo e começamos a espalhar a palavra. Em menos de seis meses, milhares de designers estavam a usar Campaign Monitor para enviar informações por e-mail para eles mesmos e para os seus clientes.

—David Greiner, fundador, Campaign Monitor

Você precisa de se importar sobre isso

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

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


Financie-se a si mesmo

Dinheiro de fora deve ser um plano B

A primeira prioridade de muitas empresas em fase de arranque é adquirir fundos de investidores. Mas lembre-se, se nos viramos para gente de fora para obtermos fundos, teremos que responder-lhes também. Crescem as expectativas. Investidores querem um retorno para o seu dinheiro – e rapidamente. O facto triste é que dinheiro entrando nem sempre significa a construção de um produto de qualidade.

Atualmente não é preciso muito para começar. O hardware é barato e uma boa parte de grandes softwares de infra-estrutura são código aberto e de graça. E a paixão não vem com uma etiqueta de preço.

Então faça o que puder com o dinheiro que tem em mãos. Pense muito e determine o que é realmente essencial e o que pode viver sem. O que pode fazer com três pessoas em vez de dez? O que pode fazer com € 40 mil em vez de € 200 mil? O que pode fazer em três meses em vez de seis? O que pode fazer se puder manter o seu emprego e construir a sua aplicação nas horas vagas?

As restrições forçam a criatividade

Dirija com recursos limitados e será forçado a contar com restrições mais cedo e mais intensamente. E isso é uma coisa boa. Restrições dirigem inovação.

As restrições também o forçam a libertar a sua ideia para fora mais cedo em vez de mais tarde – outra coisa boa. Um mês ou dois fora de portas devem dar-lhe uma boa ideia se você está em algo sólido ou não. Se estiver será imediamente auto-sustentável e não precisará de dinheiro externo. Se a sua ideia estiver errada, é hora de voltar à prancha de desenho. Pelo menos sabe disso agora em vez de daqui a meses (ou anos). E pelo menos pode voltar atrás mais facilmente. Os planos de saída tornam-se bem complicados quando estão envolvidos investidores.

Se estiver a criar software apenas para fazer dinheiro rapidamente, isso vai-se notar. Um retorno rápido é bem improvável. Então concentre-se em construir uma ferramenta de qualidade que você e os seus clientes possam viver com por um bom período de tempo.

Dois caminhos

[Jake Walker começou uma companhia com dinheiro de investidores (Disclive) e um sem (The Show). Aqui ele discute as diferenças entre os dois caminhos.]

A raíz de todos os problemas não foi conseguir dinheiro, mas tudo que veio com ele. As expectativas são simplesmente mais altas. As pessoas começam a ter salários e a motivação é para construir e depois vender, ou encontrar outra maneira para os investidores iniciais recuperarem o seu dinheiro. No caso da primeira empresa, simplesmente começamos a agir como se fôssemos muito maiores do que realmente éramos – sem necessidade …

[Com The Show] percebemos que poderíamos entregar um produto muito melhor com menos custo, apenas com mais tempo. E apostamos com um pouco de nosso próprio dinheiro que as pessoas iriam esperar por mais qualidade em vez de velocidade. Mas a empresa manteve-se (e provavelmente continuará assim) uma operação pequena. E desde esse primeiro projecto, estamos totalmente auto-financiados. Com apenas um pouco de criatividade dos nossos fornecedores, nunca mais realmente precisamos colocar muito do nosso próprio dinheiro na operação. E a expectativa não era de crescer e vender, mas de crescer por crescer e continuar se beneficiando disso financeiramente.

—Um comentário de Signal vs. Noise


Fixe o Prazo e o Orçamento, Flexibilize o Âmbito

Lance dentro do prazo e do orçamento

Aqui vai uma maneira fácil de lançar dentro do prazo e do orçamento: mantenha-os fixos. Nunca prolongue por mais tempo ou arranje mais dinheiro para resolver um problema, diminua antes o âmbito.

Existe um mito que diz o seguinte: podemos aumentar o prazo de entrega, o orçamento e o âmbito. Isso quase nunca acontece e quando acontece normalmente é a qualidade que sofre.

Se não puder encaixar tudo dentro do prazo e orçamento planeados então não aumente o tempo e o custo. Em vez disso, restrinja o âmbito. Há sempre tempo para adicionar coisas mais tarde – o mais tarde é eterno, o agora voa.

Lançar alguma coisa grande que está um pouco mais restricta em âmbito do que o planeado é melhor do que lançar uma coisa medíocre e cheia de defeitos porque precisou de atingir uma janela mágica de prazo, orçamento e âmbito. Deixe a magia para o Houdini. Você tem um negócio verdadeiro para gerir e um produto real para entregar.

Aqui vão os benefícios de fixar o prazo e orçamento e manter o âmbito flexível:

A nossa recomendação: abaixo o Âmbito. É melhor fazer meio-produto do que um produto de meia-qualidade (falaremos mais sobre isto mais à frente).

Um, dois, três ...

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

—Fred Brooks, engenheiro de software e cientista de computação


Tenha um Inimigo

Arrange um inimigo

Algumas vezes a melhor maneira de saber como é que a sua aplicação deve ser é saber o que ela não deve ser. Descubra o inimigo da sua aplicação e acender-se-á uma luz para onde precisa de ir.

Quando decidimos criar um software de gestão de projectos, sabíamos que Microsoft Project era o gorila na sala. Em vez de termos medo do gorila, usá-mo-lo como motivador. Decidimos que o Basecamp seria algo completamente diferente, o anti-Project.

Entendemos que a gestão de projectos não é sobre tabelas, gráficos, relatórios e estatísticas – é sobre comunicação. Também não é sobre um gestor de projectos sentando lá no alto e distribuindo um plano de projecto. É sobre todos a assumir responsabilidades juntos para fazer o projecto funcionar.

Os nossos inimigos eram os Gestores de Projectos Ditadores e as ferramentas que eles usavam para chicotear. Queríamos democratizar a gestão de projectos – fazê-lo de forma que todos fizessem parte (incluindo o cliente). Os projectos dão-se melhor quando todos assumem propriedade colectiva do processo.

Quando chegou a vez do Writeboard, sabíamos que tínhamos competidores lá fora com toneladas de funcionalidades. Então decidimos enfatizar um ângulo “sem frescura”. Criamos uma aplicação que permite às pessoas compartilhar e colaborar nas ideias de maneira simples, sem incomodá-las com funcionalidades não essenciais. Se não era essencial, deixamos de fora. E em apenas três meses depois do lançamento, mais de 100 mil Writeboards foram criados.

Quando começamos no Backpack o nosso inimigo eram as estruturas e regras rígidas. As pessoas devem ser capazes de organizar as suas informações à sua própria maneira – e não baseado numa série de telas pré-formatadas ou numa montanha de campos de edição obrigatórios.

Um bónus que se tem ao definir um inimigo é uma mensagem de marketing muito clara. As pessoas estão cheias de conflitos. E também entendem um produto comparando-o com outros. Com um inimigo escolhido, envia-se uma história que eles querem ouvir. Não só vão entender o seu produto melhor e mais rapidamente, mas vão tomar opções por um dos lados. E essa é uma maneira garantida de chamar a atenção e acender uma paixão.

Agora, dito isto tudo, também é importante não ficar muito obcecado com a concorrência. Analise demais outros produtos e vai começar a limitar sua maneira de pensar. Dê uma olhadela e vá em frente para a sua própria visão e as suas próprias ideias.

Não siga o líder

Marketeiros (e todos os seres humanos) são bem treinados para seguir o líder. O instinto natural é descobrir o que funciona para a concorrência e então tentar superá-los – em ser mais barato que o seu competidor que compete no preço, ou mais rápido que seu competidor que compete na velocidade. O problema é que uma vez que o consumidor já comprou a história de alguém e acredita nessa mentira, persuadi-lo a mudar é a mesma coisa que persuadi-lo a admitir que estava errado. E as pessoas odeiam admitir que estão erradas.

Em vez disso, deve-se contar uma história diferente e persuadir os ouvintes que a sua história é mais importante do que a história que eles acreditam actualmente. Se a sua competição é mais rápida, você deve ser mais barato. Se eles vendem a história da saúde, você deve vender a história da conveniência. Não apenas o posicionamento cartesiano x/y do tipo “Somos mais baratos”, mas uma história real que é completamente diferente da história que já foi contada.

Seth Godin, autor/empresário (de Seja um Mentiroso Melhor)

Qual é o problema chave?

Uma das maneiras mais rápidas de arranjar problemas é olhar para o que os seus competidores estão a fazer. Isso foi especialmente verdade para nós na BlinkList. Desde que lançamos houveram cerca de 10 outros serviços de bookmarking social que foram lançados. Algumas pessoas até começaram a gerar tabelas online com comparações funcionalidade a funcionalidade.

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

—Michael Reining, co-fundador, MindValley & Blinklist


Não Deveria ser uma Rotina

A sua paixão — ou falta de — vão notar-se

Quanto menos sua aplicação se tornar uma rotina para construir, melhor será. Mantenha pequena e gerenciável para que possa realmente apreciar o processo.

Se a sua aplicação não 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 aplicação, também vai aparecer no produto final. As pessoas conseguem ler nas entrelinhas.

A presença da paixão

Em design, onde o significado é normalmente e controversamente subjectivo ou dolorosamente indecifrável, poucas coisas são mais aparentes e lúcidas do que a presença da paixão. Isso é verdade seja quando o design do produto o agrada ou o deixa indiferente; em ambos os casos é difícil não detectar o investimento emocional das mãos que o construíram.

O entusiasmo manifesta-se prontamente, claro, mas a indiferença é igualmente inesquecível. Se o seu compromisso não vem com paixão genuína para o trabalho às mãos, isso torna-se um vazio que é quase impossível de conciliar, não importa o quão elaborado ou atractivo seja o design.

—Khoi Vinh, Subtraction.com

A padaria

Os negócios americanos neste momento realmente são sobre desenvolver ideias, torná-las lucrativas, vendê-las enquanto são lucrativas e então sair fora ou diversificar. É justamente sobre sugar tudo. A minha ideia era: aprecie cozinhar, venda o seu pão, as pessoas gostam disso, venda mais. Mantenha a padaria a ir porque você está a fazer boa comida e as pessoas estão felizes.

—Ian MacKaye, membro da Fugazi e um dos donos da Dischord Records
(da Salon.com People | Ian MacKaye)


Permaneça Elegante capítulo 3

Menos Massa

Quanto mais elegante for, mais fácil é mudar

Quanto mais massa tiver um objecto, mais energia é necessária para mudar a sua direcção. É tão verdade para o mundo dos negócios como é para o mundo físico.

Quando falamos de tecnologias web, mudar deve ser fácil e barato. Se não puder mudar durante o vôo, perderá terreno para alguém que possa. É por isso que você deve ter como objectivo ter menos massa.

A massa aumenta com...

A massa reduz-se com...

Menos massa permite mudar de direcção rapidamente. Você pode reagir e evoluir. Pode focar-se nas boas ideias e acabar com as más. Pode ouvir e responder aos seus clientes. Pode integrar novas tecnologias agora em vez de mais tarde. Em vez de um avião de carga, você dirige um pequeno barco. Aproveite esse facto.

Por exemplo, vamos imaginar uma empresa elegante, com menos massa que construiu um produto com menos código e menos funcionalidades. Do outro lado está uma empresa que tem um produto significativamente com mais software e mais funcionalidades. Então, digamos que uma nova tecnologia como Ajax ou um novo conceito como tags apareçam por aí. Quem estará apto a adaptar seu produto mais rapidamente? A equipa com mais software e mais funcionalidades e um planeamento a 12 meses ou a equipa com menos software, menos funcionalidade e um processo do tipo “vamos focar no que precisamos focar agora mesmo”, mais orgânico?

Obviamente a empresa com menos massa está em uma posição melhor para se ajustar às exigências reais do mercado. A empresa com mais massa provavelmente ainda estará a discutir as mudanças ou a empurrar o longo processo burocrático depois da empresa de menos massa já tiver feito a troca. A empresa com menos massa está dois passos à frente enquanto a empresa com mais massa ainda está a tentar entender como andar.

Negócios rápidos, ágeis, com menos massa podem mudar rapidamente o seu modelo de negócio inteiro, produto, conjunto de funcionalidades e mensagem de marketing. Eles podem cometer erros e corrigí-los rapidamente. Podem mudar as suas prioridades, misturar produtos e focar. E, mais importante, podem mudar a sua maneira de pensar.



Diminua o seu Custo de Mudança

Permaneça flexível reduzindo os obstáculos à mudança

A mudança é a sua melhor amiga. Quanto maiores forem os custos de uma mudança, menos hipóteses ela terá de ser realizada. E se os seus competidores podem mudar mais rapidamente, você estará numa enorme desvantagem. Se a mudança for cara demais, você está morto.

É aí que manter-se elegante realmente ajuda. A capacidade de mudar
num piscar de olhos é algo que as equipas pequenas têm por natureza e que
grandes equipas nunca conseguirão ter. É nisto que os grandes invejam os pequenos. O que poderia levar semanas com uma equipa grande numa mega-empresa pode levar apenas um dia numa organização pequena e elegante. Essa vantagem não tem preço. As mudanças rápidas e baratas são a arma secreta dos pequenos.

E lembre-se: Mesmo com todo o dinheiro, marketing e pessoas do mundo você não pode comprar a agilidade de ser pequeno.

Tratando-se de tecnologias web, a mudança deve ser fácil e barata. Se você não consegue realizar mudanças em tempo real perderá terreno para alguém que consiga. É por isso que você precisa ir na direcção de menos massa.

Emergência

A emergência é um dos princípios fundamentais da agilidade, e é a coisa mais próxima da magia pura. Propriedades emergenciais não são projectadas ou vêm prontas, elas simplesmente acontecem, como um resultado dinâmico do resto do sistema. “Emergência” vem do Latim da metade do século XVII que significa “ocorrência não prevista”. Você não pode colocá-la num plano ou agendá-la, mas pode cultivar um ambiente em que ela ocorra e beneficiar dela.

Um exemplo clássico de emergência está no comportamento de agrupamento dos pássaros. Uma simulação de computador pode usar tão poucas quanto três regras simples (na linha de “não se atropelem uns aos outros”) e de repente você tem comportamento complexo enquanto o grupo vai batendo as asas graciosamente pelos céus, reagrupando-se em torno de obstáculos e assim por diante. Nenhum desses comportamentos avançados (como reagrupar na mesma forma ao redor de obstáculos) é especificado pelas regras; ela emerge da dinâmica do sistema.

Regras simples, como na simulação dos pássaros, leva a comportamentos complexos. Regras complexas, como com leis tributárias na maioria dos países, levam a comportamentos estúpidos.

Muitas práticas comuns de desenvolvimento de software tem o efeito-colateral infeliz de eliminar qualquer hipótese de comportamento emergente. A maioria das tentativas de optimização – amarrando alguma coisa muito explicitamente – reduz o horizonte e âmbito de interacções e relacionamentos, que é a origem da emergência. No exemplo do grupo de pássaros, assim como sistemas bem-desenhados, são as interacções e relacionamentos que criam comportamentos interessantes.

Quanto mais duramente apertamos as coisas, menos espaço deixamos para a criatividade, e para soluções emergentes. Seja travando requisitos antes de serem bem entendidos ou prematuramente optimizando código, ou inventando navegações e cenários de fluxos de trabalho complexas antes de deixar o utilizador final usar o sistema, o resultado é o mesmo: um sistema exageramente complicado e estúpido em vez de um sistema limpo, elegante que controla emergência.

Mantenha pequeno. Mantenha simples. Deixe acontecer.

—Andrew Hunt, The Pragmatic Programmers


Os Três Mosqueteiros

Use uma equipa de três para a versão 1.0

Para a primeira versão da sua aplicação, comece com apenas três pessoas. Este é o número mágico que lhe dará força de trabalho suficiente sem lhe tirar o dinamismo e a agilidade. Comece com um desenvolvedor, um designer e um carregador de pianos (alguém que possa transitar entre ambos os mundos).

Claro, é um desafio desenvolver uma aplicação com poucas pessoas. Mas se você possuir a equipa certa, esta será valiosa. As pessoas talentosas não precisam de recursos infinitos. Elas prosperam no desafio de trabalhar com restrições e usam a criatividade para resolver os problemas. A falta de recursos humanos força-o a lidar com sacrifícios mais cedo, o que é óptimo. Fá-lo-á entender as suas prioridades mais cedo do que mais tarde. E você estará apto para comunicar sem ter constantemente que se preocupar se está deixando alguém de fora.

Se você não pode desenvolver a sua primeira versão com apenas três pessoas, então ou precisa de pessoas diferentes ou de diminuir o âmbito da sua versão inicial. Lembre-se, está tudo bem se você lançar a sua primeira versão pequena e consistente. Você rapidamente perceberá se a sua ideia tem futuro e, se tiver, terá uma base simples e limpa para progredir.

Lei de Metcalfe e equipas de projecto

Mantenha a equipa tão pequena quanto possível. A lei de Metcalfe, “O valor de um sistema de comunicação cresce aproximadamente ao quadrado do número de utilizadores finais do sistema”, tem um corolário quando se trata de equipas de projecto: A eficiência da equipa é aproximadamente o inverso do quadrado do número de membros na equipa. Começo a achar que três pessoas é óptimo para a versão 1.0 de um produto… Comece por reduzir o número de pessoas que você planeia incluir na equipa, e então reduza um pouco mais.

—Marc Hedlund, entrepreneur-in-residence na O’Reilly Media

O fluxo da comunicação

A comunicação flui mais facilmente em equipas pequenas do que em grandes. Se você é a única pessoa no projecto, a comunicação é simples. O único caminho de comunicação é entre você e o cliente. Com o aumento do número de pessoas num projecto, aumenta também o número de caminhos de comunicação. E não aumenta de forma aditiva, como o número de pessoas, aumenta de forma multiplicativa, proporcional ao quadrado do número de pessoas.

—Steve McConnell, Chief Software Engineer na Construx Software Builders Inc.
(de: Less is More: Jumpstarting Productivity with Small Teams)


Abrace as Restrições

Deixe que as limitações o guiem para soluções criativas

Nunca há o suficiente para dar a volta. Não há tempo suficiente. Não há dinheiro suficiente. Não há pessoas suficientes.

Isso é uma coisa boa.

Em vez de se desesperar com essas restrições, aceite-as. Deixe que elas o guiem. As restrições incentivam inovação e forçam o foco. Em vez de tentar removê-las, use-as em seu benefício.

Quanto a 37signals estava a desenvolver o Basecamp, nós tínhamos muitas limitações. Tínhamos:

Nós sentimos a pressão do “sem suficiente”. Então mantivemos nossos pratos pequenos. Desta maneira só poderíamos colocar até onde coubesse. Pegávamos em grandes tarefas e dividíamos em pedaços mais pequenos que atácavamos um de cada vez. Movemo-nos passo a passo e atribuímos prioridades no caminho.

Isso forçou-nos a chegar a soluções criativas. Baixámos os nossos custos de mudança construindo sempre menos software. Demos às pessoas apenas as funcionalidades suficientes para resolver os seus problemas à sua maneira – e depois saíamos do caminho. A diferença de tempo e distância entre nós tornou-nos mais eficientes na nossa comunicação. Em vez de nos encontrarmos fisicamente, comunicávamos exclusivamente via mensagens instantâneas e e-mail, o que nos forçava a ir directos ao ponto rapidamente.

As restrições são normalmente vantagens disfarçadas. Esqueça o investimento externo, os longos ciclos de lançamento e as resoluções rápidas. Em vez disso, trabalhe com o que você tem.

Combata a destruição

O que já foi descrito como “elegância bizarra” é provavelmente melhor descrito como “funcionalidade destrutiva”, como um fungo numa planta, ele gradualmente elabora a embaça a verdadeira forma do produto enquanto drena suas energias. O antídoto para funcionalidade destrutiva é, claro, o “prazo final restritivo”. Isto resulta em funcionalidades que são descartadas por causa do tempo que levaria a implementá-las. Normalmente é o caso em que as funcionalidades mais úteis levam a maior parte do tempo a serem implementadas. Portanto a combinação da destruição e do prazo final gera software como conhecemos e amamos, formado de grande quantidade de funcionalidades inúteis.

—Jef Raskin, autor (de Por que Software é como é)


Seja Você Mesmo

Diferencie-se das empresas maiores sendo amigável e pessoal

Muitas pequenas empresas cometem o erro de tentarem actuar em grande. É como se elas entendessem o seu tamanho como uma fraqueza que precisasse de ser encoberta. Muito mau. Ser pequeno pode realmente ser uma grande vantagem, especialmente quando isto representa melhor comunicação.

As pequenas empresas gostam de menos formalidades, menos burocracia e mais liberdade. As empresas menores são tipicamente mais próximas dos clientes. Isto significa que elas podem comunicar com os seus clientes de forma mais directa e pessoal. Se a empresa for pequena, pode-se usar uma linguagem familiar ao invés de calão. O seu site e o seu produto podem ter uma voz humana em vez de soar como um zumbido corporativo. Ser pequeno significa poder falar com os clientes, e não “submeter-se a eles.”

Há também vantagens na comunicação interna em pequenas empresas. Você pode dispensar as formalidades. Não há necessidade de processos complexos e múltiplas assinaturas para tudo. Todos no processo podem falar aberta e honestamente. Este fluxo livre de ideias é uma das grandes vantagens de ser pequeno.

Seja orgulhoso, desafiadoramente sincero

Embora você possa pensar que um cliente pode ser enganado por exageros no número de empregados na sua empresa ou na amplitude das suas ofertas, os espertos, aqueles que realmente quer, perceberão sempre a verdade – seja por intuição ou dedução. De forma embaraçosa, eu fiz parte de mentiras como esta no passado, e nenhuma dessas situações resultou em algo que importasse para os negócios: relações duradouras, com significado e mutuamente benéficas com pessoas que possuem uma necessidade real pelos serviços oferecidos. O melhor caminho deveria ser orgulhoso, desafiadoramente sincero sobre o tamanho exacto e a dimensão da empresa.

—Khoi Vinh, Subtraction.com

Sempre disponível

Qualquer que seja o negócio em que você estiver, um bom serviço ao cliente tornou-se o maior requisito que qualquer cliente estabelecerá. Se nós exigimos isso dos serviços que usamos então porque seria diferente com os nossos clientes? Desde o início que nós fazemos com que seja fácil e transparente para os nossos clientes contactar-nos por toda e qualquer questão que tiverem. No nosso website listamos um grande número de ferramentas gratuitas que redireciona para os nossos telemóveis e os nossos cartões de visita listam os números de cada um de nós. Nós enfatizamos para os nossos consumidores que eles podem contactar-nos a qualquer hora independentemente do problema. Os nossos clientes apreciam esse nível de confiança e nunca ninguém abusou deste serviço.

—Edward Knittel, Diretor de Vendas e Marketing, KennelSource


Prioridades capítulo 4

Qual é a Grande Ideia?

Diferencie-se das grandes empresas sendo pessoal e amigável

Defina explicitamente a visão principal da sua aplicação. O que é que a sua aplicação defende? Do que se trata? Antes de começar o design ou a codificação de qualquer coisa você precisa de saber o propósito do seu produto – a visão. Pense em grande. Para que existe ele? O que o torna diferente de outros produtos similares?

A visão irá guiar as suas decisões e mantê-lo-á num caminho consistente. Sempre que houver um ponto duvidoso, pergunte, “Estamos a manternos coerentes com a visão?”

A visão deve ser breve também. Uma frase deve ser o suficiente para definir a ideia. Aqui estão as visões para cada um dos nossos produtos:

Com o Basecamp, por exemplo, a visão era “A Gestão de Projetos é comunicação”. Sentimos fortemente que comunicação efectiva num projecto leva à propriedade colectiva, ao envolvimento, ao investimento e ao momento. Traz todos à mesma página trabalhando em direcção a um objectivo comum. Sabíamos que se o Basecamp pudesse atingir isso, tudo o resto entraria na linha.

A visão levou-nos a manter o Basecamp o mais aberto e transparente possível. Em vez de limitar a comunicação para dentro da empresa, demos acesso aos clientes também. Pensamos menos sobre permissões e mais sobre encorajar todos os participantes a tomar parte. A visão é o motivo porque ignorámos painéis, gráficos, tabelas, relatórios, estatísticas e folhas de cálculo e em vez disso focamos na prioridade da comunicação como mensagens, comentários, listas de tarefas e partilha de ficheiros. Tome a grande decisão sobre a visão logo no início e todas as pequenas decisões futuras se tornarão muito mais simples.

Filosofia do Quadro Branco

Andy Hunt e eu uma vez escrevemos um sistema de transações de cartão de débito. Um grande requisito era que o utilizador de um cartão de débito não deveria ter a mesma transacção aplicada à sua conta duas vezes. Por outras palavras, não importa que tipo de falha pudesse acontecer, o erro deveria ir para o lado de não processar a transacção em vez de a processar duplicando-a.

Então, escrevemos isso no nosso quadro branco partilhado em letras grandes: Erros a favor dos utilizadores.

Isso juntou-se a outra meia dúzia de máximas. Juntas, elas guiaram todas aquelas decisões complicadas que se fazem quando se constroi algo complexo. Juntas, essas leis deram forte coerência interna e grande consistência externa à nossa aplicação.

—Dave Thomas, The Pragmatic Programmer

Faça um Mantra

As organizações precisam de linhas de orientação. Precisam de linhas gerais; os funcionários precisam de saber a cada dia quando acordam porque é que estão a ir trabalhar. Essas linhas devem ser curtas e doces, e bem compreensivas: Por que você existe? O que o motiva? Eu chamo a isso mantra – uma descrição de três ou quatro palavras de porque você existe.

Guy Kawasaki, autor (de Make Mantra)


Ignore os Detalhes logo no início

Trabalhe do grande para o pequeno

Somos loucos por detalhes.

Sucesso e satisfação estão nos detalhes

Entretanto, o sucesso não é a única coisa que encontrará nos detalhes. Também encontrará estagnação, desacordo, reuniões e atrasos. Essas coisas podem acabar com a moral e diminuir suas hipóteses de sucesso.

Quantas vezes se encontrou encravado num único design ou elemento de código por um dia inteiro? Quantas vezes se deu conta de que o progresso que fez hoje não foi progresso real? Isso acontece quando você se concentra nos detalhes cedo demais no processo. Há tempo suficiente para ser um perfeccionista. Só que deve fazer isso mais tarde.

Não se preocupe com o tamanho da fonte do cabeçalho na primeira semana. Você não precisa empregar o tom perfeito de verde na segunda semana. Não precisa mover em três pixels o botão de “submeter” na terceira semana. Coloque apenas as coisas na página por enquanto. E depois use. Garanta que funciona. Mais tarde pode ajustar e aperfeiçoar.

Os detalhes revelam-se ao utilizar-se o que se está a construir. Verá o que precisa de mais atenção. Sentirá o que está em falta. Saberá quais crateras pavimentar porque estará sempre a cair nelas. É quando precisa de prestar atenção, e não antes.

O Diabo está nos Detalhes

Quase me cansei da atitude “entre nos detalhes imediatamente” depois de ter tido algumas aulas de desenho … Se começar a desenhar os detalhes imediatamente pode ter certeza que o desenho não vai prestar. De facto, dessa forma perde completamente o ponto.

Deve começar por definir as proporções correctas da cena toda. Então esboce os grandes objetos na sua cena, indo até os menores. O esboço deve ser bem vago nesse ponto. Então pode proceder sombreando, o que consiste em dar volume à vida. Comece apenas com três tons (claro, médio, escuro). Isso dá um esboço de tons. Então, para cada parte do seu desenho reavalie os três tons e aplique-os. Faça isso até os volumes aparecerem (requer múltiplas iterações) ...

Funciona do grande para o pequeno. Sempre.

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


Só é um Problema Quando é um Problema

Não desperdice tempo com problemas que você ainda não tem

Precisa mesmo de se preocupar em escalar para 100.000 utilizadores finais hoje se vai levar dois anos até chegar lá?

Tem mesmo que contratar oito programadores se hoje você só precisa de três?

Precisa realmente de 12 servidores topo de gama agora se dá para correr em dois durante um ano?

Desenrrasque-se apenas

As pessoas costumam gastar tempo demais logo à partida a tentar resolver problemas que elas ainda nem têm. Não faça isso. Bolas, nós lançamos o Basecamp sem a capacidade para cobrar aos clientes! Como o produto é cobrado mensalmente, sabíamos que teríamos um intervalo de 30 dias para arranjarmos uma solução. Usámos esse tempo para resolver problemas mais urgentes e só então, após o lançamento, enfrentamos o problema das cobranças. Correu bem (e forçou-nos a adoptar uma solução simples, sem floreados desnecessários).

Não se preocupe com uma coisa até que você tenha de facto que fazê-lo. Não desenvolva demais. Aumente hardware e software de sistema só conforme as necessidades. Se ficar lento por uma ou duas semanas não será o fim do mundo. Seja apenas honesto: explique aos seus clientes que está a passar por dores de crescimento. Eles podem não ficar empolgados mas apreciarão a franqueza.

Resumo da Ópera: Tome decisões só no momento necessário, pois aí você terá acesso à informação real de que precisa. No entretanto estará em condições de prestar atenção às coisas que requerem cuidado imediato.



Contrate os Clientes Certos

Encontre o nicho de mercado para a sua aplicação e concentre-se somente nele

O cliente nem sempre tem razão. A verdade é que você terá que separar quem é certo e quem é errado para a sua aplicação. A boa notícia é que a Internet torna mais fácil do que nunca encontrar as pessoas certas.

Se você tentar agradar todo mundo, não irá agradar ninguém

Quando nós desenvolvemos o Basecamp, focamos o nosso marketing em empresas de design. Por restringir o nosso mercado desta forma, foi bem mais fácil atrair clientes passionais que, por sua vez, iriam evangelizar o produto. Saiba para quem a sua aplicação realmente se destina e foque-se em agradar este público.

A Melhor Decisão Que Já Tomamos

A decisião de direcionar o Campaign Monitor estritamente para o mercado de web design foi a melhor escolha que já fizemos. Ela permitiu-nos identificar facilmente quais recursos que seriam genuinamente úteis e, mais importante do que isso, quais os recursos que deveríamos deixar de fora. Não só atraímos mais clientes por apontar para um grupo menor de pessoas, como todos esses clientes tinham necessidades similares que tornavam o nosso trabalho muito mais fácil. Há um monte de recursos no Campaign Monitor que seriam inúteis para qualquer um excepto um web designer.

Focar um nicho de mercado também torna muito mais fácil divulgar o seu software. Agora que temos um público bem definido, podemos fazer anúncios em sítios da web que este público frequenta, 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 não tem um problema de escalabilidade

”Conseguirei escalar minha aplicação quando milhões de pessoas começarem a usá-la?”

Quer saber? Espere até que isso aconteça de facto. Se você tiver um número gigante de pessoas a sobrecarregar o seu sistema, magnífico! Que óptimo problema para se ter. A verdade é que a maioria esmagadora das aplicações web nunca alcançará esse estágio. E mesmo se você começar a ser sobrecarregado isto tipicamente não é uma questão de tudo ou nada. Você terá tempo para ajustar-se e responder ao problema. Além disso, depois de lançar a sua aplicação você terá mais dados reais e benchmarks que podem ser usados para descobrir as partes que precisam de ser revistas.

Por exemplo, nós corremos o Basecamp num único servidor durante o primeiro ano. Por termos iniciado com uma configuração simples, conseguimos implementar numa única semana. Nós não começamos com um aglomerado de 15 computadores nem gastamos meses a preocupar-nos com a escalabilidade.

Tivemos problemas? Alguns. Mas também descobrimos que a maior parte do que temíamos, como um breve período de lentidão, não era o fim do mundo para os clientes. Desde que você mantenha as pessoas informadas, e seja honesto sobre a situação, elas entenderão. Em retrospectiva, estamos contentes por não termos atrasado o lançamento em meses para criar “a configuração perfeita”.

No começo, priorize construir um produto sólido em vez de obsecar-se com escalabilidade ou quintas de servidores. Crie uma grande aplicação e depois preocupe-se com o que fazer quando ela se tornar animalmente bem-sucedida. Caso contrário você o corre o risco de desperdiçar energia, tempo e dinheiro prendendo-se a algo que nunca acontecerá.

Acredite ou não, o maior problema não é escalar, é chegar ao ponto de ter de fazê-lo. Sem o primeiro problema, você não terá o segundo.

Você vai ter que rever de qualquer maneira

A verdade é que todos têm problemas de escalabilidade, ninguém lida com a transição de zero para alguns milhões de utilizadores finais sem rever quase todos os aspectos do design e arquitetura da aplicação.

—Dare Obasanjo, Microsoft (de Scaling Up and Startups)


Faça Software que tem Opinião

A sua aplicação deve tomar partido

Algumas pessoas defendem que o software deve ser agnóstico. Dizem que é arrogante da parte dos desenvolvedores limitar a funcionalidade ou ignorar os pedidos de novos recursos. Dizem que o software deve ser sempre o mais flexível possível.

Para nós isso é conversa da treta. O melhor software traz consigo uma visão. O melhor software toma partido. Quando alguém usa um software, não está a procurar apenas recursos, está a procurar uma abordagem. Está a procurar uma visão. Decida qual é a sua visão e mantenha-se fiel a ela.

E lembre-se, se não gostarem da sua visão há um monte de outras visões por aí. Não corra atrás de quem você nunca irá contentar.

Um óptimo exemplo é o projecto original do wiki. Ward Cunningham e os seus amigos deliberadamente desproveram o wiki de muitos recursos que no passado eram considerados parte indispensável da colaboração de documentos. Em vez de atribuir cada mudança do documento a uma pessoa determinada, eles removeram muito da representação visual de propriedade. Eles tornaram o conteúdo atemporal e destituído de ego. Eles decidiram que não importava quem escreveu o conteúdo ou quando ele foi escrito. E isso fez toda a diferença. Essa decisão despertou nas pessoas um senso de comunidade e foi peça-chave no sucesso da Wikipédia.

As nossas aplicações trilharam um caminho parecido. Elas não tentam ser todas as coisas para todas as pessoas. Elas têm uma atitude. Elas vão atrás de clientes que são no fundo parceiros. Elas têm apelo para as pessoas que partilham a nossa visão. Ou se está do lado de dentro ou se está do lado de fora.



Seleção de Funcionalidades capítulo 5

Metade, mas não meio-feito.

Construa metade de um produto, e não um produto meio-feito.

Previna-se contra a atitude “pau para toda obra” que a sua aplicação web pode tomar. Incluir todas as ideias decentes que lhe aparecem pela frente é meio-caminho andado para acabar com um produto meio-feito nas mãos.

Foque-se no que é essencial. As boas ideias podem ser listadas. Pense no que o seu produto deveria ser e divida-o ao meio. Descasque as funcionalidades até só sobrarem as mais essenciais. E depois descasque de novo.

Quando desenvolvemos o Basecamp, começámos pela secção de mensagens. Sabíamos que era o coração da aplicação e, enquanto a trabalhávamos, ignorámos as secções dos prazos, das listas de tarefas e das outras coisas. Isso permitiu-nos basear as nossas decisões em uso real, e não em palpites.

Comece com uma aplicação simples e inteligente e deixe-a ganhar impulso. Depois sim, comece a construir usando os alicerces sólidos que criou.



Simplesmente não interessa

Só o essencial

A nossa resposta preferida à pergunta “porque não fizeram isto ou porque não fizeram aquilo?” é: “porque, simplesmente não interessa”. Esta afirmação personifica aquilo de que um produto é feito: de descobrir o que interessa e ignorar o resto.

Quando lançámos o Campfire ouvimos as perguntas que se seguem, de pessoas que experimentaram o produto pela primeira vez:

“Porque é que só marcam o tempo de 5 em 5 minutos? Porque não marcam o tempo em todas as linhas da conversa?” Resposta: simplesmente não interessa. Quantas vezes precisamos de marcar o tempo de uma conversa ao segundo ou mesmo ao minuto? Menos de 95% das vezes, certamente. Marcar o tempo de 5 em 5 minutos é suficiente porque menos do que isso simplesmente não interessa.

“Porque é que não permitem formatação do texto nas conversas?” Resposta: simplesmente não interessa. Se precisa de enfatizar o texto, pode usar letras maiúsculas ou rodear o texto com uns poucos *’s. Estas soluções não precisam de software extra, apoio técnico e poder de processamento; nem implicam uma curva de aprendizagem. Além disso, a formatação intensiva numa aplicação de conversação em modo-texto simplesmente não interessa.

“Porque não mostram o número total de pessoas na sala da conversação, num determinado momento?” Resposta: simplesmente não interessa. Os nomes estão todos listados por isso sabe quem está na sala. Mas também… que interessa saber se estão 12 ou 16 pessoas? Se não interfere com o seu comportamento, então simplesmente não interessa.

Era bom ter estas coisas? Claro. Mas são essenciais? São mesmo importantes? Não. E é por isso que as deixámos de fora. Os melhores designers e os melhores programadores não são aqueles com mais técnica, ou dedos mais rápidos, ou aqueles que conhecem o Photoshop, ou outro programa, como a palma da mão. São sim, os que conseguem determinar o que simplesmente não interessa. É aí que se ganha muito.

A maior parte do tempo que gasta é desperdiçada em coisas que simplesmente não interessam. Se as conseguir tirar do seu, vai atingir níveis de produtividade inimagináveis.



Comece com Não

Faça com que as funcionalidades dêem duro para ser implementadas

O segredo de criar meio produto ao invés de um produto meia-boca é dizer não.

Cada vez que você diz sim para uma funcionalidade, você está adotando um filho. Você tem que levar seu bebê através de toda uma cadeia de eventos (exemplo: design, implementação, testes etc.). Uma vez que está funcionalidade está lá, você está preso a ela. Apenas tente removê-la e veja o quão irados ficarão os clientes.

Não concorde com tudo

Faça 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 três dias para serem aceitas.

É por isso que você tem que começar com um não. Cada novo pedido de funcionalidade que vem até nós – ou de nós – encontra um não. Nós ouvimos mas não agimos. A resposta inicial é “agora não”. Se o pedido continua a aparecer, então sabemos que é hora de um olhar mais profundo. Somente então nós começamos a pensar na funcionalidade de fato.

E o que dizer às pessoas que reclamam quando nós não adotamos a sua ideia? Lembre-os o porque eles gostam da aplicação em primeiro lugar. “Você gosta dele porque nós dizemos não. Você gosta dele porque ele não faz outras 100 coisas. Você gosta dele porque ele não tenta agradar a todos sempre.”

”Nós não queremos milhares de funcionalidades”

Steve Jobs deu uma pequena apresentação 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 mão perguntando, “Ele faz [x]?”, “Você planeja adicionar [y]?”. Finalmente Jobs disse, “Calma, calma – abaixem seus braços. Ouçam: Eu sei que vocês tem milhares de ideias de funcionalidades bacanas para o iTunes. Nós também. Mas não queremos milhares de funcionalidades. Isso seria horrível. Inovação não é dizer sim para tudo. É dizer NÃO para tudo exceto as funcionalidades mais cruciais.”

—-Derek Sivers, presidente e programador, CD Baby e HostBaby
(from Diga NÃO por padrão)


Custos Ocultos

Exponha o preço das novas funcionalidades

Mesmo que uma funcionalidade passe o estágio do “não”, você ainda precisa expor seus custos ocultos.

Por exemplo, fique de alerta com loops de funcionalidades, ou seja, funcionalidades que levam a mais funcionalidades. Nós recebemos pedidos para adicionar uma aba de reuniões ao Basecamp. Parece simples até que você examine com mais cautela. Pense em todos os diferentes itens que uma aba de reuniões precisaria: localização, hora, sala, pessoas, convites por e-mail, integração com o calendário, documentação de suporte, etc. Isso sem mencionar que nós teríamos que modificar as imagens de promoção, as páginas do tour, páginas do faq/ajuda, contrato de prestação de serviço e mais. Antes que você note, uma ideia simples pode ser tornar uma dor de cabeça enorme.

Para cada nova funcionalidade você precisa…



Você Pode Lidar com Isso?

Crie algo que você possa gerenciar

Se você lançar um programa de filiação, 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 filiação ao invés de escrever, assinar e enviar cheques todos os meses.

Você consegue dar 1 GB de espaço de graça, só porque o Google dá? Talvez você deva começar pequeno, em 100 mb, ou apenas ceder espaço para as contas pagantes.

Conclusão: Crie produtos e ofereça serviços que você possa gerenciar. É fácil fazer promessas. É bem mais díficl mantê-las. Tenha certeza que, seja lá o quer for que você fizer, seja algo que você possa realmente sustentar – organizacional, estratégica e financeiramente.



Soluções Humanas

Construa software para resolver conceitos genéricos e encorage as pessoas a encontrar soluções próprias

Não obrigue as pessoas a seguir convenções. Em vez disso faça software genérico de forma a que cada pessoa encontre a sua própria solução. Dê às pessoas o suficiente para resolverem os problemas delas à maneira delas. E depois deixe-as andar.

Quando criámos o Ta-da List deixámos, intencionalmente, muita coisa de fora. Não é possível afectar uma pessoa a uma tarefa, não é possível estabelecer um prazo para as tarefas, não é possível categorizar tarefas, etc.

Ao deixarmos as pessoas serem criativas mantivémos a ferramenta limpa e desobstruída. As pessoas encontraram, sozinhas, formas de resolverem os seus próprios problemas. Se queriam adicionar uma data a uma tarefa, poderiam adicionar (prazo: 7 de Abril, 2007) à descrição da tarefa. Se queriam adicionar uma categoria, poderiam adicionar [Livros] à descrição da tarefa. Ideal? Não. Infinitamente flexível? Sim.

Se tentássemos construir software para lidar especificamente com estes cenários, estaríamos a torná-lo menos útil para todos os outros casos.

Faça o melhor que conseguir com o núcleo do problema e depois afaste-se. As pessoas vão encontrar soluções e convenções próprias usando as ferramentas que lhes deu.



Esqueça os Pedidos de Funcionalidades

Deixe os seus clientes lembrar-lhe do que é importante

Os clientes querem tudo o que há debaixo do sol. Vão fazê-lo desaparecer debaixo de pedidos de funcionalidades. Basta verificar nos fóruns dos nossos produtos; a categoria de pedidos de funcionalidades tem muito mais movimento do que as outras.

Vamos ouvir acerca “desta funcionalidadezita extra” ou “isto não deve ser difícil” ou “não seria fácil adicionar isto” ou “isto deve demorar uns segundos a fazer” ou “se adicionassem isto eu pagaria o dobro” e por aí adiante.

É evidente que não culpamos as pessoas por pedirem funcionalidades. Encorajamos esses pedidos e queremos ouvir o que as pessoas têm para dizer. Quase tudo o que adicionamos aos nossos produtos começa como um pedido feito por clientes. Mas, como já dissemos, a primeira resposta deve ser um não. O que fazer, então, com todos estes pedidos que chegam? Onde é que os guarda? Como os gere? Não gere. Leia-os apenas, depois deite-os fora.

Sim, leia-os, deite-os fora, e esqueça-se deles. Parece blasfémia mas aqueles que são importantes vão continuar a aparecer. Esses são os únicos de que tem de se lembrar. São os verdadeiramente essenciais. Não se preocupe com o rastreio e armazenamento de cada pedido que chega. Deixe os seus clientes serem a sua memória. Se forem pedidos mesmo importantes, eles vão recordar-lhe disso até você não se esquecer.

Como chegámos a esta conclusão? Quando lançámos o Basecamp rastreámos todos os pedidos com alguma dimensão numa lista de tarefas do Basecamp. Quando um pedido era repetido por outra pessoa nós actualizávamos a lista com um traço extra (II ou III ou IIII, etc). Pensávamos que um dia iríamos rever a lista e começaríamos a trabalhar nas funcionalidades mais pedidas e pela lista abaixo.

Mas a verdade é que nunca mais olhámos para a lista. Já sabíamos o que era preciso fazer porque os nossos clientes estavam constantemente a lembrar-nos fazendo os mesmos pedidos uma e outra vez. Não havia necessidade para uma lista ou uma carrada de análise porque estava tudo a acontecer em tempo real. Quando lhe estão sempre a lembrar do que é importante, é impossível esquecer-se.

E mais uma coisa: não deve incluir uma funcionalidade só porque x número de pessoas a pediu. Às vezes é melhor dizer não e manter a sua visão do produto.



Segure as Rédeas

Pergunte o que as pessoas não querem

A maior parte das enquetes e pesquisas sobre software são 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 não perguntar o que as pessoas nao querem? “Se você pudesse remover algo, qual seria?” “O que você não usa?” “O que mais te atrapalha?”

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

Inovação aparece quando dizemos não

[Inovação] aparece quando dizemos não à 1000 coisas para termos certeza que não estamos seguindo o caminho errado ou tentando fazer coisas demais. Nós estamos sempre pensando em novos mercados para entrar, mas somente dizendo não para isso que você pode se concentrar no que realmente importa.

—Steve Jobs, CEO, Apple (de A Semente de Inovação da Apple)


O processo capítulo 6

Despache-se para poder executar o Software

Pegue em algo real e execute-o rapidamente

Executar o software é a melhor maneira de fazer acontecer, reuna a sua equipa e deite fora ideias que não funcionam. Esta deve ser a sua prioridade número um.

Não há problema nenhum em fazer menos, ignorar detalhes e encontrar atalhos nos seus processos se isto o levar a software que funciona mais rápido. Uma vez lá, você será recompensado com perspectivas significativamente mais precisas de como proceder. Histórias, rascunhos de estrutura e mesmo protótipos html são apenas aproximações. Software a ser executado é real.

Com o software real a ser executado todos ficam perto da compreensão e do acordo. Evitam-se assim argumentos acalorados sobre esboços e parágrafos que não resolveriam nada de importante. Você percebe que coisas que considerava triviais são na verdade bem cruciais.

Coisas reais levam a reacções reais. E é assim que você chega à verdade.

As coisas reais levam ao acordo

Quando um grupo de pessoas diferentes tentam encontrar o que é harmonioso… as suas opiniões tendem a convergir se eles estão a rascunhar coisas reais em larga escala. Claro, se estão fazendo um esboço ou a gerar ideias, não vão concordar. Mas se você começa a fazendo coisas reais, tendem a chegar a um acordo.

—Christopher Alexander, Professor de Arquitectura
(de Contrastando Conceitos de Harmonia na Arquitectura)

Faça Funcionar o Mais Rápido Possível

Eu não me lembro de nenhum projecto de software em que tenha estado envolvido – grande ou pequeno – que tenha tido sucesso em termos de prazos, custos ou funcionalidades que tenha começado com um longo período de planeamento e discussão, e sem desenvolvimentos concorrentes. É simplesmente muito fácil e às vezes divertido, deitar fora o precioso tempo a inventar funcionalidades que acabam por ser desnecessárias ou que não serão implementáveis.

Isso aplica-se a qualquer tipo de desenvolvimento e chegar a alguma coisa real e a executar é um mantra fractal. Isto não se aplica apenas a projectos como um todo, é pelo menos igualmente aplicável ao desenvolvimento de componentes de pequena escala, dos quais a aplicação é feita.

Quando há trabalho de implementação de um componente chave, os programadores querem entender como vai ou não trabalhar em conjunto com as partes da aplicação pelas quais eles são responsáveis e irão geralmente tentar usá-lo assim que puderem. Mesmo que a implementação não esteja perfeita ou completa de início, estas colaborações prematuras normalmente levam a interfaces bem definidas e funcionalidades que fazem exactamente o que se espera delas.

—Matt Hamer, programador e gestor de produtos, Kinja


Enxague e Repita

Trabalhe por iterações

Não espere fazer bem à primeira vez. Deixe a aplicação crescer e apresentar-se a si. Deixe-a alterar-se e evoluir. Com softwares baseados na web não há necessidade de entregar a perfeição. Projecte as páginas, use-as, analise-as e depois comece outra vez.

Em vês de querer tudo bem desde o início, o processo iterativo permitir-lhe-á continuar a tomar decisões informadas no percurso. Terá uma aplicação activa e a correr rapidamente, desde que não fique obcecado em atingir a perfeição logo de início. O resultado é um feedback e um guia real sobre o que requer sua atenção.

As iterações levam à liberação

Não é preciso almejar a perfeição na primeira tentativa se souber que isto será refeito mais tarde. Saber que revisitará problemas é um grande motivador para apenas lançar as ideias e ver se voam.

Talvez você seja mais esperto do que eu

Talvez você seja BEM mais esperto do que eu.

Isto é totalmente possível. De facto, isso é provável. De qualquer maneira, se você é como a maioria das pessoas, então como eu, tem problemas imaginando aquilo que não consegue ver e tocar.

Os seres humanos são extremamente bons a responder a coisas do ambiente. Nós sabemos entrar em pânico quando um tigre entra na sala e como limpar tudo depois de uma cheia devastadora. Infelizmente somos terríveis a planear para a frente, em compreender as ramificações das nossas acções e em dar prioridade às coisas que realmente têm importância.

Talvez você seja um dos poucos indivíduos que consegue manter isto tudo na sua cabeça. Isso realmente não interessa.

Na Web 2.0, o mundo em que começamos a assumir que qualquer pessoa já usa a web, possibilita aos programadores espertos colocarem estas fraquezas humanas a trabalhar para elas. Como? Permitindo que os seus utilizadores finais lhes contem o que pensam enquanto ainda há tempo de fazer algo a respeito.

E esta última frase explica porque se deve desenvolver desta maneira e como se pode querer promover/lançar.

Torne a sua história directa. Garanta que as peças funcionam. Então lance e reveja. Ninguém é tão esperto quanto todos nós juntos.

Seth Godin, autor/empreendedor


Da Ideia à Implementação

Vá da discussão aos esboços a HTML e a codificação

Aqui vai o processo que usamos para Cair na Realidade:

Discussão

Traga ideias à tona. O que este produto irá fazer? Para o Basecamp, nós olhamos para nossas próprias necessidades. Queríamos publicar actualizações de projecto. Queríamos participação dos clientes. Sabíamos que os projectos tinham datas chave. Queríamos centralizar arquivos para que as pessoas pudessem rever coisas antigas com facilidade. Queríamos ter uma visão da figura maior, uma vista aérea do que estava a acontecer com todos os nossos projectos. Juntas, estes pressupostos e alguns outros, serviram de base de fundação.

Esta fase não é sobre os pequenos pormenores. É sobre as grandes questões. O que a aplicação precisa de fazer? Como saberemos quando será útil? O que faremos exactamente? Isto é sobre ideias de alto nível, não discussões no nível dos pixels. Nesta fase, estes tipos de detalhe simplesmente não fazem sentido.

Papel de Padeiro

Os esboços são rápidos, sujos e baratos e é exactamente assim que você deve começar. Desenhe coisas. Rabisque coisas. Caixas, círculos, linhas. Transfira as ideias da cabeça para o papel. O objectivo neste momento deve ser converter conceitos em desenhos grosseiros de interface. Este passo é apenas sobre experimentação. Não há respostas erradas.

Crie páginas HTML

Faça uma versão HTML de uma funcionalidade (ou secção, ou fluxo, se for mais apropriado). Pegue em algo real e publique para que todos possam ver como fica no ecrã.

Para o Basecamp, primeiro fizemos a página de “publicar mensagens”, depois a página de “editar mensagens” e assim por diante.

Não escreva nenhum código de programação ainda. Faça apenas um protótipo em html e css. A implementação vem depois.

Codifique

Quando o protótipo parecer bom e demonstrar o suficiente das funcionalidades necessárias, prossiga e ligue o código de programação.

Durante todo este processo, lembre-se de continuar a ser flexível e esperar múltiplas iterações. Sinta-se livre para deitar fora qualquer parte de uma realização de qualquer passo particular e começar novamente se ela mostrar ser má. É natural passar por este ciclo mais do que uma vez.



Evite Preferências

Decida sobre os pequenos pormenores para que os seus clientes não precisem de o fazer

Deparámo-nos com uma decisão difícil: quantas mensagens incluímos em cada página? A primeira inclinação pode ser em dizer, “Vamos apenas transformar isso numa preferência onde as pessoas possam escolher 25, 50 ou 100”. Entretanto, essa é a forma mais simples. Tome apenas a decisão.

As preferências são uma maneira de evitar tomar decisões difíceis

Em vez de usar a nossa experiência para escolher o melhor caminho, deixamos essa escolha nas mãos dos clientes. Pode parecer que lhes estamos a fazer um favor mas apenas lhes estamos a dar mais trabalho (e provavelmente eles já são suficientemente ocupados). Para os clientes, páginas de preferência com uma quantidade infinita de opções são uma dor de cabeça, não uma bênção. Os clientes não deveriam ter que pensar sobre cada pormenor ínfimo – não coloque esse peso sobre eles quando essa responsabilidade deveria ser sua.

As preferências também são más porque criam mais software. Mais opções requerem mais código. Há ainda ainda todos os testes extra e desenho que é necessário fazer. E ainda vamos acabar com permutações de preferências e páginas que nunca usaremos. Isso significa possíveis defeitos que não sabemos a respeito: layouts estragados, tabelas a explodir, problemas estranhos de paginação, etc.

Tome a decisão

Tome as decisões simples em vez dos clientes. Foi o que fizemos no Basecamp. O número de mensagems por página é 25. Na página de resumo, mostram-se as últimas 25. As mensagens são ordenadas em ordem cronológica inversa. Os cinco projectos mais recentes são mostrados no painel. Não existem opções. É a forma que tem que ser.

Sim, podemos tomar uma má decisão. Mas, e então? Se o fizermos, as pessoas vão reclamar e dizer-nos isso. Como sempre, podemos ajustar. Cair na Realidade é justamente sobre ser capaz de mudar em tempo real.

As preferências têm um custo

No fim de contas, as preferências têm um custo. Claro, algumas preferências também têm benefícios importantes – e podem ser funcionalidades de interface cruciais. Mas cada um tem um preço e temos que considerar cuidadosamente o seu valor. Muitos utilizadores finais e programadores não entendem isto e acabam com muito custo e pouco valor pelos seus euros de preferências … acho que se formos duramente disciplinados sobre ter bons padrões Que Simplesmente Funcionam, em vez de adicionar preferências folgadamente, isto leva naturalmente a interfaces com utilizadores coerentes como um todo e na direcção certa.

—Havoc Pennington, líder técnico, Red Hat (de Software Livre e boas interfaces com Utilizadores)


"Feito !"

Se as decisões são temporárias, então faça a escolha e siga em frente

Feito. Comece a pensar nisto como uma palavra mágica. Quando algo está feito significa que se atingiu algum objectivo. Foi tomada uma decisão e podemos seguir em frente. Feito significa que estamos a criar momento.

Mas espere, e se nos enganámos e tomámos a decisão errada? Tudo bem. Não se trata de nenhuma operação ao cérebro, mas apenas de uma aplicação web. Como temos dito, de qualquer forma teremos muito provavelmente que rever funcionalidades e ideias várias vezes durante o processo. Não importa o quanto planeamos, com certeza que de qualquer forma vamos errar pelo menos em parte. Então não faça essa coisa chamada “pausa para análise”. Isso apenas desacelera o progresso e compromete a moral.

Em vez disso, avalie a importância de seguir em frente. Entre no ritmo de tomar decisões. Tome uma decisão rápida e simples, retomando a seguir e mudando se não funcionar.

Aceite o facto de que as decisões são temporárias. Aceite que vão ocorrer erros e perceba que não há nada demais enquanto estivermos a fazer correcções rapidamente. Execute, crie momento, e siga em frente.

Seja um Executador

É tão engraçado quando ouço sobre pessoas que protegem muito as suas próprias ideias. (Pessoas que querem que eu assine um contrato de sigilo antes de me contar a mais simples das ideias).

Para mim, ideias não valem nada até serem executadas. São apenas multiplicadores. É a execução que vale milhões.

Explicação:

  • Ideia Péssima = -1
  • Ideia Fraca = 1
  • Ideia mais ou menos = 5
  • Boa Ideia = 10
  • Grande Ideia = 15
  • Ideia Brilhante = 20
  • Sem execução = $1
  • Execução Fraca = $1.000
  • Execução mais ou menos = $10.000
  • Boa Execução = $100.000
  • Grande Execução = $1.000.000
  • Execução Brilhante = $10.000.000

Para fazer negócios, é preciso multiplicarem-se estes dois conceitos.

A ideia mais brilhante, sem nenhuma execução, vale $20. A ideia mais brilhante necessita de uma grande execução para valer $20.000.000.

É esse o motivo porque não quero ouvir ideias de outras pessoas. Não estou interessado até observar as respectivas execuções.

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


Teste ao Ar Livre

Teste a sua aplicação com no mundo real

Não há substituto para pessoas reais utilizando a sua aplicação de forma real. Utilize dados reais. Receba feedback real. E só então melhore baseado nessa informação.

Os testes de usabilidade formais são muito duros. As configurações de laboratório não reflectem a realidade. Se ficarmos sobre os ombros de alguém, teremos alguma ideia do que está a funcionar ou não mas as pessoas normalmente não agem bem de frente para as câmaras. Quando outra pessoa está a observar, as pessoas são especialmente mais cuidadosas para não cometer erros – sendo que os erros são exactamente do que estamos à procura.

Em vez disso, lance versões beta para alguns poucos seleccionados dentro da própria aplicação real. Faça com que usem as funcionalidades do beta ao lado das funcionalidades lançadas. Isso irá expor essas funcionalidades a dados reais das pessoas e a fluxos verdadeiros. E é aí que teremos resultados reais.

Além disso, não tenha uma versão de lançamento e outra beta. Elas devem ser sempre uma única. Uma versão beta separada só receberá uma leve navegação. A versão real, com algumas funcionalidades beta misturadas, receberão o fluxo de utilização completo.

O Livro Beta

Se os programadores ficam nervosos a disponibilizar o código que escreveram, então os editores e os autores ficam aterrorizados a lançar os seus livros. Uma vez que o livro está fixo no papel, ele é visto como uma coisa muito complicada para se mudar (na verdade não é, mas a percepção e as lembranças de problemas com velhas tecnologias ainda persistem na indústria). Então, editores passam por vários problemas (e custos) a tentar fazer com que os livros fiquem “bem” antes de serem lançados.

Quando escrevi o livro Agile Web Development With Rails, houve muita procura entre os programadores: dê-nos o livro agora – queremos aprender Rails. Mas eu caí no pensamento de um editor. “Ainda não está pronto”, dizia-lhes eu. Mas a pressão da comunidade e a trocas de ideias com David Heinemeier Hansson mudaram a minha forma de pensar. Lançamos o livro em formato pdf cerca de 2 meses antes dele ficar completo. Os resultados foram espectaculares. Não apenas vendemos um montão de livros, mas recebemos comentários – muitos comentários. Configurei um sistema automatizado para capturar os comentários dos leitores, e no final tivemos quase 850 reparos sobre erros de sintaxe, erros técnicos e sugestões para novos conteúdos. Quase todos eles acabaram po figurar no livro final.

Foi uma situação ganha-ganha: consegui entregar um livro muito melhor e a comunidade teve acesso antecipado a algo que eles queriam. E se você estiver numa corrida competitiva, ter algo antecipadamente ajuda as pessoas a comprometerem-se consigo e não com a sua competição.

—Dave Thomas, The Pragmatic Programmers

Faça isso rápido

  • 1. Decida se vale a pena fazer, e se for:
  • 2. Faça rapidamente — Não perfeito. Apenas faça;
  • 3. Grave. Faça 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 decisão de que alguma coisa vale a pena fazer, normalmente está no ar no website algumas horas depois, com falhas mas lançado, deixando o feedback guiar o futuro dos refinamentos nele.

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


Encolha o seu tempo

Divida

As estimativas que se prolongam por semanas ou meses são fantasias. A verdade é que simplesmente não sabemos o que vai acontecer daqui tanto tempo à frente.

Por isso encolha seu tempo. Continue a interromper o seu cronograma em pedaços menores. Em vez de um projecto de 12 semanas, pense nele como 12 projectos semanais. Em vez de lidar com tarefas que levam 30 ou mais horas, divida-as em pedaços mais realistas de 6 a 10 horas. Então proceda, um passo de cada vez.

Aplica-se a mesma teoria também a outros problemas. Você está a enfrentar um problema tão grande que não cabe na sua cabeça? Divida. Continue a dividir os problemas em pedaços cada vez mais pequenos até que seja capaz de digeri-los.

Tarefas mais pequenas e cronogramas mais curtos

Os programadores são uma espécie especial de optimistas: quando apresentados a uma tarefa de programação, eles pensam, “Isto vai ser fácil! Não vai levar tanto tempo, afinal de contas”.

Dê três semanas a um programador para completar uma tarefa grande, e ele gastará duas semanas e meia a adiar, e apenas uma a programar. O atraso no cronograma provavelmente encontrará os requisitos errados, porque a tarefa se mostrou mais complexa do que parecia. Além disso, quem se lembrará do que ficou combinado entre a equipa três semanas antes?

Dê a um programador uma tarde para codificar um módulo pequeno, específico e ele vai devorá-lo, pronto para ir para o próximo.

As tarefas mais pequenas e cronogramas mais pequenos são mais geríveis, escondem menos requisitos mal percebidos e custam menos a mudar de ideias ou a refazer. Os cronogramas mais pequenos mantém os programadores mais envolvidos dá-lhes mais oportunidades para aproveitar uma sensação de conquista e menos razões para pensar, “oh, eu tenho tempo suficiente para fazer isso. Mas agora vou terminar de categorizar as minhas músicas no meu iTunes”.

—Gina Trapani, programadora web e editora da Lifehacker, o guia da produtividade e software

Factores Verdadeiros

Da próxima vez que alguém o pressionar para que dê uma resposta exacta a uma questão desconhecida — seja sobre uma data de entrega, o custo final do projecto ou o volume de leite que caberia no Grand Canyon — comece apenas por tirar o ar da sala: diga, "Não sei".

Esta resposta, em vez de prejudicar a sua credibilidade, demonstra o cuidado que você tem antes de tomar uma decisão. Você não está a falar apenas para parecer esperto. Isso também nivela o campo de jogo reformulando a questão como uma conversa colaborativa. Sabendo quão exacta a sua estimativa precisa de ser (e porquê), você pode trabalhar em conjunto para desenvolver um entendimento partilhado sobre os verdadeiros factores por trás dos números.

—Merlin Mann, criador e editor da 43folders.com

Resolve aquele problema que está à frente da tua cara

Em termos absolutos, o meu acontecimento favorito na web recente é o lançamento e adopção do atributo "nofollow" ("não prossiga"). Ninguém falou sobre isto de antes. Não houve conferências ou comités onde um bando de gente poderia debater a semântica ou natureza gramatical. Nenhuma RFC que poderia tornar uma ideia simples num pedaço de XML de 20 linhas que eu teria que ler de fio a pavio apenas para entender como o usar, e então não usar porque eu não teria certeza se estava formatado para a versão .3 ou 3.3b

É simples, é eficiente, forneceu uma opção às pessoas que queriam uma opção — e isso é muito mais importante ao lidar com uma população da web que não se importa com especificações ou deferências.

Algumas vezes resolver os próximos vinte problemas não é tão útil ou prudente quanto resolver aquele único que nos está a encarar mesmo de frente. Não foi apenas uma pequena vitória contra o SPAM (todas as vitórias contra SPAM são pequenas), mas uma vitória para aqueles de nós que apreciam os resultados simples e directos sobre ser um programador web.

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


A Organização capítulo 7

Unidade

Não divida em áreas funcionais

Muitas empresas separam o desenho, o desenvolvimento, a redacção, o suporte e o marketing em áreas isoladas. Enquanto a especialização tem suas vantagens, mas também cria uma situação em que os funcionários só vêem os seus próprios mundos em vez da aplicação web como um todo.

Integre a sua equipa ao máximo para que exista um diálogo contínuo em todas as etapas do processo. Faça um sistema de verificações e balanços. Não deixe que se percam coisas nas transcrições. Tenha redactores a trabalhar com os desenhadores. Faça com que os programadores tenham ciência dos pedidos de suporte.

Melhor ainda, contrate pessoas com múltiplos talentos, que podem actuar em diversas frentes. O resultado final será um produto mais harmonioso.



Tempo Sozinho

As pessoas precisam de períodos sem interrupções para terminar o trabalho

A 37signals está espalhada por quatro cidades e oito fusos horários. Desde Provo, no estado do Utah a Copenhaga, na Dinamarca, cinco de nós estamos separados por oito horas. Um dos efeitos positivos de se ter oito horas de diferença é o tempo em que podemos ficar sozinhos.

Apenas estamos a trabalhar juntos 4 a 5 horas por dia. Durante algumas horas, a equipa norte-americana está a dormir enquanto David, que está na Dinamarca, está a trabalhar. Nas horas restantes, estamos a trabalhar enquanto David está a dormir. Isso dá-nos 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 não é nenhuma surpresa. Muitas pessoas preferem trabalhar logo de manhãzinha ou tarde na noite – nas horas em que não são incomodados.

Quando se tem um longo período em que não se é incomodado, consegue-se concentrar. E concentrado-se é mais produtivo. É quando não se tem que dividir a cabeça com outros assuntos ou tarefas. É quando não se é interrompido para responder algo, ou procurar alguma coisa, ou enviar um e-mail, ou responder a mensagens instantâneas. O tempo sozinho é onde os progressos acontecem verdadeiramente.

Concentrar-se leva tempo. E é exactamente por isso que a interrupção é o seu maior inimigo. É como pegar no sono profundo – não se entra no sono profundo do nada, tem que se deitar, dormir e então entrar no sono profundo. Qualquer interrupção força-o a começar tudo de novo. O sono profundo é onde a magia do sono verdadeiramente acontece. A concentração é onde a magia da produtividade verdadeiramente acontece.

Estabeleça uma regra: faça com que metade do dia seja de horas onde você fica sozinho. Das 10 da manhã até às 2 da tarde, ninguém pode falar com ninguém (excepto durante o almoço). Ou então, faça com que a manhã ou a tarde seja o seu tempo para ficar sozinho. O importante é que o período seja contínuo para evitar interrupções que lhe matam a produtividade.

Um período de tempo sozinho significa largar o vício da comunicação. Durante o tempo em que ficar sozinho, esqueça as mensagens instantâneas, as ligações telefónicas, as reuniões. Evite qualquer conversa por e-mail que exija respostas imediatas. Em resumo: cale-se e trabalhe.

Concentrando-se

Todos sabemos que os profissionais sábios trabalham melhor entrando no “clima”, também designado por “ concentrar-se”, onde ficam totalmente concentrados nos seus trabalhos e completamente desligados dos seus ambientes. Eles perdem a noção do tempo e produzem muito mais através da concentração absoluta… o problema é que é muito fácil perder a concentração. Barulho, telefonemas, a saída para o almoço, ter que conduzir durante 5 minutos para comer uma tosta de queijo e as interrupções por colegas de trabalho – especialmente as interrupções por colegas—tudo o tira da zona de concentração. Se parar por 1 minuto para responder a uma pergunta de um colega de trabalho, e isso lhe tirar a concentração o suficiente para levar meia hora para voltar a ser produtivo novamente, a sua produtividade geral está com sérios problemas.

—Joel Spolsky, programador, Fog Creek Software
(de De Onde Essas Pessoas Tiram Essas ideias (Não Originais)?)


As reuniões são tóxicas

Não tenha reuniões

Precisa mesmo de reuniões? As reuniões geralmente acontecem quando um conceito não está suficientemente claro. Em vez de recorrer a uma reunião, tente simplificar o conceito, para que possa discuti-lo rapidamente por e-mail ou IM ou Campfire. O objectivo é evitar reuniões. Cada minuto que gastar numa reunião é um minuto durante o qual poderia estar a trabalhar.

Não existe nada mais tóxico à produtividade do que uma reunião. Aqui vão alguns motivos:

Nos casos em que as reuniões são realmente necessárias (faça disso um evento raro), siga estas regras simples:

Tenha menos reuniões

Existem muitas reuniões. Fazer reuniões que não fazem sentido é uma tarefa improdutiva. Só agende uma reunião quando tiver um assunto muito importante para discutir e quiser ou precisar de uma ideia, aprovação ou aval. Mesmo assim, resista heroicamente à tentação de convidar toda a gente – não desperdice o tempo das outras pessoas sem necessidade. —Lisa Haneberg, autora (de Não Deixe as Reuniões Ditarem as Regras!)

Quebre-as

Conforme o projecto cresce, o aumento de pessoas diminui a produtividade de cada uma. Uma das razões mais interessantes é o aumento do número de canais de comunicação. Duas pessoas podem falar entre si; é um canal de comunicação único. Três pessoas têm três canais de comunicação; 4 têm 6. Na verdade, o crescimento dos canais é exponencial… Logo, memorandos e reuniões vão acabar por consumir o tempo todo.

A solução é clara: divida as equipas em unidades pequenas, autónomas e independentes, para reduzir os canais de comunicação.

Da mesma forma, divida os programas em unidades pequenas. Uma grande parte do problema vem de dependências externas (variáveis globais, dados passados entre funções, hardware partilhado, etc…), encontre uma forma de dividir o programa para eliminar – ou minimizar – as dependências entre as unidades. The Ganssle Group (de Mantenha Pequeno)



Procure e celebre pequenas vitórias

Entregue alguma coisa hoje

A coisa mais importante no desenvolvimento de software é a motivação. A motivação é localizada—se não estiver motivado pelo que está a trabalhar neste momento, são grandes as hipóteses de que isso não saia muito bem. Na verdade, isso provavelmente vai ficar mal.

Os ciclos de entregas longos e demorados são assassinos de motivação. Eles introduzem muito tempo entre as comemorações. Por outro lado, as conquistas rápidas que pode comemorar são grandes motivadores. Se deixar que as entregas demorem a acontecer, estará a matar a motivação. E isso pode matar o produto.

Portanto, se você estáestiver no meio de um ciclo de entrega que demora meses, dedique um dia por semana (ou a cada duas semanas) para pequenas vitórias. Pergunte-se “o que podemos nós fazer e entregar em 4 horas?”. E então, faça isso. Este tipo de trabalho poderia ser ...

Quando conseguirem esta vitória de 4 horas, vai encontrar a comemoração. E isso constrói a moral, aumenta a motivação e assegura que a equipa está na direcção certa.



Contrataçõescapítulo 8

Contrate Menos e Contrate Mais Tarde

Adicione devagar para andar mais depressa

Não há necessidade de ficar logo grande – ou ao fim de algum tempo. Mesmo se tiver acesso às 100 melhores pessoas, não é bom tentar contratá-las todas de uma vez. Você não conseguirá fazer assim tanta gente assimilar a cultura da sua empresa. Terá problemas na formação, disputas pessoais, problemas de comunicação, pessoas a ir em direcções opostas e muito mais.

Portanto, não contrate. A sério, não contrate. Procure outra saída. O trabalho é assim tanto a ponto de realmente precisar de mais gente? Porque não o faz você mesmo? Consegue resolver o problema com algum software ou uma mudança nas práticas?

Sempre que Jack Welch, antigo CEO da GE, precisava de demitir alguém, ele não contratava alguém de imediato para a substituir. Ele queria ver por quanto tempo a GE poderia sobreviver sem aquela pessoa e sem aquele cargo. Claro, não estamos a incentivar ninguém a demitir pessoas para testar esta teoria, mas nós achamos que Jack acertou em alguma coisa: Você não precisa de tanta gente quanto você pensa.

Se não houver outra forma, então pense em contratar. Mas deve saber exactamente o que precisa, apresentar os candidatos ao trabalho e mostrar-lhes o tipo de sofrimento que quer que eles tenham.

Lei de Brooks

Adicionar pessoas a um projecto de software atrasado vai atrasá-lo ainda mais.

—Fred Brooks

A programação e o Requiem de Mozart

Um único bom programador a trabalhar numa única tarefa não tem excesso de coordenação ou comunicação. Cinco programadores a trabalhar na mesma tarefa precisam de se coordenar e de comunicar entre si. E isso toma imenso tempo… O problema em usar muitos programadores medianos em vez de alguns bons programadores é que, não importa o tempo que eles levem, o resultado nunca vai ser tão bom quanto o que os bons programadores vão produzir. Cinco Antonio Salieri’s não vão produzir um Requiem, de Mozart. Nem se trabalhassem 100 anos.

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


Dê pontapés aos pneus

Trabalhe com potenciais empregados na base do “teste antes”

Uma coisa é olhar para o portfólio, curriculum, exemplo de código ou trabalhos anteriores. Outra coisa é efectivamente trabalhar com alguém. Sempre que for possível, faça um “test-drive” com os potenciais novos membros da equipa.

Antes de contratar alguém, passe-lhe um pequeno projecto. Vamos ver como ele assume esse projecto, como ele comunica, como ele trabalha, etc. Trabalhar com alguém conforme ele faça o desenho ou codifique algumas páginas vai dar-lhe uma boa ideia sobre essa pessoa. Verá rapidamente se a pessoa é ou não o que precisa.

O tempo de trabalho para este projecto pode ser pequeno. Mesmo que sejam 20 ou 40 horas, é melhor do que nada. Se o tempo é ou não suficiente, isso tornar-se-á óbvio. Em todo caso, ambos os lados livrar-se-ão do risco e da dor de cabeça fazendo este teste antes.

Comece com pouco

Faça um pequeno teste no início. Não entregue à pessoa o trabalho todo de uma vez. Dê ao seu novo [assistente virtual] um ou outro projecto de teste e veja como a química se desenvolve. Neste início, é mais fácil de detectar problemas potenciais. Deixe bem claro de que este é um período de experiência.

—Suzanne Falter-Barns, autora/especialista em criatividade
(de Como Encontrar e Manter o Assistente Virtual Perfeito)


Acções, Não Palavras

Avalie as potenciais contratações de tecnologia em contribuições open source

O método tradicional de contratação para cargos técnicos—baseados em faculdades, curriculuns, etc. —é falível por diversas razões. Importa realmente onde é que a pessoa se formou ou as suas notas? Podemos confiar mesmo num curriculum ou indicação?

Open source é uma dádiva para aqueles que precisam contratar técnicos. Com o open source, pode-se verificar o trabalho e as contribuições de alguém—para o bem e para o mal—com algum tempo.

Isto significa que você pode julgar pessoas pelas suas acções em vez de apenas por palavras. Você pode tomar decisões com base no que realmente importa:

Quando falamos de programadores, nós só contratamos pessoas que conhecemos através do open source. Nós acreditamos que se adoptarmos qualquer outro método, estamos a ser irresponsáveis. Contratamos Jamis porque nós gostamos do software que ele publicou e da sua participação na comunidade Ruby. Ele superou-se em todas as áreas mencionadas acima. Não precisamos verificar mais nada, já que nós pudemos julgá-lo com base no que realmente importa: a qualidade do seu trabalho.

E não se preocupe se as actividades extra-curriculares roubarem o foco e a paixão do trabalho diário dos funcionários. Como diz aquele velho ditado: se quer algo feito, peça à pessoa mais ocupada que você conhece. O Jamis e o David são dois dos maiores contribuintes do Rails e ainda conseguem dirigir tecnicamente a 37signals. As pessoas que adoram programar e terminar seus projectos são exactamente o tipo de pessoa que você quer na sua equipa.

Paixão open source

O que você mais quer de um novo empregado é a paixão pelo que ele faz, e não há melhor forma de mostrar isso do que a pista de comprometimento em projectos open source.

—Jarkko Laine, desenvolvedor de software
(de Reduza o risco, contrate pessoas do open source)


Procure Indivíduos Equilibrados

Procure generalistas que aprendem rápido em vez dos especialistas limitados

Nunca contrataremos alguém que seja um arquitecto de informação. É simplesmente específico demais. Com uma equipa pequena como a nossa, não faz sentido contratar pessoas com um conjunto de conhecimento tão limitado.

As equipas pequenas precisam de pessoas que possam usar diferentes chapéus. Precisamos de desenhadores que saibam escrever. Precisamos de programadores que entendam de desenho. Todos devem ter noção de como arquitectar informação (seja lá o que isso for). Todos precisam de ter as suas mentes organizadas. Todos precisam de saber comunicar com clientes.

E todos precisam de querer e ser capazes de mudar de velocidade em andamento. Tenha em mente que as equipas pequenas precisam eventualmente de mudar de direcção rapidamente. Queremos alguém que possa ajustar-se, aprender e fluir ao contrário de alguém casmurro que só consegue fazer uma coisa.



Não se consegue falsificar o entusiasmo

Opte por alguém feliz e mediano em vez de alguém frustrado e grande

Entusiasmo. É um atributo que simplesmente não se pode falsificar. Quando chega a hora de contratar, não pense que precisa de um guru ou uma celebridade high-tech. Normalmente, de qualquer maneira essas pessoas são apenas divas. Um empregado mediano, mas feliz é melhor do que um perito que grunhe sózinho.

Encontre alguém entusiasmado. Alguém em quem possa confiar para fazer as coisas quando deixado sozinho. Alguém que sofreu numa empresa grande, devagar e deseja um novo ambiente. Alguém que está excitado para construir o que você está a construir. Alguém que odeia as mesmas coisas que você. Alguém que mal consegue esperar para apanhar o seu comboio.

Pontos extras por fazer perguntas

Observe se um candidato potencial faz muitas perguntas sobre seu projecto. Os programadores apaixonados querem entender um problema tão bem quanto possível e rapidamente irão propor soluções potenciais e melhorias, o que leva a muitas perguntas. As perguntas esclarecedoras também revelam um entendimento de que seu projecto poderia ser implementado de milhares de maneiras diferentes e é essencial detalhar o mais explicitamente possível como você imagina a sua aplicação web a funcionar. À medida que vai esgravatando os detalhes, desenvolverá um sentimento sobre se a pessoa é bem aculturada.

—Eric Stephens, BuildV1.com


Artesãos de Palavras

Contrate bons escritores

Se está a tentar decidir entre poucas pessoas para preencher uma posição, contrate sempre o melhor escritor. Não importa se essa pessoa é um desenhador, programador, marketing, vendedor ou o que for, essa habilidade leva a escrever mais efectivamente e concisamente o código, o desenho, os e-mails, as mensagens instantâneas, etc.

Isto porque ser um bom escritor é mais do que apenas gerir bem as palavras. Os bons escritores sabem como comunicar. Eles tornam as coisas mais fáceis de entender. Podem colocar-se no lugar dos outros. Eles sabem o que omitir. Eles pensam claramente. E essas são as qualidades de que você precisa.

Uma Mente Organizada

Boas capacidades de escrita são um bom indicador de uma mente organizada que é capaz de arranjar informação e argumentos de uma maneira sistemática e também ajudar (não fazer) as outras pessoas a entender as coisas. Isso aparece no código, na comunicação pessoal, nas mensagens instantâneas (para aqueles colaboradores de longa distância) e até esses nos conceitos esotéricos como o profissionalismo e a confiança.

—Dustin J. Mitchell, programador (de Signal vs. Noise)

Uma escrita clara leva a pensamento

Uma escrita clara leva a pensamentos claros. Você não sabe o que sabe até tentar expressar esse conhecimento. Uma boa escrita é em parte uma questão de carácter. Em vez de fazer o que é fácil para si, faça o que é mais fácil para seu leitor.

—Michael A. Covington, professor de ciências da computação da Universidade da Geórgia
(de Como Escrever mais Claramente, Pensar mais Claramente e aprender Material Complexo mais Facilmente)


O Desenho de Interfaces capítulo 9

Primeiro a Interface

Desenhe a interface antes de começar a programar

Muitas aplicações começam com a mentalidade de programar primeiro. Isso é uma má ideia. A programação é a componente mais pesada de construir numa aplicação, significando ser o mais caro e o mais difícil de mudar. Em vez disso, comece primeiro por desenhar.

Desenhar é relativamente leve. Um esboço de papel é barato e fácil de mudar. Rascunhos em HTML são ainda relativamente simples de modificar (ou deitar fora). Isso não é verdade na programação. Desenhar primeiro deixa-o flexível. Programar primeiro limita-o e gera custos adicionais.

Outra razão para projectar primeiro é que a interface é o seu produto. O que as pessoas vêem é o que você está a vender. Se apenas rabiscar uma interface no final, as falhas vão revelar-se.

Nós começamos pela interface para que possamos ver como a aplicação será desde o início. Este será constantemente revisto no decorrer do processo. Isso faz sentido? É fácil de usar? Ele resolve um problema de imediato? Existem perguntas às quais você só pode realmente responder quando estiver a lidar com páginas reais. Desenhar primeiro deixa-o flexível e leva-o a essas respostas no processo mais cedo do que mais tarde.

A Caneta Laranja que Iniciou Blinksale

Assim que eu passei a incomodar-me com a minha frustração com o software de cobranças comercial, decidi desenhar como eu gostaria que minha solução de cobrança funcionasse. Retirei uma caneta laranja, porque era a única à mão naquela noite e tive aproximadamente 75 por cento da UI desenhada em algumas horas. Mostrei-a à minha esposa, Rachel, que estava a passar a roupa no momento, e perguntei, “O que achas?” E ela respondeu com um sorriso, “Precisas de implementar isso. A sério.”

Nas duas semanas seguintes eu refinei o desenho, e criei quase todos os protótipos HTML estáticos para a primeira versão do que se tornaria Blinksale. Nós nunca fizemos wireframes além daqueles rabiscos de caneta laranja, e fazer logo o desenho em HTML ajudou-nos a ficar excitados sobre o quão/como “real” o projecto estava a tornar-se, mesmo que nós realmente não soubéssemos o que estávamos a começar.

Depois de terminados os protótipos do HTML, apresentámos ao nosso programador Scott a ideia para a Blinksale. Ter a maioria da Interface de Utilizador (UI, User Interface em inglês) projectada anteriormente foi extremamente benéfico a diversos níveis. Primeiro, demos ao Scott uma visão real e uma clarificação para onde nós iríamos. Era muito mais do que apenas uma ideia, era real. A seguir, ele ajudou-nos a medir exactamente quanto do esforço e tempo seria necessário para tornar o desenho/projecto numa aplicação que funcionasse. Quando estiver amarrado financeiramente a um projecto, quanto mais cedo puder prever melhor as exigências de orçamento. O projecto de UI tornou-se a nossa marca de nível para o âmbito inicial do projecto. Finalmente, o projecto do UI serviu como um guia para nos lembrar sobre o que a aplicação era quando progredíamos mais no desenvolvimento. Enquanto nos era tentador adicionar características novas, nós não poderíamos simplesmente dizer, “Ok, vamos adicionar isso!” Tivemos que voltar para trás ao projecto e perguntar-nos a nós mesmos para onde iria essa característica nova, e se não tivesse um lugar, não seria adicionada.

—Josh Williams, fundador, Blinksale


Desenho do Epicentro

Comece com o núcleo da página e construa para fora

O desenho do epicentro foca-se na verdadeira essência da página — o epicentro — e depois constrói para fora. Isto significa que, no início, ignoram-se as extremidades: a navegação/menus, o rodapé, as cores, a barra lateral, o logotipo, etc. Em vez disto, começa-se no epicentro e faz-se o desenho das peças de conteúdo mais importantes primeiro.

Seja qual for a página ela não pode viver sem o seu epicentro. Por exemplo, se estiver a fazer o desenho de uma página que mostra a publicação de um blog, a publicação por si é o epicentro. Não as categorias na barra lateral, não o cabeçalho no topo, não o formulário de comentários em baixo, mas a unidade de publicação de mensagem do blog. Sem essa unidade de publicação, a página não é a publicação de um blog.

É só quando esta unidade está completa que se começa a pensar no segundo elemento mais crítico da página. Então, depois desse segundo elemento mais crítico, abordaríamos o terceiro, e assim por diante. Isto é o desenho de epicentro.

O desenho de epicentro evita o tradicional modelo "vamos construir a moldura e depois mandar lá para dentro o conteúdo". Nesse processo, o formato da página é definido, depois a navegação é acrescentada, depois são inseridas as "coisas" de marketing e só então, finalmente, o núcleo da funcionalidade, o verdadeiro propósito da página, é enfiado num espaço qualquer que tenha sobrado. É um processo de trás para frente que tira o que deveria ser a prioridade principal e deixa isso para o fim.

O desenho de Epicentro altera esse processo e permite-lhe focalizar-se no que realmente interessa no primeiro dia. Primeiro as coisas essenciais, a seguir os extras. O resultado é uma página bem mais amigável, focada e utilizável para os clientes. Além disso, permite-lhe que comece o diálogo entre o desenhador e o programador logo ao início, em vez de esperar primeiro que todos os aspectos da página sejam definidos.



Solução de Três Estados

Desenhe para os estados regular, branco e erro

Para cada página, vai precisar de considerar três estados possíveis:

O estado regular é trivial. É a página onde se passa a maior parte do tempo. Mas não se esqueça de investir tempo nos outros estados também (veja os artigos seguintes para mais informação sobre esses estados).



A página em branco

Supere as expectativas com uma primeira experiência convincente

Ignorar o estado de superfície branca é um dos maiores erros que se pode cometer. O estado branco é a primeira impressão da sua aplicação e nunca terá uma segunda ... bem, você sabe.

O problema é que quando se faz o desenho da interface de utilizador, ela está normalmente preenchida com dados. Os desenhadores preenchem sempre os seus desenhos com dados. Cada lista, cada publicação, cada campo, cada canto e espaço tem dados. E isso significa que a página parece pronta e funciona muito bem.

No entanto, o estado natural da aplicação é sem de dados. Quando alguém se regista, eles começam com uma página em branco. Muito parecido com um diário na rede, cabe a eles preencherem — a aparência geral não toma forma até as pessoas colocarem os seus dados: publicações, ligações, comentários, horas, informação da barra lateral ou o que for.

Infelizmente, o cliente decide se a aplicação vale a pena pelo estado inicial da sua página em branco — o estado onde há a menor quantidade de informação, desenho e conteúdo sobre o qual julgar a utilidade geral da aplicação. Quando se falha no desenho adequado deste estado em branco, as pessoas não sabem o que estão a perder porque está tudo em falta.

Mesmo assim a maioria dos desenhadores e programadores ainda subestima esse estado. Eles falham em gastar tempo suficiente no desenho de páginas vazias porque quando eles desenvolvem/usam a aplicação, ela já está cheia de dados que eles colocaram para fazerem os testes. Eles nem sequer vêem a página em branco. Claro, eles podem entrar na aplicação como um novo utilizador algumas vezes, mas a maioria das vezes navegam na aplicação com as páginas cheias de dados.

O que se deve incluir numa página em branco que auxilie?

As primeiras impressões são fundamentais. Se falhar ao fazer o desenho de uma página em branco bem pensada, criará a impressão negativa (e falsa) da sua aplicação ou serviço.

Nunca se tem uma segunda oportunidade ...

Outro aspecto da interface do Mac OS X que acho que foi tremendamente influenciado por [Steve] Jobs é a configuração e a primeira experiência. Acho que Jobs sabe muito bem da importância das primeiras impressões ... Acho que Jobs olha para a primeira experiência e pensa, pode ser apenas um milionésimo da experiência geral de um utilizador com a máquina, mas é o milionésimo mais importante, porque é o primeiro milionésimo, e isso supera suas expectativas e as impressões iniciais.

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


Torne-se Defensivo

Desenhe para quando as coisas resultarem mal

Vamos admitir: on-line as coisa falham. Não importam todos os cuidados com que desenha a sua aplicação, não importam todos os testes que forem feitos, mesmo assim os clientes ainda vão encontrar problemas. Como se deve então gerir essas falhas inevitáveis? Com o desenho defensivo.

O desenho defensivo é como a condução defensiva. Da mesma maneira que os condutores devem estar mais atentos nas estradas escorregadias, aos condutores imprudentes e a outros cenários perigosos, os construtores de sítios devem procurar constantemente os possíveis pontos de problema que causem confusão e frustração aos visitantes. Um bom sítio defensivo pode abrilhantar ou desfazer a experiência de um cliente.

Podíamos encher um livro separado com todas as coisas que temos a dizer sobre desenho defensivo. De facto, já o fizemos. "Desenho Defensivo para a Web" é o título desse livro e é um grande recurso para qualquer um que queira aprender como melhorar páginas de erros e outros pontos críticos.

Lembre-se: a sua aplicação pode funcionar muito bem 90% do tempo. Mas se abandonar os seus clientes no momento em que eles mais precisam de si, é pouco provável que eles se esqueçam disso.



Contexto sobre consistência

O que faz sentido aqui pode não fazer sentido ali

As acções devem ser botões ou ligações? Depende da acção. O calendário deve ser visto em forma de lista ou numa grelha? Depende de onde ele será visto e quão longo é o período exibido. Todas as ligações de navegação global devem estar em todas as páginas? Precisa mesmo de um campo de pesquisa em todo o lado? Precisa do mesmo rodapé em cada página? A resposta é: “Depende”.

Isto porque o contexto é mais importante do que a consistência. A inconsistência até é aceitável se se o seu desenho fizer mais sentido dessa maneira. Dê às pessoas apenas o que é importante. Ofereça-lhes o que elas precisam e livre-se de tudo o que não for necessário. É melhor ser correcto do que ser consistente.

Inconsistência Inteligente

A consistência não é necessária. Durante muitos anos, os estudantes de Design foram ensinados que a consistência na interface é uma das regras-chave no desenho. Talvez isso sirva para o software, mas na Web, não é verdade. O que importa na Web é que, em cada página, os utilizadores possam fácil e rapidamente avançar para o próximo passo no processo.

Na Creative Good, nós chamamos a isso a “inconsistência inteligente”: a certeza de que cada página no processo dá ao utilizador precisamente o que eles precisam naquele ponto do processo. Adicionar elementos de navegação supérfluos, só porque são consistentes com o restante do sítio, é pura parvoíce.

—Mark Hurst, fundador da Creative Good e criador da Goovite.com
(de O Paradigma da Página)


O texto é desenho de interfaces

Cada palavra importa

O texto é desenho de Interfaces. As grandes interfaces são escritas. Se pensar que cada pixel, cada ícone, cada fonte importa, então é preciso que acredite que cada palavra importa. Quando está a escrever a sua interface, coloque-se sempre no lugar da pessoa que está a Lê-la. O que precisam eles de saber? Como o pode explicar sucinta e claramente?

Você etiqueta um botão como Submeter, Gravar, Actualizar, Novo ou Criar? Isso é texto. Escreve três frases ou cinco? Explica com exemplos gerais ou com detalhes? Etiqueta seu conteúdo como Novo, Actualizado, Actualizado Recentemente ou Modificado? Será Existem novas mensagens: 5 ou Existem 5 novas mensagens ou é 5 ou cinco ou mensagens ou publicações? Tudo isso importa.

É preciso que fale a mesma linguagem do que a sua audiência. Só porque está a escrevendo uma aplicação web não significa que pode sair por aí com calão técnico. Pense nos seus clientes e pense sobre o que para eles significam aqueles botões e palavras. Não use acrónimos ou palavras que a maioria das pessoas não entende. Não use linguagem interna. Não se pareça com um engenheiro a falar com outro engenheiro. Mantenha curto e doce. Diga o que precisa e não mais.

Uma boa escrita é bom desenho. É rara a excepção em que as palavras não acompanham o desenho. Ícones com nomes, campos de formulários com exemplos, botões com etiquetas, instruções passo a passo num processo, uma explicação clara das suas políticas de reembolso. Tudo isto é desenho de interface.



Uma Interface

Incorpore funções administrativas em interfaces públicas

As páginas administrativas — as páginas usadas para gerir as preferências, as pessoas, etc. — tem uma tendência para parecerem muito más. Isto porque a maioria do tempo de desenvolvimento é gasto na aparência pública das interfaces.

Para evitar a síndrome da página-administrativa-muito má, não construa páginas separadas para lidar com funções administrativas. Em vez disso, construa essas funções (isto é, editar, adicionar, apagar) na interface normal da aplicação.

Se tiver que manter duas interfaces separadas (isto é, uma para os utilizadores normais e outra para administradores), vão ambas sofrer. Com efeito, acaba por pagar a mesma taxa duas vezes. É forçado a repetir-se e isso significa que aumenta as hipóteses de ficar desleixado. Quanto menos páginas tiver, menos terá para se preocupar e melhor as coisas saem.

Sem Interface Separada

A aplicação é tudo. Qualquer coisa pode ser modificada, adicionada ou ajustada directamente através da área de gestão da aplicação. Isso permite-nos ver exactamente o que os nossos clientes vêem para ajudá-los através de qualquer problema ou questões que tiverem. E os nossos clientes não precisam se se preocupar a fazer login numa interface separada para fazer tarefas diferentes. Num minuto podem estar a lidar com compromissos para os seus clientes e no próximo minuto poderiam estar a adicionar um novo empregado. Eles não podem ser incomodados saltando entre aplicações diferentes, e mantendo a interface consistente eles são capazes de se adaptar à aplicação ainda mais rapidamente.

—Edward Knittel, Diretor de Vendas e Marketing , KennelSource


O código capítulo 10

Menos Software

Mantenha o seu código o mais simples possível

É bastante razoável pensar que um software com o dobro do código será duas vezes mais complexo. Mas na verdade, à medida que se aumenta a quantidade de código, a complexidade do software tende a crescer exponencialmente. Cada pequeno acrescento, cada nova interdependência, cada nova preferência amplia o efeito cascata. Adicione código desenfreadamente à sua aplicação, e antes que se aperceba, terá criado uma grande e desgovernada bola de neve.

A melhor maneira de se enfrentar a complexidade é com menos código. Menos software significa menos funcionalidades, menos código, menos desperdício.

A chave está em repensar qualquer problema difícil que venha a necessitar de uma grande quantidade de componentes para ser solucionado num problema mais fácil, que requeira muito menos. Você pode acabar por não solucionar exactamente o mesmo problema, mas tudo bem. Resolver 80% do problema original despendendo 20% do esforço é uma vitória e tanto. O problema original raramente é tão crítico de forma a realmente merecer cinco vezes mais esforço na sua solução.

Menos software é a melhor maneira para reformar a sua bola de cristal. Em vez de tentar prever problemas futuros, lida-se apenas com os problemas de hoje. Porquê? A maioria dos medos a respeito do futuro raramente se tornam reais. Não perca o seu tempo a tentar solucionar esses problemas eventuais.

Desde o início, desenvolvemos os nossos produtos à volta do conceito de pouco software. Sempre que possível, simplificamos os problemas mais difíceis. E descobrimos que a solução para os problemas mais simples não é somente mais fácil de implementar e suportar, como também de entender e usar. É tudo parte de uma estratégia para nos diferenciarmos dos competidores: em vez de nos focarmos em produtos que fazem mais, construímos produtos que fazem menos.

A escolha de quais funcionalidades deve incluir ou omitir também tem muito a ver com a quantidade de software. Não tenha medo de dizer não a solicitações de funcionalidades difíceis de se implementar. A menos que elas sejam absolutamente essenciais, economize tempo, esforço e muita confusão deixando-as de fora.

Vá devagar, também. Quando surgir uma nova ideia, não faça nada durante uma semana, e no fim veja se a ideia ainda parece tão brilhante. O tempo extra em “banho maria” ajudará geralmente o seu cérebro a pensar numa solução mais simples.

Encoraje os programadores a pensar em contra-propostas
O que se deseja ouvir é: “A implementação por si sugerida demorará 12 horas. Mas eu sei uma maneira de fazer o mesmo e que vai levar só uma hora. Não vai fazer x, mas vai fazer y.”. Deixe que o software lhe replique. Encoraje os programadores a lutarem pelo que eles pensam ser a melhor maneira.

Procure também alternativas a ter que escrever mais software. Seria possível mudar um fluxo de páginas de modo a que elas sugiram uma rota alternativa para os utilizadores que não necessite de alterações ao modelo do software? Por exemplo, seria possível sugerir que as pessoas façam carreguem imagens de um tamanho específico, em vez de ter que manipular as imagens no lado do servidor?

Para cada nova funcionalidade da sua aplicação, pergunte-se se não existe uma maneira de se produzir o mesmo resultado e que não necessite de tanto software. Escreva apenas o código que precisa, e nada mais. A sua aplicação acabará bem mais elegante e saudável.

NÃO existe código mais flexível que NENHUM código!

O “segredo” de um bom projecto de software não estava em saber o que codificar; estava em saber o que NÃO codificar. Estava em saber o que deixar de fora! Estava em perceber quais os pontos que necessitariam de mais flexibilidade e quais não, deixando então espaço para futuras mudanças, em vez de tentar expandir mais e mais o desenho.

—Brad Appleton, engenheiro de software
(de Não existe código mais flexível do que nenhum código!)

A complexidade não aumenta linearmente com o tamanho

A regra mais importante da engenharia de software é também a menos conhecida: a complexidade não cresce linearmente com o tamanho… Um programa de 2000 linhas requer mais do dobro do esforço de desenvolvimento que um programa com a metade do seu tamanho.

The Ganssle Group (de Mantenha Pequeno)


Optimize para Felicidade

Escolha ferramentas que estimulem e motivem a sua equipa

Um programador feliz é um programador produtivo. É por isso que nós optimizamos em felicidade e você deveria fazer o mesmo. Não escolha as ferramentas e práticas baseado-se simplesmente no padrão do mercado ou nas métricas de desempenho. Avalie os atributos intangíveis: a ferramenta foi criada com paixão, orgulho e dedicação? Você seria feliz trabalhando neste ambiente oito horas por dia?

Isto é especialmente importante quando você estiver a escolher uma linguagem de programação. Apesar da percepção do público sobre o contrário, elas não são criadas iguais. Enquanto qualquer linguagem pode produzir qualquer tipo de aplicação, as melhores para o caso não seriam somente possíveis ou aceitáveis, elas dariam prazer e seriam revigorantes a quem as utilizasse. É simplesmente tornar os pequenos detalhes do trabalho diário mais divertidos.

A felicidade tem um efeito em cascata. Os programadores felizes trabalham da maneira correcta. Eles escrevem um código simples e de fácil leitura. Abordam o problema de uma maneira elegante, expressiva e de fácil entendimento. Eles divertem-se.

Nós encontramos o ecstasy da programação na linguagem Ruby e passámo-lo para a frente através da nossa framework, Rails. Ambos compartilham do mesmo objectivo de optimizar para os humanos e para a sua felicidade. Nós aconselhamo-lo a dar uma hipótese a esta combinação.

Resumindo, a sua equipa necessita de trabalhar com ferramentas de que gostem. Nós citamos exemplos no contexto das linguagens de programação, mas o conceito aplica-se igualmente a aplicações, plataformas, e praticamente tudo o resto. Escolha a mistura que deixa as pessoas excitadas. Vai criar mais motivação e excitação e consequentemente um melhor resultado.

Os tipos de engenheiros que quer

O motivo número um de eu ter escolhido a Ruby on Rails para criar a nossa aplicação é a sua elegância, produtividade e a beleza de sua arquitectura. Ele tem a tendência de atrair o tipo de engenheiros que se preocupam com esse tipo de coisa… exactamente o tipo de engenheiros que se quer na nossa equipa, porque eles criam softwares atraentes, elegantes e produtivos de que você precisa para ganhar o mercado.

—Charles Jolley, Director Geral da Nisus Software (de Signal vs. Noise)


O Código Fala

Ouça quando o seu código lhe replica

Ouça o seu código. Ele oferecer-lhe-á sugestões. Ele irá replicar. Ele dir-lhe-á onde ficam as armadilhas. Ele irá sugerir-lhe novas maneiras de fazer as coisas. Ele irá ajudá-lo a manter-se num modelo de menos software.

Uma nova funcionalidade está a requer semanas de tempo e milhares de linhas de código? Isso é o seu código a dizer-lhe que provavelmente existe uma maneira melhor. Existe uma maneira simples de codificar alguma coisa numa hora em vez de uma maneira complicada que consumirá dez horas? Mais uma vez, isso é o seu código a guiá-lo. Ouça-o.

O seu código pode guiá-lo a correcções que são baratas e leves. Preste atenção quando aparece um caminho mais fácil. Claro, a funcionalidade que é fácil de fazer pode não ser exactamente a mesma que originalmente tinha em mente, mas e então? Se funciona suficientemente bem e dá-lhe mais tempo para trabalhar noutra coisa, já é bom.

Ouça

Não se preocupe com o desenho, se ouvir o seu código vai aparecer um bom desenho... Ouça as pessoas técnicas. Se eles estão a reclamar sobre a dificuldade de fazer as mudanças, então leve essas reclamações a sério e dê-lhes tempo para corrigir as coisas.

—Martin Fowler, Cientista Chefe, ThoughtWorks (de O Desenho está Morto?)

Se os Programadores Fossem Pagos para Remover Código ...

Se os programadores fossem pagos para remover código do software em vez de escrever novo código, seria muito melhor.

Nicholas Negroponte, Professor de Tecnologia de Média no MIT
(de História do resto da (Conferência AIGA))


Gira os Débitos

Pague ao seu código as "contas" de desenho

Normalmente pensamos em débito na forma de dinheiro mas ele vem noutras formas também. Pode facilmente construir código e débito de desenho.

Junte vários pedaços de código maus que funcionem mas ainda assim sejam relativamente complicados e estará a acumular débitos. Junte-lhe um desenho relativamente bom mas não suficientemente bom e endividar-se-á novamente.

Não há problema nenhum em fazer isso de vez em quando. De facto, às vezes é uma técnica necessária que o ajuda a chegar mais rapidamente ao esquema Caia-na-Realidade-RAPIDAMENTE. Mas ainda precisa de o reconhecer como débito e pagá-lo nalgum ponto limpando o código complicado ou redesenhando aquela página mais ou menos.

Da mesma forma que você deve regularmente colocar de lado uma parte do seu salário para impostos, coloque regularmente uma parte do seu tempo para pagar o seu código e débito de desenho. Se não fizer isso, estará apenas a pagar juros (corrigindo remendos) em vez de pagar o montante (e prosseguir para a frente).



Abra as Portas

Publique dados para o mundo via RSS, APIs, etc.

Não tente prender os seus utilizadores. Deixe-os ter acesso às suas informações quando quiserem, da forma que preferirem. Para tal, precisa de deixar de lado a ideia de manter os dados dos seus utilizadores fechados a sete chaves. Em vez disso, deixe que a informação flua. Garanta o acesso à informação através de feeds RSS. Ofereça APIs que permitam a terceiros construir aplicações integradas com a sua. Tais atitudes tornarão a vida dos utilizadores mais conveniente e expandirão as possibilidades daquilo que a sua aplicação é capaz de fazer.

No passado, as pessoas acostumaram-se a pensar nos feeds RSS apenas como uma boa maneira de se agregar conteúdo de sítios de diários na internet e sítios de notícias. Contudo, os feeds são mais poderosos que isto. Eles também podem permitir aos seus subscritores manterem-se actualizados sobre as mudanças internas à aplicação sem a necessidade de se registarem repetidas vezes. Através do sítio do Basecamp, por exemplo, o utilizador pode registar o seu endereço web num agregador de RSS e assim receber notificações de mensagens de projectos, listas de tarefas e marcos sem a necessidade de se ligar constantemente ao sítio à procura de informações actualizadas.

As APIs permitem que outros programadores construam plugins adicionais à sua aplicação, que geralmente acrescentam valor ao seu produto. Por exemplo, a API disponibilizada pelo Backpack foi utilizada pela Chipt Productions na construção de um widget para o Mac OS X. A pequena aplicação permite aos utilizadores adicionar e editar lembretes, listagens de itens e muito mais a partir dos seus computadores de secretária. Muitos utilizadores apontaram o widget como uma óptima ferramenta, e alguns mesmo apontaram-no como um factor decisivo na escolha da utilização do Backpack.

Outros bons exemplos de empresas que publicaram dados como uma maneira de conseguir um ‘efeito boomerang’:

Um Widget Faz a Diferença

Quando a 37signals lançou o Backpack, há algum tempo atrás, a minha primeira impressão foi… er, bem.

Resolvi dar uma segunda olhada ao sítio mais ou menos ao mesmo tempo em que a Chipt Productions lançava um widget Backpack para o Sistema Operativo Tiger — que parecia interessante demais para passar despercebido — com isso dei uma segunda olhada no Backpack. O resultado? Uma grande diferença.

Hoje, sempre que uma nova ideia surge, abro o widget, digito e gravo — e pronto. Recebo algum e-mail com algo que devo fazer? Abro o widget, digito, gravo — e pronto. O widget tornou-se um tipo de bloco de notas indispensável, que instalo em qualquer Mac que uso. E por se tratar de uma aplicação totalmente web, não há necessidade de nenhum tipo de controlo de versões ou sincronização de dados — apenas a fluidez de se digitarem dados sem ter que se preocupar em saber para onde os dados foram, nem como lhes aceder mais tarde.

—Todd Dominey, fundador, Dominey Design
(de Tentando Backpack)


As palavrascapítulo 11

Não Há Nada de Funcional numa Especificação Funcional

Não escreva documentos de especificação funcional

Estas verdadeiras “plantas baixas” de projecto geralmente acabam por descrever algo completamente diferente do produto final:

As especificações funcionais são mera fantasia

As especificações não reflectem a realidade. Uma aplicação não é real enquanto os seus programadores não começarem a construção; os seus projectistas começarem a traçar a arquitectura; os utilizadores começarem a testar e experimentar o produto.

As especificações funcionais são apenas palavras em papel

As especificações funcionais são apenas uma forma de acalentar os ânimos. Elas servem para fazer com que todos se sintam envolvidos e felizes com o projecto – e embora a sensação de segurança seja reconfortante, ela não trás nenhum benefício ao desenvolvimento. Estas especificações nunca tocam nos pontos mais críticos do projecto nem avaliam seus custos, factores que nunca devem ser esquecidos na construção de uma grande aplicação.

As especificações funcionais levam apenas à ilusão de um entendimento comum

O facto de um punhado de pessoas concordarem sobre alguns parágrafos de texto não implica dizer que todos chegaram a um entendimento comum: todos podem estar a ler o mesmo texto, mas a chegar a conclusões completamente diferentes. Estas diferenças aparecem inevitavelmente no decorrer do projecto: “Espere, não era isso que eu tinha entendido.” “Mhh? Não foi assim que nós descrevemos.” “Sim, foi isso que concordamos – você aprovou que fosse assim!”. Sabe do que falamos.

As especificações funcionais forçam a tomada das decisões mais importantes justamente quando se tem o mínimo de informações sobre o todo.

É normal saber-se pouco sobre qualquer coisa antes de começar a sua construção. Quanto mais se avança no projecto, quanto mais se usa o produto, mais se entende sobre ele. É neste ponto em que as decisões deveriam ser feitas – quando se tem informação suficiente, e não antes disso.

As especificações funcionais geram excesso de funcionalidades

Não há réplica durante a fase de especificação. Não há custo nenhum em adicionar mais um tópico a uma lista de requisitos. Pode-se agradar aos críticos mais chatos do projecto adicionando à especificação aquela “funcionalidade de estimação” que eles tanto gostariam de ver implementada. E no fim de contas, a equipa acabará por desenvolver uma aplicação que satisfará uma lista de requisitos numa folha de papel – não seres humanos. E assim acabará com um sítio sobrecarregado, com um milhão de abas, menus e opções espalhadas por uma página indecifrável.

As especificações funcionais não o deixarão evoluir, mudar ou rearranjar

Cada funcionalidade é acordada e aprovada. Mesmo que se perceba durante o desenvolvimento que se trata de uma má ideia, não há mais nada que possa ser feito. As especificações não ajudarão a lidar com a realidade quando o desenvolvimento começar, e tudo mudar de um instante para o outro.

Então o que deve ser feito em vez de uma especificação funcional? Comece por uma alternativa mais breve, que possa transformar-se mais rapidamente em algo real. Escreva uma página descrevendo o que a aplicação precisa de fazer. Use uma linguagem coloquial e faça isso sem gastar muito tempo. Se precisar de mais de uma página para explicar o conceito, é porque ele é provavelmente muito complexo. Este processo de “especificação” não deve tomar mais que um dia.

Comece então a construção da interface – ela será o substituto da sua especificação funcional. Desenhe alguns esboços rápidos em papel, começando a transformar o esboço em código html. Em vez de parágrafos de texto abertos à interpretação dos seus leitores, a interface da aplicação é um corpo comum, que tenta representar ao máximo a versão desejada da aplicação – sem interpretações subjectivas.

A confusão tende a desaparecer quando todos começam a usar as mesmas páginas. Construa uma interface que permita que todos naveguem, usem e “sintam” a aplicação antes mesmo de começar a preocupar-se com o código de back-end. Coloque-se na pele do utilizador o máximo possível.

Esqueça as especificações congeladas e imutáveis. Elas forçam a tomada de decisões importantes muito cedo no processo. Salte por cima da etapa de especificação funcional e mantenha o custo das mudanças em baixa e a flexibilidade em alta.

Especificações inúteis

Uma “especificação” é um documento quase que completamente inútil. Eu nunca vi uma especificação suficientemente detalhada para que seja útil e precisa ao mesmo tempo.

E eu já vi muito lixo construído com base em especificações. Desenvolver com base em especificações é a pior maneira de se escrever software, pois por definição, trata-se de programar para satisfazer uma teoria, não a realidade.

—Linus Torvalds, Criador do Linux (from: Linux: Linus Sobre Especificações)

Enfrente os “atrasadores de projecto”

Eu cheguei à conclusão de que muitas das pessoas que insistiam numa lista extensiva de requisitos antes de começar qualquer desenho tratavam-se de meros “atrasadores” tentando travar o processo (e que geralmente estas pessoas não tinham nada a contribuir nesse desenho, nem qualquer ideia inovadora para partilhar).

Todos os nossos melhores projectos foram feitos com alguns conceitos em mente sobre como melhorar um sítio web, seguidos de um protótipo rápido (estático), algumas mudanças de desenho, e finalmente a construção de um protótipo com dados reais. Depois de termos este protótipo a funcionar, geralmente tínhamos um projecto verdadeiro em movimento – e bons resultados.

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


Não Faça Documentos Mortos

Elimine a papelada desnecessária

Evitar especificações funcionais é um bom começo, mas não é tudo: é necessário evitar o excesso de papelada em todo o projecto. A menos que um documento vá efectivamente transformar-se em algo real, ele não deve ser escrito.

Construa, não escreva. Se precisar de explicar alguma coisa, tente construir um protótipo em vez de redigir um longo documento. Uma interface verdadeira ou um protótipo tende a seguir caminho em direcção a um produto real. Um punhado de folhas de papel, por sua vez, só pode seguir o caminho de um caixote do lixo.

Se um documento provavelmente nunca evoluirá para um desenho real, não se preocupe em escrevê-lo. Se o intuito de um documento é transformar-se num modelo, vá em frente.

Documentos que existem separadamente da aplicação são inúteis. Eles não levam a lado nenhum. Todos os esforços de projecto devem ser usados na evolução do produto real. Se um documento é congelado antes de se tornar uma peça real, ele está morto.

Ninguém nunca o irá ler

Eu nem sequer me consigo lembrar de quantas especificações ou documentos de requisitos de negócio foram chutados para canto, acumulando pó enquanto a minha equipa de desenvolvimento codificava, discutia problemas, fazia perguntas e conduzia testes de usabilidade ao longo de nossos projectos. Também já trabalhei com programadores que desperdiçaram horas escrevendo longos e minuciosos e-mails ou documentos de padrões de codificação que acabaram sempre por não ser lidos por ninguém.

Aa aplicações web não avançam graças a um grande punhado de documentos. O desenvolvimento de software é um processo em constante evolução e que envolve iterações e decisões rápidas, à medida que vão aparecendo no caminho problemas inesperados. Não é possível registar nada disso em folhas e folhas de papel.

Não desperdice o seu tempo a escrever aquele longo e visionário documento: ninguém o irá ler. Console-se com o facto de que, se o seu produto tiver o espaço suficiente para crescer adequadamente, no final ele nem de longe se parecerá com qualquer coisa que tenha escrito sobre ele.

—Gina Trapani, programadora web e editora do Lifehacker, o guia de produtividade e software


Conte-me uma História Curta

Escreva histórias, não detalhes

Sempre que faltarem palavras para explicar uma nova funcionalidade ou conceito, deve-se escrever uma pequena história sobre a ideia. Sem entrar em detalhes técnicos ou de desenho, a história deve ser escrita para humanos – como que em um diálogo qualquer com outras pessoas.

A história também não precisa ser um ensaio elaborado. Um punhado de orientações sobre o fluxo das coisas geralmente é suficiente. Ainda melhor se for possível contextualizar a história com um punhado de rascunhos de páginas.

Ao expressarem-se novos conceitos através de histórias, deve-se pensar na experiência, em vez de se perder em detalhes. Focar na estratégia, não na táctica. As tácticas aparecerão uma vez comece a construção da aplicação. Até aqui, tudo que se deseja é uma história capaz de iniciar uma discussão, e colocar o projecto na pista correcta.



Use Palavras Verdadeiras

Use texto verdadeiro em vez de lorem ipsum

O clássico Lorem ipsum dolor é um amigo fiel de muitos desenhadores. Textos falsos, “de enchimento”, ajudam a ter uma ideia de como ficará o desenho, uma vez finalizado. Mas a utilização de textos de enchimento pode ser perigosa, também.

O lorem ipsum muda a forma como o texto é visualizado no todo. Reduz o conteúdo textual do sítio a um mero elemento visual – uma “forma de texto” – em vez do que ele realmente deveria ser: informações valiosas que deverão ser lidas e/ou digitadas. A utilização de textos de enchimento acaba por esconder as inevitáveis variações que aparecerão quando forem utilizados dados reais. Dificulta a percepção de como o desenho realmente se comportará quando forem digitados dados reais. Os textos de enchimento são um abismo entre o desenho e a realidade.

São precisos dados reais para que se possa definir o tamanho ou forma de certos campos. São precisos dados reais para perceber como é que as tabelas se irão expandir ou contrair. São precisos dados reais para visualizar a aplicação.

Devem usar-se palavras relevantes o mais cedo possível. Se o sítio requerer entrada de dados, devem ser fornecidos dados reais. Mais do que isso, os dados devem ser realmente digitados – e não apenas copiados e colados de outra fonte. Se o sistema solicitar um nome, utilize um nome verdadeiro. Se solicitar uma cidade, utilize uma cidade existente. Se solicitar a digitação de uma senha e a sua confirmação, digite-a duas vezes.

Claro que é muito mais fácil percorrer todos os formulários e preencher os campos com lixo (“asdsadklja” “123usadfjasld” “snaxn2q9e7”), de forma a percorrê-los rapidamente. Mas estes dados não são reais. Não é isso que os clientes farão. Não é sábio testar o sistema através de um atalho, enquanto os utilizadores serão forçados a tomar o caminho mais longo. Quando apenas se digitam dados falsos com a velocidade de uma metralhadora, perde-se a percepção de como realmente se preenchem tais formulários.

Fazer como os utilizadores fariam é uma maneira de entendê-los melhor. E depois de os entender, depois de sentir o que os utilizadores sentem, a sua equipa construirá uma interface melhor.

Lorem Ipsum Lixum

Quando o desenho deixa de levar em consideração como o conteúdo do sítio “deveria ser”, o impacto sobre o resultado final é grande. O significado das páginas perde-se por ser “apenas texto”; o entendimento é comprometido por ninguém perceber que o tal texto deve estar ali supostamente para ser lido. Perdem-se oportunidades porque o texto lorem ipsum usado no lugar de texto real não sugere novas oportunidades ou funcionalidades. E se o texto é tão desnecessário e não está ali para ser usado, então podemos apenas substituí-lo por um adorável espaço em branco.

—Tom Smith, desenhador e programador (de Eu Odeio Lorem Ipsum e Utilizadores Lorem Ipsum)


Dê Personalidade ao Seu Produto

Qual o tipo de personalidade do seu produto?

Os produtos devem ser pensados como se fossem pessoas. Que tipo de pessoa o seu produto deve ser? Educada? Divertida? Séria? Relaxada? É melhor que ela seja lembrada como uma aplicação confiável ou excessivamente segura? As a know-it-all? Modesta? Simpática?

Uma vez decidida a personalidade da aplicação, tais características devem ser sempre lembradas durante a construção do produto. Elas devem ser usadas para guiar a construção da interface, a escolha das funcionalidades e até mesmo o texto de copyright. Sempre que qualquer mudança for feita à aplicação, deve-se pensar primeiro se tal mudança se adequa à personalidade da aplicação.

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



Precificação e Assinatura capítulo 12

Amostra Grátis

Dê alguma coisa de graça

É um mundo barulhento lá fora. Para que as pessoas o notem no meio da multidão, dê alguma coisa de graça.

Empresas espertas sabem que dar brindes é uma excelente maneira de fisgar clientes. Veja a Apple. Eles oferecem o software iTunes de graça de forma a gerar demanda para o iPod e a loja de música 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 dão aos clientes. Nada mau.

Para nós, Writeboard e Ta-da list são aplicativos completamente grátis que usamos para colocar as pessoas no caminho para usar nossos outros produtos. Também, sempre oferecemos algum tipo de versão grátis de todos os nossos aplicativos.

Queremos que as pessoas experimentem o produto, a interface, a utilidade do que construímos. Uma vez fisgados, eles são muito mais propensos a atualizar para um dos planos pagos (que permitem mais projectos ou páginas e dá acesso a funcionalidades adicionais como upload de arquivos e encriptação de dados com SSL).

Pedacinhos

Faça pedacinhos: crie ofertas especializadas, pequenas para que os clientes mordam. Resolva sub-dividir pelo menos um produto ou serviço em pedacinhos que são baratos, fáceis ou divertidos.

—Ben McConnell e Jackie Huba, autores do Blog da Igreja dos Clientes
(de O que é Evangelismo do Cliente?)

Dê Sua Música de Maior Sucesso

Considere dar uma de suas músicas (por álbum) como download gratuito promocional para o mundo – para ser como um trailer de cinema – como o single de sucesso enviado ao rádio – a música que faz as pessoas quererem comprar sua música.

Não se preocupe com pirataria dessa música. Deixe as pessoas tocar, copiar, compartilhar, dar. Tenha a confiança que se o mundo a ouviu, irão pagar por mais.

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


Vem Fácil, Vai Fácil

Torne assinatura e cancelamento processos indolores

Torne simples o processo de entrar – e sair – de seu aplicativo.

Se eu sou um cliente que quer usar seu aplicativo, deve ser um processo indolor e óbvio. Providencie um botão de assinatura grande, claro, que pula e o coloque em cada página do seu website de marketing. Anuncie às pessoas como é fácil: “Da assinatura ao login em apenas 1 minuto!”

Sempre deve existir uma opção grátis para que os clientes possam experimentar o aplicativo sem entrar com informações de cartão de crédito. Alguns de nossos competidores requerem uma ligação de retorno, um compromisso, ou uma senha especial para poder experimentar seus produtos. Qual é o problema disso? Nós deixamos qualquer um experimentar nossos aplicativos de graça a qualquer hora.

Mantenha o formulário de assinatura o mais curto possível. Não pergunte coisas que não precisa e não jogue um longo e assustador formulário nas pessoas.

Os mesmos princípios permanecem verdadeiros para o processo de cancelamento. Não 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 tão claro quanto o dia na página da conta da pessoa. Não deve existir nenhum e-mail a ser enviado, formulário especial a ser preenchido ou questões a serem respondidas.

E também garanta que as pessoas possam levar seus dados se decidirem sair. Nós garantimos que os clientes possam facilmente exportar todas as mensagens e comentários em formato XML a qualquer momento. São seus dados e eles devem poder fazer com eles o que quiserem.

Isso é crucial porque dar às pessoas o controle de suas próprias informações constrói confiança. Estamos lhes dando uma ponte para suas ilhas de dados. Permitimos que saiam sem nenhum prejuízo se encontrarem uma oferta melhor. É a coisa certa a se fazer e isso constrói boa vontade.

Sair com Facilidade

Não segure utilizadores contra suas vontades. Se querem sair, deixe-os pegar todo o conteúdo que criaram enquanto estiveram no seu website e sair … de graça … 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 Dez Passos para uma Empresa Web 2.0 de Imenso Sucesso)


Coelho Bobinho, Truques são para Crianças

Evite contratos de longa duração, taxas de assinatura, etc.

Ninguém gosta de contratos de longa duração, taxas de cancelamento ou cobranças para abertura de conta. Então, evite tais cobranças. Nosso produto é cobrando na forma de assinatura mensal. Não existe contrato de tempo mínimo de utilização e pode-se cancelar a assinatura a qualquer momento, sem penalidades. E não existem, nunca, quaisquer taxas de adesão.

Não tente encontrar modos “alternativos” de conseguir mais dinheiro. Faça por merecê-lo.



Batendo de Leve

Reduza o impacto das más notícias com avisos prévios e tratamento privilegiado

Você precisa divulgar uma má notícia aos utilizadores – como um aumento de preços? Faça o anúncio o mais indolor possível, dando aos utilizadores um aviso prévio. Também considere a possibilidade de um período de bônus, isentando utilizadores antigos por um certo período de tempo. Estes utilizadores são seu ganha-pão, é seu interesse fazê-los sentir-se valorizados, não explorados.



Promoção capítulo 13

Lançamento de Hollywood

Vá de Trailer para a Prévia para o Lançamento

Se uma aplicação é lançada numa floresta e não há ninguém lá para usá-la, ela faz barulho? O ponto aqui é que se fazemos o lançamento da nossa aplicação sem nenhum tipo de anúncio antecipado, as pessoas não saberão sobre ela.

Para construir euforia e antecipação, vá com um lançamento holywoodiano: 1) Trailer, 2) Prévia e 3) Lançamento.

Trailer

Alguns meses antes do tempo, comece soltando dicas. Faça as pessoas saberem no que está trabalhando. Publique um logotipo. Publique sobre o desenvolvimento no seu blog. Mantenha-se vago mas plante a semente. Além disso levante um website onde poderá coletar e-mails das pessoas que estão interessadas.

Nesse estágio, devemos começar a seduzir gurus e insiders. Essas são as pessoas que estão à frente. São os formadores de opini3;o. Apele para suas vaidades e status como pontos-fora-da-curva. Lhes diga que estão tendo uma breve prévia exclusiva. Se um site como Boing Boing, Slashdot ou Digg criam links para sua aplicação, terá um monte de tráfego e seguidores. Mais ainda, seu page rank no Google subirá também.

Prévia

Algumas semanas antes do lançamento, comece a demonstrar funcionalidades. Dê acesso por-trás-das-câmeras às pessoas. Descreva o tema do produto. Para o Basecamp, publicamos fotos de tela e marcamos os alertas, milestones e outras funcionalidades.

Também diga às pessoas sobre as ideias e princípios por trás da aplicação. Para o Backpack, publicamos nosso manifesto antes do lançamento. Isso levou as pessoas a pensarem e falarem sobre a aplicação.

Também podemos oferecer algum tipo de “ingresso especial” para algumas poucas pessoas para que possam começar usar a aplicação antes do tempo. Ainda ganhamos o benefício de ter pessoas testando como beta enquanto elas sentirão aquele brilho especial que todos de vanguarda sentem.

E novamente, encoraje as pessoas a se cadastrarem para termos uma fundação de e-mails para usar no lançamento. Quando lançarmos nossa aplicação, teremos milhares de e-mails para pingar o que é uma grande ajuda para ganhar tração.

Lançamento

É hora do lançamento. Agora as pessoas podem realmente ir ao “cinema” e ver nossa aplicação. Envie e-mails para aqueles que se cadastraram. Lance seu site de marketing completo. Espalhe a palavra tanto quanto possível. Faça blogs criarem links para você. Publique sobre seu progresso: quantas pessoas se cadastraram? Que atualizações/refinamentos foram feitas? Mostre momentum e mantenha-se nele.

A Estrada para o Dia do Lançamento

Tão logo soubemos que Blinksale iria acontecer, começamos a soltar alguns trailers em nossa lista de e-mails. Essas eram as pessoas que pediram para receber informação de nós sobre nosso projecto. Esses são nossos fãs, se quiser chamar assim. Se você já tem permissão para falar para um grupo de pessoas, esse é o melhor lugar para começar.

A segunda coisa que fizemos foi conseguir permissão para falar a mais pessoas sobre nosso produto. Umas seis semanas antes do lançamento do Blinksale pusemos uma página de trailer em nosso site que proclamava a chegada de uma maneira mais fácil de enviar faturas online. A página dava informação apenas suficiente para construir excitação e suspense, sem entregar detalhes sensíveis que precisavam se manter confidenciais. Prominentemente mostrado na página estava um formulário de cadastro para um newsletter, pedindo não mais do que um e-mail (mantenha-se simples) para que os interessados pudessem ser notificados quando o produto fosse lançado.

Espalhamos a palavra para cerca de uma dúzia de amigos e colegas que achamos que se interessaríam pelo produto e eles começaram a espalhar a palavra sobre a página de trailer através 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 lançaríamos.

Finalmente, cerca de duas semanas antes do lançamento, convidamos vários amigos, colegas e gurus da indústria 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 lançássemos. É importante notar que não forçamos ninguém a escrever sobre o produto. Simplesmente queríamos que fosse visto e que falassem sobre ele quando fosse lançado. No fim, se você for construir euforia dessa maneira, é melhor ter certeza que seu produto faz o que diz. Caso contrário, é como nuvens sem chuva.

Quando o dia do lançamento chegou, enviamos e-mails para nossa lista de e-mails, notificamos nossos amigos dos blogs e encorajamos o pessoal do teste beta a falar o que realmente acharam. E para nossa grande alegria, o esforço pagou grandes dividendos. Logo depois do lançamento 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 Prévia para o Lançamento

A melhor ferramenta promocional é um grande produto. A palavra vai se espalhar se tivermos uma aplicação que as pessoas acham realmente útil.

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



Cavalgue pela Onda dos Blogs

Blogar pode ser mais efetivo do que propaganda (e é muito mais barato)

Propaganda é caro. E calcular a eficácia de vários tipos de propaganda pode acabar sendo ainda mais caro do que a propaganda em si. Quando não tiver o tempo ou o dinheiro para ir pela rota tradicional de propaganda, em vez disso considere a promoção-via-blog.

Comece criando um blog que não 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 graças aos pedaços que ajudam, informam e são interessantes e às anedotas que publicamos quase diariamente.

Então, quando chegou a hora de promover nosso primeiro produto, Basecamp, começamos lá. Liberamos a palavra sobre o SvN e ela começou 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 fluíram.

Ta-da Lists é outro grande exemplo do poder do marketing baseado em blogs. Lançamos Ta-da com uma única publicação 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 próprias contas Ta-da. Palavra sobre Backpack se espalhou ainda mais rápido. Dentro de 24 horas do lançamento, mais de 10 mil haviam se cadastrado.



Solicite Antecipadamente

Consiga euforia antecipada e cadastros acontecendo o mais rápidos possível

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 possível. Pegue seu nome de domínio e coloque um logotipo e talvez uma sentença ou duas que descreva, ou pelo menos dê dicas sobre, o que sua aplicação fará. Então deixe as pessoas lhes darem seus endereços de e-mail. Agora você está no caminho de ter uma fundação de pessoas prontas e esperando para serem notificadas no seu lançamento.



Promova Através da Educação

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 profissão”. 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 aplicação, ela serve um duplo propósito: Você pode dar alguma coisa de volta à comunidade que o suporta e marcar uma boa exposição promocional ao mesmo tempo.

Como uma técnica de promoção, educação é um jeito sutil de ter seu nome – e o nome de seu produto – na frente de mais pessoas. E em vez de uma aproximação dura de vendas do tipo “compre este produto”, você está conseguindo atenção fornecendo um serviço de valor. Isso cria euforia positiva que técnicas tradicionais de marketing não conseguem igualar. Pessoas que você educa se tornarão seus evangelistas.

Educação pode vir de diversas formas. Publique dicas e truques no seu site que as pessoas irão querer compartilhar com os outros. Fale em conferências e fique até depois para se encontrar e agradecer os participantes. Conduza sessões práticas de demonstração para que fãs curiosos possam aprender mais e falar com você ao vivo. Dê entrevistas para publicações. Escreva artigos que compartilhem informações úteis. E escreva livros. ;)

Um exemplo de nossa própria história é a Técnica do Amarelo que Desvanesce, um método que inventamos para sutilmente iluminar uma área que recentemente mudamos em nossa página. Escrevemos uma publicação sobre isso na Signal vs. Noise. Essa publicação circulou e trouxe milhares e milhares de visitas à página (até hoje está fazendo um grande tráfego).

A publicação funcionou tanto no nível educacional quanto promocional. Uma lição 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 código aberto. Acabou sendo um movimento sábio. Demos alguma coisa de volta à comunidade, construímos boa vontade, ganhamos reconhecimento para nossa equipe, recebemos respostas úteis e começamos a receber correções e contribuições de programadores por todo o mundo.

Ensinar tem tudo a ver com bom karma. Pagamos antecipadamente. Ajudamos os outros. Ganhamos alguma promoção saudável. E podemos até mesmo nos sentir mais nobres. Portanto, o que você sabe que o mundo gostaria de ouvir?

Pague Antecipadamente

A seção 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 máximo de nosso software. Se eles podem fornecer um serviço melhor a seus clientes, é mais provável que tenham mais negócios, que por sua vez cria mais negócios para nós – todos ganham.

Dividir gratuitamente nosso conhecimento também ajuda a nos posicionar como especialistas na indústria e reforça nossos relacionamentos com os clientes atuais. Eles sabem que nos importamos sobre qualidade do nosso trabalho. Finalmente, recebemos montanhas de tráfego direcionado a partir de sites de pesquisa e bloggers que dividem nossos artigos com seus leitores. Essas são pessoas que nunca teriam ouvido falar de nosso software se não tivéssesmos escrito esse artigo.

—David Greiner, fundador, Campaign Monitor


Comida-Funcionalidade

Eles estão famintos por isso então sirva-os

Funcionalidades novas ou interessantes são uma grande maneira de gerar euforia para sua aplicação. Grupos de interesse especiais amam mastigar “comida de funcionalidade” e cuspir de volta à comunidade. Tudo bem, essa foi uma analogia não muito boa mas você entendeu o ponto.

Por exemplo, usando Ruby on Rails, uma nova plataforma de desenvolvimento, geramos uma tonelada de atenção para o Basecampo dentro da comunidade de desenvolvedores.

Os elementos Ajax que usamos em nossa aplicação recebeu montanhas de euforia e até mesmo levou a revista Business 2.0 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 negócios com RSS.

Integração com iCal, uma funcionalidade menor à primeira vista, nos levou às notícias em uma tonelada de sites relacionados a Mac, que caso contrário provavelmente nunca teriam mencionado nossa aplicação.

Equipes pequenas tem uma perna maior na integração de novas ideias com software. Enquanto grandes empresas precisam lidar com afunilamentos de burocracia, podemos rapidamente implementar novas ideias e ganhar atenção 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, não vá adicionando a mais recente e obscura tecnologia apenas para ganhar mais atenção. Mas se estiver usando alguma coisa nova e merecedora de atenção, 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 estão quentes na sua trilha?

Descubra e então faça sua presença ser sentida. Deixe comentários nesses blogs. Agradeça as pessoas por publicarem links. Pergunte se eles querem ser adicionados à sua lista avançada especial para que estejam entre os primeiros a saber sobre lançamentos futuros, atualizações, etc. Colete elogios e crie uma página de “euforia” no seu site. Testemunhos são uma grande maneira de promover sua aplicação uma vez que elogios dos outros é mais confiável para a maioria das pessoas.

Se os comentários são negativos, ainda assim preste atenção. Mostre que está ouvindo. Responda às críticas com reflexão. Algo do tipo: “Agradecemos as opiniões mas fizemos dessa forma porque ..” ou “Você levantou um ponto importante e estamos trabalhando nisso”. Você irá amaciar a crítica e colocar um rosto humano em seu produto. É incrível como um comentário bem refletido em um blog pode dissolver pessoas negativas e mesmo transformar quem reclamava em evangelistas.



Vendas Internas Pró-Ativas

Promova oportunidades de atualização dentro de sua aplicação

Todo mundo sabe ser agudo no site de marketing. Mas as vendas não devem parar lá. Se tiver um plano de preços por níveis (ou uma versão livre de sua aplicação), não se esqueça de chamar para oportunidades de atualização de dentro do produto.

Diga as pessoas que você removerá as barreiras se atualizarem. Por exemplo, no Basecampo não se pode enviar arquivos se tiver uma conta grátis. Quando alguém tentar enviar um arquivo, não simplesmente negamos. Explicamos porque o envio de arquivos não está disponível e os encorajamos a atualizar para uma versão paga além de explicar porque essa é uma boa ideia. A mesma aproximação é usada para encorajar clientes já existentes a atualizar para uma conta de nível maior quando chegam ao máximo de seu plano atual.

Clientes existentes são suas melhores apostas de vendas. Não se sinta envergonhado em tentar repetir negócios com pessoas que já conhecem e usam seus produtos.



Nome-Gancho

Dê um nome à sua aplicação que seja fácil de lembrar

Um grande erro que muitas pessoas fazem é pensar que o nome de sua aplicação precisa ser ultra-descritiva. Não se preocupe em escolher um nome que vividamente descreva o propósito de sua ferramenta; isso normalmente leva apenas a um nome genérico e esquecível. Basecamp é um nome melhor do que algo como Centro de Gerenciamento de Projetos ou ProjectExpress. Writeboard é melhor do que CollaborEdit.

Além disso, não foque muito em grupos ou comitês para o processo de nomeação. Escolha um nome curto, que pegue, seja memorável e então vá com ele.

E não se preocupe se não conseguir o nome de domínio exato que quer. Você sempre pode ser criativo e chegar perto com um pouco mais de letras (ex. backpackit.com ou campfirenow.com).

Fácil é o Melhor

Será que a indústria de tecnologia não percebe que pensar em nomes que peguem e que sejam auto-explicativos os beneficiariam da mesma maneira em última instância? Eles venderiam mais do que quer que seja, porque não assustariam os consumidores que pensam que estão sendo mantidos fora do club high-tech por um punhado de engenheiros arrogantes. A tecnologia avançaria mais rápido também. O novo produto seria mais fácil de descrever, mais fácil de usar e mais fácil de comprar – o que, para as empresas, significa mais fácil de vender.

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


Suporte capítulo 14

Sinta a Dor

Derrube as paredes entre suporte e desenvolvimento

No negócio de restaurantes, existe um mundo de diferença entre aqueles que trabalham na cozinha daqueles que estão na linha de frente lidando com clientes. É importante para ambos os lados entender e empatizar com o outro. É por isso que escolas de culinária e restaurantes normalmente terão chefs trabalhando como garçons para que a equipe da cozinha possa interagir com clientes e ver como é realmente estar na linha de frente.

Muitos desenvolvedores de software tem uma divisão 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 é problemático porque ouvir clientes é a melhor maneira de se ligar nas partes fortes e fracas do seu produto.

A solução? Evite construir paredes entre seus clientes e a equipe de desenvolvimento/design. Não faça outsource do suporte ao cliente a um call center de terceiros. Faça isso você mesmo. Você, e sua equipe inteira, devem saber o que seu cliente está dizendo. Quando seu cliente está incomodado, você precisa saber disso. Precisa ouvir suas reclamações. Você precisa ficar incomodado também.

Na 37signals, todos os nossos e-mails de suporte são respondidos pessoalmente pelo pessoal que realmente construiu o produto. Por que? Primeiro, isso fornece melhor suporte aos clientes. Eles estão recebendo uma resposta directamente do cérebro de alguém que construiu a aplicação. Além disso, isso nos mantém em contacto com a pessoa que usa nossos produtos e os problemas que estão encontrando. Quando estão frustrados, nós ficamos frustrados. Podemos dizer sinceramente, “eu sinto a dor” .

Pode ser tentador se apoiar em análises estatísticas para revelar seus pontos de problema. Mas estatísticas não são as mesmas vozes. Você precisa eliminar a maior quantidade de acumuladores possível entre você e as vozes reais de seus clientes.

As linhas de frente são onde a ação está. Vá até lá. Faça seus chefs trabalharem como garçons. Leia e-mails de clientes, ouça suas frustrações, escute suas sugestões e aprenda delas.

Corte o Homem do Meio

Quase todo desenvolvimento do Campaign Monitor, suporte e marketing são feitos por duas pessoas. Mesmo que fôssemos forçados a expandir a equipe, nunca separaríamos suporte do desenvolvimento. Quando respondemos pessoalmente cada requisição, nos forçamos a nos colocar no lugar de nossos clientes e vemos as coisas de sua perspectiva.

É importante entender porque seus clientes precisam de alguma coisa, não apenas do que eles precisam. Esse contexto normalmente tem um impacto direto em como desenhamos alguma coisa. Corte o homem do meio. É muito mais fácil dar a seus clientes o que querem quando seus ouvidos estão perto do chão.

Discuti essa configuração com muitas pessoas e a primeira resposta normalmente é “você não deveria contratar um júnior 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 realmente irá cozinhá-lo?

—David Greiner, fundador, Campaign Monitor


Treinamento Zero

Use ajuda em contexto e FAQs para que seu produto não precise de um manual ou treinamento

Você não precisa de um manual para usar o Yahoo ou Google ou Amazon. Então por que você não pode construir um produto que não requer manual? Se esforce para construir uma ferramenta que requer treinamento zero.

Como fazer isso? Bem, como mencionamos antes, você começa mantendo tudo simples. Quanto menos complexo for sua aplicação, menos precisará ajudar as pessoas desnecessariamente. Depois disso, uma grande maneira de suporte pró-ativo é usando ajuda em contexto e faqs em potenciais pontos de confusão.

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. Então, próxima à área de “envie seu logotipo”, adicionamos um link a um faq que instruía os clientes a forçar um recarregamento de seus browsers para ver o novo logotipo. Antes de fazermos isso recebíamos 5 e-mails por dia sobre esse problema. Agora não recebemos nenhum.



Resposta Rápida

Tempo rápido de atendimento em consultas de suporte devem ser prioridade máxima

Os clientes se alegram quando você responde suas questões rapidamente. Eles estão tão 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 horário comercial, respondemos 90% de nossos e-mails de requisição de suporte dentro de 90 minutos – e normalmente dentro de meia hora. E as pessoas amam isso.

Mesmo que não tenha uma resposta perfeita, diga alguma coisa. Você pode comprar boa vontade com uma resposta entregue rapidamente de forma aberta, honesta. Se alguém está reclamando sobre um problema que não pode ser consertado imediatamente, diga algo como “ouvimos o que está dizendo e estaremos trabalhando nisso no futuro”. É uma grande maneira de diluir uma situação potencialmente negativa.

Clientes gostam de coisas diretas e normalmente mudam de irritados para calmos se responder rapidamente e de maneira direta.

Um Exército de Muitos

Como pode uma equipe pequena de apenas três desenvolvedores criar um produto inovador e competir com sucesso com os caras grandes? A resposta é alistar um exército de muitos.

Lembre no seu primeiro dia que seus clientes são seu patrimônio mais importante e que são absolutamente vitais para o sucesso de longo prazo portanto trate sua comunidade de utilizadores como a realeza. A maneira de competir com os caras grandes é começando pequeno e prestando atenção 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 não foram cumpridas e são seus primeiros clientes que carregarão a bandeira e espalharão sua mensagem.

Isso não significa que seu produto tenha que ser perfeito quando for lançado. Muito pelo contrário, lance cedo e freqüentemente. Entretanto, quando seus clientes encontrarem bugs, garanta o envio de uma resposta rápida agradecendo pela sua informação.

Os clientes não esperam que seu produto seja perfeito e não esperam que todas as suas funcionalidades serão 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). Também temos um fórum online e garantimos que cada postagem e comentário seja entendido.

Igualmente importante, todos os nossos desenvolvedores recebem o feedback dos clientes e são participantes ativos nos fórums de discussão online. Dessa maneira, estamos lentamente mas certamente construindo uma comunidade ativa e leal na BlinkList.

—Michael Reining, co-fundador, MindValley & Blinklist


Duro Amor

Esteja preparado para dizer não a seus clientes

Quando falamos de requisição de funcionalidades, o cliente nem sempre está certo. Se adicionássemos cada uma das coisas que nossos clientes pediram, ninguém iria querer nossos produtos.

Se fôssemos obedecer cada choro de nossos clientes, o Basecamp teria: gerenciamento de tempo completo, cobrança completa, cronograma de reuniões completo, sistema de calendário completo, sistema de dependência de tarefas completo, chats via mensagens instantâneas completo, funcionalidade de wiki completo, e tudo-mais-que-puder-imaginar completo.

Ainda assim, a requisição número 1 que recebemos nas pesquisas com os clientes é manter o Basecamp simples

Aqui vai outro exemplo: Apesar de algumas reclamações, decidimos não suportar o Internet Explorer 5 (ie5) em nossos produtos. Isso era 7% do mercado que estávamos endereçando. Mas decidimos que era mais importante nos preocupar com os outros 93%. Consertar bugs e testar para ie5 simplesmente não 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 requisições mas o cliente nem sempre está certo. Haverá tempos em que você precisará simplesmente deixar alguém irritado. C’est la vie.

Relacionado a isso, é crítico que você, enquanto empresa de desenvolvimento, ame seu produto. E você não ama seu produto se estiver cheio de um monte de coisas com as quais não concorda. Essa é outra justificativa para vetar requisições de clientes que não acredita que sejam necessárias.



Em Fórum Fino

Use fórums ou chats para deixar os clientes se ajudar entre si

Fórum e chats de grupo baseado na web são uma grande maneira de deixar clientes fazerem perguntar e ajudar uns aos outros. Eliminando o homem do meio – esse é você – você fornece uma linha aberta de comunicação e economiza seu tempo no processo.

Em nossos fóruns de produtos, os clientes publicam dicas e truques, requisições de funcionalidades, histórias e mais. Nós aparecemos de tempos em tempos para oferecer assistência mas os fóruns são principalmente um lugar para a comunidade se ajudar e compartilhar experiências com o produto.

Você ficará surpreso com quantas pessoas querem se ajudar.



Publique Suas Cagadas

Coloque as notícias lá fora e fora do caminho

Se alguma coisa vai errado, diga às pessoas. Mesmo que, em primeiro lugar, 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 notificação de “saída do ar inesperado” 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 saída do ar nessa manhã – tivemos problemas de banco de dados que causaram grandes lentidões e saídas do ar para algumas pessoas. Consertamos o problema e estamos tomando as precauções para garantir que isso não aconteça novamente … Obrigado pela sua paciência e, mais uma vez, nos desculpamos pela saída do ar”.

Seja tão aberto e transparente quanto for possível. Não mantenha segredos ou se esconda. Um cliente informado é seu melhor cliente. Mais do que isso, você perceberá que a maioria de suas cagadas nem são tão ruins na mente de seus clientes. Eles normalmente estão felizes em lhe dar um pouco de respiro enquanto souberem que está sendo honesto com eles.

Uma observação sobre entregar notícias, ruins ou boas: quando notícias ruins chegam, abra tudo de uma vez. Boas notícias, por outro lado, devem ser desenroladas aos poucos. Se puder prolongar as boas vibrações, faça isso.

Seja Ágil, Direto e Honesto

Pode soar estranho, mas o cenário de melhor caso é quando a própria empresa relata as más notícias. É a pró-atividade que previne sua empresa de ser colocada em uma posição fraca e defensiva.

—Greg Sherwin, Vice Presidente de Tecnologia de Aplicação, CNET, e Emily Avila, Diretora, Calypso Communications (de Introdução à Crises de Relações Públicas)


Pós-Lançamento capítulo 15

Um Mês de Melhoria

Lance uma grande atualização 30 dias após o lançamento

Uma atualização rápida mostra momentum. Mostra que estamos ouvindo. Mostra que temos mais truques sob as mangas. Nos dá uma segunda onda de burburinho. Reafirma os bons sentimentos do começo. Nos dá alguma coisa sobre o que falar e para que os outros possam publicar nos blogs.

Saber que uma atualização rápida está chegando nos faz colocar o foco nos componentes mais cruciais antes do lançamento. Em vez de tentar espremer mais algumas coisas, podemos começar aperfeiçoando apenas o conjunto principal de funcionalidades. Então podemos lançar o produto no mundo real. Uma vez lá fora podemos começar a receber opiniões de volta dos clientes e saberemos que áreas precisam de mais atenção.

Esse estilo de passo-de-bebê funcionou bem para o Backpack. Lançamos o produto básico primeiro e então, algumas semanas depois, adicionamos funcionalidades como Backpack Mobile para computadores portáteis 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 após o lançamento

Não pare de blogar depois de lançar. Mostre que seu produto é uma criatura viva mantendo um blog dedicado e actualizado frequentemente (pelo menos uma vez por semana, com mais frequência se puder).

Coisas a incluir:

Um blog não mostra apenas que seu aplicativo está vivo, mas com que sua empresa parece mais humana. Novamente, não tenha medo de manter o tom amigável e pessoal. Às vezes equipes pequenas sentem que precisam soar grandes e ultra-profissionais o tempo todo. É quase como uma versão de negócios do Complexo de Napoleão. Não sue soando pequeno. Se revele sobre o fato de conseguir conversar com os clientes como amigos.

Está Vivo

Um blog com atualizações frequentes de um produto é o melhor indicador que a aplicação web está com desenvolvimento ativo, que é amado 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 responsáveis estão dormindo no ponto.

Mantenha as conversas andando com seus utilizadores no blog de seu produto e seja transparente e generoso com as informações que compartilha. Deixe a filosofia de sua empresa brilhar. Link e discuta abertamente sobre concorrentes. Dê dicas de funcionalidades chegando e mantenha os comentários abertos para opiniões de retorno.

Um produto vivo é uma coisa que fala e escuta seus utilizadores. Um blog frequentemente actualizado de um produto promove transparência, um senso de comunidade e lealdade como suas marcas. Publicidade extra e de graça são bônus.

Como editor da Lifehacker, eu vasculho os blogs de produtos de aplicações web que amo continuamente – como os blogs de produtos do Google, Flickr, Yahoo, del.icio.us e 37signals. Eu sou muito mais propenso a mencioná-los do que aplicações web que apenas enviam propaganda de imprensa unidirecional do nado e não mantém uma conversa aberta com seus utilizadores e fãs.

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


Melhor, Não Beta

Não use “beta” como uma desculpa

Ultimamente parece que tudo está em um estágio beta permanente. Isso é um escapismo. Um interminável estágio beta indica aos clientes que não estamos realmente comprometidos a liberar um produto finalizado. Isso diz, “use, mas se não estiver perfeito, não é nossa culpa”.

Beta repassa a conta ao cliente. Se não estamos confiantes o suficiente sobre nosso lançamento então como podemos esperar que o público esteja? Tudo bem com betas privados, betas públicos são grandes bobagens. Se não está bom o suficiente para o consumo público não dê ao público para consumir.

Não espere seu produto atingir a perfeição. Isso não vai acontecer. Assuma responsabilidade sobre o que está lançando. Coloque para fora e chame de lançamento. Do contrário, está apenas dando desculpas.

Beta não tem Sentido

Culpe o Google, e outros, por causar problemas como esse. Agora, utilizadores foram treinados por um agregado de desenvolvedores a achar que “beta” não significa realmente nada.

—Mary Hodder, arquiteta de informação e designer de interação (de A Definição de Beta)

Todo o Tempo

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

—Jim Coudal, fundador, Coudal Partners


Todos os Bugs Não São Criados Iguais

Priorize seus bugs (e até mesmo ignore alguns deles)

Só porque descobrimos um bug em nosso produto não significa que é hora de entrar em pânico. Todo software tem bugs – é apenas um fato da vida.

Não precisamos corrigir cada bug instantaneamente. A maioria dos bugs é incómoda, não destrutiva. Incómodos podem ser postergados um pouco. Bugs que resultam em erros que “não parecem certos” ou outras pequenas indicações podem ser colocadas de lado de maneira segura por enquanto. Se um bug destrói seu banco de dados, no entanto, obviamente precisamos corrigí-lo imediatamente.

Priorize seus bugs. Quantas pessoas são afectadas? Quão ruim é o problema? Esse bug merece atenção imediata ou pode esperar? O que podemos fazer agora mesmo que terá o maior impacto para o maior número de pessoas? Algumas vezes adicionar uma nova funcionalidade pode ser mais importante para seu aplicativo do que corrigir um bug existente.

Também, não crie uma cultura de medo ao redor de bugs. Bugs acontecem. Não fique constantemente procurando alguém para culpar. A última coisa que queremos é um ambiente onde bugs são varridos para baixo do tapete em vez de discutidos abertamente.

E lembre-se do que dissemos antes sobre a importância da honestidade. Se clientes reclamam sobre um bug, seja directo com eles. Diga-lhes que notaram o assunto e estão lidando com ele. Se não forem resolvê-lo imediatamente, diga porque e explique que está focando em áreas do produto que afectam um número grande de pessoas. Honestidade é a melhor política.



Cavalgue para Fora da Tempestade

Espere até as reacções impulsivas por mudanças cessem antes de tomar atitudes

Quando balançamos o barco, haverá ondas. Depois de apresentar novas funcionalidades, mudar a política ou remover alguma coisa, reacções impulsivas, às vezes negativas, vão transbordar.

Resista à vontade de entrar em pânico ou mudar rapidamente as coisas em resposta. Paixões se acendem no começo. Mas se cavalgarmos para fora desse período inicial de 24 a 48 horas, as coisas provavelmente vão se resolver sozinhas. A maioria das pessoas respondem antes de realmente cavar e usar seja lá o que foi adicionado (ou se acostumarem com o que foi retirado). Então sente-se, absorva tudo e não faça nenhum movimento até que algum tempo tenha se passado. Então será capaz de oferecer uma resposta mais adequada.

Também se lembre que reacções negativas são 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 utilizadores está feliz com a mudança. Garanta que não estará dando para trás à toa em uma decisão necessária, mas controversa.



Fique Esperto com os Vizinhos

Assine alimentadores de notícias sobre seus concorrentes

Assine alimentadores de notícias (news feeds) sobre ambos seu produto e de seus concorrentes (é sempre sábio conhecer os caminhos de seus inimigos). Use serviços como PubSub, Technorati, Feedster e outros para se manter actualizado (para palavras-chave, use nomes de empresas e produtos). Com rss, essa informação em constantes mudanças será entregue directamente a você, e assim estará sempre preparado.



Cuidado com o Monstro da Gordura

Mais maduro não precisa significar mais complicado

Da forma como as coisas progridem, não tenha medo de resistir à gordura. A tentação será para aumentar. Mas não precisa ser desse jeito. Só porque alguma coisa fica velha e mais madura, não precisa significar que tem que ficar mais complicada.

Não precisamos nos tornar canetas de outro planeta que escreve do contrário. Algumas vezes está óptimo em ser apenas um lápis. Não precisamos ser canivetes suíços. Podemos apenas ser uma chave-de-fenda. Não precisamos construir um relógio de mergulho que suporta até 5 mil metros se seus clientes são amantes da terra que apenas querem saber que horas são.

Não infle tão somente para inflar. É assim que as aplicações ganham gordura.

Novo nem sempre significa melhorado. Algumas vezes existe um ponto onde devemos apenas deixar a aplicação ser como é.

Esse é um dos benefícios-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 de lhe vender novas versões todos os anos. E como não podem simplesmente vender-lhe a mesma versão, precisam de justificar o custo adicionando novas funcionalidades. É onde começa a gordura.

Com software web baseado em um modelo de assinatura, as pessoas pagam uma mensalidade para usar o serviço. Não precisamos ficar vendendo com a adição de mais e mais e mais, apenas precisamos providenciar um serviço contínuo de valor.



Siga o Fluxo

Seja aberto a novos caminhos e mudanças de direcção

Parte da beleza de uma aplicação web é sua fluidez. Não o empacotamos em uma caixa, entregamos e então esperamos anos para o próximo lançamento. Podemos refinar e mudar à medida que avançamos. Seja aberto ao fato que sua ideia original pode não ser seu melhor.

Veja o Flickr. Ele começou como um jogo online para múltiplas pessoas chamado O Jogo que Nunca Acaba. Seus criadores logo entenderam que o aspecto de compartilhamento de fotos do jogo era um produto mais plausível do que o próprio 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 grandes ondas estão quebrando e ajuste de acordo.



Conclusão capítulo 16

Liguem seus Motores

Feito!

Tudo certo, você conseguiu! Se tudo deu certo está psicologicamente preparado para começar Cair na Realidade com sua aplicação. Realmente nunca houve uma época melhor para fazer grandes softwares com recursos mínimos. Com a ideia certa, paixão, tempo e habilidade, o céu é o limite.

Alguns pensamentos de conclusão:

Execução

Qualquer um pode ler um livro. Qualquer um pode chegar com uma ideia. Qualquer um tem um primo que é um web designer. Qualquer um pode escrever um blog. Qualquer um pode contratar alguém para grudar algum código.

A diferença entre você e qualquer um será quão bem você executa. Sucesso tem tudo a ver com uma grande execução.

Para software, isso significa fazer um monte de coisas certas. Você não pode somente ter uma boa escrita mas falhar em entregar as promessas na sua prosa. Design limpo de interface não vai dar certo se seu código é cheio de gambiarras. Uma grande aplicação não vale nada se promoção pobre significa que ninguém saberá sobre ela. Para pontuar grande, precisa combinar todos esses elementos.

A chave é balanço. Se for longe demais em uma direcção, 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 aplicação web de sucesso: as pessoas envolvidas. Mantras, designs de epicentro, menos software e todas essas ideias maravilhosas não vão realmente importar se não tiver as pessoas certas a bordo para implementá-las.

Você precisa de pessoas que são 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 monetária envolvida. Pessoas que suam nos detalhes mesmo que 95% das pessoas nem saibam distinguir as diferenças. Pessoas que querem construir alguma coisa grande e não se conformam com menos. Pessoas que precisam de pessoas. Ok, não necessariamente essa última coisa mas não iríamos resistir não jogar um pouco de Streisand na mistura. De qualquer forma, quando encontrar essas pessoas, segure-se nelas. No final, as pessoas da sua equipe farão ou quebrarão seu projecto – e sua empresa.

Mais Que Apenas Software

Também vale a pena notar que o conceito de Cair na Realidade não se aplica apenas a construir aplicações web. Uma vez que você começa a tocar nas ideias envolvidas, as encontrará em todos os lugares. Alguns exemplos:

Claro, Cair na Realidade é sobre construir grandes softwares. Mas não há razão para parar por aí. Pegue essas ideias e tente aplicá-las em diferentes aspectos de sua vida. Você pode acabar atingindo resultados interessantes.

Mantenha Contato

Nos deixe saber como Cair na Realidade funcionou para você. Mande e-mail para gettingreal [at] 37signals [ponto] com.

Além disso, mantenha-se actualizado sobre as últimas ofertas da 37signals visitando Signal vs. Noise, nosso blog sobre Cair na Realidade, usabilidade, design e um monte de outras coisas.

Obrigado por ler e boa sorte!



37signals Resources



Tradução

Agradecimentos aos seguintes tradutores: Fabio Akita, Herval Freire, Juraci Krohling Costa, Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo Kochenburger

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

Contact us via email if you'd like to help translate. The entire book is also available in English.