众所周知，日本车在全世界都是很受欢迎的。究其开端，很多人会想到20世纪70年代的石油危机，认为是油价高涨，为尺寸小、油耗低的日本车打开了市场。这固然可以解释一部分原因，但另一方面，为何日本车能够持续受到欢迎，为何日本车能摆脱“价廉质差”的形象，既有优惠的价格又有优异的品质(缺陷率常年很低)。这一切，都与日本汽车厂商所采用的“精益生产”，尤其是丰田开创的“丰田生产方式”(Toyota Product System, TPS)有很大的关联。最近因为与供应链打交道很多，我花了些时间学习这种生产方式。有趣的是，我发现，它的价值不只限于汽车行业，甚至不只限于制造业，对其它许多行业(包括软件行业)。所以下面我讲讲丰田生产方式给我的启示。

   “丰田生产方式”给我印象最深的要求是，员工必须同时对工作和工艺负责。自从福特发明了“流水线”之后，工人似乎成了机器的附庸，只是完成机器暂时无法完成的工作。生产的终极形态，就是把一切工作变成简单重复劳动，用机器执行。所以，工人的工作也应该简单机械，比如每天按照生产线的运作，以一定节奏拧紧某个螺丝，就是一种典型。而在丰田生产方式下，工人不但要完成简单机械的本职工作，还必须对工艺负责，也就是理解该工作的意义，思考并不断思考改进自己的工作过程——他们既有这个义务，也有这个权力。结果，整条生产线就好像具备了不断改进的活力，而不再由少数专职的“专家”负责优化(实际上专家也负不了那么多责任)。

   软件开发/互联网虽然看起来是光鲜亮丽的高科技行业，但不少时候是达不到这种要求的。许多公司并不要求员工去思考和改进，许多员工也更愿意只做简单重复劳动，不愿意开动脑筋去思考和改进自己的工作。所以，无论是工作质量还是工作效率，其实都停留在相当低的水平上。而许多公司的解决办法，无非是找一些“技术牛人”来负责，这就好像汽车生产厂找“工艺专家”来优化生产一样，或许有效果，但不会太明显。与“对工作和工艺负责”的工人类似，有些程序员会积极开动脑筋编写或者学习一些工具软件来改进自己的工作，他们或许不能编写复杂的框架或精深的算法，但确实堪称优秀的程序员——就好比生产线上优秀的工人。可以说，如果公司的大部分员工都具有这样的意识和习惯，公司也支持和提倡这样的工作方式，那么其产品一定不会太差。

   “丰田生产方式”中的还有一点要求，即员工一定不能只了解自己的工作，还需要了解自己工作的上下游，学会从配合、团队的角度来理解自己的工作。这样做一方面可以提高配合的流畅程度，降低沟通的成本；另一方面，公司不必准备专门的“后备团队”来应付突发情况——如果某个员工突然缺勤，其上下游工位的成员完全可以临时补缺，不致影响整条生产线。为了做到这一点，公司会要求新员工入职之后不是立即投入最终岗位，而是先在整个生产线(或上下游)的各个环节都工作一定时间，最后才确定具体的工作岗位(在《改变世界的机器》里，作者希望访问本田工厂的一位公关负责人，却被告知“他刚刚入职，现在正在生产线上参加例行劳动”，这种安排的普遍性可见一斑)。

   在软件开发中，我们也经常看到“过分专业分工”导致的问题问题。比如程序员就只懂开发，丝毫不懂数据库或者运维知识，全然不理解软件最终价值是提供服务，结果每次数据库或系统出一点问题则束手无策，只能等数据库管理员或运维工程师出面。结果每次耗时相当长，结果却未必让人满意。还有些时候，客服和技术部门之间存在巨大的鸿沟。客服只负责简单传达客户的意见，根本无法帮忙判断问题的性质和解决成本；技术部门只从技术出发解答问题，根本不知道也不愿意了解问题给客户造成了多么严重的影响。其结果就是每次出问题必然扯皮推诿，许多问题解决成本居高不下。

   为了保证质量，“丰田生产方式”对质量有严格的要求。在传统的生产过程中，很多企业都会设立专门的质量部门，而且通常是设定在生产线的末端，以保证最终产品的质量。与此相反的是，“丰田生产方式”会把质量落实到生产中的每个环节，其理由是：如果把质量管理的责任全部落在最终的质量部门，生产线上的人就会认为，自己工作时只要照章操作即可，至于质量，反正最后有质量部门去操心。这样，即便质量部门能从严把关，避免缺陷产品出厂，成本也是相当高昂的。而在丰田生产方式下，为了让每个环节都要对质量负责，每个生产环节甚至都具备发现异常时中断生产线的权力。

   我曾经反复提倡“程序员要对自己的程序负责”，其实也是这个意思。扩展开来说，要做好真正的产品，产品经理要对质量负责，设计要对质量负责，程序员要对质量负责，测试要对质量负责，运维也需要对质量负责……。这里说的“负责”，不只是纸面上的责任，不是“我做好我份内事就行，最后产品能不能行，有人操心，我管不了”的工作态度，而是工作的使命感，自愿自发地从最终产品的角度来完成好自己的工作。我们已经无数次地看过这样的现象：产品质量无比差劲，谁都不能满意，最后追求起来，却是人人都没有责任。要解决这种问题，就必须把质量意识落实到每一个参与者身上(我曾经看过一本讲质量的书《质量免费》，说的也是这个道理)。

   如果遇到意想不到的问题，通常大家都知道要做的是“找到问题的原因并解决”，但很多时候这只是走个形式而已，许多问题还是会一再出现。而丰田生产方式要求，遇到问题寻找原因，一定要问“五个为什么”。例如针对一次机器的故障，五步故障排除法是这样进行的：首先，操作人员询问：机器为何停止？不久会得到答案：由于超负荷工作使熔丝断开。其次，操作人员接着询问：为什么出现超负荷工作？得到答案：轴承没有得到足够润滑。再次，操作人员再次询问：为什么轴承没有得到足够润滑？得到答案：润滑油泵没有很好泵油。接着，操作人员深入询问：为什么油泵没有正常泵油？得到答案：油泵轴严重磨损。最后，操作人员继续寻根究底：为什么油泵轴严重磨损？得到答案：油泵没有装移动式保护罩，金属屑掉入油泵。至此，操作人员找到问题的症结所在，于是给油泵装上保护罩，使赃物不会落入，杜绝了同样的故障再次发生。为什么要问“5个”而不是3个或者4个呢？这是一个经验得到的数值，其主要目的还是要求对问题求根究底，不能敷衍。

   在软件开发中，很多问题的解决也是相当敷衍的。面对运行过程中的异常问题，很多时候上级也会要求排查原因，结果却多是：“应该是系统出错了”、“可能网络断了一下吧”、“这个类库大概就是有这类问题，我也没办法”。结果，同样的问题还是不断地出现，每次都需要不断地耗费人力物力财力来解决。很多时候，只有上级领导发火要求“撤查”，才能得到相对满意的答案。相比制造行业下普通工人都必须回答“五个为什么”的要求，许多软件开发行业的从业人员真应该汗颜。

   有意思的是，“丰田生产方式”不但对员工提出了要求，对机器也提出了要求。通常的机器，只要能高效地完成其本职工作，就算合格。但丰田生产方式中，机器不但要负责自己的本职工作，还需要具备错误侦测能力。也就是说，一旦出现异常，就能够自我发现并报警。一旦发出报警，生产线上会有专门的人员，以最高优先级来处理异常情况。这样，就避免了机器发生错误，停工或生产次品，却迟迟不能被发现的现象。

   在我刚刚开始工作的时候，曾经被项目经理反复教训“你以为自己还是学生写程序吗？根本不考虑各种异常情况，也不做对应的处理”。后来换了其它工作，又被严格要求程序必须能健康运行，要能时刻把控自己程序的运行状态，及时发现异常情况。当时都很难理解，程序要完成自己的本职工作之外，还需要做那么多额外的工作。后来回想起来，才觉得庆幸自己很早领悟到软件开发的“正道”。可是放眼望去，还有那么多系统没有自我侦错能力，导致事故不断，而程序员们每天忙得焦头烂额，却始终不得解放。

   以上说了“丰田生产方式”给我启发最深的几点。如果非要说有什么神奇之处，那就是不把人当成机器的附庸，而是让人和机器有机结合——即便做体力劳动的工人，也不能阉割脑力劳动，仅此而已。如果这种生产方式真的有效，为什么只有日本汽车厂商能做好，欧美汽车厂商却做不到呢？我想一个主要的答案在于，这种生产方式对人员有相当高的要求(尤其是培养教育生产线上的工人，其难度远超一般人的想象)，并且落实起来需要很长的磨合时间。日本的国民素质相对较高，工作的流动性相对较低，所以有相当长的时间来进行磨合，把人与机器，人与人的配合协调到相当顺畅的程度。据统计，一家工厂从开始导入丰田生产方式，到最终顺畅运转，很可能要花费十年甚至二十年的时间(参考《改变世界的机器》)。不过一旦确立了这种生产方式，工厂几乎可以持续地以很高的质量和效率进行生产。几乎实现了“职员终身制”的日本公司，天然就具备这样的条件。

   从这个角度出发，我们也可以理解很多风险投资人说“投资看的是人和团队，而不是项目”的理由。团队的组成，成员的配合，文化的建立，都不是一朝一夕的工夫。但是，如果一支团队的组成合理、配合顺畅、文化健康，找到合适项目并取得成功的几率是相当大的。相反，草台班子即便误打误撞赶上了一个机会，也很难继续成功，这样的例子实在太多了。

   最后补充点题外话：日本汽车的质量普遍胜过欧美汽车，原因有很多，绝不仅仅是“丰田生产方式”那么简单。比如日本车的设计更侧重市场先行，更愿意采用成熟的技术，而欧洲车的设计更侧重技术先行，所以天然就要冒更多的风险。再比如，日本汽车厂商更倾向于与供应商构建合适健康的合作生态，而美国汽车厂商更喜欢硬梆梆的“合同采购”模式……

   附：

   对丰田生产方式感兴趣的朋友，可以阅读《丰田生产方式》和《改变世界的机器》。