产品经理的PRD文档包含需求背景、功能描述、业务流程、更新记录至少4部分。同时B端产品更侧重业务需求，所以业务流程的撰写占比会大于功能描述。

B端产品较多使用的是表单、弹窗、输入框控件，交互则是抽屉布局，导致功能描述较为简单，比如用户管理功能，就是由用户列表、用户详情组成、操作管理组成。

但B端的页面存在控制逻辑、配置边界、权限等规则，自然就产生了一个页面根本不可能就看需求文档的文字描述，就可以搞定了。

仅看一个后台操作，是看不出系统设计的背后逻辑、数据库结构、接口调用情况。比如上图后台中是用户权限管理的页面。

有表单字段、字段计算规则、以及表单访问前置条件、后置条件、都是需要一个更好的流程表达工具。

采用泳道图将业务流程、对象绘制出来，再区分开，是B端产品经理解决上面问题的最有效方式之一。

泳道图绘制4个步骤

⑴设计参与该流程的不同人员或工作功能，将他们列在海报或白板的左边或上方;

⑵依照业务将人员、功能列出步骤，并将其写在帖纸上；

⑶一一探讨这些步骤，并将贴纸贴在适当的泳道上；

⑷运用此结果来激发讨论应如何改善业务流程。

泳道图有事件流的顺序方向。从左到右组成的水平布局表达是某个事件流顺序，水平布局将不同部门负责的流程通过一条线隔起来，同时通过箭头将有关系的流程进行链接，通过垂直对接将对象、或时间独立出来。

垂直维度上标识同一个系统对象、事件效果。从上到下组成的垂直布局，表达的是同一个对象的流转顺序

一个事件流由多个对象组成，对象可以是职位部门、系统、业务名称不强行规定。

泳道图的垂直、水平布局构成了下方的标准泳道图样式。

搞清楚了泳道图的布局后，接下里就要搞清楚泳道图的颗粒单元、以及单元的使用规则。

产品经理常用的泳道图单元分为开始、结束、流程、判定、文档、子流程、数据库、注释7个版块。

用了以上的单元后我们还要来撰写事件流。在泳道图的事件流构成单元有下面8个。

角色：都有什么人参与到功能里来

事项：分别扮演什么角色，做什么事

信息的流向：要完成的任务，顺序

参与者：明确所有事件流的参与者，系统也是一个事件流的一环节参与则

关系:参与者之间的关系

目标：事件流的最终目标是什么

开始与结束：事件流的起点和终点

主流程：事件流的正向流程

异常流程：时间流的逆向流程

后台产品经理善用泳道图来表达需求。

如上是饿了么用户订餐的业务流程。包含正向流程、逆向流程、异常流程。

泳道图还包含了系统、骑手、用户、商家参与的4个对象角色。通过泳道图再此完成订单系统、支付系统、商家管理平台、用户操作界面4个功能集合。

泳道图是底层的系统核心，做产品不能脱离了业务。当然泳道图不仅是只是用来做业务梳理，还可以做关系结构、职场划分的功能。

只不过是产品经理将其用来讲清楚业务和系统、系统和人的关系即可。有了泳道图能摸清楚系统边界、开发成本。