Rock Convert —from zero to hero
Construindo um plugin de WordPress para gestão de calls to action em massa
UPDATE: Conheça as novidades da versão 2 do Rock Convert.
—
Quando se trabalha em uma empresa como a Rock Content, é muito comum surgirem ideias sobre produtos inovadores, mas infelizmente a correria do dia a dia nos impossibilita executar tudo que queremos.
Além disso, criar um produto é algo complicado. Devemos analisar se, efetivamente, estamos desenvolvendo uma solução real para problemas e pessoas reais. Há produtos no mercado que propõem soluções a problemas que talvez nem existam, e isso não pode acontecer.
Certo dia, o Matheus me chamou pra trocar uma ideia sobre um problema comum relatado pelos clientes da Rock Content. Até então ele não havia encontrado um plugin de WordPress que fizesse a gestão de calls-to-action em massa, de uma maneira simples e intuitiva.
Me interessei pelo potencial da ideia, mas claro, tive que fazer algumas perguntas.
Eu: Mas porque isso é um problema?
Ele: Porque quando entregamos materiais ricos como ebooks ou infrográficos e o cliente quer gerar leads utilizando estes materiais eles precisam colocar o CTA em cada post do blog, ou seja, se ele tem 200 posts …
Eu: Não existe nenhum plugin que faça isso ainda?
Ele: De forma simples e eficiente não
Eu: E se fosse apenas uma página de cadastro onde selecionamos as categorias que o CTA deve aparecer? Resolveria o problema?
Ele: Sim!
Como já havia desenvolvido alguns plugins em WordPress, fiz uma estimativa aproximada de quanto tempo gastaria nesta tarefa e rapidamente concordamos que seria viável criar este produto.
Logo em seguida, apresentamos a ideia em uma reunião semanal que fazemos para o Experience Valley e começamos a desenvolver este plugin como um produto interno da Rock Content, com ajuda do Werik.
Resolvendo um problema do mundo real
O problema principal que precisava ser resolvido seria gerenciar CTAs em massa, então decidimos focar nesta funcionalidade para lançar o plugin.
Fizemos um brainstorming e definimos os requisitos mínimos necessários para resolver o problema como sendo:
- Cadastrar um CTA (Link, UTM, banner e onde o banner deve aparecer).
- Em quais categorias do blog este CTA deve aparecer.
Feita esta definição, era a hora de desenhar as telas e apresentar o produto para o resto da equipe para um feedback.
Desenhando as telas do produto
Por mais simples o plugin seja, achei uma boa ideia desenhar as telas antes de colocar a mão na massa.
Seguindo as dicas do Marcello Cardoso na palestra do Experience Valley e com ajuda do Tiago Gerken, fiz um esboço de como o plugin deveria funcionar utilizando apenas lápis e papel — antes de fazer qualquer outra tarefa que pudesse gerar retrabalho.
Com os esboços prontos e devidamente apresentados para a equipe, fiz o layout final no Sketch.
Procurei no Google e encontrei o SketchPress, com praticamente todos os componentes do Wordpress!
Com isso foi fácil chegar no mockup da tela principal, que é a de cadastro do CTA.
Depois de trocar algumas ideias com o Matheus e o Werik, percebi que alguns campos no formulário de cadastro estavam faltando.
Observei ainda que seria mais fácil deixar as categorias na barra lateral direita, da mesma maneira que o Wordpress usa nos posts convencionais. Depois destas mudanças a tela ficou assim:
Desenvolvendo o plugin do zero, ou quase isso
Não perdi tempo e iniciei o projeto a partir do WordPress Plugin Boilerplate. Este boilerplate tem todo o código necessário para começar o desenvolvimento de um plugin, o que me salvou algumas horas de trabalho.
Com o esqueleto pronto, pensei em como deveria separar as responsabilidades do código que tivesse melhor resultado. Então decidi por dividir em duas partes, sendo a primeira Admin e a outra Front-end.
A parte do Admin seria responsável por:
- Cadastrar o novo custom post type;
- Criar uma caixa personalizada dentro deste custom post type para armazenar o link (UTM) e o fazer o upload do banner;
- Salvar e validar as informações na parte do admin.
Já o Frontend seria responsável por:
- Fazer a Query para mostrar os CTAs no post atual;
- Estilizar o banner.
Disponibilizando o plugin Worldwide
Outra vantagem de já ter experiência na criação de plugins é saber todos os requisitos necessários para ser aceito, de primeira, no repositório do Wordpress.
O gerador de esqueleto adianta o trabalho em 70%. Então o primeiro passo é criar o código a partir dele.
O segundo passo é criar arquivo readme.txt na raiz do projeto com as informações do plugin no formato sugerido pelo WordPress. Para isso, utilizei o Plugin Readme Generator.
É necessário ficar atento aos termos de uso do Wordpress, pois eles são bem rigorosos com algumas coisas. Os pontos mais importantes são:
1. Plugins must be compatible with the GNU General Public License #
7. Plugins may not track users without their consent. #
8. Plugins may not send executable code via third-party systems. #
13. Plugins must use WordPress’ default libraries. #
Fonte: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/
Por fim, para submeter o plugin e só criar uma conta no Wordpress.org e fazer o upload.
O que acertamos no desenvolvimento do MVP
- Traduzimos um problema do mundo real para um produto simples e viável;
- Fizemos um brainstorming para decidir quais a funcionalidades essenciais do produto; — Menos é mais
- Desenhamos as telas antes de qualquer coisa para evitar retrabalho;
- Criamos um MVP a partir de um boilerplate construído utilizando boas práticas de programação e que fossem compatíveis com os requisitos necessários para submeter um plugin para o Wordpress.org;
- Colocamos o plugin em produção, o mais rápido possível, para testar com clientes reais.
Próximos passos — Product Planning
Agora que já temos um MVP sendo testado por usuários de todo o mundo, decidimos pensar nos próximos passos.
Assim, criamos uma conta no Trello para planejar próximas features, catalogar e resolver bugs, além de gerenciar toda a parte de marketing para promover o plugin.
Hoje nosso board tem as seguintes colunas:
- Backlog — Onde coletamos sugestões de features e guardamos ideias de features para versões futuras;
- Planned — Nesta coluna ficam as features planejadas para a próxima versão do plugin;
- Doing — O nome ja diz;
- Done — Features que já estão prontas no repositório, mas ainda não estão no release disponível para os usuários;
- Production — Features ou Bugfix já disponíveis na ultima versão estável.
Com esta ferramenta em mãos, conseguiremos planejar quais funcionalidades serão construídas e quais precisarão ser amadurecidas, além de dar uma visão para os stakeholders sobre a nossa visão de como o produto deve ser.
Conclusão
Obrigado por chegar até aqui! O objetivo deste artigo é mostrar como nasceu uma ideia e como ela se transformou em um produto capaz de resolver um problema real dos nossos clientes!
Gostaria de receber o seu feedback sobre como foi a nossa jornada! Pode ser nos comentários do Medium ou por e-mail: hugo.dias@rockcontent.com.
Por fim, e não menos importante, queria convida-lo a conhecer o plugin, que já está em produção e totalmente gratuito, o Rock Convert. Baixe agora mesmo! :)
