人人都是产品经理——iamsujie

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

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

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

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

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

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

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

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

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

第二个话题：发给谁。

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

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

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

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

要不，改变从今天开始？

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

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

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

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

发送时间：2009年3月23日 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，项目进展汇报：

发送时间：2009年3月24日 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，项目进展汇报：

发送时间：2009年3月25日 20:19

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

1. 开发；

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

2. TC评审；

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

3. 相关事宜的跟进。

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

b) 服务同学修改帮助；

c) 某某方案制定，原则确认；

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

e) 培训事宜跟进。

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

发送时间：2009年3月26日 19:52

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

1. 开发：

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

2. 测试：

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

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

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

发送时间：2009年3月27日 18:04

Hi all，今天是项目的第五天，进展如下：

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

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

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

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

项目中，测试最开始一段时间，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，之后的状态改变，可以用下图表示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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