职场工具箱之 RAPID：把红线和拍板权拆开，跨部门少扯皮

短大纲（给忙人）

跨部门会议的真相：大家不是不合作，是都怕背锅

你有没有经历过这种会：

• 议题很重要（安全、合规、预算、品牌……）
• 人也很齐（各条线都来了）
• 结果很一致：没有结果

因为每个人都很“专业”地说：

“这个有风险。”
“原则上可以，但要看情况。”
“建议再评估一下。”
“我们需要更多信息。”

翻译成大白话就是：“别让我拍板。”

日常项目里你可以用 DACI 解决“推进”和“拍板”；但一旦涉及强约束决策（比如合规安全、预算审批、政策变更），你会发现：

• 光有拍板不够：你拍了也不敢落地，因为不知道踩不踩红线
• 光有共识没用：大家都“原则同意”，但没人愿意在红线上签字

这时候你需要的不是再多开三次会，而是把决策角色拆得更细一点：RAPID。

1) RAPID 是什么：把“红线”和“拍板”拆开

RAPID（Bain 提出的决策角色框架）把决策拆成五个角色：

• R - Recommend（推荐）：写方案的人。负责把选项、数据、风险、建议准备好。
• A - Agree（同意/红线）：必须同意才能往前走的人。通常是法务/合规/安全/财务等“硬约束”角色。
• P - Perform（执行）：负责把决策落地的人（真正要做事的人）。
• I - Input（输入）：提供信息、经验、观点的人（影响方案，但不拥有否决权）。
• D - Decide（决定）：最终拍板的人（最好只有一个）。

你可以把它理解成一句话：

Input 提供信息，Agree 提供红线，Decide 才负责拍板；拍完板，Perform 负责把它变成现实。

2) 什么时候用 RAPID（什么时候别用）

RAPID 不是日常每个小决策都要用，它更像“组织级大扳手”。

我判断是否需要 RAPID 的一条土办法：

只要会议里出现“合规/安全/预算/品牌/审计/法律责任”这类词，且大家开始互相看眼色——八成就该用 RAPID。

3) 会前 15 分钟：先让 Agree 把“红线清单”写出来

跨部门扯皮的根源，往往不是“大家不理性”，而是红线没提前说清。

你可以在会前发一页纸，让 Agree 角色先填（越具体越好）：

【红线清单（Agree 填）】
1) 绝对不能做的：________（例如：把 PII 明文写日志）
2) 必须满足的条件：________（例如：数据留存 <= 30 天，且可审计）
3) 必须走的流程：________（例如：安全评审 + 法务确认）
4) 我能接受的折中：________（例如：先灰度到 5% 用户）
5) 我最担心的失败场景：________（例如：权限绕过导致数据泄露）

这样做的好处是：你把“会后追责”提前变成“会前约束”。

4) 三个跨部门会议场景（直接抄）

场景 1：安全评审（新功能要采集/处理敏感数据）

❌ 低效版：

安全：这个有风险。
研发：我们会注意的。
安全：建议再评估一下。
（会议结束：没有结论）

✅ RAPID 改写：

• Recommend（研发/PM）：准备三件事：数据流向图、权限模型、日志策略（哪些字段绝不入日志）。
• Agree（安全/合规）：提前给“红线清单”（例如：PII 不落盘、日志脱敏、最小权限）。
• Decide（业务 Owner/总监）：在满足红线后当场拍板。
• Perform（研发/SRE）：把控制措施写成可验收的行动项。

会前开场白（你可以直接念）：

“今天不是讨论‘有没有风险’，是讨论‘怎么在红线内上线’。
我是 Recommend；安全/合规是 Agree；X 是 Decide；Y 团队 Perform。
如果 Agree 没有新增红线，我们今天就拍板上线策略和灰度范围。”

会后纪要要写成“可验收”的样子：

Action：日志脱敏（禁止记录 user_email / phone / token）
- Perform：张三
- 验收：安全扫描通过 + 线上抽检 10 条日志不含敏感字段
- DDL：2026-02-14

场景 2：预算申请（你要买资源/上新工具）

❌ 低效版：

你：我们需要预算。
财务：为什么需要？
你：因为现在不够用。
财务：那你再算算 ROI。

✅ RAPID 改写：

• Recommend（你）：给出“成本-收益-风险”三段式，并提供两个选项（省钱版/稳妥版）。
• Agree（财务/采购）：明确硬约束（预算上限、采购流程、合同条款）。
• Input（运维/安全）：补充运维成本与风险。
• Decide（你的主管/业务负责人）：在预算约束内拍板选项。
• Perform（你/平台团队）：负责落地采购与上线。

推荐模板（很“工程师友好”）：

选项 A（省钱）：月成本 X，风险：容量紧张（可接受）
选项 B（稳妥）：月成本 X+Δ，收益：故障概率下降/人力节省（可量化）
我的建议：选 B，因为……

场景 3：组织级规则变更（比如发布门禁/值班制度）

❌ 低效版：

“大家觉得要不要加发布门禁？”
“我觉得可以。”
“但会影响效率。”
“那再讨论讨论。”

✅ RAPID 改写（非常适合“政策类决策”）：

• Recommend（你或流程 Owner）：提出规则草案 + 试运行方案（两周试点）。
• Agree（合规/安全/质量负责人）：给出必须满足的底线指标（例如：P0 必须有门禁）。
• Input（各团队 TL）：给出执行影响与例外场景。
• Decide（负责人/委员会主席）：确定“生效范围 + 例外机制 + 复审时间”。
• Perform（各团队）：执行并反馈数据。

这里有个小技巧：把“反对”改成“例外条款”。

你不是要所有人都喜欢新规则，你是要把“哪些情况可以例外、谁批准例外、例外记录怎么留痕”写清楚。

5) 常见坑（RAPID 用不好会更慢）

• Agree 过多：每个人都想当“红线”，最后红线变成蜘蛛网
• 把 Input 当 Agree：意见很重要，但“意见 ≠ 否决权”
• Decide 不敢用 D：最后还是“集体拍板”，等于没拍
• Perform 没提前介入：拍板很爽，落地很痛（执行成本没人算）

总结：RAPID 让组织敢做决定，也敢承担后果

一句话：跨部门少扯皮，不靠情商，靠角色。

自检清单（开会前 30 秒）

• [ ] Recommend 的方案里有选项、有建议、有风险
• [ ] Agree 的红线清单提前写出来了（别在会上“临时想起”）
• [ ] Decide 只有一个，且在场
• [ ] Perform 明确到人，且有验收标准
• [ ] Input 的范围控制住（否则会议又会变长）

最后给你一张思维导图，方便收藏。

@startmindmap
<style>
mindmapDiagram {
  node { BackgroundColor #FAFAFA }
  :depth(0) { BackgroundColor #FFD700 }
  :depth(1) { BackgroundColor #E8F5E9 }
  :depth(2) { BackgroundColor #F5F5F5 }
}
</style>
* RAPID：红线与拍板拆开
** 五角色
*** Recommend：写方案
*** Agree：红线/硬约束
*** Perform：落地执行
*** Input：提供信息
*** Decide：最终拍板
** 适用场景
*** 合规/安全
*** 预算/采购
*** 组织级政策
** 会前准备
*** 红线清单（Agree）
*** 选项对比（Recommend）
*** 验收标准（Perform）
** 三个场景
*** 安全评审
*** 预算申请
*** 规则变更
** 常见坑
*** Agree 过多
*** Input 当 Agree
*** Decide 不敢用 D
*** Perform 缺席
@endmindmap

系列串读

1. DACI / RAPID 总览：别再“拉齐共识”了，把拍板权写在纸上
2. DACI：谁推动、谁拍板，会议自然短
3. RAPID：把红线和拍板权拆开，跨部门少扯皮（本篇）

扩展阅读

• RAPID® Decision Making - Bain & Company

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。