A definição do problema é o projeto todo: como escrevê-la

Uma boa definição do problema diz quem é afetado, o que acontece com essas pessoas, quando e onde acontece e por que isso importa, em duas ou três frases simples e sem nenhuma solução escondida no meio. Escreva a partir de evidências, não de opiniões, deixe claro o que está fora do escopo e teste o texto com pessoas de fora da equipe antes de gerar uma única ideia. Acerte esse ponto e cada etapa seguinte, das ideias aos protótipos e ao business case, terá chão firme para se apoiar.

Por que a definição decide o projeto

Equipes raramente fracassam por falta de ideias. Elas fracassam porque resolveram um problema que ninguém tinha, resolveram a parte errada de um problema real ou passaram semanas discutindo porque cada pessoa, sem dizer, estava resolvendo um problema diferente. É na definição do problema que essas falhas começam ou são evitadas.

Três motivos explicam por que ela pesa tanto. Ela define o limite do que conta como uma boa ideia. Ela diz com quem conversar e o que medir. E é a frase que a liderança vai lembrar, então influencia se o trabalho recebe apoio ou não. Uma definição vaga não continua vaga: ela acaba preenchida por quem tem mais autoridade na sala.

As cinco partes de uma definição do problema que funciona

Uma definição com a qual dá para trabalhar responde a cinco perguntas:

1. Quem é afetado? Um grupo específico, não "usuários" ou "stakeholders". "Pessoas que fazem o primeiro pedido com documentação incompleta" é um quem. "Clientes" não é.
2. O que acontece com essas pessoas? A situação observável, nos termos delas. Algo que você conseguiria ver ou contar.
3. Quando e onde acontece? O momento ou o canal. Muitas vezes é aqui que o verdadeiro insight está escondido.
4. Por que importa, para elas e para a organização. O custo de deixar como está: tempo, dinheiro, confiança, risco.
5. O que sabemos, e como. Uma linha sobre a evidência: entrevistas, dados de reclamações, observação. Isso mantém a definição honesta.

Muitas equipes acrescentam uma sexta linha igualmente útil: o que não é o problema. A análise "é / não é" de Kepner-Tregoe é uma forma clássica de fazer isso. Afirmar, por exemplo, que a questão acontece nos pedidos online, mas não nas agências, já estreita a busca na hora.

Como escrever, passo a passo

1. Escreva o primeiro rascunho mal e rápido. Cada pessoa escreve sua própria versão do problema em uma frase, em silêncio, em três minutos. Coloque as versões lado a lado. As diferenças entre elas são a sua primeira descoberta: mostram onde a equipe ainda não concorda.
2. Tire as soluções. Sublinhe qualquer palavra que descreva uma correção: "aplicativo", "portal", "treinamento", "falta de um sistema". "Não temos um sistema de agendamento" é uma solução disfarçada. Reescreva cada uma como a situação que as pessoas enfrentam: "Os clientes não conseguem saber com antecedência se há um horário livre."
3. Pergunte por quê e depois pergunte o que impede. Use os cinco porquês ou uma árvore de problemas para ir do sintoma à causa. Pare quando chegar a um nível sobre o qual a equipe realmente consegue agir. Vá fundo demais e você termina em "a economia"; fique na superfície e você só trata sintomas. Para um tratamento completo, veja como encontrar a causa raiz de um problema.
4. Vá conferir. Leve o rascunho a cinco ou seis pessoas que vivem o problema. Use entrevistas com stakeholders e peça que descrevam a última vez que aconteceu, não o que pensam em geral. Se o relato delas não bater com a sua definição, mude a definição.
5. Preencha as cinco partes. Reescreva usando quem, o quê, quando e onde, por que importa e o que vocês sabem. Limite a três frases. Se precisar de mais, provavelmente você tem dois problemas.
6. Escreva os limites. Acrescente uma linha sobre o que está fora do escopo e outra sobre as restrições que vocês precisam respeitar, como regulação, ciclo orçamentário ou um sistema que não pode ser alterado este ano.
7. Transforme em um ponto de vista. Uma declaração de ponto de vista, o formato usuário–necessidade–insight ensinado pela d.school de Stanford, condensa o problema em uma frase humana: "[Quem] precisa de [necessidade] porque [insight]."
8. Abra em perguntas. Só agora escreva as perguntas como poderíamos a partir da definição. Para exemplos de perguntas boas e ruins, veja 10 perguntas "como poderíamos": cinco boas e cinco ruins.
9. Teste com alguém de fora. Leia a definição para alguém de outro departamento. Peça que essa pessoa diga com as próprias palavras qual é o problema e quem o tem. Se ela não conseguir, a definição ainda não está pronta.

Antes e depois

O que fazer e o que evitar

Faça

• Escreva a definição na linguagem das pessoas afetadas, não no jargão interno.
• Baseie-se em algo que você observou ou ouviu, e diga o quê.
• Mantenha curta o bastante para ser dita em voz alta em vinte segundos.
• Revise abertamente quando surgirem novas evidências e guarde as versões antigas, para que a equipe veja como o entendimento mudou.
• Use o mapa de premissas para listar o que vocês ainda acreditam, mas não verificaram.

Evite

• Não deixe a definição conter uma solução, uma tecnologia ou o nome de um departamento como causa.
• Não escreva a definição numa reunião sem evidências e a declare final.
• Não a deixe tão ampla que qualquer ideia caiba, nem tão estreita que só uma ideia caiba.
• Não use "falta de" como verbo principal. Quase sempre esconde uma solução.
• Não pule a linha do "por que importa". Sem ela, o trabalho perde apoio na primeira revisão de orçamento.

Exemplo ilustrativo

Ilustrativo. Uma prefeitura na Austrália pediu à sua equipe de serviços que "construísse um portal online para alvarás de obra". O primeiro rascunho da equipe repetia o pedido. Em vez de começar a construção, dois integrantes passaram uma semana no balcão de alvarás e conversaram com oito requerentes e quatro analistas.

O que ouviram foi diferente. A maioria dos pedidos já era enviada online. O atraso vinha depois do envio: muitos dos pedidos que eles examinaram tinham sido devolvidos por falta de informação, e os requerentes não entendiam as cartas de exigência. Os analistas passavam boa parte do dia ao telefone explicando essas cartas.

A definição reescrita ficou assim: "Proprietários que pedem alvarás para pequenas obras costumam enviar pedidos incompletos porque as exigências estão espalhadas em vários documentos e as cartas de exigência usam linguagem técnica. Cada devolução acrescenta semanas ao processo e ocupa o tempo dos analistas com ligações de explicação. Isso vale para pequenas obras residenciais, não para empreendimentos comerciais."

As ideias que vieram depois foram mais baratas e mais rápidas do que um portal: um checklist de uma página por tipo de obra, cartas de exigência em linguagem simples e uma ligação curta antes do envio. A ideia do portal não foi descartada; ela simplesmente deixou de ser o ponto de partida.

Perguntas frequentes

Qual é um bom exemplo de definição do problema? Uma boa definição nomeia um grupo específico, descreve o que acontece com ele e quando, diz por que isso importa e não contém nenhuma solução. Por exemplo: "Enfermeiras do turno da noite perdem informações da passagem de plantão porque as anotações ficam em três lugares diferentes, o que leva a verificações repetidas no início de cada turno."

Qual deve ser o tamanho de uma definição do problema? Duas ou três frases, mais uma linha sobre o escopo. Se você precisa de uma página inteira, ou está descrevendo vários problemas, ou está incluindo a sua solução. Definições curtas são mais fáceis de testar, lembrar e compartilhar com a liderança.

Qual é a diferença entre a definição do problema e uma pergunta "como poderíamos"? A definição do problema descreve a situação como ela é, com base em evidências. Uma pergunta "como poderíamos" a transforma num convite aberto a ideias. Escreva primeiro a definição e depois derive dela várias perguntas, cada uma olhando por um ângulo diferente.

Para onde ir agora

Use os guias de árvore de problemas e cinco porquês para encontrar a causa, depois condense o resultado com uma declaração de ponto de vista e abra-o com como poderíamos. Para ver onde essa etapa se encaixa no processo mais amplo, leia design thinking, passo a passo e o guia central qual ferramenta de inovação devo usar.