多个产品方案摆在一起时，范围大小、原型完整度和实现成本往往互相牵制，讨论容易变成各说各话。本文给出一套可落地的比较方法：先把三类取舍转成统一字段，再按固定流程取证打分，最后依据硬约束、加权得分和风险敞口做出选择，并留下可追溯的评审记录。
要点总览（TL;DR）
- 多方案比较失效的常见原因是各方案口径不一，应先把范围、交互原型、实现成本拆成有取值规则和填写责任人的字段，统一到一张比较表。
- 范围按必须交付、可延后、明确不做三档界定并对应业务目标；原型按关键路径步骤数、异常分支覆盖和验证方式记录；成本按工作量区间、外部依赖和不确定性等级记录。
- 流程按收集材料、口径校准、分角色取证、按权重打分、形成结论五步推进，每步有输入、输出和完成标志。
- 选择顺序为先筛硬约束，再算加权得分，最后标注风险敞口；得分接近时优先不确定性更低的方案，并写明理由。
- 评审记录保留比较表版本、权重、结论与未选理由，遗留问题转为待办并指定负责人和时间，后续变更回到同一张表更新。
先定比较口径：三类取舍如何转成可比字段
多方案比较失效，通常不是方案本身差，而是每个方案用不同口径描述自己：A方案说“功能齐全”，B方案说“先做核心”，C方案说“成本可控”。这些说法无法横向对照。解决办法是在评审前把范围、交互原型、实现成本分别拆成有取值规则、有填写责任人的字段，统一到一张方案比较表上。
范围字段采用三档界定，并要求每档对应业务目标。这样比较的不是“功能多少”，而是“哪些目标在哪一档被覆盖”。
| 字段 | 取值方式 | 填写责任人 |
|---|---|---|
| 必须交付范围 | 逐条列出，每条注明支撑的业务目标；缺失即视为方案不成立 | 产品负责人 |
| 可延后范围 | 逐条列出，注明延后到哪个阶段、延后对业务目标的影响 | 产品负责人 |
| 明确不做范围 | 逐条列出，注明排除理由（如目标优先级低、依赖不具备） | 产品负责人 |
| 关键任务路径步骤数 | 按主要用户任务逐步计数，标注路径起止点 | 交互设计 |
| 异常分支覆盖 | 列出已覆盖的异常场景（如失败重试、权限不足、数据为空），标注未覆盖项 | 交互设计 |
| 原型验证方式 | 注明是可用性测试、内部走查还是仅示意，附参与人数或走查结论 | 交互设计 |
| 工作量区间 | 以人天或人周给出下限与上限，注明估算依据（如类比、拆解） | 研发负责人 |
| 外部依赖 | 列出依赖的系统、团队或第三方，标注是否已确认可用 | 研发负责人 |
| 不确定性等级 | 按高/中/低标注，并写明不确定来源（如技术方案未验证、依赖方未答复） | 研发负责人 |
三类字段放在同一张表里，每个方案占一行或一组列，评审时逐格对照。字段定义和取值方式在评审前发给所有参与者，避免现场临时解释。工作量区间必须带口径，例如“不含测试与上线支持”，否则不同方案的区间不可比。
操作步骤：从方案收集到评审打分的完整流程
字段确定后，按以下五步推进。每步都有明确输入、动作、输出和完成标志，评审主持人据此控制节奏。
第一步：收集方案材料
输入为各方案的说明文档与交互原型；动作是按字段表逐项填写初稿，空缺处标注“待补”而非留白；输出为字段表初稿；完成标志是每个方案都有初稿，且空缺项已列成清单。
第二步：统一口径校准
由产品负责人主持，重点对齐两件事：范围三档的划分边界（什么算必须交付），以及成本估算单位（人天口径、是否含联调）。输入是各方案初稿，输出是口径说明与修订后的字段表；完成标志是所有方案使用同一套分档规则和估算单位。
第三步：分角色取证
设计补充原型关键路径与异常分支说明，必要时用走查或小范围测试验证；研发给出成本区间、依赖项和不确定性来源；测试与运营补充可验证性与上线影响。输入是字段表，输出是各栏填齐并附证据的版本；完成标志是三类字段无空缺，每个成本区间都有估算人和依据。
第四步：按权重打分并记录分歧
评审会前确认权重，会上对每个方案逐维度打分。分歧不强行抹平，记录分歧点、各方理由和最终取值；输出为打分表与分歧记录；完成标志是每个维度都有得分和依据，分歧项有明确处理方式。
第五步：形成选择结论与遗留问题清单
按下一节的选择规则得出结论，同时把未决事项转为遗留问题，指定负责人和时间；输出为评审结论与遗留问题清单；完成标志是结论包含选择方案、理由、主要风险，遗留问题均有归属。
角色与交付物：谁填哪一栏、谁签字确认
比较表要可信，每一栏都得有人对内容负责。角色分工按下表执行，确认方式以书面记录为准，避免评审变成某一方的单方陈述。
| 角色 | 负责栏目 | 交付物 | 确认方式 |
|---|---|---|---|
| 产品负责人 | 范围三档及业务目标对应关系 | 范围分档清单 | 评审会前提交，会上确认 |
| 交互设计 | 关键路径步骤数、异常分支覆盖、验证方式 | 原型路径与异常分支说明 | 附走查或测试记录 |
| 研发负责人 | 工作量区间、技术依赖、不确定性等级 | 成本估算说明 | 注明估算人与依据 |
| 测试与运营 | 可验证性、上线影响 | 验证要点与上线风险说明 | 会上口头补充并记入记录 |
| 评审主持人 | 权重确认、结论记录 | 权重确认记录与评审结论 | 会后发出纪要，参与者确认 |
主持人最好由不直接提出方案的人担任，减少倾向性。研发负责人对成本区间负责，但区间上下限的宽窄本身也是信息：区间越宽，说明不确定性越高，应在打分时体现。
选择依据：硬约束、加权得分与风险敞口怎么用
比较表填完后，按“先筛硬约束、再比加权得分、最后看风险敞口”的顺序做选择，三步不可颠倒。
第一步，筛硬约束。合规要求、上线时间窗口、既有系统依赖属于不可协商条件。任一方案不满足，直接排除，不进入打分。排除理由要写清楚，便于后续复盘。
第二步，算加权得分。对剩余方案按评审会前确认的权重逐维度打分。权重反映当前阶段的业务重点，例如上线时间紧时，成本与不确定性权重可适当提高；体验是核心卖点时，原型覆盖度权重提高。权重一经确认，会上不再临时调整，否则得分失去可比性。
第三步，标注风险敞口。对得分最高的方案，列出主要风险及缓解动作，例如“依赖方接口未确认——评审后一周内完成对接确认”。风险敞口过大时，即使得分领先也应重新审视。
得分接近时，优先选择不确定性更低的方案，并在记录中写明理由。这一规则的价值在于：得分差距在误差范围内时，可预测性比纸面优势更值得依赖。
示例：三个方案在同一张表上的取舍对比
以下为演示情景，用于说明字段填写与结论推导，不代表真实项目结论。
| 维度 | 方案A | 方案B | 方案C |
|---|---|---|---|
| 必须交付范围 | 覆盖全部三个业务目标 | 覆盖两个核心目标，第三个延后 | 仅覆盖一个目标 |
| 可延后/不做 | 无延后项 | 一个目标延后至下一阶段 | 两个目标明确不做 |
| 关键路径步骤数 | 主路径完整，含分支流程 | 主路径完整 | 仅示意主界面 |
| 异常分支覆盖 | 覆盖主要异常场景 | 覆盖主路径异常，边缘场景未覆盖 | 基本未覆盖 |
| 原型验证方式 | 已完成可用性测试 | 内部走查通过 | 仅示意，未验证 |
| 工作量区间 | 高，区间较窄 | 中等，区间适中 | 低，区间宽 |
| 不确定性 | 低 | 中 | 高（技术方案未验证） |
推导过程：三个方案均满足硬约束，进入打分。若当前阶段以覆盖核心目标为先，方案B在范围、原型和成本之间取得平衡，加权得分领先；方案A得分接近但成本明显更高；方案C成本最低，但原型未经验证、不确定性高，得分接近时按规则不优先。结论为选择方案B，未选理由分别记录：A为成本超出当前阶段承受范围，C为不确定性过高且范围覆盖不足。方案A中已完成的可用性测试结论可作为后续迭代的复用材料。
评审记录与协作落地：把比较结论留在可追溯的位置
评审结论如果只停留在会议口头或聊天记录里，几周后范围一变就无从对照。评审记录至少包含：比较表版本号、权重及确认时间、参与角色、各方案得分、选择结论、未选方案理由、遗留问题清单。
未选方案单独记录两点：不选的具体理由，以及可复用的部分（如已完成的原型验证结论、已确认的依赖信息）。这些内容在后续方案调整时能直接调用，减少重复工作。
遗留问题逐条转为待办，指定负责人和完成时间，并在下次评审前检查状态。后续发生范围变更时，回到同一张比较表更新对应字段，而不是另起一份文档，保证口径前后一致。
这类记录与跟踪可以借助协作工具承载。在ONES中，方案文档与评审记录可作为文档沉淀版本，遗留问题转为工作项并指派负责人与截止时间，范围变更时在同一工作项下更新状态，使比较表、结论和后续动作保持在同一处可查。
完成检查：评审结论是否可执行
评审结束前，由主持人逐项核对以下清单，全部通过才算完成。
- 每个方案的范围三档、原型字段、成本字段均已填写，无空缺或“待定”项；
- 工作量区间均注明估算口径和估算人；
- 权重在打分前已确认，并有书面记录；
- 结论包含选择方案、选择理由和主要风险及缓解动作；
- 每个未选方案都有明确的不选理由，可复用部分已记录；
- 遗留问题均有负责人和完成时间；
- 比较表已标注版本，后续变更可回溯到同一份记录。
清单中任何一项不满足，说明比较口径或取证还不完整，应补齐后再形成结论，避免把不完整的比较带入执行阶段。
常见问题
如果几个方案在评审会上才第一次放到一起，还来得及建立比较口径吗？
可以，但需要把评审拆成两段。第一段只做口径校准：由产品负责人当场确认范围三档的划分边界和成本估算单位，各方案负责人按统一字段补填，空缺处标“待补”。第二段再进入打分和结论。如果当天无法补齐研发的成本区间和依赖信息，建议先形成字段表初稿，约定补齐时间后再开结论会，避免在信息不全的情况下仓促定案。
权重由谁定、什么时候定，会上可以调整吗？
权重反映当前阶段的业务重点，建议由评审主持人与产品负责人会前商定，并在评审通知中一并发出，会上不再临时调整。原因是权重一变，各方案得分就失去可比性，讨论容易回到主观偏好。如果会上确实发现权重设置遗漏了关键约束，应记录调整原因，重新计算全部方案得分，而不是只调整个别方案。
研发给出的成本区间很宽，怎么在比较中使用？
区间宽本身就是信息，说明不确定性高。比较时可以把区间上下限同时填入表中，并在不确定性等级栏标注来源，例如技术方案未验证、依赖方未答复。打分阶段可将区间宽度作为不确定性维度的依据；如果两个方案得分接近，区间更宽的一方在可预测性上处于劣势。评审后应针对宽区间安排验证动作，缩小估算范围。
范围在评审后发生变化，之前的比较结论还有效吗？
结论的有效性取决于变更幅度。建议回到同一张比较表更新对应字段，重新核对硬约束是否仍满足、权重是否仍适用，再判断结论是否需要修订。如果变更只涉及可延后范围的调整，通常更新记录即可；如果必须交付范围或成本区间发生实质变化，应重新打分并留下修订说明，保证前后口径一致、可追溯。
未选方案的材料要不要保留，保留哪些？
建议保留两类内容：一是不选的具体理由，便于后续复盘和向相关方解释；二是可复用的部分，例如已完成的原型验证结论、已确认的依赖信息、已梳理的异常场景清单。这些材料在后续方案调整或下一轮评审时可以直接调用，减少重复工作。保留位置与评审记录放在一起，并标注对应版本。
