熟悉的朋友都知道，我的聚焦点在于汽车软件研发管理上，而企业专职研发管理的职能经常落在质量的角色上，但我很少专门写这个角色的文章。
原因是，我始终觉得软件质量的“工夫在诗外”。不过，出于对这个职能的尊重，今天系统写一篇，看这个活儿到底该怎么干？主要会分三大板块：基本工作内容、质量管理水平阶梯、行业对软件质量的要求。
1
基本工作内容
第一部分纯谈理论。
软件质量保证的目的是提供独立和客观的证据，以证明产品和过程符合组织要求。质量保证的工作主要分5大步骤：
1.1 定义软件质量保证计划
根据项目特定的质量目标，准备软件质量保证计划。
在项目计划中安排质量保证活动。
批准软件质量保证计划。
1.2 执行过程软件质量保证活动
根据项目进度和软件质量保证计划执行过程合规性检查。
按照软件质量保证计划定义软件质量控制面板。
汇总过程检查状态和结果。
在特定的管理工具中记录差距、确定行动项、责任人和截止日期。
1.3 执行产品软件质量保证活动
根据项目变更级别、软件项目计划和软件质量保证计划，定义软件里程碑评审计划。
召开软件里程碑评审会议，团队对最终红黄蓝评价达成一致。
汇总质量阀检查状态和结果。
在特定的管理工具中记录差距、确定行动项、责任人和截止日期。
1.4 汇总和沟通质量保证活动与结果
总结过程与产品质量保证的结果，包括差距、行动项及行动项的最新状态。
在相关的项目管理会议上，进行质量状态汇报或升级。
1.5 确保行动项关闭
针对差距和行动项进行跟踪直至合理关闭。
这是一套最基本的PDCA循环，逻辑也并不复杂，这也是前些年汽车行业软件质量一直以来的主流做法，但我们这么干够吗？
可以说，在如今内卷到极致的汽车行业，几乎没有任何价值彰显的空间，所以，一定需要拓展和进阶。
2
质量管理水平阶梯
至于如何拓展，我们可能需要再次思考一下质量管理的不同水平。按有效性递增排列的5种质量管理水平如下。
2.1 第一级：客户发现缺陷
通常，代价最大的方法是让客户发现缺陷。这种方法可能会导致担保问题、召回、商誉受损和返工成本。
第一级别属于质量的失职，不用多说。
2.2 第二级：检测和纠正缺陷
控制质量过程包括先检测和纠正缺陷，再将可交付成果发送给客户。该过程会带来相关成本，主要是评估成本和内部失败成本。
第二级是常说的QC，迁移到软件领域，通常是测试或修复bug。
2.3 第三级：质量保证
通过质量保证检查并纠正过程本身，而不仅仅是特殊缺陷。
第三级就是QA，是我们最常说的软件质量的职能主体，也是我们第一部分论述的内容，但当组织质量文化比较差时，经常会滑到第二级。
2.4 第四级：质量融入
将质量融入项目和产品的规划和设计中。
第四级属于顶层设计，这部分通常是我们对QA的进一步期待，但也要把质量工作本身作为业务的一环。
2.5 第五级：质量文化
在整个组织内创建一种关注并致力于实现过程和产品质量的文化。
第五级是最重要的，但比较玄虚，个体无法掌控。
所以，汽车软件质量本身应该要向第四级努力。
3
行业对软件质量的要求
努力需要有一些实实在在的方向，这部分会写得最实在。
我收集了近三万字的软件质量相关的JD（由于是招聘网站找的，可能会有重复的，但在多渠道发布也能一定程度上说明其紧缺程度和热度，所以就不做去重处理），并对其关键词进行了分析，或许略能代表现在这个圈子对于其的认识和要求，可作为各位方向上的参考。
直接看结果。
下面来逐一分析。
3.1 体系/流程/过程
“体系/流程/过程”是数量最多的，很显然，脱离于独特问题，而针对体系进行系统性预防的质量保证，依然是这份工作的主体。
流程&体系是我们的最主要的专业能力和工作对象，基础不牢，地动山摇，首先要做一个公司内对流程与体系最熟悉的人。
3.2 开发
第二个关键词是“开发”，也是意料之内的，毕竟在软件整个生命周期内主要着力点在开发阶段的，不像机械产品SOP后会有老化损耗的问题，软件可靠性更多地依赖开发设计。
3.3 沟通/合作/协作/协调/组织
“沟通/合作/协作/协调/组织”高居第三位，比预想高一些。
仔细想来，也是合理的，质量不写代码，也不做测试，不会给项目直接增值，却还要挑毛病，沟通的能力和双赢的情商就很重要了。
3.4 评审/审计/审核/检查/评估/度量
“评审/审计/审核/检查/评估/度量”，不同角度的说法，但粗略理解就是“检查”，质量的来源就是检查。到目前为止，检查依然是主要的工作手段。
3.5 问题/风险
那么，“检查“是检什么、查什么呢，也只能是“问题/风险”了。
没有它们，就不需要质量。有人会说，质量还要找到做的好的，不能只看差的，道理没错，有些情况确实会提好的，可是要是都是好的，就说明项目组已经可以自驱动做好了，质量作为支持角色的价值自然弱化，质量不会这么做的，没有驱动力。
3.6 落地/推动/实施/执行
做一个居高临下、站着说话不腰疼的说教者，不光是做事的人不服，组织也不会允许，“落地/推动/实施/执行”是组织对质量的期望，养这些人不只是为了挑毛病，还要负责支持解决毛病，质量最喜欢谈的PDCA，最喜欢谈的闭环，肯定也会被人要求在自己身上。
3.7 改进/优化/改善
当然，解决个例的、具体的问题还得是专业的人，质量要更侧重于从流程和体系层面解决，“改进/优化/改善”这部分也正是体现质量高阶水平的环节了。就像8D有8步，但核心在Root Cause的分析上。
3.8 ASPICE/CMMI
“ASPICE/CMMI”几乎是比较具象的软件质量的代名词了。
据我了解，汽车行业的软件流程目前基本都在映射ASPICE（与CMMI一脉相承，在这里的统计中CMMI约占1/3），特别是Tier1&2迫于OEM的审核压力，也在不停地进行相关部署、认证和宣传。
质量比较虚一些，ASPICE算是一个抓手，可以认真研究下。
3.9 功能安全/ISO26262、敏捷/Scrum和ISO9001/16949
依次排后面的“功能安全/ISO26262”、“敏捷/Scrum”和“ISO9001/16949”也是抓手。
除了最后的“ISO9001/16949”，虽然是基础，但太成熟，不用多讲，ISO26262与敏捷和ASPICE的融合是一个非常重要的话题，值得深思。
此外，值得提的是IPD，虽然占比不多，但作为在华为获得成功的流程，或许在汽车行业内会是一个新鲜的视角。
3.10 分析/总结、表达/语言/写作/报告/汇报
“分析/总结”可以类比于医生的手术刀、军人的枪和作家的笔。日常实操中，我们要用“分析/总结”的头脑工具处理获取的“数据”输入，然后，进行“表达/语言/写作/报告/汇报”的输出。
获取数据、分析总结及汇报输出这几个环节是质量日常工作模式，也可见出功底厚薄，尤其是汇报，通常也是质量的权力与威望来源。
3.11 业务/研发
“业务/研发”，我觉得可以这样理解，质量很多时候都是理论的，但这不是质量的目的，理论之后要结合实际业务，这和前面讲到的落地是同一范畴的。
至于为什么把研发和业务放在一起，因为汽车行业里对于研发的理解比开发外延更大，会更接近于所谓的业务。
比如，ASPICE4.0相比较3.1，也扩充了硬件、结构和机器学习，关注点不仅仅在（软件）开发上了。
3.12 工具
“工具”这块分了两部分。
一部分是常规意义的质量工具，或者叫方法论也行，比如，FMEA、FTA、MBSE、7大工具之类。
另一部分是数字化工作，现在大家都在推动数字化转型，比如，Polarion、Doors、JIRA都属于这一类。
特别对于软件质量，没有数字化工具的支持，几乎无法进行。
3.13 测试
“测试”这部分占比也较多，测试和质量在识别问题的角度是一致的，质量非常需要从测试专业的角度理解产品和项目，也非常需要和测试密切合作。
3.14 培训/指导
“培训/指导”不多扩展，对于流程的创立者、守护者和推广者，自然需要这项技能。
3.15 意识
“意识”或者也可以称之为质量文化，极其重要，同时又极其虚，极其难建立，毕竟改变思想、改变意识谈何容易，但是一旦真的能撼动这块硬骨头，就会是软件质量工作源源不断的原动力。
再说一句，关键的是领导认可和组织有土壤。
3.16 认证/证书/PMP/ACP
“认证/证书/PMP/ACP”以及ASPICE PA、Scrum Master、内审员等这类资格认证，就像是各种含金量不怎么高的证书。一句话，有比没有强。
3.17 英语
虽说文化自信，这几年国外文化输入也有所淡化，但“英语”的重要性短期内仍然是有的，特别是外企。
3.18 项目管理
“项目管理”的经历和意识对于做好质量沟通有很大帮助，但确实不需要承受项目经理那样的“压力”。
3.19 编程/C语言/JAVA
“编程/C语言/JAVA”排在了最后，大体可以说明这本身的技能至少不起决定性作用。当然，懂的话更好了。
对于数据的分析就这么多了，限于数据的有效性和分析的水平，结论未必精准，供参考，并欢迎讨论。
4
全文小结
软件质量是个务虚的管理性工作，但切不可一直沉迷于务虚。所以，我们从虚到实，依次讲了PDCA的基本工作套路、通过流程与体系保证质量的理念以及行业对软件质量的理解。
5
写在最后
在这个环境下，干务虚的活儿，最怕沉迷于务虚，虚虚实实，虚中一定要有实，不可不察。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
完
