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

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

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

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

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

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

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

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

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

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

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

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

（1）确定评审类型

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

（2）确定评审角色

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

（1）评审会前

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

（2）评审会中

（3）评审会后

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!