方案设计与多方案对比
一、从单一方案到多方案对比
单一方案直接推进的问题：没有对照，难以判断是否更优、是否遗漏了更简单或更稳妥的做法；决策依据不透明，事后复盘也说不清「当时为什么这么选」。要求至少 2～3 个选项（可包含「维持现状」「最小改动」），并显式说明取舍，能提高决策质量和可追溯性。
只有一个选项就推进：缺少对照，无法评估优劣；一旦实施后发现问题，没有备选可退；决策理由也难留存。
至少 2～3 个选项，按统一维度比较，写清选谁、不选谁、理由与代价。决策可追溯，复盘可改进。
二、设计选项的生成技巧
「想不出第二个方案」时，可以用一些技巧扩展选项，而不是停留在「就这一个想法」。
选项生成技巧
- 约束反推： 先定一个强约束（如「必须 2 周内上线」「不能动数据库」），再在该约束下想方案；换一个约束又得一版。多组约束可得到多组选项。
- 最小 / 折中 / 理想： 最小可行方案（MVP）、折中方案、理想方案各一版，形成三条不同投入与收益的路径。
- 参考业界： 同类问题别人怎么做的（开源方案、云服务、业界案例），列出 2～3 种再结合自身约束做裁剪。
- 反向与替代： 「如果不做 X，还能怎样达成目标？」「用 Y 替代 X 会怎样？」帮助跳出第一个想法。
下图概括「从问题到选项再到决策」的流程：问题与约束 → 生成多个选项 → 按维度对比 → 选一个并记录。
三、对比维度：成本、风险、时间、可维护性
选项之间要在同一套维度下比较，否则无法公平取舍。常用四类：成本（人、钱、资源）、风险（技术/业务/组织风险及发生概率与影响）、时间（上线周期、依赖）、可维护性（后续演进、团队能力匹配）。可根据项目增加或减少维度（如合规、安全），但不要只比一个维度就拍板。
人力、采购、运维、迁移等。不同方案的人天、云成本、许可证成本要粗算可比。
技术风险（如新技术栈）、业务风险（如上线时机）、组织风险（如依赖外部团队）。概率与影响要大致估计。
开发周期、上线窗口、依赖方排期。能否赶上业务节点、是否有阻塞依赖。
后续扩展、运维难度、团队熟悉度。避免选了一个「上线快但以后难改」的方案。
四、决策矩阵与记录（ADR）
把选项和维度放进一张决策矩阵（表格）：每行一个选项，每列一个维度，单元格内填定性或定量结论；再写一行「结论」与「选 A 而非 B 的理由」。决策后建议写成ADR（Architecture Decision Record）：背景、选项、对比要点、决策、理由、后果（与第 9 章呼应），便于日后复盘与传承。
| 选项 | 成本 | 风险 | 时间 | 可维护性 | 结论 |
|---|---|---|---|---|---|
| A：自研调度 | 高（2 人月） | 中（自研质量） | 长（8 周） | 高（可控） | — |
| B：云 Scheduler | 低（按量） | 低 | 短（2 周） | 中 | ✓ 当前首选 |
| C：维持现状 | 零 | 高（现网隐患） | 零 | 差 | 不选 |
案例：某次要在「自研任务调度」「采购云 Scheduler」「维持现有脚本」之间选。团队列了成本、风险、时间、可维护性四个维度，矩阵对比后认为当前阶段云 Scheduler 成本低、上线快、风险可控，可维护性虽不如自研但可接受；决定选 B，并写 ADR 记录「若未来需要更复杂策略再评估自研」。这样以后有人问「当时为啥不用自研」时，有据可查。
要点： 多方案对比不是为「拖延决策」，而是为提高决策质量与可追溯性。选项不必很多，2～3 个足够；维度要统一、结论要写清「选谁、不选谁、为什么」；最后用 ADR 固化，方便复盘与迭代。
反例：只有一个方案就上，事后发现更优解却无法回头。
某次要做「跨机房数据同步」，负责人只提了一个方案「用 A 中间件」，评审会上没人提其他选项就通过了。实施到一半发现 A 的授权和运维成本很高，且与现有监控体系不兼容。后来有人查资料发现同场景下 B 开源方案更合适，但已经投入大量集成与定制，切换成本巨大。若当时要求至少再列一个选项（如 B 或「先单机房再评估」），在成本与可维护性维度上对比，很可能不会选 A。单一方案直接拍板，容易锁死在次优路径且难以追溯「当时为何不选别的」。
小结： 从单一方案走向多方案对比：至少 2～3 个选项并说明取舍。用约束反推、最小/折中/理想、业界参考、反向思考等技巧生成选项；用成本、风险、时间、可维护性等维度统一对比；用决策矩阵表格化比较，用ADR记录决策与理由，便于复盘与传承。
五、小结
方案设计与多方案对比能显著提升决策质量。至少2～3 个选项、用生成技巧扩展思路，在成本、风险、时间、可维护性等维度上对比，用决策矩阵与ADR记录取舍与理由。下一章讲风险评估与应对策略：如何识别与评估风险，并制定缓解、转移与应急计划。