Ideia principal

"Qualificar um incidente", "recuperar contexto antes de agir", "comparar várias entidades", "coordenar várias pessoas": formulada assim, uma necessidade do cliente nomeia uma ação de trabalho e nada mais. Ela não diz por qual tela, qual feature nem qual mecânica o produto deve respondê-la.

É justamente isso que a mantém utilizável por muito tempo. Uma necessidade registrada como "adicionar um botão de comparação" já decidiu a solução no momento da coleta, e o rastro do que o cliente queria fazer desapareceu — não dá mais para reabri-lo e imaginar outra coisa. Formulado no nível da ação, o mesmo retorno continua aberto a várias respostas de produto, e continua comparável a outros retornos que miravam a mesma ação por pedidos diferentes.

Esse nível também é o que melhor resiste ao tempo: as telas mudam, as features são substituídas, mas qualificar um incidente continua sendo o que um técnico faz.

Por que isso importa

Isso protege a fase de discovery de uma decisão tomada cedo demais e pela pessoa errada. Um cliente que pede um botão propõe uma solução; registrá-la tal e qual faz a proposta dele entrar no repositório como se fosse a necessidade.

Também cria um ponto de agrupamento. Três pedidos de features sem relação aparente, remetidos ao mesmo job, revelam uma mesma ação mal servida por ferramentas — agrupamento invisível enquanto cada pedido continua guardado sob a sua solução.

Nuances e limites

Subir até o job não deve virar uma subida sistemática rumo à abstração: um incômodo preciso reformulado como ação de negócio genérica perde o detalhe que permitia corrigi-lo. O nível da ação é um nível a mais, não um nível que absorve os outros.

E a formulação em job não garante nada sobre frequência nem sobre valor: ela diz o que o cliente busca fazer, não quantos clientes buscam isso.

Questões em aberto

• Como verificar que um job formulado pelo time de produto corresponde ao que o cliente realmente faz, e não ao que entendemos do relato dele?