实例解析：看板的九种泳道划分

去过游泳馆人都会发现游泳池里不止一条泳道，而是划分了多条泳道让游泳运动员在不同的泳道里游泳，避免影响彼此的速度。应用这个思想，以一定的规则将整个看板划分为不同的泳道。泳道划分的规则由每个团队根据自己的需要来定，常用的划分方式有以下九种。

按照工作项类型划分泳道

比如，需求、缺陷、技术改进属于不同的工作类型，把它们放到不同的泳道里流动，这样团队就可以一目了然地区分出不同的工作类型。此外，只从事某一类工作项的同事可以只关注那条泳道即可，不需要受其他类型的工作项干扰。

下图是一个团队建立的看板原型，分为三条泳道：新功能、缺陷、工具导入工作。这个团队定义的“工具导入”工作指的是搭建持续交付工具，这类工作不直接为客户或用户产生价值，属于投资类工作，因此将它与新功能、缺陷两条泳道并列。

按工作项类型划分泳道

按照项目划分泳道

很多团队同时做多个项目，虽然团队在多个项目来回切换会影响专注性，降低高价值项目的产出，但这是很多企业的现实。看板方法的原则之一正是从现在的工作流程开始，实施渐进式变革。因此，建立看板的时候，可以按照项目划分泳道，不同项目的工作项在不同的泳道流动。

如下图，某企业的一个团队承担了多个项目的交付工作，因此为每个项目建立一个独立的泳道。

按项目划分泳道

按照版本划分泳道

有些团队的产品版本不是线性推进，而是多个版本并行交付。比如，团队为一个版本做系统验证的同时，启动下一个版本的设计和开发，于是自然地演进了按版本划分泳道的看板。如图，某企业一个团队的看板中，“第1批”、“第2批”“第3批”泳道分别代表产品的第1个版本、第2个版本、第3个版本。

按版本划分泳道示例

按照平台划分泳道

很多互联网产品团队做的产品在不同的平台上发布，包括PC端、移动端，而移动可能会细分是安卓系统、苹果系统、微信小程序。不同的平台需要交付的需求可能有所不同。下图是某金融企业手机银行团队的看板，他们交付的软件包括安卓和iOS两个平台，两个平台各占用一条泳道，平台专有的特性在这两个泳道里流动。此外，还有个“其它”泳道，两个平台通用的需求在这个泳道里流动。

按平台划分泳道

按照人员划分泳道

有的团队喜欢以人为单位划分泳道，团队的每个成员都有一条专属泳道,如下图。这种团队一般是每个人做一个独立的领域或项目，与其他人没有协作。这样的团队确切的说不是一个团队，他们是由零散的、互不相干的人拼成的一个职能组，把大家的工作在一个看板上，主要是方便团队Leader管理和跟踪每个人的工作。

按人划分泳道

一般情况下，要尽量避免按照人来划分泳道。因为这样划分后每个人只关注自己的泳道，削弱了团队成员彼此的协作。看板管理的核心是管理价值的流动，而不是单独关注每个人名下的工作。

按照团队划分泳道

对于多团队协作交付的大型项目，如果在整个产品内建立看板，产品的负责人往往会召集各团队的负责人一起来管理整个产品的价值流。这时候建立的产品级看板，一般以团队为单位划分泳道。下图是某金融企业的一个产品级看板，每个团队是一个泳道，从而为整个产品提供一个完整的二维视图：纵向的看板列是价值流动的过程，横向的泳道表示是哪个团队交付价值。如果将各团队需求之间的依赖和协作关系可视化出来，就提供了良好的跨团队协作的平台。

下图的产品有四个团队协同交付，因此每个团队各自占用一条泳道。工作项上的窄便签条代表对其他团队的依赖。

按团队划分泳道

按照服务级别划分泳道

前面文章有介绍，不同服务级别的处理策略及投入的人力都会有所不同（参考原文：还在为产品优先级决策犯愁吗：教你服务级别分析方法）。即使在日常生活中，将服务级别引入泳道设计也很常见。比如，高速路上有小客车道、客车道，货车，应急车道，每条车道上允许的车速不同(下图)。越靠内的车道允许的速度最快，越靠外的车道速度越慢。最靠外的车道是应急车道，正常情况下禁止行驶。当堵车的时候，你会发现警车、救护车、消防车可以在应急车道上行驶。由此可见，不同用途的车享受不同的道路服务级别，而且分道行驶。

按服务级别划分泳道

下图是一个团队建立的看板原型，依据服务级别划分为“加急通道”、“常规需求”、“工程实践专项”三个泳道。“加急通道”代表最紧急的工作项，比如网上订单无法下达，或者下单后无法付费等严重问题，需要立即解决，零等待；“常规需求”泳道代表非紧急类型的产品需求，每个需求依据优先级排出开发的先后顺序后进入看板；泳道“工程实践专项”，代表代码重构、补充自动化测试脚本等工程实践工作，这类工作属于投资类服务级别。

按服务级别划分泳道

混合使用多种方法划分泳道

以上介绍的各种泳道划分方法，团队可以根据自己的需要混合使用。下图是某团队的看板，最上面的“加急”泳道用于走紧急的需求或缺陷, 这样的工作项需要当天交付，而且越快越好。然后，“主线”、“支线”两条泳道对应不同平台的需求，而每个平台泳道又划分为两个子泳道“2.4”和“3.0”，对应两个不同的版本的工作；除了需求和加急通道以外，专门为缺陷开设了“缺陷”泳道。“缺陷”泳道又划分为两个子泳道：2.4版本和3.0版本。再次，团队的非价值交付类工作项，比如招聘、培训等事务性工作都放到了“其他”泳道来管理，这些工作的流程步骤比较简单，与上面的泳道价值流不同，它们只需要三个环节：“To Do”, “Doing”,“Done”。

几条泳道混合

泳道的拆分和合并

在有并发活动的时候，经常会根据需要将泳道拆分为子泳道，然后再合并起来。如图某团队的看板，需求A经过“Backlog”、“分析”后，在开发工程师编码的同时，测试工程师需要开发测试脚本，因此团队复制了一个与“开发”列内同样的需求卡片，把它放在下面的“测试开发”子泳道流动。当开发结束后，需求流动到“开发Done”列；当复制的卡片也完成了测试脚本开发后,流动到“测试开发Done”列，复制的卡片生命周期结束，原需求卡片继续流动到“测试准备好”列。