决策框架能帮你把一个选择整理出结构，但用哪个框架有用，取决于现在还没解决的是什么。用加权矩阵（weighted matrix）把选项按多个标准做比较，用决策树（decision tree）看不确定的结果，用事前验尸（premortem）找这个计划可能怎么失败。当问题出在「谁提供输入、谁批准、谁拍板、谁执行」上，用 DACI 或者 RAPID。分析工具和角色框架可以组合使用。先说清楚要决定什么、约束是什么、截止时间是哪天；然后挑一个刚好能补上缺失答案的最轻的流程。框架组织的是判断，它不会把不确定的假设变成事实。
决策框架是什么
决策框架是一套可以重复使用的结构，用来定义一个问题、收集相关信息、比较备选方案，或者分配决策责任。有些框架同时做其中几件事，另一些只解决流程里的一个环节。
一张打分的表格没法确定谁有拍板的权限。一份决策角色清单也告诉不了你某个方案是否满足预算。认清这个区别，能让一个团队避免把熟悉的缩写套在一个用错地方的问题上。
在选框架之前，先把这句写完：「我们需要在 ___ 之前决定是否 ___，约束条件是 ___。」 把决策负责人和需要的产出都点明。对于一个小的、可以回退的选择，产出可能就是一段简短的说明。一个影响较大的投入，则可能需要证据、备选方案和一套回顾计划。
按真正的瓶颈选框架
| 还没解决的问题 | 有用的框架 | 要找的产出 | 主要局限 |
|---|---|---|---|
| 哪个可行方案最符合多个标准？ | 加权决策矩阵 | 分数、权重和一次敏感性检验 | 判断看起来可能比实际更客观 |
| 在不同可能的结果下会怎样？ | 决策树 | 分支、假设和条件取值 | 不可靠的概率会算出不可靠的期望值 |
| 这个计划可能怎么失败？ | 事前验尸 | 失败原因和可执行的应对 | 想象出来的失败只是可能性，不是预测 |
| 谁推进并做出一个跨团队的决定？ | DACI | 一名 Driver、一名 Approver、Contributors、Informed | 角色分工替代不了实质分析 |
| 谁提议、谁必须同意、谁决定、谁执行？ | RAPID | 明确的权利和责任 | 审批权给多了会把流程拖住 |
如果方案本身还很含糊，先把它们说清楚再打分。如果某个方案违反了硬性要求，直接淘汰，而不是让它在其他标准上的高分来补偿。强制性的安全或法律要求，不是一般的偏好项。
加权决策矩阵：比较可行的方案
决策矩阵把各个备选方案放在同一组标准下比较。Atlassian 的决策矩阵模板介绍了一个加权版本：选定标准、分配重要度、给方案打分、算出总分。
流程是这样的：
- 去掉不满足硬约束的方案。
- 选一组能代表不同好处或成本的标准。避免用两个不同名字把同一个好处算两遍。
- 给每个标准一个权重，所有权重加起来等于 1。
- 定义打分刻度。这里规定每一项都是分数越高越好，5 优于 1，可负担性也一样。
- 每个分数乘以它的权重，再把各项加起来。
- 改一个合理但不确定的权重或分数，看看排序是否还站得住。
算例：两个软件方案
下面的数字是为了教学编出来的，不是产品评分。「可负担性」表示分数越高越有利。
| 标准 | 权重 | 方案 A | 方案 B |
|---|---|---|---|
| 可负担性 | 0.40 | 2 | 5 |
| 流程契合度 | 0.35 | 5 | 2 |
| 支持 | 0.25 | 4 | 3 |
| 加权总分 | 1.00 | 3.55 | 3.45 |
A：0.40 × 2 + 0.35 × 5 + 0.25 × 4 = 3.55。
B：0.40 × 5 + 0.35 × 2 + 0.25 × 3 = 3.45。
这组权重略微偏向 A。只要优先级换一个合理的排法，就变成偏向 B。
把可负担性的权重提到 0.50，流程契合度降到 0.25，支持保持 0.25。总分变成 A = 3.25、B = 3.75。产品一个都没变，结论就反过来了。
在支持权重固定为 0.25、另外两项加起来为 0.75 的前提下，可负担性的权重大约在 0.417 时两个方案打平。低于这个数 A 分数更高，高于它则 B 更高。这个临界点只适用于上面假定的分数和权重约束。
真正有用的结论是：原来的偏好对优先级很敏感。要么把有争议的那个优先级定下来，要么去收集关于流程契合度更可靠的信息。不要拿 3.55 对 3.45 当作 A 客观更优的证明。
决策树：把不确定的结果摆到明面上
决策树把你能控制的选择和你控制不了的结果分开。先摆出可做的决定，然后在每个选项下面画出相关的可能结果。
举个为了教学刻意简化的例子：假设一个试点有 60% 的概率带来 800 美元的净收益，40% 的概率造成 200 美元的净损失。它的期望净值是：
0.60 × $800 + 0.40 × (−$200) = $400。
在这个模型里，一个净收益确定为 350 美元的替代方案期望值更低。但如果亏损会突破一条现金上限、假定的概率本身很站不住、或者下行风险比平均数更关键，那么它仍然可能是更好的选择。
要检查几件事：同一个机会节点下的概率加起来是不是 1；结果有没有覆盖你打算建模的情形；成本是不是只算了一次。如果你没有给出概率的依据，就用写明的情景和区间，别把猜测包装成测出来的可能性。
这个树的例子是原创的示意性算术，不是预测，也不是让你去承担金融风险的建议。机会成本计算能帮你把被放弃的那个替代方案摆在明面上；二阶思维能帮你找出简单决策树容易漏掉的后续影响。
事前验尸：在投入之前先查失败
事前验尸先假设这个项目已经失败了，再问是什么导致了失败。这个起点来自 Gary Klein 的原始描述。
拿一个原创的工作坊例子来说：设想一次软件上线失败了，因为员工没法在新系统里完成日常任务。记下一个可能原因、一个早期信号和一条应对措施：
| 可能原因 | 要检查的早期信号 | 实际应对 |
|---|---|---|
| 关键工作流缺失 | 试点用户完不成一项必需任务 | 上线前先测这项任务 |
| 责任划分不清 | 请求在团队之间来回流转却没解决 | 指定负责人和升级路径 |
| 迁移耗时超出预期 | 试迁移超出可用时间窗口 | 投入前先调整范围或时间安排 |
把一个可能的失败，变成一个要查的信号和一条你能分派的应对。
这些都是想象出来的失败模式。把它们当成值得去查的线索，再根据真实情况排优先级。一长串吓人的可能性，还不构成一份风险评估。
团队决策角色：DACI 和 RAPID
分析可能已经做完了，决定却还是卡着，因为没人知道最后是谁说了算。DACI 和 RAPID 解决的就是这个协同问题。
DACI：一个人推进，一个人拍板
- Driver： 组织流程、信息和截止时间。
- Approver： 做出这个决定的那一个人。
- Contributors： 提供相关的专业判断和建议。
- Informed： 因为工作会受影响而获知结果的人。
在一个软件选型里，运营负责人可以做 Driver，预算负责人做 Approver，使用者和技术人员做 Contributors，受影响的同事做 Informed。角色要针对这一次具体决定来分配，别假定某个职位名称永远对应同一个角色。
组织流程和做出最终决定，是两项分开的责任。
RAPID：把同意和执行也说清楚
Bain 的 RAPID 模型指的是 Recommend、Agree、Perform、Input、Decide。Recommend 负责把方案做出来；Input 提供相关信息；Decide 做出选择；Perform 负责执行。Agree 标出一项必须获得同意的权利，它可能对应某条明确的合规要求。
把 Agree 和 Input 分开。一个给出有用建议的人不会自动获得否决权。写清楚哪一件事需要经过同意，以及分歧怎么解决。Bain 建议在可能的情况下只设一个决策人。
这些说明足够你选一个角色模型了。如果正式的审批权已经由制度定好，框架必须尊重它。
一份可以复看的决策记录
把这些字段抄进一份简短文档：
| 字段 | 要回答的问题 |
|---|---|
| 决定和截止时间 | 具体必须选什么，什么时候之前？ |
| 负责人和角色 | 谁组织、谁提供输入、谁决定、谁执行？ |
| 约束条件 | 每个方案都必须满足什么？ |
| 备选方案 | 我们实际可以选择什么，可行的话包括推迟？ |
| 证据和假设 | 哪些已经核实，哪些仍然不确定？ |
| 分析 | 哪个工具适合这个瓶颈，结果对参数有多敏感？ |
| 选择和理由 | 定了什么，为什么？ |
| 回顾触发条件 | 什么事件或新证据应该让这个决定重新打开？ |
当矩阵或决策树对分析有帮助时就用，只有角色需要澄清时才加 DACI 或 RAPID。博弈论游戏处理的是另一层复杂情况：别人的选择可能会改变你的结果。
常见问题
决策框架有哪些例子？
加权矩阵用来比较标准，决策树用来表示不确定的结果，事前验尸用来探讨可能的失败，DACI 或 RAPID 用来厘清角色。它们解决的是不同问题，有时可以在同一个决策流程里组合使用。
决策的框架是什么？
没有一个框架适合所有选择。先定义决定和约束，找出还没解决的东西，选一个匹配的工具，然后记录结果和回顾条件。让流程的分量和这件事的份量相称。
什么是战略性决策框架？
对于战略性选择，一套有用的结构会把决定和目标、可行备选方案、相关证据、取舍、归属以及回顾计划连起来。如果不确定性占主导，就去考察情景；如果责任不清，就在征求意见之前先把决策权定下来。