第3章 用户角色与场景分析：识别不同角色、典型场景、痛点

功能边界的本质是“谁、在什么情况下、需要解决什么问题”的明确约束。用户角色定义“谁”，业务场景描述“在什么情况下”，痛点揭示“需要解决什么问题”。只有将三者锁定，功能边界才不会漂移。本章提供从角色识别到痛点输出的完整分析框架。

3.1 用户角色的三维分类

B 端系统的用户角色不能仅按职位划分，而应从决策层级、操作频率、数据权限三个维度交叉定义。缺少任何一维，都可能导致功能范围错配。

3.2 典型场景的捕获方法

场景不是“用户故事”的零散描述，而是包含触发条件、执行步骤、预期结果三要素的结构化单元。捕获场景时遵循“先横向枚举，再纵向分层”的原则。

1. 横向枚举：按业务生命周期列出所有可能场景（例如采购：需求提出→寻源→下单→收货→对账→结算）。
2. 纵向分层：对每个场景区分“正常流程”“异常流程”“扩展流程”，避免边界遗漏。
3. 场景卡片化：每个场景用结构化模板记录，便于后续需求拆解和验收。

以下是一个标准场景卡片的 JSON 模板，可在用户访谈后直接填充：

{
  "场景ID": "SCN-003",
  "场景名称": "采购订单变更",
  "触发条件": "供应商反馈交期无法满足",
  "涉及角色": ["采购员", "供应商", "仓储员"],
  "前置条件": "订单已审核未收货",
  "正常流程": [
    "采购员发起变更申请",
    "系统校验变更合规性",
    "更新订单交期/数量/价格",
    "通知供应商和仓储员"
  ],
  "异常流程": ["订单已部分收货时禁止修改数量"],
  "预期结果": "订单变更记录可追溯，上下游同步更新"
}

3.3 痛点的分层挖掘

痛点是角色在场景中期望与现实的差距。将痛点按“业务影响 × 发生频率”分层，能快速识别哪些痛点值得进入本次功能边界。

• 第一层（致命痛点）：业务无法闭环（例如：采购订单无法推送至财务系统）。
  → 功能边界必须覆盖，无妥协空间。
• 第二层（效率痛点）：操作步骤多、数据重复录入、审批链路长。
  → 功能边界需明确优化目标（如“减少 3 次点击”）。
• 第三层（体验痛点）：界面不直观、字段含义模糊、反馈延迟。
  → 功能边界可后置或分批交付。

用户访谈时采用“5 个为什么”引导法：

1. “这个场景中你最耗时的操作是什么？”（定位效率痛点）
2. “如果这个操作不做，会有什么后果？”（判断致命性）
3. “你尝试过什么临时方案？”（发现隐性需求）
4. “理想情况下你希望几步完成？”（定义边界上限）
5. “哪些情况你会放弃使用系统？”（识别边界红线）

3.4 角色‑场景‑痛点映射矩阵

将前三步成果汇总为一张映射矩阵，功能边界在矩阵交集处自然浮现。灰色单元格表示“该角色在该场景中无对应痛点”，可排除出本次边界。

矩阵中“致命”痛点的单元格，构成本次功能边界的必选项；“效率”痛点根据资源情况决定是否放入 MVP；“—”单元格直接排除。边界定义从矩阵的“非空行、非空列”交集处导出，杜绝无依据的功能堆砌。