前言当甲方要求“交出所有文档”时你真的准备好了吗在汽车行业有一个经典场景主机厂甲方向零部件供应商乙方索要某个样件的配置项管理清单乙方发给甲方一份Excel表格而当甲方想进一步查看表格中对应的文档及其相关的评审记录、基线记录时乙方苦笑着翻开一个包含数百个文件的文件夹里面堆满了评审记录、变更日志、基线证明……ASPICE中的配置管理Configuration Management, CM究竟是一套严谨的研发规范还是变成了“文档游戏”的代名词一、到底什么是配置管理先忘掉那些翻译腔ASPICE 3.1的官方文档上写的是配置管理过程的目的是建立和维护过程或项目的所有工作产品的完整性并使其对受影响方可用。The purpose of the Configuration Management Process is to establish and maintain the integrity of all work products of a process or project and make them available to affected parties.说人话就是在车载系统开发过程中要时时刻刻记录完整的工作产物。那工作产物是啥对整车厂而言是车对零部件厂商而言则是整个零部件包含了软件和硬件的部分。为什么要记录工作产物的完整性这个也比较好理解比如供应商A给主机厂B供应了一个版本的零部件比如C样那么主机厂需要知道这个C样是基于哪些需求文档、哪些测试用例实现的交过来的是哪个软件版本、硬件版本。这样主机厂才能一清二楚方便主机厂后续去做验证、集成以及进一步开发。到此为止我觉得都是比较合理的要求。但为什么今天的配置管理变成了“文档收割机”我们用一个V模型场景来实际还原一下需求阶段乙方写了《泊车系统需求规范》v1.0评审发现5个问题修改后v1.1。架构阶段基于v1.1架构师输出《软件架构设计》v2.0评审发现3个问题修改后v2.1。测试阶段测试工程师基于v2.1写《系统测试用例》v3.0发现需求理解有偏差回溯修改需求到v1.2再回到测试用例v3.1。此时甲方要求乙方交付C样件配置项清单需要提供需求v1.2 评审记录含5次问题闭环架构v2.1 评审记录含3次问题闭环测试用例v3.1 评审记录含2次迭代变更请求单 CCB会议纪要 影响分析代码、编译报告、刷写脚本、标定数据……工程师算了一笔账一份需求文档衍生出至少12份附属文档。一个ECU项目平均200份需求就是2400份文档。一个项目2000人其中80%在写这些“证明你妈是你妈”的材料。甲方收到的文档堆中90%是“形式合规”而非“实质合规”。相信聪明的读者已经看出来了上述问题最简单的“解决方法”就是在评审记录里面全部标记为通过文档至少少了一半。这也是目前最常见的方法手动狗头但实际开发项目研发文档都是一次写对的评审一次全通过这样的团队别说12个月造车了我觉得6个月都有可能。二、甲方的“信任危机”与乙方的“形式主义”甲方要求乙方提供全部过程文档既是对乙方研发能力的信任缺失更是对自己真正需要什么的定位不清。这种信任缺失无可批判因为即使在一家公司内部也有部门墙部门与部门之间也有自身的利益冲突互相不信任天然存在更不用说甲方与乙方呢大家都不是好哥俩儿。不过对于自己真正需要什么甲方需要想清楚。从上面的分析也可以看出甲方所要求的正向研发、合规、追溯性其实更多已经沦为了形式文档。而他真正需要的“产品”在如此繁杂的文档要求下事实上质量大打折扣。举个例子某供应商在ASPICE评审中将需求评审记录中的问题数量从10个“优化”为0个评审结论直接标注“一次性通过”。甲方虽存疑但因缺乏技术能力深入核查最终验收通过。我尝试来猜测一下甲方的真正诉求确保C样件和上一次交给乙方的需求一致出了问题乙方能快速定位乙方流程合规、可信满足汽车行业规范如果甲方想用“文档完整性”来代偿“流程可信度”实际上是在蒙着眼睛糊弄瞎子呢。文档越多可信度越低——因为工程师开始“批量通过”评审记录CCB会议纪要有一份固定模板只需要改日期即可。三、解决方案从“写文档”到“做产品”1. 从“文档合规”到“流程可信”配置管理的核心不是“堆积文档”而是通过工具链自动化和流程可信度设计让甲方无需查看所有文档也能信任乙方的能力。解决方案工具链自动化使用研发管理ALM工具自动生成版本记录、基线化证明、评审日志等等减少人工干预。流程可信度设计通过标准化的评审流程、CCB变更控制委员会机制、问题跟踪闭环确保每次变更都有迹可循这些变更在系统中自动生成无论是甲方还是乙方都无法修改甲方自然而然可以相信这些记录。用抽查代替全部文档交付随时抽查乙方提供的任何一份文档在工具链系统中的正向研发、可追溯性、评审、基线等等而避免让乙方一次性将这些文档全部导出进行整理。案例某Tier 1厂商的文档交付实践某头部Tier 1厂商通过工具链整合使用一站式的研发平台ALM每次交付时除了交付最终定稿的研发文档之外过程文档都留存在乙方研发系统中。甲方通过平台可实时查看当前版本的基线状态所有变更的审批记录问题跟踪的闭环状态最终甲方只需点击几下鼠标即可验证合规性无需接收纸质文档。2. 敏捷开发与ASPICE的融合敏捷开发强调“快速迭代、最小化文档”而ASPICE要求“过程合规、可追溯”。两者的冲突看似不可调和但核心目标一致交付高质量、可验证的产品。融合路径以产品为核心敏捷团队在开发过程中最小化地写下实现的feature、story、task的ticket由工具链自动组装成完整的文档并完成版本管理、基线管理、变更评审等相关的功能。轻量化文档用自动化工具生成评审记录、变更日志避免人工撰写冗长文档。同时借助AI工具快速生成文档框架在此基础上进行修改节约至少50%人力。写在最后给甲方的三句话你要的不是文档是可控性。可控性可以通过工具链抽查实现而不是通过文档堆叠。你要的不是历史是此刻的确定性。交付基线就是此刻的确定性历史版本留在工具系统上需要时再查。你要的不是流程是结果。如果C样件在台架上跑不过测试给你1000份文档也没用。给乙方的三个行动今晚就把ALM上线提上日程没有工具链线下用Word、Excel实现这一切除非你愿意把团队规模扩大一倍另一半人专门写文档。明天和甲方开一次对齐会重新定义“交付基线”的范围把历史版本、评审记录等从交付清单里删掉。下周把CCB会议从线下搬到ALM让每一次变更都有迹可循但不必每次都打印出来。作者介绍罗宇超云体科技创始人前蔚来汽车软件质量工程师工具链工程师。
