第3章 泳道图建模前置条件与输入物
适用场景
本章适用于以下场景：
- 产品经理需要绘制泳道图来梳理跨角色、跨系统的业务流程。
- 已有初步的业务想法，但缺乏结构化输入，导致泳道图反复修改。
- 团队协作中，开发和测试对泳道图的理解存在歧义，需要统一输入物质量标准。
- 从零开始构建新功能模块的业务流程模型。
前置条件
启动泳道图建模前，必须确认以下条件已满足：
- 已完成用户调研或业务方访谈，初步定义业务目标。
- 已确认泳道图建模的边界范围（端到端流程 vs 子流程）。
- 已获得业务方授权，可访问相关系统接口文档。
- 团队具备泳道图工具（如 Visio、Draw.io、Figma）基本操作能力。
操作步骤
- 收集业务场景描述：通过访谈或文档，获取包含触发条件、正常流程、异常分支的完整场景文本。
- 建立角色清单：列出所有参与角色（人、系统、定时器），明确每个角色的职责边界。
- 固化事件触发：识别流程启动事件（用户操作、系统回调、定时任务、外部消息），并定义事件数据格式。
- 梳理系统接口说明：整理现有系统的 API、数据库表、消息队列等接口能力，标注同步/异步、超时、错误码。
- 合并输入物并校验：将以上四项输入物合并为一份“建模输入清单”，由业务方和技术负责人双签确认。
- 进入泳道图绘制：使用工具创建泳道，按角色分配活动，按事件和时间顺序排列步骤。
输入输出物
| 类别 | 输入物 | 输出物 | 质量要求 |
|---|---|---|---|
| 业务场景描述 | 原始调研笔记、用户故事、业务方邮件 | 结构化场景描述文档（包含主流程+异常路径） | 每个场景必须有唯一 ID、前置条件、后置条件 |
| 角色清单 | 组织架构图、系统部署拓扑 | 角色与职责对照表 | 角色名称无歧义，职责覆盖所有流程步骤 |
| 事件触发 | 系统日志、事件定义文档 | 事件触发矩阵（事件类型→触发源→数据载荷） | 每个事件必须有明确的触发源和预期响应 |
| 现有系统接口说明 | API 文档、数据库 ER 图、消息队列配置 | 接口能力清单（接口名、方法、入参出参、错误码） | 接口状态需标注“已上线/待开发/废弃” |
责任边界
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品经理 | 主导场景描述编写、角色清单定义、事件触发提炼 | 建模输入清单 V1.0 |
| 系统架构师 | 提供系统接口说明，确认数据流边界 | 接口能力清单 |
| 业务方代表 | 审核场景和角色的准确性，签字确认 | 签字确认邮件或会议纪要 |
| 测试工程师 | 基于输入物编写泳道图验证用例 | 泳道图验收测试脚本 |
记录材料
- 会议纪要（场景调研、接口确认会议）
- 建模输入清单（包含四个输入物及版本号）
- 签字确认截屏或扫描件
- 泳道图初稿版本（如有）
异常处理
常见异常场景及处理方案：
- 业务场景描述模糊：通过 5W1H 模板重新提问，要求业务方提供具体用户操作路径。
- 角色清单遗漏：在本章步骤 2 后加一次“角色气球图”验证，确保所有泳道都被覆盖。
- 事件触发数据格式不统一：制定预设的事件数据模板（JSON Schema），强制统一。
- 系统接口文档过时：架构师需要在接口说明中标注接口状态，对未上线接口标注“待确认”并注明计划上线时间。
- 输入物多方冲突：组织一次“输入物对齐会”，现场逐条确认，并更新建模输入清单版本。
验收标准
- 所有输入物均已结构化存档，可通过统一 ID 追溯。
- 角色清单中每个角色都有明确的职责描述，且与泳道图上的泳道一一对应。
- 事件触发矩阵覆盖所有流程启动和分支条件。
- 系统接口说明已标注状态，且至少包含输入输出参数和典型错误码。
- 业务方和架构师已签字确认建模输入清单。
实操技巧：在收集“业务场景描述”时，建议使用统一的模板，避免描述粒度不一致。以下是一个推荐模板：
场景ID: SC-001
场景名称: 用户提交退款申请
前置条件: 用户已登录且订单状态为“已支付”
触发事件: 用户在订单详情页点击“申请退款”
主流程:
1. 用户填写退款原因并提交
2. 系统校验退款规则
3. 系统创建退款工单
异常分支:
a. 订单超过退款时限 → 提示用户“已超出退款时间”
b. 退款校验失败 → 提示用户“退款申请未通过”
后置条件: 退款工单状态变为“待审核”