DevSecOps

20 fev, 2019

Métricas de HDD (Hypothesis-Driven Development) no Azure DevOps

Publicidade

As métricas são essenciais quando trabalhamos com HDD (Hypothesis-Driven Development), pois direcionam as decisões e proveem visibilidade sobre a aceitação dos produtos ou serviços.

Há algumas recomendações na adoção de métricas para não se tornarem irrelevantes ao seu negócio.

Actionable metrics são exemplos de métricas consideradas importantes, pois resultam em ações específicas e repetíveis no apoio a tomada de decisão e cumprimento dos objetivos.

A abordagem HDD pode ser utilizada neste contexto para desenvolver e experimentar implementações que adicionem valor ao negócio. Comece com poucas métricas e que façam sentido para o seu time.

O metrics that matter, definido por Dave McClure como AARRR Pirate Funnel Metrics, possui as seguintes métricas para acompanhamento:

  • Acquisition: número de usuários que visitam o serviço ou produto. Essa métrica precisa garantir o acompanhamento correto da fase de aquisição e quantidade de conversão de clientes. Por exemplo, qual o maior volume nos canais de venda? Qual a melhor performance entre os canais?
  • Activation: mensura como está a resposta inicial dos usuários em relação a ativação do serviço. Como foi a experiência do usuário na sua primeira visita? Tempo de permanência, page views, cliques, entre outros, são boas métricas. Os testes A/B podem apoiar com landing pages e conteúdo para obter melhor experiência
  • Retention: a retenção dos clientes, mantendo por perto as pessoas que se inscreveram e utilizam um dos serviços. A automação de e-mails, por exemplo, baseada em eventos ou atividades podem apoiar de forma simples
  • Revenue: número de pessoas engajadas com a geração de receita
  • Referral: referências de usuários que encorajam outros a utilizarem seus produtos e serviços. Os testes qualitativos são aplicáveis a um número menor de usuários para depois disseminar o produto a um número maior de usuários
Figura: AARRR Pirate Funnel Metrics

Com o uso do AARRR, um dashboard de acompanhamento para cada categoria é importante para dar visibilidade às áreas: quantitativa (análise de tráfego e engajamento), qualitativa (teste de usabilidade e monitoramento da sessão), comparativa (testes A/B) e competitiva (monitoramento e rastreamento do mercado). Veja no dashboard abaixo algumas métricas desde a etapa de acquisition até a revenue.

Figura: AARRR Pirate Funnel Metrics

Um outro exemplo de utilização do AARRR pela Apptentive, que demonstra o funil aplicado a um produto de Mobile App. Na fase de Acquisition, mensura-se a quantidade de downloads, instalações e visitas na página. Em Activation, mais direcionado ao uso – tempo de permanência e telas visualizadas.

A Retention verifica a permanência, considerando usuários ativos por mês e frequência do uso. Em Referral, além das referências, as avaliações e revisões dos usuários sobre o produto. Por fim, Revenue considera a monetização como a receita média por usuário e compras do App.

Figura: The Mobile App Customer Purchase Funnel Cheat Sheet

Em uma visão adicional do AARRR, também de Dave McClure, fica bem claro o exemplo da aplicabilidade para cada métrica. Começando com a conversão de tráfego, seguida da análise pós inscrição e assinatura.

A retenção verifica os usuários que interromperam o uso e a referência avalia métricas como NPS de satisfação e lealdade dos clientes. Por fim, a receita direciona a dados monetários como o custo de aquisição do cliente e o valor do tempo de vida do cliente.

Figura: Conversion Metrics Example

Em um artigo anterior demonstramos a criação das HDDs e como gerenciar o desenvolvimento no Azure DevOps. Para representar as métricas de acompanhamento das HDDs, crie inicialmente uma query em Boards > Query. No exemplo abaixo, criamos três gráficos:

  • Status: visualiza as HDDs por status; o intuito é verificar o WIP e possíveis gargalos
  • Owner: incluído story points e o proprietário da tarefa, afim de acompanhar a capacidade dos recursos
  • Validadas*: sim ou não. O experiment framework sugere marcar como “validated” ou “falsified” quando a tarefa passa para a coluna Completed Experiments, afim de determinar se aquela hipótese foi válida ou não

* Para possibilitar isso, precisamos incluir um novo campo na User Story (ou HDD), acessando “Organization Settings > Boards | Process > Processo utilizado > Work item type”. No exemplo abaixo criamos um novo campo do tipo Picklist.

E o resultado final com os gráficos e as métricas de acompanhamento das HDDs:

Até a próxima!