📚 课程目录第4章评审流程设计

4. 评审流程设计：评审计划、预审、评审会议、缺陷跟踪、闭环验证

评审不是开个会就完事了。我见过太多团队，把评审搞成了“批斗会”或者“走过场”。说白了，评审是一个结构化、可度量、可追溯的质量活动。它需要像软件开发流程一样，有清晰的阶段划分和准入准出标准。

我个人习惯把评审流程拆成五个阶段：计划 → 预审 → 会议 → 跟踪 → 闭环。这五个阶段环环相扣，少一个都不行。

  核心观点：评审不是找茬，是风险前置。越早发现问题，修复成本越低。嵌入式项目里，一个硬件接口定义错误，到了联调阶段可能要改板子，成本翻几十倍。

评审计划不是简单地在日历上约个时间。你得想清楚：审什么？谁来审？什么时候审？

我在项目中遇到过最典型的反面案例：项目经理周五下午发邮件说“下周一评审设计文档”，结果大家周末加班看文档，周一开会时每个人理解都不一样。嗯，这种评审基本是浪费时间。

一个合格的评审计划应该包含以下要素：

小技巧：评审计划最好在项目周会上同步，而不是单独发邮件。让所有人知道“下周要评审XX模块”，大家心里有数，不会临时抓瞎。

预审是评审流程里最容易被忽视、但价值最高的环节。你想想看，评审会议就那么一两个小时，如果大家现场才看文档，能看出什么深度问题？

预审的核心是：评审员独立审查，提前提交问题清单。

我曾经带过一个项目，要求所有评审员在会前48小时提交预审意见。刚开始大家觉得麻烦，但执行了两次之后，评审会议的效率提升了至少一倍。为什么？因为会上不用花时间“读文档”，直接讨论问题。

预审阶段我建议做这几件事：

注意：如果预审阶段发现的问题超过20个，或者有严重的设计缺陷，我建议推迟评审会议。让作者先修改，改完再重新走预审。硬着头皮开会，只会浪费所有人的时间。

评审会议不是“作者读文档，大家听”。那是培训，不是评审。评审会议的核心是讨论预审中未达成一致的问题，以及发现预审遗漏的深层次问题。

我主持评审会议时，通常会遵循这个流程：

这里有个关键点：评审会议不负责“解决问题”，只负责“识别问题”和“确定责任人”。具体怎么改，会后由作者和相关负责人去落实。否则会议会变成无休止的技术辩论。

  评审会议三不准：

不准在会议上现场修改文档。

不准偏离议程讨论无关话题。

不准把评审会开成“问责会”。

评审会上发现了问题，然后呢？如果没有跟踪机制，这些问题大概率会石沉大海。我见过太多项目，评审记录写了几十页，但三个月后回头看，一半的问题都没改。

缺陷跟踪的核心是建立问题台账。每个问题都要有唯一的编号、描述、严重等级、责任人、解决期限和状态。

我常用的缺陷跟踪表结构如下：

ID	问题描述	严重等级	责任人	计划关闭日期	状态
REV-001	SPI时钟极性定义与数据手册不一致	严重	张三	2024-03-15	已修复
REV-002	看门狗超时时间未留余量	一般	李四	2024-03-18	进行中
REV-003	中断优先级配置缺少注释	建议	王五	2024-03-20	待确认

严重等级我一般分三级：严重（不改会导致功能失败或安全风险）、一般（影响可维护性或性能）、建议（优化项，不改也能接受）。

工具推荐：小团队用Excel或在线表格就行。大项目建议用Jira、Redmine或禅道。关键是每周同步一次状态，别让问题积压。

这是评审流程的最后一环，也是最容易被“信任”取代的一环。作者说“我改好了”，主持人就信了？不行。你得验证。

闭环验证有两种方式：

我记得有一次，一个硬件工程师说“电源纹波问题已经改好了”，结果复验时发现他只是在原理图上改了电容值，但PCB布局根本没动。嗯，这种问题如果不复验，到了打板阶段就晚了。

闭环验证完成后，需要在缺陷跟踪表里更新状态，并归档评审记录。归档的目的是：以后项目复盘时，可以追溯每个设计决策的来龙去脉。

铁律：所有“严重”级别的问题，必须经过评审员复验才能关闭。没有例外。这是质量底线。

说了这么多，咱们用一张图把整个流程串起来。这张图我每次做项目培训都会用，你直接拿去用就行。

这张图里有个细节你可能注意到了：每个阶段都有回退箭头。这不是为了增加流程复杂度，而是为了守住质量底线。预审发现太多问题，退回修改；会议发现重大缺陷，重新预审；闭环验证不通过，重新走评审。你想想看，如果每个阶段都“凑合过”，最后出问题的概率有多大？

好了，评审流程设计就讲到这里。这套流程我用了七八年，在十几个嵌入式项目里验证过。刚开始团队会觉得“太麻烦”，但坚持两三个迭代之后，大家会发现：评审越规范，返工越少，项目越顺。这就是质量管理的复利效应。