汽车研发过程管理之怪现状-CSDN博客

转载自 汽车电子与软件

作者 | 罗宇超

接近凌晨，王工在虹桥办公室的落地窗前灌下第三杯美式咖啡。屏幕上的DOORS需求矩阵像蜘蛛网般蔓延到第387行，微信群里德系客户的质量工程师还在@他："HW14.3.2章节的CAN总线唤醒逻辑为什么没有对应到测试用例？"

这已经是他这个月第三次被客户抓包。而就在昨天上午，他刚用Jira给新势力客户演示完"敏捷开发看板"，下午又在禅道系统里给某主机厂补了158条测试用例——同一套车机系统的开发，他们部门同时维护着三个需求池、五套文档模板。

上面你看到的这些不是个案，而是当前汽车研发过程管理中的现状：每个量产项目都有两套研发宇宙。当审核老师莅临，会议室会播放标准得能当教科书的ASPICE流程动画；而工程师电脑里的真实世界，是散落在jira、doors、微信文件助手、钉钉云盘和桌面新建文件夹（3）里的祖传代码。

#01

流程表演艺术

某头部Tier1的电子电气部门，每月要为不同客户定制三套需求文档：给日系客户的Excel矩阵表，给德系客户的DOORS可追溯文件，以及内部使用的Confluence页面（方便内部协作，但不适合作为正式交付物）。更荒诞的是，需求变更时，工程师需要同时修改三个系统里的内容。某次紧急需求变更耗时16小时，其中14小时花在同步文档。

这种高难度的文档杂耍，消耗了30%的研发资源，也让公司不得不维护着多套ALM系统：IBM doors用于ASPICE认证项目，Jira处理敏捷迭代，禅道管理测试用例。工具链的碎片化，导致需求的关闭平均需要流转3-5个系统，真正用于思考业务逻辑与编码的时间不足35%。

这种现象的根源在于，部分团队对V模型标准研发流程的误解和片面认知。许多团队认为按照标准的ASPICE流程实施项目，会导致人力投入过高、开发效率低下，从而维护了多套研发管理模式和工具系统。

#02

对ASPICE流程的误解与滥用

为什么会造成这种认知？

ASPICE是汽车行业广泛认可的软件过程改进模型，其背后的V模型是一种金字塔式的思维逻辑方式，行事严谨，本应是提升研发质量和效率的有效工具。

然而，在实际应用中，一些评审师及质量管理人员由于缺乏对具体研发过程的深入了解，生搬硬套标准，盲目要求文档记录，导致流程繁琐、效率低下。

让我来说一个真实的故事。某车企供应商在ASPICE认证时，质量部门规定“必须用SVN锁定文档打基线”。但实际开发中，工程师发现：

· 基线管理工具和需求管理工具数据割裂，打完基线之后，大家还是看着不断变化的需求做开发，基线失去了意义。也有人严格按照基线的初衷，按照基线去开发，但发现这些锁定的基线，既不能跟踪状态，又不能分配任务，最终还是不得不回到需求管理工具。

· 为应对评审，团队不得不逆向编造基线文档，甚至伪造评审会议记录

“有一次我们为了证明‘需求评审确实召开过’，不得不让项目经理在周末召集全员开‘补录会议’。”一位参与过认证的工程师回忆道。

还有一次，评审老师要求团队编写一份详细的测试策略文档。团队成员花了大量时间撰写这份文档，但当真正开始测试时，却发现这份文档几乎毫无用处。原来，评审老师只关心文档的形式，而没有考虑文档是否真正适合项目管理。

团队的需求、设计、用例文档全部以Word、Excel来呈现，完全无法支撑团队利用高效的现代化工具进行条目化追溯与跟踪。团队不得不在Excel中手动维护巨大的追溯表格，工作量大幅增加。

#03

横向裁剪的危害

在面对ASPICE流程带来的效率问题时，部分企业采取了横向裁剪的策略，即仅在有面向客户过程评审要求的项目中采用ASPICE流程，其余项目则按照简易流程进行。

这种做法看似在局部项目上节省了时间和资源，但却为整个团队的项目管理，埋下了定时炸弹。

这颗定时炸弹什么时候爆呢？一般在下面3种情况下，爆的概率很大。

首先，团队成员需要适应两套不同的项目管理方式和工具体系，学习成本大幅提高。项目经理和开发工程师都在抱怨，想要两手抓，却一手都做不好。比如，一位新入职的工程师，刚熟悉了简易流程，突然被分配到一个需要采用ASPICE流程的项目中，他完全不知所措，只能重新学习。

其次，由于在某些项目上习惯了简易流程，当需要团队了解和适应ASPICE流程时，团队会有非常大的反弹。所谓由俭入奢易，由奢入俭难，大概如此。一位资深工程师曾说：“我习惯了简易流程，突然让我按照ASPICE流程来，感觉像是在为了流程而流程，完全不知道这些繁琐的流程有什么意义。”当某个“简易项目”突然被客户要求审计时，团队因不熟悉DOORS，被迫返工3个月。

最后，为了满足ASPICE认证或客户审核要求而进行的逆向开发，会严重打击团队士气，降低工作效率。越聪明的人，越不愿意做这种形式化工作，最后劣币驱逐良币。一位优秀工程师因为不愿意参与这种逆向开发，最终选择离职，这对团队来说是一个巨大的损失。

#04

实施纵向裁剪策略

纵向裁剪是一种更为有效且长期正确的改进策略。即无论是面向客户评审的项目还是自研项目，均采用同一套研发流程和工具体系。

但对于评审要求不高的项目，则在复杂的ASPICE流程上进行适当裁剪，以响应更快的市场要求。

例如：

需求、架构、设计、测试用例文档，都可以写得更简洁，如采用思维导图的方式列清思路即可。一位项目经理告诉我：“我们之前的需求文档冗长复杂，后来改用思维导图，不仅节省了时间，还让团队成员更容易理解。”。

采用面对面会议，评审需求和架构设计，有问题当场就改，创建更务实的技术专家文化。

减少测试策略、项目管理策略等策略类文档的编写，因为这种策略类文档，早已在公司级别形成共识，而无需每个项目都从新编写。

这种纵向裁剪策略不仅可以降低工具链采购和运维成本，还能使团队成员采用一以贯之的流程，避免在不同项目中感到困惑。

同时，团队能够将一套体系流程工具打磨到最佳状态，无论面对严苛或简单的客户评审要求，都能以统一的流程和工具应对，无需额外整理，从而提高团队的一致性和士气。

#05

优化工具与系统的应用：从“AI赋能”到“高效协作”

当前，许多企业使用的传统ALM工具，多是站在合规性要求的基础上进行设计，对于易用性、学习曲线、操作高效、与敏捷开发思想融合、AI提效等方面，则考虑不足。

软件名	诞生年代	被收购
Doors	1991年，Telelogic公司开发	2008年被IBM收购
Polarion	2005年，Polarion公司开发	2016年被西门子收购
Codebeamer	2002年，Intland公司开发	2022年被PTC收购