这本书从图书馆借的，书非借不能读也。断断续续总算看完了，因为本书实在很不错，建议大家有银子的，都去买一本仔细读读，内容很丰富、语言很幽默，还有大量的插图保证你不会疲倦。我个人因为太穷，只能进行书摘，将来发财了，一定买一本，衷心的感谢作者——你对我的思维真的影响很大。

首先放出的是书摘，评论和笔记补充稍后再补充。

原文链接：http:/.csdn.net/downmoon/archive/2009/12/16/5018527.aspx

《2012》放映有些时间了，它引起了人们对人性本身的思索。作为一个普通的项目经理，对这个项目进行了简单的总结和回顾。
一、项目起因：
这个项目起源于全球多位顶尖科学家的一份报告。经过A国总统带领的团队六个月的论证，提出统一结论：地球即将毁灭，人类即将面临最大的灾难，谁也无法拯救，我们只能寻求逃避，最大限度地保存地球的最小缩略图。
二、项目可行性分析：
由A国牵头，在哥伦比亚G8峰会上，由八个国家元首（翻译也不知晓），发起一场“拯救地球最小原始集合”的秘密行动。
1、资金来源：船票收入（起价： 10亿欧元）；
2、保密措施：对所有项目参与人员进行全程监控。
3、施工地点：选在一个封闭、海拔高、易于军事化管理的地区，（可选项：**西藏）
三、项目涉众分析:
1、业主：各国政府知情重要人士，主要提供国家行政及其他资源如土地等。
2、业主二：赞助商，货币。
3、从业人员：主要是工作人员和现场施工人员两大类。
4、项目策划核心小组成员：首席科学家、A国总统及顾问。
5、其他可能知情但已作处理或没能及时处理或已无必要处理的人士。
6、使用者：全体能够在特定时间到达特定地点并且不超出系统负荷的人士。也可能是大象、文字或图像等稀缺资源。
四、项目实施期限：
自即日起，预计到2012年的12月21日。注：项目很可能提前数日甚至数月，越快越好！
五、项目风险规避：
原则是尽可能少的知情者。在此前提下，可以采取任何严厉手段，保证本项目的正常实施。
六、项目测试：
原则上必须进行载人测试。
七、项目总结：
1、由于项目大大提前，测试没有进行。
2、项目进度基本没有延误。主要是前期现场工人的觉悟和执行力。
3、没有从根本上杜绝项目内部管理漏洞，结果差点导致某主要产品—3号舟发生船毁人亡的悲剧。这是本项目最严重的bug之一。系统架构师必须对此意外负主要责任。
4、稀缺资源在任何时候都是珍贵的！要努力成为稀缺资源，比如飞行员、年轻的科学家等。
总体而言，这个项目基本达到了业主的预期。取得了显著的成果，并且对人性的探索做出了意外的贡献。值得一提的是：该项目中涌现了许多可歌可泣的画面，像与国民同生的威尔逊先生，勇敢的圣斗士萨沙，为爱默默奉献的好男人戈登，为了儿子奋力一跃的大个尤里，在风雨中等待命运的地质学家（一直奋斗在科研第一线的知情人士），他们将成为人类遗产的一部分而永放光芒！

原文来自  http://2009seo.blog.163.com/static/7369455520083258405360/ 

感谢作者！

关于豆瓣网的调查分析A

关于豆瓣网的调查分析(一)

什么是豆瓣？

豆瓣网由前某物流咨询公司CTO杨勃于 2005年3月创办，启动资金是杨勃几个朋友共计不到20万人民币的天使投资，以独到的书评、影评、乐评主题社区著称，因为开创了国内Web2.0新模式 而闻名。从构想到技术实现均由杨勃一人完成，业内对此有“一个人的豆瓣”的评价。豆瓣的得名来自于杨勃曾经居住的北京朝阳门附近的豆瓣胡同。

（一）alexa数据 (使用2009年11月24日星期二最新数据截图，原资料为旧的)

1.alexa排名：1699（3月平均）

表一：6个月排名数据变化表

2. 每百万用户登陆数：391（3月平均）

原文来自：http://youliguo78.blog.163.com/static/39861459200801701545956/

由利国的博客，我增加了一些图片、说明、点评，在此感谢原作者给我们提供了这么好的资料！

douban.com非常精巧的应用了div+css，并且通过色系的运用，最大限度减少图片等等方式既使得网站页面清新可人，而且可以最大限度的压缩了网页的大小，从而使得访问的效率得到了最大化。

图一 豆瓣网、某大型网站、某sns网站首页文件大小对比

图二 豆瓣的packed_douban48.js与某网站的js文件结构对比，可以发现豆瓣的js是经过字节压缩的

之前写过如.何处理“老板.说”，但是大家在实际突发事件中，对于老板的封口气势仍然难以招架，如果真以走流程之类的言语挡回去，自己都替.老板火冒三丈。特举出下面这种情况，跟大家说说应对上的一些策略。 .

场景：周末 你正在家裸奔

事件：老板电话 告知他的一个i.dea，需要你处理 .

通常同事们的应对方式：

回答一： 您这需求还有好多地.方没细化，.数据没验证，做不了。。。。 .

（老板后遗症：唉！我的人效率真低，水平.太差。。） .

回答二.：.%……&￥@#， 哦，啊。。嗯，咳！。。 *&￥&………R%。 （脑子里一锅浆糊，老板的事必须做，老板没让我跟别人说，先做了看吧） .

（老板后遗症：马上就能做，看来我的人平时太闲了。做出来乱.七八糟，跟我讲给他的完.全不靠谱） .

应对方法：

电话中：

1. 听明白老板要做啥，问清楚做的.原因 .

2. 围绕老板.的目的，丰富讨论。婉转地补充和归纳实现中老板没想到的、想错的地方。另外，建立老板对你承担任务能力的信任. ：） .

3.. 电话中不.要轻易决定动手。越有价值的feature，实现绝不是很简单的事。所以你们的讨论，也只是刺激思路、发现问题的充分拓展。实现的时候没有备忘.录，是不可能没有遗漏的。 .

4. 讨价还价。 如果你不敢拒绝老板什么都答应.的很顺利，那么换个角度，你是老板的话，会有个什么印象。这个人现在有时间。。。 这个人现在是闲着的。。。 这个任务很简单.（也就是不.费功夫）。。。.进而。。。 ，进而就是，你在实现中没有退路！即使你很忙，也许让老板觉得你能接临时任务，又不影响其他工作，那肯定是工作量不饱和！ .

电话后：

这里是不能偷懒的。表现.你重视老板的需求，就要仔.细想想老板交待的事，在纸上、白板上、文本工具中整理下， .

你设计的实现方案和过程，与老.板需要的对比 .

看看疏漏和必须细.化的地方，坑有哪些 .

能实现的程度和质量，需要花多少工夫，.影响到手头上的哪些工作. .

需要通知到谁，或者需要谁协助你给你些.输入，.帮你分担些啥，哪些是哪些协作角色该做的。 .

整理好以后，写成邮件发给老板， 抄送给你想到.的那些同事。 ..

想想这样做会获得什么？

最重要的：为自己争取到了.执行缓冲时间 .

从 老板那里： 获取确认和.肯定。老板大都是具备.煽动演说能力的人，也许是他情绪膨胀，文字.能让人冷静。也让他看到你是认真的，还能帮他组织实施。记住，老板只给 idea是很正常的，要不花钱雇我们干啥。实施能力的强与不强，就在于你是.能组织运作整个事，还是只是貌似很reasonable地做驴。 .

从相关同事那里： 稍微大点儿的公司，产品实现可能就分成产品角色、开发角色和维护.角色。很明显，完.成这件事，不全是你的职责。但是老板只讲给了你怎么办？ .

如果你能完整并周全地传递.给协作同事，他们也会承担份内之事，他.们会增进对你的信任，喜欢与你的沟通； .

不如其他同事专业的地方，同事也会给你反馈.，帮你确认方案.； .

还有些事，可能根本是老板.的头脑发热，与你的同事讨论过与现有计划有冲突和弊端，没准.你的同事就帮你把这事挡了。。。。 .

坚持对每一次这样的突发事件使用相同的方法，如果你的老板让你做特紧急或者特秘密的行动，他会习惯地嘱咐：这件事一定要..马上做。。。其他事你先放放。。。 不.要告诉别人。。。。！@ .

照顾好自己，理.解老板、理解同事，协调，协调！

http://www.cnbeta.com/articles/95745.htm

最近看了一些讲腾讯产品管理体系的文章，虚实都有，恰好有个同事以前在腾讯工作，能提供第一手的资料。于是今天下午开了1小时会议，专门讨论腾讯的管理之道，发现有这么几点处理得很好。马化腾带着一大批产品高管自上而下，持之以恒地推动产品本位的管理体制规范化，并不断地创新和优化这套体制，使得整个公司上上下下融入了“产品的基因”，最终成就了“产品的腾讯”。 1、 设置一个质量监控小组，由经验非常丰富的高Level的产品人员构成，赋予他们很大的权力，去监控和规范所有的产品项目。并且用KPI来制约产品项目服从 这些规范。为了不搞教条主义，很多规范都是在立项之初，由项目经理和这个小组共同确认的，未必是硬性指派，一经确认就受到严格监控。确保好的规范不流于空 喊口号。

2、每个产品都设置公开的反馈论坛，突出外部入口，积极征询用户意见，并以内部轮班方式回复“每一条”有价值的反馈，要求以“人对人，面对面”的沟通态度 来进行解答，禁止机械问答。公司高层（包括小马哥）不定期巡查每一个产品论坛，一旦发现有不认真回复用户的情况，立即予以训诫。确保产品人员与用户长期保 持近距离接触。

3、每个产品都设置内部的交流平台，分为两部分，一块类似留言板，由产品主管发布项目的进度、动态；另一块是论坛，向公司内部所有人开放，接纳反馈。在腾 讯内部已经形成了非常活跃的氛围，甚至以该平台人气高涨为荣（至少你主管会喜欢这个），利用这个平台跨项目提意见，或是项目组内部交流思维碎片都很常见， 达到了群策群力，内部监督的效果。

4、设置产品架构师这样一个职位，由少数几个技术精英，负责所有项目的系统架构搭建，只搭架构，确保每个项目的底层合理性。

5、执行项目总结制度，在每个版本上线后，由相应的策划-开发-测试人员开一个会，每个人都总结在这个版本过程里，有什么心得，有什么失误，可以怎么改 善，尤其注意改进三方人员的配合过程。用制度的方式来强制反省，强制跨职能沟通。几个版本下来，项目效率就会有明显的提高。

6、执行灰度发布政策非常之彻底，一个版本会经过若干级的内部测试，再向外部用户逐步放量升级，不断修正问题之后，最后进行大规模发布。确保提前发现问题，受影响的用户面尽可能小。与此同时，腾讯异常活跃的内部交流氛围，也能让产品在内部测试时得到较多专业反馈。

7、拥有背靠客户端，强大的数据挖掘功能，具体描述起来比较复杂，总之非常强大，数据细致到令人吃惊的地步。数据挖掘部门的地位也是相当高的。我以前说过“统计数据太单薄无法推导出可靠结果”这样的话，但在腾讯的数据挖掘机能面前，这句话恐怕要改口。

8、设置对新人和新项目的风险管理机制，比如3个老程序员带1个新程序员，将技术管理和具体开发的工作彻底分离，每周进行代码走读，对新产品采取格外严格的测试安排等等，使得缺乏经验带来的技术损害被降至最低。

其他还有一些大路货的东西，一些理想化的不可靠的东西，就不讲了。令我感慨并且佩服的，就是以上八点。不是佩服腾讯能做这八件事情——要说想法，我都能够 想到，我也有自己的一套项目管理团队建设的技巧。但腾讯从公司层面，从最高领导人的层面，身体力行地把产品管理的专业准则给贯彻下去，用多种监控手段来避 免其放空炮，令产品管理制度化，体系化，好的经验在内部流通开来，成为一种积极向上的约束力，带来整个大产品团队的合力，而不是任由项目经理各自摸爬滚 打。马化腾带着一大批产品高管自上而下，持之以恒地推动产品本位的管理体制规范化，并不断地创新和优化这套体制，使得整个公司上上下下融入了“产品的基 因”，最终成就了“产品的腾讯”。