项目实施流程中，评审是很重要的一环，并且复杂的流程会有各种评审，比如需求评审，概要设计评审，详细设计评审， 用例评审等。 为什么需要有这么多评审？ 不评审会有什么影响？ 为什么很多开发人员反感评审，认为很多评审浪费时间？ 原因是对评审的目的和收益不理解，或其参与的评审已变质。 评审核心目的形成共识， 好的评审可以大大降低项目延期风险。

项目延期是工程研发过程中经常遇到的问题， 也是过程管理的一大难点，是体现项目经理管理能力的一大指标。 项目延期的原因有很多，根据个人几十个项目经验分析， 大部分原因是评审执行不到位。有的是评审退化为宣贯，有的是评审变成了批斗会， 还有的是根本取消了评审，其后果就是很多时候它就会在延期项目的反思会上会被拿来作为根因（很多时候再下一层的根因是不会去反思的）。个人遇到过的与评审有关延期理由有：

• 与产品理解不一致，导致开发返工。
• 产品逻辑不严谨，需要加需求。
• 测试回归发现，与前产品产生兼容性或逻辑性问题。
• 第三方原因导致。

以上几种或多或少都是因为没有共识，而一边项目中主要形成共识方式就是评审，因此这类延期大部分是与评审有关的， 有可能是没有评审（一般是小需求），或评审只是走形式退化为宣贯， 或评审组织出问题没有达到应用的目的。 那么什么时候该有评审，又如何组织评审呢。

我们都知道开发过程中很多阶段都是可以有评审的， 严格执行的话会导致评审形式化，评审成本增加，所以项目实际实施的时候确实很多评审会精简掉，到底哪些是需要保留呢？根据个人经验来看，存在以下情况需要保留对应的评审：

• 需求涉及多人或多方式时，必须有需求评审, 除非连专门测试都不需要的小需求外，因为需求评审是达成需求共识的最佳方式。
• 技术方案里涉及三方（调用或输出接口），或做了特殊解决方案时，必须要有技术方案评审。核心目的在于确认研发验证对需求理解
• 新项目需要有独立概要设计评审， 这对共识技术架构方案， 规范的统一有重要作用。
• 测试用例评审。 如果有测试接入，则用例评审是不可缺少。核心目的达成需求理解共识，确认测试的覆盖度。

个人认为开发过程中的评审不是能省则省的，而是要有尽有。 我们会发现项目里该有的评审都有，但还是经常出现理解偏差； 另外，是否项目里除了Leader 都方案评审。 这其实都评审实时问题， 为了让评审目的能够实现， 有几个方面是容易忽略却对评审目标达成有关键作用的。

• 大范围的评审，评审资料需先进行组内，或组织相干专家先进行小范围讨论，确认无颠覆性问题。
• 评审需要安排在整体项目开发计划中。 不是临时找时间，特别找非工作时间来安排， 评审的目的是发现问题达成共识，类似头脑风暴，是需要消耗参与的相干人员大量精力的。一般需要提前安排，且安排到上午，或下午上班1小时后。
• 评审资料要提前将资料发送到参与评审的相干人，且要求核心相干人员（如明确的关联研发，产品，测试等）充分了解。 可以采用协同编辑的问题收集列表方式，即使没有问题的也需要填写”无相关问题“，被评审人不用评审前去核对问题列表，以免造成干扰。被评审人讲解完，需标记问题列表的问题是否还存在，且记录新产生的问题。需要避免相干人临时进会， 导致对于相干人来讲评审会变成宣贯会。
• 评审会议不要变为问题解决会。 被评审人需要把握节奏，只做宣贯方案，解决理解偏差导致共识问题，其他问题如逻辑问题，遗漏问题等只做记录，避免直接讨论解决方案或修改方案。后续可小范围讨论解决， 解决方案通知各项目参与人，特别注意不要只解决不通知， 避免解决方案导致关联方出新问题。
• 参与评审人员应关注实质性问题。 即提问题要核心关注当前评审内容， 不要关注一些非实质问题，如文档格式，措辞等等， 也不要提自己联想到的与当前评审内容无实质关系的问题。
• 重视评审的组织。 首先相关负责人需要重视起来，注意组织工程，会议时间， 相干人选择， 通知， 场所都要有要求。 另外，除被评审人外，有一个主持人，主要把控会议流程，及时组织偏离目标的讨论。

总的来说，核心的问题还是要重视评审，特别是相关负责人，需要起到带头作用，带领并督促组员形成对评审重视的风气，不要让评审形式化，也不要评审变宣贯。