getting real - 37signals

8/8/2019 Getting Real - 37Signals

1/69


2/69

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 vocobtm 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 comlanamento, refinamento e melhorar constantemente, o que o torna o caminho perfeito para softwarebaseado em web.Caindo na Real entrega exatamente o que os clientes precisam e elimina qualquer coisa que no precis

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

Caindo na Real pula especificaes funcionais e outras documentaes transitrias em favor de construir tereais. Uma especificao funcional para ingls ver, uma iluso de um acordo, enquanto uma pgina web prealidade. isso que seus clientes iro ver e usar. isso que importa. Caindo na Real o leva l mais rpido. signfica que est tomando decises de software baseado na coisa real em vez de noes abstratas.

Finalmente, Caindo na Real a maneira que se encaixa idealmente para software baseado em web. O mode

convencional de entregar software em uma caixa e ento esperar um ano ou dois para entregar uma atualizaest desaparecendo. Diferente de software instalado, aplicaes web podem evoluir constantemente de mandiria. Caindo na Real abre essa vantagem por tudo que ele vale.

Como Escrever Software Vigoroso

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

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

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

Cronogramas que levam meses ou mesmo anosEspecificaes Funcionais UtpicasDebates de EscalabilidadeReunies de equipe interminveisA "necessidade" de contratar dzias de funcionriosNmeros de verses sem sentidoPlanejamentos cristalinos que prevem o futuroOpes de preferncia interminveisSuporte terceirizadoTestes de usurio irreaisPapelada intilHierarquia de cima-para-baixo

Getting Real by 37signals http://gettingreal.37signals.com/GR_por.p

2 de 69 04/09/2010 10:32


3/69

Voc no precisa de toneladas de dinheiro ou uma equipe enorme ou um ciclo de desenvolvimento longo paconstruir grandes softwares. Essas coisas so ingredientes para aplicaes lentas, esfumaadas, que no muCaindo na Real usa o caminho oposto.

A importncia de ter uma filosofiaPor que se manter pequeno uma coisa boa

Como construir menosComo ir de idia realidade rapidamenteComo montar sua equipePor que voc deve fazer design de dentro para foraPor que escrever to crucialPor que voc deve fazer menos que sua concorrnciaComo promover sua aplicao e espalhar a palavraSegredos para um suporte de sucessoDicas de como manter o momento depois do lanamento... e muito mais

O foco em idia amplas. No vamos entedi-lo com trechos de cdigo detalhados ou truques de css. Vamomanter nas grandes idias e filosofias que dirigem o processo Caindo na Real.

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

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

Ou talvez voc ainda no esteja a bordo do desenvolvimento gil e estruturas de negcios, mas est louco paprender mais.

Se isso soa como voc, ento esse livro para voc

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

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


3 de 69 04/09/2010 10:32


4/69

Acreditamos que software muito complexo. Funcionalidades demais, botes demais, coisa demais para apNossos produtos fazem menos do que a concorrncia intencionalmente. Construmos produtos que funcioforma mais esperta, que parecem melhor, que lhe permitem fazer suas coisas e so mais fceis de usar.

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

Basecampvira a cabea de gerenciamento de projetos. Em vez de tabelas Gantt, grficos engraadinhos eplanilhas lotadas de estatsticas, Basecamp oferece painis de mensagens, listas de tarefas, cronograma simpescritas colaborativas e compartilhamento de arquivos. At agora, centenas de milhares concordam que a maneira. Farhad Manjoo, da Salon.com disse que Basecamp representa o futuro de software na Web.

Campfiretraz um simples chat em grupo para o contexto de negcios. As empresas conhecidas entendem quvalioso um chat persistente em tempo real pode ser. Mensagens instantneas convencionais so timas paraconversas entre duas pessoas, mas so miserveis para 3 ou mais pessoas de uma s vez. Campfire resolve eproblema e muito mais.

Backpack a alternativa para aqueles confusos, complexos organize sua vida em 25 simples passosgerenciadores de informaes pessoais. A tirada de Backpack com pginas, anotaes, lista de tarefas e avitelefones 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 YTimes o chamou de uma ferramenta de organizao muito legal.

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

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

Ruby on Rails, para desenvolvedores, um framework web completo, open source para escrever aplicao pmundo real rapidamente e facilmente. Rails toma conta do trabalho pesado para que voc possa focar na suNathan Torkington, do imprio editorial OReilly disse que Ruby on Rails incrvel. Us-lo como assistirfilme de kung-fu, onde uma dzia de frameworks maus se preparam para atacar o novato apenas para apanhde 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 emwww.37signals.com.

Apenas para tirar isso do caminho, aqui esto nossas respostas para algumas reclamaes que ouvimos de vquando:


4 de 69 04/09/2010 10:32


5/69

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

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

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

Se nosso tom parecer muito convencido, conviva com isso. Achamos que melhor apresentar idias de manenftica do que ser escorregadio sobre isso. Se parecer grosseiro ou arrogante, que assim seja. Preferimos seprovocativos do que diluir tudo com isso depende Claro, haver momentos quando essas regras precisesticadas ou quebradas. E algumas dessas tticas podem no se aplicar sua situao. Use seu julgamento eimaginao.

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

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

Entretanto, isso vai requerer alguma conversa de vendas. Venda a idia do processo Caindo na Real na suaempresa. Mostre a eles esse livro. Mostre a eles os resultados reais que voc pode atingir em menos tempo eequipes menores.

Explique que Caindo na Real uma maneira de baixo risco, baixo investimento para testar novos conceitos.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 que a equipe da Start.com usou na Microsoft. Eu observei a equipe da Start.com trabalhar. Eles no pedempermisso, disse Robert Scoble, Technical Evangelist da Microsoft. Eles tem um chefe que fornece cobertarea. E eles mordem um pequeno pedao de cada vez, fazem isso e respondem a feedback.

Lanando Start.com da Microsoft

Em uma grande empresa, processos e reunies so normais. Muitos meses so gastos em planejamento defuncionalidades e discutindo detalhes com a finalidade de todos alcanarem um acordo sobre o que a coiscerta para o cliente.

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


5 de 69 04/09/2010 10:32


6/69

reunies e discusses. Apenas lance e prove seu ponto.

Mais fcil falar do que fazer isso implica:

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

Lance menos funcionalidades, mas de qualidade.Voc no precisa usar a forma big bang com todo novo lanamento e amontoados de funcionalidades. D aousurios pedaos minsculos que eles possam digerir.

Se existirem pequenos bugs, lance to logo tenha os cenrios principais pregados e disponibilize as correebugs gradualmente depois disso. Quanto mais rpido tiver o feedback do usurio, melhor. Idias podem soatimas no papel, mas na prtica acabam sendo menos do que boas. Quanto mais cedo descobrir sobre pontofundamentais que esto errados com uma idia, melhor.

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

Sanaz Ahari, Gerente de Programa daStart.com , Microsoft

O senso comum diz que para vencer seus competidores, voc precisa estar um passo a frente. Se eles possuquatro funcionalidades, voc precisa de cinco (ou 15, ou 25). Se eles gastam X, voc precisa gastar XX. Se 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 defensivo e paranico. Empresas defensivas e paranicas no pensam para frente, eles pensam apenas no pElas 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 problemsimples, deixe os problemas cabeludos, difceis e desesperadores para os outros. Ao invs de estar um passofrente, 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 funcionalidadesMenos opes/prefernciasMenos pessoas e estrutura empresarialMenos reunies e abstraes


6 de 69 04/09/2010 10:32


7/69

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

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

Basecamp se originou em um problema: como uma empresa de design precisvamos de uma maneira simplecomunicar nossos clientes sobre os projetos. Comeamos fazendo isso atravs da extranet dos clientes, queatualizvamos manualmente. Mas modificar o HTML na mo toda vez que o projeto precisava ser atualizadsimplesmente no estava funcionando. Esses sites de projetos sempre pareciam ficar travados e eventualmeeram abandonados. Era frustrante porque nos deixava desorganizados e deixava os clientes no escuro.

Ento comeamos a procurar outras opes. Ainda assim cada ferramenta que encontrvamos ou 1) no faz

que precisvamos ou 2) era gorda de funcionalidades que no precisvamos como cobrana, controles estde acesso, planilhas, grficos, etc. Sabamos que deveria haver uma maneira melhor ento decidimos constrnossa prpria.

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

Arranhando sua prpria coceira

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

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

Como um desenvolvedor, detesto isso. O conhecimento de todas essas bombas-relgio em pequena escala naplicaes que escrevo somam-se ao meu stress. Desenvolvedores de cdigo aberto, arranhando suas prpricoceiras, no sofrem isso. Porque eles so seus prprios usurios, eles sabem a resposta correta para 90% ddecises que precisam tomar. Acho que uma das razes que as pessoas chegam em casa aps um dia duro trabalho de codificao e ainda trabalham com cdigo aberto: relaxante.

Dave Thomas,The Pragmatic Programmers

Nascido da necessidade

Campaign Monitor realmente nasceu na necessidade. Por anos nos frustramos com a qualidade das opes marketing por e-mail que existiam por a. Uma ferramenta fazia x e y mas nunca z, a prxima tinha y e z masimplesmente 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 qfizesse nossas vidas, e a de nossos clientes, um pouco mais fceis.


7 de 69 04/09/2010 10:32


8/69

Depois descobrimos que no ramos os nicos que estavam infelizes com as opes que existiam. Fizemosalgumas modificaes ao software de forma que qualquer empresa de design pudesse us-lo e comeamos aespalhar a palavra. Em menos de seis meses, milhares de designers estavam usando Campaign Monitor parainformativos por e-mail para eles mesmos e seus clientes.

David Greiner, fundador,Campaign Monitor

Voc precisa de importar sobre isso

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

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

A primeira prioridade de muitas empresas iniciantes adquirir fundos de investidores. Mas lembre-se, se noviramos para gente de fora para fundos, teremos que responder a eles tambm. Crescem expectativas. Invesquerem seu dinheiro de volta e rapidamente. O fato triste que dinheiro entrando nem sempre significa aconstruo de um produto de qualidade.

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

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

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

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

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

Dois caminhos

[Jake Walker comeou uma companhia com dinheiro de investidores (Disclive) e um sem (The Show). Aqui elediscute as diferenas entre os dois caminhos.]


8 de 69 04/09/2010 10:32


9/69

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

[Com The Show] percebemos que poderamos entregar um produto muito melhor com menos custo, apenasmais tempo. E apostamos com um pouco de nosso prprio dinheiro que as pessoas iriam esperar por maisqualidade em vez de velocidade. Mas a empresa se manteve (e provavelmente continuar sendo) uma operapequena. E desde esse primeiro projeto, estamos totalmente auto-financiados. Com apenas um pouco decriatividade de nossos fornecedores, nunca mais realmente precisamos colocar muito de nosso prprio dinhoperao. E a expectativa no era de crescer e vender, mas de crescer por crescer e continuar se beneficiandisso financeiramente.

Um comentrio deSignal vs. Noise

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

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

Se no puder encaixar tudo dentro do prazo e oramento planejados ento no aumente o tempo e o custo. vez disso, puxe o escopo para trs. Sempre existe tempo para adicionar coisas mais tarde o mais tarde et

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

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

Priorizao

Precisaremos descobrir o que realmente importante. O que vai chegar ao lanamento inicial? Isso fouma restrio que o pressionar a tomar decises difceis em vez de ficar hesitando.

Realidade

Configurar expectativas a chave. Se tentar fixar o prazo, oramento e escopo, no ser capaz de entrcom um alto grau de qualidade. Claro, provavelmente poder entregar alguma coisa, mas alguma coio que realmente quer entregar?

Flexibilidade

A habilidade de mudar a chave. Ter tudo fixado torna as mudanas difceis. Injetar flexibilidade de eapresentar opes baseadas em sua experincia real de construir o produto. Flexibilidade seu amigo

Nossa recomendao: abaixo o Escopo. melhor fazer meio-produto do que um produto meia-boca (mais s


9 de 69 04/09/2010 10:32


10/69

isso depois).

Um, dois, trs ...

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

Fred Brooks,engenheiro de software e cientista da computao

Algumas vezes a melhor maneira de saber como sua aplicao deve ser saber o que ela no deve ser. Descinimigo 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 g

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

Entendemos que gerenciamento de projetos no sobre tabelas, grficos, relatrios e estatsticas sobrecomunicao. Tambm no sobre um gerente de projetos sentando l no alto e distribuindo um plano de pr 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 (incluindcliente). 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 defuncionalidades. Ento decidimos enfatizar em um ngulo sem frescura. Criamos uma aplicao que permpessoas compartilhar e colaborar nas idias de maneira simples, sem incomod-las com funcionalidadesno-essenciais. Se no era essencial, deixamos de fora. E em apenas trs meses depois do lanamento, mais 100 mil Writeboards foram criados.

Quando comeamos no Backpack nosso inimigo era estrutura e regras rgidas. As pessoas devem ser capazeorganizar suas informaes de sua prpria maneira no baseado em uma srie de telas pr-formatadas ou umontanha de campos de edio obrigatrios.

Um bnus que voc recebe em ter um inimigo uma mensagem de marketing muito clara. As pessoas esto

de conflitos. E tambm entendem um produto comparando-o com outros. Com um inimigo escolhido, voc enviando uma histria que eles querem ouvir. No s eles vo entender seu produto melhor e mais rpido, mvo 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 demoutros produtos e voc vai comear a limitar sua maneira de pensar. D uma olhada e v em frente para suaprpria 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 funciona para a concorrncia e ento tentar super-los em ser mais barato que seu competidor que compepreo, ou mais rpido que seu competidor que compete na velocidade. O problema que uma vez que oconsumidor j comprou a histria de algum e acredita nessa mentira, persuad-lo a mudar a mesma coisa persuad-lo a admitir que estava errado. E as pessoas odeiam admitir que esto erradas.


10 de 69 04/09/2010 10:32


11/69

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

Seth Godin , autor/empresrio (deSeja um Mentiroso Melhor )

Qual o problema chave?

Uma das maneiras mais rpidas de se colocar em problemas olhar o que seus competidores esto fazendo.foi especialmente verdade para ns na BlinkList. Desde que lanamos houveram cerca de 10 outros serviobookmarking social que foram lanados. Algumas pessoas at comearam a gerar planilhas online comcomparaes funcionalidade a funcionalidade.

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

Michael Reining, co-fundador, MindValley& Blinklist

Quanto menos sua aplicao se tornar uma rotina para construir, melhor ser. Mantenha pequena e gerencipara que possa realmente apreciar o processo.

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

A preseno de paixo

Em design, onde o significado normalmente e controversamente subjetivo ou dolorosamente indecifrvel,poucas coisas so mais aparentes e lcidas do que a presena de paixo. Isso verdade seja quando o desigproduto o agrada ou o deixa frio; em ambos os casos difcil no detectar o investimento emocional das mo construram.

Entusiasmo se manifesta prontamente, claro, mas indiferena igualmente inesquecvel. Se seu compromissvem com paixo genuna para o trabalho s mos, isso se torna um vazio que quase impossvel de conciliaimporta o quo elaborado ou atrativo o design.

Khoi Vinh,Subtraction.com

A padaria

Os negcios americanos neste momento realmente so sobre desenvolver idias, torn-las lucrativas, vend

enquanto so lucrativas e ento sair fora ou diversificar. justamente sobre sugar tudo. Minha idia era: apcozinhar, venda seu po, as pessoas gostam disso, venda mais. Mantenha a padaria indo porque voc est faboa comida e as pessoas esto felizes.

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


11 de 69 04/09/2010 10:32


12/69

(da Salon.com People | Ian MacKaye)

Quanto mais massa tiver um objeto, mais energia necessria para mudar sua direo. uma verdade tantomundo dos negcios como para o mundo fsico.

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

Contratos de longo prazoExcesso de pessoasDecises permanentesReunies sobre outras reuniesProcessos BurocrticosInventrio (fsico ou mental)Priso em hardware, software e tecnologiaFormatos proprietrios de dadosPassado mandando no futuroPlanejamentos de longo prazoPolticas de escritrio

Pensamentos just-in-timeEquipes com membros multi-tarefaAbraar limitaes, sem aument-lasMenos software, menos cdigoMenos funcionalidadesEquipes pequenasSimplicidadeInterfaces reduzidasProdutos de cdigo abertoFormatos de dados abertosUma cultura aberta que torna fcil admitir erros

Menos massa permite mudar de direo rapidamente. Voc pode reagir e evoluir. Pode focar em boas idiasderrubar as ruins. Pode ouvir e responder a seus clientes. Pode integrar novas tecnologias agora em vez de mtarde. 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 mencdigo e menos funcionalidades. Do outro lado est uma empresa massuda que tem um produto significativcom mais software e mais funcionalidades. Ento, digamos que uma nova tecnologia como Ajax ou um novconceito como tags apaream por a. Quem estar apto a adaptar seu produto mais rpido? A equipe com masoftware e mais funcionalidades, com um planejamento de 12 meses ou a equipe com menos software, men


12 de 69 04/09/2010 10:32


13/69

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 domercado. A empresa com mais massa ainda estar discutindo as mudanas, ou empurrando-as junto ao procburocrtico, enquanto a empresa com menos massa j haver feito a troca. A empresa com menos massa estpassos 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 mu

suas prioridades, misturar produtos e focar. E, mais importante,podem mudar sua maneira de pensar.

A mudana sua melhor amiga. Quanto mais caro for para fazer uma mudana, menos chances ela ter de srealizada. Se seus competidores podem mudar mais rpido, voc se encontra em enorme desvantagem. Se amudana for cara demais, voc est morto.

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

E lembre-se: Mesmo com todo o dinheiro, marketing e pessoas do mundo voc no pode comprar a agilidadser pequeno.

Emergencia

A emergencia um dos princpios fundamentais da agilidade, e a coisa mais prxima da magia pura.Propriedades emergenciais no so projetadas ou vm prontas, elas simplesmente acontecem como um resudinmico do resto do sistema. Emergencia vem do Latim da metade do sculo 17, que significa ocorrncprevista. Voc no pode planej-la ou agend-la, mas pode cultivar um ambiente em que a deixe ocorrer, sebeneficiando dela.

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

computador pode usar apenas trs regras simples (parecidas com no colida-se com outros) e de repente tem comportamento complexo quando o bando vai batendo as asas graciosamente pelos cus, se remodelantorno de obstculos e assim por diante. Nenhum desses comportamentos avanados (como se remodelar na 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, cocom 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 de comportamento emergente. A maioria das tentativas de otimizao amarrando alguma coisa muitoexplicitamente reduz a extenso e escopo de interaes e relacionamentos, que a origem da emergencia.

exemplo do bando de pssaros, assim como sistemas bem-desenhados, so as interaes e relacionamentos criam os comportamentos interessantes.

Quanto mais amarramos as coisas, menos espao deixamos para uma soluo criativa e emergente. Seja tan


13 de 69 04/09/2010 10:32


14/69

travando requisitos, antes de serem bem entendidos ou otimizando o cdigo prematuramente, como inventanavegaes e cenrios de fluxo de trabalho complexas, antes de deixar o usurio final usar o sistema, o resuo mesmo: um sistema exageramente complicado e estpido ao invs de um sistema limpo e elegante que apra emergencia.

Mantenha pequeno. Mantenha simples. Deixe acontecer.

Andrew Hunt,The Pragmatic Programmers

Para a primeira verso da sua aplicao, comece com apenas trs pessoas. Este o nmero mgico que lhe fora de trabalho suficiente sem lhe tirar o dinamismo e a agilidade. Comece com um desenvolvedor, um dee 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, esvalorosa. Pessoas talentosas no precisam de recursos infinitos. Elas prosperam no desafio de trabalhar comrestries e usam a criatividade para resolver problemas. Falta de recursos humanos fora-o a lidar com sacrmais cedo, o que timo. Far voc entender suas prioridades mais cedo do que mais tarde. E voc estar apara 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 pessodiferentes ou diminuir sua verso inicial. Lembre-se, tudo bem voc lanar sua primeira verso pequena econsistente. Voc rapidamente perceber se sua idia tem futuro e, se tiver, voc ter uma base simples e limpara progredir.

Lei de Metcalfe e equipes de projeto

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

Marc Hedlund, entrepreneur-in-residence naOReilly Media

O fluxo da comunicaoA comunicao flui mais facilmente em equipes pequenas do que em grandes. Se voc a nica pessoa no pcomunicao simples. O nico caminho de comunicao entre voc e o cliente. Com o aumento do nmpessoas em um projeto, aumenta tambm o nmero de caminhos de comunicao. E no aumenta de formaaditiva, como o nmero de pessoas, aumenta de forma multiplicativa, proporcional ao quadrado do nmero pessoas.

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


14 de 69 04/09/2010 10:32


15/69

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 inoe 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 administrarTrabalhos para clientes j existentesUma diferena de 7 horas (O David estava programando na Dinamarca e o resto de ns nos Estados UUma equipe pequenaNenhum finaciamento externo

Ns sentimos a depresso sem suficiente. Ento mantivemos nossos pratos pequenos. Dessa maneira spoderamos colocar at onde coubesse. Pegvamos grandes tarefas e quebrvamos em pedaos menores quatcavamos 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 mesoftware. Demos s pessoas apenas as funcionalidades suficientes para resolver seus problemas do seu jeitoento saamos do caminho. A diferena de tempo e distncia entre ns nos tornou mais eficientes na nossacomunicao. Em vez de nos encontrarmos em pessoa, comunicvamos exclusivamente via mensagensinstantneas e e-mail, o que nos forava a ir direto ao ponto rapidamente.

Restries normalmente so vantagens disfaradas. Esquea investimento externo, longos ciclos de lanamresolues rpidas. Em vez disso, trabalhe com o que voc tem.

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

Jef Raskin, autor (dePor que Software como )

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

Muitas pequenas empresas cometem o erro de tentarem atuar grande. como se elas entendessem seu tama

como uma fraqueza que precisa ser encoberta. Muito ruim. Ser pequeno pode realmente ser uma grandevantagem, especialmente quando isto representa comunicao.

Pequenas empresas gostam de menos formalidades, menos burocracia e mais liberdade.Menores empresas somais prximas dos clientes por padro. Isto significa que elas podem se comunicar com seus clientes de form


15 de 69 04/09/2010 10:32


16/69

mais direta e pessoal. Se a empresa pequena, pode-se usar uma linguagem familiar ao invs de jargo. Seuseu produto podem ter uma voz humana ao invs de soar como um zumbido corporativo. Ser pequeno signipoder falar com os clientes, e no se submeter a eles.

H tambm vantagens na comunicao interna em pequenas empresas. Voc pode dispensar formalidades. Nnecessidade de processos rduos e mltiplas assinaturas para tudo. Todos no processo podem falar abertamehonestamente. Este fluxo livre de idias uma das grandes vantagens de ser pequeno.

Seja orgulhoso, desafiadoramente sincero

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

Khoi Vinh,Subtraction.com

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

Edward Knittel, Diretor de Vendas e Marketing,KennelSource

Explicitamente defina a viso principal da sua aplicao. O que a sua aplicao defende? Do que se trata? Ade comear o design ou a codificao de qualquer coisa voc precisa saber o propsito do seu produto a vPense grande. Para que ele existe? O que o torna diferente de outros produtos similares?

A viso ir guiar suas decises e o manter em um caminho consistente. Sempre que houver um ponto duvidpergunte, Estamos nos mantendo coerentes viso?

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

Basecamp: Gerenciamento de Projetos comunicaoBackpack: Junte as pontas soltas da vidaCampfire: Chat em grupo ao invs de Mensagens Instantneas ruinsTa-da List: Competindo com os post-itsWriteboard: Word coisa demais


16 de 69 04/09/2010 10:32


17/69

Com o Basecamp, por exemplo, a viso era Gerenciamento de Projetos comunicao. Sentimos fortemeque comunicao efetiva em um projeto leva propriedade coletiva, ao envolvimento, ao investimento e aomomento. Traz todos mesma pgina trabalhando em direo a um objetivo comum. Sabamos que se Basepudesse atingir isso, todo o resto entraria na linha.

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

Filosofia do Quadro Branco

Andy Hunt e eu uma vez escrevemos um sistema de transaes de carto de dbito. Um grande requisito erusurio de um carto de dbito no deveria ter a mesma transao aplicada sua conta duas vezes. Em outrpalavras, no importa que tipo de falha pudesse acontecer, o erro deveria ir para o lado de no processar atransao em vez de processar e duplic-la.

Ento, escrevemos isso no nosso quadro-branco compartilhado em letras grandes: Erros a favor dos usurio

Isso se juntou a outra meia-dzia de mximas. Juntas, elas guiaram todas aquelas decises complicadas quefazem quando se constri algo complexo. Juntas, essas leis deram forte coerncia interna e grande consistnexterna 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 qu

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

Guy Kawasaki , autor (de Make Mantra)

Somos loucos por detalhes.

O espao entre objetosO espao perfeito entre linhasA cor perfeitaAs palavras perfeitasQuatro linhas de cdigo em vez de sete90% vs 89%760px vs 750px$39/ms vs $49/ms

Sucesso e satisfao esto nos detalhes

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


17 de 69 04/09/2010 10:32


18/69

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

Quantas vezes se encontrou travado em um nico design ou elemento de cdigo por um dia inteiro? Quantase deu conta de que o progresso que fez hoje no foi progresso real? Isso acontece quando voc foca nos decedo demais no processo. H tempo suficiente para ser um perfeccionista. Apenas faa isso mais tarde.

No se preocupe com o tamanho da fonte do cabealho na primeira semana. Voc no precisa empregar o toperfeito de verde na segunda semana. No precisa mover em trs pixels o boto de submeter na terceirasemana. Apenas coloque as coisas na pgina por enquanto. Ento use. Garanta que funciona. Mais tarde vo

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

O Diabo est nos Detalhes

Quase me cansei da atitude entre nos detalhes imediatamente depois de tomar algumas aulas de desenho comear a desenhar os detalhes imediatamente pode ter certeza que o desenho ser uma droga. De fato, vocperdendo completamente o ponto.

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

Funciona do grande para o pequeno. Sempre.

Patrick Lafleur, Creation Object Inc. (deSignal vs. Noise)

Voc precisa realmente se preocupar em escalar para 100.000 usurios hoje se vai levar dois anos para cheg

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

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

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

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


18 de 69 04/09/2010 10:32


19/69

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

O cliente nem sempre tem razo. A verdade que voc ter que separarquem certo e quem erradopara seuaplicativo. A boa notcia que a Internet torna mais fcil do que nunca encontrar as pessoas certas.

Quando ns desenvolvemos o Basecamp, focamos nosso marketing em firmas de design. Por restringir nossmercado desta forma, ficou mais fcil atrair clientes passionais que, por sua vez, iriam evangelizar o produtSaiba para quem seu aplicativo realmente se destina e foque-se em agradar este pblico.

A Melhor Deciso Que J Tomamos

A decisio de direcionar o Campaign Monitor estritamente para o mercado de web design foia melhor escolhaque j fizemos. Ela nos permitiu identificar facilmente quais recursos seriam genuinamente teis e, maisimportante, quais recursos deixar de fora. No s atramos mais clientes por mirar em um grupo menor de pcomo todos esses clientes tinham necessidades similares que tornavam nosso trabalho muito mais fcil. H umonte de recursos no Campaign Monitor que seriam inteis para qualquer um exceto um web designer.

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

David Greiner, fundador,Campaign Monitor

Conseguirei escalar minha aplicao quando milhes de pessoas comearem a us-la?

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

Por exemplo, ns rodamos o Basecamp em um nico servidor durante o primeiro ano. Por termos iniciado cuma configurao simples, conseguimos implementar em uma nica semana. Ns no comeamos com umaglomerado de 15 computadores nem gastamos meses nos preocupando com escalabilidade.


19 de 69 04/09/2010 10:32


20/69

Tivemos problemas? Alguns. Mas tambm descobrimos que a maior parte do que temamos, como um breveperodo de lentido, no era o fim do mundo para os clientes. Desde que voc mantenha as pessoas informaseja honesto sobre a situao, elas entendero. Em retrospecto, somos contentes por no termos atrasado olanamento em meses para criar a configurao perfeita.

No comeo, priorize construir um produto slido em vez de obsecar-se com escalabilidade ou fazendas deservidores.Crie uma grande aplicao e depois se preocupe com o que fazer quando ela se tornaranimalmente bem-sucedida.Do contrrio voc o corre o risco de desperdiar energia, tempo e dinheiro seprendendo a algo que nunca acontecer.

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

Voc ter que revisar de qualquer jeito

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

Dare Obasanjo, Microsoft (de Scaling Up and Startups)

Algumas pessoas defendem que o software deve ser agnstico. Dizem que arrogante da parte dosdesenvolvedores limitar a funcionalidade ou ignorar pedidos de novos recursos. Dizem que o software devesempre o mais flexvel possvel.

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

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

Um timo exemplo o projeto original do wiki. Ward Cunningham e seus amigos deliberadamente desprovewiki de muitos recursos que no passado eram considerados parte indispensvel da colaborao de documenEm vez de atribuir cada mudana do documento a uma pessoa determinada, eles removeram muito da

representao visual de propriedade. Eles tornaram o contedo atemporal e destitudo de ego. Eles decidirano importava quem escreveu o contedo ou quando ele foi escrito. E isso fez toda a diferena. Essa decisdespertou nas pessoas um senso de comunidade e foi pea-chave no sucesso da Wikipdia.

Nossos aplicativos trilharam um caminho parecido. Eles no tentam ser todas as coisas para todas as pessoatm uma atitude. Eles vo atrs de clientes que so no fundo parceiros. Eles tm apelo para as pessoas quepartilham de nossa viso. Ou se est do lado de dentro ou se est do lado de fora.


20 de 69 04/09/2010 10:32


21/69

Cuidado com a viso faz-tudo no desenvolvimento de uma aplicao web. Considere todas as boas idiasaparecerem ao longo do processo e voc acabar apenas com uma verso meia-boca do seu produto. O querealmente precisa montar meio produto que detone.

Atenha-se ao que verdadeiramente essencial. Boas idias podem ser tiradas da gaveta.Pegue tudo que vocacha 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 Basecampapenas com a seo de mensagens. Ns sabamos que isso era o corao do aplicativento, de incio, ignoramos asmilestones, listas de tarefas e outros itens. Isso nos permitiu embasar as decisesfuturas no uso real e no em palpites.

Comece com um aplicativo simples e inteligente e deixe-o ganhar impulso. S ento pense em adicionar coifundao slida que voc j construiu.

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

Quando lanamos oCampfire, ns recebemos essas perguntas das pessoas que usavam o produto pela primeiravez:Porque marcar o horrio apenas a cada 5 minutos? Porque no marcar a hora de cada linha do batepapo?Resposta: Porque no importa. Com que frequncia voc precisa ter controle de uma conversa segundo asegundo, ou mesmo minuto a minuto? Certamente no 95% do tempo. Marcar o horrio a cada 5 minutos suficientes porque qualquer outra frequncia mais especfica no importa.

Porque vocs no permitem negrito ou itlico ou formatao colorida nos batepapos?Resposta: Porque noimporta. Se voc necessita enfatizar algo, use a boa e velha trava de maisculas ou coloque alguns * em volpalavra ou frase. Essas solues no requerem nenhumsoftwareadicional, suporte tcnico, capacidade deprocessamento ou curva de aprendizado. Alm disso, formatao de texto num simples batepapo baseado etexto no importa.

Porque vocs no mostram o total de pessoas na sala?Resposta: Porque no importa. O nome de todos estlistado, ento voc sabe quem est a, que diferena faz saber se h 12 ou 16 pessoas? Se isso no muda o scomportamento ento isso no importa.

Seria legal ter essas coisas? Claro. Elas so essenciais? Elas realmente importam? No. Por isso foram deixafora. Os melhores designers e os melhores programadores no so os com as melhores habilidades, ou os demais geis, ou os que podem assoviar e chupar cana com o Photoshop ou sua plataforma preferida, e sim aqque 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 temppensando no que no importa, voc atingir nveis de produtividade que voc jamais imaginou.


21 de 69 04/09/2010 10:32


22/69

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 b

atravs de toda uma cadeia de eventos (exemplo:design, implementao, testes etc.). Uma vez que estfuncionalidade est l, voc est preso a ela. Apenas tente remov-la e veja o quo irados ficaro os clientes

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

por isso que voc tem que comear com um no. Cada novo pedido de funcionalidade que vem at ns

ns encontra um no. Ns ouvimos mas no agimos. A resposta inicial agora no. Se o pedido continuaparecer, ento sabemos que hora de um olhar mais profundo. Somente ento ns comeamos a pensar nafuncionalidade de fato.

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

Ns no queremos milhares de funcionalidades

Steve Jobs deu uma pequena apresentao sobre oiTunes Music Storepara um pessoal de uma gravadoraindependente. Minha fala favorita nesse dia foi quando as pessoas insistiam em levantar a mo perguntandofaz [x]?, Voc planeja adicionar [y]?. Finalmente Jobs disse, Calma, calma abaixem seus braos. Ousei que vocs tem milhares de idias de funcionalidades bacanas para o iTunes. Ns tambm. Mas no queremilhares de funcionalidades. Isso seria horrvel. Inovao no dizer sim para tudo. dizer NO para tudoexceto as funcionalidades mais cruciais.

-Derek Sivers, presidente e programador,CD Babye HostBaby(from Diga NO por padro)

Mesmo que uma funcionalidade passe o estgio do no, voc ainda precisa expor seus custos ocultos.

Por exemplo, fique de alerta comloopsde funcionalidades, ou seja, funcionalidades que levam a maisfuncionalidades. Ns recebemos pedidos para adicionar uma aba de reunies ao Basecamp. Parece simples atque 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 suporteIsso sem mencionar que ns teramos que modificar as imagens de promoo, as pginas do tour, pginas dofaq/ajuda, contrato de prestao de servio e mais. Antes que voc note, uma idia simples pode ser tornar udor de cabea enorme.


22 de 69 04/09/2010 10:32


23/69

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

Se voc lanar um programa de filiao, voc teria os sistemas prontos para fazer a contabilidade e ospagamentos? Talvez seria melhor voc deixar as pessoas ganhar descontos nas suas taxas de filiao ao invescrever, assinar e enviar cheques todos os meses.

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

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

No force convenes. Ao invs disso, faa seusoftwarede modo generalista, assim todos podem encontrar suasprprias solues. D s pessoas s o suficiente para resolver os problemas delas ao modo delas. E ento saicaminho.

Quando criamos aTa-da List , ns intencionalmente omitimos uma srie de coisas. No h como designar umatarefa 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 descocomo resolver seus problemas sozinhas. Se elas quisessem adicionar uma data para uma tarefa, elas poderia


23 de 69 04/09/2010 10:32


24/69

inserir (Prazo: 7 de Abril de 2006) na frente do item. Se elas quisessem categorizar, poderiam simplesmentecolocar [Livros] na frente do item. Ideal? No. Infinitamente flexvel? Sim.

Se tentssemos criarsoftwarepara, especificamente, cuidar desses casos, ns estaramos o tornando menos tipara 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 encosuas prprias solues e convenes dentro de sua estrutura geral.

Os clientes querem absolutamente tudo. Eles viro com uma avalanche de pedidos de funcionalidades. D uolhada nos fruns de nossos produtos; A categoria pedido de funcionalidade sempre sobrepuja as com largvantagem.

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

Claro que no podemos culpar as pessoas por pedir funcionalidades. Ns as encorajamos e queremos ouvir elas tem a dizer. A maior parte das funcionalidades que inserimos em nossos produtos comearam como sugde nossos clientes. Mas, como dissemos antes, sua primeira resposta deve ser um no. Ento o que voc faz todos esses pedidos? Onde voc os guarda?Como voc os gerencia? Voc no faz isso. Voc apenas os l eento 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 preocuem organizar e guardar cada pedido que aparecer. Deixe seus clientes serem sua memria. Se a funcionalidarealmente necessria, eles te lembraro at que voc no consiga esquecer.

Como ns chegamos essa concluso? Quando ns lanamos o Basecampns colocvamos todos os pedidos denovas funcionalidades em uma lista de tarefas. A cada repetio de um pedido, ns marcvamos com um I( II, III ou IIII etc). Ns imaginvamos que um dia iramos revisar a lista e trabalhar indo das mais para as mpopulares.

Mas a verdade que nunca olhamos para a lista novamente. Ns j sabamos o que precisava ser feito porqunossos clientes nos lembravam constantemente fazendo sempre os mesmos pedidos. No havia necessidadeuma lista ou grupos de anlise, porque tudo estava acontecendo em tempo real. Voc no pode esquecer o qimportante 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 vezemelhor apenas dizer no e manter sua viso de produto.


24 de 69 04/09/2010 10:32


25/69

A maior parte das enquetes e pesquisas sobresoftwareso 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 quseria?, 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 aqual 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 fo

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

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

Rodar o software a melhor maneira de fazer acontecer, rena sua equipe e jogue fora idias que no funciEsta deve ser sua prioridade nmero um.

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

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

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

As coisas reais levam ao acordoQuando um grupo de pessoas diferentes tentam encontrar o que harmonioso suas opinies tendem a conse eles esto rascunhando coisas reais em larga escala. Claro, se esto fazendo um esboo ou gerando idiasvo concordar. Mas se voc comea fazendo coisas reais, tendem a chegar a um acordo.

Christopher Alexander, Professor de Arquitetura(de Contrastando Conceitos de Harmonia na Arquitetura)

Faa Funcionar o Mais Rpido Possvel

Eu no lembro de nenhum projeto de software que estive envolvido grande ou pequeno que tenha tido sem termos de prazos, custos ou funcionalidades que tenha comeado com um longo perodo de planejamentdiscusso, e sem desenvolvimentos concorrentes. simplesmente muito fcil e s vezes divertido, jogar o ptempo fora inventando funcionalidades que acabam sendo desnecessrias ou que no sero implementveis


25 de 69 04/09/2010 10:32


26/69

Isso se aplica a qualquer tipo de desenvolvimento e chegar a alguma coisa real e rodando um mantra fractno se aplica apenas a projetos como um todo, pelo menos igualmente aplicvel ao desenvolvimento decomponentes de pequena escala, dos quais a aplicao feita.

Quando h trabalho de implementao de um componente chave, desenvolvedores querem entender como no trabalhar em conjunto com suas partes da aplicao e iro geralmente tentar us-lo assim que puderem.Mesmo que a implementao no esteja perfeita ou completa no incio, estas colaboraes prematurasnormalmente levam a interfaces bem definidas e funcionalidades que fazem exatamente o que se espera del

Matt Hamer, desenvolvedor e gerente de produtos,Kinja

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-analize-as e ento comece de novo.

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

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

Talvez voc seja mais esperto do que eu

Talvez voc seja BEM mais esperto do que eu.

Isto totalmente possvel. De fato, isto provvel. De qualquer maneira, se voc como a maioria das pessento como eu, tem problemas imaginando aquilo que no consegue ver e tocar.

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

um tigre entra na sala e como limpar tudo depois de uma enchente devastadora. Infelizmente somos terrveiplanejar adiante, em compreender ramificaes das nossas aes e em priorizar as coisas que realmente temimportncia.

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

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

E esta ltima frase explica porque voc deve desenvolver desta maneira e como pode querer promover/lanTorne sua histria direta. Garanta que as peas funcionem. Ento lance e revise. Ningum to esperto quatodos ns juntos.


26 de 69 04/09/2010 10:32


27/69

Seth Godin , autor/empreendedor

Aqui vai o processo que usamos para Cair na Real:

Traga idias tona. O que este produto ir fazer? Para o Basecamp, ns olhamos para nossas prpriasnecessidades. Queramos publicar atualizaes de projeto. Queramos participao dos clientes. Sabamos qprojetos tinham datas-chave. Queramos centralizar arquivos para que as pessoas pudessem revisar coisas ancom facilidade. Queramos ter uma viso da figura maior, uma vista area do que estava acontecendo com tos 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? Csaberemos quando ser til? O que exatamente faremos? Isso sobre idias de alto nvel, nao discusses nodos pixels. Nesse estgio, esses tipos de detalhe simplesmente no tm sentido.

Esboos so rpidos, sujos e baratos e exatamente como voc quer comear. Desenhe coisas. Rabisque coCaixas, crculos, linhas. Arranque as idias da cabea para o papel. O objetivo nesse ponto deve ser convertconceitos em designs grosseiros de interface. Esse passo apenas sobre experimentao. No h respostaserradas.

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

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

No escreva nenhum cdigo de programao ainda. Apenas faa um prottipo em html e css. A implementavem depois.

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

Durante todo esse processo, se lembre de permanecer flexvel e esperar mltiplas iteraes. Voc deve se selivre para jogar fora qualquer parte entregvel de qualquer passo particular e comear novamente se ela se mlixo. natural passar por esse ciclo mltiplas vezes.


27 de 69 04/09/2010 10:32


28/69

Nos deparamos com uma deciso difcil: quantas mensagens inclumos em cada pgina? A primeira inclinapode ser em dizer, Vamos apenas tornar isso uma preferncia onde as pessoas possam escolher 25, 50 ou 1Entretanto, essa a forma mais simples. Apenas tome a deciso.

Em vez de usar nossa experincia para escolher o melhor caminho, deixamos nas mos dos clientes. Pode pque estamos fazendo um favor a eles mas apenas estamos lhes dando mais trabalho (e provavelmente eles jocupados o suficiente). Para os clientes, telas de preferncia com uma quantidade infinita de opes so umde cabea, no uma bno. Clientes no deveriam ter que pensar sobre cada nfimo detalhezinho no colesse peso sobre eles quando deveria ser sua responsabilidade.

Preferncias tambm so ms porque criam mais software. Mais opes requerem mais cdigo. E tambm a

tem todo o teste extra e design que precisamos fazer. E ainda vamos acabar com permutaes de preferncitelas que nunca usaremos. Isso significa bugs que no sabemos a respeito: layouts quebrados, tabelas explodproblemas estranhos de paginao, etc.

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

Sim, podemos tomar uma deciso ruim. Mas e da? Se fizermos isso, as pessoas vo reclamar e nos dizer sobisso. 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 importanpodem ser funcionalidades de interface cruciais. Mas cada um tem um preo e temos que considerarcuidadosamente seu valor. Muitos usurios e desenvolvedores no entendem isso e acabam com muito custopouco valor por seus dlares de preferncias acho que se formos duramente disciplinados sobre ter bonspadres Que Apenas Funcionam, em vez de adicionar preferncias folgadamente, isso naturalmente leva ainterface de usurio como um todo na direo certa.

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

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

Mas espere, e se ferramos e tomamos a deciso errada? Tudo bem.Isso no cirurgia de crebro, umaaplicao web. Como estamos dizendo, provavelmente teremos que rever funcionalidades e idias mltiplas


28 de 69 04/09/2010 10:32


29/69

durante o processo de qualquer forma. No importa quanto planejamos, com certeza estaremos meio erradoqualquer jeito. Ento no faa essa coisa de pausa para anlise. Isso apenas desacelera o progresso ecompromete a moral.

Em vez disso, avalie a importncia de seguir em frente. Entre no ritmo de tomar decises. Tome uma decisrpida 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 demaisenquanto 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 assincontrato 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 = 1Idia mais ou menos = 5Boa Idia = 10Grande Idia = 15Brilhante Idia = 20

Nenhuma execuo = $1Execuo Fraca = $1.000Execuo mais ou menos = $10.000Boa Execuo = $100.000Grande Execuo = $1.000.000Brilhante 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 execupara valer $20.000.000.

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

Derek Sivers, presidente e programador,CD Babye HostBaby

No h substituto para pessoas reais usando sua aplicao de maneiras reais. Pegue dados reais. Receba feereal. Ento aprimore baseado nessa informao.

Testes de usabilidade formais so muito duros. Configuraes de laboratrio no refletem a realidade. Se ficsobre os ombros de algum, teremos alguma idia do que est funcionando ou no mas as pessoas normalmno agem bem de frente para as cmeras. Quando outra pessoa est olhando, as pessoas so especialmente mcuidadosas para no cometer erros sendo que erros so exatamente o que estamos procurando.


29 de 69 04/09/2010 10:32


30/69

Em vez disso, lance verses beta para alguns poucos selecionados dentro da prpria aplicao real. Faa cousem as funcionalidades do beta ao lado das funcionalidades lanadas. Isso ir expr essas funcionalidades 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 beta separada s receber uma leve navegao. A verso real, com algumas funcionalidades beta misturadarecebero o fluxo de uso completo.

O Livro Beta

Se desenvolvedores esto nervosos liberando seus cdigos, ento editores e autores esto assustados lananseus livros. Uma vez que o livro est fixo no papel, visto como uma coisa cabeluda mudar (na verdade nomas percepo e lembranas de problemas com velhas tecnologias ainda persistem na indstria). Ento, edipassam 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 desenvolvedored o livro agora queremos aprender Rails. Mas eu ca no pensamento de um editor. No est pronto ainddizia. Mas a presso da comunidade e trocas de idias com David Heinemeier Hansson mudaram minha forpensar. Lanamos o livro em formato pdf cerca de 2 meses antes de ficar completo. Os resultados foramespetaculares. No apenas vendemos um monte de livros, mas recebemos feedback muito feedback. Confum sistema automatizado para capturar os comentrios dos leitores, e no final tivemos quase 850 relatos de de digitao, erros tcnicos e sugestes para novo contedo. Quase todos encontraram seu caminho para o lfinal.

Foi uma situao ganha-ganha: consegui entregar um livro muito melhor e a comunidade teve acesso antecialgo que eles queriam. E se voc est numa corrida competitiva, ter algo antecipado ajuda as pessoas a secomprometerem com voc e no com sua competio.

Dave Thomas,The Pragmatic Programmers

Faa isso rpido1. Decida se vale a pena fazer, e se for:2. Faa rpido No perfeito. Apenas faa;3. Grave. Faa upload. Publique;4. Veja o que as pessoas acham.

Embora eu esteja sempre relutante em adicionar novas funcionalidades s coisas, quando tenho aquele mom"isso!" de deciso de que alguma coisa vale a pena fazer, normalmente est no ar no website algumas horasdepois, com falhas mas lanado, deixando o feedback guiar o futuro dos refinamentos nele.

Derek Sivers, presidente e programador,CD Babye HostBaby

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

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


30 de 69 04/09/2010 10:32


31/69

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

Tarefas Menores e Cronogramas Menores

Desenvolvedores de software so uma espcie especial de otimistas: quando apresentados a uma tarefa deprogramao, eles pensam, Isso ser fcil! No vai levar tanto tempo, afinal de contas.

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

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

Tarefas menores e cronogramas menores so mais gerenciveis, escondem menos requisitos mal entendidoscustam menos para voc mudar de idia ou refazer. Cronogramas menores mantm os desenvolvedores enge lhes d mais oportunidades para aproveitar um senso de conquista e menos razes para pensar, oh, eu tentempo suficiente para fazer isso. Por ora, vou terminar de categorizar minhas msicas no meu iTunes.

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

Fatores Verdadeiros

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

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

Merlin Mann, criador e editor da43folders.com

Resolva Aquele Problema Que Est Te Encarando na Cara

Minha coisa absolutamente favorita que acontece na web em tempos recentes o lanamento e adoo doatributo "nofollow" ("no siga"). Ningum falou sobre isso de antemo. No houve conferncias ou comits

um bando de gente poderia debater a semntica ou natureza gramatical. Nenhuma RFC que poderia tornar uidia simples em um pedao de XML de 20 linhas que eu teria que ler de cabo a rabo apenas para entender us-lo, e ento no usar porque eu no teria certeza se estava formatado para a verso .3 ou 3.3b

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

Algumas vezes resolver os prximos vinte problemas no to til ou prudente quanto resolver aquele um qest nos encarando diretamente na nossa cara. No foi apenas uma pequena vitria contra o SPAM (todas asvitrias contra SPAM so pequenas), mas uma vitria para aqueles de ns que apreciam os resultados simpldiretos sobre ser um desenvolvedor web.

Andre Torrez, programador e VP de Engenharia naFederated Media Publishing


31 de 69 04/09/2010 10:32


32/69

Muitas empresas separam design, desenvolvimento, redao, suporte e marketing em reas isoladas. Enquanespecializao tem suas vantagens, tambm cria uma situao em que os funcionrios s enxergam seus prmundos 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 umsistema de verificaes e balanos. No deixe que coisas se percam nas transcries. Tenha redatores trabalcom 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 fiser um produto mais harmonioso.

37signals est espalhada por quatro cidades e oito fusos-horrio. De Provo, Utah a Copenhagen, na Dinama

cinco de ns estamos oito horas distantes. Um dos efeitos positivos de se ter oito horas de diferena o temque podemos ficar sozinhos.

Apenas 4 a 5 horas por dia estamos trabalhando juntos. Em algumas horas, a equipe norte-americana estdormindo enquanto David, que est na Dinamarca, est trabalhando. Nas horas restantes, estamos trabalhanenquanto 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 nonenhuma surpresa. Muitas pessoas preferem trabalhar logo de manhzinha ou tarde da noite nas horas emno so incomodados.

Quando voc tem um longo perodo em que no incomodado, consegue se concentrar. E concentrado se 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 mensagensinstantneas. 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 profundo no se entra no sono profundo do nada, tem que se deitar, dormir e ento entrar no sono profunQualquer interrupo o fora a comear tudo de novo. O sono profundo onde a mgica do sono acontece 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

tarde, ningum pode falar com ningum mais (exceto durante o almoo). Ou ento, faa com que a manh otarde seja o seu tempo para ficar sozinho. O importante que o perodo seja contnuo para evitar interrupmatam sua produtividade.

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


32 de 69 04/09/2010 10:32


33/69

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

Se Concentrando

Todos sabemos que profissionais sbios trabalham melhor entrando no clima, tambm chamado de seconcentrar, onde ficam totalmente concentrados em seus trabalhos e completamente desligados dos seusambientes. Eles perdem a noo do tempo e produzem muito mais atravs de concentrao absoluta o pro que muito fcil perder a concentrao. Barulho, telefonemas, sada para o almoo, ter que dirigir por 5 mpra comer um po de queijo e interrupes por colegas de trabalho especialmente interrupes porcolegastudo te tira da zona de concentrao. Se voc parar por 1 minuto para responder a uma pergunta dcolega de trabalho, e isso tirar sua concentrao o suficiente para levar meia hora pra voltar a ser produtivonovamente, 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)?)

Voc precisa mesmo de reunies? Reunies geralmente acontecem quando um conceito no est claro osuficiente. Ao invs de recorrer a uma reunio, tente simplificar o conceito, para que voc possa discut-lorapidamente por email ou IM ou Campfire. O objetivo evitar reunies. Cada minuto que voc gasta em umreunio 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 trabalhoElas geralmente tratam apenas de palavras e conceitos abstratos, no de coisas reais (como um trecho cdigo ou algum detalhe do design de interface)Elas geralmente tratam de uma pequena quantidade de informaes por minutoElas quase sempre te

getting real - 37signals

Documents