精益大家并不陌生，无论是一开始提炼出来的丰田制造原型，还是后来延伸出来的物流供应链管理，再到后来的精益创业（LeanStartup），都在不断让人耳目一新“精益”的概念。最近不乏各种把精益包装成“热词”的说法，所以很多客户建议我给“精益企业”换个名字。我通常礼貌地回答：看看精益屋（见下图），我们没有发明任何新东西。当然，LeanHouse表达的结构其实相当复杂，不能一两篇文章论证，日美管理界也未达成完全一致。很多人怀疑我们是21世纪的新兴产业，那肯定和上个世纪的汽车制造业不一样吧？使用精益思想是否合适？下面我就说说我的理解，抛砖引玉。为什么精益思想适合我们这个行业，在我看来有以下两点：追求快速价值交付的小批量生产模式追求最优秀的工匠文化追求快速价值交付的小批量生产模式”大家都懂的这”、“那不就等于白说了吗”、“这也太空了，来点干货吧”……这些都是你每次抛出这句话都会得到的反馈。然后我问，“你能告诉我你最近交付的功能赚了多少钱吗？”通常这个时候，对方会避开我真诚的目光，说：“我们的系统很复杂，一个功能太少了……”。那我们来看看每个岗位的绩效考核情况？开发了多少需求，测试了多少bug，比上月增加了多少，这些都是报表的常客。这里的“价值”定义为每个角色、每个人的阶段产出，类似于富士康流水线上生产iPhone零部件的工人。至于是iPhone6还是7，反正这位工人并不关心。这批200万台要在本周完成。你做得越多，你的个人收入自然就会越多。上面的例子告诉我们，并不是所有的生产模式都追求“小批量”。富士康的生产模式是成功的，甚至是行业标杆。丰田制造精益生产模式的核心是追求对市场变化的响应能力，即一旦用户改变口味想要开SUV，我的汽车生产团队和装配线可以迅速调整开始生产SUV，我可以pass这种能力可以快速验证SUV的市场是否真实。在这样的生产模式下，比起每个员工的资源利用率和产出，我们更关心的是“需求”能否在团队中快速流动，生产出最好的产品。对小规模和跨职能人员的要求。持续交付（ContinuousDelivery）显然是对我们行业这种小批量生产模式的总结。当然，无需争辩，科技行业的市场是不断变化的，具有不确定性，所以按理说这种生产方式应该是必要的。即使是所谓的后端核心系统，其需求也不得不随着所谓的前端用户需求而变化。很多人会说这是天生的。我们拆解UserStory进行迭代不也是这样吗？所以你说了多少次，“这些用户故事密切相关，客户需要它们，所以我一起开发（测试）它们，效率更高”，“上线过程麻烦，一个月上线一次吧”，“什么都是必须的，砍不下来，PM敲客户”……我们当然不不否认有些时候表达的这些意见可能是正确的选择，但是很明显，坚持这种生产方式需要思考大家在这些时刻是不是真的用精益思想来指导自己日常的生产工作，这个时候，一些大牛可能跳出来拍砖：“你看，经理们还是不懂精益！”那么技术人员真的了解“小批量”的含义吗？你内心深处有一个理解是包括TDD在内的基础技术实践践行精益“小批量”的价值？用测试描述一个小的业务场景，然后实施，这种小步推进的方式，正是个人精益思想的日常实践！每一个“小批量”业务场景实现后，它必须严格重构，追求代码的绝对简洁。这就是我们接下来要讲的对“工匠精神”的卓越追求。那么环顾四周，环顾整个行业，有多少工程师能够坚持TDD？当紧张的开发进度变成压力，有多少人选择先放弃TDD，先把“小批量”原则放在裤兜里呢？！追求最精良的制作工艺，回到富士康的流水线，一位有着杀手外表的小伙子正在熟练地完成iPhone屏幕的组装。屏幕在不到10秒的时间内卡入iPhone背面，然后他开始一遍又一遍地循环。他的目光似乎有些游移不定，嘴角不时浮现出一丝笑意，脑海中正在回想着昨晚与兄弟们意气风发的谈话。他入职一个月，第一天就学会了这门手艺。除了有一次画面颠倒外，这一个月来他都没有出过什么问题。最近谈恋爱要花很多钱。他每天工作10个小时。虽然辛苦，但想起和女朋友的甜蜜时光，他还是觉得很值得。上面的等效场景是一个头发蓬乱的程序员。从事对象（OO）5年。这次他遇到了一个函数（FP）项目，于是“WTF”成了口头禅。我忍不住道歉。最近codereview出现了很多问题。函数没问题，但是我老想修改变量的值。每天都有几只充血的眼睛盯着屏幕，脑海里不时有无数骏马从莫纳德身上碾过。做项目一个月了，QA还是在最近几个UserStories中发现了很多问题。虽然“心”是苦的，但这段时间还是觉得很充实。回到家，地铁就成了我思考的地方。有时突然开悟，回家就想上一堂。当然，结果通常是家庭二次元眼。每次这个时候，我都希望第二天快点开始，能够重构代码，在地铁上实践自己的灵感。以上两种场景很常见，在这两个行业中可能比比皆是。我们常开玩笑说，一个卖体力，一个卖脑力。但其实本质上的区别在于制作者采用的制作方式不同：流水线上的沙马特男孩需要的是严格按照制造过程的每一道工序，通过反复的重复形成身体的记忆；而程序员需要的是认识到自己认知的局限性，通过不断的学习形成更好的解决方案。好的流水线生产者通过认真的练习，可以很快形成身体的记忆力，从而使自己的产出效率和成功率达到一个很高的水平。一个好的程序员可以通过刻意练习形成大脑的思维体系，从而在面对新问题时不断提高自己的反应能力。由于丰田当时“特殊”的市场环境，被迫表面上是一条偏向前者的流水线，但实际上走上了一条不断学习和改进的文化之路，获得了对变化的高度响应能力在市场需求中。所以有人会说：“对啊！管理层要用技术工人，精益文化没办法！”让我们从小事做起，刚刚谈到了TDD，现在让我们谈谈对。作为一个PM，我也很恼火，两个人配对，对着代码指了半天。虽然心里满是马马虎虎，但我对“手艺”的认可还是阻止了我拆散这对夫妻。毕竟，我知道这两个人真的是在谈论重构，而不是其他琐碎的事情。当然，事实证明这一对现在已经是业内知名的敏捷和架构专家，也算是对我过去苦难的回报。环顾四周，再环顾整个行业，有多少工程师能坚持pair，甚至codereview？多少人希望在已经实现了功能的代码上继续追求精益求精，而不是想着我可以自己实现，处理起来更容易。至少这么多年的咨询生涯见过的人有限。令人遗憾的是，代码审查已成为咨询说服团队所需的日常工作之一。如果没有分享和交流，甚至辩论，真正意义上的追求卓越从何而来？总结以上两点可能只是整个精益思想实施的两个具体方面，但从我个人的经验来看，做起来是非常困难的！即使在高度认可和实践敏捷的团队中，坚持也可以说是一件很难的事情，喊口号很容易，而一万小时的坚持是每个想成为精益实践者的必经之路.“着眼长远”，精益的另一项基本原则，送给还在坚持的同学们。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
