“A dificuldade em definir a qualidade é traduzir as necessidades futuras do usuário em recursos mensuráveis, para que um produto possa ser projetado e produzido para satisfazer um preço a ser pago pelo usuário.” Walter Shewhart
Se não estamos realizando experimentos para testar o valor de novas ideias antes de desenvolvê-las totalmente, é provável que cerca de 2/3 do trabalho que estamos fazendo seja de valor zero ou negativo para nossos clientes, e certamente de valor negativo para nossa organização, uma vez que este trabalho nos custa de três maneiras:
- o custo do desenvolvimento das funções,
- custo de oportunidade (trabalho mais valioso em vez disso),
- custo da nova complexidade (custo de manutenção, velocidade e redução da estabilidade operacional e desempenho).
Muitas vezes, em projetos de software, os desenvolvedores trabalham em funções por meses ou anos, abrangendo várias versões, nunca confirmando se os resultados de negócios desejados estão sendo cumpridos, como se uma determinada função está alcançando os resultados desejados, ou mesmo se está sendo usada. Pior ainda, mesmo quando descobrimos que uma determinada função não está alcançando os resultados desejados, fazer correções para a função perde prioridade em relação a outras novas funções, garantindo que a função de baixo desempenho nunca atinja seu objetivo de negócio pretendido.
Em geral, observa Jez Humble, “a maneira mais ineficiente de testar um modelo de negócio ou uma ideia de produto é construir todo o produto para ver se a demanda prevista realmente existe”.
O cenário acima é o de uma organização que não utiliza o desenvolvimento orientado por hipóteses. Se você quiser entender mais como realizar esse modelo escrevemos um artigo completo explicando o que é desenvolvimento por hipóteses e que são as suas técnicas.
Benefícios do desenvolvimento orientados por hipóteses
Desenvolvimento por Hipóteses
O sucesso exige que não só implantemos e lançamos software rapidamente, mas também sobreporemos nossa concorrência.
Técnicas como desenvolvimento orientado por hipóteses, definição e medição do funil de aquisição de clientes e testes A/B nos permitem realizar experimentos de usuários com segurança e facilidade, permitindo-nos liberar criatividade e inovação e criar aprendizado organizacional. E, embora o sucesso seja importante, o aprendizado organizacional que vem da experimentação também dá aos funcionários a propriedade das metas de negócios e satisfação do cliente.
Um dos desafios mais comuns encontrados no desenvolvimento de software é o foco de equipes, gerentes de produtos e organizações na gestão de custos em vez de valor.
Isso geralmente se manifesta em um esforço indevido investido em atividades de adição de valor zero, como análise inicial detalhada, estimativa, gerenciamento de escopo e preparação de acumulação.
Esses sintomas são o resultado de focar na maximização da utilização (manter nossas pessoas caras ocupadas) e maximizar a produção (medir seu produto de trabalho), em vez de focar em resultados, minimizar a produção necessária para alcançá-los e reduzir o lead time (ciclo de entrega) para obter uma resposta rápida sobre os resultados de nossas decisões. A maioria das ideias, mesmo aparentemente boas, oferecem valor zero ou negativo aos usuários.
Focando nos resultados que queremos alcançar, em vez das soluções e recursos, podemos separar o que estamos tentando fazer das maneiras possíveis de fazê-lo. Em seguida, seguindo o Princípio da Missão, as equipes podem realizar pesquisas de usuários (incluindo experimentos on-line de baixo risco e seguro para falhar) para determinar o que realmente fornecerá valor aos clientes e à nossa organização. Isso nos permite descobrir, desenvolver e fornecer soluções de alta qualidade e alto valor para os usuários em escala, aproveitando a habilidade e a engenhosidade de todos na organização.
ESTUDO DE CASO – Yahoo responde aumento em 72% como visitas mensais com o desenvolvimento orientado por hipóteses
Desenvolvimento por Hipóteses
O objetivo do Yahoo era dobrar o crescimento da receita experimentando o rápido ciclo de lançamento no Yahoo! Answers (2010)
Quanto mais rápido pudermos iterar e integrar feedback no produto ou serviço que oferecemos aos clientes, mais rápido poderemos aprender e maior o impacto que pudermos criar. Ficou evidente no Yahoo! Respostas como eles passaram de um lançamento a cada seis semanas para vários lançamentos a cada semana.
Em 2009, Jim Stoneham que foi diretor geral do Yahoo! Grupo comunitário geral que incluiu Flickr e Answers. Antigamente ele havia sido o principal responsável do Yahoo! Answers, competindo com outras empresas de perguntas e respostas como: Quora, Aardvark e Stack Exchange. Nesse momento o Yahoo Answers tinha aproximadamente 140 Milhões de visitantes mensais, com mais de vinte milhões de usuários ativos respondendo perguntas em mais de vinte línguas diferentes. Sem embargo, o crescimento de usuários e a entrada estagnaram e as pontuações de participação dos usuários estava diminuindo.
Stoneham observa que “Yahoo Answers foi e continua a ser um dos Jogos Sociais mais importantes da Internet; Dezenas de milhões de pessoas estão ativamente tratando de “subir de nível” fornecendo respostas de qualidade para as perguntas mais rápido do que o próximo membro da comunidade. Foram muitas oportunidades para modificar a mecânica do jogo, os laços virais e outro Interações da comunidade. Quando é sobre estes comportamentos humano deve-se ser capaz de realizar iterações e testes rápido para ver o que atrai os cliques das pessoas. Estes [experimentos] são as coisas que o Twitter, Facebook e Zynga fizeram tão bem. Essas organizações estavam fazendo experimentos pelo menos duas vezes por semana; incluindo que estavam revisando as alterações que fizeram antes das suas implementações, para assegurar-se que estavam no caminho correto. Então aqui estou, executando [o] maior lugar de perguntas e respostas do mercado, com o desejo de realizar testes rápidos de funções iterativas, mas não podemos lançar mais rápido do que uma vez a cada 4 semanas. Em contraste, os outros players do mercado tiveram um ciclo de realimentação 10 vezes mais rápido do que nós “.
Stoneham observou que, por mais que os proprietários de produtos e desenvolvedores falem sobre serem impulsionados por métricas, se os experimentos não são feitos com frequência (diariamente ou semanalmente), o foco do trabalho diário é simplesmente na função em que estão trabalhando, em oposição aos resultados dos clientes…
Como o Yahoo! A equipe de Answers foi capaz de passar para implantações semanais e, posteriormente, para várias implantações por semana, sua capacidade de experimentar novos recursos aumentou drasticamente.
Suas incríveis conquistas e aprendizados nos doze meses seguintes de experimentação incluíram um aumento de 72% nas visitas mensais, um aumento triplo no engajamento dos usuários e a equipe dobrou sua receita.
Para continuar seu sucesso, a equipe se concentrou em otimizar as seguintes métricas principais:
- Tempo para primeira resposta: Quão rapidamente uma resposta à pergunta de um usuário foi postada?
- É hora de responder melhor: Quão rapidamente a comunidade de usuários respondeu melhor?
- Feedback positivo por resposta: Quantas vezes a comunidade de usuários votou a favor de uma resposta?
- Respostas/semana/pessoa: Quantas respostas os usuários estavam criando?
- Segunda taxa de pesquisa: Com que frequência os visitantes tinham que procurar novamente para obter uma resposta? (Inferior é melhor.)
Stoneham concluiu: “Este era exatamente o aprendizado que precisávamos para ganhar no mercado, e mudou mais do que a velocidade de nossas funções. Nós transformamos de uma equipe de funcionários para uma equipe de proprietários. Quando você se move a essa velocidade e olha para os números e resultados diariamente, seu nível de investimento muda radicalmente.”
Newsletter HNZ
Gostou de conteúdo? Inscreva-se na nossa newsletter grátis e receba toda semana em seus e-mails artigos e vídeos sobre o tema! Clique aqui!
