7.1 我的质量之旅

7.1.1 我们都是灭火队员

只要职场工作久了，大家或多或少都会碰到需要灭火的情况。

记不清是哪年哪月哪日了，仅记得当时快下班了，我突然被领导叫到了办公室。原来有个用户现场，我们的设备出现了不定时的异常复位现象，用户非常恼火，并放出狠话，如不尽快处理，就要上报国家电网。

当时，我就职的那家公司主要产品是面向国家电网的，而国家电网设备采购经常采取统一招标的模式，因此，一次用户投诉，就有可能影响后续几次招标成绩。公司领导非常着急，我连同其他两名倒霉蛋被一起火速派往现场。

记得从出发那一刻开始，我内心就异常忐忑，因为我不知道能否解决该问题，甚至都想不出该如何下手。屋漏偏逢连夜雨，老天竟然也来凑热闹，我们一行人刚踏上开往现场的长途汽车，倾盆大雨瓢泼而至，自己所在的小城竟然也能堵车堵的一趟糊涂。

记得当时自己的内心颇为矛盾，既希望交通赶快恢复，别影响到用户问题处理，又希望时间能像堵车一样静止下来，这样就不用面对现场棘手的问题了。风雨中，经历了堵车、爆胎等异常后，我们终于在凌晨两点到达用户现场，原本仅有四个小时的路程，竟然磨叽了九个多小时。

这个现场问题最后被我们很侥幸的处理掉了，但也让我真正体验了一把救火的经历。遗憾的是，这不是终结，仅仅是开始。

一次，我按照用户的要求谨慎的修改完程序，又谨慎的打包进行了测试。内心原以为自己这次够认真了，问题应该都处理掉了吧，没想到没多久现场就打来了电话。那一刻，现场工程人员的埋怨、用户的责骂、领导的不信任，诸多烦恼瞬间涌上心头。

一次，用户怀疑我们设备出了问题，但我们认为大概率是其他厂家设备出的问题。用户要求我们写保证书保证100%不出问题，但写了N多个版本，不是用户不满意，就是其他厂家不满意。折腾了N久后，用户也不提报告了，侧面了解才知道其他厂家已经修复了问题。

一次，我带着几个小伙已经连续奋斗二十余天了，看到大家都疲惫不堪，我决定让大家都好好休息一天，巧的是那一天用户大领导带着一群人去参观现场，然后一纸投诉寄到了公司。

一次，现场工期催的紧，用户嫌我们安装调试进度太缓慢，要求我们晚上必须加班到十二点。记得那一天，施工现场还处于土建施工中，江南的阴冷能透到骨头里，当晚就放倒了三个人。

……

一次次救火的痛苦经历，经常让人疲惫不堪。有一次，一个工程片区负责人离职，我请客并为他践行时，他发出一句感慨：“我再也不用担心凌晨会接到现场电话，感觉轻松多了。”祝愿他在新的工作中没有烦恼。

好不容易混个领导或技术能手，为啥大家最后都混成了灭火队员了呢？职场成长之路竟然都成了职场悲伤之路。

现实世界的诸多困惑，逼迫我们开始思考，原因何在？行业内有句名言，或许道出了其中奥秘：“你在现场受罪，你陪客户喝酒，是因为你做产品时没有流汗。”为了不再过那种紧张兮兮努力熬着的日子，我开始认真思考产品质量问题。

顺便补充一句，刚入职的新人普遍没有质量意识，与其苦口婆心的劝说，不如让其体验一次在现场被无数人围着、催促着、谩骂着解决问题的经历，一次满头冒冷汗，比无数次说教都管用。

7.1.2 被动策略

工作几年有一些痛苦经历后，大家一般都会有较强的质量意识，遗憾的很，重视并不等于成效。记得有一段时间，我们公司因为质量问题频发，连续开了很多次质量会议，领导也三番五次强调要大家重视产品质量，但最终依然收效甚微。

可能是因为过往经历太过深刻吧，参与跨国企业研发的那段时间内，我开始留意他们是如何做的，又是如何保证产品质量的。然而，让我惊奇的是大家平时只有按部就班的工作，很少有专门关于质量的会议，架构师也很少单纯的谈及产品质量问题，更没有领导色厉内荏的教训你要注意质量问题。

好奇怪，难道他们不重视产品质量吗，但明显与事实不符，要知道我们公司的产品质量还是非常受用户好评的。一般场合可能表现还不明显，但一些特殊场合质量差异就比较明显了，在我印象中最典型的就是地铁现场了。地铁运行环境比较恶劣，高温潮湿，运行工况复杂，一旦异常后影响恶劣。和全球同类厂家对比，我们的产品经常因长期运行稳定而深受用户好评，这背后隐藏着什么奥秘呢？

在协助做产品功能测试时，我发现了第一个奥秘：产品可纠错能力。产品在测试阶段总会冒出各种各样稀奇古怪的问题，但我发现每次问题提交后，研发团队修改问题的速度很快。如果是单纯功能性的问题修改速度比较快还容易理解，但很多问题明显定位困难，这类问题可以快速修复就让人震惊了。

后来我了解到，他们的产品内建有很多查错机制，一旦发现问题后，有足够的信息去定位问题源头，因此修改起来就比较快了，而这些诸多查错机制是在架构设计时就充分考虑的。

认识到这一点后，我突然发现自己用过的很多优秀软件也都具备类似功能。对我这个从dos编程一路走来的程序员老兵，最为典型的就是windows经典蓝屏界面了：
其中包含了异常错误标志、异常信息描述、异常时寄存器备份等信息。现在更多的软件异常时会弹出一对话框，请求你将异常信息发送给厂家协助问题提升，或者干脆直接请求你加入他们的体验计划。

借助这种策略持续迭代，产品问题会越来越少，质量自然就高了。

7.1.3 主动策略

大家可能都听过“华佗三兄弟医术”的故事。一人问华佗，你家三兄弟谁医术最高，华佗说他大哥最高明，其次是二哥，自己最差。大家不解，华佗解释到：我大哥治病是在人们尚未察觉身体有病时，因此人们对他医术不甚了解。我二哥治病是在人们开始发病时通过望闻问切，开处方医治病人的，因此人们对他有所了解。我看病是在病人非常严重的时候下药，偶然能救回几人，但大家都认为我具备起死回生的能力，医术高超。实际上我与兄长的差距很大啊！

做产品类同此理。一些人能快速定位解决复杂问题，大家会认为他水平很高，实际上很可能这类人最擅长的是hack大法，会让程序更加混乱。与此同时，那些能做出不惹事的工程师，反而默默无闻不受大家关注。

面对产品质量问题，完全被动等待问题找上门并非上策，我们更应该主动出击，采取更多主动策略，这是我发现的高质量背后的第二个奥秘。

我在做产品测试时，发现有一个附带的功能，可以通过命令行查看很多模块的运行状态，可以修改某些变量的当前状态，甚至可以通过脚本组合出一些复杂的逻辑。这是他们平台内建的一种调试功能，而借助该功能，我们可以相对容易的完成产品代码100%覆盖测试。而100%代码覆盖测试，可能是构建高质量产品最基本最有效的一环了。

再举一个例子。地铁机车从站台静止启动时电流很大，尤其是早晚高峰时刻，此时电流波形非常类似于故障电流。如何区别正常电流和故障电流呢？必须考虑各种现场的实际复杂运行情况，简单的静态数学模型很难做到完美。

为了应对这个问题，我们使用高精度录波仪记录了广州几条地铁线路一段时间的运行工况，有几百G的检测数据，然后将这些数据导入虚拟设备环境中进行仿真测试。经过这种环节的验证，产品算法可靠性提升了很多。这种策略就比一味的等待异常后再去努力查问题要高明的多。

另外一个类似策略是持续迭代升级的测试用例库，很多现场反馈的问题最后都会演化成测试用例库中的一条checklist，此时的测试工作相当于是在用过往的所有经验去保证产品质量，随着迭代时间的增加，产品质量自然也会比较高了。

化被动为主动，一点点提前量，可使我们在面对产品质量问题时更加游刃有余。

7.1.4 全面质量管理体系（TQM）

不管是主动策略，还是被动策略，都比较容易模仿学习，但很不幸，在实践过程中，我总感觉自己模仿出来的和在跨国公司看到的差了点味道。

刚开始在做产品时，大家会下意识的重视产品质量问题，但走着走着经常就变样了。编码时，客户和公司领导会不停的催进度；测试时（假设有的话），经常是随便搭了一个台子，简单的操作一些，好似ok了，就赶快交差。然后，等待我们的就是产品交付后漫长的质量稳定阶段，不是这儿出问题，就是那儿不可控，按下葫芦浮起瓢，不仅将自己折腾的狼狈不堪，也经常惹的用户、市场和领导不满意。

在公司项目催进度是常态，但因此在质量方面偷工减料又不应该，如何破这个矛盾呢？

在我早期就职的公司中曾换过一届领导，新领导对丰田模式非常推崇，因此公司内部曾搞过一段时间的丰田模式培训。当时，我将其当做新领导的三把火了，而且初印象都是一些虚头巴脑的东西，因此也没太上心，简简单单的了解了后就束之高阁了。

后来在跨国公司参与研发时，我总是朦朦胧胧的感觉有一些似曾相识处，虽然说不清道不明。后来，恰巧，我有过两次在丰田合资企业出差调试设备的经历，还经历过一次生产线丰田化改造过程。

感谢这些经历，我得以重新认识丰田模式，也了解到戴明博士的质量管理理论。实际上，日本很多优秀企业的管理思想，都深受戴明博士质量管理理论的影响。后来，我又阅读了一些相关方面的书籍，可能是厚积薄发吧，我突然有了一种顿悟：质量和产品不应该分开看待，质量应该是融在产品研发过程中的。围绕产品质量构建研发流程，全面质量管理体系（TQM）第一次成为我脑袋中一个成形的概念。

央视曾经制作过一个纪录片《大国质量》，强烈推荐给大家。这部纪录片我看过多遍，其中有一段内容感触颇深，文字部分引述如下：

1947年，一位数学博士，正在向美国社会迫切的发出关乎质量的呼吁：“很多人都有一个误解，质量和生产力，或者说生产效率是不能兼顾的，他们会有矛盾，除非你换一种思维看待他们。实际上，大批量生产和质量是完美匹配的”，他的名字叫威廉·爱德华兹·戴明。

按照戴明的理论，如果将质量管理思维注入到所有环节，任何一家企业，都可以做到在提高质量、节约能源的同时提高生产效率。

1945年，第二次世界大战的硝烟散去的时候，戴明兴奋的认为，一场关于质量的革命马上就要来了，自己的理论会有用武之地了。但奇怪的是，即便到1947年底，有超过三万美国人，参加了他的讲座，戴明却几乎没有感受到哪怕一丝的存在感。

二战后初期其他国家百废待兴，美国供应全世界。因为没有竞争者，当时的公司只想盈利，而不追求高质量的产品，因为他们相信，消费者根本不需要质量。戴明博士苦恼的感觉，自己仅仅是一个先知，虽然在他的祖国，却没有人愿意追随他，没有人对他真的感兴趣。只有人口统计机构，还在应用他的理念，然而他的理念没有被纳入当时的生产管理体系中。

就在郁郁不得志的戴明博士走投无路之际，大洋彼岸，一个因战争失败，而处在崩溃边缘的国家，正焦急的等待着救星的出现。

宇佐，日本南部的一座小城，在日本传统的神道教里，这里是大和民族的武神——八幡神的故乡，统领着全日本四万四千座宇佐八幡神宫。但是，这里却因另一个让人啼笑皆非的事件而“享誉全球”。在第二次世界大战后的十余年里，这里如雨后春笋般地出现了近百家日本企业的制造工厂。原因很简单，企业主们发现，宇佐在英文单词中写作“USA”，在宇佐制造的产品，可以印上“made in USA”出口海外，让人以为是美国制造。

索尼公司的创世人盛田昭夫，在他的回忆录里有过这样的描述：我们就是仿冒和劣质的代名词，任何印有“日本制造”的商品，都给人留下质量极差的印象。在创业初期，我们总是把产品上“日本制造”这行字印的尽可能小，有一次因为太小了，美国逼着我们把它重新印大。

在几乎相同的急切甚至绝望中，日本与戴明博士不期而遇。1950年6月23日，戴明接受日本科技联盟的邀请前往日本，进行为期一周的质量管理讲座。美国是日本的榜样，早在1946年，刚成立的日本科技联盟，就开始研究美国二战时期的《生产管理手册》。但三年多来，书中漫天的理论，让他们摸不着头脑。把希望寄托于一个货真价实的美国专家，似乎是最后，也是唯一的选择。

但是，在招待戴明博士的接风宴上，这位美国专家，却发出另一种忠告：“不要复制美国模式，如果你们能建立质量管理的制度，五年之后，你们的产品将超过美国”。

1950年7月10日，戴明博士在位于东京的日本医药协会大礼堂开始了为期八天的质量管理讲座，听众，除了众多企业管理人员之外，还有政府的高级官员。NHK将讲座录音制成广播节目，数百万日本民众通过无线电波加入到了这场声势浩大的质量改革运动中。五年超越美国的“天方夜谭”打动了日本。

索尼公司质量与环境副总经理佐藤裕和回忆到：“在索尼的生产，检验等各方面，都使用着戴明的质量管理法，通过这种方法，出现问题的时候，就可以比较全面地分析和反馈信息，这样才能制造出高质量的产品。”

丰田公司业务品质改善部主查古谷健夫说到：“戴明博士传授的质量管理对当时的日本企业来说是一种新事物，非常新鲜，许多人学习这个理论，并引入全面质量管理模式，但从根本上来说，提升产品质量还是需要靠人”。

结合戴明的理论与本国实际，日本，逐渐发展出看板管理，准时制等质量管理方法。这些方法，都拥有着同一个思路：质量，应该由人产生，为人服务。早在1902年，日本丰田公司的创始人，丰田佐吉，就发明了一种经过改良的自动纺织机，只要有一根断线，这台织机就会自动停止工作，制造这台机器的初衷，正是为了让妈妈不在那么辛苦。日本与戴明的“不期而遇”，冥冥之中，或许更是一种“不谋而合”。

1955年，丰田公司推出皇冠RS车型，首度打入美国市场，并于七十年代初在美国获得了巨大的成功。1980年，日本的汽车产量超过了一千一百万台，一举击败美国，成为了世界第一。美国的年轻人，甚至以开丰田车为荣，而另一个事实，也正在击溃美利坚民族的自信心，这个昔日的战败国，竟成了仅次于自己的世界第二大经济国。

当时的美国总统尼克松声称：“与第二次世界大战结束的时候相比，美国遇到了甚至连做梦也想不到的那种挑战”。这一年的6月24日，NBC电视台选择在电视剧黄金时段播出一部长达九十分钟的纪录片，纪录片讲述的是一个连尼克松做梦也想不到的一个事实，日本经济腾飞的力量，来源于一位在美国备受冷落的学者。而他办公的地方，就在距离白宫仅五英里之遥的一个地下室里。节目录像带的发行量超过四千万盘，创造了当时美国影视界的最高纪录。这部纪录片的名字叫《日本能，我们为什么不能》。

IF JAPAN CAN, Why Can’t We? 多么触动心灵的诘问。这部纪录片让我们知道了我们心目中那些质量非常好的国家或公司，曾经经历过怎样的磨难，又克服了怎样的困难。这部纪录片可能不会直接改善我们的产品质量，但可能会在我们内心埋下一颗种子。就我个人而言，最大的收获是认知思维的改变，我蓦然间发现自己好似变了一个人，看待很多现象时容易有独特的感悟。

◇◇◇

这段纪录片中戴明博士阐述的最重要的一个观点是：质量和生产关系可以兼顾。我原先的观念，要有好质量，必须重视测试环节，反复测试才行。戴明博士告诉我们“研发——测试——测试——再测试”的流程是不对的，质量管理体系应该内嵌于产品中。如丰田公司的自动织布机，断线会自动停止工作，自然就不会生产出断线的产品了。

同理，工业嵌入式软件研发领域，是否也可以将质量控制环节内建到产品研发过程中呢？带着这样的思维，再去思考我在跨国企业的那些日子，就能捕捉到很多价值点，其中对我个人后来帮助最大的是如下两个环：

传统的瀑布研发流程，是先集中设计，然后集中编码，然后再集中测试的。以戴明博士的理论，这种研发模式是错误的，其最大的问题在于中间环节会导致积压，不仅是一种很严重的浪费，而且会隐藏问题。如在完成一堆设计文档编写后，编码时才发现设计问题，返工量就比较大。

我很欣赏他们的一个观点：产品的研发过程是一个价值创造流程。换句话说每一步流程都是产品，是可提交物，每一步都在创造价值，而不是简单的将上一步工作留个尾巴给下一步。

第一个环是关于代码自查和代码审核。代码在交给项目团队审核前要先完成自查，团队内部推荐三遍自查策略，由局部到整体再到框架。如第一遍审核代码细节，第二遍思考整个代码流程是否恰当，第三遍思考当前软件模块在架构中的位置和接口等是否合理。我个人的经历，刚开始会感觉啰嗦一点，编码速度会慢很多，但养成习惯后，代码返工率会降低，反而大幅度提升了编码效率，是一种快与慢的完美统一。

团队代码审核，强调从全局去把握，强调核对知识库的诸多细节，强调团队成员培训，和代码自查侧重点不同。更为关键的是，只有在基于自审代码的基础之上，代码审核才变的可执行，也才能发挥出其应有的价值。

第二个环是关于集成测试和功能测试。我早期做产品时，有一种错觉，总之最终产品是要交给测试组的，因此团队内部的测试就容易应付了事。后来在自己带团队完成一些功能测试工作后，才对这个环有了较深入的理解。

集成测试用于将一个个的模块组合成产品，属于研发项目组内部的测试工作，集成测试侧重于接口、多模块协调等环节。功能测试由测试组负责，验证产品是否符合立项初期设定的各种目标，或各种行业标准要求，更多的是从用户角度对产品进行可用性测试。

一句话，测试组无法完成产品100%测试，更为重要的是，只有经过项目组集成测试的产品，测试组的工作才可行，才有意义。

◇◇◇

该纪录片中戴明博士阐述的另一个重要观点是：提升产品质量，关键还是要靠人，质量应该由人产生，为人服务。初期我对这个观点存在误解，感觉有点像废话，但当我经历许多，最后真正明白其背后深意时，立马意识到这是一种对传统管理模式的一种全新重构。

传统管理模式比较重视流程和考核，员工依附于流程。不知大家是否有过CMMI等软件研发流程的培训经历，或者体验过公司强行引入各种研发流程后的混乱局面。这些经历不仅让人痛苦，而且基于流程的各种考核机制（KPI经常基于年度考核单位），会让团队成员急功近利，公司内部斗争多过协作。

国内著名的CMMI专家林锐在他的书中描述到：如果企业真要提升研发管理能力，请忘掉CMMI条款，不要被CMMI束缚，自己该怎么做就怎么做。如果企业要拿CMMI等级证书，那就走捷径，不要感到羞愧，也不要指望靠CMMI等级评估来提升企业研发管理能力。好尴尬，也不知在打谁的脸。

传统流程模式下，公司奖励听话的员工（不听话的员工自然会被各种考核淘汰），希望所有工作像流水线一般自动化。作为对比，戴明管理思维更强调个人主动性，最典型的是丰田的拉灯模式，某员工一旦发现问题，会暂停整个流水线，这在传统管理模式下几乎是不可想象的。

为何丰田的员工敢于冒着让整个流水线停止的风险拉灯呢？从人员的组织结构大家或许能发现一点端倪。基于传统流程的人员组织模式一般如下：

领导邀请外部咨询公司构建研发流程，所有员工围着流程而工作。流程是核心，员工处于其次的位置。

基于戴明管理思维，公司人员组织结构呈倒立状，如下图：

所有一线员工，都有更高级别的支撑性员工作为后盾。一线员工拉灯后，后备支撑性团队会立马介入并快速解决问题。拉灯制的目的在于使问题不在中间环节积压或传递，是一种有效的提升产品质量的策略。但为了让拉灯制度可执行，需要一系列配套工作去支撑，不仅包括支撑团队，还有前端的可视化管理，看板制度等。

基于这种倒立的人员组织结构，非常有助于团队建设。以代码审核举例，普通员工中能力强、态度认真、在团队内部有一定领导力的员工会自然成长为支撑性员工，成长为审核员，此时他的工作任务会升华为：审核普通员工代码，在普通员工碰到困难或发现异常时协助，有人员请假或离岗时快速临时替代，承担一定难度模块的编码，产品级别集成测试等工作。

随着这种人员筛选制度的持续迭代，审核员中会诞生产品经理，产品经理中会诞生产品线负责人，产品线负责人中会自然诞生出架构师。这种自然成长的架构师，一般都具备较强的领导力和协调力，远比领导指派的要强的多。

此时，员工的考核，不再是以KPI为准则，而是以团队整体的利益和自身的领导力层级进行考核。团队内部会形成浓厚的协作氛围，而且个人也容易有比较好的职业发展愿景。此时，所有的制度，都是为人而服务的，或者用于克服人性中的弱点的。

“提升产品质量，关键还是要靠人，质量应该由人产生，为人服务”，现在大家是否会更容易理解戴明的这一观点。行业内有个笑话：福特流水线要雇佣1000双手，没想到来了1000个人。或许戴明管理思维就是想将流水线上的一双手手变回一个个有血有肉、有性格有脾气、有理想有冲动的人了吧。

◇◇◇

功能测试环节会经常使用各种自动化的测试手段，但这些手段不可能是在项目组提交产品后才开始构建的，此时，实际上任何有效的手段都很难添加了。如果在产品架构设计、编码、集成测试等环节都有测试组人员参与构建自动化测试模块，不仅能保证最终产品的可测试性，更省略了最后由项目组去编写各种不伦不类的调试说明的尴尬，而且便于测试组构建高复用的自动化测试组件。

测试如此，生产等很多环节也如此，围绕着质量和人，一些列新的管理流程被建立了起来，这种自然衍生出来的管理模式就是我眼中的全面质量管理体系（TQM）。

灭火队员——被动策略——主动策略——全面质量管理体系（TQM），认知在改变，质量也在迭代。此时，质量已经不仅仅是质量，更是管理，以质量为核心构建的管理流程，又在进一步提升产品质量。至此，我好像发现了高质量背后的终极奥秘：有序+可纠错=高质量。

基于全面质量管理理论，在结合各公司的实际情况，长期迭代下去经常会构建出一种称之为“标准化”的研发体系，有如下一些特点：

新产品研发时，可以快速从各处调集研发人员迅速组件团队，并能自然协作起来。支持大规模的人员动态协作组织，是标准化研发体系的主要特点之一。
产品质量和研发进度相对确定，这一点大家可能在和某些跨国公司合作时能体会到。
代码复用率高，产品研发速度快，可灵活适应市场变化。
具备复杂产品的研发能力。

总之，达到这个程度的公司，已经具备了相当强的核心竞争力，远非很多个人英雄主义的公司锁比拟。入职——团队——抽象——架构——复用——质量——标准化，或许本来就是一条永无止境的攀爬之路吧。

——————————————

返回目录

我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如需最新版PDF电子书，或期望深入交流，可加我个人微信nzn_xiaomaer，需备注“异维”二字。