需求评分权重解决的是“多个需求争同一批资源时，按什么顺序做”的问题。可行做法是：先选少数几个与当前业务目标直接相关的评分维度，为每个维度分配权重并统一打分刻度，用加权总分排序，再用一批已有结论的历史需求回测权重是否合理。本文按建模、定权重、设刻度、算分排序、分工、示例、校准、检查的顺序，给出一套可直接落地的方案。
要点总览（TL;DR）
- 需求评分模型由评分维度、权重、打分刻度、计算与排序规则四部分构成，缺一项结果就难以复用。
- 维度从当前阶段业务目标反推，数量控制在4–6个；权重用团队共识、成对比较或历史数据校准确定，合计归一为100%。
- 打分刻度统一为1–5分，每个维度的每个分值写锚点描述；成本、风险等反向维度固定一种处理方式，正向化或扣减二选一。
- 加权总分按Σ（维度得分×权重）计算，同分按预设次级规则排序，排序结果经评审组人工复核并记录调整理由。
- 权重需用已有结论的历史需求回测，调整与阶段目标变化绑定，保留版本、审批和生效范围记录。
需求评分权重由哪几部分组成
一套能重复使用的需求评分模型由四部分构成：评分维度、权重、打分刻度、计算与排序规则。四者缺一，评分结果就会变成一次性讨论，换个人、换一批需求就无法复用。评分对象是需求条目本身，用于决定先做哪个需求，不涉及功能模块如何布局，也不涉及任务层面的执行顺序。
| 构成部分 | 作用 | 常见取值 | 缺失后果 |
|---|---|---|---|
| 评分维度 | 定义从哪些角度衡量一个需求 | 业务价值、战略匹配、紧迫性、实现成本、风险 | 打分凭印象，不同人关注点不一致 |
| 权重 | 表达各维度在当期目标中的相对重要程度 | 各维度占比合计归一为100% | 所有维度等权，无法体现阶段重点 |
| 打分刻度 | 统一分值区间与每个分值的含义 | 1–5分，每档写锚点描述 | 同一需求不同人打出差异很大的分 |
| 计算与排序规则 | 把各维度得分合成一个可排序的总分 | 加权求和，同分设次级规则 | 有分无排序，或排序结果无法解释 |
维度选择上，价值类维度（业务价值、战略匹配）回答“值不值得做”，成本与风险类维度回答“做起来代价多大”，紧迫性回答“晚做会不会出问题”。维度数量建议控制在4–6个，维度越多，打分耗时越长、重叠概率越高。成本、风险这类反向维度需要在模型里明确处理方式，否则会出现“成本越高得分越高”的错误排序。
第一步：确定评分维度与权重分配
维度从当前阶段的业务目标反推，而不是照搬通用清单。如果本阶段目标是提升付费转化，转化相关价值应占较高权重；如果目标是稳定存量客户，紧迫性和风险规避的权重应上调。做法是先由产品负责人列出候选维度，再逐条回答“这个维度能否区分出两个需求谁更该先做”，区分不出来的维度删掉。
权重分配有三种常用方法，可按团队成熟度选择：
- 团队共识讨论：产品、业务、研发各出代表，对候选维度两两比较“哪个更重要”，汇总后折算占比。适合首次建模，耗时约一到两次会议。
- 成对比较法：把维度两两配对逐对判断重要程度，用比较结果计算权重，减少讨论中被声音大的人带偏。适合维度在5个以上时使用。
- 历史数据校准：取一批已上线且有结论的需求，看哪些维度最能解释“实际做对了”，据此调整权重。适合已有一定需求积累的团队。
无论用哪种方法，权重合计需归一为100%，并在文档中写明每个权重数值的确定依据，例如“业务价值40%，因本季度目标是转化率提升”。同时检查维度之间是否重叠：把“用户价值”和“业务价值”同时列入，容易对同一件事重复计分，应合并为一个维度或明确各自边界，例如一个衡量用户侧收益、一个衡量收入侧收益。
第二步：设定打分刻度与评分规则
刻度建议统一为1–5分，并为每个分值的每个维度写出锚点描述。锚点是让打分可重复的关键：没有锚点时，“业务价值4分”在不同人眼里含义不同；有锚点时，4分对应“影响核心流程、覆盖多数活跃用户”这类可判断的描述。
| 分值 | 业务价值（示例锚点） | 实现成本（反向维度示例） |
|---|---|---|
| 5 | 直接影响核心收入或核心流程 | 工作量很小，现有能力可直接覆盖 |
| 4 | 影响主要用户群的关键体验 | 工作量较小，少量改造即可 |
| 3 | 影响部分用户的体验或效率 | 工作量中等，需要跨模块配合 |
| 2 | 影响少数用户，有替代方案 | 工作量较大，需要新增模块 |
| 1 | 影响面很小，可延后 | 工作量大，涉及架构调整 |
反向维度有两种处理方式：一是先正向化再计入，即把“成本低”作为得分方向，成本越低分越高；二是把成本、风险作为扣减项，从价值总分中减去。两种方式选一种并在模型中固定，不要混用。多人打分时，约定取整或平均规则：通常各评委独立打分后取算术平均，保留一位小数；分歧超过2分的条目，由提出人补充信息后重新打分，而不是简单折中。
第三步：计算加权得分并排序
加权总分公式为：总分 = Σ（维度得分 × 维度权重）。以四个维度为例，权重分别为业务价值40%、战略匹配20%、紧迫性20%、实现成本20%（成本已正向化），某需求得分为5、4、3、2，则总分为5×0.4 + 4×0.2 + 3×0.2 + 2×0.2 = 2.0 + 0.8 + 0.6 + 0.4 = 3.8分。计算过程应保留在评分表中，便于复核时追溯每个分值的来源。
同分情况需要预设次级规则，常见做法依次比较：业务价值维度得分、战略匹配维度得分、提出时间先后。次级规则要在评分前确定，避免同分时临时争论。排序结果是决策输入而非最终结论：评审组对排序靠前但存在依赖阻塞、合规要求或客户承诺的需求进行人工复核，复核调整需写明理由并记录，不能直接改分掩盖分歧。
每条需求至少记录以下字段：需求编号、名称、各维度得分、加权总分、排名、打分人、打分日期、复核结论与调整理由。字段齐全，下一轮评分才能对比和追溯。
角色分工与各环节交付物
评分机制能否运转，取决于每个环节有人负责、有明确产出。角色不必多，但要分清谁提供信息、谁打分、谁定权重、谁复核。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 需求提出人 | 提交需求并说明业务背景、影响范围、期望时间 | 业务问题、用户反馈、客户诉求 | 需求描述与背景材料 |
| 产品负责人 | 维护评分模型，组织打分，汇总排序结果 | 需求清单、评分模型、历史评分记录 | 评分表、排序结果、评审材料 |
| 业务方代表 | 从业务收益角度打分，确认价值类维度锚点 | 业务目标、收益预估 | 价值维度得分与依据 |
| 研发代表 | 评估实现成本与技术风险 | 技术方案初判、依赖关系 | 成本与风险维度得分 |
| 评审组 | 复核排序结果，处理同分与例外，审批权重调整 | 评分表、排序结果、调整申请 | 复核结论、权重变更记录 |
权重调整由产品负责人发起、评审组审批，变更需记录调整原因、生效时间和影响范围。评分表本身作为过程交付物归档，与需求条目关联保存，保证后续能回答“这个需求当时为什么排在这个位置”。
示例：一批需求的评分与排序
以下为演示情景，用于说明计算过程，数值不代表任何真实团队结论。某团队当期权重为业务价值40%、战略匹配20%、紧迫性20%、实现成本20%，四个需求打分如下：
| 需求 | 业务价值 | 战略匹配 | 紧迫性 | 实现成本（正向化） | 加权总分 | 排名 |
|---|---|---|---|---|---|---|
| A 支付流程简化 | 5 | 4 | 4 | 3 | 4.2 | 1 |
| B 报表导出优化 | 3 | 3 | 5 | 4 | 3.6 | 2 |
| C 消息通知改版 | 3 | 4 | 3 | 4 | 3.4 | 3 |
| D 历史数据清理 | 2 | 2 | 4 | 5 | 3.0 | 4 |
计算过程以A为例：5×0.4 + 4×0.2 + 4×0.2 + 3×0.2 = 2.0 + 0.8 + 0.8 + 0.6 = 4.2。B与C相差0.2分，排序清晰；若出现同分，按预设规则先比业务价值得分。评审讨论中，D虽然排名靠后，但涉及合规期限，评审组将其提前并记录理由，这属于人工复核对排序的合理修正，而非改分。示例的边界在于：权重和锚点均为演示设定，实际团队需按自身目标重新确定，且打分依赖提出人提供的信息质量，信息不足时分数仅供参考。
权重校准与定期复核
权重定好之后需要用数据验证。做法是取一批已有结论的历史需求——已上线并验证有效果的、被否决的、延期后出问题的——用当前模型重新打分排序，对比模型排序与已知结论是否一致。若多个高价值需求被排到后面，说明价值类维度权重偏低或锚点描述有偏差；若大量低成本需求排到前面而业务收益不明显，说明成本维度权重过高。
调整时机通常与阶段目标变化绑定：季度目标切换、重大客户承诺、合规要求变化时复核一次，平时不必频繁改动。每次调整保留版本号、生效日期和变更说明，新旧版本评分不直接混排比较。频繁改权重会让不同批次需求得分失去可比性，也会让打分人对模型失去信任，因此调整应有审批、有记录、有明确生效范围。
评分结果需要落到需求条目上才能支撑排序与追溯。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，并提供业务、产品经理与研发团队三个视角，需求池与看板可实时同步状态、追溯需求来源；评分字段的具体配置以实际产品为准。当评分表、排序结果和复核记录都挂在需求条目上，回测和复核时可以直接取数，不必再从散落的表格里拼凑。
完成检查：评分机制是否可用
投入使用前逐项核对以下条目，全部满足即可认为机制可用；有未满足项，先补齐再上线。
- 评分维度已确定且数量控制在合理范围，维度之间边界清晰，没有对同一件事重复计分。
- 每个维度的权重已归一为100%，并写明确定依据和适用阶段。
- 打分刻度统一，每个维度的每个分值都有可判断的锚点描述。
- 反向维度（成本、风险）的处理方式已固定，正向化或扣减二选一。
- 多人打分的取整或平均规则、分歧处理规则已写入说明。
- 加权公式、同分次级规则已确定，评分表保留完整计算过程。
- 每条需求记录了打分人、打分日期、总分、排名和复核结论。
- 权重调整有发起人、审批人和变更记录，版本可追溯。
- 已用一批历史需求完成回测，排序结果与已知结论的偏差在可接受范围。
- 评分结果实际用于需求排序决策，评审复核有记录，而非评完即归档。
常见问题
团队第一次建评分模型，维度选几个比较合适？
建议从4–6个起步。维度太少，价值、成本、紧迫性混在一个维度里，打分人只能凭整体印象给分；维度太多，打分耗时上升，相近概念容易重复计分。可以先列出候选维度，逐条问“这个维度能否区分两个需求谁更该先做”，区分不出来的删掉。首轮运行一两个评分周期后，再根据回测结果决定是否增删。
业务方和研发对同一个需求的分数分歧很大，怎么处理？
先看分歧出在哪个维度。价值类维度分歧，通常是对影响范围的判断不同，由需求提出人补充用户量、收入影响等事实后重新打分；成本类维度分歧，由研发给出方案初判和工作量区间。约定分歧超过2分的条目重新打分，而不是取中间值折中。若补充信息后仍无法收敛，把分歧写入评审记录，由评审组在排序复核时一并处理。
权重多久调整一次，调整后旧需求的分数还能直接比较吗？
调整时机与阶段目标变化绑定，例如季度目标切换、重大客户承诺或合规要求变化时复核一次，平时保持稳定。调整后新旧版本评分不宜直接混排比较，应保留版本号、生效日期和变更说明，需要对比时用新权重对在途需求重新计算。频繁改权重会让不同批次得分失去可比性，也会削弱打分人对模型的信任。
评分排序出来后，评审组还能调整顺序吗？
可以，但要区分调整和改分。排序结果是决策输入，遇到依赖阻塞、合规期限、客户承诺等情况，评审组可以调整顺序，同时写明理由并记录在需求条目上。直接修改维度得分来让结果符合预期，会破坏模型的可追溯性，后续回测也失去意义。调整记录积累下来，还能反过来提示哪些维度或锚点需要修订。
评分结果记在哪里，才能支撑后续回测和追溯？
评分表需要和需求条目关联保存，至少记录需求编号、各维度得分、加权总分、排名、打分人、打分日期和复核结论。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，需求池与看板可实时同步状态、追溯需求来源，评分字段的具体配置以实际产品为准。记录挂在需求条目上，回测时可以直接取数，不必再从散落的表格里拼凑。
