Teste A/B é um tema super quente. E nós aqui da DiTi temos um vídeo ensinando como você pode publicar um teste A/B usando Google Optimize. Porém, neste artigo vamos falar de algo que vem um pouco antes da publicação do teste A/B em qualquer ferramenta.
Vamos falar sobre como priorizar o que iremos testar. Saber priorizar é crucial para squads/equipes hoje em dia, e o motivo é simples: ainda não podemos manipular o tempo. Então, o que nos resta é organizar como iremos utilizar este tempo para realizar ações que devem nos dar duas das coisas mais importantes para uma organização atualmente: resultados e aprendizado.
Atualmente, muitas empresas funcionam nos extremos. Ou tem que testar TUDO, ou não se testa NADA. E muitas vezes isso causa um impacto negativo nas entregas, reduzindo a velocidade da empresa em incrementar o produto ou serviço disponível para os clientes.
A resposta sempre é “depende”. Qual a capacidade que você tem para testar hoje? Se a equipe está 100% do tempo testando, quem está implementando as variantes vencedoras?
Equilíbrio é o que queremos encontrar. Da mesma forma que pessoas que fazem dieta não podem simplesmente parar de comer para perder peso, começar a testar 100% das coisas pode ter o efeito contrário e ao invés de tornar testes parte do processo natural nas squads/equipes, você pode causar um efeito reverso e ter pessoas rejeitando a prática.
O equilíbrio é importante também para a saúde financeira da empresa, algumas ferramentas gratuitas, como Google Optimize, tem um limite de testes que podem ser publicados em paralelo. E caso queira passar para a versão paga, a brincadeira fica séria.
Então, uma dica para criar um ciclo eficaz de descobertas é avançar de forma progressiva. Comece com 1 teste por semana, depois de algum tempo, aumente para dois e assim sucessivamente até, de forma saudável, ter uma cultura de testes.
Algumas empresas como Booking.com, Amazon.com, Airbnb e Netflix são super reconhecidas pela sua capacidade de realizar testes. A Booking tem, inclusive, um motor de teste A/B próprio, que é o ingrediente secreto da empresa. Tudo é testado, e o mais importante: a cultura da empresa já gira em torno disso.
Então, para as empresas que ainda não estão neste nível, tentar testar tudo pode ter o efeito inverso do esperado e tornar a empresa mais lenta. Porém, temos uma ferramenta para ajudá-los a priorizar o que testar.
Criada por Jeff Gothelf, a matriz é dividida em 4 quadrantes:
Neste quadrante, as hipóteses podem ter um alto retorno positivo, porém também apresentam riscos significativos. Estas hipóteses merecem um experimento para aprendermos mais sobre e descobrirmos se estamos no caminho certo.
Temos um nível alto de confiança de que estas hipóteses irão entregar valor para o negócio e para o cliente. Vamos construir, lançar e mensurar, sem gastar esforços do ciclo de descobertas.
Estas hipóteses não adicionam valor e têm um baixo risco, não necessitando de esforços do ciclo de descobertas. Porém, às vezes, ideias que caem aqui são necessárias para a operação do negócio. Não são um diferencial, mas precisamos delas para estar no jogo. Por exemplo: sistema de pagamento, políticas e privacidade, entre outras.
Estas hipóteses têm pouco valor percebido e trazem um risco potencial parao negócio ou produto. Não investiremos mais tempo nelas.
E dois eixos, sendo eles:
Qual o impacto desta hipótese na experiência com o produto/serviço? E para o negócio, qual o impacto?
Algumas perguntas para ajudar a definir se tem alto ou baixo valor percebido:
Qual o risco desta hipótese para a experiência e para o negócio?
Algumas perguntas para ajudar a definir nível de risco:
Este canvas pode ser preenchido em um workshop interativo de uma hora, para aproveitar a inteligência coletiva, onde a soma das partes é maior que o todo. Entre os possíveis participantes, podem estar:
Este canvas também pode ser preenchido em uma sessão apenas com o Product Owner, sem problemas.
O mais importante aqui são os argumentos que definem se uma hipótese é percebida com alto ou baixo valor percebido e alto ou baixo risco!
Uma vez definida a hipótese, podemos alimentar nosso backlog seguindo os devidos critérios de qualidade e aceitação para itens que serão entregues ou testados.
Ou seja, uma hipótese que tem alto valor percebido e baixo risco. Deve passar pelo crivo de qualidade de coisas que esperamos ser estáveis. Ou seja: código limpo, design consistente, tom e voz adequado, testes de qualidade/usabilidade.
Ou seja, uma hipótese que tem alto valor percebido e alto risco. Deve ter um crivo de qualidade mais leve. O objetivo aqui não é ter o melhor código do mundo, o melhor design do mundo. O objetivo aqui é aprender a melhor forma de realizar esta hipótese no menor tempo possível para aprendermos com mais velocidade. Este é o maior desafio para as equipes, normalmente vemos empresas construindo testes com o mesmo critério usado para construção de funcionalidades e melhorias. Por ser um teste, o objetivo é termos mais variações que resolvem a mesma hipótese e desenvolver da forma mais simples possível para funcionar. No caso de uma das variantes se provar vencedora, a hipótese deve ganhar prioridade para receber todos os finos tratos necessários para se tornar estável.
No caso onde a hipótese é inconclusiva ou carrega resultados negativos, o fardo de ter desperdiçado tempo e energia em algo que se provou inútil não existe. Pois foi investido pouco tempo lapidando a hipótese e suas variações.
Conforme testes vão acontecendo e resultados aparecendo, você pode dar um zoom out no seu ciclo de descoberta e medir algumas coisas como:
As duas primeiras métricas vão te ajudar a melhorar o processo de descoberta e aplicação de testes de forma organizacional. Ou seja, qual a eficiência para o processo de descoberta?
Já a última métrica vai te dar uma ideia de eficácia no processo de descoberta, e é onde você vai ser capaz de definir o retorno que o investimento de tempo e energia em um ciclo de descoberta guiado por testes traz para a organização. Esta última métrica deve ser lida da seguinte forma:
Nosso win rate é de 25%, ou seja, a cada 4 testes, 1 traz resultados significativos para a experiência ou o negócio. A cada 4 testes, 3 nos ajudam a não perder tempo à toa ou a evitar inserir funcionalidades que prejudicam a experiência ou o negócio.
Respeitando estas premissas, não tem como dar errado. Inserir um ciclo de descobertas para apoiar o processo de evolução de um produto/serviço é mais simples do que parece e os seus resultados são impressionantes: ou ganhamos ou evitamos desperdiçar.
Curtiu este conteúdo? Conta aqui nos comentários!
Ah, nós da DiTi podemos te ajudar a inserir em sua empresa, de forma saudável, um ciclo de descobertas. Caso queira seguir por conta própria, nós traduzimos para o português o canvas de priorização criado por Jeff Gothelf. :)
