O início da operação do Be on the Net

Vinicius Manhães Teles — Fri, 27 Mar 2009 00:48:06 -0300

Quando eu e meus colegas de turma da UFRJ estávamos estudando para o vestibular, acreditávamos que o maior dos desafios seria entrar para a UFRJ ou outra universidade pública. Uma vez lá, descobrimos que sair de lá, com um diploma debaixo do braço, é um desafio bem maior. Entrar era só o começo, a parte fácil da jornada.

Quando estamos implementando um produto, achamos que estamos diante do maior dos desafios, até que o lançamos e descobrimos que acabamos de encerrar a parte "fácil". O que acontece após o lançamento tende a ser bem mais difícil. A começar pelo problema essencial de atrair pessoas para comprarem o produto ou o serviço, passando, naturalmente, pela questão de fornecer o serviço de maneira consistente e apropriada.

Operação

No desenvolvimento do Be on the Net, tentamos simplificar tudo o que era possível, pois sabíamos que se não fizéssemos isso, seria insustentável mantê-lo com a equipe pequena que temos. Somos apenas três pessoas e isso é proposital. Acreditamos que equipes pequenas funcionam melhor.

Então, nos concentramos em pouquíssimas funcionalidades essenciais e investimos todos os nossos esforços em fazer com que elas funcionassem da maneira mais perfeita possível. Claro que isso envolveu uma infinidade de testes automatizados e melhorias constantes ao longo do desenvolvimento. A própria experiência de ter tido o site da Patricia Figueira no ar (o embrião do Be on the Net) por um ano, nos ensinou muito sobre o que o produto deveria ter ou não.

Apesar de termos tentado deixar tudo o mais preparado possível, é óbvio que fomos surpreendidos por inúmeras questões.

Emails

Os primeiros dias foram muito agitados. Pouco mais de 200 interessados tinham entrado em contato conosco durante o desenvolvimento do Be on the Net. Quando lançamos o produto e avisamos, várias pessoas contrataram o serviço logo em seguida. Foi a maior correria.

A criação de um site conosco envolve alguns passos feitos por nós e outros pelo cliente. Então, havia necessidade de enviar emails com instruções, os quais tendiam a se repetir de um cliente para outro, com poucas variações.

Logo ficou claro para mim que essa questão dos emails poderia tomar um tempo bastante grande. Felizmente, depois de alguns dias de muita digitação de email, lembrei que no Mac há o Automator, que ajuda a automatizar tarefas repetitivas. Então, comecei a criar templates dos emails que ficava enviando. A partir daí, bastava clicar duas vezes em um ícone, no meu desktop, e o email já aparecia preenchido na minha frente, faltando apenas colocar o endereço do destinatário.

Em outros casos, como o do envio do contrato, depois de clicar duas vezes na automação, bastava escolher o arquivo do contrato em uma caixa de diálogo que se abria e, em seguida, colocar o destinatário.

São automações que parecem bobas. Mas, o efeito acumulado de todos os emails que foram automatizados é excepcional. Em poucos dias, a questão dos emails ficou totalmente administrada e continuo usando esta solução até hoje.

Highrise

Usamos o Highrise desde que começamos a desenvolver o Be on the Net. Todas as pessoas que entraram em contato conosco até hoje, interessadas no Be on the Net, estão cadastradas lá. E, naturalmente, todas as interações que tivemos com essas pessoas, seja por email ou telefone, estão registradas também. Isso facilita muito a nossa vida no dia-a-dia. É uma das ferramentas mais importantes para nós, de modo que a recomendo fortemente.

Suporte

Há duas questões básicas que levam clientes a entrar em contato com uma empresa com um pedido de suporte: alguma coisa parece estar errada, ou ele não sabe como usar algo. Claro que pode haver outras razões, mas estas normalmente estão no topo da lista. Como lidamos com isso?

Alguma coisa parece estar errada

Em primeiro lugar, fizemos o máximo possível para que o software funcionasse perfeitamente, o tempo todo. De um modo geral, fomos bem sucedidos. Até o momento, quase não tivemos correções para fazer no sistema. Então, qualidade acaba se pagando muito. Porque a gente quase não tem que atender este tipo de suporte. Ele simplesmente não surge.

Enquanto isso foi verdade na infraestrutura, na parte do layout as coisas foram um pouco mais difíceis. Os sites do Be on the Net compartilham uma mesma infraestrutura de código, mas cada um usa um template para a parte do layout, feito em CSS. Um dos grandes desafios é manter a consistência em todos os navegadores, coisa que buscamos com afinco. Nem precisa dizer que o Internet Explorer 6 é um tormento permanente. Mas, a gente enfrenta e, de um modo geral, consegue domar a fera.

O que torna difícil essa parte do layout é que algumas questões não são passíveis de testes automatizados. É preciso fazer inspeção visual mesmo.

Outro ponto que gerou bastante dificuldade é a própria maneira como pensamos em usar os templates originalmente. Quando alguém pedia para usar o Amora, por exemplo, a gente pegava o CSS do Amora e copiava para a conta do cliente. Parece uma solução razoável à primeira vista, mas copiar sempre traz problemas.

Logo descobrimos que cada template "vem de fábrica" com um ou outro erro que precisa ser corrigido. Normalmente são erros difíceis de serem identificados antes de colocar o template em uso, na conta de um cliente. Quando um erro é localizado, é necessário corrigir no template. Mas, se há cópias dele em cada conta de usuário que o utiliza, as coisas se complicam bastante. Então, a solução é não copiar nada. Portanto, ter uma base de código única do template, que é carregada pelo site do usuário. Apenas ajustes específicos de cada site é que entram no CSS específico do site.

Essa foi uma questão que identificamos logo nos primeiros dias e foi preciso um trabalho razoável para mudar a infraestrutura. O Tapajós deu uma ajuda gigantesca nessa questão. Mas, felizmente fizemos o que precisava ser feito e o problema foi completamente superado.

Como usar algo?

O segundo fator básico de suporte são questionamentos sobre como fazer alguma coisa. Sabíamos que seria necessário "treinar" os clientes tão bem quanto possível, para que conseguíssemos atender a todos com o tamanho de equipe que temos. A solução que encontramos foi a criação de inúmeros screencasts que mostram, passo-a-passo, como fazer cada coisa no Be on the Net.

Criar um bom screencast é muito trabalhoso. Os mais difíceis chegaram a levar quase um mês para ficar prontos, entre planejamento, pré-produção, seleção de exemplos, produção do vídeo, gravação do áudio e edição. É uma trabalheira danada, que felizmente o Leandro aprendeu a fazer como ninguém. O resultado é magnífico.

Os clientes raramente têm dúvidas sobre as questões que são cobertas pelos screencasts. Isso é fabuloso, porque não apenas permite que eles aprendam tudo no próprio ritmo de cada um, como nos libera tempo para continuar trabalhando em outras melhorias para a infraestrutura e criação de novas funcionalidades.

Desempenho

Os sites operados pelo Be on the Net, em conjunto, recebem milhares de visitas todos os dias. E há um visitante, em especial, que faz acessos freneticamente. Chama-se Googlebot. Então, se não houver uma atenção enorme com o desempenho dos sites e dos servidores, vamos passar os dias escutando lamentações dos clientes sobre a lentidão de seus sites.

Durante o desenvolvimento, tivemos o cuidado de estruturar várias camadas de cache para a infraestrutura. Usamos cache de ação o máximo possível, bem como memcached para inúmeras coisas. Começamos assim e felizmente o resultado foi excelente. Com o tempo, fomos observando melhor o comportamento do software e descobrindo vários pontos de otimização. Eles não têm importância quando uma página já está no cache, mas mehoraram muito o desempenho quando uma página é acessada pela primeira vez.

Conclusão

Desde que colocamos o Be on the Net no ar, estamos atentos a tudo o que acontece e a todas as oportunidades de melhoria que surgem. E quando surgem, a gente atua imediatamente. Agindo desta forma, já tornamos o sistema muito melhor e mais robusto nestes três meses de operação. Agora as coisas estão bem estáveis e estamos acolhendo mais e mais clientes a cada dia.

Obviamente ainda há muito por aprender e por melhorar. Acho que manter o software enxuto e trabalhar incansavelmente para melhorar sua qualidade foi a melhor estratégia que poderíamos ter adotado.

Desenvolvimento Ágil - Blog da Improve It: Tag operação