terça-feira, 27 de outubro de 2009

MOBILE MARKETING (SMS)




SMS MARKETING - 160 caracteres pra dizer tudo
Depois do Twitter agora é a vez do MOBILE Marketing (SMS). 


São apenas 160 caracteres. Este é todo o espaço que você tem para dizer tudo o que precisa. E dá pra dizer alguma coisa num espaço tão curto? Dá pra ser passar uma mensagem com tão pouco? Dá sim. Parece pouco, mas se você parar pra pensar, é um espaço mais do que suficiente para mandar seu recado. Afinal de contas, o SMS é isso mesmo: um recado, curto e objetivo. 


Façamos um exercício: pegue o último e-mail que você enviou e conte o número de frases que você escreveu. Agora, vá um pouco mais longe e conte quantas destas frases/palavras você pode apagar sem perder o sentido de sua mensagem. Parece tolice, mas é impressionante o número de palavras que inserimos involuntariamente em nossas conversas que estão lá só para fazer figuração, são completamente dispensáveis.

Diante disso, como você pode fazer sua mensagem ser relevante, mesmo com tão pouco espaço?

Em primeiro lugar, fazendo aquela pergunta primordial (que serve para qualquer meio): é pertinente utilizar este canal nesta ação? Nunca use SMS (ou qualquer outro canal) porque “todo mundo está usando”, ou porque “Móbile está na moda”. Somente utilize canais pertinentes à sua estratégia. Você pode utilizar SMS para alertar sobre o status de seu pedido em um site de e-commerce, para confirmações de movimentações bancárias, para alertas de trânsito, tempo, vôo, enfim, só em mensagens de serviços você encontra muitas aplicações para encaixar SMS.

Aqui chegamos a um tópico importante: sempre respeite as características do meio. Não pense no SMS como um “e-mail no celular”. Um SMS é um SMS. Um e-mail é um e-mail. Ponto. Cada coisa no seu lugar. Se você deseja divulgar promoções de queima de estoque de sua empresa, use o e-mail. Para serviços e informações rápidas, use o SMS.

Think outside the box. Seja criativo, invente novas maneiras de interagir com seus clientes. Mescle SMS com e-mail, com web, TV, jornal, QR codes, Bluetooth, enfim, existe uma gama imensa de canais e oportunidades a serem utilizadas. Não deposite todos seus ovos em uma só cesta. Não tenha medo de ser criativo.

Na hora de criar a mensagem, seja sucinto. Passe sua mensagem de forma direta e objetiva. Você pode indicar um lugar para o cliente buscar mais informações, se for o caso, mas não tente colocá-las no SMS. Pense nele como um lembrete, um alerta.

Por último, coloque-se sempre no lugar do consumidor. O celular está sempre com ele. Não o importune com mensagens irrelevantes em horários inoportunos. Se você fizer seu trabalho direito, seus clientes vão esperar por suas mensagens, e não fugir delas ;)



Mais sobre Mobile Marketing via SMS em www.recadourgente.com.br


terça-feira, 29 de setembro de 2009

Desenvolvimento Orientado a Testes (TDD)



Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes é uma maneira diferente de escrever software. A diferença entre esta abordagem e a que você provavelmente está acostumado é que com TDD você vai evoluindo seu código aos poucos, conforme vai explorando o problema com o uso de testes automatizados escritos antes da solução sequer existir.
Algumas vantagens desta abordagem são:

  • Incentiva a simplicidade: como a solução vai surgindo pouco a pouco, a tendência é que não se perca tempo com aquilo que não tem certeza que será usado em seguida. Expressões como “You Ain’t Gonna Need It (YAGNI)” e “Keep It Simple, Stupid (KISS)” são recorrentes quando se está programando orientado a testes.
  • Aumenta a confiança no código: o sistema funciona de uma determinada maneira porque existem testes que foram utilizados durante sua criação e validam o que foi criado. E se ainda assim algum erro surgir, um novo teste é criado para reproduzí-lo e garantir que depois de solucionado ele não irá se repetir.
  • Ajuda como documentação: os testes quando bem definidos são mais simples de ler que o código e, embora nem sempre sirvam como uma especificação para o usuário final, eles são uma fonte eficiente para entender o que o software faz. Além disso, esta documentação sempre estará atualizada com a aplicação.
  • Facilita refactorings: quanto mais testes existem no sistema, maior é a segurança para fazer refactorings. Um erro causado por algum refactoring dificilmente vai passar desapercebido quando um ou mais testes falharem após a mudança.
Em TDD, um teste é um pedaço de software. A diferença entre teste e o código que está sendo produzido é que os testes têm 2 funções principais:
  • De especificação, ou seja, definir uma regra que seu software deve obedecer
  • De validação, ou seja, verificar que a regra é obedecida pelo software
Geralmente os testes são criados com algum framework do tipo xUnit (jUnit, nUnit Test::Unit etc) , mas também podem ser feitos num nível de funcionalidades (através de softwares como o FitNesse e Selenium) . Estas ferramentas servem basicamente para organizar os testes e facilitar na criação das verificações.
O processo de criação de programação orientado a testes é simples:
  1. Escreva um teste que falhe. Pense no que o código deve fazer, descreva o contexto e defina quais são as verificações que precisam ser feitas. Não há um limite no número de testes, então quanto menos coisa cada teste descrever/verificar, melhor. No início também não é preciso se preocupar se a classe/método ainda não existe. Pense primeiro no teste e só depois que este estiver pronto crie o esqueleto de código necessário para que ele compile e falhe ao rodar.
  2. Faça o teste passar. Agora chegou o ponto crucial: escreva o mínimo de código para que o teste passe. Controle o instinto natural do programador de tentar prever tudo que o código vai fazer e apenas faça o teste passar. Mesmo que tenha certeza que o código deve fazer mais coisas, fazer os testes passarem deve ser a única preocupação agora.
  3. Refatore. Uma vez que o teste passou, verifique o que no código pode ser melhorado. Geralmente para um teste passar é preciso inserir duplicação através de constantes (técnica conhecida como Fake It). Agora é a hora de melhorar o código e remover as duplicações, lembrando que os testes devem continuar passando.
Estes 3 passos são repetidos até que não se consiga pensar em novos testes, o que indica que a funcionalidade está pronta.