需求评分权重决定了一条需求在排序表里能拿到多少分，也决定了团队对“先做什么”的判断是否一致。确定权重可以按三步走：先从业务目标推导出3–6个评估维度，再按各维度对当前阶段目标的贡献分配初始权重并归一化到100%，最后用历史需求回测和评审校准。本文面向需要为需求对象排序建立评分表的团队，给出维度来源、数值分配、角色分工、校准机制和一张可直接参照填写的示例表。
要点总览（TL;DR）
- 需求评分权重按三步确定：从业务目标推导3–6个评估维度，按各维度对当前阶段目标的贡献分配初始权重并归一化到100%，再用历史需求回测和评审校准。
- 维度要区分价值类与成本/风险类，成本与风险类采用减分方向，并在表头写明，避免算分时出现符号错误。
- 权重粒度保留整数或5%即可，核心维度30%–50%、次要维度10%–20%，低于5%的权重位考虑合并或删除。
- 产品负责人提出维度与初始权重，业务、技术、运营代表评审，需求评审会确认版本并留档，打分人记录依据，复核人定期检查排序是否偏离目标。
- 权重表上线前逐项核对维度覆盖、权重合计、评分锚点、试打结果和复核约定，全部通过后再作为需求评审的固定输入。
先定维度：需求评分权重从哪些评估项来
权重的起点是维度，维度选错，后面的数值再精细也无法反映真实优先级。维度应当从团队当前阶段的业务目标推导，而不是照搬其他团队的评分模板。常见的维度来源有四类：业务目标（这条需求对季度或年度目标的直接贡献）、成本约束（研发投入、交付周期、维护负担）、风险与合规（安全、合规、稳定性影响）、用户价值（目标用户的使用频率、满意度或留存影响）。从这四类来源中筛选，通常能得到一份候选清单。
维度数量建议控制在3–6个。维度太少，评分无法区分需求之间的差异；维度太多，每条需求的权重被稀释到5%以下，单项打分的误差会相互抵消，总分反而失去区分度。一个实用的判断方法是：如果某个维度在评审会上从未引发过争论，它可能不值得单独占一个权重位，可以并入相近维度。
每个维度必须配一条可判断的评分口径，否则不同人打出的分数无法比较。口径通常用1–5分锚点描述，例如“用户价值”可以定义为：1分=仅个别用户提及，3分=覆盖一个主要用户群体的高频场景，5分=影响核心用户的主流程。锚点要写成可观察的事实描述，避免“很重要”“比较重要”这类主观措辞。
维度还需要区分方向。价值类维度（用户价值、业务收益）分数越高代表越应优先；成本与风险类维度分数越高代表代价越大，在加权计算时应做减分处理，或在评分口径中反向定义（成本越高得分越低）。把方向在维度定义阶段就写清楚，可以避免后续算分时出现符号错误。
这一步的交付物是一份候选评估维度清单，每个维度包含名称、类型（价值类或成本/风险类）、评分口径和1–5分锚点说明。清单完成后先不要分配数值，交给下一步处理。
分配初始权重：从目标排序到归一化数值
初始权重反映的是各维度对当前阶段目标的相对重要性。做法是先按重要性给维度排序，再把排序转成数值。排序时可以问一个具体问题：如果两条需求在某两个维度上得分相反，团队更愿意按哪个维度做决定？答案指向的维度应排在前面。
把排序转成数值有两种常用方法。第一种是直接分配百分比：召集3–5名核心干系人，各自给每个维度写一个百分比，取平均值作为初始权重。第二种是成对比较：对每两个维度判断哪个更重要、重要多少（同等、略重要、明显重要），汇总后换算成权重。维度在5个以内时，直接分配百分比更快；维度之间重要性接近、难以直接给数时，成对比较更能暴露分歧。
无论用哪种方法，得到的权重都需要归一化，使合计为100%。计算方法是将每个维度的原始分值除以所有维度原始分值之和，再乘以100%。例如四个维度的原始分值为5、3、1、1，合计10，归一化后分别为50%、30%、10%、10%。
权重粒度保留整数或5%即可，不必精确到小数点。过细的权重会制造“计算很科学”的错觉，实际上打分本身的误差远大于1%的权重差异。一个可操作的参考区间是：核心维度权重在30%–50%，次要维度在10%–20%，边缘维度低于10%时可考虑删除或合并。
成本与风险类维度在权重表中单独标注方向。若采用减分制，可在总分公式中写成“价值类加权分之和减去成本类加权分”，并在表头注明。这样评审时任何人都能复算总分，减少对结果的争议。
这一步的交付物是一张初始评分权重表，包含维度名称、类型、权重、评分口径四列，权重合计为100%。
角色与交付物：谁定权重、谁打分、谁复核
权重是团队对价值判断的显式约定，需要明确谁提出、谁评审、谁执行、谁检查，否则容易出现“权重表挂在墙上、排序仍靠拍脑袋”的情况。下表给出一套常见的分工，团队可按规模调整兼任方式。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品负责人 | 提出候选维度与初始权重，解释每个维度与当前目标的关联 | 维度清单与初始权重表草案 |
| 业务、技术、运营代表 | 评审维度是否覆盖主要判断依据，权重是否与实际感受一致 | 评审意见与修改建议 |
| 需求评审会 | 确认权重版本，形成会议结论并留档 | 权重版本记录（版本号、生效日期、变更原因） |
| 打分执行人 | 按评分口径逐项打分，记录打分依据 | 单条需求的评分记录与依据说明 |
| 复核人 | 定期检查权重与排序结果是否偏离目标，发起校准 | 复核记录与校准触发说明 |
分工中有两个容易忽略的细节。其一，打分依据要随分数一起记录，例如“用户价值4分：三个客户在近两个月提出同一诉求”，这样复核时能判断分数是否合理，而不是只看一个数字。其二，权重版本记录要包含变更原因，后续追溯“为什么上季度这条需求排第一”时，版本记录是唯一可靠的依据。
当评分结果需要进入日常需求管理流程时，可以把维度、权重和得分作为需求条目的字段维护，让排序结果与需求状态在同一处更新。ONES 支持自定义需求字段与状态流转，团队可将评分表落到需求条目上，评审结论和状态变更保留在同一条记录中，便于复核人按版本回溯。具体字段配置方式以团队实际使用的产品版本为准。
校准权重：用历史需求回测与评审修正
初始权重是基于判断给出的假设，需要用数据检验。回测方法很直接：选取10–20条已经完成决策的历史需求，按新权重逐项重新打分并计算总分，把重算后的排序与当时的实际决策顺序对比。重点看两类偏差：一是重算后排名靠前、当时却被搁置的需求，检查是否某个维度权重过低；二是重算后排名靠后、当时却优先做的需求，检查是否某个维度权重过高或口径定义有误。
回测不需要追求完全吻合。历史决策本身可能受资源、时机等评分表之外的因素影响，排序存在少量差异是正常的。需要处理的是系统性失真：如果多条需求都因同一维度出现明显错位，说明该维度的权重或口径需要调整。
调整通过评审会完成，每次调整记录三件事：改了哪个维度、从多少改到多少、依据是什么。调整后重新归一化，确认合计仍为100%。避免在一次评审中同时改动多个维度，否则无法判断是哪项调整改善了排序。
复核周期建议设为每季度一次，或在业务目标发生明显变化时提前触发。目标变化包括进入新的考核周期、核心业务方向调整、合规要求更新等。复核时不必每次重算全部权重，可以先检查各维度与当前目标的关联是否仍然成立，再决定是否调整。
这一步的交付物是回测对比结果（历史需求的重算得分与实际决策对照表）和权重调整记录。两者与权重版本记录放在一起，构成完整的权重演进档案。
示例：一张需求评分权重表怎么填
以下示例用于演示填写与算分过程，权重数值仅作演示，实际使用时需按团队当前阶段目标重新分配。
假设某团队当前阶段的目标是提升核心用户的留存，同时控制交付风险。据此确定四个维度并分配权重：用户价值40%、业务收益30%、实现成本20%（减分项）、风险合规10%。合计100%，粒度均为5%的整数倍。
| 维度 | 类型 | 权重 | 评分口径（1–5分） |
|---|---|---|---|
| 用户价值 | 价值类 | 40% | 1分=个别用户提及；3分=覆盖一个主要用户群体的高频场景；5分=影响核心用户主流程 |
| 业务收益 | 价值类 | 30% | 1分=间接影响；3分=对季度目标有可量化贡献；5分=直接支撑核心指标 |
| 实现成本 | 成本类（减分） | 20% | 1分=工作量小、一周内可交付；3分=需要一个迭代；5分=跨团队、超过一个月 |
| 风险合规 | 风险类（减分） | 10% | 1分=无合规或稳定性影响；3分=需要额外评审；5分=涉及强合规要求或高风险变更 |
两条示例需求的打分与算分如下。总分公式为：用户价值×40% + 业务收益×30% − 实现成本×20% − 风险合规×10%。
| 需求 | 用户价值 | 业务收益 | 实现成本 | 风险合规 | 加权总分 |
|---|---|---|---|---|---|
| 需求A：核心流程引导优化 | 5 | 4 | 2 | 1 | 5×0.4+4×0.3−2×0.2−1×0.1=2.7 |
| 需求B：报表导出格式扩展 | 3 | 3 | 3 | 2 | 3×0.4+3×0.3−3×0.2−2×0.1=1.3 |
按总分排序，需求A优先于需求B。把结果与团队直觉对照：如果多数人凭经验也认为A更该先做，说明权重方向与团队判断一致；如果有人认为B更紧急，需要追问是哪个维度被低估，例如B是否涉及某个大客户的合同承诺，这类因素应通过调整业务收益的评分口径体现，而不是临时改总分。
示例还说明一个常见问题：成本类维度采用减分后，高分需求的总分可能明显低于价值类维度的满分之和，这是正常的，总分只用于同一张表内的相对排序，不用于跨团队比较。
完成检查：权重表可用前的核对项
权重表在正式用于需求排序前，逐项核对以下清单。任何一项不满足，先修正再上线。
- 维度覆盖：当前阶段的主要判断依据是否都有对应维度，是否存在两个维度实际在衡量同一件事。
- 权重合计：各维度权重相加是否为100%，成本与风险类维度的减分方向是否在表头写明。
- 粒度可操作：权重是否为整数或5%的倍数，是否存在低于5%的权重位需要合并或删除。
- 评分锚点：每个维度是否都有1–5分的具体描述，锚点是否用可观察的事实表述。
- 试打一轮：至少两名打分人独立对3–5条真实需求打分，比较结果差异，差异大的维度需要补充口径说明。
- 复核约定：是否明确复核周期、触发条件和变更记录方式，版本记录是否有指定维护人。
- 方向一致：用试打结果排序，检查排在前面的需求是否与团队当前目标方向一致，出现明显背离时回到维度或权重环节修正。
清单全部通过后，权重表连同版本记录一起发布，作为需求评审的固定输入。后续每次调整都沿用同一套记录方式，权重表才能成为团队可追溯、可复用的判断依据，而不是一次性的会议产物。
常见问题
团队规模很小，还需要区分定权重、打分和复核三种角色吗？
小团队可以兼任，但职责要写清楚。常见做法是产品负责人同时承担提出维度和复核，技术负责人参与评审并作为打分人之一。关键是把“谁提出、谁确认、谁记录”落到具体人，避免权重表由一人单独决定又无人复核。人数少时可以把评审合并到一次需求评审会完成，但版本记录和打分依据仍需保留，后续追溯排序原因时才有据可查。
业务目标在季度中途发生变化，权重要不要立即重算？
先判断变化是否影响维度与目标的关联。如果只是个别指标调整，可以先检查受影响维度的评分口径是否需要补充说明，权重数值暂不动；如果核心业务方向或合规要求发生变化，应触发一次校准，按回测流程调整相关维度并重新归一化。调整后记录变更原因和生效日期，避免同一季度内出现多套未标注版本的权重表混用。
回测时历史需求的排序与新权重算出的结果差异很大，说明权重错了吗？
不一定。历史决策可能受资源、时机、客户承诺等评分表之外的因素影响，少量差异属于正常。需要关注的是系统性失真：多条需求都因同一维度出现明显错位，才说明该维度的权重或口径需要调整。处理时一次只改一个维度，改完重新回测，确认排序改善后再考虑下一项，否则无法判断是哪项调整起了作用。
评分结果和评审会上大家的直觉判断不一致时，以哪个为准？
把差异当作校准线索，而不是直接否定评分表。先追问直觉判断依据的是哪个因素，例如某条需求涉及大客户合同承诺，这类因素应通过调整业务收益维度的评分口径来体现，而不是临时改动总分。如果多次出现同类差异，说明维度或口径有遗漏，回到维度清单补充。评分表的价值在于让判断依据显式化，直觉与算分长期背离时，需要修正的是表本身。
权重表确定后，评分结果在需求管理流程中怎么落地？
可以把维度、权重和得分作为需求条目的字段维护，让排序结果与需求状态在同一处更新。ONES 支持自定义需求字段与状态流转，团队可将评分表落到需求条目上，评审结论和状态变更保留在同一条记录中，便于复核人按版本回溯。具体字段配置方式以团队实际使用的产品版本为准。
