RAPID, RACI, DACI, SPADE: Escolha Um, Depois Execute-o de Verdade

A decisão que quatro pessoas achavam que possuíam

A mudança de preços foi enviada em uma terça-feira. Na quarta-feira, a VP de Vendas perguntou por que ela não havia aprovado — ela achava que era responsável pelos preços. O CFO presumiu que tinha a palavra final; ele havia aprovado o modelo. O líder de produto na verdade tomou a decisão, acreditando que era sua responsabilidade. E o CEO, ao ler sobre isso no documento de todos, estava sob a impressão de que decisões como essa chegavam até ele. Quatro pessoas, uma decisão, quatro proprietários sinceros — e agora um debate sobre reversão que é, na verdade, um debate sobre propriedade disfarçado de uma questão de preços.

Você já assistiu a uma versão disso. É a falha de governança mais comum em organizações em crescimento, e possui uma prateleira bem abastecida de remédios: RAPID, RACI, DACI, SPADE — estruturas cujo conteúdo inteiro é escrever quem desempenha qual papel antes da decisão ser tomada. As letras diferem; a percepção é idêntica.

O que aponta para o verdadeiro problema. As equipes gastam energia escolhendo entre os frameworks — posts de comparação, debates em workshops sobre se Consulted difere de Input — e depois atribuem as letras após a decisão, como documentação. Atribuir papéis depois é apenas narração. Este tutorial dedica uma tabela à escolha e o restante à execução: o fluxo de trabalho aplicado, que é idêntico, independentemente das letras que você escolher. (Para a teoria e a história dos frameworks, nosso guia de frameworks de decisão os cobre junto com o restante da caixa de ferramentas — este tutorial deliberadamente não o reitera.)

Os quatro frameworks em uma tabela

Seis trabalhos existem em qualquer decisão consequente. As estruturas os nomeiam de maneira diferente:

Escolha pelos seus bloqueadores genuínos: verdadeiros detentores de veto → RAPID; emaranhamento de execução → RACI; cultura de executor de processos → DACI; uma equipe que não anota o porquê → SPADE. Então pare. Os passos 2 a 10 abaixo não mudam com sua escolha — apenas as letras no passo 3 mudam. Essa frase é a mais útil do tutorial: ela encerra a busca por frameworks e inicia a execução, que é o comportamento que realmente melhora as decisões.

Configurando: escopo, depois papéis, depois o caso

1. 1Nomeie a decisão como uma reivindicação raiz. "Vamos passar a um modelo de precificação baseado em uso para o nível Team no primeiro trimestre." Seu autor é, na prática, o Recomendador/Condutor — a autoria é visível, então o R está registrado desde o primeiro segundo. Ponto de verificação: a raiz existe; seu autor é a pessoa que está construindo o caso.
2. 2Escopo quem participa com níveis de visibilidade. Defina a visibilidade da discussão — pública, em toda a locatária, departamento ou privada — para corresponder ao conjunto de Entrada pretendido. Uma decisão com escopo de departamento é consultável por esse departamento por construção; você não está contando com alguém se lembrar de incluir o Jurídico. Ponto de verificação: a visibilidade corresponde ao conjunto de Entrada, não ao hábito.
3. 3Registre a atribuição de papéis — antes do primeiro argumento. Como um pro-child da raiz: "Decisor: A. Recomendador: B. Concordar: C, D. Entrada: Eng, Jurídico. Informado: todos os envolvidos." Datado, atribuível e contestável como qualquer outra coisa na árvore. Essa ordenação é o ponto principal das estruturas de direitos de decisão: papéis atribuídos após o debate meramente descrevem o que aconteceu. Ponto de verificação: o argumento de atribuição precede todos os argumentos de caso.
4. 4Construa o caso. Opções como nós irmãos, cada uma com seus próprios prós e contras — a mesma estrutura do tutorial de registros de decisão, incluindo as opções rejeitadas sobre as quais um leitor perguntará mais tarde. Ponto de verificação: toda alternativa real tem um nó.

Consulta que você pode provar que aconteceu

"Você foi consultado?" é a pergunta em que toda decisão contestada acaba se baseando — e na maioria das organizações, a resposta honesta é um encolher de ombros: houve uma reunião, houve uma conversa, as memórias diferem. O fluxo de trabalho aqui torna a consulta um recibo, não uma recordação:

1. 1Cada detentor de entrada abre uma cadeia de perguntas e respostas sobre a recomendação: sua pergunta, a resposta do Recomendador, um acompanhamento, uma resposta — completa. A cadeia completa é a prova de que a consulta ocorreu: quem perguntou, o que foi respondido, quando. Um detentor de entrada que não tem nada a perguntar recusa explicitamente. Ponto de verificação: cada detentor de entrada tem ≥1 cadeia completa ou uma recusa explícita.
2. 2Um titular de concordância que apresenta objeções abre uma cadeia de Revisão: sua avaliação, a resposta do Recomendador, acompanhamento, resposta. Vários titulares de concordância significam várias cadeias paralelas, cada uma resolvida em seus próprios termos — sem bloqueios não resolvidos escondidos em um tópico de grupo. Ponto de verificação: não existe objeção ativa fora de uma cadeia.
3. 3Dois detentores de acordo em conflito → Cadeia de compromisso. Um propõe a posição intermediária ao outro, em registro. Resolvido ou não, a tentativa é documentada — o que converte "Jurídico e Finanças nunca concordaram" de uma acusação em uma troca legível. Ponto de verificação: conflitos ou resolvidos ou visivelmente ativos.

Decidindo contra o quarto e anotando o porquê

Antes da chamada, todos avaliam as opções — uma classificação rotulada para cada uma. Leia isso pelo que é: evidência de onde o grupo estava, não um voto. Não há quórum, não há limite, não há desempate; toda a premissa do framework é que um humano nomeado decide.

Então o Decisor decide — como um argumento, elaborado por eles, sob a opção escolhida, declarando o raciocínio. E aqui está a única frase mais valiosa que o fluxo de trabalho produz: se a decisão vai contra as avaliações, o nó do Decisor é onde isso é explicado. "A sala inclinou-se para a opção B; estou escolhendo A porque o risco de renovação da empresa supera a preferência da distribuição" — uma frase que separa liderança de discordar e se comprometer de decisão por decreto, e a exata coisa da qual uma decisão durável é feita. Um Decisor que não a escrever não está gerenciando uma estrutura; está usando uma.

• ✓Ponto de verificação: distribuição capturada antes da chamada; decisão registrada como o próprio argumento do Decisor, com justificativa — obrigatória quando contradiz a sala.

Informando sem um e-mail separado

Última carta, passo mais barato: ampliar a visibilidade da decisão uma vez tomada. O conjunto Informado abre a discussão e lê não apenas o resultado, mas o debate — as opções, as cadeias de consulta, o porquê do Decisor. "Por que o preço mudou?" nunca precisa de seu próprio tópico de e-mail, porque a resposta é o registro em si. Feito dessa forma, informar também é o começo do comprometimento: as pessoas se comprometem com decisões cujo raciocínio podem inspecionar.

• ✓Checkpoint: visibilidade ampliada para o conjunto Informado; o anúncio vincula o registro em vez de paráfrase-lo.

Limitações honestas

• ✗Não há um campo de função de decisão. As cartas são uma convenção registrada — datada e atribuível, mas o produto não as atribui nem as verifica. Um papel RBAC é um nível de permissão, nunca um direito de decisão.
• ✗Avaliações não são votos ponderados. Um valor e rótulo por pessoa, sem quórum, sem limite, sem desempate. O Decisor é o desempate.
• ✗Leitura de escopos de visibilidade, não obrigação. O escopo do departamento significa que o Jurídico pode vê-lo — a cadeia de perguntas e respostas concluída, não a configuração de visibilidade, é a evidência de que eles se envolveram.
• ✗Uma cadeia é quatro voltas, então completa — e completa ≠ acordado. O detentor de Acordo dissidente que se compromete de qualquer forma é documentado como ouvido, não convertido.
• ✗Nada disso resolve um Decisor relutante. A estrutura expõe uma decisão não tomada mais rapidamente — o nó vazio onde a chamada deveria estar é muito visível — mas não pode fazer a chamada.

Aulas práticas

• ✓Escreva o argumento de papel na reunião de lançamento, ao vivo, antes que alguém discuta os méritos. Trinta segundos agora versus a arqueologia da quarta-feira seguinte.
• ✓Mantenha a lista de Acordos brutalmente curta. Cada detentor de Acordo é um potencial bloqueio com uma cadeia a resolver; a maioria dos "aprovadores" é na verdade Input. A disciplina do RAPID é dizer isso em voz alta.
• ✓A consulta recusada também é um registro. Um titular de entrada que passa explicitamente não pode reivindicar exclusão mais tarde — proteja-os e a si mesmo tornando a passagem visível.
• ✓Reutilize a atribuição. Tipos de decisão recorrentes (preços, bandas de contratação, seleção de fornecedores) mantêm as mesmas letras — cole o argumento de função como um modelo e atualize os nomes.

Quarta-feira, revisitada

Reexecute a mudança de preços através do fluxo de trabalho. A VP de Vendas é uma detentora de Acordo — sua objeção é uma cadeia de Revisão concluída, respondida duas vezes, e ela se comprometeu. O CFO é Input — sua consulta é um recibo. O líder de produto é o Decisor por um argumento datado escrito antes do debate, e sua justificativa para ir contra a tendência da sala é um parágrafo que todos podem ler. O CEO é Informado — o documento de todos os funcionários vincula a árvore. Mesma decisão, possivelmente o mesmo resultado. Mas na quarta-feira não há nada a recontestar, porque a única pergunta que sempre alimenta essas brigas — quem tinha o direito de decidir isso? — foi respondida antes que alguém argumentasse.