第3章 · 前置条件:需求条目化、清晰定义、数据准备

在正式应用RICE模型对Agent需求进行优先级评分之前,必须完成三项底层准备工作:需求条目化、清晰定义和数据准备。这三项前置条件共同构成了RICE评估的质量基线——任何一项未达标,都会导致后续评分结果失真或无法复用。本章以SOP形式详细拆解每一项前置条件的具体要求、执行步骤与验收标准。

前置条件准备流程 原始需求 需求条目化 唯一标识 字段完整 清晰定义 术语统一 边界明确 数据准备 指标可量化 数据可获取 前置条件就绪 ⚠ 注意 前置条件未满足时,RICE评估 结果可能失真或无法复用

适用场景

以下情境必须完整执行本章前置条件,否则RICE评分不具备可采信基础:

  • 原始需求已收集但未结构化——用户故事、会议纪要、邮件等分散来源需要统一格式。
  • 多个来源需求需要合并评估——不同团队、不同业务线提交的需求格式各异。
  • 需求涉及跨团队协作——研发、测试、运营等多角色对需求理解需对齐。
  • 需要为RICE评估准备量化输入——Reach、Impact、Confidence、Effort各项均依赖明确的数据基础。

前置条件

在开始执行条目化与数据准备工作之前,须确认以下物料已到位:

类别具体物料状态要求
需求源材料用户故事、功能描述、业务需求文档(BRD)、会议纪要已归档可追溯
业务术语表核心业务概念、指标定义、行业术语对照已评审发布
数据源清单埋点系统、日志、数据库、三方API数据说明已确认可用性
干系人列表需求提出方、业务决策人、技术评估人已明确职责

操作步骤

  1. 需求条目化拆分:将原始需求拆分为最小可独立评估的单元,每个单元只对应一个Agent行为或一个功能点。
  2. 字段信息补全:为每个需求条目补充完整字段——唯一ID、标题、描述、执行角色、前置条件、后置条件。参考模板:
    {
      "id": "AGENT-REQ-003",
      "title": "售后话术自动生成",
      "description": "根据客户问题意图,自动生成多轮应答话术",
      "actor": "售后Agent",
      "precondition": "已接入客服系统、已加载产品知识库",
      "postcondition": "话术内容写入对话流并推送至前端",
      "acceptance_criteria": [
        "意图识别准确率 ≥ 92%",
        "话术生成响应 < 800ms",
        "支持至少5种常见售后场景"
      ]
    }
  3. 术语定义对齐:与业务方逐条确认核心术语,消除一词多义或多词同义。输出《术语定义对照表》。
  4. 边界条件明确:定义每个需求条目适用的业务边界、最大并发量、容错策略、降级方案。
  5. 数据可用性评估:逐一检查RICE四要素对应的数据是否可获取:
    • Reach → 影响用户数/调用次数(埋点或日志可查?)
    • Impact → 转化率提升/耗时减少(A/B测试或历史数据?)
    • Confidence → 证据强度(实验数据/专家判断/行业基准?)
    • Effort → 人天/资源成本(排期计划或历史同类数据?)
  6. 数据清洗与准备:对原始数据进行去重、异常值过滤、缺失值标记,生成结构化数据表。
  7. 前置条件验收:使用验收清单逐项打勾,未通过项标记「待补齐」并退回对应责任人。

输入输出物

类型名称格式 / 载体
输入原始需求文档(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 个样例条目,对齐拆分尺度后再铺开执行。