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

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

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

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

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

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

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

评审的主要过程:

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

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

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

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

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

产品设计体会(3005)流程的作用

这次谈一下网店版项目从小到大,直到2007年夏整理出来的日常需求发布流程(写完发现流程本身没有谈及,下次再说)。

2006年底项目最初的时候,完全是白板一块,当时连要做什么都不知道,所以靠的是几位老大和我们依靠“随机应变”式的个人控制来把握项目进程,那时每个人都对产品的一切非常了解。对一个需求的响应速度超快,经常是晚上要发布,下午PD还会直接跟开发提一个需求,而开发也马上就开始coding了,完了测试点两下没问题也就上去了。这种猛打猛冲团队的核心优势就如一位著名人士所说——天下武功,无坚不破,唯快不破(《功夫》里的火云邪神)。

到了后来,加入的人越来越多,产品也越来越庞大,特别是最近几周,越来越感觉已经不能掌握产品的全部,经常需要询问别人,有的时候甚至找不到一个知道的人。(插话:不过这似乎也有一点好处,那就是当你对一个产品不太熟悉的时候才更容易体会到产品是否易用,这在对产品了如指掌的时候是体会不到的,昨天测试也笑言我们经常做一些超越人类理解力、违背人类常识的东西。)

项目庞大了以后,再依靠个人英雄主义是不行的,那样英雄会累死,项目也会失败。这时候出现的流程和规范都是一种管理的方法。在淘宝UEDblog上看到一句话很认同:设计流程的目标,在于保证“无论谁来做这个产品的设计,都能达到80分”。没错,80分已经很难了,当产品越大的时候,诞生天才产品的概率也就越小。“又快又稳定又有才”的100分产品是可遇不可求的

华为的同学也跟我说过他对流程的体会:流程的好处是人走了,事还能做,减少特定的人的影响。一个事情总是有它的两面,想到一个故事作为结尾:说古代有个名餐馆有幸花重金请到了御膳房的一名厨子,老板毕恭毕敬的请他做一道拿手菜。

厨子:我不会做菜。

老板:啊?

厨子:我只是御膳房“调料部”的。

老板非常失望,转而又想调料也不错啊,很重要,至少能尝到地道的宫廷味道,于是又毕恭毕敬的说:那烦请大师做一份宫廷特制的调料吧。

厨子:这个我也不会。

老板:啊?

厨子:我是调料部“青葱组”的。

老板:……,转而一想,实在不行就尝个宫廷的葱味吧!

厨子:我也不会做葱的全部……

……

厨子:我是负责切葱的……