Uma declaração útil do problema descreve uma lacuna observada entre o que as pessoas precisam realizar e o que acontece hoje. Inclua o grupo afetado, a tarefa ou o processo, as condições em que a lacuna aparece e sua consequência. Deixe a solução preferida e uma causa não verificada fora da declaração para que continuem abertas à investigação.
Não existe um único formato obrigatório de declaração do problema para todas as organizações. O formato abaixo é um recurso prático de escrita. Ele funciona para uma descoberta de produto, uma proposta de projeto ou um problema recorrente identificado em uma retrospectiva de equipe.
O princípio de entender o problema antes de se comprometer com uma solução também aparece nas orientações de discovery do GOV.UK. Os exemplos e a oficina deste artigo são ilustrações hipotéticas originais, não resultados relatados por clientes.
Um formato copiável de declaração do problema
Use esta frase como ponto de partida:
Quando [contexto], [grupo afetado] precisa [tarefa ou resultado desejado], mas [lacuna observada]. Evidências de [fonte e período] mostram [escopo ou frequência, se conhecido], o que resulta em [consequência sustentada pelas evidências].
Em seguida, adicione uma breve observação sobre as evidências:
- Conhecido: observações que sustentam a declaração.
- Desconhecido: perguntas que poderiam mudar a interpretação.
- Fora do escopo: problemas relacionados que este esforço não abordará.
- Sinal de sucesso: mudança observável que faria diferença.
Não force um número em todos os campos. “Frequência ainda não medida” é mais confiável do que uma linha de base inventada. Se a fonte cobrir uma amostra pequena ou incomum, indique essa limitação. A declaração deve ficar mais precisa à medida que as evidências melhoram.
O que deve fazer parte da declaração?
| Elemento | Formulação útil | Formulação a questionar |
|---|---|---|
| Pessoas afetadas | Novos administradores de conta | Todo mundo |
| Tarefa | Convidar colegas e confirmar o acesso | Usar melhor nosso produto |
| Lacuna observada | Não conseguem distinguir convites pendentes dos aceitos | Precisamos de um painel |
| Contexto | Depois de enviar vários convites | Sempre |
| Consequência | Entram em contato com o suporte para confirmar o status | Perda de milhões em produtividade |
| Evidência | Casos revisados em um período especificado | É óbvio |
Uma consequência pode ser qualitativa. Por exemplo, precisar de ajuda para uma tarefa que deveria ser autônoma é algo significativo mesmo antes de se conhecer seu custo financeiro. Não transforme todo inconveniente em perda de receita sem um método defensável.
Exemplo prático: do pedido ao problema
Exemplo hipotético: um projeto começa com o pedido “Crie um painel de convites”. Essa é uma proposta de solução. A equipe poderia construí-la corretamente e ainda resolver o problema errado.
Durante a descoberta, a equipe revisa doze conversas de suporte de um mês definido e observa quatro administradores realizando a tarefa de convite. Vários perguntam se um convite foi entregue ou aceito. Essas observações sugerem um problema que vale investigar, mas não estabelecem sua prevalência entre todos os clientes.
Uma declaração melhor seria:
Depois de convidar vários colegas, os administradores de conta precisam confirmar quem pode acessar o espaço de trabalho, mas a tela de convite não distingue convites pendentes dos aceitos. As conversas de suporte e quatro sessões observadas mostram que os administradores buscam confirmação em outro lugar, acrescentando uma verificação manual ao processo de integração.
A equipe acrescenta duas questões desconhecidas: se a incerteza ocorre fora dos tipos de conta observados e se falhas de entrega também contribuem. As respostas possíveis agora incluem rótulos de status mais claros, uma mensagem de confirmação, uma visualização de atividade ou mudanças no processo de convite. A declaração não escolhe uma delas prematuramente.
Três formatos comuns e quando usá-los
Declaração curta para decisão: use duas ou três frases em um resumo de projeto quando os leitores precisarem entender o problema rapidamente. Inclua um link para as evidências em vez de anexar todo o registro de pesquisa.
Estado atual, estado desejado, lacuna: use esse formato quando um processo tiver uma expectativa definida. Descreva o que acontece hoje, explique a condição necessária e indique a diferença. Verifique se o estado desejado é realmente necessário, e não apenas a preferência de um gerente.
Usuário, tarefa, obstáculo, consequência: use esse formato quando o problema de um produto ou serviço começar pela experiência de alguém. Inclua restrições operacionais para que a declaração não sugira que uma mudança de tela, sozinha, possa corrigir um processo mais amplo.
Essas são estruturas de escrita, não metodologias concorrentes. Escolha a menor que deixe sua decisão clara. Se uma frase ficar difícil de ler, use um parágrafo e uma tabela de apoio.
Conduza uma oficina de enquadramento do problema de 35 minutos
Convide pessoas que vivenciam o problema e pessoas que possam interpretar as evidências. Inclua alguém que possa questionar a solução presumida. Envie o material de origem com antecedência e explique quais afirmações ainda são incertas.
- Cinco minutos: leitura silenciosa. Cada participante marca de formas diferentes as observações, interpretações e soluções propostas.
- Oito minutos: escrever declarações separadas. Peça que todos descrevam a lacuna sem citar produto, ferramenta ou implementação.
- Dez minutos: comparar os limites. Discuta quem é afetado, qual contexto importa e o que fica fora do esforço.
- Sete minutos: escrever uma versão compartilhada. Mantenha as afirmações contestadas em uma nota de incerteza.
- Cinco minutos: escolher o próximo passo de evidência. Nomeie a pessoa responsável e a decisão que as evidências informarão.
O objetivo não é que todos tenham o mesmo nível de confiança. É criar uma declaração que possa ser examinada e mostre onde termina a confiança. Se o grupo não conseguir concordar sobre a população afetada, a próxima tarefa pode ser pesquisar, não realizar uma oficina de soluções.
Verifique se há soluções ocultas e causas sem sustentação
“Os clientes precisam de um assistente de IA” determina uma tecnologia. Pergunte qual tarefa é difícil e qual resultado as pessoas querem alcançar. A tecnologia pode continuar na lista de opções sem se tornar a definição da necessidade.
“Os pedidos atrasam porque a equipe não se importa” afirma uma motivação sem evidências. Substitua isso por uma condição observável, como pedidos que continuam sem responsável depois de uma transferência, e então investigue por que isso acontece.
“ A comunicação é ruim” é amplo demais para orientar uma ação. Identifique qual informação, entre quem, em que ponto de decisão e com qual consequência. A resposta pode revelar vários problemas separados. Divida-os em vez de criar uma declaração pela qual ninguém possa se responsabilizar.
Uma retrospectiva é uma forma de encontrar lacunas recorrentes no trabalho da equipe. Use um formato de quadro simples para reunir observações e leve o problema escolhido para este processo de enquadramento.
Decida se a declaração está pronta
Peça a um colega que não conheça o projeto para lê-la. Ele consegue identificar a pessoa afetada, descrever o que dá errado e sugerir duas respostas diferentes? Se só consegue repetir sua solução preferida, revise a declaração.
Depois, verifique a rastreabilidade: cada afirmação factual deve se conectar a evidências, e cada suposição deve estar identificada. Combine quando a declaração será revisada. Novas evidências podem restringir o problema, revelar outra causa ou mostrar que não vale a pena continuar o trabalho.
Depois de testar uma mudança, examine-a pelo processo de melhoria da retrospectiva. Concluir a implementação não é o mesmo que fechar a lacuna observada.
Perguntas frequentes
Qual deve ser o tamanho de uma declaração do problema?
Em geral, um parágrafo curto basta para a declaração em si. Mantenha evidências, suposições e limites em uma nota de apoio para que a declaração principal não fique difícil de ler por excesso de precisão.
A declaração do problema deve incluir a solução?
Mantenha a solução separada, a menos que o contexto exija explicitamente uma implementação limitada. Mesmo assim, explique o problema de forma independente para que os leitores possam avaliar se a resposta escolhida o aborda.
E se ainda não tivermos evidências quantitativas?
Use observações qualitativas concretas e descreva seus limites. Registre a medição que falta como próximo passo, em vez de inventar frequência, custo ou benefício esperado.