需求价值评估表的设计，核心是把“价值”拆成少数几个可判断的维度，为每个维度写清分档描述和打分口径，再配套权重、门槛规则与评审角色。一张可用的表通常包含需求标识与背景、价值维度、成本维度、评分与权重、优先级结论、评审记录与复核时间。本文按用途界定、字段结构、搭建步骤、角色分工、填写示例和验收检查的顺序展开，示例中的需求与评分均为演示情景。
要点总览（TL;DR）
- 评估表先写清用途：回答哪一类排序问题、输出什么结论、在什么节点使用，再决定字段。
- 字段分四组：需求信息、价值维度（三到四项）、成本维度（两到三项）、结论与记录；权重总和100%，单项不超过40%。
- 分档描述要写出可观察的判断依据，用两位评分者对同一需求打分差距不超过一档来检验口径是否清晰。
- 搭建按五步走：定维度与权重、写分档锚点、设计表格与填写说明、用历史需求回测、发布并约定维护责任。
- 评审必须产出优先级结论和理由，只有分数没有结论视为评审未完成；发布前用验收清单逐项核对。
先定用途：这张表要支撑哪类排序决策
评估表的第一项设计工作，是写清它服务哪一类决策。需求价值评估表处理的是“多个需求之间先做哪个”的排序问题，输出的是需求对象的优先级结论或排序清单。产品功能布局讨论的是功能之间如何组合、哪些功能构成完整方案；任务执行顺序讨论的是已确定的需求如何拆解排期。这两类问题各有自己的分析材料，混入评估表会让字段越加越多，评分却无法收敛到取舍结论。
用途说明建议控制在一页，包含三项内容：决策问题、输出物、使用节奏。决策问题写成一句可回答的话，例如“下季度进入开发的需求按什么顺序排列”。输出物明确到具体形式，是优先级分级结论、排序清单，还是资源冲突时的取舍依据。使用节奏说明评估在什么节点发生，例如季度规划前集中评估一次，月中只处理新增的紧急需求。
| 用途要素 | 需要写清的内容 | 填写示例 |
|---|---|---|
| 决策问题 | 这张表回答哪一个取舍问题 | 下季度研发资源有限时，哪些需求优先进入开发 |
| 输出物 | 结论以什么形式交付给谁 | 按优先级分档的需求清单，附评分与评审依据 |
| 使用节奏 | 评估在什么节点、以什么频率发生 | 季度规划集中评审，月中新增需求走快速评估 |
用途确定后，还要约定“只打分不决策”的防线：每次评审必须产出明确的优先级结论或取舍记录，评分只作为讨论依据。若一次评审结束时只有分数没有结论，说明用途说明中的输出物定义还不够具体，需要回到这一页补充。
核心答案：评估表的字段结构与评分口径
字段结构分为四组：需求信息、价值维度、成本维度、结论与记录。价值维度建议控制在三到四项，成本维度两到三项，维度过多会让评分者难以稳定判断，也会拉长评审时间。
| 字段组 | 字段 | 填写要求 |
|---|---|---|
| 需求信息 | 需求编号、名称、提出方、提出日期 | 唯一编号，便于回测与追溯 |
| 需求信息 | 背景与目标 | 说明当前问题、期望达成的结果，不超过三句话 |
| 价值维度 | 业务收益 | 按收入影响、成本节约或关键业务指标改善分档 |
| 价值维度 | 用户影响 | 按受影响用户范围与影响程度分档 |
| 价值维度 | 战略契合 | 按与既定目标的对应关系分档 |
| 价值维度 | 合规与风险 | 按是否涉及合规要求、风险暴露程度分档 |
| 成本维度 | 研发投入 | 按人天区间分档，由技术负责人评估 |
| 成本维度 | 依赖与不确定性 | 按外部依赖数量、技术不确定性分档 |
| 结论与记录 | 加权总分、优先级结论 | 按公式计算，结论写明档位与理由 |
| 结论与记录 | 评审记录、复核时间 | 记录参与角色、分歧点与下次复核日期 |
分档描述是评分口径的关键。每一档都要写出可观察的判断依据，避免“较高”“一般”“较弱”这类无法对齐的表述。以业务收益为例，可以写成：5分对应直接影响合同签订或续约；3分对应改善关键业务指标但无直接收入关联；1分对应体验优化、无量化指标。分档数量建议三到五档，档位过多时相邻档难以区分。
权重设置遵循两条规则：权重总和为100%，单项权重不超过40%，防止单一维度主导结论。总分按加权求和计算，成本维度可以作为减分项，也可以单独列出，由评审会结合价值分综合判断。门槛规则用于处理特殊情况，例如涉及合规要求的需求直接进入高优先级，不参与常规排序；研发投入超过约定上限的需求需要单独评审。门槛规则要写进表格说明，并在评审时逐条核对。
操作步骤：从零搭出一张评估表
搭建过程分五步，每步都有明确的输入、动作、输出和完成标志。
第一步：确定评估维度与权重。输入是用途说明和近期的需求清单；动作是召集产品、业务、技术三方各提出候选维度，合并同类项后保留三到四个价值维度和两到三个成本维度，并商定权重；输出是维度与权重清单；完成标志是三方对维度和权重无异议，且权重总和为100%。
第二步：编写分档描述与打分锚点。输入是维度清单；动作是为每个维度写出三到五档描述，每档配一个具体判断依据或示例；输出是分档说明文档；完成标志是任意两位评分者依据描述对同一需求打分，结果差距不超过一档。
第三步：设计表格结构与填写说明。输入是分档说明；动作是把字段排成表格，标注哪些字段由谁填写、哪些字段自动计算，并写一页填写说明；输出是可填写的表格模板和填写说明；完成标志是未参与设计的人能独立填完一张表。
第四步：用历史需求回测校准。输入是过去一到两个周期已决策的需求及其实际结果；动作是按新表重新打分，与当时的实际优先级对比，找出偏差大的维度并调整分档或权重；输出是回测记录和修订后的表格；完成标志是回测中大部分需求的排序与实际结果方向一致，偏差项有明确解释。
第五步：发布并约定维护责任。输入是定稿表格；动作是明确发布范围、指定维护人、约定复核周期；输出是发布通知和维护责任说明；完成标志是维护人确定，下一次复核日期已写入表格。
角色与交付物：谁填、谁评、谁定
评估流程涉及四类角色，各自承担不同的填写与判断职责，避免所有字段由一人包办。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求提出方 | 填写需求标识、背景与目标，说明期望结果 | 完整的需求背景描述 |
| 业务或产品负责人 | 评估业务收益、用户影响、战略契合等价值维度 | 价值维度评分及判断依据 |
| 技术负责人 | 评估研发投入、依赖与不确定性 | 成本维度评分及技术风险说明 |
| 评审会 | 汇总评分，处理分歧，形成优先级结论 | 优先级结论、评审记录、复核时间 |
评审会的产出要落到书面：结论写明档位和理由，分歧点记录在案，便于后续复核时对照。评审记录同时承担“避免只打分不决策”的作用，没有结论和理由的记录视为评审未完成。评估表落地到日常协作时，可以把这些字段和评审状态放在需求工作项上管理。ONES 的需求管理工作项支持自定义字段与状态流转，团队可将评分字段、评审结论和复核时间随需求一起记录，评审结论与需求条目保持对应，减少表格在多个文件间流转造成的版本不一致。具体字段配置方式以团队实际使用的版本为准。
示例：一张填好的需求价值评估表
以下为演示情景：某团队收到需求“为订单页面增加批量导出功能”，用于说明填写方式，数据不代表真实项目。
| 字段 | 填写内容 |
|---|---|
| 需求编号与名称 | REQ-021 订单页面批量导出 |
| 提出方 | 客户成功团队 |
| 背景与目标 | 多个客户每月手工整理订单数据，耗时较长；目标是将整理时间缩短一半以上 |
| 业务收益（权重30%） | 4分：影响多个存量客户的续约意愿，无直接新增收入 |
| 用户影响（权重25%） | 3分：影响部分运营人员，使用频率为每月数次 |
| 战略契合（权重25%） | 3分：与提升客户留存的目标相关，非本季度重点方向 |
| 合规与风险（权重20%） | 2分：涉及数据导出权限控制，需评估脱敏要求 |
| 研发投入（成本） | 3分：约8人天，含权限与脱敏处理 |
| 依赖与不确定性（成本） | 2分：依赖权限模块改造，存在一定不确定性 |
| 加权总分 | 4×0.3 + 3×0.25 + 3×0.25 + 2×0.2 = 3.35 |
| 优先级结论 | 中优先级，排在本季度两个高优先级需求之后 |
| 评审记录 | 技术负责人提出脱敏要求需先行确认；产品负责人建议下季度复核 |
| 复核时间 | 下季度规划会前一周 |
总分接近时的处理方式需要在评审规则中提前约定。常见做法是依次比较战略契合分、业务收益分，仍相同则比较成本分，成本更低者优先；也可以由评审会结合当季资源情况直接裁定，并把裁定理由写入评审记录。示例中若另一个需求总分同为3.35，按上述顺序比较战略契合分即可分出先后。
完成检查：评估表是否可用的验收项
表格发布前，用以下清单逐项核对，全部通过再投入使用。
- 维度数量控制在价值三到四项、成本两到三项，每个维度都能对应到具体的判断对象。
- 每个分档都有可观察的描述或示例，通读后找不到“较高”“一般”这类无法对齐的词。
- 权重总和为100%，单项权重不超过40%，门槛规则和一票否决条件写在表格说明中。
- 存在至少一次历史需求回测记录，偏差项有调整说明。
- 维护责任人和下一次复核日期已确定并写入表格。
- 完整填写一张表并完成一次评审的耗时在团队可接受范围内，超出时优先精简维度而非降低判断标准。
- 每次评审都产出了明确的优先级结论和理由，没有出现只有分数没有结论的情况。
清单中任何一项未通过，都说明表格还需要一轮修订。修订后重新回测一次，确认调整没有破坏其他维度的判断口径，再正式发布。
常见问题
评估表的维度是不是越多越全面？
维度数量需要和评分者的判断能力匹配。价值维度控制在三到四项、成本维度两到三项，评分者才能对每个维度给出稳定判断。维度增加后，相邻维度容易重叠，评分者会在相似项上重复打分，总分被放大，评审时间也随之拉长。判断维度是否合适的简单方法，是让两位评分者独立对同一需求打分，差距超过一档就说明该维度的分档描述还不够清晰，优先修订描述而不是继续加维度。
总分相同或非常接近时怎么排序？
排序规则要在评审前写进表格说明，不能等到出现平局再临时商量。常见做法是依次比较战略契合分、业务收益分，仍相同再比较成本分，成本更低者优先。也可以由评审会结合当季资源情况直接裁定，但裁定理由必须写入评审记录，便于后续复核时对照。平局处理规则一旦确定，应在下一次回测中检验它是否与历史决策方向一致。
历史需求回测发现排序和当初决策不一致，要改表吗？
先区分偏差来源再决定是否修订。如果偏差集中在某一个维度，通常是该维度的分档描述不够具体或权重偏高，可以调整分档锚点或权重后重新回测。如果偏差分散在多个维度，可能是用途说明中的决策问题定义不清，需要回到用途页确认这张表到底服务哪类取舍。回测的目的是校准口径，不必追求与历史决策完全一致，偏差项有明确解释即可视为通过。
评估表放在文档里还是放进需求管理工具里？
取决于评估的频率和参与人数。季度集中评估、参与角色固定时，文档表格加评审记录可以满足需要。需求持续进入、评审频繁发生时，表格在多个文件间流转容易出现版本不一致，评分和结论也难以和需求条目对应。此时可以把评分字段、评审结论和复核时间放到需求工作项上管理。ONES 的需求管理工作项支持自定义字段与状态流转，团队可将这些信息随需求一起记录，具体配置方式以实际使用的版本为准。
门槛规则和一票否决条件应该写在哪里？
写在表格说明中，并在每次评审时逐条核对，不放进评分公式里。门槛规则处理的是常规排序之外的情况，例如涉及合规要求的需求直接进入高优先级、研发投入超过约定上限的需求单独评审。这类规则如果混入加权计算，会让总分失去可比性。表格说明中每条门槛规则要写清触发条件和处理方式，评审记录中注明本次是否触发，方便复核时追溯。
