第2章流程评审基础

2、流程评审基础：评审的定义与目的、评审的类型、评审的角色与职责

大家好，我是老张。今天咱们聊聊流程评审的基础。说实话，很多团队把评审当成走过场，这其实是个大坑。我见过太多项目，因为评审流于形式，最后在集成测试阶段发现一堆问题，改起来成本高得吓人。

所以，咱们先把基础打牢。搞清楚评审到底是什么，为什么做，怎么做，谁来做。这些东西搞明白了，后面的效率提升才有根基。

评审，说白了就是一群人坐在一起，对某个工作产品进行系统性的检查。这个工作产品可以是需求文档、设计文档、代码、测试用例，甚至是流程本身。

那评审的目的是什么？我个人的理解，核心就三点：

发现缺陷：越早发现，修复成本越低。这是最直接的目的。
统一理解：确保所有干系人对需求、设计、方案的理解是一致的。我在项目中遇到过，开发说“我理解了”，测试也说“我理解了”，结果做出来完全两码事。评审就是用来对齐的。
知识传递：新人可以通过评审快速了解项目背景和设计思路。老手也能从别人的视角发现自己的盲区。

核心观点：评审不是找茬，而是帮团队提前排雷。你想想看，一个缺陷在需求阶段发现，改起来可能就几分钟；到了生产环境才发现，那可能就是几百万的损失。

ASPICE里把评审分成了三种类型。嗯，这里要注意，很多人把“评审”和“测试”混为一谈，其实它们是完全不同的活动。测试是动态的，要跑代码；评审是静态的，靠人眼看。

三种类型分别是：

正式评审是最重型的。它有一套完整的流程：计划、预审、评审会议、返工、跟踪。通常需要项目经理、质量经理、客户代表等高层参与。

我记得有一次做功能安全项目的里程碑评审，光预审材料就准备了三天。评审会上大家逐条过，每条都要有结论。虽然过程很痛苦，但那次评审确实堵住了好几个设计上的漏洞。

避坑指南：我曾经见过一个团队，把正式评审搞成了“批斗会”。主持人上来就说“这个文档写得不行”，然后大家开始互相指责。结果评审会开了四个小时，一个问题都没解决。正式评审要聚焦在“产品”上，不是“人”上。

技术评审是咱们日常用得最多的。它不像正式评审那么隆重，但比走查要正式一些。通常由技术负责人组织，邀请相关领域的专家参加。

我个人习惯，技术评审前会先发一份“评审邀请”，里面附上待评审的材料和重点关注的问题。这样大家带着问题来，效率会高很多。

举个例子，有一次做AUTOSAR架构的技术评审，我提前把“接口一致性”和“时序约束”这两个点标红。评审会上大家就盯着这两个点深挖，果然发现了一个RTE配置错误。如果走常规流程，这个问题可能要等到集成测试才能发现。

走查是最轻量级的评审。说白了，就是作者带着大家过一遍自己的工作产品。走查不需要提前准备，也不需要正式记录，但要求参与者能随时提问。

我建议，代码走查可以这样搞：作者打开IDE，一行一行地讲代码逻辑。听众随时打断提问。这种方式特别适合新人培养。我刚开始带团队时，每周五下午都会组织一次代码走查，效果非常好。

小技巧：走查时，作者不要急着解释“为什么这么写”，先让听众自己看，然后提问。这样能锻炼听众的阅读能力，也能发现作者没意识到的盲区。

评审不是随便拉几个人就能开的。每个角色都有明确的职责。搞不清楚角色，评审就容易乱。

ASPICE里定义了四个核心角色：

主持人：负责组织评审、控制节奏、确保会议不跑偏。主持人不能是作者本人，也不能是评审对象的直接上级。我见过最糟糕的主持人，自己先发表了一通“高见”，然后大家都不敢说话了。
作者：提供待评审的材料，回答评审员的问题。作者要心态开放，不要觉得别人提问题就是否定自己。我曾经遇到一个开发，别人一提意见他就急，最后评审会变成了辩论赛。
评审员：提前阅读材料，在会上提出问题和建议。评审员要客观，不要带个人情绪。我建议评审员在预审时就把问题写下来，这样会上不会遗漏。
记录员：记录评审过程中的所有问题、决议、行动项。记录员要中立，不能选择性记录。我习惯用Excel表格，一列问题描述，一列责任人，一列截止日期，清清楚楚。

除了这四个核心角色，有时候还需要决策者。比如正式评审中，决策者负责对争议问题做最终裁决。决策者通常是项目经理或技术总监。

经验之谈：评审员的数量不是越多越好。我个人的经验，3-5个评审员是最佳范围。人少了视角不够，人多了会议效率低下。另外，评审员要具备互补的技能。比如评审设计文档，最好有架构师、开发、测试各一名。

好了，这一章的内容就这些。咱们回顾一下：

下一章，咱们聊聊如何制定评审计划。说白了，就是怎么在项目开始前就把评审安排得明明白白，避免临时抱佛脚。

我是老张，咱们下章见。