De uma ideia a um problema que dá para resolver
A maioria das ideias chega formulada como solução: “quero um sistema que responda aos clientes”. É uma formulação natural e também a principal razão de projetos travarem no terceiro mês. Uma solução sem problema definido é um alvo móvel: cada pessoa na mesa imagina uma coisa diferente e não há como encerrar uma discussão.
Três perguntas que precisam de resposta por escrito
Quem, e em que momento do dia. Não “os clientes”, mas a atendente que abre um chamado e passa oito minutos procurando em documentos. Quanto mais específica a descrição, mais claro fica o que o sistema precisa fazer — e, mais importante, o que não precisa.
Qual é a solução atual. Todo problema já tem uma solução, mesmo que ruim: uma planilha, uma pergunta no grupo, o veterano que todo mundo consulta. Essa é a sua base de comparação real.
Como o sucesso aparece em número. Tempo de atendimento, percentual de casos fechados sem gente, minutos economizados por semana. Se não dá para formular uma métrica, a ideia ainda é uma intuição — tudo bem, mas então o próximo passo é investigar, não desenvolver.
Um documento de uma página
Antes da primeira linha de código: a pessoa e o momento, a solução atual e sua fraqueza, a métrica de sucesso, três exemplos reais de entrada e saída desejada, e uma lista do que não entra na primeira versão.
Os três exemplos são a parte importante: transformam uma discussão abstrata em conversa sobre um caso concreto. Se for difícil escrevê-los, essa é a descoberta: ainda não há acordo sobre o que o sistema deve devolver.
Indo mais fundo
Os exemplos reunidos na definição são a semente do seu conjunto de avaliação. Junte de 20 a 50 casos reais do campo — incluindo casos limite e casos sem boa resposta — antes de começar a desenvolver. É o investimento que se paga mais rápido.