聚焦客户需求传递、收集、版本整理、适用范围提取等内外部接口处工作，最好形成包含来源、渠道、时间、存档位置等信息的baseline。
确保正确的人参与评估、分析、拆解、实现、评审等，也就是“懂的人”和“错了要受影响的人”。
时刻质疑需求的合理性，这也是一种意识，要知道客户接口带来的不一定是真正的客户需求，要往上挖，找源头。
评估关键相关方（主要是内部）对需求的理解是否一致和准确。
这里的成熟度主要是针对产品的，主要目的是给管理团队信心和决策依据，有很多维度。
软件的成熟度等级，可以是按照feature实现程度（如百分比、已集成/已可验/已可用）或者适用的使用场景（如台架、整车、路试）来定义。
质量阀红黄绿状态，这也是非常典型的质量管控形式，简单粗暴但十分直观。
缺陷率（不同等级缺陷数量加权相加）数值，通常用于不同产品的横向对比。
其目的和成熟度基本一致，但需要注意的是，过程透明度通常会关系到产品成熟度水平和真实性，这是软件开发的特点。过程透明也是软件工程一直追求的目标。可以用如下一些方式。
设置环环相扣的指标，驱动真实的开发行为展示，比如，监控各个阶段的缺陷检出率能够推动缺陷检出阶段数据的准确性。
ALM工具中设置充足的数据埋点，即什么人在什么时间进行了什么操作进入了什么状态。工具的自动痕迹留存功能能够很好地反映出真实的开发状态。
数据同源和工作同平台。这样的话，信息的传递就是及时且透明的，但可能涉及到信息安全问题。
尽量合规的“尽量”可能会让大家有疑问，这里主要是强调针对强制性要求和衍生性要求应有不同的遵守尺度。
强制性要求是指高等级功能安全、数据安全、网络安全、车规标准或其他一些强标以及内部特定政策之类的不必争论合理性的要求，既涉及产品，也涉及过程。通常产品基本功能也可以理解为强制性要求。
衍生性要求是指“最好有”或者“根据实际情况而定”，比如，软件详细设计就属于此类，写了更好，但模块简单，人员不分层，不写也行。
在这里，值得注意的是，合规不能仅仅局限在狭义QA里的流程不规范的检查，需要有宏观的视角，尤其是新的小的企业。
接着上一段，引出这个要求。
汽车行业拥有十分庞大的体系，身处大产业链上的一环，会遇到很多看似无聊和不合理的现象，而它们背后多数有一个曲折的故事，是不同立场相关方利益较量的结果。
软件质量作为一个体系性的管理角色需要有这个意识、视角与经验。
系统架构、软件架构、软件项目管理、功能安全背景的人通常是软件质量比较好的选择，因为他们的知识结构比较系统和均衡。
监控、审核与评价过程中，需要向上看代码，向下找整车，这有助于给出更合理的判断。
着力为项目经理或管理层提供信息的整体视图，比如，多维度缺陷动态看板、按里程碑的feature实现及验证状态、上下追溯矩阵等，也可以担当起项目级配置管理员的角色。
这是很多企业比较务实的需求，除了常规应对审核的工作外，还可以有其他的扩展。
在项目定点期间，就开始介入，协同整车节奏制定质量管理计划。当下，协作开发的模式越来越多，也越来越复杂，仅局限在内部开发模式，不太够。
支持项目经理进行外部跨模块、跨部门的信息整理、数据分析与汇报。
如客户要求和内部要求有矛盾，需要带到内部进行适配与裁剪。
针对新OEM，尤其是欧美系，深入对标客户的质量体系与指标的要求。
软件质量设置在工程或项目管理部门，还是有独立汇报线，不同的公司有不同的模式，通常也取决于高管的背景。
一般建议保持独立的汇报线，至少要给一个与工程及项目管理相对独立的汇报平台，最好是处于独立且层级扁平的质量部门。人员不多的，可以职级不高，但汇报线高一点。
决策权衡往往是基于立场，不独立，立场则相同，质量必然和工程或项目达成某种“默契”。
很少有公司能做到让软件质量或工程质量去block项目释放，对于小企业更不现实。
所以，话语权与推动力更多来自于汇报。当然，让质量说了算不是公司目的，而是更好地将前述的产品成熟度、过程透明度、项目big picture展现出来。
邮件发送的日报、周报、月报会提供第一个工作层平台。
定期的高级别管理层专题会议是第二个有权威的平台。
形式规范的质量阀是第三个成机制的平台，注意形式一定要规范。礼仪之邦，不仅仅是礼貌，还有约束。
向车厂发布软件或样件之前，企业内部要有管控与释放机制，而不是个人化行为。软件质量在该环节要负责提供证据。
要关注产品的预期用途，比如，台架测试还是整车路试，对软件的要求自然不同。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
完
