前年，接触到了《丰田生产方式》，就对大野耐一这个人十分感兴趣，就专门找他的书来看。
同时，我一直都有一种“感觉”：我们软件工程的管理方式都是从传统工业借鉴的。比如被吹上天的“精益”概念及“看板”概念。然而，这些概念里，少有人说明这样地借鉴的理由及借鉴了哪些，放弃了哪些。想回答这个问题就必须分别弄清楚传统工业和软件工程的本质。
我尝试在这本书了解一些关于传统工业的管理概念。以下是书摘：
####“精益”的概念的产生
1990年，美国麻省理工学院的詹姆斯 沃麦克等多位教授，在《改变世界的机器》一书中，首次以“精益生产”（learn production）为核心介绍丰田生产方式，自此，欧美的一些企业才开始把丰田生产方式作为全球化以及提高生产率的标准和尺度。
领导说服力：坦诚即代表强劲的说服力
要想说服别人或是得到理解，若没有什么根据或道理是行不通的。
不要总是认为自己的言行没有错误，意识到错之后就应该爽快地说出来。如果有了这种胸怀，指挥现场以及下属不就变得轻而易举了吗？
犯了错误之后，应该不吝于向他人甚至的下属道歉，怀着这样坦诚的态度，怎么会没有说服力呢？
为了形成强劲的说服力，重要条件之一就是管理者自身应该怀着谦虚的胸襟。
现实生活中，人们似乎随着知识越来越丰富，产生错觉的可能性反而越大。
传统工业也会遇到我们软件工程一样的问题：面对同样一份工作，存在不同的意见。传统工业时里的体现可能是组装配件有两种方式，哪个效率更高；软件工程里的体现是实现某个功能，怎么实现更快（不要忘了，我们还要考虑可维护性，可读性）。当存在不同的意见时，双方容易在无用的争论上浪费时间，大野耐一是这么处理的：
在产生两种意见的情况下，各给双方一个工作日的时间，让他们按照自己的意见试着做一做，最后比较结果，直到让大家彻底理解、赞同为止。
其实，这样处理的最大好处是将**“实践出真理”**的文化慢慢带入企业。
####要提高生产效率，“意识革命”是首要问题
从上层管理者到中层管理者甚至工作在生产一线的作业员们，由于大家都是普通人，所以都有可能被禁锢在错觉之中，认为现行的做法是最科学的；或者说即使不认为是最好的，也觉得别无选择，这就是被常识化了。
我们软件行业更是如此，特别是一毕业就只在一家公司待很久的人。很容易被“常识化”，认为软件开发就只有一种方式：手工将jar包下载回来，导入到IDE中，然后写代码；部署软件也就是ssh上服务器，然后stop,start。
大野耐一说：
若是不改变从管理顶层到一线作业员以及工会的意识、观念和想法，那么怎么可能探索出做好工作的新方法呢？组织上的改革或许相对容易，但是“意识革命”应该会更加困难一些吧。
再比如很多人认为写单元测试会导致进度被拖慢。其实，关于单元测试是否加快进度，需要更多的数据支撑。所以，需要软件项目管理工具为我们提供更全面的统计工具，来收集这些数据。这也说明了软件行业和传统工业的一个很大的不同。传统工业中很多工作是重复的（产品通常是批量生产），可以快速实验，快速看效果。而软件行业中，根本没有批量生产某一软件的说法。
####无效率的动作不是工作
身为生产现场的管理者和主管，必须具有分辨“动”和“働”的慧眼，也就是说，必须能够分辨清楚哪些动作是无效率的，哪些动作与工作是无关的。
这里，对于这个“无效率”的定义会有争议。我是这样认为的，如果不能帮助我写出可读、可维护、用户可用的软件的动作都是无效率的。比如手动去管理软件依赖、手动部署、需求沟通需要等上一个星期、新加入团队的成员需要花两天的时间搭建开发环境、重复手工测试、单元测试写在main方法里、写代码过程分心看微博，动弹……
作为leader，发现这些无效率动作，然后找到改善办法是一项重中重的工作。
####改善应该按顺序进行
所谓作业改善，就是能够让现有的设备更好地发挥作用。在改善过程中，首先需要考虑的不是购买设备，而是最佳的工作方法。
我认为首先需要进行的是作业改善，之后才依次为设备改善、工序改善，也就是改善应该有先后顺序。
软件行业中，顺序应该是软件开发流程改善，之后依次是实现技术改善、软件开发工具改善。原因是软件开发流程的成本收益率比实现技术改善、软件开发工具改善更高。这只是我的片面之词。希望有数据的同学能帮我证实。
####产品质量问题
如果某个零件比较容易在前几道工序的时候出现问题，是不是应该考虑将检验工作提前呢？提前发现并剔除不良品，总比让它们一直往下走要好得好多。
品质融于生产过程中，因此，如果能在必要的地方做好检验工作，那么就不必等到工程的最后才发现不良品，或者说到工序的最后阶段只需要重点检验某些部分即可。
产品质量融于软件开发过程中，将风险高的软件模块提前开发。QA在功能开发前就参与需求的讨论，并提出验收条件AC。
####降低成本
如果有人问我，为什么要拼命减少库存、降低成本，我会告诉他，是为了让资金周转更加轻松。
然而，只要提到降低成本，大家就会觉得这是财务人员的责任，其实不然，财务人员根本无法促使成本降低，这只能通过集体的努力实现。
因此，所谓的降低成本，唯有依靠生产现场来进行，现场的降低成本的意识要做到比鬼还要精才行啊。
减少浪费也可以降低成本。关键是我们如何看待浪费。在《丰田生产方式》中定义的浪费：
1.过量生产的无效劳动：软件行业中指在不合适的时候开发多余的功能
2.窝工的时间浪费
3.搬运的无效劳动：需求沟通不完整，导致重复沟通
4.加工本身的无效劳动和浪费
5.库存的浪费
6.动作上的无效劳动：花费过多的时候搭建开发环境
7.制造次品的无效劳动和浪费：品质没有融于生产过程中
从这里就可以看出光靠架构师是不能彻底杜绝浪费，更不可能靠财务了。
####小结 这本书给我最大的启发是：高高在上不接地气的技术管理是无法管理好团队的。高高在上意味着他无法或很难及时、准确得知开发现场的情况的。如果你连“施工现场”的情况都不了解，谈何改善？
同时，我也发现软件行业的代码审查、每日站会就很好的体现了大野耐一的现场管理思想。通过这两个实践，我们的leader才有更多机会靠近“现场”。这才是代码审查、每日站会背后更深层的原因。
半年后再次重读这本小书，又知新。
老翟书摘说明
书摘内容完全来自原书，如果原书的作者或出版商觉得我侵权了。请联系我。
老翟书摘旨在通过一种书摘的方式让大家花最少的时间了解一本书，从而决定要不要继续读下去。书摘的每一本书都是本人亲自读过并理解的。
Last modified on 2016-02-15