第四章：审核准备——审核检查表的编制、审核前文档评审、审核启动会议的准备
说实话，很多工程师觉得审核准备就是“翻翻文档，列几个问题”。但我要告诉你，审核准备的质量，直接决定了你现场审核的深度和效率。我见过太多审核员，到了现场才发现文档没看透，检查表全是通用问题，启动会议开得跟念稿子一样——结果就是被审核方牵着鼻子走。
这一章，我就把审核准备的三板斧掰开揉碎了讲。你想想看，如果你连检查表都没编好，你怎么可能问出有深度的问题？
4.1 审核检查表的编制——你的“作战地图”
检查表不是问题清单。它是你的思维框架。我个人习惯，每次编检查表前，先问自己三个问题：
- 这次审核的重点是什么？是流程合规性，还是产品交付质量？
- 被审核方最可能出问题的地方在哪？
- 我需要在哪些环节深挖？
有了这个思路，再开始动手。我建议你把检查表分成三个层次：
4.1.1 第一层：通用合规性检查
这一层是“保底”的。说白了，就是看对方有没有按照ASPICE的要求做。比如：
| PA（过程属性） | 检查项示例 | 证据来源 |
|---|---|---|
| PA1.1 过程实施 | 是否定义了过程目标？过程活动是否被执行？ | 过程描述文档、项目计划、工作产品 |
| PA1.2 工作产品管理 | 工作产品是否被标识、版本控制、评审？ | 配置管理记录、评审记录 |
| PA2.1 资源与基础设施 | 是否有足够的工具、人员、培训？ | 资源计划、培训记录 |
| PA2.2 监控与控制 | 是否有度量指标？是否定期跟踪？ | 项目监控报告、度量数据 |
这一层的问题，我通常会在检查表里占30%左右。为什么？因为如果连这些基础都做不到，后面的深度审核就没意义了。
4.1.2 第二层：过程域特定检查
这一层才是体现你专业水平的地方。比如审核SWE.1（软件需求分析），我会这样编：
- 需求来源：系统需求是否被正确分解？有没有遗漏？
- 需求属性：每个需求是否有唯一标识、优先级、状态？
- 需求验证：需求是否可测试？有没有定义验收标准？
- 需求变更：变更流程是否覆盖了需求变更的影响分析？
我记得有一次审核一个ADAS项目，检查表里我特意加了一条：“需求是否考虑了功能安全等级（ASIL）的分配？”结果现场一问，对方果然把ASIL B的需求和ASIL D的需求混在一起管理了。嗯，这就是检查表的价值。
4.1.3 第三层：风险导向的深度问题
这一层是“杀手锏”。我会根据文档评审的结果，针对性地设计一些追问。比如：
示例：如果文档评审发现测试覆盖率只有70%，我会在检查表里写：
- 未覆盖的30%需求是什么？为什么没有被测试？
- 是否有风险分析？是否被管理层知晓？
- 是否有补救计划？时间节点是什么？
你想想看，这种问题一问出去，对方就知道你不是来走过场的。
4.2 审核前文档评审——别等到现场才“翻书”
文档评审，说白了就是提前“踩点”。我见过一些审核员，到了现场才开始翻对方的流程文档，结果问的问题全是文档里已经写清楚的——尴尬不尴尬？
我的做法是这样的：
- 先看过程描述文档：了解对方是怎么定义流程的。重点关注输入、输出、角色、活动。
- 再看项目计划：看实际执行是否和流程定义一致。有没有裁剪？裁剪的理由是什么？
- 最后看工作产品样本：挑几个关键的工作产品，比如需求规格、设计文档、测试报告。看看质量如何。
我曾经审核一个项目，文档评审时发现他们的测试报告里，所有测试用例都是“通过”。我当时就觉得不对劲——怎么可能一个失败的都没有？结果现场一查，原来他们只报告了通过的用例，失败的用例被“隐藏”了。这就是文档评审的价值。
注意：文档评审不是通读全文。你要带着问题去看。比如：
- 文档版本是否一致？有没有多个版本同时存在？
- 文档之间的引用是否可追溯？比如需求到测试的追溯矩阵。
- 文档的评审记录是否完整？评审意见有没有被关闭？
4.3 审核启动会议的准备——第一印象决定一切
启动会议，是审核员和被审核方的第一次正式交锋。你想想看，如果启动会议开得稀里糊涂，后面几天你怎么让人家配合你？
我个人习惯，启动会议准备三个核心内容：
4.3.1 会议议程
议程要简洁，但必须包含：
- 审核目的和范围：一句话说清楚。比如“本次审核覆盖SWE.1到SWE.6，重点是需求管理和测试过程”。
- 审核日程安排：每天审核哪些过程域？哪些人需要参加？
- 审核方法：是访谈、文档审查还是现场观察？
- 审核输出：什么时候出初步发现？什么时候出最终报告？
4.3.2 开场白
开场白不要念稿子。我通常这样说：
“大家好，我是今天的审核员。这次审核不是为了找茬，而是为了帮助团队发现改进机会。我会基于ASPICE的要求，结合项目实际情况进行审核。希望大家坦诚沟通，有什么问题我们现场解决。”
嗯，这段话虽然简单，但能有效降低对方的防御心理。我曾经见过一个审核员，一上来就说“你们这个项目问题很多”，结果整个审核过程都在对抗中度过。
4.3.3 审核规则
启动会议上必须明确规则：
- 保密性：审核发现只用于改进，不会外泄。
- 沟通渠道：如果有疑问，随时找审核员沟通。
- 证据要求：所有发现必须有客观证据支持。
小技巧：启动会议结束后，我会留5分钟让被审核方提问。有一次，对方项目经理问“如果发现不符合项，会不会影响项目交付？”我回答：“不符合项是改进机会，不是惩罚。只要你们有整改计划，审核结果不会影响项目进度。”这句话一出，整个会议室的气氛都轻松了。
4.4 避坑指南——我曾经踩过的坑
做了这么多年审核，我总结了几条血泪教训：
- 检查表不要“死”：现场发现新问题，随时调整检查表。别死守着原来的问题不放。
- 文档评审不要“浅”：只看目录不看内容，等于没看。一定要深入到具体的工作产品。
- 启动会议不要“长”：超过30分钟，大家就开始走神了。控制在20分钟以内，高效沟通。
我曾经有一次，检查表编得太细，结果现场发现对方流程和检查表完全不匹配。我只好临时调整，把检查表推倒重来。从那以后，我学会了“留白”——检查表里留20%的空白，用于现场补充。
好了，这一章的内容就到这里。下一章我们聊聊现场审核的执行技巧——怎么问问题、怎么追证据、怎么处理冲突。到时候见。