第3章：评分前的数据准备：收集项目历史数据、定义口径、统一单位
适用场景
本章节适用于以下场景：
- 团队即将进行RICE评分对比复盘，需要为所有参评项目建立统一的数据基准。当项目数据来源分散（如Jira、Excel、飞书文档、邮件）时，必须执行此流程。
- 复盘涉及跨部门或跨周期对比，不同项目成员对“覆盖用户数”“开发人天”等口径理解不一致。
- 历史项目数据缺失、格式混乱或单位不统一（例如有的项目用人天，有的用人时）。
前置条件
- 项目清单已锁定：确认本次复盘涉及的具体项目列表（通常5-15个），不允许在数据准备过程中新增项目。
- 数据源授权：已获得访问项目管理工具（Jira、Tapd）、版本控制仓库（GitLab/GitHub）、工时系统、需求文档库的读取权限。
- 数据责任人确认：每个参评项目至少指定1名数据接口人，负责核实数据准确性。
操作步骤
Step 1：采集原始项目数据
数据接口人从各自工具中提取原始数据。所有提取物需注明数据来源和提取时间戳。
采集清单表：
| 数据维度 | 推荐来源 | 采集字段 |
|---|---|---|
| 关键时间点 | Jira / 项目管理日历 | 立项时间、里程碑1/2/3时间、结项时间 |
| 团队投入 | 工时系统（Tempo / Clockify） | 角色（PM/DEV/QA）、工时（小时）、总人天数 |
| 用户影响 | 埋点系统 / 用户增长后台 | MAU、DAU、新用户数、功能渗透率 |
| 业务指标 | BI报表 / 数据仓库 | 转化率、GMV、留存率、NPS |
| 文档资产 | Confluence / GitLab Wiki | PRD数、设计稿数、测试用例数 |
Step 2：定义计算口径（建立口径词典）
核心原则：同一个字段名只能对应唯一一种计算逻辑。团队必须就以下三个最容易产生歧义的口径达成共识并记录入文档。
口径文档写入示例（RICE口径表节选）
字段: reach 覆盖用户数
口径: 项目上线后首月内，触及该功能的UV（去重DAU累计）。
排除: 内部测试账号、爬虫、后台管理人员。
特殊情况: 如果是B端项目，指所有开通此功能的客户账号数。| 维度 | 常见口径陷阱 | 推荐统一口径 |
|---|---|---|
| Impact（影响） | 有人按用户反馈数，有人按付费转化提升百分比 | 统一为“核心业务指标的相对提升率（%）” |
| Confidence（信心） | 有人仅看A/B测试显著，有人只凭主观直觉 | 严格按数据验证等级划分：强(90%) / 中(70%) / 弱(50%) |
| Effort（工作量） | PM填人天，开发填人时，且是否包含测试 | 统一按“开发+测试+PM总人天”计算，不含设计 |
Step 3：统一度量单位与量纲
将步骤1中采集的异构数据，通过口径定义转换为标准基准单位。
- 时间单位：工时一律转为“人天”（1人天=8小时），跨月项目需对齐工作日日历。
- 用户单位：统一使用“UV（Unique Visitor）”，排除PV影响。
- 金钱单位：所有财务数字转换为“元（人民币）”，汇率按采集月份最后一天中间价折算。
- 百分比单位：相对提升率统一保留2位小数，格式如“+15.23%”或“-2.10%”。绝对数值与相对值分开存储，避免混淆。
常见异常：项目A用“人时”统计开发投入共120h，项目B用“人月”统计投入共0.5PM。两者无法直接对比。必须按统一口径强制转换为“人天”。本例中：120h/8h=15人天；0.5PM * 21工作日/PM=10.5人天。
Step 4：数据清洗与初步校验
将所有标准化后的数据填入《项目历史数据汇聚表》，执行完整性检查。
- 检查是否存在空值字段，空值必须由接口人补充说明或标记为“N/A”并影响Confidence评估。
- 检查数据边界：Effort 应大于0；Reach 应为整数；Impact 应在合理业务波动范围内。
- 标记异常记录（如单次Effort突增500%），由PM与人天归属成员确认是正常还是录入错误。
输入输出物
- 输入物：各项目原始工单/代码库/BI报表/文档库；项目清单；数据接口人通讯录。
- 输出物：《RICE评分-历史数据汇总表（标准化版）》、《RICE口径定义词典》、数据异常标记日志。
责任边界
| 角色 | 职责范围 | 不可逾越边界 |
|---|---|---|
| 项目经理（PM） | 提供原始项目数据，配合口径定义，充当数据组与业务方的桥梁。 | 无权擅自修改口径定义，所有口径变更需由数据治理小组审批。 |
| 数据分析师 | 负责数据清洗、公式编写、单位转换、异常数据打标。 | 不可用估算值填充缺失原始数据，必须回传项目组确认。 |
| 流程SOP经理 | 维护口径词典，组织Step 2口径讲解会议，裁定口径争议。 | 不可直接录入数据，仅做规则讲解与仲裁。 |
记录材料
- 《口径词典V1.0.xlsx》：包含RICE四个维度的全量字段口径定义、特殊情况备注、修改历史。
- 《异常数据排查表》：记录异常数据描述、发生原因、处理方案及最终状态。
- 《数据源与口径确认签署单》：各项目接口人签字确认数据已按统一口径准备完毕，交由流程SOP经理存档。
异常处理
| 异常场景 | 处理SOP |
|---|---|
| 某项目原始数据完全丢失 | 将该项目的Confidence强制置为最低档(50%)，并在数据汇总表中标记“数据缺失”。禁止使用猜测或内插法填补。复盘时直接暴露此风险。 |
| 跨部门口径冲突引发争议 | 升级至SOP经理，召集冲突双方进行30min口径对齐会。若仍无法达成一致，按“有利于降低评分偏差”原则选最保守口径。 |
| 数据量纲转换后出现非整数 | Effort人天、用户数等原则上取整（天花板进位），百分比和货币可保留2位小数。非整数人天需附加备注说明原因。 |
验收标准
- 数据完整性：所有参评项目的RICE五字段（Reach, Impact, Confidence, Effort, Score）均有数据或明确标记。
- 口径一致性：随机抽查3个字段，由不同数据分析师独立读入口径文档并正确计算，结果误差小于0.5%。
- 异常清零：《异常数据排查表》中的所有记录均已标记为“已处理/待处理/无需处理”，无未分类异常。
- 签署确认：至少80%的接口人在《数据源与口径确认签署单》上完成电子签署，剩余20%需在24h内补签。
经验提示：不要跳过Step 2直接进入数据填写。定义口径所花费的时间通常占整个数据准备阶段的40%，但没有清晰的口径定义，后续RICE评分的内部一致性系数（ICC）会骤降。建议在数据准备周周一举行“口径午餐对齐会”，一次通过所有字段定义。