Um processo digital pode concluir alguns passos e ficar bloqueado noutros. Por exemplo, um pedido pode ficar registado enquanto a notificação falha; uma encomenda pode ser aceite, mas o pagamento não ficar confirmado; ou uma conta pode ser criada sem que um serviço ligado seja ativado. Tratar todos estes casos como «sucesso» ou «falha» tende a ocultar informação importante e dificulta a recuperação.
Para decidir como gerir operações parcialmente concluídas num processo digital, é necessário definir que resultados são válidos, que condições têm de ser mantidas e o que fazer com os efeitos que já ocorreram. A resposta nem sempre é anular tudo: consoante a atividade, pode ser mais seguro prosseguir, compensar uma ação específica ou interromper o fluxo para revisão.
Porque é que um processo nem sempre é tudo ou nada
Uma operação que parece única para uma pessoa pode envolver vários passos independentes: validar dados, guardar um registo, cobrar, reservar inventário e notificar outro sistema. Se cada passo for executado num componente ou serviço diferente, não se pode presumir que todos terminem ao mesmo tempo nem que seja possível reverter tudo automaticamente.
Nestes fluxos, o sistema pode conhecer o resultado de uma ação e desconhecer o de outra. Por exemplo, um tempo limite excedido não prova que o sistema externo não recebeu um pedido: pode tê-lo processado, mas a resposta não ter chegado. Repetir a operação sem verificar pode duplicar uma cobrança, uma reserva ou uma encomenda.
Por isso, é conveniente conceber o processo com base nos resultados observáveis e nas regras da atividade. Uma operação parcialmente concluída precisa de um estado explícito e de uma política de recuperação, não de uma etiqueta genérica de erro que apague o que aconteceu.
Classifique o resultado antes de decidir o que fazer
Defina categorias que permitam às equipas de produto, operações e tecnologia interpretar o mesmo caso da mesma forma. Uma classificação útil inclui:
- Sucesso completo: todos os passos necessários e as condições da atividade foram cumpridos.
- Sucesso parcial: há resultados válidos, mas falta concluir uma tarefa necessária. O fluxo tem de prosseguir ou ficar pendente de uma ação definida.
- Falha recuperável: o processo não chegou a um estado final, mas pode ser repetido com segurança ou retomado a partir do último passo confirmado.
- Falha que exige intervenção: o resultado é incerto, uma regra crítica foi violada ou a recuperação automática pode causar danos.
Não basta atribuir nomes aos estados. Para cada um, documente que evidência o confirma, quem o pode alterar e que ação é permitida. Se uma resposta externa não chegou, por exemplo, o estado poderá ser «resultado por confirmar», e não «falhado». Esta distinção evita repetir uma ação que talvez já tenha sido realizada.
Separe os passos confirmáveis das invariantes da atividade
Um passo pode ser confirmado de forma independente quando o respetivo resultado é útil e válido, e não viola uma regra da atividade mesmo que outro passo falhe. Guardar um rascunho antes de enviar uma notificação pode ser aceitável. Em contrapartida, assinalar uma encomenda como entregue antes de confirmar a entrega não seria.
Para tomar uma decisão, comece por identificar as invariantes: condições que têm de ser sempre cumpridas. Podem dizer respeito a limites de crédito, disponibilidade, consentimento, autorização ou correspondência entre um pagamento e uma encomenda. Em seguida, pergunte que estado intermédio é legítimo e que efeitos tem para as pessoas, as equipas e os sistemas ligados.
- O passo já executado pode ser mantido sem induzir em erro nem violar uma regra?
- A tarefa pendente é necessária para considerar o processo concluído?
- É possível repetir o passo sem duplicar efeitos?
- Existe uma compensação fiável e autorizada caso o processo não prossiga?
- Que evidência permite determinar se o sistema externo atuou?
Se não conseguir responder a estas perguntas, não apresente o fluxo como concluído. Defina primeiro o resultado aceitável e quem tem autoridade para resolver exceções.
Escolha entre prosseguir, compensar ou interromper
Prossiga quando for possível repetir os passos restantes com segurança e o estado atual não puser em risco uma regra essencial. Esta opção é adequada para tarefas pendentes que não invalidam o que já foi confirmado, desde que exista acompanhamento e um limite de tentativas ou uma via de escalonamento.
Compense quando manter um efeito anterior deixar o processo num estado inaceitável e existir uma ação inversa viável. Uma compensação nem sempre equivale a apagar o que aconteceu: pode consistir em cancelar uma reserva, emitir um reembolso ou assinalar um pedido como anulado. Confirme que sistemas permitem essa ação, quais são os seus limites e como registar o resultado. Se a compensação também falhar, o caso exige uma nova decisão, não uma falsa confirmação de reversão.
Interrompa para revisão quando o estado for ambíguo, a operação tiver um impacto financeiro ou regulamentar significativo, ou uma ação automática puder agravar o problema. A pausa deve criar uma tarefa atribuída, com contexto suficiente e critérios para a resolver. Deixar um caso parado sem responsável nem prazo operacional apenas transforma uma falha técnica numa dívida invisível.
Conceba estados e recuperação para retomar com segurança
Use estados que descrevam o que aconteceu, e não apenas o que aparece no ecrã. Consoante o fluxo, podem incluir «recebido», «em validação», «confirmado», «pendente de terceiro», «requer revisão», «em compensação» e «cancelado». Evite usar «concluído» se ainda faltar uma ação necessária para cumprir o que foi prometido à pessoa.
Registe cada transição com o identificador da operação, o passo, a hora, o resultado e a referência disponível do sistema envolvido. Mantenha separadas as decisões automáticas e as manuais: saber quem autorizou uma exceção e porquê pode ser tão importante como conhecer o resultado técnico. Não guarde dados sensíveis desnecessários nos registos.
Para retomar o processo, identifique o último passo confirmado e repita apenas as ações pendentes. Use uma chave de idempotência ou um mecanismo equivalente quando o sistema que recebe o pedido o permitir; o objetivo é impedir que uma repetição produza efeitos duplicados. Se essa proteção não existir, consulte o estado remoto antes de reenviar e defina o que fazer se não for possível verificá-lo.
Estabeleça também como detetar casos bloqueados: por exemplo, estados que ultrapassem o tempo operacional esperado, tarefas de compensação sem resultado ou divergências entre registos de sistemas. Um alerta útil conduz a uma ação e a um responsável; muitos alertas sem contexto acabam por ser ignorados.
Comunique o resultado sem ocultar o que está pendente
A mensagem deve explicar o que aconteceu, o que não foi concluído e o que se seguirá. Evite declarar sucesso total quando falta uma ação essencial, mas também não apresente um erro genérico que leve a pensar que nada ficou guardado. Se o passo seguinte depender da equipa de suporte ou de uma revisão, diga-o com clareza e indique uma forma adequada de acompanhar o caso.
As ferramentas internas também precisam de uma vista que permita agir: estado atual, passos confirmados, tarefa pendente, evidência disponível e responsável. Assim, as equipas de suporte e operações não têm de reconstruir o caso a partir de mensagens dispersas nem de pedir à pessoa que repita uma operação que já pode ter produzido efeitos.
Lista de verificação antes de disponibilizar o fluxo
- Enumere os passos e os sistemas envolvidos, incluindo os que dependem de terceiros.
- Defina os estados válidos, as invariantes e a evidência que confirma cada transição.
- Decida que passos podem ser repetidos, quais exigem uma consulta prévia e quais não devem ser repetidos automaticamente.
- Documente as compensações, os seus limites e a via de intervenção caso também falhem.
- Teste tempos limite, respostas duplicadas, interrupções e resultados incertos, e não apenas o percurso ideal.
- Atribua responsáveis e mecanismos de acompanhamento para os casos pendentes ou bloqueados.
- Verifique se as mensagens dirigidas às pessoas e às equipas descrevem o estado real e o passo seguinte.
O objetivo não é eliminar todas as falhas, mas evitar que uma falha parcial se transforme num resultado enganador ou difícil de reparar. Quando cada estado tem um significado, cada efeito tem uma política e cada tarefa pendente tem um responsável, o processo pode ser recuperado sem confundir progresso com conclusão.