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

本文来自网易云社区

做者：刘煦萍

近期笔者所在的团队对评审这件事儿有些头疼，一方面是评审质量，另外一方面是流程不够明确。哪些要作评审？哪些能够不作？要作的必需要谁参加？达到什么效果？若是全部内容都要评审，并且全部人都要参加，那么一个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

本文来自网易云社区，经做者刘煦萍受权发布

相关文章：
【推荐】 3分钟掌握一个有数小技能：回头客分析
【推荐】 30分钟，让你完全明白Promise原理
【推荐】 wireshark抓包分析——TCP/IP协议