1. 评分模型概述与适用场景
评分模型（Scoring Model）是一种量化需求优先级的结构化方法。它将影响优先级的多个维度（价值、成本、风险、依赖等）转化为可衡量的分数，并通过加权求和得到每个需求的综合得分，从而形成客观、可复现的排序结果。
1.1 定义与解决的问题
评分模型解决了以下核心问题：
- 主观偏差：避免仅凭“谁的嗓门大”或“业务方关系好”决定先做哪个需求。
- 多维度冲突：当价值高但成本高、风险大时，如何权衡？评分模型用统一量纲消弭分歧。
- 决策透明度：每个需求的最终得分可回溯，利益相关方清楚权重分配和评分逻辑。
- 批量排序：适用于需求池里几十上百个需求的规模化排序场景。
1.2 适用项目类型
| 项目类型 | 典型特点 | 是否推荐评分模型 |
|---|---|---|
| 产品功能迭代 | 需求多、版本周期固定 | ★★★（强烈推荐） |
| 技术基础设施改造 | 非功能性需求为主（性能、安全、架构） | ★★★（推荐调整因子后使用） |
| 创业阶段最小可行产品（MVP） | 需求少、不确定性高 | ★★☆（可简化权重） |
| 合规/安全类紧急事项 | 强制优先级 | ★☆☆（不适用，应直接设定为最高级别） |
1.3 与KANO模型、WSJF对比
| 维度 | 评分模型 | KANO模型 | WSJF（加权最短作业优先） |
|---|---|---|---|
| 定量程度 | 总分量化，权重可调 | 定性分类（基本型、期望型、兴奋型） | 定量（价值/成本*时间） |
| 因子数量 | 自由扩展（通常3~7个） | 仅用户满意度与实现度 | 4个因子（业务价值、时间价值、风险降级、节约成本） |
| 适用场景 | 大部分产品/项目 | 侧重于用户心理分类 | 精益/看板团队，强调交付速度 |
| 结果输出 | 优先级排序列表 | 策略建议（必须做/应该做/可有可无） | 优先级排序（CoD/Size） |
小技巧：评分模型可与其他方法结合使用。例如先用KANO分类筛选出“基本型”和“期望型”需求，再对选中的需求用评分模型排序。
1.4 前置条件
- 已建立需求列表（包含需求ID、名称、描述、初步估算工作量）。
- 项目团队（产品经理、技术负责人、业务代表）达成共识，愿意采用量化方法。
- 确定评分因子（通常包括：业务价值、开发成本、技术风险、用户影响力、市场紧迫性等）。
- 明确评分量表（例如1~5分、1~10分或1~3分）。
- 分配权重（各因子占总分的百分比，合计100%）。
1.5 操作步骤
- 定义评分因子与权重 – 团队讨论并确定3~5个核心因子，为每个因子分配权重（例如价值40%、成本25%、风险20%、用户影响力15%）。
- 设计评分细则 – 为每个因子制定打分明细（如价值5分：直接影响核心KPI；4分：显著提升效率；3分：一般改进……）。
- 收集需求数据 – 针对每个需求，由对应角色（业务方估价值、技术估成本、安全估风险）给出各因子得分。
- 计算加权总分 – 使用公式
Score = Σ (因子得分 × 权重)计算每个需求的最终分数。 - 排序与校验 – 按总分降序排列，评审前20%需求是否合理；如有异常（如政治性强制需求）进行标记与权重微调。
示例：某需求“增加支付方式-微信支付”评分过程：
- 业务价值：5（满分5），权重40% → 5×0.4 = 2.0
- 开发成本：3（成本越低分越高，假设3/5），权重25% → 3×0.25 = 0.75
- 技术风险：4（风险低分高），权重20% → 4×0.2 = 0.8
- 用户影响力：5（覆盖30%用户），权重15% → 5×0.15 = 0.75
- 总分：2.0 + 0.75 + 0.8 + 0.75 = 4.3
1.6 输入输出物
| 类别 | 名称 | 说明 |
|---|---|---|
| 输入物 | 需求列表（含属性） | 至少包括：需求ID、简要描述、估算人天 |
| 输入物 | 评分因子定义表 | 因子名称、权重、评分细则（1~5分描述） |
| 输出物 | 评分计算表 | 每个需求的因子得分、加权总分、排名 |
| 输出物 | 优先级排序列表（Top x%） | 用于版本规划或迭代排序 |
1.7 责任边界
- 产品经理（PM）：定义评分因子与权重，组织评分会议，对结果负责。
- 技术负责人（TL）：评估开发成本、技术风险因子。
- 业务方/客户代表：评估业务价值、用户影响力因子。
- 项目经理（PMO）：维护评分模型迭代记录，确保流程一致。
- 团队全体：认可评分规则，接受最终排序结果（如有异议通过权重调整机制协商）。
1.8 记录材料
- 评分因子定义历史版本（每次迭代如新增因子需评审并存档）。
- 每次评分的原始打分表（含打分人、日期、需求ID）。
- 评分模型使用说明（包含步骤、公式、示例）。
1.9 异常处理
| 异常情况 | 处理方式 |
|---|---|
| 多个需求得分完全相同 | 增加辅助因子（如用户量、紧迫性）或由团队投票决定 |
| 政治性强制需求 | 标记为“强制优先级”，不参与评分排序（单独通道） |
| 评分因子权重争议 | 试点10个需求计算得分，模拟排序结果；若团队仍不接受，可返回重新讨论权重 |
| 评分数据缺失（如某因子无法评估） | 使用该因子的默认中等分（如3分），并在备注中注明 |
1.10 验收标准
- 所有待排期的需求均已完成评分，得分无遗漏。
- 评分结果得到核心干系人确认（邮件或会议纪要）。
- 评分因子定义文档已归档至团队知识库。
- 若有需求在后续执行中被发现优先级不合理，则启动复盘，更新评分模型。