Estamos atuando em problemas ou features?
Precisamos nos perguntar primeiramente: como ele surgiu? Através de ferramentas de análise de usabilidade? Através de um discovery? Ou o negócio descobriu e trouxe pro jogo?
Em um segundo momento essa entrega gera valor para quem? O negócio? Uma persona? Um stakeholder?
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Albert Einstein
Muitas organizações cometem o erro de identificar uma funcionalidade sem uma pesquisa prévia. Um direcionamento do stakeholder, uma "falta" identificada pelo product owner, ou aquele comentário: "mas no legado tínhamos essa funcionalidade!"
A fala de Jim Johnson do Standish Group talvez chacoalhe o seu coraçãozinho: “64% das funcionalidades que criamos em softwares raramente ou nunca são usadas pelos usuários”.
Parece loucura, mas sabemos que não é. Então, como podemos virar o jogo?
A pergunta mais direcionada para quando essa situação se apresenta é: Como esse problema chegou até você?
Se a resposta foi: através de uma liderança desconhecida, acordei e estava na minha mesa (ou no backlog do produto), apareceu como um item indispensável pelo negócio. Coloque seu deerstalker cap, pegue uma lupa e vamos a investigação Sherlock!
Atente-se aos detalhes: se o problema tem especificações de tecnologia, mas não tem uma persona direcionada. Você está lidando com um feature!
Neste momento, existem focos voltados para o que acontece (por meio de ferramentas de análise de dados) e por que acontece (se conectando com quem consome a solução). O processo de Problem Research deve utilizar dados quantitativos e qualitativos para termos a validação do “o que” e “por que” o comportamento ocorre.
Como construir um problem research:
Problem Statement: Qual o problema na visão do usuário, na visão do cliente, na visão do negócio?
Análise quantitativa: Volume de dados (quantidade/período) Vs Dados do cliente (segmento/jornada de sucesso)
Análise qualitativa: Principais dificuldades do ponto de vista do cliente/stakeholders e usuários
Se você não consegue vislumbrar nenhuma dessas análises, volte uma casa e vamos olhar para o problema e não para o feature, tendo sempre em mente que o feature é apenas uma forma de solucionar o problema!
Disclaimer: O problema pode existir com algumas premissas de tecnologia, se ele acontece dentro de um produto e surgiu através de um discovery contínuo. O importante é entender se o cliente está no centro da solução e tem uma dor diretamente conectada a esse problema.
Dica de Sherlock: Levante pesquisas com os usuários para identificar os atritos da experiência e como eles impactam o usuário, descreva o cenário de forma quantitativa, faça uma análise consistente de tendências do mercado e experimente, utilize de workshops para tomada de decisão junto ao negócio.
Sem pesquisa e dados não há argumentos. Ou quase isso! Mantenha o mantra em mente: nenhuma proposta de solução é definitiva, certa ou errada!
Se ainda sim você tiver uma solução nas mãos e não tem como fugir, entenda os seguintes riscos apresentados por Marty Cagan no livro Inspired:
- Risco de valor: o cliente irá comprar ou escolherá usar essa solução?
- Risco de usabilidade: o cliente entenderá como utilizar essa solução?
- Risco de execução: temos capacidade para construir essa solução?
- Risco de viabilidade: Essa solução funciona para nosso negócio?
E para finalizar atente-se para o seguinte:
Revise as entregas e se elas estão atendendo as necessidades do usuário. Reflita no que motivou aquela dor e no cenário em que ela acontece. Questione se a proposta de solução gera uma experiência conclusiva na atividade.
Foca no probleminha bebê!
