决策矩阵解决什么问题
技术选型常卡在“各说各话”：有人说性能重要，有人说生态重要，讨论没有共同标尺。决策矩阵把备选方案与评估维度排成表格，逐项评分并加权汇总，把分歧从“观点对抗”转成“对某一格评分的证据讨论”。它的产出是结构化的讨论记录，不是替团队做决定——最终仍由责任人拍板并留痕。
基本信息
| 输入 | 备选方案清单、评估维度、各维度权重、每格评分的证据来源 |
|---|---|
| 输出 | 加权得分表、关键分歧点、待补充验证项，通常随 ADR 归档 |
| 适用时机 | 方案数量 2~5 个、维度可枚举、决策影响面较大的选型 |
| 不适用 | 信息严重不足或维度无法量化时，先做 PoC 再评分 |
典型使用场景
- 中间件选型：消息队列、注册中心、网关等候选对比
- 云与自建取舍：把成本、合规、运维能力放进同一张表
- 框架与语言选型：团队熟悉度与招聘市场一并作为维度
- 架构方案评审：多个方案对照质量属性，为 ATAM 提供输入
- 遗留系统改造路径：停机迁移与渐进替换按维度量化比较
示例
示例
维度（权重）：性能 0.3 | 生态 0.25 | 运维 0.25 | 成本 0.2
方案 A：8×0.3 + 7×0.25 + 6×0.25 + 7×0.2 = 7.05
方案 B：7×0.3 + 8×0.25 + 8×0.25 + 6×0.2 = 7.25
分歧点：B 的运维优势是否可验证？→ 补 PoC评分维度参考
| 维度 | 观察方式 | 证据形态 |
|---|---|---|
| 性能 | 压测或公开基准，按自身负载特征折算 | 压测报告与折算口径 |
| 生态成熟度 | 文档质量、社区问答量、周边工具覆盖 | 文档链接与调研记录 |
| 运维成本 | 部署复杂度、监控接入、升级与备份工作量 | 人力估算与试点结论 |
| 合规与安全 | 许可证、数据落地要求、审计能力 | 法务与安全评估意见 |
| 成本 | 按 3~5 年口径核算，含人力与迁移 | TCO 模型 |
使用要点
- 权重在评分前确定并写进文档，评分后再调权重等于用流程凑结论
- 每格评分标注证据来源与评分人，复盘时能追溯到具体压测或文档
- 得分接近时不要纠结小数位，转而补齐关键分歧点的证据
- 把“无法验证”单列一栏，说明需要 PoC 还是接受不确定性
- 矩阵是输入不是结论：最终决定与理由写进 ADR，说明为何采纳或推翻矩阵结果
评分要可追溯（证据与评分人）；差异小的方案不必纠结小数位，转而讨论关键分歧点，并把结论落到决策记录里。
矩阵容易被当成“客观结论”使用：评分仍含主观判断，权重也由人设定，把它当作结构化讨论工具而非免责任凭据，最终决策仍需责任人签字。