Antes de criar uma função, devemos nos perguntar rigorosamente: Devemos criá-la? e por quê?
Em seguida, devemos realizar os experimentos mais baratos e mais rápidos possíveis para validar através da pesquisa do usuário se a função desejada realmente alcançará os resultados desejados.
Uma vez que tenhamos a infraestrutura para suportar a liberação e testes de recursos A/B, precisamos ter certeza de que os proprietários de produtos pensem em cada recurso como uma hipótese e usem nossas versões de produção como experimentos com usuários reais para testar ou refutar essa hipótese.
Os experimentos de construção devem ser projetados no contexto do funil geral de aquisição de clientes. Barry O’Reilly, coautor de Lean Enterprise:How High Performance Organizations Innovate at Scale, descreveu como podemos enquadrar hipóteses no desenvolvimento de funções da seguinte forma:
- Acreditamos que aumentar o tamanho das imagens do hotel na página de reservas
- resultará em melhor engajamento e conversão do cliente
- Teremos confiança para continuar quando vermos um aumento de 5% nos clientes revisando imagens de hotéis e, em seguida, passar a reservar em quarenta e oito horas.
Tomar uma abordagem experimental para o desenvolvimento de produtos requer que não apenas dividamos o trabalho em pequenas unidades (histórias ou requisitos), mas também validemos se cada unidade de trabalho entrega os resultados esperados. Se não, modificamos nossa rota de trabalho com caminhos alternativos que realmente alcançarão esses resultados.
We believe that
[building this feature]
[for these people]
will achieve [this outcome]
We will know we are successful when we see
[this signal from the market]
Neste formato, descrevemos os parâmetros do experimento que realizaremos para testar o valor do recurso proposto. O resultado descreve a condição objetiva que pretendemos alcançar. Assim como no formato ágil da história, resumimos o trabalho (por exemplo, o recurso que queremos construir ou a mudança de processo de negócios que queremos fazer) em poucas palavras para nos permitir lembrar a conversa que tivemos sobre ele como uma equipe. Também especificamos a pessoa cujo comportamento mediremos ao executar o experimento. Finalmente, especificamos o sinal que mediremos no experimento.
Mapeamento de impacto
Desenvolvimento por Hipóteses
A técnica chamou mapeamento de impacto para quebrar objetivos de negócios de alto nível no nível do programa em hipóteses testáveis. “uma visualização do escopo e das premissas subjacentes, criadas de forma colaborativa por um grupo interfuncional de stakeholders. Um mapa mental é desenvolvido durante uma discussão facilitada respondendo às seguintes perguntas: 1. Por quê? 2. Quem? 3. Como? 4. O quê?
As possíveis soluções propostas no mapa de impacto não são a chave possível. Propor possíveis soluções simplesmente nos ajuda a refinar nosso pensamento sobre o objetivo e as partes interessadas. As soluções que podemos pensar nesta fase são improváveis de serem as melhores; em vez disso, esperamos que as pessoas que trabalham para alcançar os resultados venham com melhores opções e avaliá-los para determinar quais alcançarão melhor nossa condição-alvo.
O mapa de impacto pode ser considerado um conjunto de suposições; por exemplo, na Figura, assumimos que a padronização de códigos de exceção reduzirá as ordens não padronizais, o que reduzirá o custo de processamento de transações não padronizais.
Para que essa ferramenta funcione de forma eficaz, é fundamental que as pessoas certas participem do exercício de mapeamento de impacto. Pode ser uma equipe pequena e multifuncional que inclui stakeholders de negócios, equipe técnica,designers, garantia de qualidade (quando aplicável), operações de TI e suporte.
Se o exercício for realizado exclusivamente por partes interessadas empresariais, eles perderão a oportunidade de examinar as suposições por trás das condições-alvo e obter ideias dos designers e engenheiros mais próximos do problema. Um dos objetivos mais importantes do mapeamento de impacto é criar um entendimento compartilhado entre as partes interessadas, de modo que não os envolver o condena à irrelevância. Uma vez que tenhamos uma lista priorizada de condições-alvo e mapas de impacto criados de forma colaborativa por técnicos e empreendedores, as equipes devem determinar o caminho mais curto possível para a condição de alvo.
Esta ferramenta difere significativamente de muitas abordagens padrão para pensar sobre os requisitos. Aqui estão algumas das diferenças importantes e as motivações por trás delas:
Não há listas de funções no nível do programa.
- As características são simplesmente um mecanismo para alcançar o objetivo.
- Especificar condições de destino em vez de características nos permite responder rapidamente às mudanças em nosso ambiente e às informações que coletamos das partes interessadas enquanto trabalhamos em direção à condição de destino.
- Evite a “perda de recursos” durante a iteração. Mais importante, é a maneira mais eficaz de fazer uso dos talentos daqueles que trabalham para nós; isso os motiva dando-lhes a oportunidade de buscar domínio, autonomia e propósito.
Não há uma estimativa detalhada
- Nosso objetivo é uma lista de condições objetivas que é um objetivo elástico;ou seja, se todas as nossas suposições forem boas e todas as nossas apostas funcionarem, acreditamos que seria possível alcançá-las.
- No entanto, isso raramente acontece, o que significa que podemos não alcançar algumas das condições de meta de menor prioridade.
- Se estamos regularmente alcançando muito menos, precisamos reequilibrar nossas condições-alvo em favor das metas de melhoria de processos.
- Sem “épicos arquitetônicos”
- As pessoas que fazem o trabalho devem ter total liberdade para realizar qualquer trabalho de melhoria que desejarem (incluindo mudanças arquitetônicas, automação e refatoração) para melhor alcançar as condições-alvo.
- Se quisermos conduzir metas específicas que exigirão trabalho arquitetônico, como cumprimento ou melhoria de desempenho, as especificamos em nossas condições de destino.
Integrando testes A/B em testes funcionais
Desenvolvimento por Hipóteses
Um teste A/B é um experimento controlado randomizado para descobrir qual das duas versões possíveis de uma página web produz melhores resultados. Ao executar um teste A/B, preparamos duas versões de uma página:
- um controle (geralmente a versão existente da página) e
- um novo tratamento que queremos tentar.
Quando um usuário visita nosso site pela primeira vez, o sistema decide quais experimentos o usuário estará sujeito e, para cada experimento, escolhe aleatoriamente se verá controle (A) ou tratamento (B). Nós instrumentamos o máximo de interação do usuário com o sistema possível para detectar quaisquer diferenças comportamentais entre controle e tratamento.
Com base na análise estatística do comportamento subsequente desses dois grupos de usuários, demonstramos se há uma diferença significativa nos resultados dos dois, estabelecendo um nexo causal entre o tratamento (por exemplo, uma mudança em um recurso, elemento de design, fundo de cor) e o resultado (por exemplo, taxa de conversão, tamanho médio da ordem). Por exemplo, podemos realizar um experimento para ver se modificar o texto ou cor em um botão “comprar” aumenta os lucros ou se o tempo de resposta de um site é mais lento (introduzindo um atraso artificial como um tratamento) reduz os lucros. Este tipo de teste A/B nos permite estabelecer um valor monetário em melhorias de desempenho.
Às vezes, os testes A/B também são referidos como experimentos controlados on-line e testes divididos. Também é possível realizar experimentos com mais de uma variável. Isso nos permite ver como as variáveis interagem, uma técnica conhecida como teste multivariado.
Resultados
Os resultados dos testes de A/B são geralmente surpreendentes. Ronny Kohavi, distinto engenheiro e gerente geral do grupo de análise e experimentação da Microsoft, observou que depois de “avaliar experimentos bem projetados e executados que foram projetados para melhorar uma métrica chave, apenas cerca de um terço foi bem sucedido em melhorar a métrica chave!” .
Em outras palavras, dois terços das funções têm um impacto insignificante ou pioram as coisas. Kohavi continua a apontar que todos esses recursos foram originalmente pensados como boas ideias razoáveis, elevando ainda mais a necessidade de testes de usuários acima da intuição e opiniões de especialistas. As implicações dos dados de Kohavi são impressionantes.
Se não estamos realizando pesquisas de usuários, as chances são de que dois terços dos recursos que estamos construindo fornecerão valor zero ou negativo à nossa organização, mesmo que tornem nossa base de código cada vez mais complexa, aumentando nossos custos de manutenção ao longo do tempo e tornando nosso software mais difícil de mudar.
Além disso, o esforço para construir esses recursos é muitas vezes feito às custas da entrega de recursos que forneceriam valor (ou seja, custo de oportunidade). Jez Humble brincou: “Levado ao extremo, a organização e os clientes estariam melhor se tivessem dado férias a toda a equipe, em vez de construir uma dessas características que não agregam valor.” Nossa contramedida é integrar testes A/B na maneira como projetamos, implementamos, testamos e implementamos nossas funções.
Realizar pesquisas e experimentos significativos de usuários garante que nossos esforços ajudem a alcançar os objetivos de nossos clientes e da organização, e nos ajude a vencer no mercado.
Integrando testes A/B em testes de lançamento
Desenvolvimento por Hipóteses
Testes rápidos e iterativos de A/B são possíveis pela capacidade de executar implantações de produção sob demanda de forma rápida e fácil, usando switches de recursos e potencialmente fornecendo várias versões do nosso código simultaneamente para segmentos de clientes. Fazer isso requer telemetria de produção útil em todos os níveis da pilha de aplicativos.
Ao conectar nossos toogles de recurso, podemos controlar qual porcentagem de usuários vêem a versão de tratamento de um experimento. Por exemplo, metade dos nossos clientes pode ser nosso grupo de tratamento e metade pode ser mostrada o seguinte: “Link para itens semelhantes em itens não disponíveis no carrinho.” Como parte do nosso experimento, comparamos o comportamento do grupo controle (sem oferta) com o grupo de tratamento (oferta feita), talvez medindo o número de compras feitas naquela sessão.
A Etsy abriu sua estrutura de experimentação de API de características (anteriormente conhecida como API Etsy A/B), que não só suporta testes A/B, mas também ramp-ups on-line, possibilitando limitar a exposição a experimentos. Outros produtos de teste A/B incluem Optimizely, Google Analytics, etc.
Em uma entrevista de 2014 com Kendrick Wang, da Apptimize, Lacy Rhoades on Etsy descreveu sua jornada: “A experimentação em Etsy vem do desejo de tomar decisões informadas e garantir que quando lançamos recursos para nossos milhões de membros, eles funcionam. Muitas vezes, tínhamos recursos demorados que tinham que ser mantidos sem qualquer prova de seu sucesso ou popularidade entre os usuários. O teste A/B nos permite… dizer que vale a pena trabalhar em uma função assim que ela está em andamento.
Newsletter HNZ
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
