精益对大家来说都不陌生了，无论是最开始提取的丰田制造原型，还是后面延伸出来的物流供应链管理，再到近两年颇为流行的精益创业(Lean Startup)，都在不停刷新着“精益”这个概念。最近也不乏把精益当成“热词”来包装的各种理论，以至于很多客户建议我另外给“精益企业”取个名字。我一般都会礼貌回答说：看看精益房子(见下图)吧，我们并没有发明什么新东西。
当然，精益房子所表达的架构其实还蛮复杂的，也不是一两篇文章可以论证的，日本和美国管理学界也没有达成完全的一致。很多人的疑惑是咱们好歹是21世纪的新兴产业，肯定跟上个世纪的汽车制造业有不同吧?还用精益思想合适吗?这里我来谈谈自己的理解，抛砖引玉。
精益思想为什么适合于咱们这个行业，在我看来有以下两点：
- 追求快速价值交付的小批量生产模式
- 追求***卓越的匠艺文化
追求快速价值交付的小批量生产模式
“这个谁都知道”、“这不等于白说吗”、“这个太虚，来点干货吧” ...
这些都是每次抛出这句时会收到的反馈。然后我反问，“能给我讲一下你最近交付的一个功能挣了多少钱吗?”一般这个时候对方会回避我真诚的目光，嘴巴上说着“我们的系统很复杂，一个功能太小了...”。
那么我们再来看看各个岗位的绩效考核吧?开发了多少条需求和测试出了多少bug，横比环比增长了多少都是报告中的常客。这里的“价值”被定义为了每个角色、每个人的阶段输出，类似富士康流水线上生产一个iPhone零部件的工人，至于***是iPhone 6还是7于这个工人其实并没有太大关系，反正这批订单200万台，本周得搞定，做的越多个人收入自然会更多。
上面的例子告诉我们，并不是所有的生产模式都是追求“小批量”的，富士康在生产模式上是成功的，甚至是行业标杆。而丰田制造当年形成精益的生产模式，其核心是追求对市场变化的响应力，即用户一旦变了口味想开SUV，我的轿车生产团队及流水线能够很快调整开始生产SUV，并且我能够通过这种能力快速验证SUV的市场是不是真的。
在这样的生产模式下，较之每个员工的资源利用率及输出，我们更关心的是“需求”是否能够在团队快速流动产出***的产品，应运而生的是对生产批次小规模化及人员跨职能的要求。持续交付(Continuous Delivery)显然是咱们这个行业对这小批量生产模式的总结。
当然不用论证的是科技行业的市场是持续变化的，具有不确定性，所以逻辑上这种生产方式应该是必须的，即使是所谓的后台核心系统，其需求也不得不跟着所谓的前台用户需求变。很多人会说这个很自然啊，咱们拆了User Story做迭代不都是这样吗?那么有多少次大家会说“这几个User Story关联很紧，客户都要，我一起开发(测试)了，效率高一些”、“上线走流程麻烦死了，咱们还是一个月上线一次吧”、“所有都是Must Have，砍不下去了，PM上去磕客户了” ...
当然我们不否认有的时候这些意见表达的可能是正确的选择，但显然，坚守这样的生产方式就需要在这些时刻去思考是否大家真的都运用了精益思想来指导自己日常的生产工作。
这个时候可能会有大牛又跳出来拍一砖：”看吧，还是管理的人不懂精益!”
那么技术人员真的理解了“小批量”的含义吗?在你的内心深处有理解包括TDD这样的基础技术实践是在践行精益“小批量”的价值观吗?用测试来描述一个业务小场景，然后加以实现，这种小步前进的方式正是个人对精益思想的日常修炼!每个“小批次”业务场景实现后，都要严格重构，追求代码的***简洁，这又是我们接下来谈的对”匠艺“的卓越追求。那么环顾四方、环顾行业，有多少工程师能够坚持TDD呢?当开发进度紧张成为压力的时候，有多少人是选择***个放弃TDD，将“小批量”原则***个放到裤兜里的呢?!
追求***卓越的生产匠艺
回到富士康流水线上，一个杀马特造型的青年在熟练地完成着iPhone屏幕的组装，他下意识地拿着工具钳咯噔一下，熟练地把一个屏幕扣入了iPhone的背壳，时间不到10秒钟，然后他开始重复循环。他的眼神好像有点游离，嘴角不时露出微笑，脑子里在回忆着昨晚和兄弟们撸串时的高谈阔论。他到岗1个月，***天就学会了这道工艺，除了有一次把屏幕扣反了，这一个月还没出过啥问题。最近谈恋爱花钱不少，他每天都工作10个小时，虽然辛苦但想到和女友的甜蜜时光还是觉得值。
上面对等的场景是一个蓬头的程序员，对象(OO)也搞了5年了，这次遇上了函数(FP)项目，于是“WTF”成了口头禅，有时候在pair时忍不住说了还得道歉。最近code review出来问题很多，功能是没问题了，但老是想着修改变量值。每天盯着屏幕的眼睛有几根血丝，脑子里不时闪过无数马匹从Monad身上压过去，都上项目一个月了，最近几个User Story还是被QA揪出不少问题。
虽然“心”苦，这段时间还是觉得很充实的，回家地铁成了***的思考地儿，有时候突然开悟，回家兴奋着也想来个session，当然结果一般都是家人2次元的眼神。每每这个时候都希望第二天快点开始，能够去把代码重构了，实践一把自己在地铁上的灵感。
上面的两个场景很普通，在这两个行业里可能比比皆是。经常我们会开玩笑说一个卖体力，一个卖脑力。但其实本质的不同是生产者采用的生产方式的不同：在流水线上的杀马特少年需要的是严格遵循制造工艺的每一道工序，通过不停的重复形成机体的记忆;而程序员需要的是认清自己认知的局限性，通过不停的学习形成更好的解决方案。
好的流水线生产者能够通过认真练习、快速形成机体的记忆，使自己产出的效率和成功率都能够达到一个高水平。好的程序员能够通过刻意练习形成大脑的思维体系，从而能够持续提升自己面临新问题时的响应力。由于丰田当时的“特殊”市场环境，迫使其表面看是一个偏重于前者的流水线，但实际却走出了一条持续学习和提高的文化之路，收获了对市场需求变化的高响应力。
所以有人会说：“对嘛!管理层都想着用熟练工，所以没法有精益的文化了!”
咱们还是小处着手，刚才谈了TDD，现在谈谈pair。曾经作为一名PM，我也为两个人结对指着代码论道半天非常恼火，虽然内心万马奔腾，但对“匠艺”的认可还是阻止了我去拆散这对pair，毕竟我清楚两人确实是在讨论重构而非其它琐事。当然事实证明这对pair现在都是业界有名的敏捷和架构专家了，好歹也算是对我当年苦难的回报。
再次环顾四方、环顾行业，有多少工程师能够坚持pair，甚至code review?有多少人希望能够在功能已经实现的代码之上持续追求卓越，而不是想着我自己干实现快一点好交差。至少这么多年的咨询生涯所见者有限，令人惭愧的是code review成了咨询需要去说服团队的日常工作之一。如果都没有分享和交流，甚至是争论，又哪里来的真正意义上对***卓越的追求呢?
小结
上面两点可能只是整个精益思想落地层面的两个具体方面，但就我个人的体会而言，要做到已经非常困难了!即使在对敏捷高度认可和实践的团队里，要坚持做也可谓是一件艰苦卓绝的事情。什么事情喊口号容易，持之以恒的一万小时是每个希望成为精益践行者必须经历的磨练。“着眼长远”这一精益的另一基本原则送给还在坚持的同学们。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
