VDA6.3系列|P2项目管理——7个提问逐条拆解， 审核员看的是这些

VDA6.3系列 · 2023版P2项目管理

P2项目管理——7个提问逐条拆解，
审核员看的是这些

VDA6.3:2023第四版 · 基于标准原文逐条讲解 · P2篇

审核员一进会议室，第一句话通常是："先看你们的项目计划。"

很多人以为P2只是"开胃菜"——毕竟只有7个提问，比P5（供应商管理）一整章还少。但你错了。

P2是审核员观察企业管理水平的第一窗口。开会前5分钟就能看出你这个项目的管理是"真干活"还是"写文件"。这7个提问查的不是文档厚度，而是你有没有把项目管理流程真正跑起来。

而且，2023版P2的评分逻辑变了——不是你"做了没有"，而是"你做的这些事，从顾客的角度来看够不够"。

P2为什么被称为"开胃菜"

P2项目管理共7个提问（与2016版数量相同），是整个VDA6.3过程审核中提问数量最少的部分。但这7个提问涵盖了从项目计划、资源配置、组织架构到经验教训的完整管理闭环。

2023版P2核心变化

1. 评分第三角度变更：2016版原为"抽象系统化评估"，2023版改为"从顾客角度"——这意味着评分时你必须回答"顾客会在意这个问题吗"

2. 软件方面新增考虑：2023版在每个提问中都加入了软件开发活动的考量，包括与ASPICE和VDA-MLA的协调

3. 提问数量不变（7项），但"怎么评"完全变了

翻译成大白话：以前你只要证明"按流程做了"就能得分。现在审核员会追问——"如果这事没做好，顾客会受影响吗？影响多大？"

逐条拆解：P2.1 – P2.7 P2.1 是否制定了项目计划？

审核员在看什么

• 项目计划是否包含所有里程碑节点

• 里程碑是否与顾客要求逐项对应

• 是否包含了软件开发活动 2023新增

• 项目计划变更后是否及时更新和沟通

• 计划是否由跨职能团队共同确认（不能只有项目经理自己签字）

需要准备的证据

• 项目计划文件/甘特图（须标注顾客里程碑节点）

• 软件开发子计划（如适用） 2023新增

• 计划变更记录/版本履历

常见不符合

项目计划是模板——打开一看，模板的"SOP"字样还没删。实际进度没人跟踪，变更靠口头通知。软件活动根本没写进项目计划。

及格答案长什么样：一份包含顾客强制里程碑（如OTS、PPAP提交日期）在内的甘特图，节点与顾客APQP计划对应，软件开发活动有专门的子计划（如软件发布节点），变更记录清晰可追溯。项目经理能对应计划讲清楚当前进度和偏差。

P2.2 是否落实了必要的资源？

审核员在看什么

• 人员、设备、工装、检具、IT基础设施等资源是否匹配项目需求

• 资源计划是否与项目计划同步推进、同步更新

• 软件相关的IT资源是否到位 2023新增

需要准备的证据

• 资源规划矩阵（人力/设备/工装/量检具）

• 关键人员任命文件/委任状

• 关键设备/工装采购计划及进度跟踪

• IT资源（服务器、开发环境、测试环境）到位证明

常见不符合

资源规划表格做得非常漂亮，但全是PPT层面的"规划"——设备没采购、人员未到位、测试环境没搭建。项目经理说有资源，一问细节就露馅。

及格答案长什么样：资源计划不是静态文档。审核员查的不是"有没有规划表"，而是"资源是不是真的到位了"。关键设备有采购合同+到货日期，关键岗位有任命书+在职证明，IT环境能当场打开看。

P2.3 项目组织架构和职责是否明确？

审核员在看什么

• 跨职能小组成员是否明确、覆盖完整

• 职责矩阵（如RACI）是否清晰

• 软件开发团队的组织接口是否清晰 2023新增

• 成员是否知道自己在项目中的角色和任务

需要准备的证据

• 项目组织架构图（含跨职能小组名单）

• 职责说明文件/RACI矩阵

• 项目会议纪要（证明成员实际参与） 2023新增

• 软件团队接口人名单及沟通机制

常见不符合

组织图上清清楚楚，"质量代表"大名挂在上面。但审核员一查会议签到——此人从未出席过项目会议。更有软件团队的人没在组织架构里出现，审核员问"软件谁管"，项目经理说"哦那是IT部门的事"。

及格答案长什么样：组织架构图不是摆设。跨职能小组每个成员都会参加项目会议（有签到记录证明）。RACI矩阵不是"默认全写R"，而是每个任务有明确的A/责任人。软件相关接口人有明确的汇报线和沟通机制。

P2.4 是否对顾客特定要求进行了评审？

审核员在看什么

• 合同/技术协议的评审是否完整

• CSR（顾客特定要求）清单是否建立

• 技术规范评审是否有记录

• 软件相关要求是否纳入评审 2023新增

• CSR是否传递到所有相关部门

需要准备的证据

• 合同/PPAP合同

• CSR清单（含软件要求）

• 合同评审记录 / 技术规范评审记录

• CSR传递记录（覆盖所有相关部门）

常见不符合

CSR清单确实做了，但只是Excel上一行标题。审核员问"这些要求你通知到工艺部门了吗？通知了多久？他们有没有反馈？"——沉默。尤其软件相关的CSR最容易被遗漏（比如顾客要求ASPICE CL2，项目团队完全不知道）。

及格答案长什么样：CSR有清单，每一项有责任人、完成状态、证据链接。审核员能随机抽查一项，看到它从识别→评审→传递→落实的完整链路。软件CSR（如ASPICE等级、信息安全要求）单独列出。

P2.5 是否进行了可行性分析？

审核员在看什么

• 技术可行性、商务可行性、制造可行性是否全面评估

• 是否包含风险评估（不是"无风险"三个字）

• 软件开发可行性是否纳入 2023新增

• 可行性结论是否由跨职能团队签署

需要准备的证据

• 可行性承诺书（AIAG格式或等效文件）

• 风险评估记录（含风险等级、应对措施）

• 开发可行性评估记录 2023新增

• 跨职能小组签署页

常见不符合

可行性分析表上，每个格子都是绿色✓。风险栏写着"无重大风险"。审核员问"这个项目的核心技术你们是第一次做吧？为什么没有风险？"——这就是形式化。

及格答案长什么样：可行性分析不是为了签"可行"，而是真正找出风险。高风险项有明确的应对措施和责任人。审核员能看到"这个技术有难度，我们计划了A/B方案"而不是"全量可行"。软件开发可行性（如技术栈、架构、测试覆盖率）有独立评估。

P2.6 是否有项目状态报告机制？

审核员在看什么

• 是否定期进行项目评审

• 是否有红绿灯状态指标（且红灯会被真对待）

• 问题升级机制是否有效运行

• 是否包含软件成熟度评估（与VDA-MLA协调） 2023新增

需要准备的证据

• 项目状态报告（含红绿灯）

• 项目评审会议纪要（含决议和行动项跟踪）

• 问题升级记录

• MLA成熟度评估记录（如适用） 2023新增

常见不符合

状态报告存在，但连续6个月全是绿灯。审核员问"你们项目真的毫无问题？"更典型的是：月报上有红灯项，但管理层没有升级机制，红灯亮了三个月没人理。

及格答案长什么样：状态报告有红有绿——绿灯说明进展顺利，黄灯说明有风险但可控，红灯必须有升级记录和解决计划。审核员会随机抽查一项红灯：看它什么时候亮的、什么时候升级的、什么时候关闭的。软件成熟度有对应评估（如MLA等级评估）。

P2.7 是否有经验教训/Lessons Learned机制？

审核员在看什么

• 类似项目的历史经验是否被引用到当前项目

• 项目结束时是否对经验教训进行归档

• 知识是否在跨项目间传递（而非每个项目重新发明轮子）

需要准备的证据

• Lessons Learned文档（含引用记录）

• 类似项目经验引用/规避清单

• 项目收尾阶段的经验总结记录

• 跨项目知识库/共享平台（如有）

补丁说明

2016版第10章"最佳实践/经验教训"在2023版中已删除，但P2.7提问本身保留。这意味着Lessons Learned的审核权重在P2项目管理部分依然是明确的评分项，不要因为"标准删了第10章"就忽略它。

常见不符合

每个项目都是从零开始。上一个项目出现过的同样质量问题，这个项目没有记录、没有引用。项目做完了，经验跟着项目经理一起走了。审核员问"上个项目的问题这个项目怎么避免的？"——没有答案。

及格答案长什么样：Lessons Learned不是"项目做完写一个Word归档"的仪式。审核员会查"当前项目的风险清单里有没有引用历史项目的教训"，以及"这些引用是真实的还是抄来的"。好的企业会有跨项目知识沉淀机制——即使只是个Excel表不断更新。

7个提问 × 关键证据文件对照

提问

核心审核主题

关键证据文件

P2.1

项目计划

甘特图（含顾客里程碑、软件里程碑）；项目计划变更记录

P2.2

资源落实

资源规划矩阵；人员任命文件；关键设备采购计划

P2.3

组织与职责

组织架构图；RACI矩阵；软件接口人任命；会议签到

P2.4

CSR评审

合同/PPAP合同；CSR清单（含软件CSR）；评审记录

P2.5

可行性分析

可行性承诺书（AIAG）；风险评估记录；开发可行性评估

P2.6

状态报告

项目状态报告（红绿灯）；升级记录；MLA成熟度评估

P2.7

经验教训

Lessons Learned文档；跨项目引用记录；经验库

每个提问至少准备以上关键证据文件

P2最容易丢分的三个地方

1. 所有文档都有，但全是"壳"

✗ 项目计划有，但进度没跟踪

✗ 可行性分析签了，但没识别出一个风险

✗ 状态报告有，但连续多月绿灯

✗ 审核员一眼看穿：这是"写文件"不是"管项目"

2. CSR识别不全，尤其是软件要求

✗ 只关注了尺寸、材料、性能类CSR

✗ 软件相关CSR（ASPICE等级、信息安全、OTA要求）完全遗漏

✗ CSR有清单但没传递到工艺、研发、IT部门

✗ 这是2023版新增关注重点，也是最容易踩的新坑

3. P2.7被当成"Optional"题

✗ 经验教训被认为"可做可不做"

✗ 没有跨项目知识沉淀机制

✗ 项目做完没有收尾总结

✗ 审核员问"上个项目同样的问题怎么解决的"，你只能沉默

实操建议：项目启动时的P2自检清单

✓ 项目计划：有没有顾客的里程碑清单？电子版计划是否包含软件发布节点？

✓ 质量代表：他/她在项目群里说话了吗？会议签到有他/她的名字吗？

✓ 可行性分析：有没有一条"高风险"标记？如果有真实风险但文档没写，回去改

✓ CSR：顾客的供应商手册/技术协议/质量协议是否完整评审？软件要求是否单独列出了？

✓ 红绿灯：最近一期的状态报告有几盏红灯？没有红灯是正常的吗？

✓ Lessons Learned：上一个类似项目的LL你引用了吗？还是这个项目从零开始？

✓ 软件团队：软件开发活动是否纳入了项目计划、组织架构、可行性分析和CSR评审？

加分项提示

如果你能在P2审核时主动展示以下几点，审核员会对你印象非常深刻：

1 软件成熟度评估（VDA-MLA等级）已纳入项目状态报告

2 软件开发计划有独立子计划，与ASPICE流程对齐

3 CSR清单包含软件和信息安全要求

4 Lessons Learned不是文件归档，而是"当前项目的输入"

5 项目计划中的每个里程碑对应批准交付物清单