Ideia principal

Um vencimento de faturamento futuro aparece no calendário de cobranças de um cliente. Ele não existe, porém, como documento: só terá existência própria no momento em que a fatura for emitida. Consequência imediata — ele está ausente dos resultados de busca. O usuário, por sua vez, viu o vencimento na tela; ele o procura, não encontra, e abre um ticket.

Não é um defeito pontual, é uma família inteira de reclamações, tratada caso a caso há anos por um suporte que não dispõe de nenhuma formulação da causa. Cada ticket é fechado com uma explicação improvisada, e o seguinte recomeça.

A origem é uma divergência entre dois modelos: o que a interface dá a ver e o que o produto manipula como objetos. Uma coisa vista pelo usuário é um objeto para ele, qualquer que seja sua existência técnica.

Por que isso importa

Isso fornece um ângulo de busca por direito próprio: percorrer o que o usuário manipula todos os dias e verificar que cada elemento existe em algum lugar como objeto do produto. As telas trazem assim o que nem o código nem o banco sinalizam.

Isso também muda o tratamento dos tickets repetitivos: uma família de reclamações sem causa escrita é um sinal de modelo faltante, não um volume a absorver.

Nuances e limites

Nem tudo o que aparece precisa virar um objeto: um total, um agrupamento de exibição, uma linha de síntese podem continuar sendo visões sem que ninguém sofra com isso. O critério não é a presença na tela, é que o usuário precise reencontrar a coisa, falar dela ou agir sobre ela.

E a correção não é necessariamente criar o objeto: nomear a ambiguidade e explicá-la na interface pode bastar.

Questões em aberto

• Como identificar esses casos de outro jeito que não lendo as telas uma a uma, em um produto que tem várias centenas delas?