Discovery - Julgamento

Marty Cagan - 10/09/2020 Traduzido por: Raphael Jubram

Para continuar com a série sobre fontes comuns de confusão relativamente à descoberta de produtos, neste artigo quero falar sobre o papel crítico do julgamento na descoberta de produtos.


Esta pode, de fato, ser a confusão mais comum que encontro. Penso que a fonte da questão é que muitas pessoas de produto foram levadas a acreditar (e desejam acreditar) que existe um framework ou modelo para tudo. Mas o produto tem muito a ver com julgamento.


Em termos de descoberta de produtos, existem quatro áreas principais onde o julgamento é necessário, e vou discutir cada uma delas aqui:


Avaliar o risco


No centro da descoberta do produto está o fato de termos quatro grandes riscos com tudo o que procuramos: valor, usabilidade, factibilidade (feasibility) e viabilidade (viability).


Contudo, isso não significa que os quatro riscos sejam significativos ou iguais. Tudo o que perseguimos tem um perfil de risco diferente. E também é verdade que para muitos dos itens menores, nenhum dos riscos é significativo. Nesse caso, limitamo-nos a acrescentar o trabalho ao backlog e seguimos em frente.


Será possível que você esteja errado, e o que parece ser um risco menor acaba por ser um risco maior? Com certeza. E, ocasionalmente, você aprende isso da maneira mais difícil. Mas perceba que se tratasse cada risco como um risco maior, então a) iria se mover muito lentamente; e b) provavelmente não teria o tempo necessário para os itens que possuem verdadeiramente riscos maiores.


De um modo mais geral, sempre que se considera o risco, é necessário considerar as consequências.


Em outras palavras, com muitos riscos, se você acaba julgando algo errado, mas o tempo e esforço para corrigir esse erro são apenas algumas horas de trabalho, então essa é uma situação muito diferente daquela em que o erro causa uma perda substancial de receita, ou tempo e esforço para corrigir.


Portanto, é essencial que ao planejar o seu trabalho de descoberta, você considere cada um dos quatro riscos, e julgue tanto a sua gravidade, como a sua potencial consequência.


Note também que é absolutamente essencial apoiar-se nos outros membros da sua equipe de produto ao avaliar os riscos.


Um dos problemas mais comuns, mas em grande parte evitáveis, é quando um(a) gerente de produto julga o risco de viabilidade técnica, sem consultar a equipe de engenharia. Quando um esforço acaba demorando substancialmente mais tempo do que o previsto, esta é muitas vezes a causa principal.


Do mesmo modo, é importante apoiar-se no(a) designer de produto ao avaliar os riscos de usabilidade. Especialmente com fluxos de trabalho complexos como é frequentemente o caso de software B2B, pode ser fácil subestimar a complexidade e os riscos associados.


Avaliar as evidências necessárias


Depois de termos identificado o que julgamos ser os maiores riscos, então você terá que decidir quantas evidências precisa para se sentir confortável a tomar uma decisão.


As evidências podem abranger todo o espectro desde apenas opiniões qualitativas de um pequeno grupo de usuários num extremo, até resultados estatisticamente significativos num teste de descoberta A/B no outro extremo. Nesse intervalo você encontrará feedback qualitativo de um grupo maior, ao feedback quantitativo que vem de um grupo menor e, portanto, com um nível de confiança mais baixo, e muitas outras formas de evidência.


Você poderá sempre insistir no mais alto nível de evidência (evidência estatisticamente significativa), mas com a maioria dos produtos, pagará um preço muito elevado por isso em termos de tempo.


Queremos avançar rapidamente, mas também temos a responsabilidade de proteger as receitas, a marca, os clientes e os colegas.


Voltamos, portanto, ao julgamento. Precisamos equilibrar tempo e custo contra o risco e consequência.


Para as equipes que aconselho, gosto de reservar os testes de dados em tempo real e em grande escala para as questões verdadeiramente arriscadas e de grandes consequências, e gosto de tomar a maior parte das decisões com base em testes qualitativos muito mais rápidos, embora de menor confiança.


Avaliar o Escopo do Trabalho


A terceira dimensão do julgamento tem a ver com o reconhecimento do escopo do trabalho do produto. Isto normalmente relaciona-se diretamente à consequência, porém nem sempre, pelo que é importante considerar essa dimensão.


Cada equipe de produto trabalha numa vasta gama de esforços, desde simples correções de bugs, a melhorias de performance, a otimizações, a funcionalidades, a projetos maiores até iniciativas muito grandes.


Os projetos e iniciativas são, quase por definição, arriscados. Só por causa do grande tempo e esforço que lhes é dedicado. Você não quer mesmo que eles falhem.


Por outro lado, funcionalidades podem variar desde as muito pequenas e de baixo risco, até às muito complicadas e de alto risco. Mesmo certas correções de bugs têm o potencial de causar danos reais.


Assim, mais uma vez, você terá que julgar a situação e determinar onde precisa passar a maior parte do seu tempo na descoberta.


Avaliar a Documentação Necessária


Esta última área é um pouco diferente das outras, mas é uma questão muito comum, especialmente num mundo de trabalho remoto.


Um dos benefícios secundários das equipes de produto co-localizadas é que os(as) engenheiros(as) estão tão envolvidos(as) no trabalho de descoberta que quando algo está pronto para ser desenvolvido, muitas vezes sabem exatamente o que precisam fazer.


Um dos benefícios secundários dos protótipos é que fazem um trabalho muito melhor de descrição do comportamento necessário do que a maioria dos documentos.


Entre os protótipos e a co-localização, os(as) engenheiros(as) já identificaram fontes de ambiguidade, e tiveram as suas perguntas respondidas.


Contudo, quando a equipe não está co-localizada, tal como quando parte ou toda a equipe está trabalhando de casa, os(as) engenheiros(as) podem não participar tanto do trabalho de descoberta como antes, por isso, quando chega o momento de desenvolver, podem ter muito menos clareza. Neste caso, podem pedir documentação adicional.


A chave é que precisamos fornecer a documentação necessária, mas não queremos fornecer nada além disso, porque isso é uma grande perda de tempo para produzir.


O erro comum que encontro é que as empresas acabam criando um modelo deste tipo de documentação suplementar, e eventualmente, o que começa como documentação mínima, cresce para uma grande sobrecarga que de qualquer forma raramente é lida.


Por isso, por favor, não faça esse modelo, e em vez disso, use o seu julgamento em cada coisa que irá descrever. Fale com os(as) engenheiros(as) sobre o que eles(as) precisam especificamente para este caso, e depois o(a) gerente de produto e o(a) designer podem fornecer isto.


Este é um daqueles casos em que a experiência é uma vantagem real. Um(a) líder técnico(a) de engenharia, ou um(a) designer de produto, ou um(a) gerente de produto que tenha experimentado uma vasta gama de trabalho de produto, já terá aprendido muitas das lições necessárias.


Quando você tem um membro de equipe mais novo, que provavelmente não tem esta experiência, então dependemos do(a) gestor(a) da pessoa para fornecer o coaching necessário ao desenvolvimento deste julgamento.

Artigo Original: https://bit.ly/30fYujg

140 visualizações0 comentário