Académique Documents
Professionnel Documents
Culture Documents
http://gettingreal.37signals.com/GR_por.php
Job Board
Thumbtack is looking for a Software Engineer.
Gig Board
Looking for design, copywriting, or programming help with your project? Check the Gig Board.
Caindo na Real
Bem vindos primeira das tradues mundiais completa do livro 'Getting Real'. Totalmente em Portugus. captulo 1 Introduo captulo 2 A Linha de Largada captulo 3 Permanea Enxuto captulo 4 Prioridades captulo 5 Seleo de Funcionalidades captulo 6 Processo captulo 7 A Organizao captulo 8 Contratando captulo 9 Design de Interface captulo 10 Cdigo captulo 11 Palavras captulo 12 Precificao e Assinatura captulo 13 Promoo captulo 14 Suporte captulo 15 Ps-Lanamento captulo 16 Concluso
Introduo captulo 1
1 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
setas, esquemas, wireframes, etc.) e realmente construir a coisa real. Caindo na Real menos. Menos massa, menos software, menos funcionalidades, menos papis, menos tudo que no essencial (e a maioria do que voc pensa ser essencial realmente no ). Caindo na Real permanecer pequeno e ser gil. Caindo na Real inicia com a construo da interface, ou seja, as telas reais que as pessoas iro utilizar. Comea com as experincias reais dos clientes, construindo a partir disso para trs. Dessa forma voc obtm a interface adequada antes de obter um software errado. Caindo na Real sobre iteraes e baixar os custos da mudana. Caindo na Real tem tudo a ver com lanamento, refinamento e melhorar constantemente, o que o torna o caminho perfeito para software baseado em web. Caindo na Real entrega exatamente o que os clientes precisam e elimina qualquer coisa que no precisam.
2 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Reunies de equipe interminveis A "necessidade" de contratar dzias de funcionrios Nmeros de verses sem sentido Planejamentos cristalinos que prevem o futuro Opes de preferncia interminveis Suporte terceirizado Testes de usurio irreais Papelada intil Hierarquia de cima-para-baixo Voc no precisa de toneladas de dinheiro ou uma equipe enorme ou um ciclo de desenvolvimento longo para construir grandes softwares. Essas coisas so ingredientes para aplicaes lentas, esfumaadas, que no mudam. Caindo na Real usa o caminho oposto.
3 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Sobre a 37signals
O que fazemos
37signals uma pequena equipe que cria software simples e focado. Nossos produtos o ajudam a colaborar e se organizar. Mais de 350 mil pessoas e pequenos negcios usam nossas aplicaes web para fazer suas coisas. Jeremy Wagstaff, do Wall Street Journal, escreveu os produtos da 37signals so ferramentas maravilhosamente simples, elegantes e intuitivas que fazem uma tela de Outlook parecer um equivalente em software de uma cmara de tortura. Nossos aplicativos nunca pe voc no pau de arara.
Nossos produtos
At a data de publicao desse livro, temos cinco produtos comerciais e um framework open source de aplicaes web. Basecamp vira a cabea de gerenciamento de projetos. Em vez de tabelas Gantt, grficos engraadinhos e planilhas lotadas de estatsticas, Basecamp oferece painis de mensagens, listas de tarefas, cronograma simples, escritas colaborativas e compartilhamento de arquivos. At agora, centenas de milhares concordam que a melhor maneira. Farhad Manjoo, da Salon.com disse que Basecamp representa o futuro de software na Web. Campfire traz um simples chat em grupo para o contexto de negcios. As empresas conhecidas entendem quo valioso um chat persistente em tempo real pode ser. Mensagens instantneas convencionais so timas para conversas entre duas pessoas, mas so miserveis para 3 ou mais pessoas de uma s vez. Campfire resolve esse problema e muito mais. Backpack a alternativa para aqueles confusos, complexos organize sua vida em 25 simples passos gerenciadores de informaes pessoais. A tirada de Backpack com pginas, anotaes, lista de tarefas e avisos via telefones celulares / e-mail so idias inovadoras em uma categoria de produtos que sofre com o status quo. Thomas Weber, do Wall Street Journal disse que o melhor produto na sua classe e David Pogue, do New York Times o chamou de uma ferramenta de organizao muito legal. Writeboard deixa voc escrever, compartilhar, revisar e comparar texto, sozinho ou com outros. a alternativa refrescante dos gordurosos processadores de texto que so demais para 95% do que voc escreve. John Gruber, da Daring Fireball disse Writeboard deve ser a aplicao web mais clara e simples que j vi. O guru de Web, Jeffrey Zeldman disse as mentes brilhantes da 37signals fizeram novamente. Ta-da List mantm todas as suas listas de tarefas juntas e organizadas online. Mantenha as listas para voc ou compartilhe com outros para fcil colaborao. No existe jeito mais fcil de terminar suas coisas. Mais de 100 mil listas e perto de 1 milho de tens foram criadas at agora.
4 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Ruby on Rails, para desenvolvedores, um framework web completo, open source para escrever aplicao para o mundo real rapidamente e facilmente. Rails toma conta do trabalho pesado para que voc possa focar na sua idia. Nathan Torkington, do imprio editorial OReilly disse que Ruby on Rails incrvel. Us-lo como assistir a um filme de kung-fu, onde uma dzia de frameworks maus se preparam para atacar o novato apenas para apanharem de uma variedade de formas imaginativas. No tem como no gostar dessa citao. Voc pode encontrar mais sobre nossos produtos e nossa companhia no nosso site web em www.37signals.com.
5 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Mesmo que sua empresa funcione tipicamente com cronogramas de longo prazo e com grandes equipes, ainda existem maneiras de Cair na Real. O primeiro passo quebrar em pequenas unidades. Quando existem pessoas demais envolvidas, nada acontece. Quanto mais enxuto voc for, mais rpido e melhor as coisas acontecem. Entretanto, isso vai requerer alguma conversa de vendas. Venda a idia do processo Caindo na Real na sua empresa. Mostre a eles esse livro. Mostre a eles os resultados reais que voc pode atingir em menos tempo e com equipes menores. Explique que Caindo na Real uma maneira de baixo risco, baixo investimento para testar novos conceitos. Veja se voc pode se separar da nave-me em um projeto menor, como prova de conceito. Demonstre resultados. Ou, se quiser ser corajoso, v silenciosamente. Voe abaixo do radar e demonstre resultados reais. Essa foi a forma que a equipe da Start.com usou na Microsoft. Eu observei a equipe da Start.com trabalhar. Eles no pedem permisso, disse Robert Scoble, Technical Evangelist da Microsoft. Eles tem um chefe que fornece cobertura area. E eles mordem um pequeno pedao de cada vez, fazem isso e respondem a feedback.
6 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Construa Menos
Faa menos que sua competio
O senso comum diz que para vencer seus competidores, voc precisa estar um passo a frente. Se eles possuem quatro funcionalidades, voc precisa de cinco (ou 15, ou 25). Se eles gastam X, voc precisa gastar XX. Se eles tm 20, voc precisa 30. Este tipo de estratgia, a Guerra Fria de estar um passo a frente, leva a uma briga sem fim. Trabalhar assim caro, defensivo e paranico. Empresas defensivas e paranicas no pensam para frente, eles pensam apenas no passado. Elas no lideram, elas seguem. Se voc quer construir uma empresa que segue, este livro no para voc. Mas ento, e ai? A resposta menos. Faa menos que a concorrncia para desbanc-los. Resolva os problemas simples, deixe os problemas cabeludos, difceis e desesperadores para os outros. Ao invs de estar um passo a frente, esteja um passo atrs. Ao invs de se superar, tente manter-se dentro do seu potencial. Veremos o conceito de menos durante o livro, mas para os iniciantes, menos significa: Menos funcionalidades Menos opes/preferncias Menos pessoas e estrutura empresarial Menos reunies e abstraes
7 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
fazia o que precisvamos ou 2) era gorda de funcionalidades que no precisvamos como cobrana, controles estritos de acesso, planilhas, grficos, etc. Sabamos que deveria haver uma maneira melhor ento decidimos construir nossa prpria. Quando resolvemos nossos prprios problemas, criamos uma ferramenta que nos apaixona. E paixo a chave. Paixo significa que realmente a usaremos e cuidaremos dela. E essa a melhor maneira de fazer os outros se sentirem apaixonados sobre ela tambm.
Nascido da necessidade
Campaign Monitor realmente nasceu na necessidade. Por anos nos frustramos com a qualidade das opes de marketing por e-mail que existiam por a. Uma ferramenta fazia x e y mas nunca z, a prxima tinha y e z mas simplesmente no podia ter x direito. No podamos vencer. Decidimos liberar a agenda e comear a construir nossa ferramenta de marketing por e-mail dos sonhos. Conscientemente decidimos no olhar para o que os outros estavam fazendo e em vez disso construir algo que fizesse nossas vidas, e a de nossos clientes, um pouco mais fceis. Depois descobrimos que no ramos os nicos que estavam infelizes com as opes que existiam. Fizemos algumas modificaes ao software de forma que qualquer empresa de design pudesse us-lo e comeamos a espalhar a palavra. Em menos de seis meses, milhares de designers estavam usando Campaign Monitor para enviar informativos por e-mail para eles mesmos e seus clientes. David Greiner, fundador, Campaign Monitor
8 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Dois caminhos
[Jake Walker comeou uma companhia com dinheiro de investidores (Disclive) e um sem (The Show). Aqui ele discute as diferenas entre os dois caminhos.] A raz de todos os problemas no foi conseguir dinheiro, mas tudo que veio junto com ele. As expectativas so simplesmente mais altas. As pessoas comeam tomando salrios e a motivao para construir e depois vender, ou encontrar outra maneira para os investidores iniciais terem seu dinheiro de volta. No caso da primeira empresa, simplesmente comeamos a agir como se fssemos muito maiores do que realmente ramos sem necessidade [Com The Show] percebemos que poderamos entregar um produto muito melhor com menos custo, apenas com mais tempo. E apostamos com um pouco de nosso prprio dinheiro que as pessoas iriam esperar por mais qualidade em vez de velocidade. Mas a empresa se manteve (e provavelmente continuar sendo) uma operao pequena. E desde esse primeiro projeto, estamos totalmente auto-financiados. Com
9 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
apenas um pouco de criatividade de nossos fornecedores, nunca mais realmente precisamos colocar muito de nosso prprio dinheiro na operao. E a expectativa no era de crescer e vender, mas de crescer por crescer e continuar se beneficiando disso financeiramente. Um comentrio de Signal vs. Noise
10 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Como um projeto chega a estar um ano atrasado? Um dia de cada vez. Fred Brooks, engenheiro de software e cientista da computao
Tenha um Inimigo
Pegue uma briga
Algumas vezes a melhor maneira de saber como sua aplicao deve ser saber o que ela no deve ser. Descubra o inimigo da sua aplicao e voc acender uma luz para onde precisa ir. Quando decidimos criar um software de gerenciamento de projetos, sabamos que Microsoft Project era o gorila na sala. Em vez de temer o gorila, o usamos como motivador. Decidimos que Basecamp seria algo completamente diferente, o anti-Project. Entendemos que gerenciamento de projetos no sobre tabelas, grficos, relatrios e estatsticas sobre comunicao. Tambm no sobre um gerente de projetos sentando l no alto e distribuindo um plano de projetos. sobre todos assumindo responsabilidades juntos para fazer o projeto funcionar. Nossos inimigos eram os Gerentes de Projetos Ditadores e as ferramentas que eles usavam para chicotear. Queramos democratizar o gerenciamento de projetos faz-lo de forma que todos fizessem parte (incluindo o cliente). Projetos se do melhor quando todos assumem propriedade coletiva do processo. Quando chegou a vez do Writeboard, sabamos que haviam competidores l fora com toneladas de funcionalidades. Ento decidimos enfatizar em um ngulo sem frescura. Criamos uma aplicao que permite s pessoas compartilhar e colaborar nas idias de maneira simples, sem incomod-las com funcionalidades no-essenciais. Se no era essencial, deixamos de fora. E em apenas trs meses depois do lanamento, mais de 100 mil Writeboards foram criados. Quando comeamos no Backpack nosso inimigo era estrutura e regras rgidas. As pessoas devem ser capazes de organizar suas informaes de sua prpria maneira no baseado em uma srie de telas pr-formatadas ou uma montanha de campos de edio obrigatrios. Um bnus que voc recebe em ter um inimigo uma mensagem de marketing muito clara. As pessoas esto cheias de conflitos. E tambm entendem um produto comparando-o com outros. Com um inimigo escolhido, voc est enviando uma histria que eles querem ouvir. No s eles vo entender seu produto melhor e mais rpido, mas vo tomar um lado. E essa uma maneira garantida de chamar a ateno e acender uma paixo. Agora, com tudo isso dito, tambm importante no ficar muito obcecado com a concorrncia. Analise demais outros produtos e voc vai comear a limitar sua maneira de pensar. D uma olhada e v em frente para sua prpria viso e suas prprias idias.
No siga o lder
Marketeiros (e todos os seres humanos) so bem treinados para seguir o lder. O instinto natural descobrir o que funciona para a concorrncia e ento tentar super-los em ser mais barato que seu competidor que compete no preo, ou mais rpido que seu competidor que compete na velocidade. O problema que uma vez que o consumidor j comprou a histria de algum e acredita nessa mentira,
11 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
persuad-lo a mudar a mesma coisa que persuad-lo a admitir que estava errado. E as pessoas odeiam admitir que esto erradas. Em vez disso, voc deve dizer uma histria diferente e persuadir os ouvintes que sua histria mais importante do que a histria que eles acreditam atualmente. Se sua competio mais rpida, voc deve ser mais barato. Se eles vendem a histria de sade, voc deve vender a histria da convenincia. No apenas o posicionamento cartesiano x/y do tipo Somos mais baratos, mas uma histria real que completamente diferente da histria que j foi contada. Seth Godin, autor/empresrio (de Seja um Mentiroso Melhor)
A preseno de paixo
Em design, onde o significado normalmente e controversamente subjetivo ou dolorosamente indecifrvel, poucas coisas so mais aparentes e lcidas do que a presena de paixo. Isso verdade seja quando o design do produto o agrada ou o deixa frio; em ambos os casos difcil no detectar o investimento emocional das mos que o construram. Entusiasmo se manifesta prontamente, claro, mas indiferena igualmente inesquecvel. Se seu compromisso no vem com paixo genuna para o trabalho s mos, isso se torna um vazio que quase impossvel de conciliar, no importa o quo elaborado ou atrativo o design. Khoi Vinh, Subtraction.com
A padaria
12 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Os negcios americanos neste momento realmente so sobre desenvolver idias, torn-las lucrativas, vend-las enquanto so lucrativas e ento sair fora ou diversificar. justamente sobre sugar tudo. Minha idia era: aprecie cozinhar, venda seu po, as pessoas gostam disso, venda mais. Mantenha a padaria indo porque voc est fazendo boa comida e as pessoas esto felizes. Ian MacKaye, membro da Fugazi e um dos donos da Dischord Records (da Salon.com People | Ian MacKaye)
Menos Massa
Quanto mais enxuto for, mais fcil para mudar
Quanto mais massa tiver um objeto, mais energia necessria para mudar sua direo. uma verdade tanto para o mundo dos negcios como para o mundo fsico. Quando falamos em tecnologias web, mudanas devem ser fceis e baratas. Se voc no puder mudar rapidamente, perder terreno para algum que possa. por isso que voc deve optar por menos massa.
13 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Menos massa permite mudar de direo rapidamente. Voc pode reagir e evoluir. Pode focar em boas idias e derrubar as ruins. Pode ouvir e responder a seus clientes. Pode integrar novas tecnologias agora em vez de mais tarde. Ao invs de um avio de cargas, voc dirige um pequeno bote. Aproveite esse fato. Por exemplo, vamos imaginar uma empresa enxuta e com menos massa, que construiu um produto com menos cdigo e menos funcionalidades. Do outro lado est uma empresa massuda que tem um produto significativamente com mais software e mais funcionalidades. Ento, digamos que uma nova tecnologia como Ajax ou um novo conceito como tags apaream por a. Quem estar apto a adaptar seu produto mais rpido? A equipe com mais software e mais funcionalidades, com um planejamento de 12 meses ou a equipe com menos software, menos funcionalidade e com um processo mais organico do tipo vamos focar no que realmente precisamos agora? Obviamente a empresa com menos massa est em uma posio melhor para se ajustar s demandas reais do mercado. A empresa com mais massa ainda estar discutindo as mudanas, ou empurrando-as junto ao processo burocrtico, enquanto a empresa com menos massa j haver feito a troca. A empresa com menos massa est dois passos frente enquanto a empresa com mais massa ainda est tentando entender como andar. Negcios rpidos, geis, e com menos massa podem rapidamente mudar seu modelo de negcios, produtos, funcionalidades e mensagem de marketing. Eles podem cometer erros e corrig-los rapidamente. Podem mudar suas prioridades, misturar produtos e focar. E, mais importante, podem mudar sua maneira de pensar.
Emergencia
A emergencia um dos princpios fundamentais da agilidade, e a coisa mais prxima da magia pura. Propriedades emergenciais no so projetadas ou vm prontas, elas simplesmente acontecem como um resultado dinmico do resto do sistema. Emergencia vem do Latim da metade do sculo 17, que significa ocorrncia no prevista. Voc no pode planej-la ou agend-la, mas pode cultivar um ambiente em que a deixe ocorrer, se beneficiando dela.
14 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Um exemplo clssico de emergncia est no comportamento dos bandos de pssaros. Uma simulao de computador pode usar apenas trs regras simples (parecidas com no colida-se com outros) e de repente voc tem comportamento complexo quando o bando vai batendo as asas graciosamente pelos cus, se remodelando em torno de obstculos e assim por diante. Nenhum desses comportamentos avanados (como se remodelar na mesma forma ao redor de obstculos) especificado pelas regras; eles emergem da dinmica do sistema. Regras simples, como na simulao dos pssaros, leva a comportamentos complexos. Regras complexas, como com leis tributrias na maioria dos pases, levam a comportamentos estpidos. Muitas prticas comuns de desenvolvimento de software tem o infeliz efeito-colateral de eliminar qualquer chance de comportamento emergente. A maioria das tentativas de otimizao amarrando alguma coisa muito explicitamente reduz a extenso e escopo de interaes e relacionamentos, que a origem da emergencia. No exemplo do bando de pssaros, assim como sistemas bem-desenhados, so as interaes e relacionamentos que criam os comportamentos interessantes. Quanto mais amarramos as coisas, menos espao deixamos para uma soluo criativa e emergente. Seja tanto travando requisitos, antes de serem bem entendidos ou otimizando o cdigo prematuramente, como inventando navegaes e cenrios de fluxo de trabalho complexas, antes de deixar o usurio final usar o sistema, o resultado o mesmo: um sistema exageramente complicado e estpido ao invs de um sistema limpo e elegante que aproveita a emergencia. Mantenha pequeno. Mantenha simples. Deixe acontecer. Andrew Hunt, The Pragmatic Programmers
Os Trs Mosqueteiros
Use uma equipe de trs para a verso 1.0
Para a primeira verso da sua aplicao, comece com apenas trs pessoas. Este o nmero mgico que lhe dar fora de trabalho suficiente sem lhe tirar o dinamismo e a agilidade. Comece com um desenvolvedor, um designer e um varredor (algum que possa transitar entre ambos os mundos). Claro, um desafio desenvolver uma aplicao com poucas pessoas. Mas se voc possuir a equipe certa, esta ser valorosa. Pessoas talentosas no precisam de recursos infinitos. Elas prosperam no desafio de trabalhar com restries e usam a criatividade para resolver problemas. Falta de recursos humanos fora-o a lidar com sacrifcios mais cedo, o que timo. Far voc entender suas prioridades mais cedo do que mais tarde. E voc estar apto para comunicar-se sem ter constantemente que se preocupar se est deixando algum de fora. Se voc no pode desenvolver sua primeira verso com apenas trs pessoas, ento ou voc precisa de pessoas diferentes ou diminuir sua verso inicial. Lembre-se, tudo bem voc lanar sua primeira verso pequena e consistente. Voc rapidamente perceber se sua idia tem futuro e, se tiver, voc ter uma base simples e limpa para progredir.
15 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
cresce aproximadamente ao quadrado do nmero de usurios do sistema, tem um corolrio quando se trata de equipes de projeto: A eficincia da equipe aproximadamente o inverso do quadrado do nmero de membros na equipe. Estou comeando a achar que trs pessoas timo para a verso 1.0 de um produto Comece por reduzir o nmero de pessoas que voc planeja incluir na equipe, e ento reduza um pouco mais. Marc Hedlund, entrepreneur-in-residence na OReilly Media
O fluxo da comunicao
A comunicao flui mais facilmente em equipes pequenas do que em grandes. Se voc a nica pessoa no projeto, comunicao simples. O nico caminho de comunicao entre voc e o cliente. Com o aumento do nmero de pessoas em um projeto, aumenta tambm o nmero de caminhos de comunicao. E no aumenta de forma aditiva, como o nmero de pessoas, aumenta de forma multiplicativa, proporcional ao quadrado do nmero de pessoas. Steve McConnell, Chief Software Engineer na Construx Software Builders Inc. (de: Less is More: Jumpstarting Productivity with Small Teams)
Abrace as Restries
Deixe as limitaes lhe guiar para solues criativas
Nunca h suficiente para dar a volta. Sem tempo suficiente. Sem dinheiro suficiente. Sem pessoal suficiente. Isso uma coisa boa. Em vez de se desesperar com essas restries, aceite-as. Deixe que elas o guiem. Restries incentivam inovao e foram o foco. Em vez de tentar remov-las, use-as em seu benefcio. Quanto a 37signals estava desenvolvendo o Basecamp, ns tnhamos muitas limitaes. Tnhamos: Uma empresa de design para administrar Trabalhos para clientes j existentes Uma diferena de 7 horas (O David estava programando na Dinamarca e o resto de ns nos Estados Unidos) Uma equipe pequena Nenhum finaciamento externo Ns sentimos a depresso sem suficiente. Ento mantivemos nossos pratos pequenos. Dessa maneira s poderamos colocar at onde coubesse. Pegvamos grandes tarefas e quebrvamos em pedaos menores que atcavamos um de cada vez. Nos movemos passo a passo e priorizamos no caminho. Isso nos forou a chegar com solues criativas. Baixamos nosso custo de mudana construindo sempre menos software. Demos s pessoas apenas as funcionalidades suficientes para resolver seus problemas do seu jeito e ento saamos do caminho. A diferena de tempo e distncia entre ns nos tornou mais eficientes na nossa comunicao. Em vez de nos encontrarmos em pessoa, comunicvamos exclusivamente via mensagens instantneas e e-mail, o que nos forava a ir direto ao ponto rapidamente.
16 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Restries normalmente so vantagens disfaradas. Esquea investimento externo, longos ciclos de lanamento e resolues rpidas. Em vez disso, trabalhe com o que voc tem.
Combata a destruio
O que j foi descrito como elegncia bizarra provavelmente melhor descrito como funcionalidade destrutiva, como um fungo em uma planta ele gradualmente elabora a embaa a verdadeira forma do produto enquanto drena suas energias. O antdoto para funcionalidade destrutiva , claro, o prazo final restritivo. Isso resulta em funcionalidades serem descartadas por causa do tempo que levaria para implement-las. Normalmente o caso que as funcionalidades mais teis levam a maior parte do tempo para implementar. Portanto a combinao da destruio e do prazo final gera software como conhecemos e amamos, formado de grande quantidade de funcionalidades inteis. Jef Raskin, autor (de Por que Software como ) Table of contents | Essay list for this chapter | Next essay
Sempre disponvel
No importa em qual negcio voc est, um bom servio ao cliente tornou-se o maior requisito que
17 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
qualquer cliente estabelecer. Ns demandamos isso dos servios que usamos ento por que com nossos clientes seria diferente? Desde o comeo ns deixamos fcil e transparente para nossos clientes contatar-nos por toda e qualquer questo que tiverem. Em nosso website ns listamos um grande nmero de ferramentas gratuitas que redireciona para nossos celulares e nossos cartes de visita listam os nmeros de cada um de ns. Ns enfatizamos para nossos consumidores que eles podem nos contatar a qualquer hora independente do problema. Nossos clientes apreciam esse nvel de confiana ningum jamais abusou deste servio. Edward Knittel, Diretor de Vendas e Marketing, KennelSource
Prioridades captulo 4
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
era que o usurio de um carto de dbito no deveria ter a mesma transao aplicada sua conta duas vezes. Em outras palavras, no importa que tipo de falha pudesse acontecer, o erro deveria ir para o lado de no processar a transao em vez de processar e duplic-la. Ento, escrevemos isso no nosso quadro-branco compartilhado em letras grandes: Erros a favor dos usurios. Isso se juntou a outra meia-dzia de mximas. Juntas, elas guiaram todas aquelas decises complicadas que se fazem quando se constri algo complexo. Juntas, essas leis deram forte coerncia interna e grande consistncia externa nossa aplicao. Dave Thomas, The Pragmatic Programmer
Faa um Mantra
Organizaes precisam de pontos-guia. Precisam de linhas gerais; funcionrios precisam saber a cada dia quando acordam porque esto indo trabalhar. Essas linhas devem ser curtas e doces, e bem compreensivas: Por que voc existe? O que o motiva? Chamo isso de mantra uma descrio de trs ou quatro palavras de porque voc existe. Guy Kawasaki, autor (de Make Mantra)
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
terceira semana. Apenas coloque as coisas na pgina por enquanto. Ento use. Garanta que funciona. Mais tarde voc pode ajustar e aperfeioar. Os detalhes se revelam ao se usar o que est construindo. Voc ver o que precisa de mais ateno. Sentir o que est faltando. Saber quais crateras pavimentar porque ficar sempre caindo nelas. quando precisa prestar ateno, e no antes.
Apenas se vire
As pessoas costumam gastar tempo demais logo de cara tentando resolver problemas que elas ainda nem tm. No faa isso. Poxa, ns lanamos o Basecamp sem a habilidade de cobrar os clientes! Como o produto cobrado mensalmente, sabamos que teramos um intervalo de 30 dias para dar um jeito. Usamos aquele tempo para resolver problemas mais urgentes e ento, aps o lanamento, enfrentamos a cobrana. Deu certo (e nos forou a adotar uma soluo simples, sem firulas desnecessrias). No esquente com uma coisa at que voc tenha de fato que faz-lo. No desenvolva demais. Aumente hardware e software de sistema conforme necessrio. Se ficar lento por uma ou duas semanas no ser o fim do mundo. Apenas seja honesto: explique para os seus clientes que voc est passando por dores de crescimento. Eles podem no ficar empolgados mas apreciaro a franqueza. Resumo da pera: Tome decises s no momento necessrio, pois a voc ter acesso informao real de que precisa. Entrementes voc estar em condies de prestar ateno s coisas que requerem cuidado
20 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
imediato.
21 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Por exemplo, ns rodamos o Basecamp em um nico servidor durante o primeiro ano. Por termos iniciado com uma configurao simples, conseguimos implementar em uma nica semana. Ns no comeamos com um aglomerado de 15 computadores nem gastamos meses nos preocupando com escalabilidade. Tivemos problemas? Alguns. Mas tambm descobrimos que a maior parte do que temamos, como um breve perodo de lentido, no era o fim do mundo para os clientes. Desde que voc mantenha as pessoas informadas, e seja honesto sobre a situao, elas entendero. Em retrospecto, somos contentes por no termos atrasado o lanamento em meses para criar a configurao perfeita. No comeo, priorize construir um produto slido em vez de obsecar-se com escalabilidade ou fazendas de servidores. Crie uma grande aplicao e depois se preocupe com o que fazer quando ela se tornar animalmente bem-sucedida. Do contrrio voc o corre o risco de desperdiar energia, tempo e dinheiro se prendendo a algo que nunca acontecer. Acredite ou no, o maior problema no escalar, chegar ao ponto de ter de faz-lo. Sem o primeiro problema, voc no ter o segundo.
22 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
as pessoas que partilham de nossa viso. Ou se est do lado de dentro ou se est do lado de fora.
Meio, No Meia-Boca
Faa meio produto e no um produto meia-boca
Cuidado com a viso faz-tudo no desenvolvimento de uma aplicao web. Considere todas as boas idias que aparecerem ao longo do processo e voc acabar apenas com uma verso meia-boca do seu produto. O que voc realmente precisa montar meio produto que detone. Atenha-se ao que verdadeiramente essencial. Boas idias podem ser tiradas da gaveta. Pegue tudo que voc acha que seu produto deve ser e corte pela metade. Remova funcionalidades at que voc obtenha apenas o essencial. E ento, repita o processo. Comeamos o Basecamp apenas com a seo de mensagens. Ns sabamos que isso era o corao do aplicativo, ento, de incio, ignoramos as milestones, listas de tarefas e outros itens. Isso nos permitiu embasar as decises futuras no uso real e no em palpites. Comece com um aplicativo simples e inteligente e deixe-o ganhar impulso. S ento pense em adicionar coisas fundao slida que voc j construiu.
23 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Porque vocs no mostram o total de pessoas na sala? Resposta: Porque no importa. O nome de todos est listado, ento voc sabe quem est a, que diferena faz saber se h 12 ou 16 pessoas? Se isso no muda o seu comportamento ento isso no importa. Seria legal ter essas coisas? Claro. Elas so essenciais? Elas realmente importam? No. Por isso foram deixadas de fora. Os melhores designers e os melhores programadores no so os com as melhores habilidades, ou os dedos mais geis, ou os que podem assoviar e chupar cana com o Photoshop ou sua plataforma preferida, e sim aqueles que podem determinar o que no importa. a onde os ganhos reais so feitos. A maior parte do tempo que voc gasta perdido em coisas que no importam. Se voc puder cortar o tempo pensando no que no importa, voc atingir nveis de produtividade que voc jamais imaginou.
Comece com No
Faa com que as funcionalidades dem duro para ser implementadas
O segredo de criar meio produto ao invs de um produto meia-boca dizer no. Cada vez que voc diz sim para uma funcionalidade, voc est adotando um filho. Voc tem que levar seu beb atravs de toda uma cadeia de eventos (exemplo: design, implementao, testes etc.). Uma vez que est funcionalidade est l, voc est preso a ela. Apenas tente remov-la e veja o quo irados ficaro os clientes.
24 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
dizer sim para tudo. dizer NO para tudo exceto as funcionalidades mais cruciais. -Derek Sivers, presidente e programador, CD Baby e HostBaby (from Diga NO por padro)
Custos Ocultos
Exponha o preo das novas funcionalidades
Mesmo que uma funcionalidade passe o estgio do no, voc ainda precisa expor seus custos ocultos. Por exemplo, fique de alerta com loops de funcionalidades, ou seja, funcionalidades que levam a mais funcionalidades. Ns recebemos pedidos para adicionar uma aba de reunies ao Basecamp. Parece simples at que voc examine com mais cautela. Pense em todos os diferentes itens que uma aba de reunies precisaria: localizao, hora, sala, pessoas, convites por e-mail, integrao com o calendrio, documentao de suporte, etc. Isso sem mencionar que ns teramos que modificar as imagens de promoo, as pginas do tour, pginas do faq/ajuda, contrato de prestao de servio e mais. Antes que voc note, uma idia simples pode ser tornar uma dor de cabea enorme. Para cada nova funcionalidade voc precisa 1. Dizer no. 2. Forar a funcionalidade a provar seu valor. 3. Se no novamente, pare aqui. Se sim, continue 4. Esboce as telas/UI. 5. Crie as telas/UI. 6. Programe-as. 7-15. Teste, aperfeioe, teste, aperfeioe, teste, aperfeioe 16. Cheque para ver se o texto da ajuda precisa ser modificado. 17. Atualize o tour do produto (se necessrio). 18. Atualize a cpia de marketing (se necessrio). 19. Atualize o Termo de Prestao de Servio (se necessrio). 20. Cheque se alguma promessa foi quebrada. 21. Cheque se a estrutura de custos foi afetada. 22. Publique. 23. Cruze os dedos.
25 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Voc consegue dar 1 GB de espao de graa, s porque o Google d? Talvez voc deva comear pequeno, em 100 mb, ou ceder espao apenas para as contas pagantes. Concluso: Crie produtos e oferea servios que voc possa gerenciar. fcil fazer promessas. bem mais dficl mant-las. Tenha certeza de que, seja l o que voc fizer, seja algo que voc possa realmente sustentar organizacional, estratgica e financeiramente.
Solues Humanas
Crie softwares voltados para conceitos gerais e incentive as pessoas a criar suas prprias solues
No force convenes. Ao invs disso, faa seu software de modo generalista, assim todos podem encontrar suas prprias solues. D s pessoas s o suficiente para resolver os problemas delas ao modo delas. E ento saia do caminho. Quando criamos a Ta-da List, ns intencionalmente omitimos uma srie de coisas. No h como designar uma tarefa para algum, no h como marcar uma data de trmino, no h como categorizar os itens, etc. Ns mantivmos a ferramenta limpa e sem frescuras deixando as pessoas serem criativas. As pessoas descobriram como resolver seus problemas sozinhas. Se elas quisessem adicionar uma data para uma tarefa, elas poderiam inserir (Prazo: 7 de Abril de 2006) na frente do item. Se elas quisessem categorizar, poderiam simplesmente colocar [Livros] na frente do item. Ideal? No. Infinitamente flexvel? Sim. Se tentssemos criar software para, especificamente, cuidar desses casos, ns estaramos o tornando menos til para todos os casos onde essas preocupaes no se aplicam. Faa o melhor trabalho que voc puder com a raiz do problema e ento saia de fininho. As pessoas vo encontrar suas prprias solues e convenes dentro de sua estrutura geral.
26 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
comearam como sugestes de nossos clientes. Mas, como dissemos antes, sua primeira resposta deve ser um no. Ento o que voc faz com todos esses pedidos? Onde voc os guarda? Como voc os gerencia? Voc no faz isso. Voc apenas os l e ento os joga fora. Sim, leia, jogue fora e esquea-os. Pode soar como heresia mas os realmente importantes iro, com certeza, reaparecer. Esses so os nicos que voc precisa se lembrar. Esses so os realmente esseciais. No se preocupe em organizar e guardar cada pedido que aparecer. Deixe seus clientes serem sua memria. Se a funcionalidade for realmente necessria, eles te lembraro at que voc no consiga esquecer. Como ns chegamos essa concluso? Quando ns lanamos o Basecamp ns colocvamos todos os pedidos de novas funcionalidades em uma lista de tarefas. A cada repetio de um pedido, ns marcvamos com um I extra ( II, III ou IIII etc). Ns imaginvamos que um dia iramos revisar a lista e trabalhar indo das mais para as menos populares. Mas a verdade que nunca olhamos para a lista novamente. Ns j sabamos o que precisava ser feito porque nossos clientes nos lembravam constantemente fazendo sempre os mesmos pedidos. No havia necessidade de uma lista ou grupos de anlise, porque tudo estava acontecendo em tempo real. Voc no pode esquecer o que importante quando voc lembrado todos os dias. E mais uma coisa: S porque x pessoas pedem algo, no significa que voc tem que inclu-la. Algumas vezes melhor apenas dizer no e manter sua viso de produto.
Segure as Rdeas
Pergunte o que as pessoas no querem
A maior parte das enquetes e pesquisas sobre software so focalizadas em o que as pessoas querem num produto. Qual funcionalidade voc acha que est faltando?, Se voc pudesse adicionar mais uma nica coisa, o que seria?, O que tornaria esse produto mais til para voc? E o outro lado da moeda? Porque no perguntar o que as pessoas nao querem? Se voc pudesse remover algo, qual seria? O que voc no usa? O que mais te atrapalha? Mais no a resposta. Algumas vezes o maior favor que voc pode fazer para os clientes deixar algo de fora.
Processo captulo 6
27 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
28 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Enxague e Repita
Trabalhe por iteraes
No espere fazer certo na primeira vez. Deixe a aplicao crescer e se apresentar a voc. Deixe ela mutar e envolver. Com softwares baseados na web no h necessidade de entregar a perfeio. Projete as telas, use-as, analize-as e ento comece de novo. Ao invs de querer tudo certo desde o incio, o processo iterativo lhe permite continuar tomando decises informadas no percurso. Voc ainda ter uma aplicao ativa e rodando rapidamente, desde que no fique obcecado em atingir a perfeio logo de cara. O resultado um feedback e um guia real sobre o que requer sua ateno.
Da Idia Implementao
V do brainstorm esboos HTML codificao
29 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Brainstorm
Traga idias tona. O que este produto ir fazer? Para o Basecamp, ns olhamos para nossas prprias necessidades. Queramos publicar atualizaes de projeto. Queramos participao dos clientes. Sabamos que projetos tinham datas-chave. Queramos centralizar arquivos para que as pessoas pudessem revisar coisas antigas com facilidade. Queramos ter uma viso da figura maior, uma vista area do que estava acontecendo com todos os nossos projetos. Juntas, estas premissas e algumas outras, serviram como nossa fundao. Esse estgio nao sobre os mnimos detalhes. sobre grandes questes. O que a aplicao precisa fazer? Como saberemos quando ser til? O que exatamente faremos? Isso sobre idias de alto nvel, nao discusses no nvel dos pixels. Nesse estgio, esses tipos de detalhe simplesmente no tm sentido.
Papel de Padeiro
Esboos so rpidos, sujos e baratos e exatamente como voc quer comear. Desenhe coisas. Rabisque coisas. Caixas, crculos, linhas. Arranque as idias da cabea para o papel. O objetivo nesse ponto deve ser converter conceitos em designs grosseiros de interface. Esse passo apenas sobre experimentao. No h respostas erradas.
Codifique
Quando o prottipo parecer bom e demonstrar o suficiente das funcionalidades necessrias, v em frente e conecte o cdigo de programao. Durante todo esse processo, se lembre de permanecer flexvel e esperar mltiplas iteraes. Voc deve se sentir livre para jogar fora qualquer parte entregvel de qualquer passo particular e comear novamente se ela se mostrar lixo. natural passar por esse ciclo mltiplas vezes.
Evite Preferncias
Decida sobre os pequenos detalhes para que seus clientes no precisem
30 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Nos deparamos com uma deciso difcil: quantas mensagens inclumos em cada pgina? A primeira inclinao pode ser em dizer, Vamos apenas tornar isso uma preferncia onde as pessoas possam escolher 25, 50 ou 100. Entretanto, essa a forma mais simples. Apenas tome a deciso.
Tome a deciso
Tome as decises simples no lugar dos clientes. o que fizemos no Basecamp. O nmero de mensagems por pgina 25. Na pgina de resumo, as ltimas 25 so mostradas. Mensagens so ordenadas em ordem cronolgica reversa. Os cinco projetos mais recentes so mostrados no painel. No existem opes. o jeito que tem que ser. Sim, podemos tomar uma deciso ruim. Mas e da? Se fizermos isso, as pessoas vo reclamar e nos dizer sobre isso. Como sempre, podemos ajustar. Cair na Real justamnete sobre ser capaz de mudar em tempo real.
Preferncias Tm um Custo
No fim das contas preferncias tem um custo. Claro, algumas preferncias tambm tm benefcios importantes e podem ser funcionalidades de interface cruciais. Mas cada um tem um preo e temos que considerar cuidadosamente seu valor. Muitos usurios e desenvolvedores no entendem isso e acabam com muito custo e pouco valor por seus dlares de preferncias acho que se formos duramente disciplinados sobre ter bons padres Que Apenas Funcionam, em vez de adicionar preferncias folgadamente, isso naturalmente leva a interface de usurio como um todo na direo certa. Havoc Pennington, lder tcnico, Red Hat (de Software Livre e boas interfaces de usurio)
"Feito !"
Decises so temporrias ento faa a escolha e siga em frente
Feito. Comece a pensar nisso como uma palavra mgica. Quando algo est feito significa que algum objetivo foi atingido. Uma deciso foi tomada e podemos seguir em frente. Feito significa que estamos construindo momento.
31 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Mas espere, e se ferramos e tomamos a deciso errada? Tudo bem. Isso no cirurgia de crebro, uma aplicao web. Como estamos dizendo, provavelmente teremos que rever funcionalidades e idias mltiplas vezes durante o processo de qualquer forma. No importa quanto planejamos, com certeza estaremos meio errados de qualquer jeito. Ento no faa essa coisa de pausa para anlise. Isso apenas desacelera o progresso e compromete a moral. Em vez disso, avalie a importncia de seguir em frente. Entre no ritmo de tomar decises. Tome uma deciso rpida e simples e ento retorne e mude se no funcionar. Aceite que decises so temporrias. Aceite que erros vo acontecer e entenda que no tem nada demais enquanto estivermos fazendo correes rapidamente. Execute, construa momento, e siga em frente.
Seja um Executador
to engraado quando ouo sobre pessoas protegendo tanto suas idias. (Pessoas que querem que eu assine um contrato de sigilo antes de me contar a mais simples das idias). Para mim, idias no valem nada at serem executadas. So apenas multiplicadores. Execuo vale milhes. Explicao: Idia Pssima = -1 Idia Fraca = 1 Idia mais ou menos = 5 Boa Idia = 10 Grande Idia = 15 Brilhante Idia = 20 Nenhuma execuo = $1 Execuo Fraca = $1.000 Execuo mais ou menos = $10.000 Boa Execuo = $100.000 Grande Execuo = $1.000.000 Brilhante Execuo = $10.000.000 Para fazer negcios, voc precisa multiplicar os dois. A idia mais brilhante, sem nenhuma execuo, vale $20. A idia mais brilhante necessita de grande execuo para valer $20.000.000. Esse o motivo porque no quero ouvir idias de outras pessoas. No estou interessado at ver suas execues. Derek Sivers, presidente e programador, CD Baby e HostBaby
Teste ao Ar Livre
Teste sua aplicao com uso do mundo real
32 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
No h substituto para pessoas reais usando sua aplicao de maneiras reais. Pegue dados reais. Receba feedback real. Ento aprimore baseado nessa informao. Testes de usabilidade formais so muito duros. Configuraes de laboratrio no refletem a realidade. Se ficarmos sobre os ombros de algum, teremos alguma idia do que est funcionando ou no mas as pessoas normalmente no agem bem de frente para as cmeras. Quando outra pessoa est olhando, as pessoas so especialmente mais cuidadosas para no cometer erros sendo que erros so exatamente o que estamos procurando. Em vez disso, lance verses beta para alguns poucos selecionados dentro da prpria aplicao real. Faa com que usem as funcionalidades do beta ao lado das funcionalidades lanadas. Isso ir expr essas funcionalidades a dados reais das pessoas e a fluxos verdadeiros. E a que teremos resultados reais. Alm disso, no tenha uma verso de lanamento e outra beta. Elas devem ser sempre a mesma coisa. Uma verso beta separada s receber uma leve navegao. A verso real, com algumas funcionalidades beta misturadas, recebero o fluxo de uso completo.
O Livro Beta
Se desenvolvedores esto nervosos liberando seus cdigos, ento editores e autores esto assustados lanando seus livros. Uma vez que o livro est fixo no papel, visto como uma coisa cabeluda mudar (na verdade no , mas percepo e lembranas de problemas com velhas tecnologias ainda persistem na indstria). Ento, editores passam por vrios problemas (e custos) tentando fazer os livros ficarem certos antes de serem lanados. Quando escrevi o livro Agile Web Development With Rails, houve muita demanda entre os desenvolvedores: nos d o livro agora queremos aprender Rails. Mas eu ca no pensamento de um editor. No est pronto ainda, eu dizia. Mas a presso da comunidade e trocas de idias com David Heinemeier Hansson mudaram minha forma de pensar. Lanamos o livro em formato pdf cerca de 2 meses antes de ficar completo. Os resultados foram espetaculares. No apenas vendemos um monte de livros, mas recebemos feedback muito feedback. Configurei um sistema automatizado para capturar os comentrios dos leitores, e no final tivemos quase 850 relatos de erros de digitao, erros tcnicos e sugestes para novo contedo. Quase todos encontraram seu caminho para o livro final. Foi uma situao ganha-ganha: consegui entregar um livro muito melhor e a comunidade teve acesso antecipado a algo que eles queriam. E se voc est numa corrida competitiva, ter algo antecipado ajuda as pessoas a se comprometerem com voc e no com sua competio. Dave Thomas, The Pragmatic Programmers
33 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Fatores Verdadeiros
Da prxima vez que algum o pressionar por uma resposta exata a uma questo desconhecida seja sobre uma data de entrega, o custo final do projeto ou o volume de leite que caberia no Grand Canyon apenas comece tirando o ar da sala: diga, "Eu no sei". Longe de danificar sua credibilidade, isso demonstra o cuidado que voc trs sua tomada de decises. Voc no est dizendo palavras apenas para parecer esperto. Isso tambm nivela o campo de jogo reformulando a questo como uma conversa colaborativa. Sabendo quo exata sua estimativa precisa ser (e porque), voc pode trabalhar junto para desenvolver um entendimento compartilhado sobre os verdadeiros fatores por trs dos nmeros.
34 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
A Organizao captulo 7
Unidade
No quebre em reas
Muitas empresas separam design, desenvolvimento, redao, suporte e marketing em reas isoladas. Enquanto a especializao tem suas vantagens, tambm cria uma situao em que os funcionrios s enxergam seus prprios mundos ao invs da aplicao web como um todo. Integre sua equipe ao mximo para que exista um dilogo contnuo em todas as etapas do processo. Faa um sistema de verificaes e balanos. No deixe que coisas se percam nas transcries. Tenha redatores trabalhando com designers. Faa com que os desenvolvedores tenham cincia dos pedidos de suporte. Melhor ainda, contrate pessoas com mltiplos talentos, que podem atuar em diversas frentes. O resultado final ser um produto mais harmonioso.
Tempo Sozinho
Pessoas precisam de perodos sem interrupes para terminar o trabalho
37signals est espalhada por quatro cidades e oito fusos-horrio. De Provo, Utah a Copenhagen, na
35 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Dinamarca, cinco de ns estamos oito horas distantes. Um dos efeitos positivos de se ter oito horas de diferena o tempo em que podemos ficar sozinhos. Apenas 4 a 5 horas por dia estamos trabalhando juntos. Em algumas horas, a equipe norte-americana est dormindo enquanto David, que est na Dinamarca, est trabalhando. Nas horas restantes, estamos trabalhando enquanto David est dormindo. Isso nos d meio dia juntos e meio dia sozinhos. Adivinhe qual a parte do dia em que somos mais produtivos? O tempo em que estamos sozinhos. E isso no nenhuma surpresa. Muitas pessoas preferem trabalhar logo de manhzinha ou tarde da noite nas horas em que no so incomodados. Quando voc tem um longo perodo em que no incomodado, consegue se concentrar. E concentrado se mais produtivo. quando voc no tem que dividir a cabea com outros assuntos ou tarefas. quando no se interrompido para responder algo, ou procurar alguma coisa, ou enviar um email, ou responder mensagens instantneas. O tempo sozinho onde progressos de verdade acontecem. Se concentrar leva tempo. E exatamente por isso que a interrupo seu maior inimigo. como pegar no sono profundo no se entra no sono profundo do nada, tem que se deitar, dormir e ento entrar no sono profundo. Qualquer interrupo o fora a comear tudo de novo. O sono profundo onde a mgica do sono acontece de verdade. A concentrao onde a mgica da produtividade acontece de verdade. Estabelea uma regra: faa que metade do dia seja de horas onde voc fica sozinho. Das 10 da manh at s 2 da tarde, ningum pode falar com ningum mais (exceto durante o almoo). Ou ento, faa com que a manh ou a tarde seja o seu tempo para ficar sozinho. O importante que o perodo seja contnuo para evitar interrupes que matam sua produtividade. Um perodo de tempo sozinho significa largar o vcio da comunicao. Durante o tempo que ficar sozinho, esquea as mensagens instantneas, ligaes telefnicas, reunies. Evite qualquer conversa por e-mail que exija respostas imediatas. Em resumo: cale a boca e trabalhe.
Se Concentrando
Todos sabemos que profissionais sbios trabalham melhor entrando no clima, tambm chamado de se concentrar, onde ficam totalmente concentrados em seus trabalhos e completamente desligados dos seus ambientes. Eles perdem a noo do tempo e produzem muito mais atravs de concentrao absoluta o problema que muito fcil perder a concentrao. Barulho, telefonemas, sada para o almoo, ter que dirigir por 5 minutos pra comer um po de queijo e interrupes por colegas de trabalho especialmente interrupes por colegastudo te tira da zona de concentrao. Se voc parar por 1 minuto para responder a uma pergunta de um colega de trabalho, e isso tirar sua concentrao o suficiente para levar meia hora pra voltar a ser produtivo novamente, sua produtividade geral est em srios problemas. Joel Spolsky, desenvolvedor de software, Fog Creek Software (de De Onde Essas Pessoas Tiram Essas Idias (No Originais)?)
Reunies So Txicas
No tenha reunies
Voc precisa mesmo de reunies? Reunies geralmente acontecem quando um conceito no est claro o
36 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
suficiente. Ao invs de recorrer a uma reunio, tente simplificar o conceito, para que voc possa discut-lo rapidamente por email ou IM ou Campfire. O objetivo evitar reunies. Cada minuto que voc gasta em uma reunio um minuto que voc poderia estar trabalhando. No existe nada mais txico produtividade do que uma reunio. Aqui vo alguns motivos: Elas quebram seu trabalho dirio em pequenos perodos, que acabam por quebrar o fluxo do trabalho Elas geralmente tratam apenas de palavras e conceitos abstratos, no de coisas reais (como um trecho de cdigo ou algum detalhe do design de interface) Elas geralmente tratam de uma pequena quantidade de informaes por minuto Elas quase sempre tem uma pessoa que inevitavelmente vai fazer com que todos percam o tempo com assuntos no relacionados O assunto principal vai embora muito facilmente Freqentemente tem pautas to vagas que ningum tem certeza do assunto principal Requerem uma preparao prvia, que quase ningum faz Em casos em que reunies so realmente necessrias (faa disso um raro evento), siga estas regras simples: Coloque um alarme pra 30 minutos. Assim que ele tocar, a reunio acabou. Ponto final. Chame o menor nmero de pessoas possvel. Nunca tenha uma reunio sem uma pauta bem clara.
Quebre-as
Conforme o projeto cresce, o acrscimo de pessoas diminui a produtividade. Uma das razes mais interessantes o aumento do nmero de canais de comunicao. Duas pessoas podem falar entre si; um canal de comunicao nico. Trs pessoas tem trs canais de comunicao; 4 tem 6. Na verdade, o crescimento dos canais exponencial Logo, memorandos e reunies vo acabar consumindo o tempo todo. A soluo clara: quebre as equipes em unidades pequenas, autnomas e independentes, para reduzir os canais de comunicao. Da mesma forma, quebre os programas em unidades pequenas. Uma grande parte do problema vm de dependncias externas (variveis globais, dados passados entre funes, hardware compartilhado, etc), encontre um jeito de quebrar o programa para eliminar ou minimizar as dependncias entre as unidades. Grupo Ganssle (de Mantenha Pequeno)
37 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Contratando captulo 8
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Lei de Brooks
Adicionar pessoas a um projeto de software atrasado vai atras-lo ainda mais. Fred Brooks
Chute os Pneus
Trabalhe com possveis funcionrios na base do teste antes
Uma coisa olhar o portflio, curriculum, exemplo de cdigo ou trabalhos anteriores. Outra coisa efetivamente trabalhar com algum. Sempre que possvel, faa um test-drive com possveis novos membros da equipe. Antes de contratar algum, passe a ele um pequeno projeto antes. Vamos ver como ele assume o projeto, como ele se comunica, como ele trabalha, etc. Trabalhar com algum conforme ele faa o design ou codifique algumas telas vai te dar uma boa idia sobre a pessoa. Voc ver rapidamente se a pessoa ou no o que voc precisa. O tempo de trabalho para este projeto pode ser pequeno. Mesmo que sejam 20 ou 40 horas, melhor do que nada. Se o tempo ou no suficiente, isso se tornar bvio. Em todo caso, ambos os lados se livraro do risco e dor de cabea testando antes.
Aes, No Palavras
Julgue potenciais contrataes de tecnologia em contribuies
39 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
open source
O mtodo tradicional de contratao para cargos tcnicosbaseados em faculdades, curriculums, etc. falho por diversas razes. Realmente importa onde a pessoa formada ou suas notas? Podemos confiar mesmo em um curriculum ou indicao? Open source uma ddiva para aqueles que precisam contratar tcnicos. Com open source, pode-se checar o trabalho e contribuies de algumpra bem ou malcom um bom intervalo de tempo. Isso significa que voc pode julgar pessoas pelas aes ao invs de apenas palavras. Voc pode tomar decises com base no que realmente importa: Qualidade do trabalho Muitos programadores falam bonito, mas afinam na hora do vamos ver. Com open source, voc consegue ver com detalhes as prticas e conhecimentos de programao de uma pessoa. Perspectiva cultural Programar tomar decises. Muitas delas. Decises so tomadas com base na cultura, nos valores e em ideais. Veja as decises especficas feitas por um candidato enquanto est programando e testando, e veja seus argumentos na comunidade para ver se o candidato est dentro do que a empresa espera. Se no se encaixa na empresa, as decises podem parecer erradas. Nivel de paixo Por definio, envolvimento em projetos open source requerem um nvel mnimo de paixo. Se no, porque outro motivo a pessoa perderia tempo na frente de um monitor? O tamanho do envolvimento em movimentos open source mostra quanto um candidato realmente se importa com programao. Porcentagem de finalizao Toda a inteligncia, toda a cultura e paixo no se transformam em software de valor se o candidato no consegue termin-lo. Infelizmente, muitos programadores no terminam seus projetos. Ento, procure a exceo. Contrate aquele que consegue sair pela porta e est disposto a fazer as trocas pragmticas que o trabalho exige. Lado social Trabalhar com algum por um bom perodo de tempo, durante tanto as horas de stress e descontrao e altos e baixos vo mostrar a verdadeira personalidade do candidato. Se algum no tem modos ou um lado socivel, deixe-os de lado. Quando estamos falando de programadores, somente contratamos pessoas que ns conhecemos atravs do open source. Ns acreditamos que se adotarmos qualquer outro mtodo, estamos sendo irresponsveis. Contratamos Jamis porque ns gostamos de seus releases e participao na comunidade Ruby. Ele se superou em todas as reas que acima. No precisamos verificar mais nada, j que ns pudemos julg-lo com base no que realmente importa: qualidade do seu trabalho. E no se preocupe se as atividades extra-curriculares roubarem o foco e paixo do trabalho dirio dos funcionrios. Como diz aquele velho ditado: se quer algo feito, pea pessoa mais ocupada que voc conhece. Jamis e David so dois dos maiores contribuidores do Rails e ainda conseguem dirigir tecnicamente a 37signals. Pessoas que amam programar e terminar seus projetos so exatamente o tipo de pessoa que voc quer em sua equipe.
40 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Jarkko Laine, desenvolvedor de software (de Reduza o risco, contrate de open source)
41 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Artesos de Palavras
Contrate bons escritores
Se est tentando decidir entre poucas pessoas para preencher uma posio, sempre contrate o melhor escritor. No importa se essa pessoa um designer, programador, marketing, vendedor ou o que for, essa habilidade leva a escrever mais efetivamente e concisamente cdigo, design, emails, mensagens instantneas e mais. Isso porque ser um bom escritor mais do que apenas palavras. Bons escritores sabem como se comunicar. Eles tornam as coisas mais fceis de entender. Eles podem se colocar no lugar dos outros. Eles sabem o que omitir. Eles pensam claramente. E essas so as qualidades que voc precisa.
Primeiro a Interface
Desenhe a interface antes de comear a programar
Muitos aplicativos comeam com a mentalidade de programar primeiro. Isso uma m idia. Programao o componente mais pesado de construir em um aplicativo, significando ser o mais caro e mais difcil de mudar. Ao invs disso, comece desenhando primeiro. Design relativamente leve. Um esboo de papel barato e fcil de mudar. Rascunhos HTML so
42 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
relativamente simples de modificar (ou jogar fora). Isso no verdade na programao. Desenhar antes deixa voc flexvel. Programar primeiro prende voc e gera custos adicionais. Outra razo para projetar primeiro que a interface o seu produto. O que as pessoas vem o que voc est vendendo. Se voc somente rabiscar uma interface no final, os buracos vo aparecer. Ns comeamos pela interface para que possamos ver como o aplicativo ser desde o comeo. Este ser constantemente revisado no decorrer do processo. Isso faz sentido? fcil de usar? Ele resolve um problema de imediato? Existem perguntas que voc s poder realmente responder quando voc lidar com telas reais. Desenhar antes deixa voc flexvel e o leva para essas respostas no processo mais cedo do que mais tarde.
Design de Epicentro
Comece do ncleo da pgina e construa para fora
Design de epicentro foca na verdadeira essncia da pgina o epicentro e ento constri para fora. Isso significa que, no comeo, voc ignora as extremidades: a navegao/menus, rodap, cores, barra lateral, logotipo, etc. Em vez disso, voc comea o epicentro e faz o design das peas de contedo mais importantes primeiro.
43 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Seja qual for a pgina ela no pode viver sem seu epicentro. Por exemplo, se estiver fazendo o design de uma pgina que mostra a publicao de um blog, a publicao por si o epicentro. No as categorias na barra lateral, no o cabealho no topo, no o formulrio de comentrios embaixo, mas a unidade de publicao de mensagem do blog. Sem essa unidade de publicao, a pgina no a publicao de um blog. Somente quando essa unidade est completa voc comearia a pensar no segundo elemento mais crtico da pgina. Ento, depois desse segundo elemento mais crtico, se moveria para o terceiro, e assim por diante. Isso design de epicentro. Design de epicentro evita o tradicional modelo "vamos construir a moldura ento jogar o contedo dentro". Nesse processo, o formato da pgina construda, ento a navegao includa, ento as "coisas" de marketing so inseridas e ento, finalmente, o ncleo da funcionalidade, o verdadeiro propsito da pgina, enfiado em um espao qualquer que tenha sobrado. um processo de trs para frente que tira o que deveria ser a prioridade principal e deixa isso para o fim. Design de Epicentro vira esse processo e permite que voc foque no que realmente interessa no dia um. Essenciais primeiro, extras em segundo. O resultado uma tela mais amigvel, focada e usvel para os clientes. Alm disso, permite que voc comece o dilogo entre designer e desenvolvedor logo de cara em vez de esperar por todos os aspectos da pgina carem na linha primeiro.
A Tela em Branco
Supere as expectativas com uma primeira experincia convincente
Ignorar o estado de superfcie branca um dos maiores erros que voc pode cometer. O estado branco a
44 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
primeira impresso de sua aplicao e voc nunca ter uma segunda ... bem, voc sabe. O problema que quando se faz o design da interface de usurio, normalmente ela est preenchida de dados. Designers sempre preenchem os desenhos com dados. Cada lista, cada publicao, cada campo, cada canto e espacinho tem coisa dentro. E isso significa que a tela parece pronta e funciona muito bem. Entretanto, o estado natural da aplicao vazia de dados. Quando algum se cadastra, eles comeam com uma tela em branco. Muito parecido com um weblog, cabe a eles popularem o visual geral no toma forma at as pessoas colocarem seus dados: publicaes, links, comentrios, horas, informao de barra lateral ou o que for. Infelizmente, o cliente decide se a aplicao vale a pena pelo estado inicial de sua tela em branco o estado onde h a menor quantidade de informao, design e contedo sobre o qual julgar a utilidade geral da aplicao. Quando voc falha no design adequado deste estado em branco, as pessoas no sabem o que esto perdendo porque tudo est faltando. Mesmo assim a maioria dos designers e desenvolvedores ainda subestima esse estado. Eles falham em gastar um bom tempo no design de telas vazias porque quando eles desenvolvem/usam a aplicao, esta j est cheia de dados que eles colocaram para propsitos de testes. Eles nem mesmo encontram a tela em branco. Claro, eles podem fazer o login como uma nova pessoa algumas vezes, mas a maioria das vezes gastam nadando em uma aplicao que est cheia de dados. O que voc deve incluir em uma tela em branco que ajuda? Use como uma oportunidade de inserir pequenos tutoriais e caixas de ajuda. D uma foto da tela final como exemplo da pgina populada com dados para que as pessoas saibam o que esperar (e porque devem ficar por l). Explique como comear, como a tela vai ficar exatamente, etc. Responda as perguntas-chave que visitantes de primeira viagem fazem: O que esta pgina? O que fao agora? Como essa tela vai ficar quando estiver cheia? Supere as expectativas e ajude a reduzir frustraes, intimidaes e a confuso em geral. Primeiras impresses so cruciais. Se voc falhar em fazer o design de uma tela em branco bem pensada, criar impresso negativa (e falsa) da sua aplicao ou servio.
Torne-se Defensivo
Faa Design para quando as coisas derem errado
45 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Vamos admitir: As coisa vo dar errado online. No importa o quo cuidadoso voc faa o design de sua aplicao, no importa quanto teste fizer, os clientes ainda vo encontrar problemas. Ento como voc gerencia essas quedas inevitveis? Com design defensivo. Design defensivo como direo defensiva. Da mesma maneira como motoristas devem estar sempre atentos para estradas escorregadias, motoristas imprudentes e outros cenrios perigosos, construtores de sites devem procurar constantemente por pontos de problema que causem confuso e frustrao aos visitantes. Um bom site defensivo por criar ou quebrar a experincia do cliente. Poderamos encher um livro separado com todas as coisas que temos a dizer sobre design defensivo. De fato, j fizemos. "Design Defensivo para a Web" o ttulo e um grande recurso para qualquer um que queira aprender como melhorar telas de erros e outros pontos crticos. Lembre-se: Sua aplicao pode funcionar muito bem 90% do tempo. Mas se voc abandonar seus clientes no momento em que mais precisam, improvvel que eles se esqueam disso.
Inconsistncia Inteligente
Consistncia no necessria. Por muitos anos, estudantes de Design foram ensiados que consistncia na interface uma das regras-chave no design. Talvez isso sirva pra software, mas na Web, no verdade. O que importa na Web que, em cada pgina, os usurios possam fcil e rapidamente avanar para o prximo passo no processo. Na Creative Good, ns chamamos isso de inconsistncia inteligente: certeza de que cada pgina no processo d ao usurio precisamente o que eles precisam naquele ponto do processo. Adicionar elementos navigacionais suprfluos, s porque so consistentes com o restante do site, pura bobagem. Mark Hurst, fundador da Creative Good e criador da Goovite.com (de O Paradigma da Pgina)
46 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Uma Interface
Incorpore funes administrativas em interfaces pblicas
Telas administrativas as telas usadas para gerenciar preferncias, pessoas, etc. tem uma tendncia de parecer um lixo. Isso porque a maioria do tempo de desenvolvimento gasto na aparncia pblica das interfaces. Para evitar a sndrome da tela-administrativa-lixo, no construa telas separadas para lidar com funes administrativas. Em vez disso, construa essas funes (isto , editar, adicionar, deletar) na interface regular da aplicao. Se tiver que manter duas interfaces separadas (isto , uma para o pessoal regular outra para administradores), ambas vo sofrer. Em efeito, voc acaba pagando a mesma taxa duas vezes. Voc forado a se repetir e isso significa que voc aumenta as chances de ficar desleixado. Quanto menos telas tiver, menos ter para se preocupar e melhor as coisas saem.
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
interface consistente eles so capazes de se adaptar aplicao ainda mais rpido. Edward Knittel, Diretor de Vendas e Marketing , KennelSource
Cdigo captulo 10
Menos Software
Mantenha seu cdigo o mais simples possvel
bastante razovel pensar que um software com o dobro de cdigo seria apenas duas vezes mais complexo. Mas na verdade, medida que se aumenta a quantidade de cdigo, a complexidade do software tende a crescer exponencialmente. Cada pequena adio, cada nova interdependncia, cada nova preferncia amplia o efeito cascata. Adicione cdigo desenfreadamente sua aplicao, e antes que voc perceba, voc ter criado uma grande e desgovernada bola de neve. A melhor maneira de se enfrentar a complexidade com menos cdigo. Menos software significa menos funcionalidades, menos cdigo, menos desperdcio. A chave est em repensar qualquer problema difcil que venha a necessitar de uma grande quantidade de componentes para ser solucionado em um problema mais fcil, que requeira muito menos. Voc pode acabar no solucionando exatamente o mesmo problema, mas tudo bem. Resolver 80% do problema original despendendo 20% do esforo uma vitria e tanto. O problema original raramente to crtico de forma a realmente merecer cinco vezes mais esforo em sua soluo. Menos software a melhor maneira para aposentar a sua bola de cristal. Em vez de tentar prever problemas futuros, lide apenas com os problemas de hoje. Por qu? A maioria dos medos que voc tem a respeito do futuro raramente tornam-se reais. No perca seu tempo tentando solucionar estes problemasfantasma. Desde o incio, desenvolvemos nossos produtos ao redor do conceito de pouco software. Sempre que possvel, simplificamos os problemas mais difceis. E descobrimos que a soluo para problemas mais simples no somente mais fcil de implementar e suportar, como tambm de entender e usar. tudo parte de uma estratgia para diferenciar-se dos competidores: em vez de focar-se em produtos que fazem mais, construimos produtos que fazem menos. Menos software mais fcil de se gerenciar. Menos software reduz a quantidade de cdigo e isso significa menor carga de trabalho de manuteno (e uma equipe mais feliz). Menos software reduz os custos de mudana, de forma que voc pode adaptar-se rapidamente. Voc pode mudar de idia sem ter que mudar milhes de linhas de cdigo. Menos software resulta em menos bugs. Menos software significa menos suporte. A escolha de quais funcionalidades incluir ou omitir tambm tem muito a ver com a quantidade de software. No tenha medo de dizer no a solicitaes de funcionalidades difceis de se implementar. A menos que elas sejam absolutamente essenciais, economize tempo, esforo e muita confuso deixando-as de fora.
48 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
V devagar, tambm. Quando surgir uma nova idia, no tome nenhuma ao por uma semana, e ao final veja se a idia ainda parece to brilhante. O tempo extra em banho maria geralmente ajudar seu crebro a pensar em uma soluo mais simples. Encoraje programadores a pensar em contra-propostas O que se deseja ouvir : A maneira como voc sugeriu levar 12 horas para ser implementada. Mas h um jeito de fazer que vai levar s uma hora. No vai fazer x, mas vai fazer y.. Deixe o software dizer "no".. Encoraje os programadores a lutarem pelo que eles pensam ser a melhor maneira. Tambm busque por alternativas a ter que escrever mais software. Seria possvel mudar um fluxo de telas de modo que elas sugiram uma rota alternativa para os usurios que no requeira mudanas no modelo do software? Por exemplo, seria possvel sugerir que as pessoas faam upload de imagens de um tamanho especfico, em vez de ter que manipular as imagens no lado do servidor? Para cada nova funcionalidade de sua aplicao, pergunte-se se no existe uma maneira de se produzir o mesmo resultado e que no requeira tanto software. Escreva apenas o cdigo que precise, e nada mais. Sua aplicao acabar bem mais magra e saudvel.
49 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
dirio mais divertidos. A felicidade tem um efeito em cascata. Programadores felizes trabalham da maneira correta. Eles escrevem cdigos simples e de fcil leitura. Eles abordam o problema de uma maneira elegante, expressiva e de fcil entendimento. Eles se divertem. Ns encontramos o ecstasy da programao na linguagem Ruby e o passamos adiante atravs do nosso framework, Rails. Ambos compartilham do mesmo objetivo de otimizar para humanos e sua felicidade. Ns o aconselhamos a dar uma chance a essa combinao. Resumindo, sua equipe necessita trabalhar com ferramentas de que eles gostem. Ns citamos exemplos no contexto de linguagens de programao, mas o conceito se aplica aplicaes, plataformas, e praticamente a tudo. Escolha a fuso que deixa as pessoas excitadas. Voc vai criar mais motivao e excitao e consequentemente um melhor resultado.
O Cdigo Fala
Oua quando seu cdigo diz "no"
Oua seu cdigo. Ele oferecer sugestes. Ele ir dizer "no". Ele lhe dir onde ficam as armadilhas. Ele ir sugerir novas maneiras de fazer as coisas. Ele ir ajud-lo a se manter em um modelo de menos software. Uma nova funcionalidade est requerendo semanas de tempo e milhares de linhas de cdigo? Isso seu cdigo lhe dizendo que provavemente existe uma maneira melhor. Existe uma maneira simples de codificar alguma coisa em uma hora em vez de uma maneira complicada que consumir dez horas? Novamente, esse seu cdigo o guiando. Oua. Seu cdigo pode gui-lo a consertos que so baratos e leves. Preste ateno quando um caminho mais fcil emerge. Claro, a funcionalidade que fcil de fazer pode no ser exatamente a mesma que voc originalmente tinha em mente, mas e da? Se funciona bem o suficiente e lhe d mais tempo para trabalhar em outra coisa, um ganhador.
Oua
No se preocupe com o design, se ouvir seu cdigo um bom design vai aparecer ... Oua as pessoas tcnicas. Se eles esto reclamando sobre a dificuldade de fazer mudanas, ento leve essas reclamaes a srio e lhes d tempo para consertar as coisas. Martin Fowler, Cientista Chefe, ThoughtWorks (de Is Design Dead?)
50 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Gerencie Dbitos
Pague a seu cdigo e as "contas" de design
Normalmente pensamos em dbito na forma de dinheiro mas ele vem em outras formas tambm. Voc pode facilmente construir cdigo e dbito de design. Grude junto alguns cdigos ruins que so funcionais mas ainda assim um pouco cabeludos e estar construindo dbito. Jogue junto um design que bom o suficiente mas no realmente bom e estar se endividando novamente. No tem problema fazer isso de vez em quando. De fato, s vezes uma tcnica necessria que o ajuda a chegar mais rpido ao esquema Caia-Na-Real-RPIDO. Mas voc ainda precisa reconhec-lo como dbito e pag-lo em algum ponto limpando o cdigo cabeludo ou redesenhando aquela pgina mais ou menos. Da mesma forma que voc deve regularmente colocar de lado uma parte do seu salrio para impostos, regularmente coloque uma parte do seu tempo para pagar seu cdigo e dbito de design. Se no fizer isso, apenas estar pagando juros (consertando grudes) em vez de pagar o montante (e movendo-o adiante).
Abra as Portas
Publique dados para o mundo via RSS, APIs, etc.
No tente prender seus usurios. Deixe que eles possam ter acesso a suas informaes quando quiserem, da forma que preferirem. Para tal, voc precisa deixar de lado a idia de manter os dados de seus usurios trancados a sete chaves. Em vez disso, deixe que a informao flua. Garanta o acesso informao atravs de feeds RSS. Oferea APIs que permitam a terceiros construir aplicaes integradas sua. Tais atitudes tornaro a vida dos usurios mais conveniente e expandiro as possibilidades do que sua aplicao capaz de fazer. No passado, as pessoas acostumaram-se a pensar nos feeds RSS apenas como uma boa maneira de se agregar contedo de sites de blogs e sites de notcia. Contudo, os feeds so mais poderosos que isto. Eles tambm podem permitir ao usurio manter-se atualizado sobre mudanas internas aplicao sem a necessidade de logar-se repetidas vezes. Atravs do site do Basecamp, por exemplo, o usurio pode cadastrar sua url em um agregador de RSS e assim receber notificaes de mensagens de projetos, listas de tarefas e objetivos sem a necessidade de conectar-se constantemente ao site em busca de informaes
51 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
atualizadas. APIs permitem que desenvolvedores construam plugins adicionais sua aplicao, que geralmente agregam valor ao seu produto. Por exemplo, a API disponibilizada pelo Backpack foi utilizada pela Chipt Productions na construo de um widget para o Mac os X. A pequena aplicao permite aos usurios adicionar e editar lembretes, listagens de items e muito mais a partir de seus desktops. Muitos usurios apontaram o widget como uma tima ferramenta, e alguns mesmo apontaram-no como um fator decisivo na escolha da utilizao do Backpack. Outros bons exemplos de empresas que liberaram dados como uma maneira de conseguir um efeito bumerangue: A API do Google Maps permitiu o surgimento de toda sorte de pequenas aplicaes que recuperam dados de outras fontes (ex.: uma listagem de apartamentos) e os exibem em um mapa. Linkrolls oferece aos usurios exibir seus ltimos bookmarks do del.icio.us em seu prprio site. O Flickr permite que outros negcios acessem as suas APIs comerciais, de forma a permitir aos usurios comprar livros de fotos, posters, backups em DVD e selos. O objetivo manter as portas completamente abertas e permitir o maior nmero possvel de possibilidades de utilizao de suas fotos, diz Stewart Butterfield, do Flickr.
Palavras captulo 11
52 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Especificaes funcionais foram a tomada das decises mais importantes justamente quando se tem o mnimo de informaes sobre o todo.
normal saber-se pouco sobre qualquer coisa antes de comear a construo. Quanto mais se avana no projeto, quanto mais se usa o produto, mais se entende sobre ele. neste ponto em que as decises deveriam ser feitas quando se tem mais informao, no menos.
53 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
breve, que possa transformar-se mais rapidamente em algo real. Escreva uma pgina descrevendo o que a aplicao precisa fazer. Use linguagem coloquial e faa isso rpido. Se voc precisar de mais de uma pgina para explicar o conceito, ento ele provavelmente muito complexo. Este processo de especificao no deve tomar mais que um dia. Comece ento a construo da interface ela ser o substituto da sua especificao funcional. Desenhe alguns esboos rpidos em papel, ento comece a transformar o esboo em cdigo HTML. Diferentemente de pargrafos de texto abertos a interpretao, a interface da aplicao um corpo comum, que tenta representar ao mximo a verso desejada da aplicao sem interpretaes subjetivas. A confuso tende a desaparecer quando todos comeam a usar as mesmas telas. Construa uma interface que permita que todos naveguem, usem e sintam a aplicao antes mesmo de comear a se preocupar com o cdigo de back-end. Coloque-se na pele do usurio o mximo possvel. Esquea as especificaes congeladas e imutveis. Elas foram a tomada de decises importantes muito cedo no processo. Pule a etapa de especificao funcional e mantenha o custo das mudanas em baixa e a flexibilidade em alta.
Especificaes inteis
Uma especificao um documento quase que completamente intil. Eu nunca vi uma especificao detalhada o suficiente para que seja til e precisa ao mesmo tempo. E eu j vi muito lixo construdo com base em especificaes. Desenvolver com base em especificaes a pior maneira de se escrever software, pois por definio, trata-se de programar para satisfazer uma teoria, no a realidade. Linus Torvalds, Criador do Linux (from: Linux: Linus Sobre Especificaes)
54 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
no deve ser escrito. Construa, no escreva. Se voc precisar explicar alguma coisa, tente construir um prottipo em vez de redigir um longo documento. Uma interface de verdade ou um prottipo tende a seguir caminho em direo a um produto real. Um punhado de folhas de papel, por sua vez, somente seguir caminho rumo a uma lixeira. Se um documento provavelmente nunca evoluir para um design real, no se preocupe em escrev-lo. Se o intuito de um documento transformar-lo em um modelo, v em frente. Documentos que existem separadamente da aplicao so inteis. Eles no levaro a lugar nenhum. Todos os esforos de projeto devem ser usados na evoluo do produto real. Se um documento congelado antes de se tornar uma pea real, ele est morto.
55 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Amostra Grtis
D alguma coisa de graa
um mundo barulhento l fora. Para que as pessoas o notem no meio da multido, d alguma coisa de graa. Empresas espertas sabem que dar brindes uma excelente maneira de fisgar clientes. Veja a Apple. Eles oferecem o software iTunes de graa de forma a gerar demanda para o iPod e a loja de msica iTunes. No mundo offline, as lojas fazem a mesma coisa. A Starbucks diz que uma nova compra estimulada para cada cinco amostras de bebidas que eles do aos clientes. Nada mau. Para ns, Writeboard e Ta-da list so aplicativos completamente grtis que usamos para colocar as pessoas no caminho para usar nossos outros produtos. Adicionalmente, sempre oferecemos algum tipo de verso grtis de todos os nossos aplicativos. Queremos que as pessoas experimentem o produto, a interface, a utilidade do que construmos. Uma vez fisgados, eles so muito mais propensos a atualizar para um dos planos pagos (que permitem mais projetos ou pginas e d acesso a funcionalidades adicionais como upload de arquivos e encriptao de dados com SSL).
Pedacinhos
Faa pedacinhos: crie ofertas especializadas, pequenas para que os clientes mordam. Subdivida pelo menos um produto ou servio em pedacinhos que so baratos, fceis ou divertidos. Ben McConnell e Jackie Huba, autores do Church of the Customer Blog (de What is customer evangelism?)
57 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
para ser como um trailer de cinema como o single de sucesso enviado ao rdio a msica que faz as pessoas quererem comprar sua msica. No se preocupe com pirataria dessa msica. Deixe as pessoas tocarem, copiarem, compartilharem. Tenha a confiana que, se o mundo a ouviu, iro pagar por mais. Derek Sivers, presidente e programador, CD Baby e HostBaby (de Free Promo Track)
58 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Batendo de Leve
Reduza o impacto das ms notcias com avisos prvios e tratamento privilegiado
Voc precisa divulgar uma m notcia aos usurios como um aumento de preos? Faa o anncio o mais indolor possvel, dando aos usurios um aviso prvio. Considere tambm a possibilidade de um perodo de bnus, isentando usurios antigos por um certo perodo de tempo. Estes usurios so seu ganha-po, e seu interesse faz-los sentirem-se valorizados, no explorados.
Promoo captulo 13
Lanamento de Hollywood
V de Trailer para a Prvia para o Lanamento
Se uma aplicao lanada numa floresta e no h ningum l para us-la, ela faz barulho? O ponto aqui que se fazemos o lanamento da nossa aplicao sem nenhum tipo de anncio antecipado, as pessoas no sabero sobre ela. Para construir euforia e antecipao, v com um lanamento holywoodiano: 1) Trailer, 2) Prvia e 3) Lanamento.
Trailer
Alguns meses antes do tempo, comece soltando dicas. Faa as pessoas saber no que est trabalhando. Publique um logotipo. Publique sobre o desenvolvimento no seu blog. Mantenha-se vago mas plante a semente. Alm disso levante um website onde poder coletar e-mails das pessoas interessadas. Nesse estgio, devemos comear a seduzir gurus e insiders. Essas so as pessoas que esto frente. So
59 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
os formadores de opinio. Apele para suas vaidades e status como pontos-fora-da-curva. Diga-lhes que esto tendo uma breve prvia exclusiva. Se um site como Boing Boing, Slashdot ou Digg criam links para sua aplicao, ter um monte de trfego e seguidores. Mais ainda, seu page rank no Google subir tambm.
Prvia
Algumas semanas antes do lanamento, comece a demonstrar funcionalidades. D acesso por-trsdas-cmeras s pessoas. Descreva o tema do produto. Para o Basecamp, publicamos fotos de tela e marcamos os alertas, milestones e outras funcionalidades. Tambm diga s pessoas sobre as idias e princpios por trs da aplicao. Para o Backpack, publicamos nosso manifesto antes do lanamento. Isso levou as pessoas a pensar e falar sobre a aplicao. Tambm podemos oferecer algum tipo de ingresso especial para algumas poucas pessoas para que possam comear a usar a aplicao antes do tempo. Ainda ganhamos o benefcio de ter pessoas testando como beta enquanto sentem aquele brilho especial que todos de vanguarda sentem. E novamente, encoraje as pessoas a se cadastrar para termos uma fundao de e-mails a ser usado no lanamento. Quando lanarmos nossa aplicao, teremos milhares de e-mails para pingar, o que uma grande ajuda para ganhar trao.
Lanamento
hora do lanamento. Agora as pessoas podem realmente ir ao cinema e ver nossa aplicao. Envie e-mails para aqueles que se cadastraram. Lance seu site de marketing completo. Espalhe a palavra tanto quanto possvel. Faa blogs criarem links para voc. Publique sobre seu progresso: quantas pessoas se cadastraram? Que atualizaes/refinamentos foram feitas? Entre no embalo e mantenha-se nele.
60 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
indstria para nos ajudar nos testes beta do Blinksale. Isso nos permitiu colocar o produto na frente de pessoas que sentimos que poderiam se beneficiar dele que poderiam nos ajudar a espalhar a palavra sobre o produto quando lanssemos. importante notar que no foramos ningum a escrever sobre o produto. Simplesmente queramos que fosse visto e que falassem sobre ele quando fosse lanado. No fim, se for construir euforia dessa maneira, melhor ter certeza que seu produto faz o que diz. Caso contrrio, como nuvens sem chuva. Quando o dia do lanamento chegou, enviamos e-mails para nossa lista, notificamos nossos amigos dos blogs e encorajamos o pessoal do teste beta a falar o que realmente acharam. E para nossa grande alegria, o esforo pagou grandes dividendos. Logo depois do lanamento dezenas de milhares visitaram nosso site e milhares deles se cadastraram para usar o produto. Josh Williams, fundador, Blinksale
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
pedaos que ajudam, informam e so interessantes e s anedotas que publicamos quase diariamente. Ento, quando chegou a hora de promover nosso primeiro produto, Basecamp, comeamos l. Liberamos a palavra sobre o SvN e ela comeou a se espalhar. Pessoas como Jason Kottke, os BoingBoingers, Jim Coudal e uma variedade de pessoas com blogs populares ajudaram a crescer a visibilidade e as coisas fluram. Ta-da Lists outro grande exemplo do poder do marketing baseado em blogs. Lanamos Ta-da com uma nica publicao no Signal vs. Noise e algumas semanas depois ela foi mencionada em mais de 200 blogs e mais de 12 mil pessoas se cadastraram para suas prprias contas Ta-da. Palavra sobre Backpack se espalhou ainda mais rpido. Dentro de 24 horas do lanamento, mais de 10 mil haviam se cadastrado.
Solicite Antecipadamente
Consiga euforia antecipada e cadastros acontecendo o mais rpidos possvel
J falamos sobre isso mas vale a pena repetir: consiga algum tipo de site no ar e comece a coletar e-mails o mais depressa quanto for possvel. Pegue seu nome de domnio e coloque um logotipo e talvez uma sentena ou duas que descreva, ou pelo menos d dicas sobre o que sua aplicao far. Ento deixe as pessoas dar seus endereos de e-mail. Agora voc est no caminho de ter uma fundao de pessoas prontas e esperando para serem notificadas no seu lanamento.
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Um exemplo de nossa prpria histria a Tcnica do Amarelo que Desvanesce, um mtodo que inventamos para sutilmente iluminar uma rea que recentemente mudamos em nossa pgina. Escrevemos uma publicao sobre isso na Signal vs. Noise. Essa publicao circulou e trouxe milhares e milhares de visitas pgina (at hoje est fazendo um grande trfego). A publicao funcionou tanto no nvel educacional quanto promocional. Uma lio foi aprendida e muitas pessoas que nunca saberiam sobre nossos produtos foram expostos a eles. Outro exemplo: durante nosso desenvolvimento de Ruby on Rails, decidimos tornar a infra-estrutura como cdigo aberto. Acabou sendo um movimento sbio. Demos alguma coisa de volta comunidade, construmos boa vontade, ganhamos reconhecimento para nossa equipe, recebemos respostas teis e comeamos a receber correes e contribuies de programadores por todo o mundo. Ensinar tem tudo a ver com bom karma. Pagamos antecipadamente. Ajudamos os outros. Ganhamos alguma promoo saudvel. E podemos at mesmo nos sentir mais nobres. Portanto, o que voc sabe que o mundo gostaria de ouvir?
Pague Antecipadamente
A seo de artigos e dicas em nosso blog uma das mais populares de nosso site. Passar nosso conhecimento sobre marketing por e-mail garante que nossos clientes tirem o mximo de nosso software. Se eles podem fornecer um servio melhor a seus clientes, mais provvel que tenham mais negcios, que por sua vez cria mais negcios para ns todos ganham. Dividir gratuitamente nosso conhecimento tambm ajuda a nos posicionar como especialistas na indstria e refora nossos relacionamentos com os clientes atuais. Eles sabem que nos importamos sobre qualidade do nosso trabalho. Finalmente, recebemos montanhas de trfego direcionado a partir de sites de pesquisa e bloggers que dividem nossos artigos com seus leitores. Essas so pessoas que nunca teriam ouvido falar de nosso software se no tivssesmos escrito esse artigo. David Greiner, fundador, Campaign Monitor
Comida-Funcionalidade
Eles esto famintos por isso ento sirva-os
Funcionalidades novas ou interessantes so uma grande maneira de gerar euforia para sua aplicao. Grupos de interesse especiais amam mastigar comida de funcionalidade e cuspir de volta comunidade. Tudo bem, essa foi uma analogia no muito boa mas voc entendeu o ponto. Por exemplo, usando Ruby on Rails, uma nova plataforma de desenvolvimento, geramos uma tonelada de ateno para o Basecamp dentro da comunidade de desenvolvedores. Os elementos Ajax que usamos em nossa aplicao recebeu montanhas de euforia e at mesmo levou a revista Business 2.0 a nomear a 37signals um competidor chave em Ajax junto com grandes nomes como Google, Yahoo, Microsoft e Amazon. Outro exemplo: Bloggers tomaram nota do suporte RSS do Basecamp j que foi um dos primeiros exemplos de negcios com RSS.
63 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Integrao com iCal, uma funcionalidade menor primeira vista, nos levou s notcias em uma tonelada de sites relacionados a Mac, que caso contrrio provavelmente nunca teriam mencionado nossa aplicao. Equipes pequenas tem uma perna maior na integrao de novas idias com software. Enquanto grandes empresas precisam lidar com afunilamentos de burocracia, podemos rapidamente implementar novas idias e ganhar ateno por us-las. Cavalgar junto com as tecnologias mais recentes e que mais fazem barulho um jeito efetivo e barato de construir euforia. Dito isso, no v adicionando a mais recente e obscura tecnologia apenas para ganhar mais ateno. Mas se estiver usando alguma coisa nova e merecedora de ateno, v em frente e anuncie isso para grupos de interesses especiais.
64 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
encorajar clientes j existentes a atualizar para uma conta de nvel maior quando chegam ao mximo de seu plano atual. Clientes existentes so suas melhores apostas de vendas. No se sinta envergonhado em tentar repetir negcios com pessoas que j conhecem e usam seus produtos.
Nome-Gancho
D um nome sua aplicao que seja fcil de lembrar
Um grande erro que muitas pessoas fazem pensar que o nome de sua aplicao precisa ser ultradescritiva. No se preocupe em escolher um nome que vividamente descreva o propsito de sua ferramenta; isso normalmente leva apenas a um nome genrico e esquecvel. Basecamp um nome melhor do que algo como Centro de Gerenciamento de Projetos ou ProjectExpress. Writeboard melhor do que CollaborEdit. Alm disso, no foque muito em grupos ou comits para o processo de nomeao. Escolha um nome curto, que pegue, seja memorvel e ento v com ele. E no se preocupe se no conseguir o nome de domnio exato que quer. Voc sempre pode ser criativo e chegar perto com um pouco mais de letras (ex. backpackit.com ou campfirenow.com).
Fcil o Melhor
Ser que a indstria de tecnologia no percebe que pensar em nomes que peguem e que sejam auto-explicativos os beneficiariam da mesma maneira em ltima instncia? Eles venderiam mais do que quer que seja, porque no assustariam os consumidores que pensam que esto sendo mantidos fora do club high-tech por um punhado de engenheiros arrogantes. A tecnologia avanaria mais rpido tambm. O novo produto seria mais fcil de descrever, mais fcil de usar e mais fcil de comprar o que, para as empresas, significa mais fcil de vender. David Pogue, colunista, New York Times (de O que h no nome de um produto?)
Suporte captulo 14
Sinta a Dor
Derrube as paredes entre suporte e desenvolvimento
No negcio de restaurantes, existe uma enorme diferena entre aqueles que trabalham na cozinha daqueles que esto na linha de frente lidando com clientes. importante para ambos os lados entender e simpatizar com o outro. por isso que escolas de culinria e restaurantes normalmente tero chefs trabalhando como garons para que a equipe da cozinha possa interagir com clientes e ver como realmente estar na linha de frente.
65 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Muitas empresas desenvolvedoras de software tem uma diviso similar. Designers e programadores trabalham na cozinha enquanto o suporte lida com clientes. Infelizmente, isso significa que chefs de software nunca ouvem o que o cliente realmente est dizendo. Isso problemtico porque ouvir clientes a melhor maneira de se ligar nas partes fortes e fracas do seu produto. A soluo? Evite construir paredes entre seus clientes e a equipe de desenvolvimento/design. No terceirize o suporte a seus clientes. Faa voc mesmo o suporte. Voc e sua equipe inteira, devem saber o que seu cliente est dizendo. Quando seu cliente est incomodado, voc precisa saber disso. Voc pecisa ouvir as reclamaes. Voc precisa ficar incomodado tambm. Na 37signals, todos os e-mails de suporte so respondidos pessoalmente pelo pessoal que realmente construiu o produto. Por que? Primeiro, isso fornece melhor suporte aos clientes. Eles esto recebendo uma resposta diretamente do crebro de algum que construiu a aplicao. Alm disso, isso nos mantm em contato com a pessoa que usa nossos produtos e com os problemas que esto encontrando. Quando esto frustrados, ns ficamos frustrados. Podemos dizer sinceramente que eu sinto sua dor. Pode ser tentador se apoiar em anlises estatsticas para revelar seus pontos problemticos. Mas estatsticas no so como vozes reais. Voc precisa eliminar a maior quantidade possvel de atravessadores entre voc e as vozes reais de seus clientes. As linhas de frente so onde a ao est. V at l. Faa seus chefs trabalharem como garons. Leia e-mails de clientes, oua suas frustraes, escute suas sugestes e aprenda com elas.
Treinamento Zero
Use ajuda em contexto e FAQs para que seu produto no precise de um manual ou treinamento
Voc no precisa de um manual para usar o Yahoo! ou Google ou Amazon. Ento por que voc no pode construir um produto que no requer manual? Se esforce para construir uma ferramenta que requer treinamento zero.
66 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Como fazer isso? Bem, como mencionamos antes, voc comea mantendo tudo simples. Quanto menos complexa for sua aplicao, menos precisar ajudar as pessoas sem necessidade. Depois disso, uma grande maneira de suporte pr-ativo usando ajuda em contexto e FAQs em potenciais pontos de confuso. Por exemplo, oferecemos suporte pr-ativo na tela que permite as pessoas a fazer upload de seus logotipos ao Basecamp. Algumas pessoas experimentaram um problema onde continuavam vendo um logotipo antigo por causa do cache do browser. Ento, prxima rea de envie seu logotipo, adicionamos um link a um FAQ que instrua os clientes a forar um recarregamento de seus browsers para ver o novo logotipo. Antes de fazermos isso recebamos 5 e-mails por dia sobre esse problema. Agora, no recebemos nenhum.
Resposta Rpida
Tempo rpido de atendimento em consultas de suporte devem ser prioridade mxima
Os clientes se alegram quando voc responde suas questes rapidamente. Eles esto to acostumados a respostas enlatadas que aparecem dias depois (se muito), que voc pode realmente se diferenciar dos concorrentes oferecendo uma resposta bem pensada, imediatamente. Durante o horrio comercial, respondemos 90% de nossos e-mails de requisio de suporte dentro de 90 minutos e normalmente dentro de meia hora. E as pessoas amam isso. Mesmo que no tenha uma resposta perfeita, diga alguma coisa. Voc pode comprar boa vontade com uma resposta entregue rapidamente de forma aberta, honesta. Se algum est reclamando sobre um problema que no pode ser consertado imediatamente, diga algo como ouvimos o que est dizendo e estaremos trabalhando nisso no futuro. uma grande maneira de diluir uma situao potencialmente negativa. Clientes gostam de coisas diretas e normalmente mudam de irritados para educados se responder rapidamente e de maneira direta.
Um Exrcito de Muitos
Como pode uma equipe pequena de apenas trs desenvolvedores criar um produto inovador e competir com sucesso com os caras grandes? A resposta alistar um numeroso exrcito. Lembre-se no primeiro dia que seus clientes so seu patrimnio mais importante e que so absolutamente vitais para o sucesso de longo prazo; portanto trate sua comunidade de usurios como a realeza. A maneira de competir com os caras grandes comeando pequeno e prestando ateno a cada um de seus clientes. seu cliente o primeiro que ir alert-lo de bugs, o primeiro que ir alert-lo de necessidades que no foram cumpridas e so seus primeiros clientes que carregaro a bandeira e espalharo sua mensagem. Isso no significa que seu produto tenha que ser perfeito quando for lanado. Muito pelo contrrio, lance cedo e freqentemente. Entretanto, quando seus clientes encontrarem bugs, garanta o envio de uma resposta rpida agradecendo pela sua informao.
67 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Os clientes no esperam que seu produto seja perfeito e no esperam que todas as suas funcionalidades sero implementadas. Entretanto, esperam que esteja ouvindo e mostrando que se importa. Essa uma rea onde a maioria da grandes empresas mostra um grande descaso, portanto desenvolva um senso de comunidade cedo. Na Blinklist, cada um dos e-mails de cliente respondido, normalmente dentro da primeira hora (a menos que estejamos dormindo). Tambm temos um frum online e garantimos que cada postagem e comentrio seja entendido. Igualmente importante, todos os nossos desenvolvedores recebem o feedback dos clientes e so participantes ativos nos frums de discusso online. Dessa maneira estamos, lentamente mas, certamente construindo uma comunidade ativa e leal na BlinkList. Michael Reining, co-fundador, MindValley & Blinklist
Amor spero
Esteja preparado para dizer no a seus clientes
Quando falamos de requisio de funcionalidades, o cliente nem sempre est certo. Se adicionssemos cada uma das coisas que nossos clientes pediram, ningum iria querer nossos produtos. Se fssemos obedecer cada choro de nossos clientes, o Basecamp teria: gerenciamento de tempo completo, cobrana completa, cronograma de reunies completo, sistema de calendrio completo, sistema de dependncia de tarefas completo, chats via mensagens instantneas completo, funcionalidade de wiki completo, e tudo-mais-que-puder-imaginar completo. Ainda assim, a requisio nmero 1 que recebemos nas pesquisas com os clientes manter o Basecamp simples Aqui vai outro exemplo: Apesar de algumas reclamaes, decidimos no suportar o Internet Explorer 5 (IE5) em nossos produtos. Isso era 7% do mercado que estvamos endereando. Mas decidimos que era mais importante nos preocupar com os outros 93%. Consertar bugs e testar para IE5 simplesmente no valia a pena. Em vez disso fizemos um produto melhor para todo o resto. Como uma empresa de desenvolvimento de software, voc precisa agir como um filtro. Nem tudo que todo mundo sugere a resposta correta. Consideramos todas as requisies mas o cliente nem sempre est certo. Haver tempos em que voc precisar simplesmente deixar algum irritado. Cest la vie. Relacionado a isso, crtico que voc, enquanto empresa de desenvolvimento, ame seu produto. E voc no ama seu produto se estiver cheio de um monte de coisas com as quais no concorda. Essa outra justificativa para vetar requisies de clientes que no acredita que sejam necessrias.
Em Frum Afinado
Use frums ou chats para deixar os clientes se ajudarem
68 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Frum e chats de grupo baseados na web so uma grande maneira de deixar clientes fazerem perguntar e ajudar uns aos outros. Eliminando o intermedirio esse voc voc fornece uma linha aberta de comunicao e economiza seu tempo no processo. Em nossos fruns de produtos, os clientes publicam dicas e truques, requisies de funcionalidades, histrias e mais coisas. Ns aparecemos de tempos em tempos para oferecer assistncia, mas os fruns so principalmente um lugar para a comunidade se ajudar e compartilhar experincias com o produto. Voc ficar surpreso com quantas pessoas querem se ajudar.
Ps-Lanamento captulo 15
Um Ms para melhorias
69 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Est Vivo
Um blog com atualizaes frequentes sobre um produto o melhor indicador de que essa aplicao web est com desenvolvimento ativo, um produto adorado e que existe uma luz acesa em casa. Um blog abandonado de um produto um sinal de um produto abandonado e diz que as pessoas responsveis esto dormindo no ponto. Mantenha as conversas andando com seus usurios no blog de seu produto e seja transparente e generoso
70 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
com as informaes que compartilha. Deixe a filosofia de sua empresa brilhar. Link e discuta abertamente sobre concorrentes. D dicas de funcionalidades chegando e mantenha os comentrios abertos para opinies de retorno. Um produto vivo uma coisa que fala e escuta seus usurios. Um blog frequentemente atualizado sobre um produto promove transparncia, um senso de comunidade e lealdade com a marca. Publicidade extra e de graa so bnus. Como editora da Lifehacker, eu vasculho constantemente os blogs de produtos que amo como os blogs de produtos do Google, Flickr, Yahoo, Del.icio.us e 37signals. Eu sou muito mais propensa a mencion-los do que aplicaes web que apenas enviam propaganda de imprensa unidirecional do nada e no mantm uma conversa aberta com seus usurios e fs. Gina Trapani, desenvolvedora web e editora da Lifehacker, o guia de produtividade e software
Melhor, no Beta
No use beta como uma desculpa
Ultimamente parece que tudo est em um estgio beta permanente. Isso um escapismo. Um interminvel estgio beta indica aos clientes que no estamos realmente comprometidos a liberar um produto finalizado. Isso diz, use, mas se no estiver perfeito, no nossa culpa. Beta repassa a conta ao cliente. Se no estamos confiantes o suficiente sobre nosso lanamento ento como podemos esperar que o pblico esteja? Tudo bem com betas privados. Betas pblicos so grandes bobagens. Se no est bom o suficiente para o consumo pblico ento no o d ao pblico para consum-lo. No espere seu produto atingir a perfeio. Isso no vai acontecer. Assuma responsabilidade sobre o que est lanando. Coloque para fora e chame de lanamento. Do contrrio, est apenas dando desculpas.
Todo o Tempo
Sou apenas eu ou estamos todos em beta, o tempo todo? Jim Coudal, fundador, Coudal Partners
71 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
72 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Siga o Fluxo
Esteja aberto a novos caminhos e mudanas de direo
Parte da beleza de uma aplicao web sua fluidez. No a empacotamos em uma caixa, entregamos e ento esperamos anos para o prximo lanamento. Podemos refinar e mudar na medida em que avanamos. Esteja aberto ao fato que sua idia original pode no ser sua melhor idia.
73 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Veja o Flickr. Ele comeou como um jogo online para mltiplas pessoas chamado "O Jogo que Nunca Acaba" (The Game Neverending). Seus criadores logo entenderam que o aspecto de compartilhamento de fotos do jogo era um produto mais plausvel do que o prprio jogo em si (que foi eventualmente engavetado). Esteja pronto para admitir erros e mudar o curso. Seja um surfador. Observe o oceano. Descubra onde as ondas grandes esto quebrando e ajuste-se de acordo.
Concluso captulo 16
Execuo
Qualquer um pode ler um livro. Qualquer um pode chegar com uma idia. Qualquer um tem um primo que um web designer. Qualquer um pode escrever um blog. Qualquer um pode contratar algum para grudar algum cdigo. A diferena entre voc e qualquer um ser quo bem voc executa. Sucesso tem tudo a ver com uma grande execuo. Para software, isso significa fazer um monte de coisas certas. Voc no pode somente ter uma boa escrita mas falhar em entregar as promessas na sua prosa. Design limpo de interface no vai dar certo se seu cdigo cheio de gambiarras. Uma grande aplicao no vale nada se promoo pobre significa que ningum saber sobre ela. Para pontuar grande, precisa combinar todos esses elementos. A chave balano. Se for longe demais em uma direo, est caminhando para o fracasso. Constantemente procure seus pontos fracos e foque neles at estar nivelado.
Pessoas
Vale a pena enfatizar a coisa que achamos que o ingrediente mais importante quando falamos em construir uma aplicao web de sucesso: as pessoas envolvidas. Mantras, designs de epicentro, menos software e todas essas idias maravilhosas no vo realmente importar se no tiver as pessoas certas a bordo para implement-las. Voc precisa de pessoas que so apaixonadas pelo que fazem. Pessoas que se importam pela seu artesanato e que realmente acham que um artesanato. Pessoas que se orgulham do seu trabalho, independentemente da recompensa monetria envolvida. Pessoas que suam nos detalhes mesmo que 95%
74 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
das pessoas nem saibam distinguir as diferenas. Pessoas que querem construir alguma coisa grande e no se conformam com menos. Pessoas que precisam de pessoas. Ok, no necessariamente essa ltima coisa mas no iramos resistir no jogar um pouco de Streisand na mistura. De qualquer forma, quando encontrar essas pessoas, segure-se nelas. No final, as pessoas da sua equipe faro ou quebraro seu projeto e sua empresa.
Mantenha Contato
Nos deixe saber como Caindo na Real funcionou para voc. Mande e-mail para gettingreal [at] 37signals [ponto] com. Alm disso, mantenha-se atualizado sobre as ltimas ofertas da 37signals visitando Signal vs. Noise, nosso blog sobre Caindo na Real, usabilidade, design e um monte de outras coisas. Obrigado por ler e boa sorte!
37signals Resources
37signals site Signal vs. Noise weblog Basecamp Web-based project collaboration Campfire Web-based group chat for business
75 de 76
05/06/2012 12:45
http://gettingreal.37signals.com/GR_por.php
Backpack Web-based information organizer Writeboard Web-based collaborative writing Ta-da List Web-based dead-simple to-do lists Ruby on Rails Open-source web application framework
Traduo
Organizao: Fabio Akita Agradecimentos aos seguintes tradutores: Herval Freire, Juraci Krohling Costa, Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo Kochenburger E tambm aos revisores: Mateus Del Bianco, Diogo Bispo, Davis Zanetti Cabral, Gustavo Cardoso, Ricardo Augusto Getting Real Overview
76 de 76
05/06/2012 12:45