第4章 用户故事与场景拆解：用户画像、痛点分析、核心场景地图、功能依赖关系

4.1 适用场景

本流程适用于以下情形：

• 产品团队已完成初步战略方向（见第3章），需要将业务假设转化为可验证的用户故事。
• 存在多个潜在用户群体（B2B/B2C/混合），需精细化区分核心用户与次要用户。
• MVP范围因用户场景冲突而频繁摇摆，急需建立场景优先级共识。
• 开发与产品人员对功能关联性理解不一致，导致重复开发或遗漏关键链路。

4.2 前置条件

• 已完成用户研究基础访谈（至少3个行业专家或典型用户）。
• 已梳理业务假设清单（参见第3章输出物《假设验证矩阵》）。
• 团队已确定参与拆解的角色清单（产品经理、开发代表、UX设计师各至少1名）。
• 具备可视化工具（白板/在线协作工具或实物便签板）。

4.3 操作步骤

1. 构建用户画像（Persona）：基于访谈成果，为每个目标角色创建人物卡片，包含人口特征、行为习惯、核心目标。
2. 痛点映射（Pain Map）：针对每个画像，列出其在当前流程中遇到的具体困难、效率损失或情感落差，用“当……时，我感到……”句式记录。
3. 生成核心场景地图（Core Scenario Map）：选择最高频/最痛的2~3个场景，以“用户-触发-行为-结果”四要素描绘完整故事线。
4. 提取功能依赖关系（Dependency Graph）：将场景中的行为拆解为原子功能，识别前置/后置依赖、数据共享关系与外部系统接口。
5. 输出MVP场景优先级：结合依赖紧密度与痛点严重度，标记各场景的优先级（P0~P2），并锁定本轮MVP必须覆盖的场景边界。

4.4 输入输出物

类别	输入物	输出物
数据	用户访谈记录（原始文本/录音整理） 业务假设清单（第3章输出）	用户画像卡片（每个角色1张，共3~5张） 痛点分析表（按画像分组）
模型	场景框架（第2章输出MVP边界）	核心场景地图（2~3个完整故事线） 功能依赖关系图（包含节点与箭头）
决策	团队优先级原则（从第3章的假设验证矩阵中提取）	场景优先级分类（P0/P1/P2） 本轮MVP场景边界确认

4.5 责任边界

• 产品经理：主持画像构建与场景拆解，保证用户视角不被稀释；负责输出最终场景地图。
• UX设计师：主导痛点映射，使用叙事可视化方法（如用户旅程地图）；绘制功能依赖草图。
• 技术负责人：从技术可实现性角度校验依赖关系中的关键数据流与外部服务。
• 数据/运营（可选）：提供定量辅助数据（如用户行为统计），验证痛点发生的真实频率。

4.6 记录材料

以下文件需在流程结束后归档至产品共享目录（如 Confluence / 飞书文档）：

• user_personas_v1.json —— 用户画像结构化数据（JSON格式）
• pain_map_report.md —— 痛点分析报告（Markdown）
• core_scenario_map.drawio —— 场景地图源文件
• dependency_graph.md —— 功能依赖关系表（含数据共享字段说明）
• mvp_scenario_priority.md —— 场景优先级判定与边界说明

4.7 异常处理

常见异常	处理方式
画像数量过多（>5个）	按用户价值权重（MAU/营收贡献）筛选Top 3，次要用户合并到一个“非主流角色”画像。
痛点描述过于泛化	强制要求每个痛点附带至少1个具体事例（“上周我花了3小时手动对账”），不得只写“效率低”。
场景地图中存在循环依赖	在依赖图中用虚线标出循环链路，并在MVP计划中注明需通过技术调研或折中方案解决。
开发团队对依赖关系优先级有争议	举行5分钟“依赖仲裁桌”：按“无该功能则核心场景完全不可用”等价于P0，否则降级为P1。

4.8 验收标准

1. 每个用户画像包含：姓名、头像示意图（文字描述）、背景、目标、技术熟悉度。
2. 痛点分析表覆盖至少80%的访谈提及问题，并标注严重度（高/中/低）。
3. 核心场景地图中每个故事线的“触发→行为→结果”逻辑闭环，无遗漏步骤。
4. 功能依赖关系图中所有节点均有指向关系（单向箭头），无孤立节点。
5. 场景优先级划分经过团队投票通过（简单多数），且MVP场景边界在依赖图中可用红色虚线框标识。

4.9 场景拆解与依赖关系图