第3章 评分维度选择：用户价值、商业价值、开发成本、风险、战略对齐

适用场景

• 需求池中待排期的功能/特性数量超过团队产能（通常>20项），需要剔除低价值需求。
• 产品路线图面临多利益相关方冲突，需用统一语言对齐优先级。
• 跨部门（产品、开发、运营、数据）联合评审时，要求评分维度公开、透明、可审计。
• 首次建立机会评分体系或对现有评分体系进行迭代优化。

前置条件

1. 已完成需求收集与初步筛选（参见第2章），需求清单具备基本描述和预估工作量。
2. 公司/产品线的战略目标（如提升月活跃用户、降低流失率）已书面化。
3. 团队至少包含产品经理、技术负责人、业务方代表各一名。
4. 准备一块白板或共享文档（如 Confluence、飞书文档），用于记录维度定义和评分锚点。

操作步骤

1. 确定维度候选集：从本章五个维度出发，评估是否需要合并/拆分。例如“用户价值”可拆为“用户收益”和“用户体验”。
2. 定义每个维度的评分标准（1～5分）：为每个维度编写明显的锚点描述，避免模糊。
3. 加权讨论：通过德尔菲法或简单投票确定各维度权重，确保总和为100%。
4. 试打分：选取3～5个典型需求进行测试，检查评分结果是否符合直觉。
5. 定稿发布：将维度定义、评分标准、权重填入模板，全员签署确认。

责任边界

• 产品经理：组织维度讨论会，撰写维度定义初稿，确保与战略对齐。
• 技术负责人：对“开发成本”维度提供工程量级估算（T恤尺寸或人天）。
• 业务方/运营：对“用户价值”“商业价值”提供用户反馈、营收数据。
• 数据分析师：协助量化风险概率（如技术可行性、合规风险）。
• 决策层：审批最终维度清单及权重，当出现跨部门争议时仲裁。

记录材料

• 维度定义表决记录：记录每次讨论的变更理由及投票结果。
• 评分标准锚点对照表：例如“用户价值4分：影响核心用户路径，提升日活5%以上”。
• 试打分校准日志：记录试打分时发现的歧义点及修正动作。

异常处理

验收标准

1. 维度定义表已通过全员评审，无重大反对意见。
2. 试打分中，不同评分者针对同一需求的分数差异≤1分（满分5分）的比例≥80%。
3. 评分模板已经嵌入需求管理工具（如 Jira、ClickUp），可直接调用。
4. 包含“战略对齐”维度的需求，优先于其他维度同分需求。