Misc

丁丁历险记，恐怕很多人都会想到这部动漫吧。
居然也出了电影版，如果不知道丁丁历险记，那就是没童年的孩子。90后除外

BOSS在微博问有谁想去看，结果全公司的人都说要去。于是乎，包场了。。
准备周六去看，因为要带小孩，公司还特地发的中文版的票子（HOHO）

那天看了预告片，感觉特效什么的和以前的忍者神龟差不多，嗯非常满意。
丁丁，我来了

文抄公是一种鄙视，事实上有很多时间我们都在做着文抄公的事情。嗯，我也是一个文抄公。仅此而已
抄是一种美德，抄是一种文化，天下文章都是一大抄，无非就是你抄我我抄你的，几年前的黄夏留老师也说过，当全班同学都在抄的时候，只有一个同学没抄，他的名字叫杨伟。
好吧，这仅仅是一个笑话。
互联网上的东西，确实抄来抄去的比较多，但怎么着也得给对方留一下链接，代表了文章的来源。你摘抄了没错，但也不能否认别人的辛苦劳动。如果大家都只抄内容不抄链接，这终将是一个恶性循环。
事实上，很多人在抄的同时，都放弃了原作者原内容的样式、风格，甚至连内容都有放弃，这个时候你让别人在看到你的文章时怎么想？
给别人留条后路，也给自己留条路。

看到这里的时候，又有点感触。
事实上现在就处于这种情况，想找人的时候找不到，不想找人的时候，面试的人一大堆。
可是你说真要拿来做人才储备吧，可能几个月都用不上他，那时候更纠结。

OK，看看rework中怎么说：

应付不来的时候才雇人

不要在高兴的时候去雇人；雇人是为了解决事情。重复的问自己：如果我们不雇佣任何人又怎样？那些让我们烦恼的加班是否真的有必要？我们能用一部分软件或者改变一下业务来解决这个问题吗？如果我们不这样做又会怎样？

同样的，如果你解雇了某人，不要立刻找人来替代他的位置。 看看你没有了那个人和那个职位可以撑多久。你会发现其实实际上不需要想象中那么多人。

雇人的正确时间是你顾及不过来的时候。你不能再做更多的事情，发现产品质量在下滑；当你苦恼的时候就可以雇人了，不能太早。

割舍那个你并不需要的牛人

有的公司对雇人乐此不疲。有的公司在不需要雇人的时候都在招聘。他们听说某某很厉害，于是造出一个职位和头衔吸引人家入伙。结果人家来了，坐上一个不重要的位子，做些不重要的事情。

别管那些你不需要的人，就算你觉得那个人是个牛人。 如果你引进一个做些无用功的人才，那这样对你的公司来说是有害而无一利的。

问题出现在你有超过需求的人员。你开始弄出点工作好让这些人忙起来。人为的工作导致人为的项目。而人为的项目导致实际成本和错综复杂的状况。

不要担心“错过了那个人”。让一个人做些没有意义的事情会更糟。天底下有那么多人才。当你真正有需求的时候就会找到一个合适的人选。

牛没什么用。如果你不需要人，那你就不需要雇人。

这是其中一段，事实上在很久以前就知道了，但最终都无法改变
里面的一小段说的很有意思，那就是，会议会衍生会议，。。。。

OK，上原文：

会议有毒

会议是最糟糕的打断方式。原因是：

通常会议只是文字和抽象的内容，没有实质。

通常会议每分钟只传达出极为少的信息。

人们在会议中容易跑题堪比暴风雪里的芝加哥出租车。

会议要求做充分的准备，但是大多数人难以做到。

频繁的提出模糊的议程而没有人能真的清楚目标是什么。

常常会出现至少一个傻瓜不可避免的，毫无意义的浪费大家时间。

会议会繁殖。一次会议会导致另外一次，再生出下一次......

不幸的是会议典型的时间表就像电视节目。

你腾出 30 分钟或一个小时因为那是软件安排的行时间表（ 你决不会看见任何人安排 7 分钟时间和 Outlook 开会）。太糟了。如果只是花 7 分钟时间就能完成会议目标，那这就是你所要花的所有时间。别把 7 分钟拖到 30 分钟。

想想看，会议所花费的真实时间是惊人的。 假如你准备安排一次会议持续一个小时，你请了 10 个人到场。那确实是 10 个小时的会议，不是一小时会议。你用 10 小时的生产力换来一个小时的会议时间。也有可能花超过 15 小时的时间，因为要停下你正在做的事情，需要精神转换， 去哪里见什么人，然后再重新开始预先在做的事情。

花 10 小时生产力去换 1 个小时的会议可以吗？有时，也许可以。但这样真的不划算。 就基于付出的来说， 这种规模的会议很快就变成一种不利因素而不是有力因素。 想想你浪费的时间，值得吗？

如果你执意要聚一下，试着坚持以下原则会让你的会议有成效：

用计时器。当它响起，会议结束。句号。

尽量减少与会人员。

保持清楚的议程。

开篇点题。

就地解决。指出实际问题，提出实质改变。

作出结论，找个靠谱的人去执行。

最近很多人提到了《rework》这本书。
嗯，我最早是在劣头翔的博客（黑暗代码界）上看到了这本书的介绍，开始以为是关于网站重构啊或者什么其他的，可是打开了之后才发现这是本关于创业的书。
嗯，其中有些话说的真靠谱：创造一款伟大的产品或者服务的最直接、最简单的方法就是去做你自己想用的。这会让你设计出你所了解的产品，并能立即明白你做的东西是否靠谱。

本来还在慢慢看呢，coolshell上面也有介绍（http://coolshell.cn/articles/5815.html），它是这么说的：好吧，让我再回到创业的话题上来，有一本书叫“Rework”，想创业的朋友可以好好读一读。 “保持 小的公司规模，你不需要加班，你没有必要耗尽你一生的积蓄，承担财务风险。你可以一边继续日常工作，一边开始创业，这样随时都能有现金满足需要。你甚至不 需要办公室。现在可以在家工作，和从未见面离你千里之外的人合作…… ” 这是一本让你可以去思考的书，远比那些名人们的微博有价值地多得多。不要跟随大流，保持住内心的理想，Think it Big, Make it Different。

好吧，既然这样，那为什么不好好看看这本书呢？
http://www.v2ex.com/rework，这里有在线版，v2ex，这个站，你们总熟悉的吧，曾经国内一直被墙的站点之一。套用一句老话，判断一个站是否知名，就看它有没有被墙过。
我的站从未被墙过，所以，它是不知名的。这点，我确认

其实关于产品驱动和技术驱动，历来就有很大的讲法。产品驱动最大的隐患就是时间，技术驱动的话，一个原型很有可能就能够拿来卖钱，产品驱动，从原型到可运行，其中的时间也是很长的。

第二个就是产品驱动和技术驱动中，技术人员的地位问题，在国内的很多公司时，技术人员的地位其实是很低的，产品驱动在国内还算是好的，更多都是业务驱动。 业务驱动比产品驱动又狠一点，业务可能时时会变，甚至连一个产品线的时间都一定准确。国内很多小公司都是这样的，其实很多大公司也差不多是这样处理的，也 就造成了技术人员在疲于奔命，如果你硬要解释，领导的话可能就是，这么一个改动能给公司带来几十万的收益，你改不改？哭泣中。。。。。。

OK，下面是转来的内容：

公司的运行方式有两种：“产品驱动”和“技术驱动”。

国内甚至国际上绝大部分的公司都是“产品驱动”型，它的运作方式是这样的：公司高层负责“战略布局”，只提出需求“我要个什么东西，能实现 什么功能”，然后给出一个时间点，要抢在什么什么时间点上线这个项目。如果有现成的团队，那么由这个团队去完成，如果没有，那么招人或内部调整组织起来这 么个队伍。队伍里会有产品经理和项目经理，产品经理负责设计工作的把控和对产品的收益负责，也就是说，由他来对这个产品的经济效益扛KPI。项目经理负责 开发团队的日常进度管理，协调资源分配开发任务什么的。产品经理和项目经理虽然同称为“经理”，但事实上，产品经理是公司高层和开发团队的扭带，公司高层 并不会关心开发工作的细节，他们只会跟产品经理衔接，对于开发团队来说，产品经理是公司高层的代表，是项目需求方，而且他对产品的经济效益扛KPI，所以 产品经理其实权力非常大！

但产品经理通常都没有技术背景，他们不懂技术，也不懂工程师文化，不知道工程师对什么在意，他的思想集中在“商业”和“产品设计”上。项目经理的职责是对 项目的进度进行把控，他其实是很需要“软件工程”方面的知识的，如果项目经理靠谱的话，事情也好办，但往往项目经理大多数对“软件工程”其实并不太了解， 项目经理往往是“技而优则仕”提拔起来的，也许“开发”能力过得了关，但“开发”和“管理”是两码事，“软件工程”之所以能独立成为一个方向，正是因为其 重要程度已经达到了一个不可忽视的地步——上世纪六、七十年代的软件危机，就是因为缺少“软件工程”方面知识的指导而暴发的。

项目经理对“软件工程”的知识欠缺导致的问题就是：公司高层习惯了指定一个粗略的项目需求和一个时间点，而产品经理接受这个任务，一方面对项目需求进行进 一步的详细设计并定时向高层反馈项目进展，另一方面对开发团队提出详细的产品需求。开发团队接受开发需求，在项目经理的带领上进行实际的项目开发。这里有 两个问题需要重点关注：“时间点”和“产品需求的详细度”。“时间点”是由公司高层决定的，他们习惯了这样的方式，而“产品需求的详细度”是由产品经理控 制的。我们知道软件开发的几个步骤应该是“提出需求-->概要设计-->详细设计-->编码-->测试-->发布”，理论 上在工程师“编码”之前，产品人员应该把“详细设计”的工作做完，“项目需求的详细度”应该非常高，项目进入编码阶段，需求就不应该再改动了。但稍有经验 的工程师都知识，产品人员不会也不可能会在项目进入编码阶段前完成详细的设计，他们总是会不停地进行修改。理想情况下，项目经理应该会很懂“软件工程”， 为了保证项目进度，他们会对开发团队做出一些保护，阻止产品人员在项目开发过程中修改需求，就算无法完全阻止，至少会做一些措施，提高产品人员修改需求的 门槛——比如说，修改可以，但时间点要重新预估。也就是说，“时间点”确定的前提下，“需求的修改”就不能那么随意，必须有一套合理的游戏规则平衡“高层 管理”、“产品经理”、“项目经理”、“开发团队”各种角色的责任和权利。但实际情况是，产品经理权利过大，项目经理往往无法保护开发团队，更有些甚至不 懂去保护开发团队，只会“拿鞭子抽”，成了一个监工的角色。开发团队于是成了埋头干活，却几乎完全没有话语权的编码机器人。时间点确定了，需求不停地改， 监工不停地催，代码在一次次修改中越变越腐坏，只好不停地加班，期望通过延长工作时间这种原始的办法来按时完成开发任务。结果就如大家所熟悉的那样：开发 人员抱怨产品人员需求老在变，代码越变越糟糕满是bug，产品人员抱怨开发团队不能按时交付高质量没bug的产品，开发团队加班严重，人员流失严重，项目 组成员不停地更替，交接工作不可能完美，新人且对历史遗留代码头疼不已，项目开发前快后慢，维护成本越来越大直到某一天，某人实在受不了了，大喊一声“重 构吧”。。。

上面提到的画面大家一定很熟悉吧，没错，这是“产品导向”的公司的基本行态。产品经理权利过大，产品的原型完全是由产品人员和公司高层决定的，开发团队完 全是棋子，编码机器人，开发压力大，加班严重，生产的代码质量差，很难在预计时间点交付高质量产品。所谓“兵熊熊一个，将熊熊一窝”，在这种体制下，整个 产品线完全围绕产品经理转，再牛B的工程师也扛不住不靠谱的产品经理，产品经理是如此之重要，以至于一个不靠谱的产品经理很可能会毁了一整支团队。“产品 驱动”的体制大体上分产生两类问题：1）产品创意来自非技术人员 2）软件开发管理混乱。 对于第2点，通过推行好的软件开发方法（比如scrum）可以解决，当然，推行起来会有它的困难，但这不是这篇博客想要探讨的，后面有时间会再另写一博文 探讨。对于第1点，完全无解，“产品驱动”的机制先天就无法解决这个问题。“创意”应该来自两个层面，一个是脱离技术的纯应用层面的创意，这是产品人员的 长处，他们的灵感主要来自于用户需求，发掘用户所需，提供用户所想但IT圈里还没有做的产品，比如团购、sns都是;另一个层面应该来自技术层面的创意， 比如说技术上出现了什么新的技术，这种技术如何合理应用，发挥一些创意，可以用它来做成什么的产品，它的灵感来自于各种技术api的创意用法，比如 gmail的ajax，比如google地图，这些都不可能由非技术人员去创意出来，他们压根就不知道这能否实现，对这种类型的“创意”他们并不敏感。虽 然任何产品最终最会落实到具体的技术实现上，但非技术人员对技术层面不了解，这是他们的短板，哪怕他们再也创造力，技术上的创意他们无能为力。

“技术驱动”型的运作模式非常罕见，google应该算是。如果在产品驱动型的公司，工程师们想到什么创意其实很难去实施，很难去启动一个项目——大多数 公司面对工程师的创意会去问“有其他公司在应用这个技术吗？”，如果没有，那么很难得到高层的支持去做。所以你可以看到国内大多数公司只会去抄一个国外的 创意项目，迅速将其山寨化，拼的是山寨的速度，而不是创意。在技术驱动型的公司里，可以很好地发挥工程师们的创意，启动一个项目的并不是公司高层，而是工 程师自己，工程师自己有什么创意就可以动手去跑这个项目，项目没有一个明确的上线的时间点，甚至不一定被要求要上线。项目开发到相对完善的程度了，可以请 产品经理参与进来，如果产品经理对这个项目感兴趣，可以从产品设计角度提出修改意见，并帮助工程师将项目运作起来向外发布。产品经理的角色权力不会过大， 他们在他们擅长的领域“产品设计”领域里可以发挥所长，但不会对“项目开发过程”有权力——他们并不在行这个，这方面他们没权力反而更好，对技术层面负责 的完全是工程师。产品经理的KPI考核会有别的机制，并不像“产品驱动”型那样，背负过重的压力，导致有过大的权力，导致在他们不擅长的“管理”领域不得 不过分关心。在“技术驱动”型的公司里，工程师有着非常高的权力，有着自由得多的时间，做着自己感兴趣的事，他们的KPI考核机制也和“产品驱动型”公司 完全不同。为什么google是工程师梦想的天堂？不是没有原因的。

“技术驱动”型的公司竟然这么好，那么为什么这么多的公司都不用这种模式？因为他的成本很高，产品的原型完全是工程师去做的，也许他 最终只能成为一个“技术成功”的项目，而无法带来“商业价值”，因为这不是工程师们的兴趣和长处所在。也就是说，也许100个项目里，最后有一个项目获得 了商业上的成功，其他99个也许挣不到钱，甚至有可能夭折。而且技术驱动的公司，对工程师的要求很高，不会让一些能力很弱的工程师来公司混日子，公司相对 很自由但相应的，进入门槛会很高——google和facebook的招聘条件大家都有所耳闻吧？门槛高意味着开出的薪水也会很高，而这些工程师开发的项 目还有可能并不挣钱！“技术驱动”型的公司，必须有玩得起的资本，并不是什么公司都玩得起和有那个胆量去玩的。

－－－－－－－

上面的原文来自于：http://hi.baidu.com/cly84920/blog/item/741a13ced83ad21093457ea5.html

最后一秒

－－－－

还是晚了。。。晚了一秒。

光棍节又可以称为六一儿童节，所以我和老婆去过儿童节了，很开心。Over

受不了，最近很多人加我QQ说要跳舞，我就纳闷了。我没有说过我要跳舞啊？
怎么会有这种事情？然后居然在QQ邮箱里也收到了邮件，说是什么闵行跳舞总群活动了。。
一下子纠结起来，看了一下所谓的贴子，居然还真是留的19129540
我一开始以为是某个人冒充我的名义发的贴子，想着谁那么无聊，但后来一想，不对啊。跳舞总群，难道是QQ群
所以。。。搜索了一下，果然：

哎，真悲催啊

不想多说，其实我转这篇也是想给几个人看看，国庆的时候，我说过，要做编程这一行，一定要耐得住寂寞。可惜没人附和。
原文如下：http://blog.csdn.net/heiyeshuwu/article/details/6920880

文章来自baidu NY 同学的邮件，整理发出。

1. 想学的技术非常多，该怎么办？

区分重点，选定目标，循序渐进。技术是无边际的，随着知识的不断增加，会发现未知的东西更多。我们能做的是：

1) 找重点：区分感兴趣的技能和必须技能，将重点放在必须技能上。如实在区分不开，可以这样问自己：不学这个技术会现在的工作是不是干不下去了？

2) 定目标：在一段时间（至少半年内）选定一个技术方向，精研下去。

3) 不断向前：当某一种技术掌握后，再开始另一个技术的研究；

2. 很想学一种技术，但项目工作太多，没时间开展，一直拖着，怎么办？

生存状况和工作性质注定了我们不能像在学校和外企那样有大把的可支配时间，所以要追求技术进步只能自己找时间，也即“白天求生存，晚上谋发展”的道理。我一般会将晚上和周末的时间拿出一部分来学习。

3. 选定一个技术方向作为学习目标的时候哦，如何开展效果比较好？

学习一门技术一般分几个阶段，入门->掌握->精通。一般情况下，达到熟练掌握的程度即可，要实现至少需一年的积累。

可以分下边几步：

1) 知其然：了解该技术的基本原理和应用场景，并进行简单的实践。这个阶段，官方文档是最好的教材；

2) 站在巨人的肩膀上：找该技术业界成熟的开源类库和应用系统进行学习，精度源代码；

3) 在问答中进步：去相关论坛学习，提问或者回答问题，并尝试独立解决论坛中已有问题，www.stackoverflow.com是最好的选择。

4) 躬身而行：实践相关技术，达到能独立完成中等规模应用的程度；

5) 知其所以然：深入了解该技术的运行机制、周边技术、性能优化、深度知识等；

6) 善用资源：在公司，高手很多，你想了解的任何一门技术，差不多都能找到相应的牛人，多和这些人沟通，会事半功倍。

以PHP为例：

熟悉语法&api -> 阅读zend、ci、wordpress源码 -> 用PHP独立开发项目 -> 深入了解PHP引擎实现细节、扩展编写、性能优化等

4. 外界干扰太多，静不下心来学习，怎么办？

刚来百度的时候，前辈给过我一个建议：关掉QQ，结合在学校时的体会，我深知这个建议的重要性，欣然接受了。

其实，静心是做好任何事的前提，关掉QQ只是一个表象，最本质的是我们要给自己营造一个好的学习环境。

做技术需要一个安静的环境和一套方法论，方法论可以找到很多（论语第一篇讲的最好），环境必须我们自己营造。

所以我的建议是：忘掉QQ、适度娱乐，努力使自己沉迷到工作和学习中。

虽然不太容易做到，但做到了对提高效率、找出学习时间都很有帮助。

一些复杂的技术会涉及很多方向，每个方向也可以按照上边的方式分解。

技术学习可以触类旁通，当你完全吃透一门技术的时候，其它的再学起来就快了。

以上内容归根结底就是要我们：懂得选择，学会放弃，耐得住寂寞，经得起诱惑。

做技术如同做学问，关于如何做学问，王国维有段话我高中以来一直非常喜欢：

古今之成大事业、大学问者，罔不经过三种之境界：“昨夜西风凋碧树。独上高楼，望尽天涯路。”此第一境界也。“衣带渐宽终不悔，为伊消得人憔悴。”此第二境界也。“众里寻他千百度，蓦然回首，那人却在灯火阑珊处。”此第三境界也。

有兴趣者可参阅：http://www.china.com.cn/culture/guoxue/2010-03/16/content_19620537.htm

技术之路是艰辛且寂寞的，希望以上内容对有志于此道者有所启发。

－－－－－－－－－－－－－－
上面的内容中那句：懂得选择，学会放弃，耐得住寂寞，经得起诱惑
其实真的应该记一下。

这是cnbeta上面的一篇文章里面讲的很有意思。其中有一点：很多人不知道电子邮件是什么，以为QQ就是互联网
这句说的真的不错，其中还有一点说了中国的现状：创业公司不得不在办公地点上花大量钱财。大多数中国技术人员喜欢为大公司工作，并且他们更喜欢现金而非股权。如果公司没有一个好的办公环境，那么他们很难招到合适的员工。
嗯。宁当凤尾不做鸡头，这句话其实和以前是相反，以前是宁做鸡头不做凤尾的，现在不一样，宁可在大公司当小员工，不想云小公司当头。做互联网破产的机会比较大，很多人就不愿意去小公司搏。

原文来自：http://www.cnbeta.com/articles/160449.htm

感谢雷锋网的投递
这是一位出生在中国、但早年随父母移居美国的华人工程师Bowei Gai所做的一个PPT，不久前他来到中国寻找机会，于是有了以下的PPT，这份PPT在Slideshare上发布后迅速成为第二热门的PPT。这多少能反映硅谷公司和VC对中国创业公司的看法。

Bowei Gai的结论是：进入中国市场就像你摸着石头过河初次创业。因为：

-----------------------------
以上都是原文，原文中还有几段很深得人心啊，我在里面都加背景色了。
不过，评论更给力：

一直在模仿，从未想过创新。所谓的创新即是以最快的速度复制国外成功案例，国内首创！

镇上js对外来合作者的态度是，大不了先给你找个niu，然后咱再谈生意~