产品设计体会（3007）说说评审会

我的感觉，评审就是项目相关的几个小团队的人坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，防止偏差没有及时发现而随时间放大。这个过程不做，往往问题到很后才暴露，然后是谁的责任纠缠不清，与其亡羊补牢不如之前就在流程上预防，防病优于治病。

项目过程中，比较大的三方面是PD、开发、测试，所以派生出三次评审，按照项目阶段依次为：

Ø 需求评审，俗称UC评审，在需求完成以后，是PD说给开发、测试听；（iamsujie补：有的团队可能会先有需求评审，再有UC评审，也ok，这里的需求一般比较粗粒度。）

Ø 设计评审，在设计完成之后，是开发把对需求的理解以设计文档的形式说给PD、测试听，这部在时间紧的情况下会被省略（代码评审现在几乎不做）；（iamsujie补：开发很强可省，他们在需求评审时会问很多；开发较弱、新人、业务不熟则必须。）

Ø 测试评审，俗称TC评审，在TC写完测试开始之前，是测试把对需求的理解以TC的形式说给PD、开发听。

评审的发起方，可以考虑都由QA发起，作为项目过程管理的一部分。也可以考虑每个评审由每个阶段的负责人发起，在阿里通常是这样做的。

评审的主要过程：

Ø 确定参加人员，注意两种容易被漏掉的角色：一是能做决定的人，因为评审的时候各方不可避免的会对业务有不同理解，从而开始对需求细节进行讨论，这时候就需要有人能拍板，有人能负责；二是与此系统有接口的其他项目的成员，我们吃过太晚发现冲突的亏，改起来成本很高；

Ø 协调资源（时间、地点、设备），通常大家都很忙（包括会议室和投影仪），找个时间不容易；

Ø 事先分发文档，保证参加评审的人有足够的时间阅读并思考，每个参加者也要做好功课，带着问题参加（这点自己做的不好，=,=），否则评审是没有效率的，避免出现评审会上第一次看到相关文档的情况发生；

Ø 评审会本身，没问题就快速的通过，有小问题当场确认，大问题带回去，需要再次评审；最后是评审结果的发出，项目继续往下走。

（iamsujie补：开会必须有产出物，否则想想这个会是否有必要开。）