大家好！我来自福建厦门，目前在一家软件企业从事研发的工作，这是我第一次参加拆书帮的活动，水平有限，希望各位不吝赐教，多多指正。
如果说书籍是人类进步的阶梯，那我想拆书帮选择的书应该可以称之为电梯了。一直以来，我面对每天纷至沓来的工作都有一种迷茫，虽然这本书还没有读完，但看板方法已经在我的脑海里初步构建了一个完整的理论体系，受益匪浅。
看板方法是一种工作方法，他是基于三个简单的原则的：可视化、限制在制品、管理流动。
我今天要分享的内容就是关于第二个原则的。
神马是在制品？
在制品即手头上要处理的所有事情。
以前面章节举的硬币游戏为例，那一枚枚硬币就是在制品。每一批次投入的硬币数量就是整个团队的在制品数量，个人正在处理的硬币数量就是个人的在制品数量，每个人等待硬币到达自己工位上的时间就是前置时间。
硬币游戏中的“在制品”和“前置时间”
这里书中谈到了另外一个概念“
工作周期时间
就是处理完手上所有在制品所要消耗的时间，这个时间其实从某种意义上等于工作流程中下一个节点的前置时间。并且书中提供了一个计算工作周期时间的法则——利特尔法则，这个法则说明了完成固定工作的时间和在制品的数量是成正比的。
利特尔法则及其用法
例如：在给硬币翻一面的工作中，一批处理二十个硬币的耗时是一批处理一个硬币耗时的二十倍。在这里我想应该明确一个限制，在制品必须是近似的或者能够明确的比较相互间消耗的资源（也就是利特尔法则中的吞吐量），这个法则才能有效。如果是翻一枚重一吨的硬币对比翻二十枚一元钱的硬币，这个法则就不成立了。
接下来书中介绍了在软件开发中在制品的具体体现。对这部分我个人认为例子本身并不重要，重要的是怎样去在实际工作中定义在制品。因为在不同的公司、不同的团队工作的方式是有差异的。在A公司认为需要投入大量资源的工作在B公司可能是轻而易举的，所以实际应用中划分在制品的方法是不会相同的。但原则是一致的，要能够很清晰的在利特尔法则中定义出在制品的吞吐量。
回到看板方法中，在制品体现在看板方法中就是一枚枚的即时贴，整个团队的在制品数量就是看板上所有即时贴的数量，工作流程上每个阶段的在制品就是那一列中即时贴的数量，贴着自己头像的即时贴数量就是团队中的个人手中在制品的数量。这样也就做到了看板方法的第一个原则：可视化。
那在制品的数量会对工作产生什么影响呢？
在回答这个问题前，我想先给大家看一幅图。
扔球表演的小丑，我把他手上的球看成是在制品
这是一个马戏团正在做扔球表演的小丑，我把他手上的球看作在制品。如果球太多，他的手跟不上，这个表演搞砸了；如果球太少，比如只有一个球，这个表演也就失去了观赏的乐趣。因此通过这个例子我们得到这样的结论：在制品过多或者过少都是不好的！不好的！不好的！接下来就具体分析一下呗。
在制品过多的影响
1、上下文切换的开销和在制品数量成正比
我在工作中有这样一个经验，如果并行处理的工作越多，在这些工作间切换的机会也就越多。所以工作项目切换的频率和在制品数量是成正比的。而切换工作项目的时候都会或多或少的消耗时间或者其他资源。在工厂生产制造时，切换产品必须对设备进行相应的调整；在软件开发时，切换项目必须重新熟悉当前项目的情况调整开发环境。就我本人来说，就算刚刚回答完同事一个问题，要回到其中写代码的状态中都不可能是一两分钟的事情，经常是要喝口水，再打开几个网页，然后伸伸腰，甚至顺便上个厕所走几步，就这几个动作，十分钟完成应该算快的吧！所以要降低这种风险可以尽量避免并行多项工作，或者在无法避免并行工作的时候尽可能的尝试减少在制品的数量。
2、过多的在制品导致反馈的延迟，会带来更多的工作
手上的事情如果太多，是很难一眼就看出里面存在的问题的，一旦发现了问题又的花更多的精力去沟通。好比测试，一次测试100个功能点对比一次测试10个功能点，发现最后一个功能点有问题所需要的时间是大大大大的不一样的。特别针对测试这种工作，如果你上报bug的时候，开发人员还没有完全切换到其他工作项目上，那么处理起这个bug就会快很多，也容易沟通的多。
3、前置时间的加长会带来更多的风险
“天下武功，唯快不破！”忘记这是哪个敏捷教练的名言了。敏捷在某种意义上来说不就是要快，更快吗？那些让我们无所事事的前置时间就是敏捷的敌人，必须砍掉！根据利特尔法则的公式我们完全可以推导出来：在吞吐量不变的情况下，要缩短前置时间只有减少在制品数量了！那到底慢会导致什么样的结果呢？很简单，你的工作永远跟在了别人的后面，在这个老二都无法生存的时代，这个结果就是致命的！哦，不！是没命！
4、更多的开销
每天把todo list过一遍是一个好习惯吧？每天站会的时候和大家伙汇报一下自己手头的工作是应该的吧？如果手上的事情太多了，复习todo list会变成一件耗时费力的工作，汇报工作的时候你也会变成一条长长的可能不是很臭的裹脚布！究其源头，这就是在制品过多导致的！
5、质量下降和缺少动力
“虱子多了不痒，债多了不愁。”
那工作多了呢？
没干劲！没心情！无所谓！
别人不知道，我反正就是酱紫的。抱着这样的心态去工作，质量可想而知了。人的精力是有限的，把单位时间内的精力尽可能专注在某件工作上，这就是对这个工作最大的爱！
过少的在制品也是不合理的
原书本章中并没有讨论这个问题，至少我还没有发现。但回想一下那个扔球的小丑，我发现这个问题是肯定存在的。只要是需要团队协作的工作，就会存在着前置时间，如果在制品太少，必然会引起大量前置时间的浪费，也就是会让资源闲置了，或者说团队里有人员闲置了。好比一条高速公路，同时只允许路上跑一部车子，虽然车速可以达到极限，但这条高速公路单位时间内的吞吐量是很低的，路面资源是大大的闲置了的。
既然知道了在制品的数量不可以过多或者过少，也就是要刚刚好。那怎样去找这个刚刚好的点呢？
限制在制品的原则
1、没有限制是不对的
如果你看完了上面的那些，这句话我想没有必要再做解释了。
2、限制的方向——更低比更高好
既然是限制，那就存在两个方向，往更低的在制品限制或者更高的在制品限制？
两害相权取其轻！上面一章已经分析了在制品数量过多或者过少会带来的负面影响，看篇幅都能知道，在制品数量过少的不良影响相对而言是比较小的，所以限制应该是往更低的方向去，万一限错了，危害比较小嘛。
而且过低的在制品限制往往会造成团队的人员闲置，现实中就是发现某人无所事事了，这比发现某件事情没有人去做简单的多吧！
3、一句口号“停止启动，聚焦完成”
开始任何新的工作前，尽力完成当前手头的工作。也就是集中精力去尽快处理手上的工作，完成它！清空的购物车可以装更多的商品！哦，淘宝的购物车是无限大的！这个笑话听起来真的很冷！
4、在制品限制是一个改进工具，不是一个具体的数字
每天的工作都充满了变数：客户需求、团队成员健康情况、交通是否拥堵、网络是否通畅，甚至保洁阿姨今天把水洒在打印机上这样的事情。这些变数的存在就会导致利特尔法则里吞吐量数值的变化，所以就不可能存在着一个不变的最优在制品数量。既然这样，限制在制品数量的重点就在于不停的去找这个最佳点，而不是在某时找到了就可以万事大吉了。
这就是：“君子博学而日参省乎己，则知明而行无过矣。”
好了，现在我知道限制在制品了，也知道了这个事情要不断地去做了，那该从哪里入手？
从整个看板，整个团队开始，先给团队指定一个初始限制值
同意，那这个值从哪里来的？
第一种办法：拍脑瓜随便挑个喜欢的数字
不开玩笑，既然这个数字只是一个开始，它很快就要被调整了，那在你没有更好方法的时候，这个方法最快！
第二种方法：根据团队成员工作类型来推算
假设团队中每个成员都是独立工作的，就是每个人完成自己手上的工作不需要和其他人协作。先把在制品总数限制为团队成员的数量，也就是假设每个成员手上都只有一个工作任务。正常情况下，这很完美，工作丝一般滑顺的流过每个成员！但是，如果某个成员的工作出现了问题，这时候整个团队的工作流就会被阻塞！
就好比只有一个车道的环形赛道上跑着一个车队，一辆车出现了故障会导致所有的车不得不停下了，直到这辆车故障排除。
那如果把在制品总数限定值设定为团队成员数量的两倍呢？也就是每个团队成员的在制品限制为2。
在这样的状态下，如果一件在制品出现问题，工作可以马上切换到另外一个在制品，不会阻塞整个工作流。就好比两车道的赛道上，一辆车抛锚了，道路不会被完全阻塞。
但会带来另外一个问题，由于道路没有被阻塞，所以路过的人会很容易的忽视故障的车辆，任由它停在那里，直到道路完全被阻塞才会不得不去处理故障车。在这里完全阻塞道路所需要的故障车最少需要两辆，最多的话就是停满一边的车道还要多一辆，那是一个多么糟糕的赛道啊。
因此这种类型的团队在制品的初始限制值应该取在这两种情况之间，具体取多少，那就不那么重要了，因为这个值将不断的去调整。
每个团队成员都是独立工作情况下的算法
如果团队成员需要互相协作呢？这个算法就应该再调整，我认为需要进行协助的几个团队成员把他们合并成一个，再套用前面的算法进行计算就好了。书上的方法和我的不一样，但其实道理是相同的。
有协作的情况下，原书中提供的算法
第三种方法：根据经验值
很简单，观察一下在没有引入看板方法前处于通常工作状态下团队的在制品数量，这个数量乘以2就是了。
再次强调，合理的在制品限制不是通过计算的出来的，必须通过不断的尝试才能找到最合适当前团队和实际情况的值，而且这个数值是不断变化的。而且初始值不妨定得宽松一点。
好了，现在我们已经有了初始限制值，那接下来就是不断的限制咯？
没错，有了初始值后，再经过一个阶段的尝试后，如果发现太多的工作处于闲置的状态，那就说明这个值过于宽松了，应该往下调整。如果发现有太多的人员闲置了，无所事事了，那就说明这个值太低了，应该向上调整。
那每次应该调整多少比较合理呢？这个幅度在每个具体的团队里应该是不一样的，如果还没有经验，不妨就先取20%吧。
一直到这里，都是在讨论整个看板和整个团队的在制品限制。而现实中往往还需要对工作流的某个部分，或者对某个团队成员的在制品进行限制。甚至这个限制的优先级高于整个团队的在制品限制。
为什么有这种需求？
答案是瓶颈！瓶颈是什么，瓶颈体现在工作流中就是在他闲置的事情一大堆，他之后的环节人员大量的闲置。体现在看板上，就是某个列的即时贴都快放不下了，可是它后面的列却空空如也。
发现看板上的瓶颈
这个时候我们应该首先对这个列进行限制，防止过多的在制品进入，然后想办法改变这个环节的吞吐量。可以把他进行拆分，优化工作流程，或者抽调团队中的其他闲置资源来加强这个部分。
当瓶颈出现在团队的某个成员身上时，就要考虑是不是让其他人来协作他工作？
书中这里举了很多对看板上了具体工作列或者团队人员进行在制品限制的方法，这里我就不做搬运工了。
特别要说明的是，这里书中谈到了一个用来衡量工作量的概念——“故事点”。这个名字我总觉得怪怪的，不是很好理解。这里其实一张图就可以讲清楚了。
“故事点”
网友评论