汽车软件质量体系DIY（1）难题-价值-周期

导读：

撰写《汽车软件质量体系DIY》系列，是因为在汽车软件体系质量体系的构建和落地中遇到了太多的迷惘需要厘清思路。纵观各行各业，随着软件在越来越多工业领域中占据更重要的地位，汽车、机械、能源、航空航天、医疗器械……更多的实践、更深的思考，对于把握未来相信也会有所帮助。

01.

难题
 

（质量部）：

现在整车厂软件开发越来越复杂，有自研、有外包、也有联合开发，这时候搭建质量体系的着眼点在哪里呢？既然要做就参考行业标准吧，既然现在一说到汽车软件开发都会提起ASPICE，就按照这个标准做做看吧！

（软件团队）：

搞ASPICE？这群搞汽车质量的对软件都是外行！知不知道搞这些文档要花多少人力！计划跟踪文档要写、需求设计要分层、追溯性要建立、还要一大堆的检查表评审记录，说人力翻倍都是保守的，这年头招一个能干活的人有多难，精力都用来搞这个了谁来写代码啊。应付16949的审核是客户要求的没办法，搞ASPICE还是省省吧！

（质量部）：

搞ASPICE阻力太大推不下去，什么都不搞嘛上头又没法交代，要不就从已有流程往软件里推先做个一两件事，流程FMEA（PFMEA）、设计FMEA（DFMEA）什么的都做了，就让软件FMEA（SW FMEA）也做起来问题总不大吧？

（软件团队）：

软件FMEA？没听说过，问题的why-why分析横展开倒是有的，让大家往这个表格里面填是不是有点生搬硬套了？软件如此庞大，边界图如何限定范围？结构分析的时候硬件有属性，软件的属性是什么？穷尽的功能性/非功能性要花多少工作量知道么，如何安排优先级？如何确保产品特性不遗漏？构建功能网聚焦元素在哪一层？七种失效套用到程序代码里怎么考虑？功能网与失效链的关系怎么建立，那还不是要按ASPICE那一套搞双向追溯嘛？软件的SOD（严重度/发生度/探测度）怎么算？预防和探测措施和跟踪优化我们横展开里面有做过了，抄过去不是浪费时间么？——这些问题回答不了，软件FMEA没法做！

（质量部）：

行业标准（例如ASPICE/CMMI）推不下去，传统方法（例如FMEA）又不对路，那就从现有开发实践中收集提取，整一个适合公司“司情”的质量体系吧。

（两个月过去了……）

完全没有头绪！现有的开发实践一个项目一个样，模板指南没法定制；度量数据的定义的进展也不顺利，光是定义工作量的单位就够头疼的——不管是代码行数、功能点还是story points都没法达成共识；软件团队拼命加班，要整理出个流程改进的措施总得明白原因吧，天天叫“缺人”偏偏又缺少数据支持说不清问题在哪怎么协调到资源呢……

汽车软件的乌卡时代

来源：https://www.jianshu.com/p/a69e18b133ba

随着“软件定义汽车”的“乌卡（VUCA）”时代来临，建立汽车软件质量体系已经成为了行业公认的难题——

• V=Volatility（易变性）：汽油车到电动车、锂电池到氢能源、自动驾驶L1到L5、中美欧日群雄逐鹿……现在的汽车行业说是战国时代并不为过，无论技术的日新月异还是市场的风云变幻都让人应接不暇。

• U=Uncertainty（不确定性）：在快速变化之下，把握其中的规律就变得非常困难，仿佛一切都是不确定的，从瀑布模型到敏捷、从敏捷到规模化敏捷，往往流程定义刚刚完成市场的需求就已经不一样了。

• C=Complexity（复杂性）：为了应对各种不确定性，从政府法规到行业标准再到主机厂流程，各类需求层层加码，代码亿行起步的程序其中架构复杂自然不言而喻，更要满足功能安全、网络安全、代码规范、开源授权等等框架。

• A=Ambiguity（模糊性）：如此复杂的背景下，作为人类的我们要看清本质的难度可谓几何级数的增加，而偏偏“没有规矩不成方圆”，哪怕搭建了质量体系哪怕有了度量手段，其效果也许还是模糊不清，有如“薛定谔的猫”无法确定……

虽是难题在前，但硬着头皮也得把汽车软件体系的质量体系给DIY出来；

虽是看不到路，但只要踏出了第一步，就还有希望；

虽被百般吐槽，但反复试错持续改进，总有做成的一天。

02.

价值

周末，一个提问在质量专家微信群里引起了大家的关注——

来自微信群截图

A：各位大咖老总，周末愉快，想请教一下，质量部的价值在哪里，通常说到帮老板/公司创造价值，特别在中小民营企业，老板期望的这个“价值”是什么，谢谢！

于是，各位专家各抒己见——

B：这个要和你老板深入沟通，每个公司老板期望不一样

C ：这是个好问题，每一个人对质量的认知都是不一样的，非常同意楼上说的，你想在企业里发展的好，一定要和老板去沟通，企业的发展阶段是不一样的，老板的认知不 一样，质量部的价值也是不尽相同，我之前遇到一个老板，他的质量部长除了做好质量工作，还要做好兼职司机，随叫随到。

D：all of business are money.

E： 是的，有Business Quality 这个词语/策略出现了！

F：我认为质量部的一个价，值在于说如何使用最合适的质量成本来保证我们获取到最长远的利益。当然在长期利益和短期利益之间的平衡，以及预防质量成本和后期质量成本的平衡。这个得根据每个公司的现状还有客户的要求不一样的。不应该过度地亲和老板，更应该有自己的想法和分析。当然还有可以使用质量获取到客户，这些就看行业了

G：部门低成本运维，公司层面不创造明显利益但必须产生附加值。

H：嗯。那再说到质量就更深层，产品小质量和运营大质量。那是有比较大的差别的

I：每个工厂口号放在前面的都是质量第一，这不是value是啥？

J：我很同意F的说法 质量工作还是要不卑不亢 （虽然有难度）

K：很多时候嗯，老板不缺人家给他一个方向，但是他缺乏一个第三方，或者更加公平公正的一个声音，甚至对他的决策做出一些判定的一个声音，可能会更好一点。

L：其实质量总监经理很多时候还是要看自己的定位，自己的理想，最关键的是怎么经营自己的未来，只有自己的目标和方向明确了，这些问题就迎刃而解了。

M：是的，老板/公司/客户/行业对质量部的定位也是极为重要的指导方向！

N：你让他到质量部的各岗位干一天，和他讲价值就是秀才遇到兵，只有干了才知道 当然他也知道可以分出来部分给其它部门。

……

一时间，微信群里众说纷纭，好不热闹。设身处地在现实场景中，被老板问到你的部门有什么价值，任谁都会多少有些危机感——敏感些的会想到该不是要把整个部门给裁了吧。尤其作为质量部门，既不像销售部门能秀出订单上的真金白银，又不像开发部门拿出产品功能跑一跑，就连数据报表里的也不一定有项目管理部门更能吸引老板的眼球，如若不能在老板问出这个问题之前先发制人地在日常工作中潜移默化地用质量文化把老板给“向上管理”了，至少应该未雨绸缪再被问道这个问题的时候给出答案。

在质量领域，每个人的答案随着实际情况会有不同，但一定能体现他的层次。以下是个人根据十多年质量经验整理出来的层次图，比较主观，不同的质量专家根据自己经验可能整理出不同的层次表。其中，虽然人的本能都期待达到最高层次的流程咨询师，但不可能一蹴而就，作为下面层次的打杂、检查单、教练、培训、数据分析作为上游层次的基石，是不可能直接跳过的。没有现地现场的“打杂”、没有按部就班的检查单（checklist）、没有严谨的数据收集，上游的流程咨询不过是空中楼阁。

• 打杂人手：收集数据、整理报告、协调审计……这些都是质量人员的打杂日常，至于能不能快点升级，就看是否具备相应的技术能力——自动化脚本收集数据、规范化模板整理报告、畅通的沟通机制做好协调等等，在效率提升的基础上自然可以进行个人提升。

• 检查单检查者：检查单（Checklist）是质量人员不可或缺的工具也是无法跨越的阶段，脚踏实地一条一条地实施检查，该看代码看代码、该看架构看架构、该看客户抱怨看客户抱怨，积累到了一定程度才能真正理解检查项背后的逻辑和所要达成的目标是什么。

• 项目教练：基于日常与各个团队的协同，质量人员在特定细节把控上强于项目经理、而在全局把控上又强于单个部门如软件开发、测试、产品经理，因而应当在项目层级担当教练（coach）的角色，有效地落地改进。

• 组织培训讲师：从项目级到组织级的积累，对于质量人员是一个量变到质变的过程，看的项目多了、看的问题多了、看的解决方案也多了，它山之石可以攻玉，在整个组织内部可以成为一个打破壁垒的培训者的存在。

• 数据分析专家：与外来咨询公司的一大差异在于，内在流程人员可以拿到实际的数据，无论是项目缺陷、代码warning、需求条目、交付延迟……因此可以做到“纯干货、重实战”，而通过有效的方法组织分析就可以实打实的把流程落地，而非纸上谈兵。

• 流程咨询师：在质量工作中，机械地拿着checklist逐条问询已经远远不能满足时代的需要，对各类人员的需求把控、流程实施中的专业知识、工具链的熟悉使用，都成了不可或缺的基本技能。在现下的行情下，具备这些实力，那就是一个妥妥的流程咨询师了。

当老板问到“质量部门的价值”时，他更期待的是来自于“流程咨询师”级别的高屋建瓴的回答，质量人员也应该从这个角度入手，而具体怎么操作则需要随机应变，就如其中一位专家所回答的“这个要和你老板深入沟通，每个公司老板期望不一样”。只是记住，在回答这个问题，预备预判后续可能问到的问题，因为——

“Detail is Knowledge, Knowledge is Power.”（细节就是知识，知识就是力量）

03.

周期

在传统汽车主机厂（OEM）和供应商（Tier 1/2/3）的软件开发流程转型中，短时间内就很容易积累大量的“怨念”——

系统工程师：原来的系统需求写得好好的，又详细又清晰，看着就能把代码写出来。现在可好，一定要把软件需求拆出来，一拆就拆出一大堆事情——原来系统需求里重复的内容得删掉吧；改过的文档得评审吧；追溯性得建立吧；一致性得确认吧……你说好好的都放在系统需求里不就好了，费那事干嘛？

软件工程师：把软件需求拆出来挺好的，这样咱们软件有了自主权，不然按照系统那帮人写的需求做出来东西来了，出了问题还得我们背锅。不过要把软件的合规性测试和集成测试拆出来就比较坑了，之前虽然软件都测但追溯性什么的要求没那么严，基本都是让测试团队把关。现在多了这么多测试的工作量，叫我们上哪要人去？

测试工程师：谢天谢地，流程总算要求软件团队自己测试了，不然每次东西基本不测一坨软件丢过来让直接我们把关，报过的问题还反复出现，这样他们自己把关问题再给出来的软件问题总归能少一点。但是现在组织流程把测试统括的责任都放到我们这边是肿么回事，从SIL、MIL、PIL、HIL还要有VIL都让我们确认是不是有一点夸张。明明是一个ECU的开发偏偏搞到整车级别的测试，这个怎么搞。

EE/ME工程师：这么多年我们的流程都定义得好好的，为了个追溯性（Traceability）偏偏要让我们把所有文档都往系统（DOORS、Polarion等类的工具）上搬，用起来超复杂的，还容易出错，简直是为了流程而流程……

项目经理：这平常列一个EXCEL、写一封邮件、拉一个会就能搞清楚的事情，偏偏要上JIRA分配任务，这个工具一直都是软件部门才用的我们项目经理就从来没用过，不是强人所难么！

质量工程师：大家都不配合，上头又逼着推ASPICE，这可让我咋整啊……

不同于特斯拉的横空出世，多数的传统汽车在软件开发流程方面，都面临着已有多年积累的弃旧迎新批判继承，而又不同于纯粹的软件开发，汽车软件依附于汽车这个产品的应用程序开发。因此在汽车软件开发流程建立/转型之初，就应该明确一个前提：汽车软件开发的生命周期不是一般的软件开发生命周期（SDLC - Software Development Life Cycle），而属于更广义的应用程序生命周期管理（ALM - Application lifecycle management）。（以下就用ALM代替）

应用程序生命周期管理 (ALM) 是计算机程序的产品生命周期管理（治理、开发和维护）。它包括需求管理、软件架构、计算机编程、软件测试、软件维护、变更管理、持续集成、项目管理和发布管理。ALM 是比软件开发生命周期 (SDLC) 更广泛的视角，SDLC仅限于软件开发的各个阶段，例如需求、设计、编码、测试、配置、项目管理和变更管理。ALM 在开发后继续，直到不再使用应用程序，并且可能跨越许多 SDLC。（参考资料）

在互联网寒冬的同时，智能制造对软件的需求在各制造业中与日俱增，如汽车、医疗器械、能源、船舶、航空航天……软件人才进入这些领域之初，对于SDLC与ALM这两类生命周期的区别应当有清醒的认识。而原本就扎根这些领域的专业人员，同样需要基于这样的认识，积极面对软件开发流程所带来的的变化。固然在转型的过程中会遇到各种难以预料的难题，但身处“在短短几十年里就走完了西方发达国家几百年的路”的中国，这样的变化不早已习以为常了么？

面对ALM的复杂性，不同的行业作出了各自的应对，而德国汽车工业联合会VDA给出方案之一则是“插件（Plug-in）”的概念，即把产品分解为不同的级别（Layer）。系统级别提纲挈领，而软件、机械、硬件（电子）各司其职，如下图——

来自ASPICE 3.1标准

在构建汽车软件质量体系的时候，虽然不一定全盘接受ASPICE的标准要求，但考虑ALM的复杂性进行分层还是非常必要的。如同前面提到的，转型必然会带来各个部门的“怨念”，如何务实地落地，则是对整个组织的考验，当年以IPD为代表的的流程在华为的落地就带来了公司的持续发展，可见方向对了，带来的收益将是巨大且持久的。