深入浅出 Kanban 系列 (4) - 实践看板可能遇到的困难和抵制观点

经过前面一系列文章，你应该已经知道了看板是什么和它能带来什么好处了。是不是非常急切的想在你的团队或者公司里面实践？先等一等。落地，永远都是一件困难的事情。实践看板以前，你还要了解一下你将有可能遇到的困难和一些抵制的观点。

管理层面

推行的方向

虽然说，有观点认为看板能够从底至上的实践和推动，也就是说你可以先在你自己能掌控的团队里面实行，然后不断影响你的合作伙伴或者上级。但是，即便是可行，这种方式还是很难的。

当你实施看板的时候，你至少应该要有说“不”的权力。这是因为你必须控制从上级或者外部压过来的任务。否则，要设置 WIP 是很难的事情，而且如果任务不集中从一种渠道过来，你的团队成员可能还会被各种渠道的任务打乱他们的工作流程。所以，你至少要能够控制需求和任务的输入，让团队成员只需要关注看板里面的任务。

如果你没有什么职能权力，或者你不懂得怎么说“不”，会不会有点绝望的感觉，觉得就没法推行看板了？其实还是有机会的。还记得实践看板的第一步是什么吗？就是把流程可视化出来。所以，你尽可能用看板反映出当前团队的情况。如果你可以展示出当前的流程非常混乱，拿到一些数据来说明有多少精力是浪费了的，每个人并行做多少个任务，需求质量不好或者经常有流程阻碍等，这也是你向管理层推动看板的一个好的机会。

WIP 限制

要说服管理层在开发流程中的环节设置 WIP 限制，一旦达到就不能再接受新的工作任务，还要用拉动的方式，是不容易的。但是，绝大多数的人都会认同，他们自己在没有干扰，和不需要处理多任务的情况下，会把一件事情做得更好。这也是很明显和符合直觉的。不想设置 WIP 其实多数是因为管理层怕流程中出现阻碍的时候，资源利用率不高。

事实上，即便我们没有在现有的流程显式的设置 WIP，我们还是被一定的 WIP 在限制着。流程中的某一个阶段，比如开发，能够同时开展多少任务，基本取决于人数 * 每个人的并行任务数。并行任务一般都是由于阻碍因素，或者优先级调整的原因造成的。限制 WIP 其实就是限制并行任务数，发现既有流程问题并解决。有时候我们抱怨开发慢，其实真正写代码实现不慢，很可能是之前谈过的那些可变因素导致流程中有太多浪费。不设置 WIP，我们很可能没有意识到我们的开发流程里面存在多少问题和人员多任务情况有多严重。

David 曾经分享过一个有趣的故事。有一次，他的一个客户的市场部和开发部老大开了一个会。市场部的老大在抱怨，说他们的需求并不能很快很好的处理。实现的功能最后要么上线质量不好，要么等很长时间才能上线。而开发部的老大说，他们团队里面的每一个人，都已经平均同时处理 7 个任务了。David 就问市场部，你们觉得他们已经尽最大努力了吗？每个人已经同时做 7 个任务了，你觉得是太多还是太少？市场部的老大毫不犹豫的说 7 个任务太多了。但是他又觉得每个人如果只做一个任务又太少了，不太现实。所以，最后 David 把每个人的平均任务数量从 1 逐渐提高到 3、4 个的时候，市场部的老大觉得可以接受，又不至于太多。这样，双方已经达成一定的共识，每个人手上并行任务不能太多，开发那边可以说减少了一半的工作量。那么顺着这个，就可以开始设置流程中各个阶段的 WIP 了。

支持观点和理论

1. 从资源利用率转换到流的管理角度

   评估停车场，基本的指标一般就用资源利用率，看是否能经常停满，利用率是否高。但是，如果我们要观测和评估某一条道路的状况，汽车的流动效率和道路是否顺畅显然更重要。软件开发流程显然更像是一条道路，过程中充满了可变因素，打造一个顺畅的流程和环境可以更好的适应变化。低 WIP 和预留空闲资源，就像限制道路上的汽车数量一样。

2. 多任务处理对质量有害

   首先，WIP 和平均前置时间是有一定的因果关系的，而且是线性的。这在排队理论里面的 Little's Law 里面有详细描述。再说，根据 David 的观察，

   Longer lead times seem to be associated with significantly poorer quality. In fact, an approximately six-and-a-half times increase in average lead time resulted in a greater than 30-fold increase in initial defects. Longer average lead times result from greater amounts of work-in-progress.

   所以说，设置小的 WIP 有助于减少前置时间，还可以让产品质量变得更好。

延迟承诺

我曾经碰到一位开发主管，他说他的领导宁可你和他说有人接手，即便是拖得比较晚才做完，也好过你和他说因为有其它更重要的事情在处理，没有人能着手跟进他提出的任务。但是，这样真的好吗？这样的结果就是，那个领导觉得他的任务已经被接纳了，他就会时不时问一下任务进展。团队里面的人就不得不多任务工作，这边看看，那边看看，导致两个任务的前置时间都拉长，而且质量可能也不如做完一个再处理一个好。

所以，我们要尽量学会说不，并和上游明确什么时候才是真正的承诺开始时间。如果用餐厅的例子来比方，在外面排队并不能算是餐厅开始接待你了，当然你也不能把排队的时间算到等上菜的时间里面。因为在排队的时候，餐厅还没有承诺一定能够接待你呢。你可以抱怨人太多，你可以放弃不等，但是不能责备餐厅没有好好招待你。那什么时候才算是餐厅正式接待呢？当然是你被请进餐厅和点菜的时候了。对开发团队来说，承诺开始的时间点，就是把任务从需求阶段，拉到设计或者开发的时候。只有和上游沟通协调好真正的承诺起始阶段，才能保证双方的期望值是一致的，正确的计算前置时间和保证可预测性。

执行层面

沟通渠道切换

在执行层面，最最重要的事情就是，整个团队，尤其是上游人员，应该通过创建看板卡片来和下游沟通。而不是用电话，邮件或者即时通信来通知下游开始一项任务。而且，必须遵循拉动的原则，不能动不动就和下游的人员说，你马上帮我做这个。不然，下游的工作流程就很可能一直被打断，而且他们也不必用看板，就知道了他们需要做什么。这样的话，回头让他们去更新看板里面的任务状态，或者帮上游创建任务出来，就变成一种很无聊和多余的事情。最终，看板上就无法反映最真实的状况了。

在迭代前安排好故事点的常规做法这里就不多说了。如果中途要新加或者调整任务怎么办？

1. 首先，检查一下看板上面，看看整个团队，或者某特定人员正在做什么任务。判断一下你的紧急任务，对比 backlog 和正在进行的任务的紧急程度。

2. 在看板上创建一个卡片，调整你的任务的优先级，或者放到一条特别的泳道上面，清楚表示它的服务等级。

3. 如果确定真的是很紧急的任务，比如线上故障，那么做完上面的两步之后，再线下用电话或者即时通信通知团队或某位成员，让他们意识到有紧急任务出现。然后，他们再自己决定是应该马上停下手上的任务，还是等手上的任务做完了再处理这个紧急任务。拉动的原则必须坚持。

紧急任务和线下交流都是无法避免的。不是不能做，只是应该尽最大的可能来把它们反映在我们的沟通渠道，看板和卡片上。事实上，当我们真正能够这样做的时候，我们才能够鼓励团队培养自主能动性。他们自己决定什么事情应该先开始，自己觉得能胜任任务，又有时间的话，就主动去做。这样才更容易激发团队的责任心和主动性，减少那种事不关已，高高挂起的态度。

不过，有一件事情特别要注意。如果要在看板系统里面创建一个任务卡片是一件很困难的事情，人们是不会乐意这样做的。比如，看板系统太慢，设定了太多的规则，并要求任务卡片必须填什么信息，或者什么不能填等，都会导致团队成员不愿意用看板系统。

团队人员担心受到监视

我想没有一个人喜欢被监视。这并不是信任和鼓励创造性的表现。尽管说，如果我们能够完全通过看板来沟通，在里面记录所有的任务，目的也不是为了监控团队或者任何人。正如我在前面的文章说到，看板是赞同空闲资源，而不追求 100% 资源利用率的。使用看板是为了增加信息透明度，鼓励自我管理，主动协作和流的管理。

从另一个角度来看，如果一个领导真的不信任他的团队，要看每一个人的利用率，那他还是会通过别的方式来达到那样的目的。比如让每个人估算计划，每天或每周收集数据和做一些统计报表什么的。那些方式可能更浪费时间，无聊又降低生产率。可是如果用了看板，领导就可以清晰看到团队的运行情况。要做统计报表的话，统一从看板收集数据也容易得多。

结语

无论是从管理层面或者执行层面，使用看板都需要一些思想和行为上的改变，而人的本性是不愿意做出改变的。所以，实践看板前，我们应该充分了解清楚它可以带来的好处，和可能会遇到的问题。如果团队里面的每一个人都掂量过，好处比坏处要多，改变起来就容易一些。如果遇到不接纳看板的人，而你又需要他的配合，考虑怎么才能说服这些人是一件不容易的事情。你要知道他是通过 System 1 还是 System 2 来思考的。什么是 System 1 和 System 2？或许你可以回想一下，你和你的伴侣经历过的那些没有达成共识的争吵。当时你们可能就用了不同的系统在争论。有兴趣的话，可以看看《思考，快与慢》这本书。

更多精彩内容请长按一下二维码，关注我们的微信公众号：互联网plus管理新范式。

• 回复：看板方法，进一步了解看板方法
  

• 回复：深入浅出，获取深入浅出看板系列历史文章

互联网plus管理新范式

Agilean官方博客平台

微信号

iPlusLeadership

点击

阅读原文

访问英文博客