第3章：Reach 评分标准制定

3.1 适用场景

本章方法适用于以下场景：

• 首次在团队或产品线上引入 RICE 模型，需要定义统一的 Reach 分档规则。
• 现有 Reach 评分标准已使用超过一个季度，因业务变化需要重新校准。
• 跨职能团队对某类用户触达量的估算存在长期分歧，需要建立共识锚点。
• 产品经理、数据分析师、业务负责人共同参与需求优先级排序前，必须先对齐 Reach 的取值范围。

3.2 前置条件

3.3 操作步骤

1. 确定计量单位：统一使用“自然月内触达的用户数”作为 Reach 的原始分母。如产品是周活主导（如工具类），可折合为月活跃用户数（MAU）。
2. 拉取基线数据：从 BI 系统提取过去3个月的 MAU 中位数、最小值、最大值，以及典型用户分层（新用户、活跃用户、沉睡用户）的分布。
3. 建立分档规则：基于基线数据，将 Reach 分为5档（0–2, 3–4, 5–6, 7–8, 9–10）。每档对应一个实际用户区间（例如：0–2分 = 每月 < 1千人；3–4分 = 1千–1万；以此类推）。
4. 设定锚定案例：针对每档选取一个已上线或高置信度的功能作为锚点，帮助团队快速映射。
5. 团队共识校准：组织评审会，逐条讨论锚点案例，使用“独立打分→公开讨论→重评分”方式达成一致。
6. 制定校准规则：若有争议（2档之间偏差），取中值或取高值须有数据支撑；若数据缺失，取低分并标记为待验证。
7. 验收检查表核实：对照验收检查表逐条确认分档结果可操作、可复盘。

3.4 输入 / 输出物

3.5 责任边界

• 产品经理（Owner）：主导分档规则设计、组织评审会、输出最终文档。
• 数据分析师（Co-Owner）：提供基线数据、校准锚点案例、保证数字真实性。
• 开发负责人（Reviewer）：从技术可行性角度验证分档是否合理，尤其对“零用户”场景的界定。
• 业务方（Info）：仅参与讨论并提供业务侧预期，不强制签署。

3.6 记录材料

• Reach分档规则_v1.0.xlsx – 包含分档表格、锚点案例、数据来源说明。
• Reach评分共识会议纪要_MDYYYY.md – 会议日期、参会人、争议点、决议。
• 锚定案例数据截图.zip – 每个锚点功能的触达用户数截图（脱敏后）。

3.7 异常处理

3.8 验收标准

完成本章后，需逐项检查以下清单，全部通过视为达标：

• ☐ Reach 分档规则文档已输出，包含 0–10 分对应实际用户量区间。
• ☐ 至少每档有 1 个锚点案例，锚点案例的真实用户量数据可溯源。
• ☐ 团队评审会已召开，且共识签字记录存档。
• ☐ 校准规则已写明（争议时取中值/取高值的条件）。
• ☐ 验收检查表已在文档末尾附上，并留空供后续使用。

3.9 典型分档规则模板（仅供参考）

3.10 团队共识方法：三步校准法

1. 个人独立打分：每位参与者（PM、数据、开发）独立对5个随机功能使用新分档规则打分，不透露他人分数。
2. 公开核对+讨论：汇总分数到白板/共享文档，找出偏差 >2 分的案例，由当事人解释判断依据，其他人质疑或支持。
3. 重评分+锁定：讨论后每人重新打分，若仍有 >2 分偏差则进入“模糊区间”处理流程，否则取中值锁定为最终分数。