我们的一生会经历许多重要的节点：18岁成年、参加高考、步入大学、开始工作、结婚成家、生儿育女、退休养老……每一个节点都标志着人生进入新的阶段，也象征着个人的逐步成熟。
类似于人生的节点，软件在生命周期的六大环节或ABCD样件中，同样包含许多大小不一的关键节点。
即便某些个体经历特殊，例如某人被保送大学未参加高考，或某人选择独身主义“裁剪”了部分人生阶段，但依然会经历某些不可避免的重要节点。
在项目管理中，我们将这些关键节点称为“里程碑”，而那些需要正式评审的节点则被称为“质量门”（也称“质量阀”“阶段门”或“卡点”等）。
质量门通常设置在交付节点之前，通过正式的评审会议进行质量控制。
此外，还有一些非正式但具有一定强制性的关卡，例如领导签字、代码评审或客户演示等。
从概念上讲，“里程碑”涵盖更广泛的意义，它既可以是一个方向性的指引，也可能直接影响项目的进展。
然而，只有那些需要审核的里程碑才会对项目产生明确影响；而无需审核的里程碑更像公路上的路标或未设置检查的卡口，车辆可以直接通过，不会被阻拦。
因此，我们重点讨论的是需要审核、正式且全面的里程碑——即“质量门”。
里程碑与质量门的关系如下图所示。
众所周知，汽车项目对时间的敏感性极高。
这种敏感性不仅体现在快速推向市场的需求上，还体现在冗长而复杂的供应链中各节点的协调与配合上。
可以说，按时交付是多数项目经理的核心关注点，而这一目标在层层传递中，往往成为项目团队面临的主要压力来源。
那么，具体要遵循什么时间节点呢？
核心是软件或样件的交付时间。
更规范地说，是按照需要通过审核的里程碑时间来执行。
在这些关键时间点之后，项目要么直接提交软件交付物，要么将样件的交付工作转交给生产和物流团队，继续推进后续流程。
1
如何开展质量门评审
评审是一个广义而通用的概念，涵盖多种形式，例如同行评审、内外部审计、IATF 16949 审计、功能安全认证、ASPICE 评级、领导检查、签字审批、会议汇报、团队回顾，以及本节讨论的质量门评审等，均属于评审的范畴。
从模式上看，评审通常可以归纳为以下三种现实形式：依赖经验、走过场和依托检查清单（checklist），如下图所示：
依赖经验：效果高度依赖于评审者的个人能力和责任心，因人而异，难以标准化。
走过场：在许多情况下，评审可能流于形式，主要由于团队对评审的重视程度不够。要改善这一现状，需要通过优化流程设计，逐步形成重视评审的良好文化。
依托检查清单：这是相对平衡且高效的评审方式，也是主要的评审工具。通过系统化的检查清单，不仅能够规范评审流程，还可以积累和传承知识与经验，是推动评审工作落地的实际路径。
总之，无论是作为评审者还是被评审者，无论是管理者还是执行者，理解评审背后的意义，有助于我们在汽车行业这一层级分明、阶段清晰、评审频繁的环境中更有效地推动工作。
接下来，我们将从不同角度进一步探讨评审的实践与方法。
2
检查清单的设置
作为一种实用的工具，检查清单的定义会根据评审对象的不同而体现出不同的专业性。
不过，本节将重点讨论普适性较强的设置方法，而不涉及过于专业的内容。
面对日新月异且复杂的技术，细节常常难以一一掌握，我们更多的是需要根据产品或项目的特点，将方法论内化为实践。
以下列举了与软件评审相关的15类实用检查项，供参考：
交付物是否有专属ID？ ID及版本设置是否正确？是否使用了正确版本的软件？
文档是否已存档并放置于正确位置？ 模板是否正确或最新？文件结构是否合理？
必填项目是否已填写？ Excel筛选中是否有未设置的内容？变更原因是否已记录？文档历史是否有日期、修改记录和作者标注？
被评审项是否已验证、基线化并获得授权人评审和认可？ 是否已正式发布？
计划内容是否完成？ 上一阶段或版本的开口项是否已在当前阶段或版本中关闭？
易错项设置是否正确？ 被删除的部分是否确实不再需要？
是否建立追溯链接，如需求和测试用例？ 所有测试用例是否至少有一个与相应需求的外部链接？前后更新是否一致？在系统和Excel、FMEA与功能安全档案之间的相关更新是否同步？需求是否与系统概念和设计规则一致？
描述是否详细、合理且易于理解？ 是否使用一致的专业术语？
前提条件是否明确？ 是否已经满足？
粒度是否合适？ 是否有定性描述，如“小的”、“大的”？组件划分是否合理（模块化、高内聚、低耦合）？
硬件是否对软件产生影响？ 这些依赖项是否已识别清楚？每个组件的输入输出是否完整？系统与软件的匹配关系是否已检查？
执行需求时是否存在风险？
每个测试步骤是否有序列号？ 是否标明测试顺序，并记录预期与实际结果？
是否对比更改前后的输出？ 判断更改是否合理？
这些条目主要针对基本的完整性和逻辑性进行检查。
然而，对于优秀的评审者或管理者来说，这些检查项虽然必要，却还远远不够。
它们可能零散且缺乏逻辑性。深入理解业务运作并掌握产品细节，仍然是高效评审的关键。
如果评审者无法准确把握评审对象的细节和现实适用性，评审工作就可能停留在表面，缺乏实际效果。
3
层次、对象与思维
为了更系统地提炼评审方法论，如下图所示。
我们还需关注当前评审实践中的一些不足之处：
(1) 评审的层次
有没有
对不对
好不好
在实际操作中，评审往往只能做到“有没有做”或者仅仅根据纸面标准判断“对不对”，很难深入到实际业务中，全面评估“好不好”。
这种局限性往往影响了评审效果的深度与准确性。
(2) 评审的对象
产品
过程
现实中，评审通常只能判断过程是否遵循标准，以及产品表现的度量指标是否有问题。
较为先进的评审者能够分析数据的未来趋势，但很难对产品、软件、测试设计的优劣与合理性做出准确判断。
(3) 评审的基础思维
凡事预则立（计划思维）
事事有着落（闭环思维）
完整不遗漏（系统思维）
自己说了不算（评审与批准思维）
拿着要求说问题（标准思维）
决定不能拍脑袋（分析思维）
历史要清白（基线思维）
理解并清晰表达这些思维逻辑，是评审者能够立足和成功的关键所在。
掌握这些理论，将有助于在实践中进行更加深入和有效的评审。
虽然在实际工作中，我们可能很难时刻保持完美，但偶尔回顾这些原则，能够在关键时刻为实践提供重要的指导。
接下来，我们将深入探讨一些实践经验。
4
评审实用“找坑”指南
在项目中，团队成员常常面临“挖坑”和“填坑”的问题。
作为评审员，我们的职责就是发现那些尚未填好的坑，或者被有意忽视的坑。
找坑不仅能展现评审员的能力，也直接关系到质量门的效果。
以下列举了一些在评审过程中常见的“坑”问题如下图所示：
没有规划或规划不充分：对于项目缺乏整体规划，或团队成员不清楚项目规划，通常会暴露出如下问题：
立项背景不清晰：项目是基于旧产品优化，还是应对新法规，或是解决上一代产品的局限？
项目运行模式不明确：是全栈自研，模块分包，还是多供应商共同交付？
项目定义不明确：是否清晰项目架构？变更范围是否明晰？是否要求完成ASPICE L2认证？
这些问题通常表明项目启动会议或沟通会缺乏规划，项目章程或启动文档也可能未编制或发布。
相比总体规划，计划更为细化，若计划存在以下问题，可能导致项目进展受阻：
时间计划未及时更新，或其他具体活动未完成。
里程碑不完整，目标无法达成。
工作包之间依赖关系不清晰，或未在部门间落实到可执行层级。
任务未分配给负责人，且计划未得到监控。
关键路径无法识别，资源设备不充足。
这些问题表明计划未得到充分细化和执行，且缺乏有效的跟踪机制。
开口项跟踪是项目管理的核心，若存在以下问题，往往会影响项目推进：
没有责任人或截止日期，描述不清晰。
长期无人处理的开口项，或者开口项超期无应对措施。
开口项未进行交付影响分析。
随着软件迭代速度加快，bug管理越来越复杂。以下问题常见于Bug管理中：
不按照流程推进，缺乏对应的角色分配。
Bug描述不清晰，等级划分不合理。
测试失败项未与Bug关联，修复版本混乱。
Bug修复未按计划完成，且存在严重Bug被交付。
变更管理常常是项目中最具挑战的环节，以下问题可能导致变更管理混乱：
未进行变更影响分析，未经变更控制委员会（CCB）批准的变更。
变更范围不清晰，缺乏与需求、测试、开发的追溯关系。
基于未冻结内容进行变更，变更未与功能计划对齐。
配置项不完整，未经过评审或批准，未打基线等问题依然较为常见，虽然这一部分问题较弱化，但仍需关注。
需求管理中的问题包括：
法规需求未考虑，需求未存档或未控制版本。
需求缺乏拆分或标记，未明确需求的状态。
功能需求未按计划实现，缺少性能或接口需求。
设计实现的缺陷通常是开发人员专属领域的内容，评审员在这方面较难直接评价，但仍可能发现以下问题：
缺少架构框图、功能分配、状态机图等重要设计文档。
代码复用分析未完成，资源消耗超标。
测试验证中的问题通常包括：
错误的报告，覆盖率、执行率偏低。
静态验证违反项未修复，测试失败项未触发Bug或无风险分析。
质量门的开展实际上是评审者与被评审者之间的“较量”。
根据不同的流程成熟度、人员经验及能力，评审员能够识别出项目中的不同问题。
一个有经验且负责任的评审员，结合项目释放权限和质量门的有效实施，能够确保软件交付质量。
然而，事情往往不会尽如人意，评审员仍需具备高度的敏锐性和全面的能力，才能有效识别和填补项目中的“坑”。
5
略显尴尬的评审
在汽车软件行业，质量门评审常常流于形式，未能真正发挥应有的作用。
个人而言，我较为排斥将工作变成纸面工作，空谈理论。
然而，当前汽车软件行业的评审往往是典型的“纸面工作”，这一现象反映出汽车行业对软件开发过程和规则的忽视。
其原因可能有两个方面：
汽车行业对软件开发重视不够，在精于机械制造的汽车行业，软件开发过程往往不被重视（下一节将进一步讨论）。
缺乏深入业务的评审员，国内汽车行业中，能够真正深入了解软件业务的评审员仍然较少。
那么，面对这一理论上有价值但在实践中难以落实的工作，我们该如何看待呢？
1. 法治还是人治
评审的价值首先取决于所处的环境是法治还是人治。
显而易见，法治环境更重视流程或标准评审，不容易在决策时被忽视。
这个道理本身并不复杂，但需要强调的是，法治与人治之间并没有明确的界限。
总体而言，以下环境更接近于法治：
外企相较于民企
工厂相较于研发部门
劳动密集型行业相较于智力密集型行业
成熟产业相较于新兴产业
财务相较于销售
底盘开发相较于座舱开发
代码编写相较于项目管理
外审相较于内审
IATF 16949相较于ASPICE
然而，我们所处的企业是一个复合系统，各个部门之间的文化观念、工程需求、外部环境等因素都可能影响到法治和人治的划分。
例如，外企中也可能有注重人际关系的本土销售，民企中可能有精细的财务流程；工厂内有各类背景的工人，研发中也有严格的测试标准。
这表明组织环境是否偏向法治或人治，有多方面的影响因素：
文化观念的差异
内在工程逻辑的需求
外部政治或业务权衡的诉求
行业技术成熟度
因此，在复杂的环境中，如何推动法治流程，需要我们深思熟虑。
2. 流程悖论
如果希望评审能够真正发挥价值，就必须让各环节重视流程，制定更合适的流程并严格执行。
只有这样，流程才能逐步完善，评审的价值才能逐渐提升。
然而，在当前国内市场和企业的阶段，这一目标仍然难以实现，形成了一个明显的悖论：
在理想的情况下，评审可以通过完善流程推动业务的优化；
然而，在实践中，流程常常未被深入执行，导致评审失去应有的深度和效果。
这一悖论提示我们，汽车行业向软件化转型过程中，如何平衡流程的规范化与实际操作的灵活性，是一个亟待解决的问题。
最近阅读了一本关于智能汽车的专业书籍《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》。
作者在全球百强汽车企业的一级供应商和整车厂（OEM）中拥有10余年技术与管理实战经验，书中从技术和管理视角全面剖析智能汽车电子与软件领域。
内容涵盖行业背景、组织架构、项目管理、开发方法、系统集成、流程体系、团队构建、核心标准、工具链、行业痛点及未来展望，推荐给从事智能汽车开发和管理的专业人士学习和参考。
本篇文章来源于这本书中的一些重要知识，希望对大家有所帮助。
