PROCESS

Aqui é Como Construir

Design

Exceções

A decisão depositada

O mundo já tem uma coisa a que chama uma exceção pré-aprovada, e não é bem isto. Ali, uma exceção pré-aprovada é um só desvio autorizado de antemão mas ainda tratado como uma exceção: temporário, o seu risco formalmente aceite, pronto a expirar e ser revisto de novo. Continua a ser uma exceção o tempo todo; só foi autorizado cedo, e a autorização expira, por isso o caso volta a rondar. Isso é um instrumento de governação, e o seu lar é o domínio de Governação, onde quem pode aceitar um desvio, e por quanto tempo, e a que risco, é a pergunta apropriada. Não é o que este livro quer dizer.

Aqui, pré-aprovado significa uma resposta permanente. O designer previu o caso, decidiu como devia ser gerido, escreveu essa gestão num guia, e fê-lo assinar uma vez. Desde então, o guia mantém-se. Qualquer Executor que encontra o caso procura-o, segue-o, e avança, dentro de plena sanção, porque a decisão já foi tomada e a aprovação já está depositada. A aprovação não é concedida e a expirar; é feita uma vez e mantém-se. O Executor não dobra uma regra nem gasta uma dotação de risco; segue uma resposta assente que o design pôs no lugar antes de ele chegar. O que era, para o mundo, um desvio a reautorizar a cada ciclo é, aqui, uma resposta escrita que o Executor simplesmente usa.

E há uma diferença em onde recai o fardo, que importa mais do que parece à primeira. Na versão do mundo, a expiração recai sobre quem faz: a concessão expira, e o caso deve ser trazido de novo para aprovação, um ponto de contacto devolvido a quem o encontra. Aqui é o contrário. Para o Executor, o guia pré-aprovado nunca expira. Mantém-se, e ele segue-o indefinidamente, sem voltar a perguntar. A única expiração é a do designer, e é uma responsabilidade, não um lapso: o designer carrega o dever permanente de arranjar a exceção quando possível, dobrando-a nas regras para que o caso deixe de ser uma exceção de todo. O Executor não sente nada disso. Segue um guia estável até que, um dia, sem fricção, o caso seja simplesmente a maneira normal e o guia, em silêncio, já não seja preciso. A provisoriedade é do designer para carregar; ao Executor dá-se apenas estabilidade.

O padrão mais elevado possível é entender por pré-aprovado não uma concessão temporária, de risco aceite e a expirar, que mantém um caso como exceção e faz recair o seu lapso sobre quem faz, mas uma resposta permanente, desenhada, escrita num guia e assinada uma vez, que o Executor segue dentro de plena sanção e nunca tem de voltar a procurar, enquanto o designer sozinho carrega o dever de a resolver para cima com o tempo.

Conclusão chave: A exceção pré-aprovada do mundo é um só desvio autorizado de antemão mas ainda uma exceção, temporário, de risco aceite, a expirar, revisto de novo, um instrumento de governação que pertence ao domínio de Governação. Aqui, pré-aprovado significa uma resposta permanente: desenhada, escrita num guia, assinada uma vez, e seguida por cada Executor dentro de plena sanção, a aprovação depositada, não concedida e a expirar. E o fardo recai diferente: a expiração do mundo recai sobre quem faz, que deve procurar aprovação de novo; aqui o guia nunca expira para o Executor, e a única expiração é o próprio dever do designer de a dobrar nas regras a tempo.

Pré-aprovado é uma resposta permanente, escrita e assinada uma vez, que o Executor segue dentro de plena sanção e nunca tem de voltar a procurar.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 5: Pré-Aprovado · Secção: A decisão depositada

MarvinPro | Junho 2026

marvinpro.com

O que pode ser pré-aprovado

Nem toda a exceção pode ser pré-aprovada, e saber qual pode é o juízo de que esta disciplina depende. Um caso pode ser pré-aprovado quando a sua resposta é conhecível de antemão e segura de escrever: a condição que marca o caso pode definir-se com clareza, a resposta é fixa e correta cada vez que ocorre, e nenhum juízo no momento é necessário para a aplicar. O cliente que optou por não ser contactado é um tal caso. A condição é clara, o cliente pediu para não ser contactado, e a resposta é fixa, suprime a mensagem e avança. Não há nada a pesar no momento, por isso a resposta pode escrever-se uma vez e ser seguida por qualquer um. Um caso cuja resposta é assim tão estável pertence ao pré-aprovado.

Um caso não pode ser pré-aprovado quando a sua resposta ainda não é conhecível, ou quando aplicá-la precisa mesmo de uma decisão tomada no momento. A incidência desconhecida não pode ser pré-aprovada, porque ninguém ainda a compreende o suficiente para escrever a sua resposta; não podes escrever um guia para um caso que não compreendeste. Um caso que gira sobre um juízo, quanto conceder, se as circunstâncias de verdade encaixam, qual é a exceção certa entre várias, também não pode reduzir-se com segurança a um passo escrito, porque a escrita teria de fingir uma certeza que o caso não tem. Para estes, o caminho a seguir é o escalonamento, tratado a seguir, não um guia.

E aqui está a guarda que mantém isto honesto: não pré-aprovas um caso que precisa de uma decisão no momento. Um guia escrito para um caso que de verdade exige juízo é um guia falso, e um guia falso é pior do que nenhum. Diz ao Executor para avançar por uma resposta fixa onde nenhuma resposta fixa é certa, e assim produz uma gestão confiante, uniforme, errada, mais difícil de apanhar do que um vazio óbvio, porque parece o design a funcionar. A precisão do designer aqui é pré-aprovar exatamente o que é seguro pré-aprovar, e encaminhar o resto ao escalonamento sem fingir que pode escrever-se. A cobertura que é falsa não é cobertura; é uma falha oculta com a forma de uma resposta. Melhor um escalonamento honesto do que uma mentira escrita.

O padrão mais elevado possível é pré-aprovar exatamente aqueles casos cuja resposta é conhecível de antemão e segura de fixar por escrito, com uma condição clara e uma resposta fixa correta, e encaminhar cada caso que precisa de juízo no momento ao escalonamento em vez disso, nunca escrevendo um guia que finge uma certeza que o caso não tem.

Conclusão chave: Um caso pode ser pré-aprovado quando a sua resposta é conhecível de antemão e segura de escrever: condição clara, resposta fixa correta, sem juízo no momento, como o cliente que optou por não ser contactado. Não pode ser pré-aprovado quando a sua resposta ainda não se conhece, como a incidência desconhecida, ou quando aplicá-la de verdade precisa de uma decisão no momento. A guarda: nunca pré-aprovas um caso que precisa de juízo no momento, um guia falso é pior do que nenhum, porque produz uma gestão confiante, uniforme, errada que parece o design a funcionar. Pré-aprova o que é seguro; encaminha o resto ao escalonamento com honestidade.

Pré-aprova só o que é conhecível e seguro de escrever; um guia que finge uma certeza que o caso não tem é pior do que nenhum guia.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 5: Pré-Aprovado · Secção: O que pode ser pré-aprovado

MarvinPro | Junho 2026

marvinpro.com

Os mínimos pontos de contacto

Pergunta por que o designer alcança o pré-aprovado primeiro e com mais força, e a resposta é o Executor. Cada caminho a seguir custa algo ao Executor: uma pergunta, uma espera, um escalonamento, uma passagem, uma decisão procurada noutro. Estes são pontos de contacto, e cada um é um lugar onde o trabalho para. Todo este design existe para que o Executor trabalhe tão depressa quanto possível, com tão poucas ações e tão poucos pontos de contacto quanto o caso permita. O pré-aprovado é onde esse custo cai a quase nada. O Executor encontra o caso, segue o guia permanente, e avança, no fluxo do trabalho, sem parar por ninguém. Uma exceção pré-aprovada é uma que o Executor mal sente, porque o design já fez o perguntar, o decidir, e o aprovar, de antemão, para que ele não tenha de o fazer.

É por isto que pré-aprovar é a gestão de maior alavancagem que há. Cada pré-aprovação pega num caso que teria custado um ponto de contacto, um escalonamento a um Líder, uma espera por uma decisão, e retira esse custo para cada Executor que alguma vez encontre o caso. O designer faz o pensamento uma vez; a poupança repete-se para sempre. Por isso o designer alcança o pré-aprovado antes dos níveis mais altos, não por arrumação mas porque é onde mais fricção se retira de mais gente. E pré-aprovar emparelha-se com pôr de lado como as duas maneiras em que um design entra em funcionamento sem esperar pela perfeição: põe de lado o que pode esperar com segurança, e pré-aprova o que tem uma resposta conhecível, para que o trabalho possa lançar-se agora, o Executor coberto desde o primeiro dia, em vez de retido até que cada caso seja uma regra. Um guia pré-aprovado é muitas vezes exatamente isto, a resposta escrita para que o design possa entrar em funcionamento, às vezes a resposta assente para o caso, e às vezes uma solução provisória que o designer tenciona substituir assim que o remédio apropriado esteja pronto. Para o Executor as duas são o mesmo, um guia estável a seguir; a diferença vive só na intenção do designer.

E os pontos de contacto caem ainda mais, abaixo do pré-aprovado, quando o caso é dobrado nas regras. Um guia pré-aprovado custa ao Executor uma pequena ação, procura-o, segue-o. Uma regra não custa nem isso, porque o caso já não é uma exceção; é simplesmente o trabalho normal, gerido pela regra que agora o encaixa. Por isso o descenso que a disciplina anterior descreveu, escalonamento a guia a regra, é, visto do lado do Executor, um retirar constante de pontos de contacto: de perguntar a alguém, a ler um guia, a nada de todo. O designer empurra cada caso tão abaixo por esse caminho quanto vá, porque o fim, sob tudo isso, é um Executor que encontra cada vez menos casos que lhe custem algo, e se move pelo trabalho como se as exceções nunca tivessem estado ali. Os guias que isto produz são o assunto do volume que trata os guias por inteiro; aqui, o ponto é só que cada um existe para poupar ao Executor um ponto de contacto.

O padrão mais elevado possível é pré-aprovar onde quer que a resposta de um caso possa escrever-se com segurança, porque retira um ponto de contacto para cada Executor que alguma vez encontre o caso, e empurrar cada caso ainda mais abaixo, para a regra que não custa ponto de contacto algum, para que o Executor trabalhe tão depressa quanto possível com tão pouco a fazer quanto o design possa dispor.

Conclusão chave: O designer alcança o pré-aprovado primeiro por causa do Executor: cada caminho a seguir custa um ponto de contacto, uma pergunta, uma espera, um escalonamento, e o pré-aprovado não custa quase nenhum, o Executor segue o guia permanente no fluxo do trabalho, sem parar por ninguém. É a gestão de maior alavancagem: o designer pensa uma vez, e a poupança repete-se para cada Executor para sempre. Emparelha-se com pôr de lado para que um design entre em funcionamento sem esperar pela perfeição, e um guia pré-aprovado pode ser uma resposta assente ou uma solução provisória, o mesmo para o Executor. Abaixo, dobrar numa regra retira o ponto de contacto por completo.

Pré-aprova para poupar ao Executor um ponto de contacto, e dobra numa regra para lhe poupar até esse, para que se mova como se a exceção nunca tivesse estado ali.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 5: Pré-Aprovado · Secção: Os mínimos pontos de contacto

MarvinPro | Junho 2026

marvinpro.com

Um exemplo real

Volta à empresa de software e ao cliente que optou por não ser contactado, o caso pré-aprovado mais claro do design. A sua resposta era conhecível de antemão e segura de escrever: quando um cliente pediu para não ser contactado, suprime a mensagem e avança. Não havia nada a julgar no momento, por isso a gestão foi escrita num guia, assinada uma vez por quem tinha a autoridade sobre ela, e posta permanente. Desde esse dia, qualquer Executor que encontrou um cliente que optou por não o ser procurou o guia, seguiu-o, e prosseguiu, ninguém perguntado, ninguém interrompido, o caso gerido no fluxo do trabalho. Para o Executor custou uma só pequena ação e nenhuma espera. A aprovação tinha sido depositada; o ponto de contacto quase desaparecera.

Repara no que o design não fez. Não escreveu um guia para a incidência desconhecida, porque a incidência desconhecida ainda não tinha resposta conhecível, e um guia fingindo uma teria dito ao Executor para avançar com confiança para um caso que ninguém compreendia. Esse caso foi deixado ao escalonamento, com honestidade, até a sua resposta ser encontrada. E repara também que nem todo o guia pré-aprovado no design era uma resposta final. Quando uma solução provisória foi encontrada para um caso posto de lado, uma maneira em que o Back Office podia manter à mão a preferência de canal de um cliente até a gestão apropriada ser construída, essa solução provisória foi escrita e pré-aprovada também, para que o Executor pudesse segui-la diretamente em vez de escalonar cada vez. Manteve-se exatamente como o guia da opção de não contacto, e o Executor seguiu-a exatamente igual. A diferença era invisível para ele e vivia só na intenção do designer: o guia da opção de não contacto era a resposta assente, e o guia da solução provisória era uma ponte, a substituir assim que o verdadeiro remédio estivesse pronto.

Por isso o design entrou em funcionamento com um conjunto de guias pré-aprovados a fazer um trabalho silencioso e pesado, alguns assentes, alguns temporários, cada um poupando ao Executor uma pergunta ou uma espera. O cliente que optou por não o ser nunca mais chegou a um Líder; a solução provisória do canal do cliente manteve o Executor firme até a sua regra ser construída; e a incidência desconhecida, uma vez resolvida, teria a sua própria resposta escrita num guia por sua vez, baixando do escalonamento ao pré-aprovado e poupando ao próximo Executor o escalonamento que o primeiro teve de fazer. Cada guia era um ponto de contacto retirado, depositado de antemão pelo designer para que o Executor, encontrando o caso, pudesse simplesmente avançar. Isso é o nível pré-aprovado a fazer aquilo para que é: fazer que a exceção, para quem a encontra, se sinta quase como nenhuma exceção.

Cada guia pré-aprovado, assente ou temporário, era um ponto de contacto que o designer retirou de antemão, para que o Executor pudesse encontrar o caso e simplesmente avançar.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 5: Pré-Aprovado · Um exemplo real

MarvinPro | Junho 2026

marvinpro.com

Pré-Aprovado

O mundo chama a uma exceção pré-aprovada um só desvio autorizado de antemão mas ainda uma exceção, temporário, o seu risco aceite, pronto a expirar e ser revisto de novo, um instrumento de governação cujo lar é o domínio de Governação. Este livro quer dizer outra coisa. Aqui, pré-aprovado é uma resposta permanente: o designer previu o caso, decidiu a sua gestão, escreveu-a num guia, e fê-lo assinar uma vez, e desde então o guia mantém-se. O Executor segue-o dentro de plena sanção e nunca volta a procurar aprovação, porque a aprovação foi depositada, feita uma vez e permanente, não concedida e a expirar. E o fardo recai diferente: a expiração do mundo recai sobre quem faz, que deve trazer o caso de novo para aprovação; aqui o guia nunca expira para o Executor, e a única expiração é o próprio dever do designer de dobrar o caso nas regras a tempo. A provisoriedade é do designer para carregar; ao Executor dá-se estabilidade.

Nem todo o caso pode ser pré-aprovado. Um caso pode, quando a sua resposta é conhecível de antemão e segura de escrever, uma condição clara, uma resposta fixa correta, sem juízo no momento, como o cliente que optou por não ser contactado. Não pode, quando a sua resposta ainda não se conhece, como a incidência desconhecida, ou quando aplicá-la de verdade precisa de uma decisão no momento. E a guarda que mantém isto honesto: nunca pré-aprovas um caso que precisa de juízo no momento, porque um guia escrito para tal caso é um guia falso, e um guia falso é pior do que nenhum, produzindo uma gestão confiante, uniforme, errada que parece o design a funcionar. Pré-aprova exatamente o que é seguro de escrever; encaminha o resto ao escalonamento, sem fingir que pode escrever-se.

A razão por que o designer alcança o pré-aprovado primeiro é o Executor. Cada caminho a seguir custa um ponto de contacto, uma pergunta, uma espera, um escalonamento, e o pré-aprovado não custa quase nenhum: o Executor encontra o caso, segue o guia permanente, e avança no fluxo do trabalho, sem parar por ninguém. É a gestão de maior alavancagem, porque o designer pensa uma vez e a poupança repete-se para cada Executor que alguma vez encontre o caso. Emparelha-se com pôr de lado para que um design entre em funcionamento sem esperar pela perfeição, põe de lado o que pode esperar, pré-aprova o que tem uma resposta conhecível, lança agora. E um guia pré-aprovado pode ser uma resposta assente ou uma solução provisória; para o Executor são o mesmo guia estável, e a diferença vive só na intenção do designer de substituir um e manter o outro.

Por isso a disciplina é esta: pré-aprova cada exceção cuja resposta seja conhecível e segura de escrever, e não mais. Escreve a resposta permanente num guia, fá-lo assinar uma vez, e deixa o Executor segui-lo sem perguntar a ninguém, poupando-lhe um ponto de contacto de cada vez. Não escrevas um guia onde o caso precisa de juízo no momento; envia isso ao escalonamento com honestidade. E carrega, como a própria responsabilidade do designer, o dever de empurrar cada caso pré-aprovado ainda mais abaixo, dobrando os recorrentes nas regras, até que o caso não custe ao Executor nem sequer um guia, porque a regra agora o encaixa. Sob tudo isso há um fim: um Executor que trabalha tão depressa quanto possível, com tão poucas ações e tão poucos pontos de contacto quanto o design possa dispor, encontrando cada exceção como se fosse mal uma exceção.

Pré-aprova o que possa escrever-se com segurança, para que o Executor siga um guia permanente e não pare por ninguém; depois dobra-o nas regras, para que com o tempo a exceção não lhe custe nada.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 5: Pré-Aprovado · Resultado do Capítulo

MarvinPro | Junho 2026

marvinpro.com

Think Simple.