研发平台部署选型进入统一评审时，常见难点是各方案在不同假设下被比较：有人看合规，有人看成本，有人只关心上线速度。本文给出一套可执行的决策矩阵构建方法，从固定候选方案与评审口径开始，依次完成维度裁剪、否决项设置、权重分配、打分汇总与记录归档，并附三方案示例和核验清单，帮助评审组形成带证据、可复核的选择结论。
要点总览（TL;DR）
- 决策矩阵的构建顺序是：固定候选方案与评审口径、裁剪维度、设置否决项、分配权重、逐项打分汇总、归档选择记录，顺序颠倒会让评审反复返工。
- 维度从合规与安全、数据主权与网络条件、集成与迁移、运维与人力、性能与容量、成本与合同、交付周期与供应商风险七类中裁剪，剔除无关项、降级无证据项、合并重复计分项。
- 权重由业务目标和关键约束推导，可用百分制或一级/二级分组权重，确认后做敏感性检查，权重小幅调整不改变排序才说明结论稳定。
- 否决项对应不可协商的硬约束，先于打分执行，候选触碰即出局；可权衡的偏好放入权重，同一因素不在两处重复出现。
- 选择记录需包含候选、维度、权重、否决判定、得分、证据、结论与保留意见，评审前和评审后各做一轮核验再进入决策。
先固定评审对象与口径：矩阵的输入怎么准备
矩阵的第一项工作是把“比较什么”和“怎么比”固定下来。候选方案清单、评审角色、统一假设和证据来源四项输入齐备后，打分才有意义；任何一项缺失，后续权重和得分都容易在评审会上被推翻。
候选部署方案清单
按本次决策的实际范围列出候选形态，常见包括公有云托管、专属云、私有化本地部署、混合部署，以及私有化基础上的高可用集群形态。清单需要写到可比较的粒度：同一供应商的不同部署形态应分别列为候选，并注明对应的产品版本或方案版本。清单确定后由评审组确认封版，评审过程中新增候选须重新走一轮口径确认。
评审组构成与职责
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务负责人 | 提出业务目标、使用场景与上线时间要求 | 业务需求说明、场景清单 |
| IT运维 | 评估现有基础设施、运维人力与网络条件 | 运维测算、资源评估 |
| 安全合规 | 识别监管要求、数据分级与隔离条件 | 合规要求清单、否决项建议 |
| 采购 | 核对合同条款、计费方式与供应商资质 | 商务条款对比 |
| 财务 | 统一成本口径，核算多年期总拥有成本 | 成本测算表 |
评审组应指定一名矩阵负责人，负责维护维度、权重和打分记录的一致性，避免不同角色各自使用一套表格。
统一比较口径
所有候选方案须在同一套假设下评估：相同的业务场景范围、相同的评估时间跨度（例如三年）、相同的用户数与数据规模、相同的可用性要求。假设写成书面说明附在矩阵前，打分人引用同一份说明，减少“按自己理解打分”的偏差。
证据来源清单
为每个维度预先约定可接受的证据类型：供应商方案书与报价、POC或测试结果、内部运维测算、合同条款、合规评估意见。证据来源在打分前登记，打分时逐项标注出处；无法取得证据的项按待验证处理，不凭印象给分。
维度怎么设：七类候选维度与取舍规则
维度从固定维度池中裁剪，而不是每次从零 brainstorm。先列出七类候选维度，再依据本次决策的业务目标和约束逐类判断保留、降级或剔除，最后为保留维度定义评分刻度。
七类候选维度
| 维度 | 评估内容 | 典型证据 |
|---|---|---|
| 合规与安全 | 等保、行业监管、数据分级与访问控制要求 | 合规评估意见、安全方案 |
| 数据主权与网络条件 | 数据存放位置、出境限制、网络隔离与访问链路 | 网络架构说明、部署方案 |
| 集成与迁移 | 与现有账号体系、内部系统的对接，历史数据迁移工作量 | 集成清单、迁移评估 |
| 运维与人力 | 日常维护工作量、所需技能、值班与升级责任 | 内部运维测算 |
| 性能与容量 | 并发与数据量增长下的表现、扩容方式 | POC结果、容量规划 |
| 成本与合同 | 多年期总成本、计费方式、合同约束条款 | 报价单、合同草案 |
| 交付周期与供应商风险 | 上线周期、实施依赖、供应商持续服务能力 | 实施计划、供应商资料 |
维度裁剪规则
裁剪按三条规则执行。第一，与本次决策无关的维度剔除，例如已有统一账号体系且无迁移需求时，集成与迁移可只保留对接工作量一项。第二，无法取得证据的维度降级为待验证项，在结论中列为前置条件，不参与当期打分。第三，检查维度之间是否重复计分：把“运维人力投入”和“运维成本”拆成两项并分别加权，会让同一因素被计算两次，应合并为一项或明确各自只覆盖人力工时与外部支出。
评分刻度定义
每个保留维度用1–5分刻度，并为每一档写出可观察的事实描述，而不是形容词。例如运维与人力维度可定义为：5分对应供应商托管、内部无需专职维护；3分对应内部需约半个人力做日常维护；1分对应需要专职团队并承担升级与故障处理。刻度描述在评审前定稿，打分人对照事实描述给分，减少主观差异。
权重怎么分配：从业务目标推导，而不是平均分
权重回答的是“哪些维度对本次决策更重要”，应由业务目标和关键约束推导，经跨部门确认后固定。平均分配看似公平，实际掩盖了约束差异；由单一部门拍定则容易在评审会上被质疑。
权重推导路径
按四步推进：先明确业务目标（例如按期上线支撑新业务、满足监管检查、控制三年总支出）；再从目标中提取关键约束（数据不得出内网、须在某个时间点前上线）；然后对维度排序，约束越硬、影响越大的维度排位越前；最后把排序转换为百分制数值，一级维度权重合计100%。推导过程写成简短说明附在权重表后，便于复核。
两种权重做法
| 做法 | 适用情形 | 注意事项 |
|---|---|---|
| 百分制直接分配 | 维度数量少（约5–7项）、评审组对优先级判断一致 | 各维度权重合计须为100%，避免个别维度权重过高导致结论被单项主导 |
| 分组权重（一级维度+二级指标） | 维度较多、需要细分指标，或不同部门分别负责不同维度 | 先分一级权重，再在一级内部分配二级权重，两级相乘得到最终权重 |
典型场景的权重倾向
以下为倾向示例，具体数值须结合本次目标确定。强合规场景中，合规与安全、数据主权与网络条件合计可占较高比重，成本权重相应下调；快速上线场景中，交付周期与集成迁移权重上升；成本敏感场景中，成本与合同、运维与人力权重上升，性能与容量按实际负载需求保留中等权重。示例数值只用于说明分配思路，不作为通用标准。
权重复核机制
权重初稿由矩阵负责人整理，提交评审组跨部门确认，确认记录随矩阵归档。确认后做敏感性检查：对权重较高或得分差距较小的维度做小幅调整（例如上下浮动5个百分点），观察候选排序是否改变。排序稳定说明结论对权重不敏感；排序翻转则说明该维度需要补充证据或重新讨论权重依据，并在记录中写明处理结果。
否决项怎么设：先筛掉不合格方案
否决项处理硬约束：候选方案只要触碰否决项即出局，不进入加权打分。把硬约束放进权重里打分，会让一个不满足监管要求的方案靠其他维度高分“补回来”，这是评审中最需要避免的情形。
否决项的典型来源
- 数据出境与合规要求：数据必须存放在特定地域或不得离开内网。
- 等保或行业监管要求：须满足特定等级保护或行业主管部门的明确要求。
- 网络隔离条件：部署环境与现有网络架构的连通方式存在硬性限制。
- 合同与采购红线：付款方式、服务范围或供应商资质存在不可协商的条款。
否决项与高权重维度的区别
判断标准是“是否可协商”。不可协商、不满足即不可用的要求写成否决项；可以权衡、愿意用其他收益交换的偏好放入权重打分。同一因素不应同时出现在两处，否则会出现“已被否决却又参与打分”的矛盾。
否决项的表述方式
每条否决项写成可判定、可举证的句子，包含对象、条件和判定依据。例如“候选方案须支持数据存放于甲方指定机房，且提供部署架构说明作为举证材料”，而不是“安全性好”。表述完成后由安全合规与采购角色确认，避免评审中途追加。
判定流程与记录
判定由对应职责角色出具意见，矩阵负责人汇总。每条否决项记录：判定结论（通过/不通过/待补充证据）、举证材料、判定人和日期。不通过的候选方案保留在矩阵中并注明出局原因，便于事后复核，不直接从清单中删除。
打分、汇总与形成可追溯的选择记录
这一阶段把维度、权重与否决项落到具体得分和结论上。执行要点是打分有分工、汇总有计算过程、分歧回到证据、结论完整归档。
逐项打分
每个维度指定主责打分人，由其对照评分刻度给出1–5分并附证据出处；涉及多个角色的维度（如成本与合同）由采购与财务共同确认后给一个分数。打分完成后交叉复核，复核人检查分数与刻度描述是否对应。
加权汇总
计算方式为：维度得分先归一化到百分制（得分÷5×100），乘以该维度权重，逐项相加得到加权总分。汇总表同时呈现各维度原始得分和加权贡献，便于看出总分由哪些维度支撑。敏感性分析结果附在汇总表后，说明权重小幅调整后排序是否变化。
分歧处理
同一维度打分差异超过两档时，不取平均值了事，而是回到证据层面复核：核对双方引用的证据是否为同一版本、是否覆盖同一场景。证据不足的项标记为待验证，并在结论中写明该不确定性对选择的影响。
选择记录的内容结构
- 评审背景与统一口径说明（场景、时间跨度、规模假设）。
- 候选方案清单及各自对应的部署形态与版本。
- 裁剪后的维度清单、评分刻度与权重表，附权重推导说明。
- 否决项清单及每个候选的判定记录。
- 逐项得分、加权汇总与敏感性分析结果。
- 结论、保留意见与待验证事项，以及后续复核时间点。
评审过程本身也需要承载：维度讨论、权重确认、否决判定和结论审批会产生多轮文档与待办。ONES 的文档与工作项管理可用于把评审材料、打分记录和审批动作放在同一处流转，使矩阵版本与评审结论保持对应；具体使用方式按团队现有协作流程安排。
示例：一次三方案评审的矩阵填写
以下为演示情景，用于说明填写方法，数值不代表任何真实项目结论。
示例背景
某研发团队计划引入研发管理平台，评估周期三年，用户规模约500人，数据须存放在公司机房，须在四个月内上线支撑新项目。候选方案三个：A为公有云托管，B为私有化本地部署，C为私有化高可用集群部署。
维度、权重与否决项
裁剪后保留五个维度：合规与安全（30%）、数据主权与网络条件（20%）、集成与迁移（15%）、运维与人力（15%）、成本与合同（20%）。交付周期因三个方案均能在四个月内完成，降级为待验证项不参与打分。否决项两条：数据须存放于公司指定机房；须提供部署架构说明作为举证材料。方案A因数据存放位置不满足第一条否决项出局，不进入打分。
打分与汇总
| 维度（权重） | 方案B得分 | 方案B加权 | 方案C得分 | 方案C加权 |
|---|---|---|---|---|
| 合规与安全（30%） | 4 | 24 | 4 | 24 |
| 数据主权与网络条件（20%） | 5 | 20 | 5 | 20 |
| 集成与迁移（15%） | 4 | 12 | 3 | 9 |
| 运维与人力（15%） | 3 | 9 | 2 | 6 |
| 成本与合同（20%） | 4 | 16 | 3 | 12 |
| 加权总分 | — | 81 | — | 71 |
敏感性检查：将运维与人力权重上调5个百分点、成本与合同下调5个百分点，方案B仍领先，排序不变。
结论与保留意见写法
结论可写为：“建议选择方案B。方案A因数据存放位置不满足否决项出局；方案C在集成与运维维度得分较低，加权总分低于方案B，且在权重小幅调整后排序不变。保留意见：方案B的高可用能力需在实施阶段单独评估，交付周期待供应商确认实施计划后复核。”结论中同时写明出局原因、得分依据和待验证事项，便于后续复核。
完成检查：矩阵可用与否的核验清单
矩阵进入决策前和形成结论后各做一轮检查，可以提前发现大多数返工原因。
评审前检查
- 候选方案清单已封版，每个候选写到部署形态与版本粒度。
- 统一口径说明已书面化，所有打分人引用同一份。
- 维度经过裁剪，无重复计分项，每个维度有可观察的评分刻度。
- 权重有推导说明，合计为100%，已经跨部门确认。
- 否决项可判定、可举证，已由对应职责角色确认。
评审后检查
- 每个得分都有证据出处，待验证项已单独标注。
- 打分差异超过两档的项有复核记录和处理结论。
- 敏感性分析已完成，排序变化情况已写明。
- 结论与权重逻辑一致，保留意见和后续复核时间点齐全。
常见失效情形
维度堆砌导致表格庞大但无人能解释权重；权重由单一部门拍定，评审会上被推翻；否决项在打分后追加，使已完成的评分作废；证据缺失仍给出确定结论，事后无法复核。出现其中任一情形，矩阵应退回对应步骤修正后再进入决策。
常见问题
候选方案在评审中途新增，矩阵需要怎么处理？
新增候选须重新走一轮口径确认：先核对它是否与已封版候选使用同一套业务场景、时间跨度、用户与数据规模假设，再补齐证据来源，然后才进入维度打分与否决判定。已完成的评分不因新增候选而作废，但汇总表和敏感性分析需要重算，结论中注明新增时间和原因。若新增候选触碰已确认的否决项，直接在矩阵中记录出局原因，不进入打分环节。
权重已经跨部门确认，评审会上有人要求调整怎么办？
先判断调整理由属于哪一类：如果是发现了新的硬约束，应转为否决项处理，而不是调高某个维度的权重；如果是对优先级判断有分歧，回到权重推导说明，核对业务目标和关键约束是否发生变化。理由成立时按变更处理：更新权重表、重算汇总、重做敏感性分析，并在记录中写明变更前后结论是否改变。理由不成立时保留原权重，把分歧写入保留意见，避免会上临时拍定。
敏感性检查具体怎么做，调整幅度多大合适？
做法是对权重较高或候选得分差距较小的维度做小幅调整，例如上下浮动5个百分点，同时保持权重合计为100%，然后重算加权总分，观察候选排序是否变化。排序不变说明结论对该维度不敏感；排序翻转说明该维度是结论的关键支撑，需要补充证据或重新讨论权重依据。调整幅度没有统一标准，可按本次评审对权重精度的要求确定，并把每次调整的数值和结果一并记录，便于复核。
证据不足的维度是直接剔除还是保留？
按维度裁剪规则处理：与本次决策无关的维度剔除；与决策相关但暂时无法取得证据的维度降级为待验证项，不参与当期打分，在结论中列为前置条件并约定复核时间点。降级不等于删除，待验证项仍保留在矩阵中，后续取得证据后可补打分并更新结论。需要避免的是证据缺失仍凭印象给分，这会让结论在事后复核时失去依据。
评审结论形成后，后续还需要做哪些复核动作？
结论归档时同步写明保留意见和待验证事项，并为每项约定复核时间点和责任人。进入实施阶段后，重点复核两类内容：一是待验证项是否取得证据、结论是否需要修正；二是实施过程中出现的条件变化（如交付周期、资源要求）是否触碰原否决项。复核结果追加到原选择记录中，保持版本对应，不另起一份新文档覆盖原结论。
