软件开发和制造业的相互启示

我今年买了个九阳的榨汁机，不得不吐槽，组装和拆洗这么复杂，说明书也看不懂，看来我还要去上培训课才知道怎么用，这个产品狗要拖出去斩了。

软件开发对制造业的启示

软件开发的产品是虚拟的，代码可以随时推翻重建，做任何事情成本低，自由度很高，可以通过代码来实践很多前卫的概念，而制造业觉得人是活的，人的存在可以实现一切，但问题是并不是每个人都是超人。

• 标准模块化思维
  

软件开发的工作最大的便利是代码可以直接 copy paste，无论哪个程序员都会把重复能够用得到到的代码做成一个通用模块（子程序、函数、类什么的），下次再用的时候，就不需要重新写那么多代码，直接调用或者拿过来用稍微改一改就可以了。

制造业的产品本身不能像软件开发一样直接copy paste，。但是受到软件开发思维的影响，我习惯会把一些可能会重复的工作也标准模块化，比如开新项目启动会议（kick-off meeting），我把会议的内容做出一个通用框架（比如分四大块项目交期、成本、客户新要求、开发的挑战），每次这样的会议都按照这种思路来讨论，这样的标准化会议能够避免遗漏重要方面。我还会把一个项目从头到尾要做的工作全部列出来，建立一个通用模板(想象成PPT里的母版或者模板)，做下一个项目的时候，依照这个母版稍作修改变成了某个项目专属的（软件术语叫继承），就不用动太多脑筋了。如果公司来新来了菜鸟，我直接把这个母版给他让照着去做事，这样他做事会目标很明确，犯错的几率低很多，也不需要走一步问一步。

• 流程化思维及其触发机制

软件设计的里面，下一步执行的操作一定是要依据上一步的逻辑指示yes, no 或者flag(标识）来触发的，如上图。即计算机会根据上一步的结果是yes no（或者flag内容）来判断下一步是否执行或者应该做什么，如果上一步没有结果，下一步就一直等待。

实际工作中，经常因为项目前段的工作没做好，到头来后段的人发现了问题，反而不得不去替前段的人擦屁股。导致这种问题的原因就是触发机制不明确或者没有触发机制。

比如一个新的项目，样品满意->客户下单-> 生产计划员接到订单->安排生产，可以认为客户下单的就是一个触发指令。理想情况下，这样触发是没问题的。

但是实际操作中，往往没有充分准备就仓促就进行量产了，因为虽然接到了客户订单（虽然客户认可你们寄出去的产品），但是内部开发过程中的品质问题还没解决，这个信息经常被忘记传达给生产计划员里，生产计划员只管接到单就触发生产，生产部也不知道前期开发有什么问题，最后生产出大批量不良品。很多公司都存在这样的问题，只能高度依赖人的自觉性（自觉去沟通）。如果人一换，这样的问题又会发生。

我的解决方案是摒弃“接到客户订单”这种触发机制，改成“量产通知书”（某些五百强公司就是这样）。以“量产通知书”上的完成的状况（Yes or No）作为触发机制，生产部门只认量产通知书，没有签字完成就不接受量产。“量产通知书”要求要各部门的经理签名，包括工程部、质量部、计划部、生产部等。持续追踪这这个通知书的签名状况就知道是否能够量产，比如当质量经理觉得还有很大的品质问题没解决就暂不签字，比如采购经理觉得还有某个关键物料没到位也不签字，生产部门觉得人员没到位，也不签字。这样有效阻止了没有充分准备就仓促进行生产的风险。项目负责人只需要持续关注这张表的签名状况，哪个签字没完成就调动资源去解决。

• 用户体验

用户体验这个概念在软件开发中已经深入人心，以让小白用户都能无师自通作为设计的目标，你看微信，连我妈这种从来没用过触屏机的人也在五分钟之内学会怎么用。

我开发VBA程序的时候，为了避免小白总是来问我怎么使用，我的UI和交互设计尽量弄得简单易懂，常常都是一键操作或者加上通俗易懂的提示。

但是在制造业中似乎还并没有这个概念。比如设计一台机器，把把实现功能和降低制造机器的难度作为首要目标。做出来的机器往往操作很复杂，人员要经过专门的培训才能上岗。

出于半个程序员的习惯，我会习惯去想，如何保证小白都能够懂？

找机器设计工程师设计新设备的时候，不自觉会去想，如果流水线来了一个新工人，怎么让他能够一分钟之内就会使用呢（软件工程师职业习惯O(∩_∩)O哈哈~）？

在做作业指导书（WI）的时候，我会考虑，用怎么用的语言描述才会让文化程度不高的人也能够清楚明白我的意思呢？

写邮件的时候，我也会考虑，怎么写才能让所有人的人都能一分钟内清楚明白我的意思呢？下面是我的以前的文章，总结出来的一些写邮件的心得。

写工作邮件的几点建议（一目了然，高效沟通） - 史蒂芬的专栏 - 知乎专栏

我今年买了个九阳的榨汁机，不得不吐槽，组装和拆洗这么复杂，说明书也看不懂，看来我还要去上培训课才知道怎么用，这个产品狗要拖出去斩了。

制造业对软件开发的启示

制造业的产品是实物，一旦出问题就是大问题，做事情的成本很高，会考虑如何防止人犯错误。

• 潜在失效模式分析（FMEA）

这是汽车行业通用的标准。就是在项目开发的时候，就要召集所有相关功能的人来开会分析产品潜在设计的缺陷(DFMEA,比如设计厚度达不到功能要求等）和潜在量产过程产生的缺陷（PFMEA, 比如漏装零件、加工参数错误、用错物料），最后要产生一个方案如何事先预防这些问题产生，而不是事后发现了再去解决。这个方案就是FMEA表格（如上图），完成之后还需要提交给客户审阅。

下面举个网上找的 轻松的例子方便大家理解，约会FMEA^_^。

设计上的FMEA

这个概念似乎在软件开发中似乎很少提到过，一般都是程序员只管写代码，然后交给软件测试工程师去测试就万事大吉了，测试工程师发现有bug再来找程序员重新写代码。可以考虑一下像制造业一样开这种会议，提前预测可能会有的bug，然后在写代码的时候就预防。

（我知道肯定会有喷子留言说，软件行业又不是制造业，更新迭代非常快，没时间开这种会议瞎BB，而且代码写一步算一步，根本没办法做到。我这里提前说一句，做不到并不代表不应该这样说。你考不上大学并不代表你不应该上大学。）

• 变更管理
  

制造业为了保证产品输出的稳定性和可控性，对每个变更（设计上的变更、生产参数的变更、采用新模具）都是小心翼翼，哪怕变更看上去不会对产品产生影响。并且需要提前知会各个部门进行评估（每个部门的视角不同，会发现不同的潜在风险），需要各个部门签字同意才能进行更改。

但是软件开发，程序员可以很任性，代码想改就改，改完之后测试工程师测试通过就可以了。常常因为程序员突然后想出来一种新的算法能够实现相同需求，就把代码改了，测试工程师那里通过了，但是测试工程师毕竟不是只是站在产品本身，其他部门比如产品狗、销售狗、客户支持狗的立场没有考虑进去，或者其他安全隐患也不一定能够考虑进去。

• 版本升级的履历表
  

制造业文件的都附带一个文件的履历注释每个版本更新的内容以及更新原因，以方便人们知道改动在哪里，而且交接工作时很很方便，新来人的人看这个履历就知道这个文件的所有历史。

而软件开发，版本更新也有注释，但是这种注释大多只对最终结果的改变负责，至于代码发生了什么变动不会去记录，这样很难追溯当时候改动这个代码的原因。过了一段时间后，写代码的人都不知道曾经改过哪里，也不知道修改的原因了（我不知道像BTW这种大公司是否会管理得好一点）。在交接工作的时候，新来人的常常会很费解那些更新是什么原因。

===========================================================

哈哈 我也有微信公众号stehouse