产品设计体会(3016)一个只有七天的项目

为了写书,我在翻看几年来的邮件,找到了一个只有七天的项目,光从项目日报里,就让我觉得那几天奋斗的时光恍如昨日:

2009323日星期一,我接到一个任务,说为了配合331日下周二的新闻发布会,要做一个项目。我做过不少这种救火队员式的任务,每次开始的时候老板总能让我的嘴张成一个O型——这怎么可能么,但结束的时候我们也屡次让老板的嘴张成O型——居然真做到了!

一大早接到任务,迅速的四处找人组建临时团队、制定时间计划、讨论项目方案……我一直是反对加班的,但在这种情况下,晚上晚点走也是不可避免的了,不过,我的计划中仍然留了余地:争取周五完成上线的准备,周末尽量不加班,下周一机动。我们直接看邮件来感受一下当时的情况吧。

主题:第1/7天,魔方计划2.0,项目进展汇报:

发送时间:2009323 21:16

Hi all,项目一共只有7个工作日,一切从简,尝试自由体日报。

今天主要进展如下:

1. Kick Off完成;

2. 项目范围与方案确定;

a) 数据提取与分析,确认项目方案(详见附件);

b) 某功能决定免费,账号数上限取消;

c) 魔方计划1.0遗留问题加入项目:更新帮助、修改“新手上路”、替换首页广告及链接;

d) TK(业务有关,不便透露,用字母替代,后面还有一些类似的。)相关问题另起项目,3月31日之前只对用户做告知。

3. 需求写作;

a) 附上PRD,明早评审。

4. 团队组建;

a) 开发同学(某某某、某某)搬到8楼,大家集中办公;

b) 测试资源在明天需求评审完成后确认。

5. 知会周边干系人。

a) 某某搜索引擎某某某

b) 某某产品:某某、某某某。

明天重点预告:

1. 需求评审;

2. 进入设计与开发。

主题:第2/7天,魔方计划2.0,项目进展汇报:

发送时间:2009324 22:44

Hi all,今天是项目的第2/7天,晚上大家辛苦,感谢肯德基全家桶的支持,进展如下:

1. 上午需求评审 & 确认完成;

a) 下班时需求冻结,终稿见附件。

2. 下午进入开发阶段;

a) 只有16工作小时,周四中午提交测试;

b) 明天下午TC评审。

3. 测试人员确定;

a) 某某 + 半个某某某,可能需要周末加班,先说一句辛苦了;

b) 存在人员不足的风险,随时监控,周五晚、周日晚为两个监控点。

4. 相关事宜的跟进。

a) 财务同学跟进修改用户协议;

b) 服务同学修改帮助;

c) 某某方案制定;

d) 培训事宜跟进;

e) 配合运营整理MF与TK的材料。

主题:第3/7天,魔方计划2.0,项目进展汇报:

发送时间:2009325 20:19

Hi all,今天是项目的第3/7天,进展如下:

1. 开发;

a) 晚上部分功能提前半天提交测试,感谢同学们的努力。

2. TC评审;

a) 来了6位测试的同学把关,感谢大家的支持。

3. 相关事宜的跟进。

a) 财务同学修改用户协议,周五下班前提交;

b) 服务同学修改帮助;

c) 某某方案制定,原则确认;

d) 配合运营整理MF与TK的材料,某某某负责制作页面;

e) 培训事宜跟进。

主题:第4/7天,魔方计划2.0,项目进展汇报:

发送时间:2009326 19:52

Hi all,今天是项目的第4/7天,进展如下:

1. 开发:

a) 全面提交测试,据测试同学说质量不错,感谢大家;

2. 测试:

a) 截至下班时,比计划稍有领先约1/3工作日;

目前一切顺利,但项目时间已经过半,更加容不得任何闪失,+U+U~~~

主题:第5/7天,魔方计划2.0,项目进展汇报:

发送时间:2009327 18:04

Hi all,今天是项目的第五天,进展如下:

1. 第一轮测试完成,Bug全部修改完毕,等待下周二,配合新闻发布会上线。

2. 周末测试的同学会加班再测一轮,其他人员待命。

3. 下周一团队临时解散一天,下周二集合发布,谢谢大家。

之后的周末没有碰到大问题,第六天空出来了,第七天的发布也很顺利。这是我喜欢的风格,先紧后松,但,又有多少次能这么幸运呢。

产品设计体会(3015)项目中Bug的一些事

项目中,测试最开始一段时间,Bug总是不断的蹦出来,Bug指缺陷或故障,区别在于项目发布之前发现的叫缺陷,项目发布之后发现的叫故障,通常故障会对用户造成伤害,团队里也制订了相应的惩罚机制。这次不妨从Bug的角度来说说项目,下图是我们使用过的一份Bug级别定义,一般来说对一个Bug的描述有以下几个关键点。

bug级别定义

缺陷级别(Severity:即上图中的5级别定义,一般大于等于III级的Bug被认为是严重的问题。

所属产品、项目:有的人需要同时处理很多产品、项目,这个属性可以用来筛选。

Bug名称:一个短句,此Bug的简单说明。

Bug描述:写成如下形式,“执行某操作,期望出现什么情况,实际出现什么情况”,还可以添加截图、文档等附件。

其实其他属性还有很多,不过我觉得非必须,经常不填,也就不说了。

我们的测试过程使用了Mercury Interactive公司的Quality Center来管理,它是一个基于 Web且支持测试管理的所有必要方面的应用程序,更小的团队,用Excel来管理Bug也未尝不可。作为PD,也是会经常提Bug的,PD做测试的时候主要是模拟用户的身份使用产品,而测试人员会更多的按照TC执行。当发现一个Bug以后,我们会提交给相应的开发工程师,如果认为是需求问题也会提交给对应的PD,这时候Bug的状态为Open,之后的状态改变,可以用下图表示。

Bug状态流转图(图中defer拼错了)
Bug状态流转图(图中defer拼错了)

收到OpenBug,确认并修复,状态变为Fixed;否认,也许提出者理解错了,也许不打算修改,状态改为Rejected;或者认为不是自己的问题,可以把Bug转交(Assign to)给别人。

测试验证状态为FixedBug,没问题了就Closed,否则可以Reopened。看到RejectedBug,发现是自己理解错了,就可以Closed,仍然认为是Bug的可以Reopened。对于DeferredBug,意味着本项目中暂不修正,可能是因为技术做不到,时间不允许,性价比太低等,必须慎之又慎,通常由能负责的人,比如是测试经理、项目经理最终同意才Deferred

整个过程中,Bug的每次状态改变都可以添加注释说明,我们更鼓励有争议叫上当事人面对面的交流,而不是在系统里不停的纠缠。

到了项目发布之时,我们要求所有Bug的状态必须是Closed或者Deferred,当然对III级的Bug,有时候并没有这么严格。

使用Quality CenterExcel的好处,在于每个Bug重要的状态转换点,系统都会有邮件通知到相关人员,防止遗漏;项目中每个人在系统里的角色不同,权限不同,防止误操作,甚至一些恶意行为,比如开发人员就不能把Bug状态改为Closed;所有操作都有记录,谁在何时做了什么,便于追溯。这些都有效的防止了人为因素导致的问题。

PS:很久都不发带图片的文章,是因为picasa,我终于打算放弃,转投flickr了。。。

产品设计体会(3014)敏捷实践的一些过程项

上次说到了我们在项目中“敏捷沟通”的实践,顺着再补充几点项目过程中的敏捷实践。

任务认领,我们没有完全实施,现在是利用开发经理对工程师能力的了解安排任务。任务认领的假设是:每个人都是足够聪明和职业的,应该被安排在最合适的工作上,所以最了解自己能力的就是自己,于是应该每个人制定自己的工作计划,其他人帮着定都是不优的。相对而言,任务认领更适合工程师文化的特种部队式团队,比如Google

需求评审,有的团队在需求评审会的时候,让开发工程师来讲述他要开发的那部分功能的PRD(含UC),PD来提问。对比更经典的PD讲述,开发提问的方式,这样做有两个好处:一是逼着开发认真看PRD;二是可以省去设计评审,相对PD讲述PRD的传统方式而言,开发讲述的方式下,不做设计评审的风险降低。

结对编程,我们还没魄力尝试,相信国内也很少有团队敢尝试。一位开发经理对我说其本质是两个人互相监督,没法偷懒以提高效率,更重要的是,这种效率的提高还伴随着代码质量、可读性的提高,从而完全可以抵消表面的“做事的人少一半”带来的损失。

测试驱动,我们有很强很严谨的测试,会利用TC编写、TC评审、甚至测试执行的过程来补充和细化需求,比如一些限制条件、异常流程等等,往往都是测试的同学提出来的。

冒烟测试,编码完成后,测试的同学会马上做冒烟测试,目的是确认产品基本功能正常,可以进行后续的正式测试,冒烟完成后立即进行产品演示会,叫上项目干系人来查看产品是否符合期望,符合“尽早交付”的概念。

关于加班,我一直让开发经理、测试经理评估资源的时候留一点余量,甚至我在排项目计划的时候会再留一点,但每次看上去仍然还是在加班,也许是大家不习惯一下班就走,反而喜欢上班时不时看会新闻,晚上时不时做点工作的方式吧,不管给多少时间,任务总是在最后一刻完成,呵呵。

你在的团队有什么好的实践么,不妨也说出来给大家看看。