第2章 权重评估前置条件:所需数据清单、参与角色分工、评估时机与触发条件
本章定位:在正式使用RICE模型对AI需求进行权重打分之前,必须完成三项前置条件的确认——数据就绪、人员到位、时机成熟。本章以SOP清单形式逐一展开,确保评估启动前无遗漏、无歧义。
1. 适用场景
权重评估前置条件检查适用于以下三类具体场景:
- 首次评估启动:团队初次引入RICE模型,需要建立标准化的数据与角色基线。
- 迭代周期切换:每个评估周期(如 sprint / PI)开始前,需重新核对数据时效性与角色可用性。
- 紧急需求插队:突发高优AI需求进入排布通道时,触发前置条件快速检查,确保评估不跳步。
2. 前置条件
权重评估启动必须同时满足以下三大前置条件,缺一不可。
2.1 所需数据清单
数据是RICE模型量化的基石。下表列出每项评估必需的数据字段、来源与质量要求:
| 数据类别 | 数据字段 | 数据来源 | 质量要求 |
|---|---|---|---|
| 需求属性 | 需求标识符(ID) | 需求管理平台 | 全局唯一,不可为空 |
| 需求描述与验收标准 | PO / 业务方 | 清晰可理解,无二义性 | |
| 需求类型标签 | 分类体系映射 | 符合团队既定分类(功能/非功能/技术债务) | |
| 项目资源 | 预估人天数 | 技术负责人评估 | 精确到0.5人天,有估算依据 |
| 依赖项清单 | 架构师 / 系统地图 | 标注阻塞型依赖与软依赖 | |
| 历史评估 | 上一周期RICE得分(如有) | 评估记录库 | 得分与明细可追溯 |
| 需求交付实际效果反馈 | 数据分析 / 用户行为埋点 | 定量指标(如点击率、转化率) |
数据准备技巧:建议在迭代规划前2个工作日由数据分析师导出需求清单并预填充公共字段,避免评估会议现场等待。
2.2 参与角色分工
角色权重与表决机制必须提前书面约定。下表定义每个角色的职责、表决权重与不可替代性:
| 角色 | 职责范围 | RICE维度主责 | 表决权重 | 备选人机制 |
|---|---|---|---|---|
| 产品负责人(PO) | 需求价值主张、业务对齐 | Reach, Impact | 30% | 指定副PO或产品总监代理 |
| 数据分析师 | 数据提取、置信度测算 | Confidence | 20% | 团队内交叉审核 |
| 技术负责人 | 工作量评估、技术风险判断 | Effort | 25% | 架构师或技术经理代理 |
| 业务代表 | 用户视角、场景补充 | Reach, Impact | 15% | 用户研究专员代理 |
| Scrum Master / 流程引导 | 评估流程合规、时间盒控制 | 流程中立(无维度权重) | — | 不代理,缺席则改期 |
角色缺席红线:PO与技术负责人为强制出席角色,任意一方缺席则评估会议必须改期。数据分析师与业务代表可提交书面评估材料后由代理人参与。
2.3 评估时机与触发条件
评估并非随时可发起,必须满足以下时机条件之一,并触发启动信号:
| 触发条件 | 时机描述 | 适用场景 | 启动信号输出物 |
|---|---|---|---|
| 迭代规划前固定窗口 | 每个迭代结束前第3天~第2天 | 常规周期性评估 | 《迭代需求预排清单》 |
| 需求冻结期开启 | 需求冻结公告发布后24小时内 | 版本发布前最终评估 | 《需求冻结通知》 |
| 关键决策点触发 | 技术方案评审通过 / 用户验证反馈到达 | 紧急需求或重大变更 | 《决策点评估申请单》 |
| 积压工作超过阈值 | 待排需求数量 > 团队容量×1.5 | 需求积压治理专项 | 《积压需求排名报告》 |
3. 操作步骤(前置条件检查SOP)
在进入RICE正式打分前,按照以下四步检查流程完成前置条件验证:
- 步骤一:数据完备性校验 —— 对照“所需数据清单”逐项核对,缺失项标红并通知责任人在4小时内补全。
- 步骤二:角色出席确认 —— 检查强制出席角色(PO、技术负责人)是否在线,代理人是否持有书面授权。
- 步骤三:触发条件匹配 —— 确认当前所处时机满足至少一种触发条件,并输出对应的启动信号物。
- 步骤四:前置条件会签 —— 由Scrum Master发起线上会签,三条件均满足后解锁“权重评估”阶段。
SOP检查口诀:“数据齐、人到场、时机对,会签通过再评估。”
4. 输入输出物
| 类型 | 物名称 | 格式 | 责任方 |
|---|---|---|---|
| 输入 | 原始需求列表(含ID与描述) | Excel / Jira CSV | PO / 需求管理 |
| 输入 | 项目资源日历 | 在线日历 / 排期表 | PMO |
| 输出 | 《前置条件检查清单》 | Markdown / 在线文档 | Scrum Master |
| 输出 | 《评估准备就绪报告》 | PDF / 看板卡片 | Scrum Master |
5. 责任边界
- PO:对需求数据完整性负首要责任,确保每项需求有明确的业务价值描述。
- 数据分析师:对历史数据和置信度数据的准确性负责,提供可复现的数据源路径。
- 技术负责人:对Effort评估的颗粒度负责,标注技术风险点。
- Scrum Master:对前置条件检查流程的合规性负责,对未达标项有权叫停评估会议。
6. 记录材料
以下材料必须归档至共享知识库,保留至少3个评估周期:
- 《前置条件检查清单》(含逐项确认人、确认时间)
- 《数据缺失项追踪表》(含补全记录)
- 《角色授权代理书面记录》(含授权人签字)
- 《触发条件匹配说明》(含截屏或链接)
7. 异常处理
| 异常类型 | 具体表现 | 处理预案 |
|---|---|---|
| 数据缺失 | 核心字段(如人天数、依赖项)缺失超过2项 | 终止评估,由PO在24小时内发起数据补全专项 |
| 角色缺席 | PO或技术负责人缺席且无授权代理 | 评估会议改期至最快可参会时间,重新走触发条件检查 |
| 时机不成熟 | 触发条件未达(如积压未超阈值) | 暂停评估,标记为“待触发”状态,每周自动检查一次 |
| 数据质量不合格 | 预估人天数与实际偏差 > 30%(经抽样验证) | 退回技术负责人重新评估,同时更新估算校准记录 |
8. 验收标准
以下五项全部满足,方可认定前置条件通过,进入第3章RICE正式打分环节:
- 所有需求ID在需求管理平台中状态为“已确认”,且描述字段不为空。
- 强制出席角色(PO、技术负责人)均已签到或持有有效授权代理记录。
- 当前时间匹配至少一种触发条件,且启动信号物已生成并归档。
- 《前置条件检查清单》已由Scrum Master与PO双人会签。
- 无未关闭的异常项(如有异常项,必须已启动对应预案并有明确的跟踪人)。
章节交付物:完成本章学习后,团队应持有已签署的《前置条件检查清单》与《评估准备就绪报告》,并确保三项 pillar 全部绿灯,方可继续学习第3章“RICE四维度权重定义与分值标定”。