4. Confidence 信心：量化不确定性的核心标尺

4.1 适用场景

Confidence 评估适用于以下典型场景：

• 数据稀疏的需求：新功能、探索性需求缺乏历史数据，需要显式标记不确定性。
• 高风险决策：投入成本高或影响范围大的需求，必须量化决策风险。
• 跨团队争议：多个团队对需求优先级有分歧时，Confidence 提供客观对齐标尺。
• Roadmap 评审：在季度/月度规划中，统一评估所有候选需求的置信水平。
• 迭代复盘：回顾已上线需求的实际效果，反向校准 Confidence 判断标准。

4.2 前置条件

开始 Confidence 评估前，团队需完成以下准备：

• 已对需求进行 Impact 和 Reach 初步评分（RICE 前两个要素）。
• 已收集可用的用户数据、调研报告、竞品分析材料。
• 明确每个需求的 核心假设（例如：“用户愿意为此功能每周打开 App 3 次”）。
• 确定参与评估的角色（至少包含 PM + 1 名技术负责人 + 1 名数据/用研同学）。

4.3 操作步骤

Confidence 评估遵循 “证据→分类→评级→判定→输出→调整” 六步流程，下图展示完整链路：

具体操作分为以下 6 个步骤：

步骤 1：收集需求相关证据

围绕需求的核心假设，系统性收集以下四类证据：

步骤 2：对证据进行分类

将收集到的证据按上述四类标注。如果同一需求存在多类证据，以 最高可信度 证据为准进行后续评级。

步骤 3：进行假设评级

步骤 4：对照标准判定信心等级

步骤 5：记录信心分数

将判定结果写入需求卡片，格式为 Confidence: {代表值}%（如 Confidence: 70%）。若团队使用三级简化版，可映射为 High=90%，Medium=70%，Low=50%。

步骤 6：动态调整与复审

遵循以下规则持续维护 Confidence 分数：

• 新证据触发：当新的用户数据、调研结果或上线数据可用时，立即重新评估。
• 定期复审：每个迭代/里程碑结束时，对所有活跃需求的 Confidence 进行批量回顾。
• 跨团队校准：每季度组织一次 PM + 数据 + 技术 三方校准会，对齐判断标准。
• 阈值变更：当多个候选需求 Confidence 接近时，自动提升对直接证据的要求（例如：从中信心中再细分档位）。

4.4 输入输出物

4.5 责任边界

• 产品经理：发起评估、整理证据、组织评审、维护 Confidence 字段。
• 数据分析师 / 用研：提供直接/间接证据，验证假设可信度。
• 技术负责人：评估技术可行性对假设的影响（例如：实现成本是否改变假设风险）。
• 评审组（PM + 数据 + 技术）：对争议需求进行投票校准，最终确认信心等级。

4.6 记录材料

每个需求的 Confidence 评估需留存以下记录：

需求 ID: REQ-2025-0042
需求标题: 用户成就勋章系统
核心假设: 勋章能提升周留存率 5%
证据清单:
  - 直接证据: 无
  - 间接证据: 用户访谈 12 人，8 人表示“有趣” (可信度中)
  - 推理性证据: 竞品 Gameful 勋章功能留存+7% (可信度中)
  - 假设性证据: 团队认为符合游戏化趋势 (可信度低)
证据分类: 间接证据
假设评级: 部分验证
信心等级: 中 (70%)
评审参与人: 张三(PM) / 李四(数据) / 王五(技术)
复审日期: 2025-04-15

4.7 异常处理

4.8 验收标准

完成 Confidence 评估后，需满足以下条件方可视为合格：

• 每个需求已明确标注 证据类型 和 假设评级。
• Confidence 分数已写入需求卡片，格式为整数百分比（如 70%）。
• 所有参与评审的角色已确认评级结果（至少 PM + 数据/技术 双签）。
• 若 Confidence 低于 60%，必须附带 证据缺口清单 和 提升计划（例如：计划在 2 周内完成用户调研）。
• 复审日期已记录，下次复审时间已纳入团队日程（不超过一个迭代周期）。