需求价值评估要先把“价值”拆成可计量的几个维度，再为每个维度定义口径、公式和时间窗，最后按权重合成排序分并做敏感性校验。本文给出维度清单、取数口径、排序分公式和一组可复算的算例，并说明结果在什么范围内可用、哪些情况会失真。评估对象限定为待排序的需求条目，结果服务于取舍讨论。
要点总览（TL;DR）
- 需求价值评估先把“价值”拆成收益、影响、战略与合规、成本与风险四组维度，每组选一到两个具体指标，避免同一笔收益被重复计入。
- 每个维度都要写明数据来源、责任人、单位、时间窗和分母，定性维度配评分锚点，缺失值与估算值显式标注。
- 排序分按“归一化得分×权重”加权合成，成本类维度固定用负向处理或单位投入价值其中一种，不能混用。
- 算例中三个需求按收益0.35、影响0.25、战略0.25、成本0.15加权，排序为A、B、C；零分母与真实零收益要区分处理。
- 排序分只反映既定口径下的相对位置，权重变化、估算偏差和时间窗不一致都会让结果失真，需做敏感性检查并保留口径变更记录。
评估目标：需求价值要回答什么排序问题
需求价值评估回答的是一个相对排序问题：在给定时间窗和资源约束下，若干待处理需求中，哪些应当优先进入方案设计和开发排期。评估对象是需求条目本身，交付物是一份带口径说明的排序结果，供产品、业务和技术负责人讨论取舍时使用。
这个结果与另外两类决策分工不同。产品功能布局决定产品长期提供哪些能力、功能之间如何组织，属于规划层面的判断；任务执行顺序决定已进入迭代的工作项谁先做、如何排期，属于执行层面的调度。需求价值排序处在两者之间：它筛选出值得投入的需求，为功能规划提供输入，也为后续任务排期提供依据，但不替代这两类决策。
因此评估结果应满足三个条件：同一批需求使用同一套维度和口径；每个得分可以追溯到数据来源；排序结论能说明在什么假设下成立。缺少任何一条，排序就容易变成印象投票。
指标与范围：价值维度如何拆分
维度拆分的目的是让不同需求在同一把尺子上比较，同时避免两个维度测量同一件事。建议按收益、影响、战略与合规、成本与风险四组划分，每组内再选一到两个具体指标。
| 维度组 | 具体指标 | 含义 | 适用范围 |
|---|---|---|---|
| 收益类 | 预期收入增量 | 需求上线后在时间窗内带来的新增合同额或续费额 | 有明确商业转化路径的需求 |
| 收益类 | 成本节约 | 减少的人力、外包、运维或赔付支出 | 内部流程与支撑类需求 |
| 收益类 | 效率提升 | 单位业务动作耗时的下降折算为工时 | 高频重复操作场景 |
| 影响类 | 覆盖用户数 | 受影响的活跃用户或客户数量 | 面向终端用户的需求 |
| 影响类 | 覆盖业务环节数 | 需求涉及的流程节点数量 | 内部系统与平台类需求 |
| 战略与合规类 | 目标契合度 | 与当期业务目标的关联强度 | 全部需求，需评分锚点 |
| 战略与合规类 | 合规要求 | 是否满足法规、合同或安全审计要求 | 有硬性时限的合规需求 |
| 成本与风险类 | 投入人力 | 设计、开发、测试合计人天 | 全部需求 |
| 成本与风险类 | 技术不确定性 | 方案可行性、依赖外部条件的程度 | 涉及新技术或外部集成的需求 |
拆分时注意两点。收益类三个指标只选与需求最贴近的一个作为主指标，其余作为补充说明，避免同一笔收益被重复计入。影响类指标要区分“覆盖人数”和“使用频次”，覆盖广但低频的需求与覆盖窄但高频的需求应分别归入不同指标，不能混在一个分数里比较。
数据口径与证据：每个维度怎么取数
口径的作用是让两个人在不同时间对同一需求算出接近的数值。每个维度至少写明五项：数据来源、责任人、单位、时间窗、分母。下表给出常用维度的口径模板，实际使用时按团队数据条件调整。
| 维度 | 数据来源 | 责任人 | 单位与时间窗 | 分母与缺失处理 |
|---|---|---|---|---|
| 预期收入增量 | 销售预测、合同台账 | 业务负责人 | 万元，上线后12个月 | 分母为受影响客户数；无合同依据时标注“估算” |
| 成本节约 | 财务成本科目、外包结算单 | 财务对接人 | 万元/年 | 分母为年度总成本；无数据时留空并标注 |
| 效率提升 | 操作日志、工时记录 | 流程负责人 | 人天/年 | 分母为年操作次数；次数为零时该维度记零并说明 |
| 覆盖用户数 | 埋点、账户系统 | 数据负责人 | 人，近90天活跃 | 分母为总活跃用户；新业务无数据时用试点范围估算 |
| 目标契合度 | 季度目标文档、评审记录 | 产品负责人 | 1–5分 | 按评分锚点评分，附一句证据说明 |
| 合规要求 | 法务意见、审计清单 | 合规负责人 | 是/否，附截止日期 | 无截止日期按“否”处理 |
| 投入人力 | 研发估算、历史同类需求工时 | 技术负责人 | 人天 | 按团队历史均值估算，标注估算依据 |
| 技术不确定性 | 技术预研结论、依赖方确认 | 技术负责人 | 1–5分 | 按评分锚点评分，附风险点清单 |
定性维度需要评分锚点，否则不同评审人给出的分数不可比。以目标契合度为例，可定义为：5分对应当期首要目标且是关键路径；4分对应支撑首要目标但非关键路径；3分对应次要目标；2分对应间接相关；1分对应无直接关联。每个分数要求附一句证据，例如引用目标文档中的条目编号或评审纪要。
缺失值和估算值必须显式标注。规则可以设为：定量维度缺失时该维度不参与合成，排序分按剩余维度权重重新归一；估算值在结果表中加标记，并在敏感性检查中单独观察其对排序的影响。零分母的处理要写进口径，例如效率提升维度在年操作次数为零时记零分，而不是留空，避免把“没有发生”误读为“数据缺失”。
这些口径和证据需要在团队共用的工作项与文档中沉淀，否则每次评估都要重新对齐。ONES 的需求条目可以承载字段化的取值，评审记录与口径说明可以放在项目文档中，ONES Assistant 能基于项目、工作项和 Wiki 页面等已有上下文回答问题并执行后续操作，便于在评审时快速调取历史口径。评分模型本身仍需团队自行定义，工具承担的是记录与追溯。
计算与评估步骤：从打分到排序分
合成排序分分四步：归一化、定权重、套公式、做敏感性检查。
第一步，归一化。把各维度换算到同一量纲。收益、影响类指标用极值归一化：某需求该维度得分 =（该需求取值 − 本批最小值）÷（本批最大值 − 本批最小值），结果落在0到1之间。若本批最大值等于最小值，全部记0.5，并在记录中注明。定性维度按锚点分数除以满分，例如5分制除以5。
第二步，定权重。权重来源应写明，常见做法是由产品、业务、技术三方在评估前共同确认，并按季度目标调整。权重之和为1。权重一旦确定，本批需求评估期间不再改动，改动需记录版本。
第三步，套公式。排序分 = Σ（维度归一化得分 × 维度权重）。成本类维度有两种处理方式：一是作为负向维度，用（1 − 归一化成本得分）参与加权；二是先算价值分，再用价值分除以投入人天得到单位投入价值。前者适合成本差异不大的批次，后者适合成本跨度大的批次。两种方式不能混用，需在口径中固定一种。
第四步，敏感性检查。对权重做上下浮动，例如把收益类权重提高或降低20%，重新计算排序，观察前几名是否变化。若排名对权重高度敏感，说明该批需求的价值差异不明显，应补充数据或缩小评估范围，而不是直接采用原排序。复核机制可设为：评估人出分，业务负责人核对数据来源，产品负责人确认权重版本，三方签字后结果生效。
例子：三个需求如何算出排序结果
以下为演示情景，数值仅用于说明计算过程。假设某季度有三个待排序需求：A为面向企业客户的报表导出增强，B为内部审批流程自动化，C为合规要求的日志留存改造。选取四个维度：预期收入增量、覆盖用户数、目标契合度、投入人力。权重设为收益0.35、影响0.25、战略0.25、成本0.15，成本按负向维度处理。
| 需求 | 预期收入增量（万元） | 覆盖用户数（人） | 目标契合度（1–5） | 投入人力（人天） |
|---|---|---|---|---|
| A | 120 | 800 | 4 | 60 |
| B | 0 | 300 | 3 | 25 |
| C | 0 | 0 | 5 | 40 |
归一化计算：收入维度最大值为120、最小值为0，A得1，B和C得0。覆盖用户数最大800、最小0，A得1，B得0.375，C得0。目标契合度除以5，A得0.8，B得0.6，C得1。投入人力最大60、最小25，A得1，B得0，C得0.43；负向处理后A得0，B得1，C得0.57。
加权合成：A = 1×0.35 + 1×0.25 + 0.8×0.25 + 0×0.15 = 0.80；B = 0×0.35 + 0.375×0.25 + 0.6×0.25 + 1×0.15 = 0.394；C = 0×0.35 + 0×0.25 + 1×0.25 + 0.57×0.15 = 0.336。排序为A、B、C。
这个算例包含两个边界情况。C的覆盖用户数为零，原因是该需求面向系统后台，没有直接用户，此时按口径记零并在备注中说明“后台合规需求，影响维度不适用”，而不是当作缺失值剔除。B的收入增量为零，属于真实的零收益而非数据缺失，同样记零。若把C的影响维度剔除并按剩余权重重新归一，C的得分会上升，这正是敏感性检查需要覆盖的情形。合规需求通常还带有硬性截止日期，实际评估中可将其作为前置条件单独列出，不参与加权排序。
解读与限制：结果怎么用、哪里会失真
排序分反映的是在既定维度、权重和时间窗下的相对位置，不构成对需求实际收益的因果保证。得分高的需求意味着按当前口径更值得优先讨论，不意味着上线后一定产生对应回报。
常见失真来源有四类。权重变化会直接改变排名，尤其是收益类与战略类权重接近时，前几名容易互换，因此权重版本必须记录并随目标调整。估算数据会带入偏差，投入人力和收入预测多来自经验判断，估算方与需求提出方重合时偏差更大，建议由独立角色复核。主观评分受评审人立场影响，目标契合度这类维度需要证据锚点约束。时间窗不一致会让数据不可比，例如一个需求按12个月测算收入、另一个按3个月测算，归一化后前者会被系统性高估。
复评节奏建议与规划周期对齐，例如每季度复评一次，或在需求范围、目标或关键数据发生明显变化时触发临时复评。每次复评保留口径变更记录，包括维度增删、权重调整、数据来源替换，便于解释两次排序结果为何不同。评估结果用于排序和取舍讨论，不直接作为个人或团队的绩效结论；涉及绩效时需另行设计指标和归因方法。
常见问题
需求价值评估和任务优先级管理有什么区别，两者会不会重复？
两者处理的对象不同。需求价值评估的对象是尚未进入开发的需求条目，输出的是“哪些需求值得优先进入方案设计和排期”的排序依据；任务优先级管理处理的是已经进入迭代的工作项，决定谁先做、如何排期。实际操作中，需求价值排序为任务排期提供输入，任务排期再结合人力容量和依赖关系做调整，两层判断衔接使用，不互相替代。
某个维度的数据拿不到，是留空还是记零？
要区分“数据缺失”和“真实为零”。真实为零的情况，例如需求本身不产生收入，按口径记零并在备注中说明原因；数据缺失的情况，例如新业务还没有埋点数据，该维度不参与合成，排序分按剩余维度的权重重新归一，同时在结果表中标注缺失。两种处理不能混用，否则会把“没有发生”误读为“数据缺失”，或者把缺失当成零拉低得分。
权重由谁定，评估中途能不能调整？
常见做法是由产品、业务、技术三方在评估开始前共同确认权重，并按季度目标调整，权重之和为1。权重一旦确定，本批需求评估期间不再改动；确需调整时记录版本，并在结果中注明使用的是哪一版权重。评估中途改权重会让同一批需求的得分失去可比性，也会让后续解释排序结果变得困难。
合规类需求带硬性截止日期，还要参与加权排序吗？
可以把合规要求作为前置条件单独列出，不参与加权排序。带硬性时限的合规需求通常没有讨论余地，直接进入排期；参与加权反而可能因为收益维度为零而被排到后面。算例中的C需求就属于这种情况，它的影响维度记零并在备注中说明“后台合规需求，影响维度不适用”，同时把截止日期作为独立条件标注。
排序结果能不能直接用于团队绩效考核？
不建议直接使用。排序分反映的是在既定维度、权重和时间窗下的相对位置，受估算偏差、评审人立场和权重选择影响，不构成对需求实际收益的因果保证。用于绩效时需要另行设计指标和归因方法，明确个人或团队对结果的贡献范围。评估结果更适合作为取舍讨论的输入，帮助团队解释为什么优先做某几个需求。
