关于评审--从思想到落地

作者：刘煦萍

近期笔者所在的团队对评审这件事儿有些头疼，一方面是评审质量，另一方面是流程不够明确。哪些要做评审？哪些可以不做？要做的必须要谁参加？达到什么效果？如果所有内容都要评审，而且所有人都要参加，那么一个2周的版本中间光全体评审会就要开至少4次，再加上站会、小结会等，这样的节奏团队无法承受。今天笔者就这个问题跟大家谈谈自己的想法（所有的实践也都是笔者亲身尝试过），希望能有所帮助。

工作中我们常见的评审可能有：需求评审、交互稿评审、视觉评审、研发设计评审、测试用例评审、代码评审、上线计划评审、运营推广计划评审等等。可是每个版本如果都这么走一遭的话，还快的起来吗？特别是在很多互联网公司有些小版本也就5-10个工作日，这么搞似乎吃不消啊。

那怎么办？接下来就跟着笔者的思路走一遭吧，相信中间有些点你也深有同感。

1.      直面问题

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

评审的目的是基于大家对评审内容的理解后为了发现问题，提高评审内容的质量，确保接下来在做大家共同认可的事。评审后的输出则是所有评审人员共同的输出物，所有评审人员共同为此负责，而非只是owner。这点很重要，而且很多人都认为那是owner的事情，我只是去了解是什么，然后觉得哪里不合适提提意见。所以会发现很多评审上风平浪静，等交互案、视觉稿出了，反过来说这样设计不合理，blabla……回过头再去做重复功的情况时常发生。

只有得到团队的认可和真正理解，接下来的事才能轻松且有效的往下走（这里的轻松是指大家共同认可后的执行会更顺畅，让发起者更轻松）。而要让团队认可和真正理解，往往的实际情况是团队在此确实遇到了问题，痛了，否则可能会认为竟是些有的没的浪费大家时间的东西。所以让团队认可和理解这件事所选择的时机其实也很重要，如果是让团队自己发现并抛出来的效果往往要比旁观者去讲的效果要好的多。所以笔者所建议的形式是，在实际的工作过程中去发现，然后让团队参与去分析和解决，中间去引导大家举一反三，最终达成大家所提出的共同认可的方式。

2.      团队确认流程

2.1  确认一定要有的评审

在得到认同的情况下，由团队或核心成员共同决策项目过程中各种评审的必要性和级别，有些是一定要有的，有些是在一定情况下要有的，有些则可选（一般可选的往往都是不会被执行的）。

必要性和级别的确定会根据当前团队和项目类型及所处的阶段不同会有所不同，比如，有些团队在测试用例评审环节总是会发现很多问题，他们会将此评审优先级作为必选。有些项目是偏视觉的比如官网风格等，则视觉评审变得很重要。有些项目是底层存储数据类项目，设计文档以及上线计划的评审是必须的等等。所以不同团队、项目类型及所处阶段不同会对此有不同的要求，需要团队确认当前情况下项目过程中各评审的优先级。

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

a)      确定评审类型。

需要先了解评审对象的重要性和复杂度，下一步要确认不同重要性的评审所采用的方式，可能是最为正规的会议评审，可能是略微轻松的站会评审，可能是邮件评审等；

这里需要介绍下几类评审的区别。

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

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

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

b)      确定评审角色。

不同的评审对象所要求的评审成员可能是不同的，比如视觉评审，可能视觉主管、产品是必须的，交互、开发、测试是可选的；对于开发设计评审，可能对应开发主管和测试同学是必须的，交互、视觉是可选的。

所以要针对自己的项目和团队组成情况，对不同评审内容的角色进行确定，以下图为例，可以在团队中共同确认这个表格，作为后面参考的标准。 

对象 角色	需求案评审	交互案评审	视觉稿评审	开发设计评审	测试用例评审
策划	P0	P0	P0	P1	P1
交互	P0	P0	P0		P1
视觉	P1	P0	P0（视觉主管）
开发	P0（开发主管）	P0（开发主管）		P0	P0
QA	P0（QA主管）	P0（QA主管）		P0	P0
运营	P0（运营主管）	P1

2.3  关于执行

a)      评审会前

• 确定是会议评审还是邮件评审？
• 将评审材料提前至少一天发出，便于参会人提前了解评审内容；
• 所有关键评审员都要确认可以参加评审会议；
• 开会前收到所有关键评审员的反馈，此项标为可选项，因为会发现在不同类型的项目以及不同的团队，所适用的情况是不一样的。

之前有严格按照此来做的，即用此环节来确保每个关键评审员都有提前看过材料，从而会上可以只针对问题展开讨论，大大提高评审会上的效率，如果有人在会前没有反馈那么会延迟会议并发邮件说明是因为什么而延迟，这样下次基本就不会再出现这种情况。

而有些项目可能是一次性且周期很短的情况，当场讲述比写详细的文档更高效，所以评审的材料会当场讲述，然后大家提出疑义和反馈意见，可能会出现的情况是，短暂的会议时间想到的点不全，会后就过去了，或者会后再提出再进行沟通讨论。

大家需要根据自己项目的类型以及团队实际情况选择适合的方式。

b)      评审会

• 按照会议议程有序进行
• 将所有的comments用相应的工具记录下来以便会后跟踪
• 为保证会议高效，每个议题应控制在3~5分钟
• 除了主持人，其它人员不许带电脑
• 整个会议最好是1小时以内，不要超过2小时

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

c)      评审会后

• 作者根据评审会上接受的建议进行更新
• 所有会上未有结论的议题，会后有公告，并将更新后的材料发出再次邮件确认
• 所有关键评审员对更新的材料进行再次审核，没有异议则Done.

执行流程确认后，可以做个简单的checklist进行确认

检查表
1	确定进行哪种类型的评审？	正式会议
2	确定关键评审人员	xx、xx、xx
3	至少提前一天发出邮件	√
4	所有关键评审员是否可以参会？	√
5	开会前收到comments？P1	X
6	进行评审会
7	通过？Or 不通过？
8	所有待跟进问题解决了？

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

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

网易云大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者刘煦萍授权发布