1. 场景模型定义与业务价值
1.1 场景模型概念
场景模型（Scenario Model）是对用户在特定环境下为达成某一目标所经历的行为路径、交互反馈及约束条件进行的结构化、可复用的抽象描述。它不是用户故事的简单罗列，而是将碎片化的访谈信息、观察记录和业务规则整合为统一的分析框架。
一个完整的场景模型包含以下5个核心构成要素：
| 要素 | 说明 | 典型问题 |
|---|---|---|
| 用户角色 | 执行操作的主体及其特征 | 谁在使用？权限等级？操作频率？ |
| 目标动机 | 用户期望达成的结果或驱动力 | 为什么要做这件事？不做的损失？ |
| 行为路径 | 从触发到结束的完整操作序列 | 先做什么？后做什么？分支条件？ |
| 环境条件 | 行为发生时的物理或数字上下文 | 设备类型？网络状态？时间窗口？ |
| 约束规则 | 限制行为或影响结果的业务逻辑 | 必填字段？数据上限？审批层级？ |
以下是一个场景模型的结构化模板示例，展示如何将上述要素组织为可复用的分析单元：
场景模型：员工提交报销申请
├── 用户角色：正式员工（非财务岗）
├── 目标动机：快速完成差旅费用报销
├── 行为路径：
│ 1. 登录 OA 系统 → 2. 进入“费用报销”模块
│ 3. 选择关联出差申请单 → 4. 填写费用明细
│ 5. 上传电子发票（≤3 张） → 6. 提交审批
├── 环境条件：Web 端（Chrome 90+）/ 移动端（iOS 14+）
└── 约束规则：
├─ 单笔报销金额 ≤ 5000 元
├─ 发票日期需在出差申请日期范围内
└─ 审批流：直属上级 → 财务初审 → 财务复审（金额>2000）
要点提示：场景模型的核心产出是“可复用的行为模板”，而非一次性描述。同一模型可被多个 PRD 条目引用，避免需求重复定义。
1.2 场景模型与 PRD 需求条目的关系
PRD 需求条目是场景模型的解耦表达：一个场景模型通常会衍生出多个功能条目、业务规则和验收标准。反之，脱离场景的需求条目容易陷入“功能堆砌”——每个功能都正确，但整体无法解决用户的实际问题。
从信息完整性角度看，场景描述存在三个层级，直接影响 PRD 质量：
| 层级 | 完整性 | 可复用性 | 可验证性 | 典型问题 |
|---|---|---|---|---|
| 无场景描述 | ❌ 无 | ❌ 无 | ❌ 无 | 需求模糊、频繁返工 |
| 碎片化场景 | ⚠️ 部分 | ❌ 低 | ⚠️ 部分 | 理解偏差、范围蔓延 |
| 结构化场景模型 | ✅ 完整 | ✅ 高 | ✅ 强 | 交付争议少、共识度高 |
常见误区：将碎片化场景直接当作 PRD 条目。例如仅记录“用户需要上传发票”就写入需求，缺少对发票数量、格式、大小、真伪校验等约束的描述，导致开发与测试阶段反复返工。
1.3 场景建模的核心作用
场景建模在需求分析中承担“翻译层”角色——将模糊的业务诉求转化为结构化的分析单元，再进一步拆解为可执行的 PRD 条目。其核心作用围绕以下五个维度展开：
上图展示了场景模型如何作为需求分析的中枢，驱动五个关键价值输出。每个箭头代表“支撑”或“转化”关系，确保从用户研究到 PRD 输出的路径可追溯、可验证。
1.4 业务价值分析
在企业级产品实践中，场景建模带来的业务价值可直接量化为以下四个维度：
- 需求质量提升（减少 40%-60% 的返工）：结构化场景暴露隐含规则，避免开发阶段才发现需求缺失。
- 团队协作效率（沟通成本降低 50%）：业务方、产品、开发、测试基于同一场景模型对齐认知，消除歧义。
- 需求复用性增强（跨项目复用率≥30%）：标准化的场景模型可在不同产品或版本间迁移，减少重复分析。
- 验收争议减少（上线前缺陷率下降 70%）：场景模型直接导出验收用例，测试覆盖更完整。
实操建议：在项目启动阶段，产品经理应优先产出 3-5 个核心场景模型，并组织跨角色评审。评审通过后再进入 PRD 条目细化，可大幅降低后期需求变更频率。
案例参考：某 SaaS 报销系统在重构时，团队基于 8 个标准化场景模型生成了 126 条 PRD 条目，开发周期缩短 35%，上线后仅出现 2 项低优先级缺陷——均源于场景模型中未覆盖的边缘环境（弱网离线提交）。
场景建模不是“额外工作”，而是需求分析的防错前置。它让后续的条目拆分、方案设计、测试验收都建立在可共识、可追溯的结构之上。这正是本课程要系统传授的方法论——从场景模型到 PRD 条目的完整转化路径。