第4章 用户故事与场景挖掘：角色定义、业务目标、触发条件、异常分支、验收标准

许多B端产品经理在编写PRD时，习惯直接列出功能列表，却忽略了需求背后的“人”和“事”。这导致开发完成后才发现流程走不通、用户不买账。本章将引入用户故事+场景挖掘的结构化方法，把模糊的“我想要个报表”拆解为可验证的五要素模型。

4.1 为什么需要五要素？从“叙事”到“结构”

用户故事的标准格式是：“作为<角色>，我希望<功能>，以便<价值>”。但在B端复杂业务中，仅凭三要素远远不够——缺少触发条件和异常分支，需求描述会留下大量模糊地带。五要素模型对此进行了增强：

4.2 场景挖掘的四个步骤

不要坐在工位“脑补”场景。按照以下步骤从业务一线萃取真实场景：

1. 还原业务现场： 跟随用户完成一次完整闭环节点，记录每步决策与等待点。
2. 定位触发事件： 是手动点击？系统定时？还是上游消息推送？明确起点。
3. 追问“如果不行”： 对每一步提问“如果A数据缺失怎么办？”“如果审批人出差怎么办？”。
4. 定义完成标志： 请用户描述“看到什么才放心认为这件事情做完了”。

4.3 五要素详细拆解与避坑

4.3.1 角色定义：拒绝“用户”二字

在B端，角色 = 岗位 + 权限上下文。例如“设备巡检员-只读版”与“设备巡检员-编辑版”是不同角色。错误案例：“管理员可以查看所有数据。” 改进：“区域运维主管可查看管辖范围内所有设备的实时状态，无法修改设备参数。”

4.3.2 业务目标：可测量才有验收

好的目标包含量化指标和时间约束。对比：

• ❌ 提高退换货处理效率
• ✅ 客服在接到退货申请后，3分钟内生成退换货单，90%的异常单在当日下班前完成审核。

4.3.3 触发条件：时间、事件、状态三选一

每个用户故事必须明确启动引擎。常见触发类型：

4.3.4 异常分支：让系统“见过世面”

异常分支是B端系统稳定性的根基。访谈时使用“假如……”句式挖掘：

• 假如上游数据延迟到达，系统如何处理？
• 假如审批人连续三个工作日不操作，是否需要自动转审？
• 假如并发修改同一张单据，数据锁定策略是什么？

4.3.5 验收标准：业务语言，而非技术语言

验收标准必须由业务人员逐条认可。示例对比：

• ❌ 后端接口返回 code=0，list 不为空。
• ✅ 应收会计打开“待核销列表”，默认显示今天及前3天的未核销记录，按单据日期降序排列，与业务台账核对一致。

4.4 标准模板案例：一个完整的场景卡片

以下是一个直接可用于面试/工作中的五要素场景卡片，建议复制到自己的 PRD 模板库：

场景 ID：SC-FIN-2025-0301
场景名称：应付会计付款申请 - 退回修改

【角色定义】
  岗位：应付会计（具备付款单创建与发起权限，不可直接审核）
  系统账号类型：AP_User

【业务目标】
  在30分钟内完成对退回付款单的修改并重新提交，确保当天内通过审核。

【触发条件】
  主触发：主管在“付款审批”页面点击“退回”按钮，并填写退回意见。
  附加触发：系统自动发送站内信及邮件通知给原单应付会计。

【正常流程】
  1. 应付会计登录后看到待办任务红色角标。
  2. 点击任务进入付款单详情，退回意见高亮显示在单据顶部。
  3. 修改相关信息（金额、账户、发票号）后点击“重新提交”，状态变为“待主管审批”。

【异常分支】
  EB-01：退回超过两次 —— 系统自动锁定该付款单，需财务经理手动解封。
  EB-02：修改金额超过原单30% —— 要求附加上传补充审批邮件截图。
  EB-03：超48小时未操作 —— 系统自动发起转审至直属主管，并通知原会计。

【验收标准】
  1. 应付会计可在待办列表直接区分“退回”与“新发起”。
  2. 修改后的付款单保留全部原始附件，不丢失、不覆盖。
  3. 每次退回操作均记录在系统日志中，审计可查。