人人都是产品经理——iamsujie

为什么要说严肃版呢？因为之前发过一批不严肃的，猛击此处围观。

放3张，下面开始：

那个，虽然图里已经有广告了，是不是还给个链接呢？太纠结了，算了，还是再给那本“励志的专业书”加加人气吧~~~

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

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. 下周一团队临时解散一天，下周二集合发布，谢谢大家。

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

老板项目，就是指老板突然跟你说，我们要做个什么什么，然后你只有执行的份儿……的项目。什么，你们公司所有项目都是老板项目？很正常，那我们更应该聊聊这个话题了。

先来一点科普，做项目的目标无非是多快好省：范围多、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板也都明白这一点，所以我们通常是在上述4个要求中做平衡。对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎一样。一点区别就是Q，我觉得Q = Quality+Quantity更准确，质量这个词其实包含了“品质”和“数量”两个含义，而我所经历的项目，Q更多的是表达Quantity，一般来说，品质高这点是不会舍弃的（不排除有特殊场景），所以可变的是项目范围。

综合一下，我们做项目就是在时间要求、人财物花费、项目范围三点上做平衡，不妨就继续叫做TRQ吧。

来一个真实场景回放：“你突然被老板叫到办公室，他和蔼可亲，又情绪激动的对你说，小某啊，组织上有个重要项目要交给你，blablabla，省去半小时，这都不关键，最后一句：某月某日之前一定要发布！”似曾相识？嗯。首先恭喜你，通常这样的“老板项目”都是重要的项目，说明老板信得过你。然后你要反驳了，恭喜什么啊，我牙还没刷呢，连做什么都不知道，居然TRQ的T已经定了？！

是的，当时就是这样。

传统项目管理中的那一套，先需求，知道要做什么以后，再组织协调资源，最后推算出时间计划，在这里跑不起来啦。我脑中突然浮现一句话，改编如下：做项目，特别是老板项目就像被强奸，与其无畏的反抗，不如好好享受。

于是，阿Q的我们找到了理论支撑：Agile，敏捷！不是么，更多的时候我们都是被动敏捷，或是被老板逼的，或是被用户逼的，或是被对手逼的……人类的本性应该还是恐惧变化和不可知的吧，不知有多少人看到这里内心在呐喊——我爱瀑布模型！

所以有公司在价值观里宣扬“拥抱变化”真是很积极的一种人生态度。那我们来拥抱敏捷吧，看看在TRQ三方面应该如何享受：

T是给死的，可以试着商量一下，但一般很难改变，如果是老板的老板给老板定的，那就更甭想改了。通常，每一级任务的下放，老板都会给自己留一小段时间做缓冲，但是我们可千万不要在定项目计划的时候算上老板留给自己的这段时间，反过来，我们订计划的时候应该再给自己留一段，这些都是最后救命用的。

Q是可变的，先说Q，一般越大的老板给出的指示越战略性，越不具体，所以具化出来的Q就可大可小了，所以开始的时候，尽量发挥自己的聪明才智，先天马行空的爽一把，把Q搞大搞大搞大，并合理的算出一个巨大的R，然后，你就可以欣赏到老板因为无法付给你这么多R而自己砍Q的表演了……当然，我们应该尽职的帮老板排出各种功能的建议优先级和所耗资源，好让老板知道刀该往哪里挥。

R是丰富的，老板项目么，第一优先级，R就是大大的有，其他项目统统让路，让多少路，这个问题应该抛回给老板决定，我们只提供专家意见，狮子大开口：让的越多越好！记住，千万不用在这个时候就帮老板着想，应该怎么节省R，那样反而不讨好，老板会觉得你思路不开阔，没劲，我有过一次做了个项目方案，十几个人就搞定，沾沾自喜，结果老板说：你先给我照着100个人做这么久来规划。

真的这么爽？

当然不是，有时候你发现，老板比较猛，Q都帮你想好了，那只能说没劲，也别废话了，甩开膀子干活呗。更悲剧的是，R也是不足的，就那么几棵人，又要在固定的T下做这么多Q，绝望？不至于，我们还有最后一招IT民工必杀技——加班，天天加班，天天加班还不要加班费……我们期望的是老板看得到，公司有前途，明天会更好……

如果这样还做不完，那只能说——老板丧失理智了！兄弟，撤吧……

最后谈谈，老板项目到底好不好？从个人角度，如果是纯项目经理，这就是本质工作，无所谓好坏，而对于我们这样做产品的同学，老板项目没有成就感（有成就感的项目是自己去做用户/市场研究，然后发现问题，发起项目），而好处就是接近老板，无需多说；从老板/公司角度，效率高，决策风险大，其实，这和民主与专制的区别是很像的。

回顾一下2007经历的5个项目，成功或失败在不同的阶段。

先简单描述软件项目的生命周期，其他项目也应该大致如此：战略规划，需求分析，开发，测试，上线，运营维护……加深体会了一个基本常识：问题出现的越早，越早调整项目规划，损失越小。

第一个是在压力测试阶段怎么也过不了，无法发布。我不是技术出身的，所以具体原因也不太清楚，感觉问题应该是出在系统设计上，测试的时候功能都跑的很遛，但模拟数千人同时使用的时候始终很慢，改了几个礼拜仍然没法解决，最后由于人力资源的问题，和考虑到这个项目的重要程度，只好把项目砍掉。

第二个是在需求分析阶段结束，因为集团的政策因素，项目转移给别的团队做了。这次可以说是完全不可控的，也让我加深了对“项目发起应该是‘从上到下’”的认识，无论哪个项目，没有上层强有力的支持完全就是白搭，而且自己努力很多会觉得很失落。

第三个是在市场扫描阶段结束，收集到的信息让我们觉得不值得继续做下去。一句老话：早一步是先驱，再早一步是先烈。

第四个算是成功了，发布升级、运营维护一整套走完，这个项目从2006年底开始一直到现在，现在我也逐渐移交给同事，大家会继续做下去。这个项目是让我学到最多的，特别是到了项目上线以后，还有很多事情需要做，比如和客服、技术支持、财务以及其他在商业上合作部门的协调；对产品整体调整的需求管理；等等。

（iamsujie补充：这个产品在2008年，几乎没有投入的情况下，帮助公司其他产品吸引了不少用户，而且自己也有几百万营收，很不错）

第五个是和外部合作的项目，这是个非常牛B但挑战也非常大的项目，因为一些我无法控制的原因，不太顺利，最终延期了将近半年发布，而且也无法满足最早的商业目标，我做项目协调人学到了很多项目管理方面的知识，仅此而已。