评审有“道”，落地更重要

如果所有内容都要评审，而且所有人都要参加，那么一个2周的版本中间光全体评审会就要开至少4次，再加上站会、小结会等，这样的节奏团队无法承受。今天笔者就这个问题跟大家谈谈自己的想法（所有的实践也都是笔者亲身尝试过），希望对你有所帮助。

近期笔者所在的团队对评审这件事儿有些头疼。一方面是评审质量，另一方面是流程不够明确。

• 哪些要做评审？

• 哪些可以不做？

• 要做的必须需要谁参加？

• 达到什么效果?

如果所有内容都要评审，而且所有人都要参加，那么一个2周的版本中间光全体评审会就要开至少4次，再加上站会、小结会等，这样的节奏团队无法承受。今天笔者就这个问题跟大家谈谈自己的想法（所有的实践也都是笔者亲身尝试过），希望对你有所帮助。

工作中我们常见的评审可能有如下几种：需求评审、交互稿评审、视觉评审、研发设计评审、测试用例评审、代码评审、上线计划评审、运营推广计划评审等等。可是每个版本如果都这么走一遭的话，还快的起来吗？在很多互联网公司，有些小版本也就5-10个工作日，这么搞吃不消。那怎么办？接下来请跟着笔者的思路走一趟，相信中间有些点你也深有同感。

1. 直面问题

让大家直面问题，评审需要得到团队的共同认可及对评审文化真正理解。写在最前面也是决定后面成败的最重要一环。笔者发现不同的企业文化对此的认知差别很大，而且接受程度也有很大不同。即便同一企业不同项目，对此的认知和认同也会不一样。所以如果想能往下走，最重要的一步就是团队共同认可，认可的基础是理解为什么这么做以及所阐释的理念。

评审的目的是基于大家对评审内容的理解上发现问题，提高评审内容的质量，确保接下来在做大家共同认可的事。评审后的输出则是所有评审人员共同的输出物，所有评审人员共同为此负责，而非只是owner。

这点很重要，有很多人都只认为那是owner的事情，我只是去了解是什么，哪里不合适提提意见就可以了。所以大家会发现不少评审会当时风平浪静，等交互案、视觉稿出来，又跳出来说这样设计不合理，blabla…回过头再去做重复功的情况时有发生。

只有得到团队的认可和真正理解，接下来的事才能轻松且有效的往下走（这里的轻松是指大家共同认可后的执行会更顺畅，让发起者更轻松）。而要让团队认可和真正理解，往往实际情况是团队在此确实遇到了问题，痛了。否则团队可能会认为这是在浪费大家时间。所以在让团队认可和理解这件事上所选择的时机也非常重要。如果是团队自己发现并抛出来，效果往往要比旁观者直接讲效果要好很多。

所以，笔者建议的形式是，在实际的工作过程中去发现，然后让团队参与分析和解决，中间去引导大家举一反三，最终达成大家所提出的共同认可的方式。

2. 团队确认流程

2.1 确认必有的评审

在得到认同的情况下，由团队或核心成员共同决策项目过程中各种评审的必要性和级别。哪些是一定要有的，哪些是在一定情况下要有的，哪些则是可选的（一般可选的往往都不会被执行）。必要性和级别的确定会根据当前团队和项目类型及所处的阶段不同而有所不同。比如，有些团队在测试用例评审环节总是会发现很多问题，他们会将此评审优先级作为必选。有些项目是偏视觉的比如官网风格等，则视觉评审变得很重要。有些项目是底层存储数据类项目，设计文档以及上线计划的评审是必须的等。

不同团队、项目类型及所处阶段不同会对此有不同的要求，需要团队确认当前情况下项目过程中各评审的优先级。

2.2 确定评审的类型和必须参与的角色

（1）确定评审类型

先需要了解评审对象的重要性和复杂度，接下来确认不同重要性的评审所采用的方式。可能是最为正规的会议评审，可能是略微轻松的站会评审，也可能是邮件评审等。这里介绍下几类评审的区别。

• 第一类会议评审：相对正式，提前发出会议邀请和评审内容，通过正式会议的形式让评审员共同确认评审对象并对有疑义的地方做确认，从而输出大家共同认可的评审对象。

• 第二类站会评审：相对形式活泼些，时间和地点都比较随意。比较适合非关键性或很小的内容确认，几个人在座位上一同确认评审对象并达成一致。

• 第三类邮件/线下评审：通过邮件的形式，在邮件指定的时间范围内，各自进行评审，并反馈意见。

（2）确定评审角色

不同的评审对象所要求的评审成员可能是不同的。比如视觉评审，视觉主管、产品是必须的，交互、开发、测试是可选的；对于开发设计评审，对应的开发主管和测试同学是必须的，交互、视觉是可选的。所以要针对自己的项目和团队组成情况，对不同的评审内容的角色进行确定。

2.3 关于执行

（1）评审会前

• 确定是会议评审还是邮件评审；

• 将评审材料至少提前一天发出，便于参会人提前了解评审内容；

• 所有关键评审员都要确认可以参加评审会议；

• 开会前收到所有关键评审员的反馈，此项标为可选项，因为会发现在不同类型的项目以及不同的团队，所适用的情况是不一样的。

用此环节来确保每个关键评审员都有提前看过材料，从而会上可以只针对问题展开讨论，大大提高评审会上的效率。如果有人在会前没有反馈，那么延迟会议并发邮件说明是因为什么而延迟，这样下次基本就不会再出现这种情况。而有些项目可能是一次性且周期很短的情况，当场讲述比写详细的文档更高效。那评审的材料会当场讲述，然后大家提出疑义和反馈意见。可能会出现的情况是，短暂的会议时间想到的点不全，会后就过去了，或者会后再提出再进行沟通讨论。大家根据自己项目的类型以及团队实际情况选择适合的方式。

（2）评审会中

• 按照会议议程有序进行；

• 将所有的comments用相应的工具记录下来以便会后跟踪；

• 为保证会议高效，每个议题应控制在3~5分钟；

• 除了主持人，其它人员不许带电脑；

• 整个会议最好是1小时以内，不要超过2小时；

• 如果发现critical或者block级别的问题，则团队会上立即商议是否需要二次评审。

（3）评审会后

• 作者根据评审会上接受的建议进行更新；

• 所有会上未有结论的议题，会后有公告，并将更新后的材料发出再次邮件确认；

• 所有关键评审员对更新的材料进行再次审核，没有异议则Done；

• 执行流程确认后，可以做个简单的checklist帮忙辅助确认。

在现实工作中，评审会后的跟进往往容易被轻视。特别是一些未确定但不会影响当前进展的问题，往往是到了开发在做的时候才再次被提出讨论确认。这些问题甚至可能会引起更多问题，导致开发测试的重复功，所以待跟进问题的落实在团队共同确定执行方式时也需要引起重视。

结语

以上便是笔者关于评审各环节的一些认知和实际做法，从团队共同认可（认可并深刻理解评审文化：大家共同对评审内容负责，而不是只有作者 ），到团队共同确认流程（哪些类型是要做评审的，以及是何种程度的评审），再到具体执行（执行方式的选择和确认）。这些环节中最重要的就是第一步团队共同认可。只有大家真正认可和理解这件事，后面确定流程以及执行才能更深入人心。当然团队的执行力也不容小觑，再完美的方案也需要落地才能见到效果。