限制在制品这玩意真的可能吗？|精益论剑

凡是教你看板方法的老师应该都教了看板方法的四个原则：

• 从现有工作方式开始
  

• 实施渐进式变革

• 启动时，尊重现有的角色、责任和工作职责
  

• 鼓励各级领导
  

同时也一定教了你六大实践:

• 可视化工作流程
  

• 限制在制品数量
  

• 度量和管理工作流
  

• 现实化定义规则
  

• 构建反馈环

• 协作式改进，实验性演进（应用模型&科学实验方法）
  

有了这四个原则，加上领导支持（注：做任何变革都不要鄙视领导）使得看板在初步启动时，一般都非常顺利，一马平川，应用了第1个实践：大量板子立起来了。

但往往到第二个实践：限制在制品，是众多团队迈不过去的坎。类似的声音总是回荡在你耳边：

声音1 ：项目需求那么老多，而且都是ASAP(越快越好），产品经理说都得做，而且都要有硬性上线日期，我们怎么可能限制？！

声音2 ：因为那个限制，我们开发的闲下来了也不能拉入工作项，因为瓶颈在测试环节。啥？让我们帮助测试？为啥不干脆多招点测试工程师？！

于是，渐进式变革中蕴藏的剧变浮出水面。也许你还没有意识到，当你尝试在制品限制的时候，你不是在尝试限制这个实践本身，而是在尝试改变团队内部不同职能的协作方式，甚至改变研发和产品的协作关系。

大多数的企业，玩了多少年的敏捷和精益，都只在研发部门内部玩，无法向产品推进。更遗憾的是，很多互联网产品经理长着非精益的脑袋作产品，将大量低价值的需求扔向研发，还“ASAP！”。限制在制品，是在推动产品方的变革，触发产品方尊重研发的实际能力。更重要的是：从无穷到有限，促使产品方思考价值，按照投资回报率区分产品特性的优先级。最大的浪费是什么？不是bug, 而是没有价值的Shit！

研发流程内部限制在制品，必然会触发跨职能协作的讨论。即便你跟大家讲：精益的原则是加速价值快速流动出去，如果上游自己忙得团团转，但价值阻碍在下游流不出去，上游拉入再多的工作项也是堆积在那里......大家的直觉反应可能还是：加测试人力吧！

此时你就比较尴尬：如果限制，就触了马蜂窝；如果不限制，就停滞在第一个实践"可视化”裹足不前。

与其质疑：限制在制品真的可能吗? 不如捅破窗户纸揪出其背后的问题：向前一步推进变革真的可能吗？

向前一步，远不止是在板子上加了个数字那么简单。在看板实践方法之外，你需要线下做很多变革的铺垫、外交、甚至政治工作，而这些都远远超出了看板方法本身。有一天，当你成长为不仅精通精益或敏捷包含的那些方法的实践者，而且还是个擅长变革的改革者，就不会再这样想："限制在制品不适合我们公司的情况和文化...".其实，我还没有看到限制在制品天然地适合哪个公司的文化。

一个做看板的团队，一直在温和地渐进式改进：可视化，做回顾改进工作方式，逐渐实现了稳定的交付能力，并有缓慢上升的趋势，从而增进了与产品方的信任关系。一天，团队决定不要继续温水煮青蛙，兄弟们与产品方谈判，将拉入看板的工作项设限制，过载后禁止新特性涌入看板！

如果你一开始启动看板就跟产品方说：“我们做看板限制了在制品，所以，不好意思，您的需求拉不进来了。”你想人家会是什么反应？

记住：别人不在乎你做的是白板黑板看板还是老板，在乎的是给他带来了什么利益！如果你的交付能力像过山车一样上蹿下跳，还有什么筹码跟别人谈判变革？

笔者想起多年前的一次失恋。与男友想结束但舍不得分手，于是笔者提议：咱们逐渐冷却，一点点地结束（唉，女人就是女人）。磨蹭了一年后，他问：“你要渐进到永远妈？”于是，当场就o了。彻痛...彻痛...但过后是彻底的自由和快乐。是啊，谁说渐进式变革就要渐进到永远？