第3章 · 前置条件:需求条目化、清晰定义、数据准备
在正式应用RICE模型对Agent需求进行优先级评分之前,必须完成三项底层准备工作:需求条目化、清晰定义和数据准备。这三项前置条件共同构成了RICE评估的质量基线——任何一项未达标,都会导致后续评分结果失真或无法复用。本章以SOP形式详细拆解每一项前置条件的具体要求、执行步骤与验收标准。
适用场景
以下情境必须完整执行本章前置条件,否则RICE评分不具备可采信基础:
- 原始需求已收集但未结构化——用户故事、会议纪要、邮件等分散来源需要统一格式。
- 多个来源需求需要合并评估——不同团队、不同业务线提交的需求格式各异。
- 需求涉及跨团队协作——研发、测试、运营等多角色对需求理解需对齐。
- 需要为RICE评估准备量化输入——Reach、Impact、Confidence、Effort各项均依赖明确的数据基础。
前置条件
在开始执行条目化与数据准备工作之前,须确认以下物料已到位:
| 类别 | 具体物料 | 状态要求 |
|---|---|---|
| 需求源材料 | 用户故事、功能描述、业务需求文档(BRD)、会议纪要 | 已归档可追溯 |
| 业务术语表 | 核心业务概念、指标定义、行业术语对照 | 已评审发布 |
| 数据源清单 | 埋点系统、日志、数据库、三方API数据说明 | 已确认可用性 |
| 干系人列表 | 需求提出方、业务决策人、技术评估人 | 已明确职责 |
操作步骤
- 需求条目化拆分:将原始需求拆分为最小可独立评估的单元,每个单元只对应一个Agent行为或一个功能点。
- 字段信息补全:为每个需求条目补充完整字段——唯一ID、标题、描述、执行角色、前置条件、后置条件。参考模板:
{ "id": "AGENT-REQ-003", "title": "售后话术自动生成", "description": "根据客户问题意图,自动生成多轮应答话术", "actor": "售后Agent", "precondition": "已接入客服系统、已加载产品知识库", "postcondition": "话术内容写入对话流并推送至前端", "acceptance_criteria": [ "意图识别准确率 ≥ 92%", "话术生成响应 < 800ms", "支持至少5种常见售后场景" ] } - 术语定义对齐:与业务方逐条确认核心术语,消除一词多义或多词同义。输出《术语定义对照表》。
- 边界条件明确:定义每个需求条目适用的业务边界、最大并发量、容错策略、降级方案。
- 数据可用性评估:逐一检查RICE四要素对应的数据是否可获取:
- Reach → 影响用户数/调用次数(埋点或日志可查?)
- Impact → 转化率提升/耗时减少(A/B测试或历史数据?)
- Confidence → 证据强度(实验数据/专家判断/行业基准?)
- Effort → 人天/资源成本(排期计划或历史同类数据?)
- 数据清洗与准备:对原始数据进行去重、异常值过滤、缺失值标记,生成结构化数据表。
- 前置条件验收:使用验收清单逐项打勾,未通过项标记「待补齐」并退回对应责任人。
输入输出物
| 类型 | 名称 | 格式 / 载体 |
|---|---|---|
| 输入 | 原始需求文档(BRD / 用户故事 / 会议纪要) | Confluence / 飞书文档 / Word |
| 输入 | 业务术语表(V1.0) | Excel / 语雀表格 |
| 输入 | 数据源清单及权限说明 | Wiki / 权限系统截图 |
| 输出 | 条目化需求清单(含唯一ID+完整字段) | JSON / YAML / 数据库记录 |
| 输出 | 术语定义对照表(已对齐版) | Excel / 语雀表格 |
| 输出 | 数据准备完成报告(含清洗记录+可用性结论) | PDF / 内部平台报告 |
责任边界
| 角色 | 负责内容 | 交付物 |
|---|---|---|
| 需求分析师 | 需求条目化拆分、字段补全、术语对齐 | 条目化需求清单、术语对照表 |
| 业务方 | 确认需求定义准确性、边界条件合理性 | 签字确认邮件 / 审批记录 |
| 数据工程师 | 数据可用性评估、数据清洗、结构化准备 | 数据准备完成报告 |
| 产品经理 | 验收前置条件完成质量、组织评审 | 前置条件验收签字 |
记录材料
- 《需求条目化模板》——包含ID、标题、描述、角色、前置/后置条件、验收标准字段。
- 《术语定义对照表》——记录原始术语、对齐后术语、定义来源、确认人。
- 《数据准备检查清单》——逐项列出RICE四要素所需的数据源、权限状态、清洗情况。
异常处理
| 异常情况 | 处理方式 | 负责人 |
|---|---|---|
| 需求描述模糊,无法拆分 | 标记为「待澄清」,退回业务方补充场景描述与用户目标 | 需求分析师 → 业务方 |
| 需求颗粒度不一致(过细或过粗) | 与研发+业务对齐拆分规则,统一按「一个Agent原子行为」为标准重拆 | 需求分析师 |
| 关键数据不可获取(如无埋点) | 标记为「数据缺失」,评估是否可寻找替代指标或通过专家估算 | 数据工程师 + 产品经理 |
| 术语定义冲突(多方理解不同) | 组织专题评审会,统一术语并更新对照表,双方签字确认 | 需求分析师 + 业务方 |
| 数据清洗发现大量异常值 | 记录异常值明细,与数据Owner确认是否需要重建数据管道 | 数据工程师 |
验收标准
以下标准全部达标方可视为本章前置条件完成:
- 完整性:每个需求条目包含唯一ID、标题、描述、角色、前置条件、后置条件、验收标准七项字段,无遗漏。
- 清晰性:独立阅读者(非提出人)能准确复述该需求的核心意图,歧义率测试 < 5%。
- 可测量性:RICE四要素中至少有三项有直接数据支撑或可替代估算方法,无「无法评估」项。
- 一致性:术语定义对照表覆盖所有核心概念,无未对齐术语;不同需求条目中同一术语含义完全一致。
- 可追溯性:每个需求条目均可追溯到原始需求来源(文档链接/会议记录ID)。
💡 效率提示:首次执行本章流程时,建议使用模板化工具(如 Airtable / Notion / 飞书多维表格)管理条目化需求清单,配合自动字段校验和校验规则,可减少人工核对成本约 40%。
✋ 常见返工场景:需求条目化阶段最常见的返工原因是「颗粒度不统一」——有的需求拆到了按钮级别(过细),有的还是大功能模块(过粗)。建议团队在开始拆分前先评审 2~3 个样例条目,对齐拆分尺度后再铺开执行。