汽车零部件软件质量评审流程

硬件笔记本

rltgmtlxzgl64025460739.gif

点击上方蓝色字体，关注我们
2 n9 S2 `9 Q" E! `5 l' W我们的一生会经历许多重要的节点：18岁成年、参加高考、步入大学、开始工作、结婚成家、生儿育女、退休养老……每一个节点都标志着人生进入新的阶段，也象征着个人的逐步成熟。

& s9 V) X' c$ A类似于人生的节点，软件在生命周期的六大环节或ABCD样件中，同样包含许多大小不一的关键节点。

即便某些个体经历特殊，例如某人被保送大学未参加高考，或某人选择独身主义“裁剪”了部分人生阶段，但依然会经历某些不可避免的重要节点。
; X2 B# F  U+ a* [
5 L) c3 Z. D) g8 ?0 B2 ?! R在项目管理中，我们将这些关键节点称为“里程碑”，而那些需要正式评审的节点则被称为“质量门”（也称“质量阀”“阶段门”或“卡点”等）。

; [+ v3 r- P, d质量门通常设置在交付节点之前，通过正式的评审会议进行质量控制。

此外，还有一些非正式但具有一定强制性的关卡，例如领导签字、代码评审或客户演示等。
0 U* G8 S8 y8 |; d
从概念上讲，“里程碑”涵盖更广泛的意义，它既可以是一个方向性的指引，也可能直接影响项目的进展。
$ |: V8 `3 \* C
8 U; I. f- y4 [3 Q  P' V& v5 |& ~然而，只有那些需要审核的里程碑才会对项目产生明确影响；而无需审核的里程碑更像公路上的路标或未设置检查的卡口，车辆可以直接通过，不会被阻拦。

: I' \( x( C' P6 g因此，我们重点讨论的是需要审核、正式且全面的里程碑——即“质量门”。
1 R, }- o/ q0 g9 e& K7 F) N/ H
6 u" n; X+ C! p# d; }- l% s里程碑与质量门的关系如下图所示。

. [; K+ J7 L* v- _

hndtvxwvlge64025460840.png

众所周知，汽车项目对时间的敏感性极高。

1 I8 E$ S. N3 K这种敏感性不仅体现在快速推向市场的需求上，还体现在冗长而复杂的供应链中各节点的协调与配合上。
8 A# w' \) |7 q
4 L7 x6 Y0 }! o$ P可以说，按时交付是多数项目经理的核心关注点，而这一目标在层层传递中，往往成为项目团队面临的主要压力来源。

+ {5 u) x* ^* W' `" H  I那么，具体要遵循什么时间节点呢？

5 |; {5 z8 x, }核心是软件或样件的交付时间。
8 W  s7 ^+ v: O6 a
更规范地说，是按照需要通过审核的里程碑时间来执行。

在这些关键时间点之后，项目要么直接提交软件交付物，要么将样件的交付工作转交给生产和物流团队，继续推进后续流程。
( D1 b! w$ M# x1
如何开展质量门评审
评审是一个广义而通用的概念，涵盖多种形式，例如同行评审、内外部审计、IATF 16949 审计、功能安全认证、ASPICE 评级、领导检查、签字审批、会议汇报、团队回顾，以及本节讨论的质量门评审等，均属于评审的范畴。
+ B/ r2 ]& i9 q' D$ k1 Z! u3 {  t  v
从模式上看，评审通常可以归纳为以下三种现实形式：依赖经验、走过场和依托检查清单（checklist），如下图所示：

f0qs1ik0gma64025460940.png

+ j- h: w" p) L6 R: {- ?

依赖经验：效果高度依赖于评审者的个人能力和责任心，因人而异，难以标准化。

走过场：在许多情况下，评审可能流于形式，主要由于团队对评审的重视程度不够。要改善这一现状，需要通过优化流程设计，逐步形成重视评审的良好文化。

依托检查清单：这是相对平衡且高效的评审方式，也是主要的评审工具。通过系统化的检查清单，不仅能够规范评审流程，还可以积累和传承知识与经验，是推动评审工作落地的实际路径。

6 x: L( C$ n2 ]5 f总之，无论是作为评审者还是被评审者，无论是管理者还是执行者，理解评审背后的意义，有助于我们在汽车行业这一层级分明、阶段清晰、评审频繁的环境中更有效地推动工作。

+ n* ]1 U+ A4 o% C( h接下来，我们将从不同角度进一步探讨评审的实践与方法。
+ U5 f+ j& N  u0 @% q2
检查清单的设置
作为一种实用的工具，检查清单的定义会根据评审对象的不同而体现出不同的专业性。

不过，本节将重点讨论普适性较强的设置方法，而不涉及过于专业的内容。
1 |/ Q  ?8 i0 k
面对日新月异且复杂的技术，细节常常难以一一掌握，我们更多的是需要根据产品或项目的特点，将方法论内化为实践。

5 u' v+ b  }7 s5 m以下列举了与软件评审相关的15类实用检查项，供参考：

交付物是否有专属ID？ ID及版本设置是否正确？是否使用了正确版本的软件？

文档是否已存档并放置于正确位置？ 模板是否正确或最新？文件结构是否合理？

必填项目是否已填写？ Excel筛选中是否有未设置的内容？变更原因是否已记录？文档历史是否有日期、修改记录和作者标注？

被评审项是否已验证、基线化并获得授权人评审和认可？ 是否已正式发布？

计划内容是否完成？ 上一阶段或版本的开口项是否已在当前阶段或版本中关闭？

易错项设置是否正确？ 被删除的部分是否确实不再需要？

是否建立追溯链接，如需求和测试用例？ 所有测试用例是否至少有一个与相应需求的外部链接？前后更新是否一致？在系统和Excel、FMEA与功能安全档案之间的相关更新是否同步？需求是否与系统概念和设计规则一致？

描述是否详细、合理且易于理解？ 是否使用一致的专业术语？

前提条件是否明确？ 是否已经满足？

粒度是否合适？ 是否有定性描述，如“小的”、“大的”？组件划分是否合理（模块化、高内聚、低耦合）？

硬件是否对软件产生影响？ 这些依赖项是否已识别清楚？每个组件的输入输出是否完整？系统与软件的匹配关系是否已检查？

执行需求时是否存在风险？

每个测试步骤是否有序列号？ 是否标明测试顺序，并记录预期与实际结果？

是否对比更改前后的输出？ 判断更改是否合理？

这些条目主要针对基本的完整性和逻辑性进行检查。

0 c& f3 ^$ L" S! v, N$ G% f然而，对于优秀的评审者或管理者来说，这些检查项虽然必要，却还远远不够。

: ]" r; M+ z" X, {3 `: j它们可能零散且缺乏逻辑性。深入理解业务运作并掌握产品细节，仍然是高效评审的关键。
7 [5 |+ X& }4 s0 n# p- l; ^
) q( C: j& f, D如果评审者无法准确把握评审对象的细节和现实适用性，评审工作就可能停留在表面，缺乏实际效果。
3
层次、对象与思维
为了更系统地提炼评审方法论，如下图所示。
; e3 T: _8 X" E! c5 ~2 l0 B/ A
2 [1 N- q1 {7 C' h% ^

y31yptq14nj64025461040.png

我们还需关注当前评审实践中的一些不足之处：

; i2 _: ]9 _2 ](1) 评审的层次
- Q5 f) |* Y0 v8 i! s( R4 F$ R

有没有

对不对

好不好

在实际操作中，评审往往只能做到“有没有做”或者仅仅根据纸面标准判断“对不对”，很难深入到实际业务中，全面评估“好不好”。

这种局限性往往影响了评审效果的深度与准确性。
: n. e  \5 G& z, t: M4 S4 L
(2) 评审的对象

产品

过程

  K& r, l9 a  \现实中，评审通常只能判断过程是否遵循标准，以及产品表现的度量指标是否有问题。

较为先进的评审者能够分析数据的未来趋势，但很难对产品、软件、测试设计的优劣与合理性做出准确判断。

(3) 评审的基础思维
. V2 I6 ^- \6 r4 l3 |

凡事预则立（计划思维）

事事有着落（闭环思维）

完整不遗漏（系统思维）

自己说了不算（评审与批准思维）

拿着要求说问题（标准思维）

决定不能拍脑袋（分析思维）

历史要清白（基线思维）

理解并清晰表达这些思维逻辑，是评审者能够立足和成功的关键所在。
7 T+ N6 F; G, J4 o' V
7 Q+ r( W. O5 ~! ]! n掌握这些理论，将有助于在实践中进行更加深入和有效的评审。
6 r4 a3 t; n5 j4 k8 r/ P( Y# v
7 w* L; \% U. E  y+ [虽然在实际工作中，我们可能很难时刻保持完美，但偶尔回顾这些原则，能够在关键时刻为实践提供重要的指导。

, Z1 \6 G7 `0 r接下来，我们将深入探讨一些实践经验。
7 [5 E. F5 G- |# q4
9 O; r" V9 A# r5 O评审实用“找坑”指南
在项目中，团队成员常常面临“挖坑”和“填坑”的问题。

作为评审员，我们的职责就是发现那些尚未填好的坑，或者被有意忽视的坑。
- Y( t% e" O) n" K* S
- r% i* L" O* K+ D2 _3 Z8 @" b找坑不仅能展现评审员的能力，也直接关系到质量门的效果。
$ T7 w8 `1 `2 _4 E, c6 n! ?
以下列举了一些在评审过程中常见的“坑”问题如下图所示：

of2h2ombwmb64025461140.png

没有规划或规划不充分：对于项目缺乏整体规划，或团队成员不清楚项目规划，通常会暴露出如下问题：
[/ol]

立项背景不清晰：项目是基于旧产品优化，还是应对新法规，或是解决上一代产品的局限？

项目运行模式不明确：是全栈自研，模块分包，还是多供应商共同交付？

项目定义不明确：是否清晰项目架构？变更范围是否明晰？是否要求完成ASPICE L2认证？

这些问题通常表明项目启动会议或沟通会缺乏规划，项目章程或启动文档也可能未编制或发布。

相比总体规划，计划更为细化，若计划存在以下问题，可能导致项目进展受阻：
5 a+ Q) T3 |! O

时间计划未及时更新，或其他具体活动未完成。

里程碑不完整，目标无法达成。

工作包之间依赖关系不清晰，或未在部门间落实到可执行层级。

任务未分配给负责人，且计划未得到监控。

关键路径无法识别，资源设备不充足。
1 n; Z8 {8 ~$ s1 ^
' g, Z* J$ A6 J) b: w, u1 V2 F这些问题表明计划未得到充分细化和执行，且缺乏有效的跟踪机制。
- h' C( [9 W. D5 W+ M: F
开口项跟踪是项目管理的核心，若存在以下问题，往往会影响项目推进：
* M" S+ _7 N, e* I& x% U8 ^* [3 H

没有责任人或截止日期，描述不清晰。

长期无人处理的开口项，或者开口项超期无应对措施。

开口项未进行交付影响分析。

随着软件迭代速度加快，bug管理越来越复杂。以下问题常见于Bug管理中：

不按照流程推进，缺乏对应的角色分配。

Bug描述不清晰，等级划分不合理。

测试失败项未与Bug关联，修复版本混乱。

Bug修复未按计划完成，且存在严重Bug被交付。
1 b1 w9 T1 h; n, L( d1 s
9 H; k4 f' a/ r. {变更管理常常是项目中最具挑战的环节，以下问题可能导致变更管理混乱：

未进行变更影响分析，未经变更控制委员会（CCB）批准的变更。

变更范围不清晰，缺乏与需求、测试、开发的追溯关系。

基于未冻结内容进行变更，变更未与功能计划对齐。
8 I) g( l* t& u% q! Y/ x& r
4 U  F* M3 K( Z1 t# M2 z$ u配置项不完整，未经过评审或批准，未打基线等问题依然较为常见，虽然这一部分问题较弱化，但仍需关注。
需求管理中的问题包括：

法规需求未考虑，需求未存档或未控制版本。

需求缺乏拆分或标记，未明确需求的状态。

功能需求未按计划实现，缺少性能或接口需求。
* |- L% w5 w2 i9 T
设计实现的缺陷通常是开发人员专属领域的内容，评审员在这方面较难直接评价，但仍可能发现以下问题：

缺少架构框图、功能分配、状态机图等重要设计文档。

代码复用分析未完成，资源消耗超标。
$ H2 ^0 Q$ `0 n+ X' T/ b8 q7 U
/ Q. a* |2 b) Z测试验证中的问题通常包括：
  j. e+ I6 J# ^7 x8 I6 j

错误的报告，覆盖率、执行率偏低。

静态验证违反项未修复，测试失败项未触发Bug或无风险分析。
4 `2 v& _' `, v  Z2 b+ G# m0 v  O) B
! T' @# U" X8 M( o% v质量门的开展实际上是评审者与被评审者之间的“较量”。

+ y; a/ Q% ^8 c根据不同的流程成熟度、人员经验及能力，评审员能够识别出项目中的不同问题。

6 v* [; e  N6 L1 f- j5 s2 Z一个有经验且负责任的评审员，结合项目释放权限和质量门的有效实施，能够确保软件交付质量。

& Z5 x. {& g- T& R# T0 S然而，事情往往不会尽如人意，评审员仍需具备高度的敏锐性和全面的能力，才能有效识别和填补项目中的“坑”。
5
略显尴尬的评审
/ d% k4 }! A. l" w: V, h在汽车软件行业，质量门评审常常流于形式，未能真正发挥应有的作用。
( A. o. [) l+ D/ P
个人而言，我较为排斥将工作变成纸面工作，空谈理论。

5 q. A8 d* P/ [然而，当前汽车软件行业的评审往往是典型的“纸面工作”，这一现象反映出汽车行业对软件开发过程和规则的忽视。

其原因可能有两个方面：

汽车行业对软件开发重视不够，在精于机械制造的汽车行业，软件开发过程往往不被重视（下一节将进一步讨论）。

缺乏深入业务的评审员，国内汽车行业中，能够真正深入了解软件业务的评审员仍然较少。
[/ol]
那么，面对这一理论上有价值但在实践中难以落实的工作，我们该如何看待呢？

7 J+ {; }! W- U5 q1. 法治还是人治
评审的价值首先取决于所处的环境是法治还是人治。

% p' m) ^8 k. A% m显而易见，法治环境更重视流程或标准评审，不容易在决策时被忽视。
: V2 l1 T% J' W9 ^1 m. w: e
这个道理本身并不复杂，但需要强调的是，法治与人治之间并没有明确的界限。

# M$ f2 z* \8 D1 G& f  ~总体而言，以下环境更接近于法治：
# T0 i5 e% p+ X, s& w1 Z4 s

外企相较于民企

工厂相较于研发部门

劳动密集型行业相较于智力密集型行业

成熟产业相较于新兴产业

财务相较于销售

底盘开发相较于座舱开发

代码编写相较于项目管理

外审相较于内审

IATF 16949相较于ASPICE
( b0 b, [* B$ m0 d
然而，我们所处的企业是一个复合系统，各个部门之间的文化观念、工程需求、外部环境等因素都可能影响到法治和人治的划分。
4 }3 p) C- U' l6 a/ u
例如，外企中也可能有注重人际关系的本土销售，民企中可能有精细的财务流程；工厂内有各类背景的工人，研发中也有严格的测试标准。
9 s' e  ]6 D' p4 ]$ N) W
这表明组织环境是否偏向法治或人治，有多方面的影响因素：
6 V7 z# J6 g+ I

文化观念的差异

内在工程逻辑的需求

外部政治或业务权衡的诉求

行业技术成熟度
因此，在复杂的环境中，如何推动法治流程，需要我们深思熟虑。

! V" C* J2 ~4 T2 c0 r2 ^2. 流程悖论
如果希望评审能够真正发挥价值，就必须让各环节重视流程，制定更合适的流程并严格执行。

只有这样，流程才能逐步完善，评审的价值才能逐渐提升。

然而，在当前国内市场和企业的阶段，这一目标仍然难以实现，形成了一个明显的悖论：

在理想的情况下，评审可以通过完善流程推动业务的优化；

然而，在实践中，流程常常未被深入执行，导致评审失去应有的深度和效果。

这一悖论提示我们，汽车行业向软件化转型过程中，如何平衡流程的规范化与实际操作的灵活性，是一个亟待解决的问题。

最近阅读了一本关于智能汽车的专业书籍《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》。

  q8 r- S  U: i. j# e2 U, y作者在全球百强汽车企业的一级供应商和整车厂（OEM）中拥有10余年技术与管理实战经验，书中从技术和管理视角全面剖析智能汽车电子与软件领域。

内容涵盖行业背景、组织架构、项目管理、开发方法、系统集成、流程体系、团队构建、核心标准、工具链、行业痛点及未来展望，推荐给从事智能汽车开发和管理的专业人士学习和参考。
, ^! `  v% b1 Z3 G0 e本篇文章来源于这本书中的一些重要知识，希望对大家有所帮助。

0a3aldkhrvp64025461240.jpg

4b2epysd3ls64025461340.gif

点击阅读原文，更精彩~