Da conversa da equipe para critério de sistema: documentar regras antes de automatizar

O critério existe na cabeça de alguém

Pegue uma regra que hoje vive na conversa da equipe, em mensagens e na memória de quem coordena, e transforme-a em critério escrito que um sistema possa aplicar. Ao final, você terá a regra em rotas explícitas "se, então, senão", com fonte observável, exceções escritas e um caminho definido para os casos em que o critério não decide sozinho.

Esse passo é o pré-requisito que os fluxos de conferência e aprovação costumam assumir pronto. Toda conferência que compara componente contra tabela contratada pressupõe que a tabela existe em versão legível. Toda fila de exceções pressupõe que o critério de triagem está escrito. Quando não está, a automação recebe uma regra que só existe de cabeça e reproduz a adivinhação da equipe em escala maior.

O exemplo que percorre o post é hipotético. Considere uma operação de recebimento em que a janela de permanência do veículo na doca é de duas horas, número tomado como premissa do cenário. A regra funciona na prática: o coordenador olha o horário de chegada, o horário de início da descarga e a fila do dia, e decide se a cobrança de permanência do transportador se justifica. Ninguém escreveu isso. Quando o coordenador sai de férias, a decisão depende de quem lembra o quê, e quando um fluxo automatizado tenta aplicar a regra, ela simplesmente não existe para ele.

Escolha a regra que mais trava o trabalho

Comece pelo bloqueio, não pela regra mais fácil de escrever. A fonte natural é a fila de exceções que já existe: as divergências que voltam para revisão humana na conferência de documentos, as cobranças discutidas com fornecedores, as aprovações que dependem de uma pessoa específica.

Condição de aprovação deste passo: a regra escolhida tem registros de bloqueios recentes, na fila, no e-mail ou no grupo da equipe. Condição de reprovação: ninguém sabe dizer quantas vezes ela trava o processo no mês.

Há um trade-off consciente aqui: cobrir todas as regras da operação antes de automatizar qualquer coisa é um caminho que costuma não terminar. Escolhemos o lado oposto. Escreva primeiro as poucas regras que mais travam, ligue o fluxo só sobre elas e deixe o resto na conversa por enquanto.

Escreva cada rota no formato se, então, senão

Uma regra conversada não vira critério em parágrafo corrido. Ela vira quando separa as situações que o sistema encontrará e diz, para cada uma, o que acontece. No exemplo hipotético, três rotas:

Se o intervalo entre a chegada registrada e o início da descarga não passa de duas horas, não há excesso a avaliar e o fluxo segue. Se o excesso existe e mais da metade das docas estava ocupada no momento da chegada, o atraso tem causa externa plausível. Aí o critério consulta o contrato antes de decidir: quando o contrato prevê a cobrança nessas condições, ela é encaminhada para aprovação antes da criação da obrigação financeira ou da liberação do pagamento, conforme o momento em que o ERP do cliente cria uma ou outra; quando o contrato não prevê, a cobrança vai para revisão. Se faltam dados ou o contrato não está disponível, a cobrança também vai para revisão. Se o excesso existe e metade ou menos das docas estava ocupada, o atraso pode ter vindo do próprio transportador, e o critério não aprova nem rejeita por conta própria: a cobrança entra na fila de revisão com o motivo e as evidências, e quem decide confere o contrato antes de concluir.

Repare que a regra conversada cobria só o número. O "duas horas" estava na cabeça de todos; o que distinguia as situações, no julgamento do coordenador, era a ocupação das docas, definida aqui como premissa do cenário. Escrever a regra é descobrir essas condições.

O passo está pronto quando cada rota tem um destino escrito e uma pessoa que nunca participou da conversa consegue aplicá-la. Ele não termina enquanto o texto depender de julgamento sem condição definida, como "espera excessiva" sem número, ou "quando fizer sentido".

Amarre cada condição à evidência observável

Um critério que ninguém consegue verificar depois não é critério, é opinião formalizada. Cada condição aponta para uma fonte que existe independente de quem aplica: o horário no registro de chegada, a ocupação registrada no sistema, a versão datada do contrato, o campo do documento. É o mesmo princípio da conciliação de fretes: a conferência sobrevive quando compara contra evidência neutra, não contra memória.

Aqui aparecem os limites reais do projeto. A regra do exemplo só vira critério aplicável se o horário de chegada e a ocupação das docas estiverem registrados em algum sistema. Se não estiverem, o trabalho muda: primeiro o registro passa a existir, depois a regra se aplica. Pular essa etapa leva o fluxo a decidir sem fonte, e o resultado fica mais difícil de defender do que a decisão manual que ele substituiu.

Escreva as exceções junto, não depois

Toda regra tem os casos que ela não cobre, e eles são mais fáceis de listar enquanto a regra está fresca na conversa do que meses depois, quando alguém se depara com um caso sem resposta. No exemplo: descarga interrompida por avaria, chegada fora do horário agendado, atraso decorrente do próprio transportador.

Cada exceção precisa de um destino, e é aqui que o desenho se conecta ao que descrevemos em revisão humana e limites de automação: para cada exceção, quem decide e com qual informação em mãos. A exceção sem destino definido é a que costuma virar o bloqueio real do fluxo depois de implantado.

Valide contra o histórico antes de ligar

Antes de qualquer automação, aplique o critério escrito contra as últimas decisões que a equipe tomou de cabeça. Pegue os casos de permanência dos últimos meses, aplique a regra do exemplo e compare com o que o coordenador decidiu na época. Quando o critério reproduz as decisões, bom sinal, mas não suficiente: decisões passadas podem estar em desacordo com o contrato ou com a prática atual, então cada uma é conferida antes de virar referência. Quando ele discorda de parte delas, ou a equipe mudava o critério conforme o caso, o texto precisa de ajuste, e é melhor descobrir antes de o sistema decidir.

Esse passo é também uma conversa honesta com a equipe: ela vê o próprio julgamento sendo escrito e corrige o texto enquanto a correção custa pouco. Feito isso, a regra está pronta para os critérios de validação de um piloto, se o fluxo for passar por um.

flowchart TD
  A[Regra vivendo na conversa da equipe] --> B[Escolher a regra que mais trava]
  B --> C[Escrever as rotas: se, então, senão]
  C --> D{Cada condição tem evidência observável?}
  D -- não --> E[Registrar a fonte: horário, campo, versão datada]
  E --> C
  D -- sim --> F[Escrever exceções com destino definido]
  F --> G[Aplicar o critério contra o histórico recente]
  G --> H{Critério reproduz as decisões tomadas?}
  H -- não --> C
  H -- sim --> J{Decisões conferidas contra o contrato e a prática atual?}
  J -- não --> C
  J -- sim --> I[Pronto para entrar no fluxo]

Em resumo

Checklist para cada regra antes de virar critério de sistema:

• A regra foi escolhida pela frequência com que trava o trabalho, não pela facilidade de escrever.
• Ela separa as situações do dia a dia e roteia cada uma para um destino escrito: fluxo segue, aprovação ou revisão.
• Cada condição aponta para uma evidência observável, com fonte e data.
• As exceções estão escritas, e cada uma tem um responsável decidindo.
• Os casos incertos vão para revisão, e nenhuma cobrança vira obrigação financeira sem a aprovação prevista.
• O critério reproduziu as decisões recentes, e cada decisão reproduzida foi conferida contra o contrato e a prática atual.

Uma regra que passa nessa lista deixa de depender da memória de uma pessoa. A que não passa ainda está na conversa, e automação sobre conversa reproduz adivinhação em escala maior.

Quer avaliar quais regras da sua operação estão prontas para virar critérios? Solicitar diagnóstico.