汽车软件质量在小企业该怎么干？

• 聚焦客户需求 传递、收集、版本整理、适用范围提取等 内外部接口处工作 ，最好 形成 包含来源、渠道、时间、存档位置等信息的 baseline。

• 确保 正确的人参与 评估、分析、拆解、实现 、评审等， 也就是“ 懂的人 ”和“ 错了要受影响 的人 ”。

• 时刻 质疑需求的合理性 ，这也是一种意识，要知道客户接口带来的不一定是真正的客户需求，要往上挖，找源头。

• 评估 关键相关方（主要是内部） 对需求的理解 是否一致和准确。

这里的成熟度主要是针对产品的，主要目的是 给管理团队信心和决策依据 ，有很多维度。

• 软件的 成熟度等级 ，可以是按照 feature实现程度 （如百分比、已集成/已可验/已可用）或者 适用的使用场景 （如台架、整车、路试）来定义。

• 质量阀红黄绿 状态，这也是非常典型的质量管控形式，简单粗暴但十分直观。

• 缺陷率 （不同等级缺陷数量加权相加）数值，通常用于不同产品的横向对比。

其目的和成熟度基本一致，但需要注意的是， 过程透明度通常会关系到产品成熟度水平和真实性 ，这是软件开发的特点。过程透明也是软件工程一直追求的目标。可以用如下一些方式。

• 设置 环环相扣的指标 ，驱动真实的开发行为展示，比如，监控各个阶段的缺陷检出率能够推动缺陷检出阶段数据的准确性 。

• ALM工具 中设置充足的 数据埋点 ，即 什么人在什么时间进行了什么操作进入了什么状态 。工具的自动痕迹留存功能能够很好地反映出真实的开发状态。

• 数据同源和工作同平台 。这样的话，信息的传递就是及时且透明的，但可能涉及到信息安全问题 。

尽量合规的“尽量”可能会让大家有疑问，这里主要是强调针对 强制性要求 和 衍生性要求 应有 不同的遵守尺度 。

• 强制性要求 是指高等级功能安全、数据安全、网络安全、车规标准或其他一些强标以及内部特定政策之类的 不必争论合理性的要求，既涉及产品，也涉及过程 。通常 产品基本功能 也可以理解为强制性要求。

• 衍生性要求 是指“ 最好有 ”或者“ 根据实际情况而定 ”，比如，软件详细设计就属于此类，写了更好，但模块简单，人员不分层，不写也行。
  

在这里，值得注意的是，合规不能仅仅局限在狭义QA里的流程不规范的检查，需要有宏观的视角，尤其是新的小的企业。

接着上一段，引出这个要求。

汽车行业拥有十分庞大的体系，身处大产业链上的一环，会遇到很多看似 无聊和不合理的现象 ，而它们 背后 多数有一个 曲折的故事 ，是 不同立场相关方利益较量的结果 。

软件质量作为一个体系性的管理角色需要有这个意识、视角与经验。

• 系统架构 、 软件架构 、 软件项目管理、功能安全 背景的人通常是软件质量比较好的选择，因为他们的知识结构比较系统和均衡。

• 监控、审核与评价过程中，需要 向上看代码 ， 向下找整车 ，这有助于给出更合理的判断。

• 着力 为项目经理或管理层 提供 信息的整体视图 ，比如，多维度缺陷动态看板、按里程碑的feature实现及验证状态、上下追溯矩阵等，也可以担当起 项目级配置管理 员的角色。
  

这是很多企业比较务实的需求，除了常规 应对审核 的工作外，还可以有其他的扩展 。

• 在项目 定点期间 ，就开始 介入 ，协同整车节奏制定质量管理计划。当下，协作开发的模式越来越多，也越来越复杂，仅局限在内部开发模式，不太够。

• 支持项目经理 进行外部 跨模块、跨部门 的信息整理、数据分析与汇报。

• 如 客户要求 和 内部要求 有 矛盾 ，需要带到内部进行适配与 裁剪 。

• 针对 新OEM ，尤其是欧美系，深入对标客户的 质量体系与指标的要求 。

软件质量设置在工程或项目管理部门，还是有独立汇报线，不同的公司有不同的模式，通常也取决于高管的背景。

一般建议保持独立的汇报线，至少要给一个与工程及项目管理相对 独立的汇报平台 ， 最好是处于独立且层级扁平的质量部门 。人员不多的，可以职级不高，但汇报线高一点。

决策权衡往往是基于立场，不独立，立场则相同，质量必然和工程或项目达成某种“默契”。

很少有公司能做到让软件质量或工程质量去block项目释放，对于小企业更不现实。

所以， 话语权与推动力更多来自于汇报 。当然，让质量说了算不是公司目的，而是更好地将前述的产品成熟度、过程透明度、项目big picture展现出来。