Práticas de Growth Engineering na RD Station: o que são e como escrever seus experimentos na engenharia
A RD Station tem quase 40 times de desenvolvimento de software atuando em diversas áreas dentro da Engenharia. Alguns desses times concentram a atuação nos produtos como o RD Station Marketing e RD Station CRM, já outros são unidades de negócio totalmente independentes, como a nossa BU (business unit) de internacionalização das nossas soluções.
Neste post irei explicar com exemplos o que é experimentação e também quais são as 5 práticas essenciais que permeiam os times que realizam experimentos, estratégia conhecida como Growth Engineering (iremos falar em outro post exatamente sobre essa área da engenharia).
O que é experimentação?
Escrever código para criar um experimento é diferente de escrever código para atender um requisito de negócio já provado, o entregável é diferente. Enquanto em um contexto tradicional temos o próprio código como artefato final, o objetivo na experimentação é aprender. Muitas vezes o produto final é um relatório que mostra o resultado do experimento, com os dados obtidos e informações complementares. Para atingir esse objetivo, levando em consideração o contexto, podemos abrir mão de certas práticas tradicionais em prol da velocidade (ainda mantendo a qualidade e reduzindo o risco de problemas).
As práticas de experimentação são aplicáveis em apenas parte de um sistema existente, pois pelo próprio conceito das hipóteses serem criadas em cima de um etapa da jornada do cliente, leva-se que os experimentos sejam isolados (além de que isso garante uma refatoração de código mais fácil de ser feita). Ao optarmos por velocidade e abrir mão da qualidade no curto prazo, estamos convidando risco. Isso porque o código escrito em experimentação tem uma longevidade curta, ou seja, nasce com data para morrer (assim que o experimento colher dados o suficiente). O código que vive mais do que isso, precisa de qualidade, pois vai ser lido, entendido e alterado muitas vezes por outras pessoas desenvolvedoras. O código que tem vida curta, muitas vezes passa despercebido pelos outros times.
É importante definirmos o que caracteriza um experimento: Uma hipótese bem formulada com um teste que possa refutá-la.
Exemplo:
Recentemente criamos uma hipótese de que se colocássemos um botão de “Compre Agora” na página rdstation.com/precos, iríamos aumentar a taxa de novos clientes em 25%. E para definir como esse experimento seria validado, usamos nosso histórico de dados para estabelecer que seria necessário apresentá-lo para 20 mil usuários (o que levaria cerca de 30 dias) e coletar os dados de conversão. O objetivo em Growth é sempre testar rápido e melhorar ainda mais rápido, inclusive aqui na RD Station priorizamos o uso de “no code/less code” nesses casos, sempre que possível.
5 Práticas de Growth Engineering
Zero ou poucos testes automatizados
Dois principais objetivo dos testes automatizados são:
1. Guiar o desenvolvimento (TDD)
2. Documentar e garantir o funcionamento do código para que futuras alterações não comprometam a corretude do sistema.
Como já estabelecemos que os experimentos são de vida curta, o segundo ponto perde força. Com práticas de testes manuais em desenvolvimentos, podemos sacrificar essas validações garantindo o funcionamento do código.
Escrever código de fácil deleção
Se já sabemos que nosso código tem data de validade, podemos facilitar nossa vida no futuro e escrever código que vai ser fácil de deletar. Isso pode ocasionalmente jogar contra com princípios como DRY, que faz bastante sentido quando consideramos a manutenção do código, afinal, ninguém quer causar um incidente porque corrigiu um erro em uma regra de negócio e esqueceu (ou nem sabia) que existia uma duplicação. Mas quando estamos falando de um código que vai viver por duas semanas, é mais eficiente duplicar código para a deleção, por exemplo:
Ao invés de adicionar um cláusula if em um pedaço de uma view Rails, adicionamos um if no controller que renderiza uma view que foi copiada da original e que tem as modificações para o experimento. Assim, mesmo que o time precise dar manutenção na página original, não vai precisar entender o código do experimento. Além disso, a deleção das linhas no controller e de um arquivo é mais simples do que desfazer as modificações na view, especialmente considerando que o arquivo pode ter mudado no meio tempo.
Limitar exposição
Outra maneira de reduzir risco de problemas quando trabalhamos favorecendo a velocidade em detrimento da estabilidade, é limitar a exposição de mudanças de algumas formas (ou seja, caso algo dê errado, só uma parte dos clientes vai ser exposta ao erro).
Procure oportunidades de experimentação em camadas mais “externas” do software. Ao fazermos mudanças em partes estruturais do sistema, arriscamos que um problema tenha um impacto na satisfação muito maior do que o possível retorno que o experimento traria, logo, queremos ficar longe de partes críticas do sistema. Se você está experimentando com uma regra de negócio super importante que roda no backend do seu sistema, pode ter problemas muito grandes ao introduzir mudanças.
Isso se alinha com a própria disciplina de experimentação, que procura os experimentos com maior ROI (retorno sobre investimento) e geralmente favorece em camadas mais baratas para alterar.
Apresente a alternativa apenas para um subconjunto de usuários. O próprio teste A/B é uma forma de cortar pela metade o potencial de impacto de um release com problemas. Além disso, podemos pensar em partir de um conjunto reduzido, como usuários que usam determinada feature, ou contas que existem há pelo menos 3 meses, por exemplo.
Review de código compartilhado
Partindo do pressuposto de que a pessoa engenheira de growth faz parte de um time dedicado para essa estratégia, é comum que essa equipe não seja dona de funcionalidades do produto, o que leva a pessoa engenheira a trabalhar em diversos projetos ao longo do tempo. Dessa forma, para mitigar o risco de problemas, é sugerido pedir revisão do código criado para integrantes do time que é dono daquela funcionalidade.
É importante salientar que essa técnica deve ser usada em casos mais críticos, pois normalmente o tempo de revisão de código por outros times leva uma quantidade de tempo considerável, consequentemente diminuindo a velocidade com que o experimento vai para produção.
A instrumentação e incidentes/reaberturas
Consideramos como incidente quando temos falhas no envio dos dados do experimento para as ferramentas de análise, por exemplo:
um experimento que é um teste A/B, onde na versão variante (B) temos um novo botão e na versão controle (A) esse botão não existe.
Dessa forma, queremos medir a quantidade de cliques desse botão, caso a instrumentação deste botão não esteja configurado de forma correta, todo o experimento está comprometido, pois não está sendo enviado para as ferramentas de análise os dados que validarão se o teste foi sucesso ou não, e isso se traduz em uma reabertura do experimento.
Em outras palavras, a reabertura do experimento é recomeçar a coleta de dados após feita a correção (que neste exemplo é receber a informação de quantos cliques o novo botão teve), e como explicado acima, quanto mais tempo levamos para ter o experimento no ar, mais tempo irá levará para se ter uma conclusão sobre a hipótese.
Conclusão
O time de growth é responsável por fazer experimentos de interação com os clientes, levantando dados e confirmando/refutando hipóteses de fluxos que podem aumentar a visibilidade, experiência ou até mesmo receita da sua aplicação. Se você se interessou em fazer diversos experimentos, confirmar hipóteses e coletar dados de forma rápida e precisa para seguir, temos vagas aqui em nosso time de growth! Utilizamos muito no-code, low-code com testes A/B e estatísticas para confirmar um experimento.
Vem escrever com a gente o próximo artigo sobre Growth! ;)
