泳道图指南：是什么、何时使用，以及如何制作

普通流程图显示发生了什么。泳道图显示发生了什么以及谁负责每个步骤。当流程跨越团队边界时，这种区别很重要——大多数重要流程都是如此。

本指南介绍泳道图是什么、何时是正确的选择，以及如何创建有效的泳道图。

泳道图一览

元素	表示含义
泳道（行/列）	一个角色、团队、部门或系统
泳道中的步骤	由该角色负责的工作
跨泳道箭头	角色之间的交接
泳道中的决策	由该角色做出的选择

想快速做一张泳道图？使用泳道图制作工具——描述流程及各方职责，AI 会为你布置泳道和交接关系。

什么是泳道图？

泳道图是一种分为水平或垂直带（泳道）的流程图，每条泳道代表一个人、团队、部门或系统。活动放置在负责该活动的参与者的泳道中，使参与者之间的交接可见。

名称来源于其视觉上与游泳池泳道的相似之处——不同角色在各自指定空间内工作的平行轨道。

基本结构：

┌─────────────────────────────────────────────────┐
│ 客户       │ 提交订单 ──→ 接收确认                │
├─────────────────────────────────────────────────┤
│ 销售       │ 审查订单 ──→ 批准？                  │
│            │               ├─ 是 → 处理           │
│            │               └─ 否 → 通知           │
├─────────────────────────────────────────────────┤
│ 仓库       │ 拣货 ──→ 包装 ──→ 发货               │
├─────────────────────────────────────────────────┤
│ 财务       │ 生成发票 ──→ 收款                    │
└─────────────────────────────────────────────────┘

每个活动位于负责方的泳道中。跨越泳道边界的箭头表示交接——工作从一个人或团队转移到另一个人或团队的时刻。

泳道图 vs. 普通流程图

两者都是有效的工具。问题是哪一个适合你的情况。

方面	普通流程图	泳道图
显示	发生了什么（序列）	发生了什么 + 谁来做
最适合	单人或单团队流程	跨职能流程
复杂度	创建和阅读更简单	更复杂但信息更丰富
交接	不可见	明确可见
瓶颈检测	较难——责任不明确	较易——可以看到哪条泳道负担过重
所需空间	紧凑	更宽/更高——需要更多空间

使用普通流程图时：

一个人或团队处理整个流程
流程简单且线性
你在记录技术逻辑（算法、决策树）
空间有限（幻灯片、报告）

使用泳道图时：

涉及多个人员、团队或系统
交接点导致延误或错误
你需要明确责任
你在改进跨职能流程

关键组件

泳道（或池）

每条泳道代表一个参与者：

人员： "经理"、"员工"、"客户"
团队： "销售"、"工程"、"支持"
系统： "CRM"、"支付网关"、"数据库"
角色： "审批人"、"审查人"、"请求者"

将泳道保持在 3-6 个参与者。超过 6 条泳道就难以阅读了。

活动

放置在负责方泳道中的流程步骤。使用标准流程图形状：

矩形用于流程步骤
菱形用于决策
圆角矩形用于开始/结束
平行四边形用于输入/输出

交接

跨越泳道边界的箭头。这些是最重要的元素——交接点是流程通常崩溃的地方。每个跨泳道箭头代表一个时刻：

信息在团队之间转移
可能发生延误（等待对方）
可能发生误沟通
责任转移

序列流

显示步骤顺序的泳道内箭头。与普通流程图箭头相同，但在交接点之间限制在单条泳道内。

何时使用泳道图

跨部门流程

任何涉及多个部门的流程都受益于泳道可见性：

采购： 请求者 → 审批人 → 采购 → 供应商 → 接收 → 财务
招聘： 招聘经理 → HR → 招聘人员 → 面试小组 → HR → 入职
客户投诉： 支持 → 产品 → 工程 → QA → 支持 → 客户

识别交接瓶颈

如果流程很慢，泳道图会揭示原因。当你看到箭头频繁跨越边界时，每次跨越都是潜在的延误点。减少跨泳道交接通常可以提高流程速度。

合规和审计文档

受监管的行业需要清晰的问责记录。泳道图精确显示每个步骤谁负责，审计师和合规官员对此表示赞赏。

软件开发工作流

开发工作流自然涉及多个角色：

产品经理    │ 编写需求 ──→ 优先排序
─────────────────────────────────────────────────
开发者      │ 实现 ──→ 代码审查 ──→ 修复
─────────────────────────────────────────────────
QA          │ 测试 ──→ Bug？ ──→ 验证修复
─────────────────────────────────────────────────
DevOps      │ 部署到暂存 ──→ 部署到生产

何时不使用泳道图

单人流程。 如果一个人做所有事情，泳道增加了复杂性而没有价值。
简单的线性流程。 5 步顺序流程不需要泳道。
技术算法。 代码逻辑没有"部门"。使用普通流程图。
快速沟通。 当你需要在 30 秒内解释一个流程时，简单的流程图更清晰。

如何创建泳道图：分步说明

第一步：定义流程和范围

设置清晰的边界：

起始事件： 什么触发了流程？（例如，"客户提交订单"）
结束事件： 什么标志着完成？（例如，"订单已交付并收款"）
范围： 包含什么，排除什么？

第二步：识别参与者

列出流程中涉及的每个人。将类似角色分组：

不要为"初级开发者"和"高级开发者"创建独立泳道——使用"工程"
如果"财务"和"法律"有不同的活动，则分开
如果系统执行自动化步骤，包括系统

第三步：列出所有活动

写下流程中的每个步骤，不管顺序如何。对于每个活动，注意：

发生了什么
谁来做（哪条泳道）
什么触发它
它产生什么

第四步：安排序列

在各自泳道内按时间顺序放置活动。用箭头连接它们。用菱形标记决策点。

第五步：识别交接

在工作转移的地方绘制跨泳道箭头。对于每个交接，考虑：

需要转移什么信息？
交接通常需要多长时间？
在这一点上可能出什么问题？

第六步：审查和验证

与实际流程参与者一起走查图表：

这与实际情况匹配吗（而非理想状态）？
有遗漏的步骤吗？
交接准确吗？
泳道分配正确吗？

常见泳道图示例

采购订单审批

请求者   │ 创建 PO ──→ 附报价 ──→ 提交
───────────────────────────────────────────────────
经理     │ 审查 ──→ 低于 $5K？ ──→ 是 → 批准
         │                        └─ 否 ↓
───────────────────────────────────────────────────
总监     │ 审查 ──→ 低于 $25K？ ──→ 是 → 批准
         │                         └─ 否 ↓
───────────────────────────────────────────────────
VP/CFO   │ 审查 ──→ 批准/拒绝
───────────────────────────────────────────────────
采购     │ 创建订单 ──→ 发给供应商 ──→ 追踪
───────────────────────────────────────────────────
接收     │ 接收货物 ──→ 检验 ──→ 确认
───────────────────────────────────────────────────
财务     │ 匹配 PO/发票 ──→ 处理付款

Bug 修复工作流

客户支持 │ 接收报告 ──→ 能复现？ ──→ 否 → 请求详情
         │              └─ 是 ↓
─────────────────────────────────────────────────────
工程     │ 分类 ──→ 优先级？ ──→ 关键 → 热修复分支
         │                    └─ 普通 → 冲刺待办
         │ 实现修复 ──→ 代码审查 ──→ 合并
─────────────────────────────────────────────────────
QA       │ 测试修复 ──→ 通过？ ──→ 否 → 返回工程
         │                        └─ 是 ↓
─────────────────────────────────────────────────────
DevOps   │ 部署 ──→ 监控
─────────────────────────────────────────────────────
客户支持 │ 通知客户 ──→ 确认解决

最佳实践

将泳道保持在 3-6 条。 超过 6 条泳道使图表难以阅读。如果你有更多参与者，考虑对相关角色进行分组或拆分为子流程。

按交互频率排列泳道。 将相互交互最频繁的泳道放在相邻位置。这最大程度减少了箭头交叉并使交接更清晰。

显示真实流程，而非理想流程。 记录实际发生的事情，包括变通方法和非正式步骤。你可以稍后创建改进版的"目标状态"。

突出显示痛点。 用视觉提示标记常见延误点、容易出错的交接或瓶颈。这使图表立即具有可操作性。

使用一致的符号。 遵循标准流程图符号。决策菱形、流程矩形和终止符椭圆在每个图表中应该有相同的含义。

常见错误

太多泳道。 每个角色都有自己的泳道，导致 10 条以上没人能阅读的泳道。对相关角色进行分组。

混合细节级别。 一条泳道有 15 个详细步骤，而另一条只有 2 个高层次步骤。在各泳道保持一致的粒度。

忽视交接。 活动被记录了，但泳道之间的箭头没有受到关注。交接是流程崩溃的地方——在那里集中注意力。

图表太大。 需要滚动或缩放的泳道图失去了它的价值。如果流程对一页太大，拆分为子流程。

使用 AI 创建泳道图

泳道图传统上创建耗时，因为有泳道结构和跨边界连接。像 Flowova 这样的工具可以从文字描述生成泳道式图表——描述你的流程，提到负责方，然后得到一个可以优化的结构化图表。

对于更复杂的泳道需求，Flowova 的泳道图制作工具专为跨职能流程可视化设计。