Marco Gomes

Geek, imigrante, nerd, cristão, biker. Founder da boo-box (vendida) e do Heartbit. Consigliere do JovemNerd

Tornando reais suas aplicações para a Web

Publicado em 2006-07-27

Introdução (talvez você não precise desta parte)

Todos já notamos que vender aplicações em caixas bonitas é coisa do passado. Mesmo que este tipo de distribuição de software se mantenha por um bom tempo, mesmo que sistemas operacionais precisem ser entregues em caixas bonitas daqui a 30 anos, ainda assim é passado.

O novo modelo de distribuição coloca os softwares para serem utilizados na Web, dentro do navegador(por enquanto), com conexões banda-larga e CPUs ultra poderosas fica fácil.

Este texto está sendo escrito em uma aplicação chamada Writely que roda na web e, para meu uso, tem muitas vantagens sobre um processador de texto que rode localmente, como Microsoft Word ou BrOffice.org Writer. Para citar três destas vantagens: eu posso acessar o texto de qualquer lugar, posso escrever o texto em conjunto com outras pessoas simultaneamente, não precisei instalar uma suite de aplicativos que custa quase R$:1000,00 e iria consumir processamento e memória RAM do meu computador pra sempre.

O objetivo deste texto é traçar algumas dicas para pessoas envolvidas no desenvolvimento de aplicações para esta Nova Web (perdão pelo jargão, mas não consigo achar nada mais adequado). Não é focado apenas em programadores, designers, gerentes de projeto ou qualquer outro perfil profissional, pode ser usado inclusive para projetos não-Web e não-programação.

Implemente o princípio KISS para desenvolver suas aplicações (talvez você não precise desta parte também =)

Para quem não sabe, KISS significa: Keep It Simple Stupid, ou Mantenha-o Simples Estúpido em bom português. É um princípio inicialmente criado para definir o desenvolvimento de softwares do mundo UNIX, onde vários programas simples e altamente especializados conversam entre si para realizar tarefas de qualquer tamanho, grandes ou pequenas, simples ou complexas. Posteriormente este princípio foi portado para outras áreas, como design, arquitetura da informação e web design.

KISS significa não perder recursos com itens inúteis, seja o recurso em questão espaço, tempo, processamento. Significa manter somente o necessário para o bom funcionamento da aplicação e experiência do usuário.

Aparentemente o princípio KISS foi esquecido em softwares como Microsoft Word, Microsoft Excel, Microsoft Power Point, Microsoft Outlook (este é o inferno dos usuários), BrOffice.org (derivado do OpenOffice.org), e-Mule, KaZaA, Microsoft Messenger (MSN, Live, Windows), e vários outros. A Microsoft não é a única a pecar em não utilizar o KISS, quase todos os softwares da "geração passada" são complicados demais.

Com o desenvolvimento de aplicações para a Web, KISS foi relembrado, aplicações especializadas, objetivas, que fazem "só isso" são comuns. O Google Calendar não manipula e-mails, o Ta-Da List nem sabe o que é uma imagem, o Bloglines não navega na Web (mesmo porque ele está dentro dela).

Mantenha a equipe pequena

Muitas pessoas em equipes paquidérmicas gera confusão, o trabalho sempre fica embolado no meio de campo. Mantenha a equipe pequena, as coisas serão feitas com maior agilidade caso não sejam necessários 4 e-mails de aprovação para cada ícone da aplicação.

Evite reuniões

A maior parte das reuniões pode ser evitada com e-mails e conversas por mensagem instantânea. As reuniões só fazem você perder um precioso tempo e ainda quebram o seu fluxo de trabalho diário. Além disso, elas se desviam do caminho proposto com a mesma facilidade que um brasiliense dirigindo nas ruas de São Paulo.

Não perca tempo prevendo o mundo real, enfrente-o

Não perca tempo com coisas que representam o mundo real, como gráficos, planilhas, especificações, testes; enfrente o mundo real desenhando a interface, programando o software e lançando-o.

Se você não perde tempo com tarefas inúteis pode trabalhar diretamente no que é real e lançar a aplicação mais rapidamente.

Comece por algo palpável (não se esqueça: enfrente o mundo real!)

Seus investidores e utilizadores preferem ver uma janela de terminal com toda a saída de um banco de dados orientado a objeto ou algumas telas da interface do programa com as funcionalidades básicas implementadas?

O Wufoo, um construtor de formulários para a Web, se manteve meses "em alta" na comunidade de desenvolvedores simplesmente com um "demo", não gerava uma linha de código, porém, deixava você criar e arrastar campos pela tela. Se a equipe do Wufoo tivesse começado com a infra-estrutura ao invés da interface você acha que eles teriam tanto sucesso?

Para notar isto, basta ver o fantisy rpg, não há nada na página do projeto, caso houvesse pelo menos as imagens dos personagens, as pessoas se interessariam com maior facilidade.

Lance logo e atualize sempre

Você não deve perder tempo tentando prever o que os usuários vão aprovar ou não em seu programa. Não gaste tempo tentando cobrir todas as falhas possíveis do software para só então publicá-lo.

Um software na Web não precisa aguardar um ano para ser atualizado, não precisa de nomes de versão ininteligíveis: Internet Explorer 6.0.2900.2180.xpsp_sp2_rtm.040803-2158? Mozilla Firefox 1.5.0.4? Isso é passado. [1]

Se você lança logo, pode receber respostas dos usuários e retirar os recursos indesejados no mesmo dia, assim como inserir recursos solicitados.

Os softwares têm potencial para ter atualizações rápidas e transparentes aos utilizadores, seu método de desenvolvimento deve conseguir atender a esta demanda.

<update datetime="2006-07-27">

Escalabilidade é sua amiga

Se o software será atualizado constantemente, você precisa poder incrementar novas funcionalidades e recursos com facilidade, se a cada atualização for necessário reescrever todo o código-fonte, suas atualizações não serão tão rápidas quanto poderiam.

Lembre-se do princípio KISS aplicado ao mundo UNIX, divida sua aplicação em componentes que conversem entre si. Com sua aplicação componentizada você poderá alterar o fluxo da comunicação, ou modificar os componentes individualmente, com bastante facilidade.

</update>

Não se preocupe com problemas do futuro

Não se preocupe se seu servidor não suporta 400.000 acessos simultâneos, deixe este problema ser resolvido quando você tiver este número de acessos, concentre-se em resolver os problemas do presente.

Não perca tempo com problemas que surgirão no futuro, você não precisa cobrir o universo, é por isso que seu software está na Web, você pode cobrir apenas a área necessária. Deixe as preocupações de compatibilidade futura de lado.

Faça menos que a concorrência

Costumava-se acreditar que para vencer um concorrente, você deveria fazer mais que ele. Se o software dele tem 10 funcionalidades, o seu deve deve ter 15 ou 20. Se ele tem 60% de qualquer coisa, você deve ter 80%. Não faça isso, esta é uma prática antiga que já não funciona mais.

Sua aplicação deve fazer menos que a dos concorrentes, deve atingir um ponto objetivamente, sem deixar dúvidas para o usuário sobre a função do seu software.

Menos significa:

  1. Menos janelas de opções e preferências.
  2. Menos elementos na interface.
  3. Menos formulários de cadastro com menos campos para preenchimento.
  4. Menos cliques.
  5. Menos instalações de plug-ins.
  6. Menos avisos.
  7. Menos telas.
  8. Menos burocracia.

O meebo ganhou o mundo por ser mais simples que seus concorrentes, basta entrar no site, digitar login e senha do serviço de mensagem instantânea desejado e pronto, você está conectado, sem cadastros, sem avisos, sem configurações, sem alteração de permissões aqui e ali, sem e-mails de confirmação.

Conclusão (gancho para atualizações =)

Este texto também segue a filosofia do publique logo e atualize sempre. Foi escrito rapidamente e será atualizado constantemente. Não coloquei sequer as tags de semântica XHTML necessárias, isso será feito nas atualizações.

Links:

Observações:

  • Boa parte deste texto foi escrito com base em algumas lições da 37signals.
  • É óbvio que estas dicas não são imutáveis e não devem ser seguidas à risca, cada projeto tem suas peculiaridades. Eu sei bem que sistemas de internet banking e gerenciadores de usinas nucleares não devem ser desenvolvidas na doida =)
  • [1] Sei que usei como exemplo programas que não poderiam rodar na Web, mas foi só para ilustrar como nomes de versão podem ser confusos.

Textos relacionados:

Deixe sua opinião

22 comentários

  1. Marcelo Linhares comentou:

    Audacioso….
    Jogou os 20 anos dedicados ao estudo de engenharia de software no buraco… Conceitos de Gerenciamento de projetos, então.. nem pensar….

    tirando alguns pontos que discordo completamente, o texto faz algum sentido, o interessante ao meu ver seria um meio-termo… um processo não tão anárquico como vc propôs e não tão engessado como RUP por exemplo…

    Também vejo que muito do que vc abordou condiz com a metodologia de programação extrema (XP).

  2. Marco Gomes comentou:

    Não fui só eu, a 37signals e mais algumas outras empresas também.

    Mas já disse, alguns pontos devem ser ignorados em alguns projetos, são só dicas, não leis.

  3. ALK comentou:

    Mandou bem!Otimo texto, tu tá escrevendo bem!
    Mas eu nao consegui baixar o Fantasy RPG… =P

  4. Nandico comentou:

    Belo texto! Vamos ver no que dá isso tudo =).

    Eu não gosto muito dessa cultura do beta. Concordo com você em que não uma única melhor forma de desenvolver software, para cada projeto deve existir a melhor forma.

    Dessas idéias que você sintetizou aqui, eu gosto de pegar o melhor e descartar todas as posições muito extremas.

    Não sou a favor da aplicação xiita de tudo o que a Engenharia de Software manda, mas também essa bagunça que é a “nova web” esculhamba as coisas demais. Não tenho paciência para software instável e “No donuts for you” a vida inteira. =)

    Time to market é só uma das coisas que um bom produto deve ter. Muitas vezes a comunidade está mais preocupada de criar vapor do que em resolver os problemas dos clientes ;).

  5. Sergio Lima comentou:

    Oi Marcos!

    Eu sou suspeito pra falar pois não sou progamador nem trabalho com desenvolvimento de software. Sou usuário!

    Mas reconheço no seu texto um software que adoro (e já tem 5 anos) mas que segue muito dos paradigmas propostos neste seu texto. É o txt2tags (http://txt2tags.sourceforge.net/pt/).

    A vida já é naturalmente complicada, então o software que uso deve permanecer simples :-)

    []’s

  6. Walmar Andrade comentou:

    Marco, parabéns pelo texto, estávamos precisando de algo assim. É bom o pessoal conhecer as regras para saber quando transgredi-las. Abraço.

  7. Rafael Lima comentou:

    Também fiz um apanhado do livro da 37signals em minha palestra, publicada em meu blog.

    Os caras são bons, vale a pena acompanhar o blog deles…
    http://37signals.com/svn/

  8. Filipe Souza comentou:

    gostei da teoria… bem elaborada.

  9. André Cassal comentou:

    Acredito que é esse o caminho, softwares “incremetais”, porém discordo do ponto sobre reuniões. Penso que na maioria das empresas ainda não há cultura de reuniões produtivas.
    Para diminuir o impacto dessa falta tento aplicar alguns conceitos de empresas como IDEO e FrogDesign, que buscam na discussão na prototipagem a evolução do produto, ou seja, mais “penso” e menos desenvolvimento.
    Consegui em alguns projetos um real ganho com essa metodologia mas ainda sinto em alguns profissionais (acredito q pelo perfil) uma barreira em relação a esse tipo de estrutura, parece que há uma necessidade insaciável de começar o desenvolvimento e isso faz com que a visão fique restrita ao comum.

  10. Daniel Soares comentou:

    KISS não era uma banda de rock? õ.Ô

  11. Marcelo comentou:

    Bem, a coisa funciona, mas até onde? Textos confidenciais de empresa no writely? nem pensar? Planilha de salarios dos funcionarios rodando por ai em conexoes nao seguras? Planos e skecthes de novos projetos secretos? Jamais. Confidencialidade é uma barreira que os projetos web no formato citao ainda vao esbarrar no ambiente corporativo, que é um dos maiores se nao o maior cliente de aplicaçoes.

    Agora quanto a agilizar todo o desenvolvimento, concordo em parte, discordo em outras. 37signals, AdaptativePath, ok empresas “cool” mas ainda tem muito hype ao redor delas, mas claro sempre podemos tirar boas liçoes. Eu sou a favor de uma versao otimizada do modelo evolutivo utilizado no software livre. Reunioes? nao evite. Mas nao faça no modelo tradicional, reuniao aqui no escritorio é virar as cadeiras pro centro e debater. Sempre, evita-se codigo/design errado e principalmente: erro de comunicacao. Ganha-se: a opiniao que pode ser matadora daquele cara calado, que nao teria como ler o email com o problema que foi enviado entre 2 peers.

    no Mais, o basico foi dito : KISS.

    *sem acentos, teclado finlandes em um mac. pensa numa zona!

  12. thiago machado comentou:

    eu queria uma versão para impressão

    é muito bom isso em um blog, você não acha ?

    parabens pelo conteudo !!

  13. Opa, excelente artigo. Fiz um trackback para ele no meu blog: http://www.luizantonio.com/blog/2006/11/17/tornando-reais-suas-aplicacoes-para-a-web/

    ps.: Acho que o trackback não está funcionando.

  14. Eduardo Comin comentou:

    Muito bom texto…
    Também estou me interessando pelo livro…
    Mas é fundamental o que você diz no fim:
    “…É óbvio que estas dicas não são imutáveis e não devem ser seguidas à risca, cada projeto tem suas peculiaridades…”
    Isso é o mais importante, devemos aproveitar somente o que é útil ao nosso projeto, porém tem umas sacadas muito boas… e é claro que temos que lembrar que a nossa realidade mudou sim e não é mais possível continuar com as mesmas regras de engenharia de software…

  15. Aguinelo Pedroso comentou:

    Muito bom, cada vez mais gente com esta visão caminhando para o mesmo lugar, isso é muito bom.

  16. Alan Domladovac Silva comentou:

    Resumiu bem o Getting Real… :)

  17. JC digital comentou:

    Demorei mais de 2 anos pra chegar aqui e ler esse artigo super interessante.
    E como sempre vim parar aqui por uma twittada sua falando do wallpapr, e não pude deixar de ler essa espécie de tutorial que foi fundamental pra dar um up na minha cabeça.

    ;)

  18. Willian Rodrigues comentou:

    O melhor ate agora que li.. simples e eficiente!