看板可视化四步法

我每次做看板培训的时候都会拿出来两个照片问学员：“如果你走近图（图1）这两个团队的工作区，觉得哪个团队的效率更高一些？”

 

图1-两个团队的工作区

资料来源：Henrik Kniberg的博客

不同的人意见不同，选择团队1和团队2的人数参半。由此可见，如果没有可视化，大家就只能靠主观感觉来判断项目和团队的状况，而主观感觉很可能与实际情况有偏差。
当看到这两个团队建立的看板后，真实情况浮出水面，如图2：第一个团队做结对编程，每个工作项都有人在处理，工作项的平均周期时间（Average Lead Time）只有3天；而第二个团队，看板上有大量闲置的工作项无人处理，工作项的平均周期时间（Average Lead Time）长达12天之久。
 

图2-两个团队的看板及工作项平均周期时间

资料来源：Henrik Kniberg的博客
因此，看板能够帮助团队依据事实和数据做决策。看板方法本身并没有规定需要可视化哪些内容，但是至少需要包括团队管理价值流动的基本元素。一般来说，看板可视化需要设计以下内容：
 

•  过程改进的起始点和终止点：这决定了看板的范围。
•  看板的列：用于可视化价值流经哪些环节
•  看板的泳道：依据不同的工作项类别，或者不同的工作项的服务级别等划分泳道
•  工作项：可视化工作项的信息

看板可视化第1步：定义过程改进的起始点和终止点
完成价值流映射后，团队需要思考看板从哪里开始导入。最理想的情况是涵盖从开始提出Idea，到将Idea交付给客户或用户为止的整个全价值流过程。但理想是美好的，现实是骨感的。很多发起敏捷转型的组织对端到端的流程没有全局的控制权力，他们能够影响的是其中的一部分。因此，他们往往从这一部分开始引入看板，再逐渐影响其上、下游接入看板系统，最终将看板系统延展至端到端的价值流。
因此，过程改进的起始点和终止点的选择比较容易：从你能够控制的范围开始。

看板可视化第2步：设计看板的列
以完成的价值流图（图3）为输入，就可以设计出工作项需要流经的看板的列，如图4所示。

图3-价值流映射示例

 

图4-设计看板的列

需要注意的是，每列分成“进行中”和“完成”两个子列。“完成”列是为下游准备输入的等待列。

常见误区：没有子列的看板
很多团队设计的看板没有区分“进行中”和“完成”两个子列，在这样的看板里，当上游处理完一个工作项后，将工作项直接推到下游。因此，工作项从上游的“进行中”直接流到了下游的“进行中”，这样的看板不是拉动式生产，而是典型的推动式生产。严格的说，这样的看板不是看板。
为什么一定要分成“进行中”和“完成”两个子列呢？因为“完成”列给下游一个指示信号，提示上游工作已经完成，可以拉动，开始下游的工作。

看板可视化第3步：设计看板的泳道
去过游泳馆人都会发现游泳池里不止一条泳道，而是划分了多条泳道让游泳运动员在不同的泳道里游泳，避免影响彼此的速度。应用这个思想，以一定的规则将整个看板划分为不同的泳道。泳道划分的规则由每个团队根据自己的需要来定，常用的划分方式有以下：
按照工作项类型划分泳道
比如，需求、缺陷、技术改进属于不同的工作类型，把它们放到不同的泳道里流动，这样团队就可以一目了然地区分出不同的工作类型。此外，只从事某一类工作项的同事可以只关注那条泳道即可，不需要受其他类型的工作项干扰。
图5是一个团队建立的看板原型，分为三条泳道：新功能、缺陷、工具导入工作。这个团队定义的“工具导入”工作指的是搭建持续交付工具，这类工作不直接为客户或用户产生价值，属于投资类工作，因此将它与新功能、缺陷两条泳道并列。

 

图5-按工作项类型划分泳道

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

 

图6-按项目划分泳道

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

 

图7-按版本划分泳道示例

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

 

图8-按平台划分泳道

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

 

图9-按人划分泳道

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

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

 

图10-按团队划分泳道

按照服务级别划分泳道
不同服务级别的处理策略及投入的人力都会有所不同。即使在日常生活中，将服务级别引入泳道设计也很常见。比如，高速路上有小客车道、客车道，货车，应急车道，每条车道上允许的车速不同(图11)。越靠内的车道允许的速度最快，越靠外的车道速度越慢。最靠外的车道是应急车道，正常情况下禁止行驶。当堵车的时候，你会发现警车、救护车、消防车可以在应急车道上行驶。由此可见，不同用途的车享受不同的道路服务级别，而且分道行驶。

 

图11-按服务级别划分泳道

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

 

图12-按服务级别划分泳道

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

 

图13多种方法混合划分泳道

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

 

图14-子泳道示例

看板可视化第4步：设计看板的工作项卡片
在看板上将工作项用卡片的方式可视化。卡片的设计要遵循“足够好”的原则，即: 卡片对工作项的状态和风险的呈现有一目了然的效果，足以让团队依据卡片的信息做决策。如图15所示，工作项可视化的信息一般会包含下面这些内容：

 

图15-工作项卡片模版

下面详细介绍每个信息。
卡片类型或服务级别
不同类型或者不同服务级别的工作项用不同的颜色标识，以便于区分。用什么颜色都无所谓，简单实用即可。要达到的效果是：当团队站在看板前，不需要猜测或询问某个卡片代表的含义。例如，团队在建立看板的时候可以这样约定（图16）:

 

图16-工作项的颜色定义

标题和ID
每个工作项卡片都需要有个标题，用一句话来描述卡片做什么。如果团队用电子系统管理工作项，每个卡片上一般还会有一个ID号，作为卡片在电子系统里的唯一编号。
负责人
卡片责任人可以用任何团队喜欢的方式来可视化。很多团队在卡片上直接写上负责人，如图17所示。

 

图17卡片责任人可视化方法

但是这个方法有两个缺点:
 不直观，大家需要走近看板将卡片拿到手里才能看清负责人的名字
 要改变责任人的时候，需要修改卡片上责任人的名字
一个灵活的小窍门是用磁贴标识责任人，如图18所示，将名字写在磁贴上，而磁贴可以自由移动到任何的卡片上。

 

图18-在磁贴上可视化责任人

图19是“阿凡达 ”可视化方法，即用替身图片代表某个人。这种方法让看板变得可爱，有助于营造轻松活泼的工作氛围。

 

图19-用阿凡达可视化责任人

卡片的优先级顺序
对于如何标识优先级顺序，每个团队有自己的习惯。常见的有：
 绝对的数字序号1，2，3，4，5… ….；
 没有明显标识，但是在看板队列里从高到低按照优先级的顺序摆放卡片，从而团队明确地知道下一步该做哪张卡片

常踩的坑：
很多团队看板上的大量卡片甚至所有卡片的优先级写的是“ASAP”, 即“As Soon As Possible”越快越好。
优先级的定义相是对的，即A相对于B更重要，B相对于C更重要。如果大量卡片都是ASAP，那就说明团队没有真正分析工作项的优先级。如果所有的工作都一样重要，那么可能，没有真正重要的工作。
常踩的坑：
很多团队的看板上没有呈现任何优先级的信息，包括卡片上的标识，以及看板上的卡片按照优先级摆放等可视化手段都没有。优先级信息掌握在个别人的脑子里。
如果没有任何可视化，团队只能盲目拉动卡片开发。出于人的本能，会拉动工作量小、容易完成的那些卡片，从而违背了价值优先的原则。

常见疑惑：优先级顺序与7.3节介绍的服务级别有什么区别？
答：服务级别是从延期成本的角度对工作项的服务等级进行了分类，而优先级顺序是工作项之间相对的关系。比如：同样对于固定截止日期的工作项A和B，A的截止日期更近些，同时工作量也更少些，那么工作项A应该比工作项B的优先级顺序靠前，团队优先拉入A启动。由此可见，对工作项排优先级顺序的时候，应该先按照服务级别分类，然后，对于同一服务级别的工作项再排优先级先后顺序。

卡片的描述
不同类型工作项的描述格式会有不同。对于需求，一般会采用用户故事的格式描述(8.4节介绍)。对于缺陷，每个公司一般会定义自己的描述模板。
卡片的规模/工作量
在不同的企业，甚至是同一个企业里的不同团队都可能会采用不同的工作量估算方式。以下方式是常见的工作量估算方式：

 自然天。即：一个工作项预计需要多少天完成。
 故事点。即：一个工作项需要几个点数。点数是虚拟的没有单位的相对度量单位。
 小时数。对于将需求拆分为技术实现任务的工作项，可以更细粒度估算到小时。
此外，估算不是必须的，取决于团队的成熟度和工作习惯，以及需求拆分的粒度。需求拆分得越小，估算的必要性越小。

团队根据自己的需要，可以记录以下时间信息：

 卡片的启动日期，即：卡片开始进入看板就绪队列的那一天。如果用我们去饭店吃饭做比喻的话，启动时间相当于我们点完菜后下单的那一刻，作为饭店上菜周期时间（Lead Time）计算的起点。
 卡片的实际完成日期，即：卡片流动到看板最后一列的那一天。如果用我们去饭店吃饭做比喻，实际完成时间相当于饭店服务员将菜端到我们面前的那一刻，作为上菜周期时间（Lead Time）计算的终点。
有了卡片的实际完成时间和卡片的实际开始时间，就可以计算出卡片的周期时间（Lead Time）：
 

周期时间（ Lead Time）=卡片的实际完成时间-卡片的实际开始时间卡片的实际完成时间
如果团队用电子看板系统，卡片的开始时间和完成时间都是自动记录的，不需要人工记录。此外，很多具有度量统计功能的电子系统可以自动统计出周期时间。
 卡片的截至日期，或团队的承诺日期。对于固定交付日期类型的卡片，需要记录卡片要求的交付日期；对于非固定交付日期类型的卡片，如果团队已经向利益干系人承诺了交付日期，那么也应该记下这个日期，在每日站会的时候关注对于承诺的达成是否有风险。

常踩的坑：
很多团队喜欢更精细地管理，在卡片进入看板的队列后就开始详细地计划了卡片的开发启动日期、开发截至日期、测试启动日期，测试截至日期。
这样做貌似让计划很靠谱，团队有安全感，其实反而削弱了应对变化的灵活度。很多工作项在开发还未启动的时候，开发过程中会遇到什么困难是未知的。如果这时候就计划开发的截至时间，甚至用这个截至时间来推算测试预计的启动日期和截至日期，这样的测试计划实质是将开发过程中的不确定因素作为自己的一部分，这种过早计划不仅不靠谱，反而是一种管理浪费。更严重的负面作用是，当团队为每个工作项计划了开发启动时间、开发结束时测试启动时间、测试结束时间，团队就开始按照这个详细的计划执行。当特性A的开发截至日期临近的时候，如果此时有更高价值的特性B流入看板，团队为了确保特性A在原来计划的截止日期之前完成开发，会将更高优先级的特性B搁置，结果导致优先交付的是更低价值的工作。