【3017】又到一周周报时

又到周五了,意味着大家又要开始憋周报了,从@纯银的一个段子开始——

公司有个技术牛人,某产品专员向他提单,牛人一看内容很扯,质问“你觉得这个需求有价值吗?”对方诚恳回答:“没价值,但是我总得写周报啊。”牛人想了一分钟,回答说好吧我帮你做,因为我也得写周报啊。

我想,看这个博客的人,基本上都要写周报吧,更有甚者估计要写日报,但多少人打心底里觉得写的周报没有意义?只是为了写而写?今天,不妨从两个方面,简单说说,如何让周报真正的有意义。

第一个话题:写什么内容。

这个万变不离其宗,其实和敏捷里的站立晨会是一样一样一样的。形式不重要,说清楚3件事即可。

本周做了什么:重点不在于做了什么,而是拿到了什么结果(有共识的)。举个例子,花了半天时间和谁谁开了个什么会不重要,重要的是会上做了什么决定,会后定了什么后续的行动方案。

下周要做什么:同样,重点在于希望拿到什么结果,推进什么事情。不要是“继续优化Q2的产品规划”这样虚的东西,而应该是“与某某老板讨论Q2产品规划,并达成共识,从而下下周可以启动某项目”。

碰到了什么问题:怎么去尝试解决,搞不定的需要什么资源,打算找谁,打算让老板或同事怎么帮你。

然后,针对你的工作内容,细化一下,比如分为“项目、日常需求、其他”几个模块,有的时候再加一点工作感悟,也挺好,比如我,就是从每周500字的感悟渐渐写出一本书的,:)

第二个话题:发给谁。

可能有人觉得这个没啥可讨论的,传统上,周报不就是汇报工作(说白点,方便老板汇总周报)么?发给自己的主管不就行了么,我觉得这是最傻的,这大大浪费了“写周报”这个及其费脑子的工作。

稍好一些,周报可以发给主管和团队同事,团队里的人互相了解都在做什么,可以便于工作展开。

更好的,周报应该发给主管、团队同事、下属、以及有干系的合作方(其他部门的人),并且酌情区分“To”和“CC”,这才是真正的信息流通,发挥最大价值。愿意把周报发给下属的主管是好主管,:)

这位说了,周报里有敏感的内容啊,不方便发这么多人……我说两句:第一,互联网的精神就是开放共享,再想想,你觉得敏感的内容,是不是真的敏感;第二,稍稍做点技术处理,很简单的,可以共享的内容发给所有人,实在敏感的内容,在邮件上再回复一下,补充给对应的收件人好了。

要不,改变从今天开始?

产品设计体会(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了。。。