大江大河，静水流深——我赋予“质量评审”的高价值

最近又做了几次评审，涉及到智能座舱、自动驾驶及传统的嵌入式多种类型的模块，有感觉比较顺畅、可以让自己以往的经验知识有发挥空间的地方，也有感觉难以入手、听不懂对方说什么、也不知道该怎么问的地方……趁热打铁，简单写一点经验和教训的总结。

1

一个值得尊敬的评审员应该是什么样的？

评审员要想获得业务的认可和尊重，首先，必须要展示出你对业务理解的广度和深度，以及看到点上的眼力和说到点上的嘴力。

对业务的理解能够让你和项目成员用“行话”交流，说“行话”是获得技术人员尊重的首要条件，不然，肯定是嘴上“您好”，心里“骂娘”。比如，ASIL怎么读，MISRA怎么读，外行一开口就会露底。

怎么能找到“点”，很考验评审员的能力和经验。除了一些技术性或专业性知识，多数“点”就是那些“坑”，你挖过“坑”，填过“坑”，才会知道“坑”在哪里，一个优秀的评审员非常需要实际的业务经验，如果你有非常丰富的“忽悠”评审员或甲方的经验，你“反忽悠”的水平自然也是首屈一指的。

评审员主要靠嘴来说，所以嘴力很重要，你要能说明白话、说完整话、说严谨话、说总结话，不说废话、不说车轱辘话、不说没根据的话。

此外，尽管被评审方出于对审核出来的问题项的反感，多数会对评审员报以一定的尊重，但评审员自身切莫居高临下、装专家、充大头，谦逊、不卑不亢是评审员的基本素养，当你经验越丰富，也会越发现自己视野和知识的局限性。

正所谓，山外有山，人外有人。碰到对方擅长的领域，也是自讨没趣。

评审员的水平上不封顶，但如若能做到以上列举的部分，也足够获得对方的基本尊重了。

2

评审员的“主心骨”——逻辑

还是想提“逻辑”这个词，专业不够，只能逻辑来凑。

从概念上，逻辑的内涵极为广泛，但我们日常的感觉上，如果评价一个人逻辑好，基本上是这个人说话能抓住重点、简洁、有条理、易理解。

对于评审而言，基本要做到以下这几点：

1） 以Checklist作为框架，不要太自由发散；

2）一件事情不要重复提及，让对方反复解释；

3） 把控节奏，不要被对方牵着鼻子走，评你想评的，问你想问的；

4） 跑题不可避免，但要记住跑之前在聊什么，及时回来；

5）对于 同样的信息，要在不同的人、不同的地方、不同的时间处印证；

6） 关注PDCA，关注闭环，关注输入输出；

7） 提前做准备，梳理思路，特别是经验不丰富时，甚至开场、暖场、收尾的话都可以提前串好。

《金字塔原理》里描述了比较实用的思维模型，可以参考。

3

发问有什么技巧？

从形式上，评审也就是发问、回答、记录这几个环节。

由此可见，发问是开端，也是评审员能力的集中体现，所以发问是非常见功力的。

有些粗浅的技巧可供参考，有一个很重要的点是新手评审员经常忽略的，忘记关注回答者是什么角色，面对项目经理就不要问代码结构，面对程序员就不要问商务决策……否则，不是得到不准确的答案，就是重复问询，显得你思维混乱。

还有个很关键的是，获取信息要问开放式问题，要让对方多讲，尽量让其提供更全面的信息；而确认信息可以在你精炼总结后问封闭式问题，提高效率。

比如，让对方简单介绍一下模型代码的交付过程，在他回答的过程中，交流你的关注点，而如果问“你是软件开发工程师吗？“、“代码是基于模型生成的吗？“、”是用某某软件吗？、“是你完成相应Code Review吗”……对方只能回答“是“或”不是“，你只能得到你认为的局限的信息，甚至当你问题本身偏颇时，会引导对方回答出错误的信息。

不过，评审员需要偶尔来确认你的理解是否准确，有时候被评审方会讲得很多，讲原因，讲原理，讲思路，你可能需要适当打断，来从他的表达里提炼出你所需要的，然后总结后用封闭式问题确认。

比如，对方一直在讲，由于外部因素，导致我们时间压力很大，但我们通过很多方式，经过很多人，严格地评定了此次的交付风险，风险很小……套话和空话居多，你就可以直截了当地问“测试是不是还没做完？”、“是不是项目经理根据经验‘拍脑袋’觉得问题不大？”、“风险很小的意思是不是指邮件发出后无人反馈有风险？”。

4

评审就是快速走一遍业务流

我们经常说业务流、信息流、物流、价值流，一个好的评审就是要快速走一遍业务流，干流要顺着业务流跑过去看一下，支流要确认实际工作有流过去，具体状态可以抽查，毕竟人家一个项目少则几个月，多则好几年，你半天一天时间无法覆盖那么全面。

这里面的流有两方面：一是对方是否确实走过，是否切切实实做了这部分工作，他们走得是不是顺畅；二是你是否有能力走过去看看，你走得是不是顺畅，这需要我们没有知识漏洞，需要我们不容易被忽悠。

“流”，我们更多是在说普遍的全面，一定程度的“深”也是必要的，特别是当你需要向上汇报时，汇报需要言之有物，要具体，要直观，所以技术细节层面的情况也要适当挖掘。

怎么“深”呢？就是所谓多想一步，多卷一步。

比如，第一步识别出某部分测试未完成，第二步去找到哪些未完成，第三步去分析未完成的原因，第四步去明确未完成的影响，第五步去想想如何解决，第六步再思考下后续改善的方法……卷到山穷水尽，卷到海枯石烂。

当然，对于这么多步骤，从评审的角度，未必是你该关心的，但从整个业务过程来看，这些东西都需要去关注的。

5

写在最后

评审很容易，明哲保身，应付交差，多数没太大压力；

评审也很难，言之有理，言之有物，言之有序，都需要你有深厚的积累和积极的态度。

当然，大江大河，静水流深，对于评审这一手段或工作类型，我们可以期望既要、又要、还要，但不要太过期待可以、应该、马上。

“期望”是一个理性的指引目标，是对“摸鱼”小伙伴说的，事情可以做做好；“期待”是你以为容易或应该达到这个目标的执念，是对“卷王”小伙伴说的，不要想用铁钻头打磨细瓷器。