质量评审的节奏和逻辑把控

质量评审离不开标准，而标准必然是分模块的，或者用ASPICE的语言是“域”，这样的“域”是人为按照不同的视角和维度进行的逻辑划分，逻辑上是清晰的，但操作上往往很难分得清楚你我他。

很多主持质量评审的人都会有这种“拎不清”的感觉，特别是标准化程度不够高时，这是今天行文的一个原因，帮助质量的朋友梳理下节奏。

尽管ASPICE或各公司自己的各种模式都会分得很细，比如系统工程、软件工程、项目管理、支持过程等，以及在此基础上的需求、架构、代码、验证、评审、变更管理、配置管理、问题管理、风险管理等，五花八门。

然而，实际上的项目要素都是你中有我，我中有你，系统里有软件，软件里还有硬件，需求中可能来源于变更，代码中可能有风险，测试中还催生了问题……

系统评审时，看到了具体软硬件的内容，深挖还是停止？梳理需求时发现来源于变更，怎么办，需求问题还是变更问题？看静态代码分析时，看到了风险，问不问，定位在风险管理还是代码质量？测试测出了问题，是问题管理的问题还是测试管理的问题……

诸如此类，不一而足。

实际观察中发现，各位评审员很多时候会走一步问一步，记一步看一步，能到哪算到哪。最终报告的逻辑难免是混杂不清的，这样的报告拿出去，很难说，能让人很信服。

逻辑是质量人员的必杀技，也应是基本功。

答案并不复杂，就是定好“标准”和“定义”。同一个标准定义是逻辑的开端。

我刚和团队定义了几个评审点的范围，结合这个范式，做一点阐释，可供参考。质量面对的对象整体大体可以分为两类：过程和产品，有时也不得不考虑诸如成本、时间、战略等，我们下面的内容也会尝试引入这几个角度来探讨。

对于某一项目或产品而言，我们整个项目团队以及所有的支持团队的终极目标，其实就是满足客户上帝的真实需求，从而获取收益，这也是所谓Business Sense的最初级，职场新人可以品味一下。工程化语言一点，可用FeatureList来涵盖，一般来说，我们必须要评审这个项目的Feature List是否具备以及是否实现，这是侧重于非常High Level的需求，怎么说呢，可以理解为关键利益相关者直接感知和关心的那部分内容，比如汽车转向、刹车可以正常操作，仪表可以正常显示等等。对于仪表显示有些模糊，转向回正时灯关闭有延迟之类的“小问题”，可以不在此环节深挖，但对于某些重大Bug，严重到影响到了刹车卡滞的程度，那这个环节也不能坐视不管。或者说，某Feature的开发涉及到了高昂成本并影响到了交付，理论上我们也应该关注下。

风险管理、问题管理、变更管理、需求管理……都带有管理的字样，那么对于这类评审点，我们不得不关注其管理，关注其“过程”，看它的管理水平如何，是不是走了预设的流程，是不是完成了该有的评审。除此之外，还要关心对产品性能的影响吗，还要关心对项目交付的影响吗？当然，我们该时刻有商业Sense和业务Sense。

不过呢，如何做到既不过度热情，又不过度冷淡，关心得恰到好处？点到为止。尽管实际是很难的，但是这个原则会让你把控节奏上有了依托。比如，变更管理过程中发现了某个变更导致了严重Bug，严重Bug还引起了巨大交付风险，而且Root Cause是需求理解错误，它们会相互纠葛，但当你审到变更时，你的重点要放在变更本身，看CCB开展得如何，看变更分析得怎么样，可以点到Bug，但落脚点还是变更，手莫伸得太远，管得不要太宽。管理就管管理，技术归技术。

对于架构、代码、测试等，偏技术一点，可以多看看它们的本身质量，通过率怎么样，覆盖率多少，CPU负载率多大，内存溢出风险高不高，Fail项有没有合理解释和风险评估等等，而对于比如测试计划的整体安排和评审情况略微降低一点要求……

几个粗浅的评审点例子，显然不能作为标准。我的核心观点是，基于公司、项目和产品的特点，定义好评审标准和定义，定义方式可以各有不同，甚至完全相反，但逻辑要清晰，节奏要有序。

在和某家业内巨无霸公司交流中发现，他们会给具体评审的打分一个Case参考，就是让这样的标准和范围更具实操性。

这都需要时间，要一步一步来，当一切都越来越成熟时，这样的Case越来越多，质量人员脑子里记的Case也越来越多，未见过的特殊Case越来越少，大家的节奏就都稳下来了。

质量评审只是一个小点，更重要的是看到汽车软件拨乱反正的归途。