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

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

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

流程表演艺术

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

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

对 ASPICE 流程的误解与滥用

ASPICE 是汽车行业广泛认可的软件过程改进模型，其背后的 V 模型是一种严谨的流程。然而在实际应用中，一些评审师及质量管理人员由于缺乏对具体研发过程的深入了解，生搬硬套标准，盲目要求文档记录，导致流程繁琐、效率低下。

比如某车企供应商在 ASPICE 认证时，质量部门规定 "必须用 SVN 锁定文档打基线"。但实际开发中，基线管理工具和需求管理工具数据割裂，打完基线之后，大家还是看着不断变化的需求做开发，基线失去了意义。为应对评审，团队不得不逆向编造基线文档，甚至伪造评审会议记录。

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

横向裁剪的危害

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

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

首先，团队成员需要适应两套不同的项目管理方式和工具体系，学习成本大幅提高。一位新入职的工程师，刚熟悉了简易流程，突然被分配到一个需要采用 ASPICE 流程的项目中，他完全不知所措。

其次，由于在某些项目上习惯了简易流程，当需要团队了解和适应 ASPICE 流程时，团队会有非常大的反弹。当某个 "简易项目" 突然被客户要求审计时，团队因不熟悉 DOORS，被迫返工 3 个月。

最后，为了满足 ASPICE 认证或客户审核要求而进行的逆向开发，会严重打击团队士气。越聪明的人，越不愿意做这种形式化工作，最后劣币驱逐良币。

实施纵向裁剪策略

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

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

需求、架构、设计、测试用例文档，都可以写得更简洁，如采用思维导图的方式列清思路即可

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

减少测试策略、项目管理策略等策略类文档的编写

这种纵向裁剪策略不仅可以降低工具链采购和运维成本，还能使团队成员采用一以贯之的流程，避免在不同项目中感到困惑。同时，团队能够将一套体系流程工具打磨到最佳状态，无论面对严苛或简单的客户评审要求，都能以统一的流程和工具应对。