Case CalaBocaGalvao.com.br

  • 2 de julho de 2010
  •    Postado por Flavio Steffens de Castro
  •    9

Desenvolver um projeto, ao invés de realizar um treinamento? Será que esta pode ser uma boa solução para a sua empresa? Este case é para provar que SIM, é possível.

Iremos mostrar como desenvolvemos o www.calabocagalvao.com.br , nosso primeiro projeto da empresa Woompa.

INTRODUÇÃO

A Woompa iniciou no mês de junho, bem no período da Copa do Mundo. Como toda empresa quando inicia, buscamos alguma forma de entrosar a nova equipe. Surgiu a idéia de desenvolver um projeto paralelo. Algo que levasse no máximo um mês de desenvolvimento, que gerasse um resultado divertido.

Mais do que isso, que também nos possibilitasse vivenciar já, na prática, um projeto web do começo ao fim, passando por todas as fases (por assim dizer) que envolvem o processo.

Aproveitando o início da campanha “CALA BOCA GALVAO” que surgiu pelo Twitter e ganhou fama mundial, resolvemos escolher desenvolver um projeto em cima deste mote.

A partir de agora, vamos apresentar tudo o que aprendemos com este projeto.

CONCEPÇÃO

Quinta-feira. Início de Copa do Mundo. Enquanto nós ainda acertávamos nossa infra-estrutura e discutíamos o que desenvolveríamos, ocorria a abertura da Copa. E Galvão Bueno começava falar de forma interminável na televisão. Pipoca o primeiro tweet “Cala Boca Galvao” no twitter e logo isso se espalha.

Naquela noite, o CALA BOCA GALVAO atinge o primeiro lugar nos Trending Topics do Twitter. Naquela noite tivemos a idéia de explorar o assunto. O Flávio, num impulso acertado, registrou o domínio www.calabocagalvao.com.br em tempo hábil! Na manhã seguinte, já recebemos email de pessoas interessadas em saber o que faríamos com o domínio.

Tínhamos a idéia e o domínio. Tínhamos a campanha bastante ativa, naquele momento. Faltava agora lapidar, desenvolver e colocar no ar.

Decidimos que, devido a nossa limitação no momento, faríamos um site inicial para colocar no ar o mais cedo possível. E depois focaríamos em algo que tivesse a participação do público.

DESENVOLVIMENTO

Decidimos que nosso desenvolvimento seria em Ruby on Rails, com banco de dados Postgres e inicialmente utilizaríamos o Netbeans, com o Windows.

Na sexta-feira fomos para o quadro branco prototipar e refinar a idéia do site inicial para colocar no ar o mais cedo possível. O que faríamos? Colocar só uma mensagem? Dar a chance para o pessoal participar?

Após algumas discussões pela manhã, definimos que seria apenas um campo de texto, explicando que o site oficial entraria no ar dentro de alguns dias. E solicitávamos que o pessoal colocasse o seu twitter (@nome) que ele seria avisado quando o site estivesse no ar. Uma decisão bem acertada, na nossa visão.

O site inicial também serviria para vermos como são os usuários do site: quais browsers eles utilizam? Quais resoluções? Isso influencia bastante no desenvolvimento.

A Patrícia ficou responsável pelo layout inicial. O Marcus, pelo desenvolvimento. E o Flávio pelo texto e também pela hospedagem. Devido a equipe estar se conhecendo, acabamos segmentando o desenvolvimento.

A hospedagem foi um caso interessante. Assinamos primeiramente o KingHost, e descobrimos que eles não tinham Ruby on Rails. Fizemos o cancelamento menos de uma hora depois. Fomos para a Locaweb, pois eles anunciam que possuem o Rails.

Iniciamos a homologação no fim daquela tarde de sexta. Até sábado de manhã, o Marcus ficou no suporte da Locaweb tentando instalar o Rails. E o pessoal do suporte colocando a culpa na gente, quando claramente a empresa não tinha o devido suporte para Rails, como diziam. Optamos por cancelar a Locaweb.

Buscando outras hospedagens, acabamos ficando entre a SliceHost e a Linode. Vimos que, ao digitarmos o nome das duas empresas no Twitter, ambas recebiam mais (bem mais) elogios do que críticas. Portanto, o que acabou decidindo em favor da Linode, foi o custo/benefício.

O Linode oferece Virtual Private Server por 20 dólares mensais. Possuem um suporte diferente (eles utilizam um canal em um IRC) e um FAQ bastante completo. Basicamente toda instalação e configuração do projeto é feita por nós. E isso, apesar de assustar aos mais leigos, possibilitou um aprendizado enorme para nós.

Naquele final de semana, em que não colocamos o site no ar, blogs e revistas online publicaram a reportagem sobre a campanha do CALA BOCA GALVÃO. Foi o período em que surgiram os vídeos da Lady Gaga e do Galvão Institute, que logo se tornaram virais. Foi também o final de semana da reportagem no NYTimes. Toda essa repercussão foi perdida, pois não conseguimos colocar o site no ar a tempo.

Na segunda-feira, resolvemos mudar algumas coisas no site, deixando-o mais limpo e simples. Sem animações, sem tweets.

Colocamos o site no ar na terça-feira, durante o jogo do Brasil x Costa do Marfim. E fizemos a divulgação pelo Twitter, além de comentar em blogs e vídeos. Isso nos gerou, no dia, aproximadamente 1300 pageviews e 1200 visitantes únicos. Ficamos bem empolgados! Mesmo rivalizando, naquele dia, com a pronúncia do Galvão Bueno falando sobre a campanha e também com os links mostrando a faixa que apareceu no jogo. Tudo isso acabou tirando um pouco o foco do nosso site.

Iniciamos a discussão do site que seria o “oficial”. Após vários drafts, decidimos que ele seria participativo, uma “campanha” para que as pessoas pudessem enviar imagens do Cala Boca Galvão.

Enchemos de coisas como: uma animação em flash do Galvão falando as pérolas, a possibilidade do pessoal enviar as pérolas, enviar imagens, montagens, retuitar as frases, retuitar as fotos, votar nelas, etc. Priorizamos as funcionalidades (criamos user stories) e iniciamos o desenvolvimento.

No meio tempo também tomamos duas decisões bem acertadas. Iríamos colocar uma foto do Galvão Bueno falando as abobrinhas de uma forma bem tosca (a cabeça dele cortada falando). Foto do Galvão, decente, é difícil de encontrar na web. Não quisemos ter problemas com direitos autorais ou algo do tipo. Criamos então a animação do “Galvãozinho”, usando um gerador de personagens do South Park. Foi um ponto positivo,pois ele ficou muito mais engraçado e divertido, e é o que os visitantes mais se divertem no fim das contas.

Também decidimos nos fotografar e colocar no site segurando os cartazes. Fizemos as fotos aqui no pátio da empresa, numa tarde de muitas risadas. Deu um charme também para o site, sendo um ponto divertido, bem o que queríamos passar.

Já na metade do desenvolvimento, ficou claro que nós não conseguiríamos cumprir nem metade do que definimos, se de fato quiséssemos finalizar o site antes da Copa. Isso ficou frequente ao final de cada dia que passava. Falávamos: “Hoje finalizamos tudo!” e sempre faltava algo.

Começamos a cortar funcionalidades tentando manter a veia participativa do projeto. Mas o tempo foi passando e ficou claro que o site não teria a repercussão que gostaríamos. Apesar disso, o pessoal ainda continuava a visitar e até mesmo tuitar o site, sem que fizéssemos qualquer menção dele.

Na terça-feira, dia 29 pelas 17h, lançamos oficialmente o site colaborativo. A versão final, que está no ar. Ficamos bastante aliviados (por finalmente publicá-lo) e orgulhosos do resultado. Não primamos pela excelência, mas pela brincadeira e diversão. E, principalmente, pelo aprendizado. Naquele fim de tarde e noite, tivemos 560 acessos únicos e 1700 pageviews.

Divulgamos novamente no twitter, comentários em blogs e para conhecidos com seguidores ativos. Saímos em blogs e reportagens de um dos sites mais conhecidos aqui da região (Baguete). No dia seguinte, os números dobraram. E já começamos a receber fotos. E contatos.

Decidimos não acrescentar mais nenhum serviço ao site, nem fazer ajustes (a não ser os mais críticos). Estava entregue nosso projeto de batizado da empresa!

ACERTOS

Os acertos que tivemos neste projeto foram vários. Obviamente são acertos na nossa visão crítica, talvez você concorde ou não. Vamos a eles:

- Apostar na campanha: foi um dos grandes acertos que tivemos. Esta brincadeira, com certeza, não teria apenas alguns dias de vida, mas duraria a Copa toda. O que, teoricamente, sempre nos daria mídia.

- Apostar na colaboração: criar um site apenas agregando os tweets da campanha do Cala Boca Galvão seria contraproducente. Vários pipocaram por aí, sem sucesso. Ao possibilitar a participação direta do público, criamos algo que motivava o pessoal a visitar o site e perder alguns minutos ali. E, principalmente, voltar.

- Adaptação: não seguimos o plano em nenhum momento. Mudamos, adaptamos e tudo isso durante o desenvolvimento. Chegamos ao resultado assim.

- Aprendizados: este foi o principal mote do projeto. Aprender. Todos estes erros que tivemos aqui, foram excelentes para nós. Pois não afetaram em NADA. Nenhum cliente ficou brabo ou decepcionado. Estes problemas que tivemos aqui, se não tivéssemos desenvolvido este projeto, poderiam ter ocorrido quando estivéssemos lançando o nosso produto! E daí sim, os resultados seriam catastróficos.

- Diversão: o projeto foi levado como uma diversão. E o clima foi este.

- Ativação da campanha já com conteúdo: lançar o site, como este, sem nenhuma imagem, seria algo totalmente equivocado. Passaria uma péssima sensação de vazio. Tivemos o cuidado de nós já produzirmos imagens e convocar amigos a fazerem o mesmo. Isso motivou outros visitantes a fazerem o mesmo.

ERROS

Tivemos muitos erros. E talvez eles sejam mais visíveis de serem citados.

- Planejar mais do que podíamos fazer: ficou evidente que abraçamos funcionalidades demais do que poderíamos desenvolver de fato, no período que tínhamos.

- Time to market: ficou nítido para nós a importância do time to market, em projetos associados a campanhas como essa. Lançamos os sites de forma atrasada, e perdemos toda a crista da onda que a mídia espontânea poderia ter nos dado.

- Divulgação: também vimos como é importante ter bons canais de divulgação do projeto. Todos que entravam no site achavam ele divertido e bem sacado, mas mesmo os tweets que enviaram, não foram nem metade do público que o site poderia ter tido. Ter toda essa divulgação já planejada e acertada, desde o início, poderia ter nos dado um resultado muito melhor.

- Ambiente de desenvolvimento: desenvolvemos todo o projeto em Windows. E o servidor de homologação era em Linux. O resultado? Todos as gems (módulos do Ruby on Rails) que utilizamos no Windows, tinham configurações diferentes no Linux. E isso nos quebrou a cabeça por dois dias, até colocarmos o site no ar.

- Mau planejamento da versão inicial do site: quando lançamos a primeira versão do site, onde o usuário colocava o seu twitter para receber uma mensagem de quando o site oficial estivesse no ar, fizemos muito bem, na minha opinião. O problema é que desenvolvemos tudo de forma errada. E daí, o resultado foi que tínhamos vários twitters (a grande maioria falso, é verdade), mas não pudemos avisar ninguém.

- Qualidade: colocamos o site no ar deixando a qualidade para trás. Várias consistências e validações importantes (além de alguns toquezinhos no layout) deixamos para trás. Foi o efeito “vamos publicar logo”. No fim, isso não afetou o resultado final, mas alguns dos problemas podem ser visualizados até hoje.

- Segmentação do processo: apesar dos dois projetos não terem sido em waterfall, também não podemos dizer que foram ágeis. Segmentamos demais o processo (Patrícia no layout, Marcus no desenvolvimento e Flávio no conteúdo e todo resto). Tendo só uma pessoa desenvolvendo, isso nos deixou mais lentos ainda.

- Infra-estrutura: problemas no SVN e no ambiente de desenvolvimento minaram todo o processo, durante alguns dias. O SVN não funcionou direito, e portanto ficava be difícil de compartilhar arquivos.

RESULTADOS E CONCLUSÕES

Os resultados mais importantes, para nós, foram atingidos: colocamos o site no ar, divulgamos a empresa, geramos aprendizado e entrosamos a equipe.

Tudo isso para nós, era muito mais importante do que ter o sucesso ou não no projeto. Não tínhamos clientes para prestar contas. Tudo não passou de uma experimentação.

Ainda assim, dadas todas as limitações já citadas, atingimos resultados bem interessantes:

- Versão 1: obtivemos quase 10 mil pageview (9 mil visitas) em 16 dias. Com dias tendo picos em 1500 e 2000 visitas.

- Versão 2: obtivemos quase 9.200 pageviews (2.600 visitas) em 4 dias. Com pico de 1200 num dos dias. E mais de 20 imagens enviadas por pessoas das quais não tínhamos contato algum. O que foi bacana.

Ficamos bem satisfeitos com o resultado final. Saímos na mídia. Pessoas entraram em contato pedindo mais informações sobre a empresa. Propondo parcerias. Para uma empresa com um mês de vida, não poderíamos ter desejado mais :)

Resolvemos divulgar este case para servir de inspiração para quem busca implementar alguma idéia. Não temos vergonha de expôr nossos erros e nos orgulhamos de ter aprendido com eles. Esperamos que você não cometa os mesmos erros que nós.

Um grande abraço e agora veja algumas fotos do desenvolvimento!

FOTOS

Veja mais fotos no nosso flickr.


  • Pingback: Tweets that mention Case CalaBocaGalvao.com.br : Blog da start-up Woompa! -- Topsy.com

  • http://www.emaus.org.br João Paulo Novais

    Senhores,

    Parabéns pelo trabalho! Idéia simples, bem bolada e bem executada para o tempo que se tinha. Entendo que o planejamento feito foi o necessário para o conhecimento que se tinha, sendo que a priorização foi mais acertada ainda.
    Uma coisa que me surpreendeu foi a produtividade do Rails e outra que já era esperada: o sucesso da adoção de metodologias ágeis na execução de projetos de software. Sucesso!

  • http://viniciusban.blogspot.com Vinicius Assef

    Flávio, muito boa essa experiência.

    Vejo aqui duas situações que sempre vivenciamos em TI:
    1) Somos otimistas (ou prepotentes) pq achamos que seremos mais rápidos do que realmente somos. Isso é um grande risco, porque se esse projeto tivesse sido encomendado por algum cliente, vcs não ficariam muito bem na foto, certo?

    2) “Detalhes” como ambientes diferentes para desenvolvimento e produção podem ser críticos. O que vc citou sobre Windows x Linux aconteceu comigo há pouco mais de 1 mês.

    Agora, uma dúvida: vcs ficaram com uma base de twitters inválidos porque não validaram a existência deles ou pq a rotina de gravá-los errou em algum ponto?


    Vinicius Assef.

  • Rogerio

    Parabéns Flávio, e obrigado por compartilhar conosco mais uma etapa de sua vida. Acompanho você desde o antigo blog Mudando uma pequena empresa, e espero que continue crescendo cada vez mais nessa nova empreitada. Achei legal o site que vocês criaram, e mais ainda você ter compartilhado um pouco como foi o seu desenvolvimento, pois sempre me interessei em ler relatos de desenvolvimento de outras pessoas.
    Boa sorte e sucesso!

    Abraços

    Rogerio

  • Flavio Steffens de Castro

    Salve, Vinicius! Obrigado pelo comentário!

    A questão do twitter foi a seguinte: primeiro, a grande maioria não entendeu direito que era para colocar o nome do twitter ali. Então vinham até endereços ou nomes pessoais. Segundo, o pessoal não sabia o que ia acontecer, muitos ficaram com medo de colocar ali e receber spam ou algo do tipo. Terceiro, a grande maioria usou o campo como lixo. Colocavam o twitter de outras pessoas, até alguns que nem existiam. E por último, ao não validarmos, aceitamos tudo o que entrava ali.

    Faz parte!

    Abração

  • http://blog.andrefaria.com André Faria Gomes

    Muito bem galera! Parabéns pela iniciativa e por compartilhar as experiências de vocês.
    Grande abraço e sucesso!

  • Rafael Fuchs

    Grande Flávio!

    Muito legal seu post! Parabens pela empresa e pela iniciativa de fazer este projeto inicial com o pessoal.

    Sobre a questão do ambiente… já tive problemas parecidos com esse. O mais interessante não é ter o ambiente dos desenvolvedores parecido com o de homologação ou produção. É preciso ter um servidor de testes ou um ambiente anterior ao de produção o mais parecido possível com o de produção. Neste ambiente serão feitos os principais ajustes antes do bicho pegar.

    Mas uma coisa é certa: alguma coisa sempre vai ficar para trás, por menos que seja. É muito dificil conseguir um ambiente 100% fiel ao ambiente de produção, ainda mais quando não se tem 100% de controle sobre ele, como no teu caso que está contratando uma hospedagem.

    Mais uma dica: tente colocar as alterações em horários o mais bizarros possíveis. Desta forma, se algo der errado, ou não tão certo assim, menos gente vai notar e o impacto vai ser menor.

    O ambiente do desenvolvedor tem que ser o que ele acha melhor. Fazer o cara usar alguma coisa que ele não se sente a vontade ou não está acostumado vai só f@#$! com a vida dele.

    Abraços!

  • Pingback: Adicionando marca-d’agua nas suas imagens com ImageMagick e Mini-Magick : Blog da start-up Woompa!

  • tiago jaime machado

    fiquei com vontade de perguntar sobre visitantes únicos e tempo de permanência. Melhor não.

    Um abraço gurizada. Primeiro projeto é isso, é como dar uma bela barrigada na piscina, que sempre pode ser uma lembrança divertida.

    @tiagomx