产品设计体会(3007)说说评审会

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

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

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

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

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

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

评审的主要过程:

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

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

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

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

iamsujie补:开会必须有产出物,否则想想这个会是否有必要开。