评估需求价值，需要围绕“谁受益、受益多大、依据是什么、多久见效、成本多少”准备五类证据：需求来源与用户证据、业务影响数据、成本与投入估算、时间与紧迫性依据、可验证的假设与验收口径。每项证据写清来源、时间窗、分母和缺失处理，再按统一规则合成排序，并用试点或回溯结果校验评分是否可信。结论通常呈现为排序建议加证据强度标注。
要点总览（TL;DR）
- 评估需求价值需要五类证据：需求来源与用户证据、业务影响数据、成本与投入估算、时间与紧迫性依据、可验证的假设与验收口径。
- 每项证据要写清来源、统计时间窗、分母口径和缺失处理方式，未取到的数据标记为缺失，不用零代替。
- 评分时先统一量纲，再按权重加权求和，并乘以证据强度系数，最后排序并人工复核；分母为零或数据不可比时改用替代口径或暂缓排序。
- 评分是排序工具，不替代业务判断；通过已上线需求的实际效果回溯校验，并做权重敏感性分析，判断结论是否稳定。
- 评估对象限定为进入排序池的需求条目；产品功能布局归功能规划，任务执行顺序归任务优先级管理。
评估需求价值要回答哪几个问题
需求价值评估的目的是为排序提供依据，帮助团队在多个候选需求之间形成可讨论、可复核的先后顺序。它不承担证明某个需求一定成功的任务，也无法替代业务负责人对战略方向的判断。把评估目标定在“排序依据”上，可以避免为了追求精确分数而投入过多取数成本。
围绕这个目标，评估需要回答五个问题：
- 受益对象是谁：是外部客户、内部某个岗位，还是平台上的其他系统。受益对象不同，证据来源和统计口径也不同。
- 影响规模多大：涉及多少客户、多少订单、多少流程量或多少工时，需要有明确的分母。
- 影响程度多深：是解决阻断性问题、明显降低操作成本，还是体验层面的改善。
- 投入成本多少：研发人力、周期、依赖的系统改造和上线后的维护投入。
- 时效与不确定性如何：是否存在合同、合规或市场窗口带来的截止日期，关键假设是否已经验证。
评估结论建议采用“排序建议 + 证据强度”的形态。例如某个需求排在第三位，同时标注“业务影响数据完整、成本估算为区间、用户证据来自小样本访谈”。这样评审时既能讨论顺序，也能看到哪些结论建立在薄弱证据上，需要补充取数或降级处理。
需求价值评估的指标与范围怎么定
评估对象应限定为进入排序池的需求条目，并明确每个条目的边界：包含哪些功能点、服务哪些用户、在什么时间范围内生效。边界不清的需求会在取数时反复扩大范围，导致不同需求之间无法比较。建议在评估前由需求提出人写清一句话范围描述，评审时确认后再进入打分。
指标可以按五组组织，与前述五个问题对应：
| 指标组 | 典型指标 | 作用 |
|---|---|---|
| 用户价值 | 受影响用户数、反馈频次、任务完成时间变化 | 衡量谁受益、受益面多大 |
| 业务价值 | 受影响订单量、流程量、金额、客户数 | 衡量对业务结果的影响规模 |
| 成本投入 | 研发人力、周期、依赖改造、维护投入 | 衡量取得价值需要付出多少 |
| 时效性 | 截止日期来源、窗口期长度 | 衡量延迟的代价 |
| 风险与不确定性 | 关键假设验证状态、合规约束、技术风险 | 衡量结论可信度和潜在损失 |
指标数量建议控制在每组两到四个，总数不超过十五个。指标过多会稀释权重，也会让取数成本超过评估收益。权重来源应写清楚：可以来自业务目标拆解、历史回溯结果或评审共识，并在评估周期内保持稳定，避免针对单个需求临时调整权重。
范围上需要区分相邻主题。产品功能布局与功能取舍属于功能规划，评估的是功能组合是否合理；任务执行顺序属于任务优先级管理，关注的是已确定需求在迭代内的排期。本文讨论的是需求条目之间的价值排序，这两类内容不在评估范围内。
每类证据的数据口径与来源
证据的质量取决于口径是否统一。同一指标在不同需求上使用不同分母或时间窗，排序结果就失去可比性。建议为每类证据建立“证据—口径—来源”对照，并在需求条目上附上取数记录。
| 证据类别 | 需要的数据 | 口径要求 | 常见来源 |
|---|---|---|---|
| 用户证据 | 访谈记录、工单与反馈量、行为数据 | 注明样本量、统计时间窗、去重规则 | 客服工单、用户访谈纪要、产品行为埋点 |
| 业务影响 | 受影响客户数、订单或流程量、金额 | 写明分母是全部客户还是目标客群，金额是月度还是年度 | 业务系统报表、销售与运营数据 |
| 成本投入 | 研发人力、周期、依赖系统改造 | 人力按人天计，周期含评审与测试，改造项单列 | 研发负责人估算、架构评审记录 |
| 时效与风险 | 截止日期来源、合规或合同约束、不确定性 | 截止日期需注明出处，不确定性按高、中、低标注 | 合同条款、合规要求、项目计划 |
用户证据要避免只引用个别声音大的反馈。工单量需要给出统计时间窗和去重后的数量，访谈记录要注明访谈对象数量和选取方式。行为数据要说明统计的是活跃用户还是全部用户，否则“使用率”这类指标会因分母不同而失真。
业务影响数据的关键是分母。受影响客户数要说明是全部客户中的多少，订单量要说明统计周期。金额口径要统一为同一币种和同一时间单位，跨区域需求需要先换算再比较。
成本投入建议采用区间估算，并单列依赖系统改造的部分。研发人力按人天记录，周期包含评审、开发、测试和上线，避免只算开发时间导致成本被低估。
缺失值处理需要事先约定规则：未取到的数据明确标记为“未取到”，不用零代替；能给出区间的给区间；无法量化的降级为定性证据，并在证据强度中体现。分母为零的情况单独处理，例如某需求面向新客群、当前没有存量订单，应改用目标客群规模或试点数据作为替代口径，并注明这是替代证据。
这些证据需要被稳定承载，才能在评审和复算时找到出处。ONES 可以承载需求条目，并通过 Wiki 页面、附件和项目数据保留取数记录与评审结论，使证据与需求条目保持关联；具体字段结构和关联方式以实际配置为准。
从证据到排序：计算与评估步骤
拿到证据后，需要把不同量纲的数据换算为可比分值，再按权重合成。以下步骤可以复算，也便于在评审中逐项检查。
步骤一：统一量纲。把金额、人数、频次分别换算为0到1之间的分值。常用方法是极值归一化：某需求分值 =（该需求数值 − 候选集中最小值）÷（候选集最大值 − 最小值）。如果候选集中最大值等于最小值，该指标全部记为0.5，并标注“该指标无区分度”。
步骤二：加权求和。综合得分 = Σ（指标分值 × 指标权重），权重之和为1。权重由业务目标拆解或历史回溯确定，并在评估周期内固定。
步骤三：证据强度调整。为每个需求标注证据强度系数，例如证据完整取1.0，部分缺失取0.9，主要依赖定性证据取0.8。调整后得分 = 综合得分 × 证据强度系数。系数取值应在团队内事先约定，不能针对单个需求临时设定。
步骤四：排序与复核。按调整后得分从高到低排序。得分相同或差距小于约定阈值时，视为并列，交由业务负责人结合战略方向判断。排序结果需要人工复核，重点检查高分需求是否依赖单一指标、低分需求是否因数据缺失被低估。
当分母为零或数据不可比时，不强行计算。可以改用替代口径并标注，或者将该需求列为“证据不足、暂缓排序”，先补充取数再进入下一轮评估。
一个可复算的评估例子
以下为演示情景，用于说明计算过程，数值为假设值。假设排序池中有三个需求：A为订单导出功能，B为报表加载速度优化，C为移动端审批入口。
取数结果如下：A影响客户120家，月订单量8000单，成本估算60人天；B影响客户300家，月订单量20000单，成本40人天；C影响客户80家，月订单量3000单，成本25人天。用户证据方面，A有工单45条，B有工单20条，C有访谈记录6份、工单12条。
先对“受影响客户数”做极值归一化：最小值80，最大值300，极差220。A得分（120−80）÷220≈0.18，B得分1.00，C得分0。对“月订单量”同样处理：最小值3000，最大值20000，极差17000。A得分（8000−3000）÷17000≈0.29，B得分1.00，C得分0。成本指标取反向分值，成本越低得分越高：A得分0，B得分（60−40）÷35≈0.57，C得分1.00。
假设权重为业务影响0.5、用户证据0.3、成本0.2，其中业务影响由客户数和订单量各占一半。A综合得分 = 0.5×（0.18+0.29）÷2 + 0.3×0.8 + 0.2×0 ≈ 0.12+0.24 = 0.36；B综合得分 = 0.5×1.00 + 0.3×0.5 + 0.2×0.57 ≈ 0.50+0.15+0.11 = 0.76；C综合得分 = 0.5×0 + 0.3×0.6 + 0.2×1.00 ≈ 0.18+0.20 = 0.38。
再叠加证据强度：A证据较完整取1.0，B用户证据样本较少取0.9，C主要依赖访谈取0.8。调整后A为0.36，B为0.68，C为0.30。排序为B、A、C。若C补充了行为数据、证据强度提升到1.0，其得分升至0.38，将超过A。这说明证据强弱会直接影响排序，评估时需要把补数计划与排序结论一起呈现。
如何解读结果并校验评估可信度
评分是排序工具，不替代业务判断。解读结果时，应先看排序，再看每个需求的证据强度和数据完整度。高分但证据薄弱的需求，适合安排小范围验证；低分但证据充分的需求，需要检查权重设置是否符合当前业务目标。
回溯校验是检验评分可信度的主要方式。对已上线需求，比较上线后的实际效果与当初评分：实际受益客户数、订单变化、成本投入是否落在估算区间内。如果多个需求的评分排序与实际效果排序差异明显，说明指标选择或权重需要调整，而不是简单认定某个需求“评错了”。
单指标不能代表全部价值。金额大的需求未必紧迫，成本低的需求未必影响面广。可以通过权重敏感性分析观察结论是否稳定：把某一指标权重上下调整一定幅度，如果排序发生大幅变化，说明结论对权重敏感，评审时应重点讨论权重依据。
证据不足时应有降级与复评机制。约定一个复评周期，例如两周内补齐关键数据后重新打分；无法补齐的，维持定性判断并标注局限。评估记录与复评结论一并保留，便于下一轮评估参考，也便于在需求上线后回溯当初的判断依据。
常见问题
需求证据不完整时，应该先补数还是先排序？
取决于缺失的是哪类证据。如果缺失的是决定排序方向的关键数据，例如受影响客户数或订单量，建议先补数再排序，或者用替代口径给出区间并标注。如果缺失的是次要指标，可以先按现有证据排序，同时把补数计划写进结论，约定复评时间。无论哪种情况，都要在需求条目上记录“未取到”的状态，避免后续复算时误以为该项为零。
权重应该由谁定，定完之后还能改吗？
权重通常由业务负责人、产品负责人和研发负责人共同确认，依据可以是业务目标拆解、历史回溯结果或评审共识。权重应在评估周期内保持稳定，避免针对单个需求临时调整。如果业务目标发生明显变化，可以在新一轮评估开始前统一调整权重，并保留调整记录，便于回溯时理解排序变化的原因。
评分排序和业务负责人的判断不一致时怎么处理？
先检查差异来源：是权重设置与当前业务目标不匹配，还是某个需求的证据强度被低估或高估。可以把争议需求的取数记录和计算过程摆出来逐项核对。如果核对后评分仍然与业务判断冲突，可以由业务负责人说明战略层面的考虑，并在评估记录中注明“人工调整及理由”。评分的作用是提供可讨论的依据，最终排序仍由业务负责人确认。
小团队没有专门的数据分析人员，怎么降低取数成本？
可以控制指标数量，每组保留两到三个最容易取到的指标，总数控制在十个以内。优先使用已有系统里的报表数据，例如工单量、订单量、客户数，减少专门取数。用户证据可以用近期访谈纪要和客服反馈替代大规模调研，但要注明样本量和时间窗。成本估算由研发负责人给出区间即可，不必追求精确到人天。评估流程先跑通一轮，再根据实际使用情况补充指标。
需求上线后回溯发现评分不准，应该怎么调整？
先区分是指标选择问题还是权重问题。如果多个需求的实际效果排序与评分排序差异明显，检查指标是否覆盖了真正影响业务结果的因素；如果只是个别需求偏差，检查该需求的证据强度和取数口径。调整时一次只改一类因素，保留调整前后的评分记录，下一轮评估再观察效果。回溯的目的是让评分方法逐步贴近实际，不必因为一次偏差就推翻整套规则。
