1. 一张ASPICE CL2证书为什么让智能驾驶圈都在转发亚远景那条热烈祝贺希迪智驾通过ASPICE CL2评估的消息最近几天在圈里刷屏不少。做汽车软件、做域控制器、做智驾方案的朋友一眼就懂这不是普通的商务祝贺而是我们又多了一个能打量产项目的供应商的信号。这两年做智能驾驶、ADAS、域控制器的公司要是还没把ASPICE CL2过下来出去谈前装量产项目都不好意思递名片。先把基础概念捋清楚。ASPICE全称Automotive SPICE是汽车行业基于ISO/IEC 15504SPICE框架发展出来的过程评估模型主机厂用它来评估供应商的软件开发过程是否受控、是否可重复。CL2全称Capability Level 2翻译成已管理级核心含义是你们不只是把功能做出来了那是CL1而是这个过程经过了策划、监控与数据反馈有明确的角色责任、有工作产品定义、有纪律地执行——换句话说任何一名骨干离职过程还能照着定义继续跑不会塌方。为什么主机厂认这个东西因为智能驾驶软件的复杂程度已经超出个人英雄主义能扛住的范围。一台量产车的智驾系统代码量动辄上百万行起步横跨感知、融合、规划、控制、高精地图、车辆接口几十个模块再叠加OTA远程升级、功能安全、网络安全合规如果开发过程不受控出问题只是时间问题而且一出就是规模性问题。ASPICE CL2其实就是主机厂用来筛掉草台班子式团队的最直接工具——你连过程都管不住谁敢把刹车、转向这类功能交给你1.1 CL2在能力等级坐标里的位置聊CL2之前得先把整个能力等级阶梯看一眼不然很容易被各种缩写绕晕。ASPICE把过程能力分成六个等级CL0不完全级过程根本没实施或实施结果无法证明。CL1已执行级过程目标基本达成但靠的是个人能力和临时发挥没有制度化。CL2已管理级过程被策划、监控、调整工作产品有明确要求且受控项目级管理到位。CL3已建立级在CL2基础上企业级有了标准过程项目按标准裁剪执行并且持续收集数据改进。CL4可预测级用统计手段量化控制过程表现。CL5持续优化级用数据驱动创新与优化。主机厂对量产供应商最常见的要求就是CL2个别激进的平台项目会要求CL3但主力需求还是压在CL2上。这里有个容易误解的点CL2是项目级的过程管理能力不是公司级的。你只需要在指定范围内证明某个代表性项目把过程跑起来了而不是全公司所有项目都达到这个水平。很多团队一上来就想建一套完美的大而全体系其实完全没必要CL2的切入点永远是一个项目把这条流程跑透。1.2 CL2到底在评哪些过程ASPICE过程很多但CL2评估一般不会把几十个过程全部评一遍常见做法是选择与项目强相关的V模型主链条加上必要的支持过程和管理过程。以软件类项目为例典型评估范围是系统工程类系统需求分析、系统架构设计、系统集成与集成测试、系统合格性测试。软件工程类软件需求分析、软件架构设计、软件详细设计与单元构建、软件单元验证、软件集成与集成测试、软件合格性测试。支持类质量保证、配置管理、问题解决管理、变更请求管理以及联合评审、文档管理等。管理类项目管理、风险管理。可以看到这条链路就是从需求到设计、到编码、到测试、到交付的完整闭环。CL2评估的核心是看这条链路上每个过程的过程属性有没有达标——特别是PA 2.1绩效管理有没有定义活动计划、分配资源、监控执行、追偏差和PA 2.2工作产品管理工作产品内容是否清晰、版本受控、变更可追溯、发布过程明确。评级的时候每个过程的属性等级用N/P/L/F打分N是未达成P是部分达成L是大部分达成F是完全达成。以CL2为目标的话CL1和CL2相关的几个过程属性都得拿到L以上严格一点的主机厂甚至要求全部F。1.3 希迪智驾这次过评为什么值得关注回到希迪智驾这个案例。这家公司主要做商用车自动驾驶、矿区无人驾驶、V2X车路协同这些场景和乘用车智驾有个显著区别客户不是普通的C端消费者而是矿区业主、物流车队、工程机械厂商交付形态往往是整套解决方案加运营服务。这类业务过去大多靠研发能力和现场实施能力打单签完合同就埋头干过程管理相对粗放。现在主动把ASPICE CL2拿下说明两件事一是公司开始往规模化、可复制、可交付的方向转型二是它在为后续的海外市场、合资客户以及车规级产品合作铺路。很多海外主机厂在评估中国智驾供应商时第一句就是有没有ASPICE CL2这一张证书比任何PPT都管用。2. 从启动到过级一条完整的CL2准备路径这一节是很多人最想看的干货。我见过不少团队拿到过级目标后上来就开始写体系文件三个月憋出两百份文档结果评估当天被challenge得体无完肤。为什么因为CL2评估看的是过程是否真实执行并有证据不是看你的文档多不多、厚不厚。整个过程我把它拆成四步按顺序走完过级基本上就是水到渠成。2.1 第一步摸底评估与差距分析准备工作的第一步不是写文件而是搞清楚现状。找有资质的评估师最好是intacs认证的主任评估师带团队或经验丰富的咨询顾问对试点项目的现状做一次快速差距分析。怎么快速法按评估范围里的每个过程对照CL2要求逐条检查这个过程的输出有没有有没有实际使用的证据角色清不清楚监控数据有没有把差距列成一张RAG状态表绿色是基本满足黄色是部分满足红色是完全没有。我特别想强调这个阶段的价值。很多团队对自身问题一无所知自己觉得干得挺规范一查全露馅。比如需求管理团队用Excel管需求清单改了哪个版本也说不清开发依据的是不是最新需求也没法证明——这种在CL2里直接就是红色项。摸底的价值就是让你把所有风险提前暴露出来而不是等到正式评估那天让评估师来给你爆。2.2 第二步过程定义与裁剪差距分析之后就要定义目标过程了。注意ASPICE不要求你创建一套全新的流程更不要求你照抄某大厂的最佳实践。它要求的是适合你组织特点的过程定义。很多团队栽就栽在贪大求全把CMMI或者某标杆车企的流程套过来结果团队跑不动文档体系臃肿最后执行变形。正确做法是基于现有工作方式做结构化。比如你们现在开例会那就把它定义成项目跟踪会议明确参与人、频率、输入输出你们现在用Jira管任务那就定义成变更和问题管理的载体。然后做裁剪矩阵哪些过程全评、哪些过程部分适用、哪些活动跳过裁剪理由必须写清楚评估师会看合理性。这里有个实操要点过程定义文件不要写成八股文建议采用流程图加角色表加工作产品模板加检查单四件套。流程图让人一眼看懂活动顺序角色表明确谁干什么模板保证输出格式一致检查单支持过程自查。模板尤其重要因为评估文档抽样的就是你的工作产品模板设计得好抽样证据会非常规整。2.3 第三步试点项目跑起来过程定义好了必须找一个真实的项目来执行。这个项目最好满足三个条件一是项目类型和你未来主要业务一致比如希迪智驾就适合拿一个正在交付的量产或准量产项目二是时间窗口能覆盖完整的V流程至少要有需求到测试的闭环三是团队成员稳定尽量不要在评估前出现大面积换人。试点项目跑的过程中咨询顾问或内部过程工程师要做的不是坐在办公室里看文件而是跟着项目走每周跟项目例会、抽查工作产品、对关键交付物做同行评审、记录过程偏差。这个过程叫过程落地它的目标不是把项目变成完美的教科书案例而是让项目成员形成肌肉记忆——需求变了知道要去提变更、测试发现了缺陷知道要挂到问题管理、任何工作产品知道它应该有版本和责任人。两个月下来过程和团队就磨合得差不多了。2.4 第四步预评估与整改正式评估之前强烈建议做一次预评估最好用和正式评估一样的评估师或同等资质的顾问按照正式评估的流程和抽样方式跑一遍。预评估的价值在于它能在不产生正式不符合项的前提下把绝大多数问题暴露出来。你会惊讶地发现有些过程你以为做到了L实际上连P都勉强有些工作产品你以为齐了结果版本混乱到评估师无从下手。预评估之后要形成整改计划按优先级排红色项关键过程属性不达标必须在一两周内闭环黄色项排第二绿色项保持。整改不是给评估师演戏而是真实补齐过程执行缺失。这里我要给个建议整改一定要留证据评估师正式来的时候看的就是证据链。你今天补了一个流程明天把相关会议纪要、评审记录、审批邮件留好这就是你的证据。3. 评估当天到底发生了什么一个亲历者的视角很多没经历过正式评估的团队对评估当天有各种想象。我以亲历者的身份讲讲正式评估一般持续三到五天具体取决于评估范围大小和取证情况。它不是考试更像一次高强度、有方法论的尽职调查。每天上午通常先做小组评审评估师内部合议下午安排访谈和文档审查晚上再整理发现项节奏相当紧凑。3.1 文档评审与抽样证据链是王道评估师进场后第一件事是看文档。根据你提供的项目计划和过程定义评估师会确定抽样矩阵然后对每个过程抽样至少一到两个工作产品实例。抽样不是随便拿两份就完事评估师会刻意选择有代表性的样本比如需求文档的最新版本、某个历史里程碑的设计文档、某轮测试的报告。他们会重点检查工作产品的完整性、内部一致性、版本状态和变更历史。这块最容易出的问题是文档看起来有实际上没有。比如项目计划里写了要配置管理但配置管理计划没人签批测试报告里写了通过率但没通过的用例没解释需求评审有会议纪要但纪要里没记录遗留问题和责任人。这些在评估师的放大镜下全是漏洞。所以我一直说证据不是有文件就行的而是能构成一条完整的链条——计划到执行、执行到检查、检查到纠正、纠正到留档环环相扣。3.2 访谈不是拷问但别掉以轻心文档评审之外评估师会对项目关键角色做访谈。被访谈的包括项目经理、需求工程师、架构师、开发人员、测试人员、配置管理员、质量工程师等。访谈不是考试背诵评估师会拿着你提交的文档问具体问题这个需求的来源是什么这个变更走的是哪条流程缺陷修复之后有没有回归验证你上一个迭代的偏差率是多少怎么处理的要注意的是访谈不是只找最会说的人。评估师会故意挑一线的开发、测试问最具体的问题目的就是验证说一套做一套有没有发生。所以准备阶段就要做全员briefing不需要背答案但必须让人人都了解基本流程和工具用法知道自己负责什么、有事找谁。我最常见到的翻车场面是项目经理说得头头是道开发一问三不知当场穿帮——这说明过程压根没落地只是PPT落地了。3.3 评级规则与通过线评估师收集完全部证据后会对每个过程的能力等级做初步评定然后和公司代表开共识会逐过程确认评级结果。这里面有个关键规则CL2评估不是总分及格就行而是每个抽样过程都必须达到CL2即相关过程属性至少L。一个过程掉到CL1整个评估结论就会受影响。有些评估模式允许带短期行动计划如果对个别问题有明确的纠正计划但主流主机厂供应商合同中通常要求的是无重大不符合项。评估结果分几个层级通过所有抽样过程CL2达成、有条件通过部分过程带纠正措施、不通过存在关键过程未达成。希迪智驾这次能拿到明确的CL2通过结论说明在抽样范围内所有过程都过了线这个含金量是实打实的。会后评估师会给出发现项清单和改进建议这份材料别锁进抽屉它就是下一阶段过程改进的第一手输入。4. 最容易翻车的九个坑现场实录与避坑指南这一节我整理了这些年陪团队过级时反复出现的高频问题每一个都是真实踩过的坑。对照自查比看十本理论书都有用。4.1 需求管理双向追溯的陷阱需求是V模型的最上游也是CL2评估的重灾区。最常见的问题有三个一是需求没有唯一标识用需求1、需求2这样命名根本没法追溯。二是需求到设计、设计到测试用例的双向追溯矩阵不完整要么漏了某些需求要么没法证明每条测试用例都有对应需求。三是需求变更后下游设计、代码、测试的同步更新不及时导致追溯链断裂。解决思路很朴素用需求管理工具常见的如DOORS、Polarion、Jama以及国内团队爱用的Jira加插件来管需求ID把需求-设计-测试的关联关系建起来。哪怕项目规模小用Excel强约束格式维护也行关键是要有变更自动触发同步检查的机制。评估师看的是证据给你一条需求你能不能五分钟内指出它对应哪个设计模块、哪几条测试用例、最近一次变更是什么时候。4.2 配置管理版本混乱是重灾区CL2的PA 2.2就是工作产品管理配置管理是它的核心载体。很多团队用Git管代码但配置文件、文档、测试脚本散落在个人电脑或网盘里版本根本无法控制。评估师抽样时最怕见到的是这个文档我有三个版本我发你的这个是最新的这类回答——对不起这直接就是不符合项。我要强调一个概念配置管理不是代码入库而是所有基线工作产品受控。工程文档、需求说明书、架构设计、测试用例、客户交付物都必须在配置管理库里有明确的目录结构、命名规范、版本标签和权限控制。每次里程碑完成要打基线基线内的东西要变更必须走变更流程。这个机制在评估前后是重中之重因为它直接决定评估师对你工作产品管理的信心。4.3 问题管理与变更管理数据要闭环问题解决管理和变更请求管理看起来是支持过程但评估师特别爱深挖。常见问题包括缺陷库有记录但没有优先级和责任人问题关闭了但根本没有验证修复效果变更请求批了但变更影响分析只写了影响不大四个字。这些问题背后其实是同一件事流程没有闭环。闭环意味着每一条记录都要有发现到分析、分析到处理、处理到验证、验证到关闭的完整路径每个环节都有时间戳、责任人和证据。我给团队的建议是把问题管理当成产品来运营定义缺陷报告的字段、状态流、升级机制每周开质量例会过一遍遗留缺陷趋势。你会发现这不仅是为了过级真的能提升交付质量。4.4 其余高频坑一览剩下几个高频问题我直接列个表方便对照每一条都对应过真实的不符合项坑位典型症状避坑动作计划虚设项目计划写得很美实际干的和计划两张皮计划要有版本和审批变更走流程周例会核对偏差估算无依据规模、工期、工作量拍脑袋用历史数据和合适模型估算记录假设前提评审走形式评审会议纪要全是同意无异议记录评审要有问题清单和跟踪号测试不可重复测试报告有结果但没有测试环境版本和数据测试用例、环境、被测版本全部入配置管理风险登记册休眠风险列了不跟踪不更新每周评审风险状态追加缓解措施证据角色职责模糊项目有多人干同一件事出事互相推RACI矩阵明确到人访谈口径一致培训无记录新人直接上岗流程文件发了不看上岗培训有签到和考核保留记录拿这张表去看自己项目中三条以上的先别急着约评估师把坑填了再说。5. CL2之后的路这不是终点是量产入场券通过了CL2庆祝是应该的但我更想泼点冷水CL2只是起点。尤其对希迪智驾这样有商用车和矿区无人驾驶背景的公司来说后续要面对的是三座大山。5.1 向CL3迈进与体系固化CL2证明一个项目跑得不错CL3要求的是整个组织能复制这种能力。这意味着要把试点项目的经验抽象成组织级标准过程建立过程资产库实现跨项目的数据度量。大部分公司过了CL2之后会松一口气但主机厂供应链管理是动态的——今年要CL2明年可能就要CL3起步。我的建议是CL2刚过的那段时间趁团队记忆还在立刻启动组织级过程资产的沉淀把试点项目里养成的模板、检查单、度量基线固化下来后面再推广到新产品线成本会低得多。如果你准备的时间足够长我在实操中也建议给新项目的体系设计留出向ASPICE新版本迁移的余地。目前主机厂主流正式评估还是基于3.1版本展开过渡期内很多OEM没有完全切到新版本但新项目的接口管理、网络安全相关过程的预留最好一开始就考虑进去省得后面推倒重来。5.2 与功能安全、网络安全和预期功能安全的握手单独做ASPICE是不足以支撑智能驾驶量产的。当前行业主流要求是ASPICE CL2/CL3与ISO 26262功能安全、ISO/SAE 21434网络安全、以及预期功能安全SOTIFISO 21448协同建设。它们的结合点在流程接口比如功能安全的ASIL等级会影响开发流程的严格度ASPICE的过程产物需求、设计、测试证据同时就是功能安全评审的输入网络安全漏洞的处置要落到问题管理里去闭环。对智驾公司来说最务实的路径是一个过程体系多标准映射不要为每个标准建一套流程而是把需求管理、设计、测试、变更、问题这些基础过程做好然后做标准差距映射看看功能安全和网络安全还要补哪些活动。这样评估的时候也是一次准备多处受益比各干各的省一半以上的力气。5.3 商业层面的真实价值最后说说商业价值。ASPICE CL2在招投标里是实打实的加分项尤其是在国际主机厂的供应商准入评审里它是硬性门槛。对希迪智驾这种做商用车自动驾驶解决方案的公司未来出海、和外资Tier 1联合开发、参与车路协同项目都会因为这张证书少掉很多解释成本。更重要的是过程能力的提升会直接反映在产品缺陷密度、交付准时率、客户投诉率这些指标上——我见过不止一家公司过完级之后内部度量数据明显变好因为团队终于开始用数据说话了。6. 最后分享一点个人体会陪了这么多团队做ASPICE过级我最大的体会是这个证书从来不应该是为了给客户看而做的项目它应该是团队把工程管理基本功补齐的一个契机。希迪智驾这次通过CL2恭喜的话不用多说我更想看到的是他们后续能不能把CL2的惯性用在新项目、新产品上。对那些正在准备过级的团队我最后给三条实在建议第一尽早做差距分析别闷头写文档先知道自己差在哪第二让一线员工真正参与流程定义别让流程文件成为纸面文章执行的人不认同文件再漂亮也是废纸第三把证据文化植入日常所有的评审、变更、测试记录都当成未来的法庭证据来对待。做到这三点CL2不是难题CL3也只是一个时间问题。