3. 确定评分维度
评分维度是需求优先级模型的骨架。只有将抽象的价值、成本、风险、时间拆解为可量化、可验证的子维度，后续的加权计算才能产生有意义的排序结果。本章给出从业务目标到维度定义的完整操作规范，确保每个维度都有明确的边界、评分锚点和责任人。
1 适用场景
- 首次建立评分模型：组织尚未定义标准化的需求优先级维度，需要从零搭建。
- 模型版本迭代：已有维度不再匹配当前业务目标（如从追求增长转向控制成本），需要重构维度体系。
- 跨团队对齐：产品、技术、业务、风险等角色对“什么更重要”存在分歧，需要统一维度的定义与权重。
- 引入新品类需求：当需求类型发生重大变化（如从功能需求转向合规需求），原有维度可能失效。
2 前置条件
| # | 条件 | 验收标准 |
|---|---|---|
| 2.1 | 已收集不少于 20 条真实需求样本（含功能、非功能、业务需求） | 需求清单经 PO 签字确认 |
| 2.2 | 已明确当前阶段的业务战略目标（如营收增长、用户体验提升、技术债务清理） | 战略目标文档已评审发布 |
| 2.3 | 已组建维度定义工作组（至少包含产品经理、技术架构师、业务代表各 1 人） | 会议纪要记录成员名单及角色 |
| 2.4 | 准备评分标准模板（1‑5 级 Likert 量表或 0‑100 连续分值） | 模板已导入协作平台 |
提示：前置条件中“需求样本”的数量直接影响维度覆盖度。少于 20 条可能导致关键维度遗漏，建议从历史需求池中随机抽取。
3 操作步骤
维度定义遵循“业务驱动 → 维度提炼 → 子项拆解 → 锚点标定 → 评审固化”五阶段。每个阶段都有明确的入口标准和出口物。
-
识别业务目标与需求特征
分析战略文档、用户调研报告、技术债务报告，提取影响优先级的关键因子。将因子按“价值‑成本‑风险‑时间”四个篮子初步归类。
-
确定价值维度及子项
从“商业价值”和“用户价值”两个子项展开。商业价值关注收入、市场份额、竞争优势；用户价值关注 NPS、任务完成率、满意度。
-
确定成本维度及子项
拆分为“开发成本”（人天、技术难度、依赖复杂度）和“维护成本”（运维负担、技术债务利息、长期支持成本）。
-
确定风险维度及子项
至少包含“技术风险”（方案可行性、性能风险、安全风险）和“市场风险”（需求波动、政策合规、竞争响应）。
-
确定时间维度及子项
聚焦“交付时间”（绝对工期、关键路径长度）和“机会窗口”（市场时机、季节性窗口、监管截止日期）。
-
定义各维度评分锚点
为每个子项编写 1 分、3 分、5 分的具体行为锚定描述，确保不同评分者的主观偏差可控。
示例（商业价值 1‑5 分）：
1 分：对营收无直接或间接贡献；
3 分：可在 6 个月内带来 5‑10% 的增量收入；
5 分：直接开辟新市场或创造 ≥30% 收入增长。 -
评审并确认维度体系
召开维度定稿会，工作组逐项投票。通过标准：每项子维度获得 ≥2/3 赞成票，且无强烈反对意见。未通过项需重新调研后进入下一轮评审。
常见陷阱：不要将“风险”和“时间”合并为一个维度。风险是概率×影响，时间是绝对窗口，两者驱动力不同，合并会导致模型混淆不确定性与时限压力。
4 输入输出物
| 类型 | 名称 | 格式/载体 | 责任人 |
|---|---|---|---|
| 输入 | 需求清单（≥20 条） | Excel / Jira 导出 | 产品经理 |
| 输入 | 业务战略目标文档 | Confluence / PDF | 业务负责人 |
| 输入 | 技术评估报告（含人天估算、依赖风险） | PPT / 邮件确认 | 技术架构师 |
| 输出 | 评分维度定义书 | Word / 在线文档 | 产品经理 |
| 输出 | 评分锚点对照表（1‑5 分行为描述） | Excel / Google Sheets | 工作组 |
| 输出 | 维度评审会议纪要（含投票记录） | 邮件归档 / 协作平台 | 记录员 |
5 责任边界
| 角色 | 在本章中的责任 | 决策权限 |
|---|---|---|
| 产品经理 | 组织维度定义工作坊；撰写维度定义书；推动评审 | 对维度数量（4‑6 个）有建议权，无最终决定权 |
| 技术架构师 | 提供成本、风险维度的技术输入；确认子项可行性 | 对“开发成本”“技术风险”子项有一票修正权 |
| 业务代表 | 提供商业价值、用户价值、市场风险的业务视角 | 对“商业价值”“机会窗口”子项有一票修正权 |
| 风险管理人员 | 审核风险子项是否覆盖合规、安全等必评项 | 对“风险维度”子项具有否决权 |
| 记录员 | 记录会议决议、分歧点、待办事项 | 无决策权，但需确保记录可追溯 |
6 记录材料
- 维度定义工作坊签到表：记录参会人、角色、时间，作为流程合规证据。
- 因子归类原始记录：从需求样本中提取的原始因子及归类过程，便于后续追溯“为什么定义这个子项”。
- 评分锚点草稿：每个子项 1‑5 分的初始描述及修改版本，体现迭代过程。
- 投票计分表：记录每项子维度的得票数、反对理由及最终决议。
- 维度定义书签署页：产品经理、技术架构师、业务代表三方签字，纸质或电子签章均可。
7 异常处理
| 异常场景 | 判定条件 | 处理措施 | 输出 |
|---|---|---|---|
| 维度间语义重叠 | 两个子项的分值高度相关（r > 0.8）或定义描述出现 60% 以上雷同 | 合并为单一子项，或重新定义边界（如“维护成本”与“技术债务”必须明确区分） | 维度去重分析报告 |
| 工作组无法达成一致 | 某子项连续两次评审赞成票 < 2/3 | 升级至项目指导委员会裁决；或暂时搁置该子项，用替代维度试跑 10 条需求后验证 | 升级裁决记录 / 试跑对比报告 |
| 业务目标变更导致维度失效 | 战略方向在维度定义期间发生重大调整 | 冻结当前定义，按新战略重新执行步骤 1‑7；旧定义归档备查 | 维度迭代变更日志 |
| 子项评分锚点不可观测 | 锚点描述使用“可能”“大概”等模糊词汇，或无法用现有数据验证 | 重写锚点，要求每个等级对应一个可量化的指标（如“上线后 7 天内用户活跃度提升 ≥10%”） | 锚点可观测性检查清单 |
8 验收标准
以下条件全部满足后，本章工作方可视为完成：
- 评分维度定义书已包含价值、成本、风险、时间四个维度，且每个维度至少拆分为 2 个可量化子项。
- 每个子项均有 1‑5 级行为锚定描述，锚定描述中不含模糊用语（如“大概”“可能”“较好”）。
- 工作组三方（产品、技术、业务）在定义书上签字确认，无未解决的异议。
- 使用随机抽取的 5 条需求进行试评分，不同评分者对同一子项的分值偏差 ≤1 分（标准差 ≤0.5）。
- 所有记录材料（签到表、原始记录、投票表、签署页）已归档至指定路径。
验收检查表（项目经理使用）：
□ 维度覆盖 4 个篮子 □ 子项总数 ≥8 □ 锚点可观测 □ 签字齐全 □ 试跑偏差达标
任一条件不通过 → 退回至对应步骤整改，重新评审。
□ 维度覆盖 4 个篮子 □ 子项总数 ≥8 □ 锚点可观测 □ 签字齐全 □ 试跑偏差达标
任一条件不通过 → 退回至对应步骤整改，重新评审。
附：评分维度体系架构图
下图展示了本章定义的四个维度及其子项之间的层级关系。中心节点代表完整的评分维度体系，第二层为四个主维度，第三层为每个维度下的核心子项。