简介

本文一共6000字左右，会涉及：

• 看见的力量；
• 从最简单和朴素的理解开始 —— 状态板；
• 让看板开始演化 —— 演化板；
• 看板三个阶段的演变过程；
• 系统持续优化 —— 精益看板；
• 度量哪些基本数据；
• 应用看板是否应该承诺交付时间点？
• 并行任务就应该避免吗？
• 一些可以参考的作业

阅读完成之后你会对看板有更深入的理解，并明确知道该如何实施看板来促进团队在敏捷状态下的协作。

看见的力量

想象一下，如果屋子的一个角落冒起了非常大的烟，这绝对是着火的迹象，你会作何反应？有的人就会“扭头就跑”，但其他人可能会“拨打火警电话”，甚至有人会“大声呼救”。1000个人面对这样的情况可能会有1000种选择，但为什么我们会不同选择的行动呢？

这是因为我们每个人头脑中的紧迫感不一样。有些人看到烟想起自己曾经的经历，权衡自己的状态，观察周围的情况，综合以上的种种才会产生一个特有的紧迫感。这特殊的紧迫感会驱动个体产生行动。

那紧迫感是因为什么产生的呢？是来源于看见，因为如果没有看到发生，那后面的紧迫感就无从谈起。

对于“看板”来说，我们有可能重视后面的字：板。就如同白马是马，饭桌是桌一样。我们要弄清楚什么是这样的一个“板”，然后再是如何使用这个“板”。

我认为这种观点错过了重要的一个内容，就是“看”字。这个字决定了我们如何设计后面的“板”。

当然，一下子看到太多的内容与细节，每一个人都会崩溃。一般来说我们的会……

从最简单和朴素的理解开始 —— 状态板

最入门（无序）的团队最希望看到什么呢？这其实是一个管理的问题，项目或产品的负责人想要看到的是进度和完成情况。经典项目管理的思路就是分解与执行，纠结的是，一旦项目领域涉及到知识工作进度跟进就不能像之前的粗放管理，恨不得吧团队成员每天写了多少行的代码，打了多少电话，编了多少页的幻灯片都进行拆分与跟进。

但这种跟进程度无法与任务的完成画上必然的等号，郁闷的管理者就会让执行者自己列出自己的待办任务，并以此实施进度跟踪。

这看似简单的三列板子和审视机制会神奇的……

提高个体执行意识

工作任务在一个集中的位置表现出来，每天跟进进度。你起码在例会的时候得有一些话说吧，如果昨天没有可以描述的工作，这就是工作态度问题了。这就如同房间里比较脏，但我逐个房间看一下：房厅是否干净，如果1-10分干净程度的话，你会打几分。

这会强制我们的关注点移动到人员近期的行动事项，从而强化了个体的执行纪律。

执行意识的提高只是一方面的好处，另一方面你会获得的是……

关注更高视角

当每一个人自己的任务的时候，不管这个任务是否在线性的一维度排列还是平面二维的排列。这个过程都会强化我们理解这个任务的其他维度信息。比如我们按照完成状态排列，就会从进度角度进行思考。如果按照任务复杂度排列，我们就会从工作量的维度进行思考。

二维平面的力量使我们一上来就可以强制使用者从两个维度进行思考。这个思考的方向是我们可以进行设计的。如果我们中长期关注的是进度，我们就可以设置“没干完”，“干完了”两列。

永远不要低估可视化的力量，哪怕你看到的是任何一副艺术品，这幅艺术品也会带给你不同的感受。但如果给你一些上下文的话你就会得到不同的感受，比如我说你看到的是彼此的关系图，任务的进度图等等。这些东西就会比邮件中的文字描述提供更多角度的信息。

作业

如果你对于一上来的状态板不知道如何设置，可以参考上面的形式自行调整。这里注意，研发完成的任务需要测试人员拖拽改变任务的状态，而不是研发自己觉得做完了就移动任务的。

如果你一直使用看板工具，个体执行意识的提高与更高角度的关注这两个好处团队会一直持续获得。 但任何的手段一段执行时间之后都会僵化和无聊。但如何应对这种状态呢？

你需要……

让看板开始演化 —— 演化板

在开始演化之前，先需要回答为什么要实现看板的演化。在满足单一的管理诉求之后，一方面我们需要使得看板与团队更加融合，另一方面个体的执行与更高的视角需要持续的强化。

什么是单一的管理诉求呢？对于项目或产品管理来说，进度控制就是假设的单一诉求。这也是为什么一上来我们通过状态板来展现进度的情况。并通过任务的状态来强化团队的执行与更高视角。

什么是看板与团队的融合呢？对于不同团队管理的重点是不一样的，比如说某些团队看中的是尽可能多的“完成”（销售），有些团队关注的是减少流程中的阻塞任务（重流程），有些团队关注的是完成之后的效果与影响（艺术）。而且这种不同的关注点千差万别，解决团队的主要矛盾（进度控制）之后，团队需要回到自己希望关注到的内容之上，并让每一个人真正的用起来。

为什么要再次强化个体的执行与更高的视角呢？敏捷性的提高从手段上来说就是不停的强化执行与提高视角的过程。执行的背后就是纪律，而纪律有从内向外的纪律，也有从外向内的纪律。当第一阶段我们发力于外部纪律（状态板）之后，我们需要逐渐向内部纪律上偏移。更高的视角其实是责任的扩展，责任范围越大其实团队选择的可能性也就越大。

纪律与视角的提高，就会使得团队不会在低层次的问题上不停徘徊，而会逐渐拥有更多的可能性。

总而言之看板演化的目标就是：

在管理上使团队与工具更加融合

融合是一个持续的过程，融合的背后是团队逐渐强化的思考能力：我们团队需要展现什么内容？我们有哪些风险可以进行抽象？有哪些团队规则需要强化？有哪些奖惩措施需要明确？

团队思考过程是重要的，在这个演化过程之中一个空降的外部专家可能不会闪闪发光，因为演化的过程是持续的，不是一个一次性的过程。

目标明确之后，就回到我们的关注点，关注点就是看板上的哪些具体的内容能够体现团队需要关注的内容？比如增加一个新的流程列，或在卡片上进行更多的标记等等。好处看上去很多，但如何能够……

启动看板演化的过程

教练或管理者，站在看板（状态板）前当着团队中领导力小组的成员说：

没错，就是强制让看板发生进化。让状态板逐渐真正成为看板。而且作为团队的教练或管理者可以鞭策他们，提醒他们，鼓励他们，夸奖他们。

这么多的理论支持，其实对于个人来说。就是让一切回到起点，也就是使用这块板子的起点———团队的协作平台。如果团队都不认可这个协作平台的话，那一切的建议内容可能只会让团队感觉有些新鲜感而已，一段时间的采用之后，就又回到团队之前的做事方法之上。还有，要让一个与团队交互更为密切的教练诞生———作为镜子的看板。这面镜子会让一切的转变衍生出来（参考《看板方法》¹），大部分团队真正的困扰在于如何真正的把看板当成一面镜子，他们一般只把看板当成一个模特、一个理想中的流程过程。这也就是我为什么非常避免自己给团队提出看板的具体改进建议。

这就会在更深的层次上强化文前提到的：提高个体执行意识 以及 关注更高视角。但有的时候这两个关注点是矛盾的，关注执行就不一定能够关注更高的视角，关注更高的视角就可能会脱离执行的细节。我们在团队状态板的阶段可以很简单粗暴的引入某种工具，但是在演化阶段就需要团队内部的改进力量来驱动管理细节的落地。这里总结一下：

看板演化的关键特征

1. 看板演化驱动主体必须为团队内部（外部可以给出建议，团队可以决定采纳或否决）
2. 看板细节持续且有节奏的调整（为什么调整？引领团队的视觉符号是什么？）
3. 演化时间比较长（以年为单位演进与优化）

作业（注意：不同团队演进方向不同）

团队在经历看板演化的过程其实就是强化自管理的过程，在这个过程的同时可以让团队了解看板第三个阶段 —— “精益看板”

在正式进入对精益看板的描述之前，需要描述与解释一下……

看板三个阶段的演变过程

状态板成为纪律之后有可能长时间停留在这个状态，当然也可以因为团队更为混乱而抛弃。抛弃可能代表着团队进入了混乱的管理状态，也可能代表团队不需要这种管理工具就能实现日常的运行与管理工作。但需要注意的是，越是稳定越不需要这种东西，越是变化剧烈充满不确定性才会需要这种管理手段。

当状态板运行一段时间之后，团队可以选择抛弃、坚持、演进。抛弃部分上一段已经描述了，坚持也不多介绍。开始演进其实对于团队的管理来说是一个质变的过程。因为状态板（不管多少列，不管设没设在制品限制WIP都一样）是外部影响的结果，坚持使用状态板可以内化管理手段，但是这不是敏捷转型所希望看到的现象。坚持使用状态板和传统管控性的产品管理没有任何本质区别。我只承认一个持续在看板演化过程中的团队为敏捷团队。当然这个状态和第三种阶段（精益看板）不矛盾。

可能一个持续演化的看板其实已经与团队长在了一起，生长的过程可能就已经实现精益看板的若干要求。但如果是精益看板的话肯定是一个演化看板，如果没有经历演化的看板只能是状态板。

当拥有精益看板关注点，从更为系统的角度进行优化的看板就成为……

系统持续优化 —— 精益看板

精益看板强调的某些东西，团队之前的看板状态也会有所涉及，但某些内容存在一定的门槛，或者说不合时宜。简单来讲就是让工作任务，尽晚的开始，尽早的结束。因为本部分文字不是针对精益看板进行普及性介绍，所以可以参考相关书籍。这里进行简单的概要描述：

• 可视化工作流（工作要经过哪些步骤？）
  • 可视化端到端的用户价值实现和交付过程
  • 逐渐更为整体进行优化，而不是优化局部
  • 这点基本比较好达成
• 显示化流程规则（如何让人们容易做正确的事情？）
  • 明确团队一致的规则，成为协作和决策的依据
  • 如果经历过看板演进，这点也会比较容易达成
• 限制在制品数量（如何不要让工作堆积在流程的任何一步？）
  • 加速流动、暴露问题、激发协作
  • 这点，很多团队实施过程遇到纠结，问题可能在：
    • 职责过于清晰，但工作边界也太过清晰。我为啥要帮助测试的人干活？我不会写代码啊，怎么帮开发？对于在制品限制我们限制之前需要观察，到底哪些价值列存在堆积？有哪些堆积？这些堆积是否对于我们的工作造成了影响？我们下面的优化领域是否是是这个领域？
    • 不要为了限制而限制，先要观察，先要承认系统中的现状。
• 管理工作流动（前置时间、周期时间、产能？关注哪些数据？）
  • 即时、有效地发现和处理问题，让团队顺畅运作
  • 这点其实就是度量数据，下面一段将详细描述
• 建立反馈循环并持续改进（您是否定期审查你的工作和流程？召开回顾会）
  • 指导深层次改进，渐进性演进
  • 这点将在回顾会议相关的文章中涉及

度量哪些数据

度量哪些数据都不宜僵化，什么是僵化呢？就是永远一直不停的关注持续下去。对于组织来说关注任何数据时间长了都会有共生进化（组织会随着关注点而变化，有可能有意想不到的结果）。正确的方式是有若干简单且基础的数据作为整体健康的抽查，对于重点关注的数据要周期性的调整。比如这几个月关注LeadTime（前置时间），过几个月关注缺陷率，再过几个月关注事件响应速度，又或者是系统堆积情况与关键岗位环节。

对于基础性的度量以下的内容可供选择：

• LeadTime （前置时间）
  • 从需求开始分析（从沙子移动到板砖的时间点）到上线（功能能够被用户感知到的时间点）
  • 优化方向：让系统更快
  • 共生可能方向：
    • 团队尽可能晚的确认需求开始分析（不期望）
    • 团队尽可能的拆分需求（期望）
• 各阶段缺陷数量
  • 从测试环境、UAT（客户验证）环境、生产环境下的缺陷数量与数量趋势
  • 优化方向：缺陷数量更少
  • 共生可能方向：
    • 瞒报缺陷数量（不期望）尤其小团队测试与研发一个负责人的时候
    • 纠结或探讨到底什么算是Bug（缺陷）（期望）
• 关键流程点任务堆积
  • 在某个流程点上停留的任务数量（堆积数量）或从上个工序完成到当前日期的日期跨度（堆积时间）
  • 优化方向：更少的堆积，更少的堆积时间
  • 共生可能方向：
    • 做完才拖动到下一个状态（时间状态不准确）（不期望）
    • 任务粒度更大（不期望）
• 用户及客户反馈
  • 针对某些项目或产品周期性的收集主管反馈
  • 优化方向：更积极的反馈
  • 共生可能方向：
    • 好好先生，掩盖问题（不期望，但这也可能促成协作双方/多方非正式的沟通）

对于度量来说，不能没有，也不能僵化，两种思路都不可取。

关于承诺纠结

看板的承诺让我想起了一个事情，看板之父，戴维安德森前几年准备出一本关于看板实践方面的书籍，让一位相关人员来到中国收集看板使用的素材信息。这个人来到中国非常吃惊的看到，看板上的每一个卡片都有承诺移交时间、估算、进度跟进等等信息。她震惊到这不是看板方法的关键点啊，这哪里是流水一般的改进，这简直是赤裸裸的剥削和压迫啊。

我想对她说，如果贵国的房贷和我们一样沉重，如果你们的系统和我们的一样耦合严重，如果你们的人员素质和我们一样参差不齐，如果你们的版本也和我们一样拥有无比的压力。你也会用我们相似的手段的。

所以科班的看板专家会说一个名词：置信区间 ²。也就是根据历史情况，我在85%的情况之下可能完成你给的任务 ³ 。你说对吧，也对。你敢这么跟上下游系统说吗？估计你会很惨。

但如果说给出直接承诺其实严格来说就已经和看板方法走向了不同的方向。我无法承认这就是经典意义上的看板方法，但退后一步来说，在这里纠结其实也没有多大的意义。

关于并行任务与WIP（在制品限制）

很多文章说到，什么没有WIP就不称为一个看板，任务最好不要有并行，并行就是等待，并行就是浪费，并行就是不专注。WIP如果这么简单就能设置成功的话，我估计我也不会费笔墨在这里重点点评这个东西了。在现实的团队实施过程中，WIP基本算是一种鸡肋实践，弃之可惜，食之无味。接上一段的观点，理论还说不要有承诺呢。为什么会是这样呢？

团队的疼痛

WIP会让团队疼痛，但看板的其他手段不会直接让团队疼痛。疼痛需要团队进一步的思考，但没有养成思考惯性的团队会对突如其来的疼痛不知所措。但恰恰是在经历演化阶段之后的团队才会养成思考的惯性。所以对于WIP的使用，在状态板的团队不要考虑使用。

团队在真正限制自己工作之前先需要识别这些潜在堆积的工作，看一下工作任务价值流状态变换的顺畅程度是什么样的，累积数据是什么样的。在改进之前先承认现状，在承认现状的之前先识别现状。 团队应该知道有这么个概念，且是重要的概念。当团队准备好了要使用WIP的时候，再进行使用。

另外，对于并行任务，我有一位朋友突然问我：

现在的组织上下文下，如果没有并行，而实施真正的串行开发我们交付的效率会提高吗？

我思考了一会说：不行。他说没错，恰恰是因为系统之间的耦合与等待，我们提高效率的手段就是并行。如果没有等待和系统之间的耦合，串行就是效率最高的状态。

也就是说，现在组织中并行的开发过程，其实是一种保持效率的方式。真正影响整体效率的瓶颈在于系统之间的耦合与强依赖状态。这也就是说如果每一个人是一专多能的状态，并且团队之间没有互相依赖的话。尽可能的实现单件流就可以极致的优化LeadTime（前置时间），但这种假设一般不会存在。

所以在关注并行或串行的过程，还不如关注系统耦合与依赖来得更为有“效率”。也可以这么理解：管理优化到一定程度，就需要技术与代码的优化与改进。如果光关注于管理也会造成某种意义的局部优化。

最后

不要太过强调“精益看板”是什么？而应该强调整体系统的现状是什么？我们要优化与改进整体系统哪些领域和方面？以让这个整体系统更加平滑、平顺、平安、平常的运行得更好。在精益的世界之中，要利用好整体系统优化的动力——人，让整体系统之内尽可能的没有变量。

但也要注意，人同样也是系统的变量……

相关参考

1. 《看板方法》douban↩

2. 置信区间 Wikipedia↩

3. Excel中计算方法：=PERCENTILE(array,0.85) //85% Office Excel参考↩