西博传媒

成功人生应记住的十个故事

Thu, 20 Aug 2009 00:09:54 +0800

最近比较烦躁，于是又找到了这篇文章，还是将它挂在自己的博客上吧，想看的时候可以随时看到，激励一下自己。下面这句是来源地方的作者的话，呵呵，他也是转载的。

来源：http://freddy.cc/article/169

最近思维比较乱，稍微有点颓了，正好看到一篇文章，虽说有点年头了，倒也还能让人振奋一下，所以转帖上来，有空就看两眼吧：）

一.相信自己是一只雄鹰

一个人在高山之巅的鹰巢里，抓到了一只幼鹰，他把幼鹰带回家，养在鸡笼里。这只幼鹰和鸡一起啄食、嬉闹和休息。它以为自己是一只鸡。这只鹰渐渐长大，羽翼丰满了，主人想把它训练成猎鹰，可是由于终日和鸡混在一起，它已经变得和鸡完全一样，根本没有飞的愿望了。主人试了各种办法，都毫无效果，最后把它带到山顶上，一把将它扔了出去。这只鹰像块石头似的，直掉下去，慌乱之中它拼命地扑打翅膀，就这样，它终于飞了起来！

秘诀1：磨练召唤成功的力量。

二.五枚金币

有个叫阿巴格的人生活在内蒙古草原上。有一次，年少的阿巴格和他爸爸在草原上迷了路，阿巴格又累又怕，到最后快走不动了。爸爸就从兜里掏出5枚硬币，把一枚硬币埋在草地里，把其余4枚放在阿巴格的手上，说：“人生有5枚金币，童年、少年、青年、中年、老年各有一枚，你现在才用了一枚，就是埋在草地里的那一枚，你不能把5枚都扔在草原里，你要一点点地用，每一次都用出不同来，这样才不枉人生一世。今天我们一定要走出草原，你将来也一定要走出草原。世界很大，人活着，就要多走些地方，多看看，不要让你的金币没有用就扔掉。”在父亲的鼓励下，那天阿巴格走出了草原。长大后，阿巴格离开了家乡，成了一名优秀的船长。

秘诀2：珍惜生命，就能走出挫折的沼泽地。

三.扫阳光

有兄弟二人，年龄不过四、五岁，由于卧室的窗户整天都是密闭着，他们认为屋内太阴暗，看见外面灿烂的阳光，觉得十分羡慕。兄弟俩就商量说：“我们可以一起把外面的阳光扫一点进来。”于是，兄弟两人拿着扫帚和畚箕，到阳台上去扫阳光。等到他们把畚箕搬到房间里的时候，里面的阳光就没有了。这样一而再再而三地扫了许多次，屋内还是一点阳光都没有。正在厨房忙碌的妈妈看见他们奇怪的举动，问道：“你们在做什么？”他们回答说：“房间太暗了，我们要扫点阳光进来。”妈妈笑道：“只要把窗户打开，阳光自然会进来，何必去扫呢？”

秘诀3：把封闭的心门敞开，成功的阳光就能驱散失败的阴暗。

四.一只蜘蛛和三个人

雨后，一只蜘蛛艰难地向墙上已经支离破碎的网爬去，由于墙壁潮湿，它爬到一定的高度，就会掉下来，它一次次地向上爬，一次次地又掉下来…… 第一个人看到了，他叹了一口气，自言自语：“我的一生不正如这只蜘蛛吗？忙忙碌碌而无所得。”于是，他日渐消沉。第二个人看到了，他说：这只蜘蛛真愚蠢，为什么不从旁边干燥的地方绕一下爬上去？我以后可不能像它那样愚蠢。于是，他变得聪明起来。第三个人看到了，他立刻被蜘蛛屡败屡战的精神感动了。于是，他变得坚强起来。

秘诀4：有成功心态者处处都能发觉成功的力量。

五.自己救自己

某人在屋檐下躲雨，看见观音正撑伞走过。这人说：“观音菩萨，普度一下众生吧，带我一段如何？” 观音说：“我在雨里，你在檐下，而檐下无雨，你不需要我度。”这人立刻跳出檐下，站在雨中：“现在我也在雨中了，该度我了吧？”观音说：“你在雨中，我也在雨中，我不被淋，因为有伞；你被雨淋，因为无伞。所以不是我度自己，而是伞度我。你要想度，不必找我，请自找伞去！”说完便走了。第二天，这人遇到了难事，便去寺庙里求观音。走进庙里，才发现观音的像前也有一个人在拜，那个人长得和观音一模一样，丝毫不差。这人问：“你是观音吗？” 那人答道：“我正是观音。” 这人又问：“那你为何还拜自己？” 观音笑道：“我也遇到了难事，但我知道，求人不如求己。”

秘诀5：成功者自救。

六.让失去变得可爱

一个老人在高速行驶的火车上，不小心把刚买的新鞋从窗口掉了一只，周围的人倍感惋惜，不料老人立即把第二只鞋也从窗口扔了下去。这举动更让人大吃一惊。老人解释说：“这一只鞋无论多么昂贵，对我而言已经没有用了，如果有谁能捡到一双鞋子，说不定他还能穿呢！”

秘诀6：成功者善于放弃，善于从损失中看到价值。

七.请不要开错窗

一个小女孩趴在窗台上，看窗外的人正埋葬她心爱的小狗，不禁泪流满面，悲恸不已。她的外祖父见状，连忙引她到另一个窗口，让她欣赏他的玫瑰花园。果然小女孩的心情顿时明朗。老人托起外孙女的下巴说：“孩子，你开错了窗户。”

秘诀7：打开失败旁边的窗户，也许你就看到了希望。

八.人生的秘诀

30 年前，一个年轻人离开故乡，开始创造自己的前途。他动身的第一站，是去拜访本族的族长，请求指点。老族长正在练字，他听说本族有位后辈开始踏上人生的旅途，就写了3个字：不要怕。然后抬起头来，望着年轻人说：“孩子，人生的秘诀只有6个字，今天先告诉你3个，供你半生受用。” 30年后，这个从前的年轻人已是人到中年，有了一些成就，也添了很多伤心事。归程漫漫，到了家乡，他又去拜访那位族长。他到了族长家里，才知道老人家几年前已经去世，家人取出一个密封的信封对他说： “这是族长生前留给你的，他说有一天你会再来。”还乡的游子这才想起来，30年前他在这里听到人生的一半秘诀，拆开信封，里面赫然又是3个大字：不要悔。

秘诀8：中年以前不要怕，中年以后不要悔。

九.司机考试

某大公司准备以高薪雇用一名小车司机，经过层层筛选和考试之后，只剩下三名技术最优良的竞争者。主考者问他们：“悬崖边有块金子，你们开着车去拿，觉得能距离悬崖多近而又不至于掉落呢？” “二公尺。”第一位说。 “半公尺。”第二位很有把握地说。 “我会尽量远离悬崖，愈远愈好。”第三位说。结果这家公司录取了第三位。

秘诀9：不要和诱惑较劲，而应离得越远越好。

十.狮子和羚羊的家教

每天，当太阳升起来的时候，非洲大草原上的动物们就开始奔跑了。狮子妈妈在教育自己的孩子：“孩子，你必须跑得再快一点，再快一点，你要是跑不过最慢的羚羊，你就会活活地饿死。” 在另外一个场地上，羚羊妈妈也在教育自己的孩子：“孩子，你必须跑得再快一点，再快一点，如果你不能比跑得最快的狮子还要快，那你就肯定会被他们吃掉。”

秘诀10：记住你跑得快，别人跑得更快

马太效应、梅特卡夫法则、摩尔定律

Wed, 19 Aug 2009 23:52:28 +0800

关于“马太效应”、“梅特卡夫法则”、“摩尔定律”的一些概念。

1、马太效应（Matthew Effect）：

是指好的愈好，坏的愈坏，多的愈多，少的愈少的一种现象。名字来自于圣经马太福音中的一则寓言。

它的原创者是美国科学史研究者罗伯特·莫顿(Robert K. Merton)。1968年，莫顿提出“马太效应”这个术语。

20世纪60年代，著名社会学家罗伯特﹒莫顿归纳“马太效应”为任何个体、群体或地区，一旦在某一个方面（如金钱、名誉、地位等）获得成功和进步，就会产生一种积累优势，就会有更多的机会取得更大的成功和进步。

马太效应揭示了一个不断增长个人和企业资源的需求原理，关系到个人的成功和生活幸福，因此它是影响企业发展和个人成功的一个重要法则。

马太效应的现象：

A 使用《圣经》中的一句话：“凡是有的，还要给他，使他富足；但凡没有的，连他所有的，也要夺去。”

B 贫者越贫，富者越富。

C 一步领先，步步领先。

2、梅特卡夫(Metcalfe)法则：

是指网络价值以用户数量的平方的速度增长。网络外部性是梅特卡夫法则的本质。这个法则告诉我们：如果一个网络中有n个人，那么网络对于每个人的价值与网络中其他人的数量成正比，这样网络对于所有人的总价值与n×(n-1)=n2- n成正比。如果一个网络对网络中每个人价值是1元，那么规模为10倍的网络的总价值等于100元；规模为100倍的网络的总价值就等于10000元。网络规模增长10倍，其价值就增长100倍。

3、摩尔定律：

是著名芯片制造厂商美国因特尔公司 (Intel)创始人之一的戈顿·摩尔对集成电路技术发展趋势作出的推断。它描述了特定时期，特定技术及其相关应用的性能或价格以18个月为周期的一种增长或下降规律。摩尔定律主要有三种不同的表述：
（1）集成电路芯片上所集成的电路数目，每隔18个月翻一番；
（2）微处理器的性能每隔18个月提高一倍，而价格下降50%；
（3）用一个美元所能买到的电脑性能，每隔18个月翻两番。

《疯狂程序员》一书中的”奥秘”

Wed, 19 Aug 2009 17:54:16 +0800

想想自己转向做程序员也有半年多了，也许一年多了吧，从仅认识一些HTML标签符号，到慢慢开始学习面向对象，学习程序的设计思想，有不少说不出来的懵懂的地方，但是好在还有一些动力去学习。

《疯狂的程序员》这本书我没有买，这篇文章是在别人的博客看到的，他说是在别人订阅的CSDN的RSS看到了的，整理的不错特意转载。

来源：http://blog.csdn.net/gisfarmer/archive/2009/07/22/4371153.aspx

在此记录这本书中的精华（个人认为是精华！呵呵！如果有不对或遗漏的地方还希望大家莫怪，水平有限！）目的是以后方便时刻提醒自己！

1.千里之堤溃于蚁穴啊，一个个小小的BUG最终毁掉了这个大CASE。

2.其实不是它难，是自己不去用它，不管什么技术，只要你必须去用它，学起来也就不难了。

3. 程序员不管是做程序还是做事，都应该有这种习惯：一个问题要尽量在做之前就把所有的结果想出来，分别对每种结果进行分析，找到较好的应对措施再去做。这样，整个问题都尽量在你的控制中，不至于做出“Out of control”的事情。一件事，如果你决定去做，就要尽力让它在你的控制中。

4.写程序前先写文档，把所有思路理清，千万不要一上来就写，就好比驴拉磨：驴蒙了眼睛去拉磨，只晓得往前跑，不知道为什么。这是最痛苦的事情。

5.把复杂的东西简单化，融入自己的思想切记不要浮躁，踏实走稳。

6.不要在简历上做手脚或夸张的表现自己，坦坦荡荡！员工最重要的品质就是诚实！

7.做项目这就像修房子，虽然里面的一砖一瓦不知道凝结了多少工人的心血，但他们永远体会不到一座座高楼拔地而起的幸福和成就感，因为在他们眼中，只能看到一块砖或一片瓦，只有设计师，在他眼中看到的是整栋雄伟的大厦。

8.不要为工作而工作那样你会感觉到很疲惫，根本没有时间和想法去提升自己，只有兴趣，兴趣才能牵引着你一步一步的望技术的前沿走。

9. 什么是程序员，能为一两千块工资天天在公司加班加点回家还继续干到两三点甚至通宵的程序员，他们根本就不在乎挣多少钱。程序员，他们想的是什么？他们想的永远都是技术，他们崇尚的也永远是技术，哪怕我现在身上只有两毛前，只要有志同道合的人跟我聊技术，我一样敢跟他从C++聊到ASM，从API钩子聊到 inline hook，从Ring3聊到Ring0。聊完了，今天晚上吃什么？吃什么并不重要，重要的是如何才能获取Kernel基址。

10.好多CASE根本不是给老板和用户做的，是给自己做的，别人怎么想不重要，关键是自己要对得起自己。

11.写程序，和别的工作不一样，有些工作需要人缘，有些工作需要关系，有些工作还需要美色，但是写程序，只需要你有技术。

12. 做技术工作的，最忌讳就是心态不能平衡，一旦你心态不平衡，你就写不出什么程序，虽然你可以几个小时一直坐在电脑面前，而且要写什么怎么写你也很清楚，可是你就是下不了手。因为写程序这个工作和别的不一样，从你决定动工，你就很清楚地知道这次至少要实现个什么功能，或者完成什么阶段性的工作，中间思路不能断，一旦断了，接上去的工夫甚至比全部重写还要麻烦。

13.程序员一定要信守自己的承诺，如果你没把握做到，最好就不要去承诺，至少你什么也不承诺，别人不会看不起你。

14. 一个CASE，只要能够卖出去，能够通过验收，在商业上讲它就是成功的。效果都是一样，与其花大力气去做得非常精制比如节约点时间尽量过关。时间就是金钱呐，有了时间，这个CASE做完，我还能再接一个CASE。什么是“商业价值”？一个产品卖出去一份和卖出去一万份没什么差别。哪怕只卖出去一份，客户对它的评价是好的，那么就是100%的成功，同样的，即使卖出去一万份，却没有一个客户来肯定它，这就是100%的失败.

15.成功的经验，只需要跟一个人学就行了，失败的经验，却需要从千千万万的人身上去找.

16.做东西先要对得起自己!对得起自己的设计，对case没把握，没把握做的一定很漂亮，但只要尽力去做，做到问心无愧就可以了！

17.提升功力大低有两种方法，一是自己不断写代码，不断完善，不断把自己的代码写好，二是看牛人的代码。牛人的代码实在太高深了，一句看似平凡的语句，也许背后都蕴含着惊天地泣鬼神的智慧。

决定你是穷人还是富人10个标准

Thu, 23 Jul 2009 00:52:31 +0800

最近发现自己很……无聊，看得文章很多，但没有多少记下的。

出处：http://freddy.cc/article/283

1、自我认知

穷人：很少想到如何去赚钱和如何才能赚到钱，认为自己一辈子就该这样，不相信会有什么改变。

富人：骨子里就深信自己生下来不是要做穷人，而是要做富人，他有强烈的赚钱意识，这也是他血液里的东西，他会想尽一切办法使自己致富。

2、学习

穷人：学手艺

富人：学管理

3、休闲

穷人：在家看电视，为肥皂剧的剧情感动得痛苦流涕，还要仿照电视里的时尚来武装自己。

富人：在外跑市场，即使打高尔夫球也不忘带者项目合同。

4、时间

穷人：一个享受充裕时间的人不可能赚大钱，要想悠闲轻松就会失去更多赚钱的机会。穷人的时间是不值钱的，有时甚至多余，不知道怎么打发,怎么混起来不烦。如果你可以因为买一斤白菜多花了一分钱而气恼不已。却不为虚度一天而心痛，这就是典型的穷人思维。

富人：一个人无论以何种方式赚钱，也无论钱挣得的是多还是少，都必须经过时间的积淀。富人的玩也是一种工作方式，是有目的的。富人的闲，闲在身体，修身养性，以利在战，脑袋一刻也没有闲着；穷人的闲，闲在思想，他手脚都在忙，忙着去麻将桌上多摸几把。

5、归属感

穷人：是颗螺丝钉。穷人以为出身卑微，缺少安全感，就迫切地希望自己从属于并依赖于一个团体，于是他们以这个团体的标准为自己的标准，让自己的一切合乎规范，为团体的利益而工作，奔波，甚至迁徙。对于穷人来说，在一个著名的企业里稳定的工作几十年，有实习生一直干到高级主管,那简直是美得不能再美的理想。

富人：那些团体的领导者通常都是富人，他们总是一方面向穷人灌输：团结就是力量，如果你不从属于自己的团体，你就什么都不是，一名不文。.但另一方面，他们却从来没有停止过招兵买马，培养新人，以便随时可以把你替换掉。

6、自信

穷人：穷人的自信要通过武装到牙齿，要通过一身高级名牌的穿戴和豪华的配置才能给他们带来更多的自信，穷人的自信往往不是发自内心和自然天成的。

富人：李嘉成在谈到他的经营秘诀时说：其实也没什么特别的，光景好时，决不过分乐观；光景不好时，也不过度悲观。其实就是一种富人特有的自信。自信才能不被外力所左右，自信才可能有正确的决定。

7、投资及对待财富

穷人：经济观点就是少用等于多赚，比如开一家面馆，收益率是100%，投入2万，一年就净赚2万，对于穷人来说很不错了。穷人即使有钱，也舍不得拿出来，即使终于下定决心投资，也不愿意冒风险，最终还是走不出那一步。穷人最津津乐道的就是鸡生蛋，蛋生鸡，一本万利……但是建筑在一只母鸡身上的希望毕竟是那样的脆弱。

富人：富人的出发点是万本万利。同样的开面馆，富人们会想，一家面馆承载的资本只有2万，如果有一亿资金，岂不是要开 5000家面馆？要一个一个管理好，大老板得操多少心，累白多少根头发呀？还不如投资宾馆。一个宾馆就足以消化全部的资本，哪怕收益率只有20%，一年下来也有2000万利润

8、激情（能不能干成事，首先要看有没有激情）

穷人：没有激情。他总是按部就班，很难出大错，也绝对不会做到最好。没有激情就无法兴奋，就不可能全心全意投入工作。大部分的穷人不能说没有激情，看他的激情总是消耗在太具体的事情上：上司表扬了，他会激动；商店打折，他会激动；电视里破镜重圆了，他的眼泪一串一串往下流，穷人有的只是一种情绪。

富人：燕雀安知鸿鹄之志?王侯将相,宁有种乎?有这样的激情，穷人终将不是穷人！激情是一种天性，是生命力的象征，有了激情才有了灵感的火花，才有了鲜明的个性，才有了人际关系中的强烈感染力，也才有了解决问题的魄力和方法。

9、习惯

穷人：有个故事，一个富人送给穷人一头牛。穷人满怀希望开始奋斗。可牛要吃草，人要吃饭，日子难过。穷人于是把牛卖了，买了几只羊,吃了一只，剩下来的用来生小羊.可小羊迟迟没有生出来，日子有艰难了。穷人把羊卖了，买成了鸡，想让鸡生蛋赚钱为生，但是日子并没有改变，最后穷人把鸡也杀了，穷人的理想彻底崩溃了，这就是穷人的习惯。

富人：根据一个投资专家说，富人成功的秘诀就是：没钱时，不管多困难，也不要动用投资和储蓄，压力会使你找到赚钱的新方法，帮你还清帐单。这是个好习惯。性格决定了习惯，习惯决定了成功。
10、消费花钱

穷人：买名牌是为了体验满足感，最喜欢试验刚出来的流行时尚产品，相信贵的必然是好的。

富人：买名牌是为了节省挑选细节的时间，与消费品的售价相比，他更在乎产品的质量，比如会买15元的纯棉t恤，也不会买昂贵的莱卡制品。

让你的创业失败的18个昏招

Thu, 23 Jul 2009 00:52:16 +0800

很好的一篇文章，感谢作者和译者，有些问题，经历过了，才会真正的明白和清楚。

最近创业这个话题谈的太多了，有时间也要自己总结一下了。

后面有英文的，另外发布一篇了。

来源：http://freddy.cc/article/133

原本我在译言看到的版本只翻译了1/3，没想到在评论里发现有人已经翻译过这篇文章了，对于我来说，确实得来全不费工夫，对于两位译者，确实消耗了不少脑细胞，所以在这里谢谢拙尘以及pestwave，给我们带来这么有见地的文章。同时也提醒我们需要注意一个问题，就是网站在提供更好的UE、更多创作空间的同时，也要多站在用户的角度上想一想，不要让用户做无用功。

在最近的一次演讲中，有人问我，哪些错误会导致创业失败。站在那里愣了几秒后，我意识到，这是一个很难回答的问题。它等于是在问：一个初创公司如何才能成功。如果你能避免所有导致失败的错误，那么你自然就会成功。这个问题太大了，很难在那样短的时间里回答清楚。

后来我又认识到，这个问题如果从另一个角度看，也许是有意义的。假如你有一个清单，列出了所有你不应该做的事情，那么只需要把这个清单取反，你就得到了一张成功的处方。而在实际应用中，这样的清单会更有价值。查觉你正在做不应该做的事情，总比一直记着你应该做的事情更容易些。[1]

从某种意义上说，导致创业失败的错误只有一个：没人需要你做的东西。如果你在做的东西是用户需要的，那么你应该能够生存下去，其它的问题都无关紧要。但如果你在做的东西不符合用户的需求，那么你死定了，任何事都改变不了这个结局。所以，这个清单里列出的18个错误，实际上是导致初创公司不能满足用户所需的因子。几乎所有失败的原因，都可以归结到这里面来。

1 孤家寡人（Single Founder）

不知你是否注意到，极少有成功的初创公司是由一个人创办的？一些你可能会以为是单一创始人的公司，比如说甲骨文（Oracle），实际上是由多个人一起创办的。这似乎不是一个巧合。

单一创始人有什么问题呢？最起码，这反映了一种信心的缺乏。隐含的信息是，创始人无法说服他的任何一个朋友跟他一起打天下。这很值得玩味：别忘了，他的朋友是最了解他的人。

就算朋友们都错了，公司实际上可能很有前途；但是，单一创始人的不利仍然是很明显的。一个人创业实在太难了。就算你无所不能，你也需要同伴们来集思广益，避免愚蠢的举动，以及在遇到挫折时互相鼓励。

最重要的一点是，创业的过程中你可能遇到难以承受的低点。当你有多个创始伙伴时，彼此信念上的支撑就好比捆成了一捆的箭。每个人都暗暗给自己打气：“我绝不能让我的朋友们失望。”这是一个人最强大的动力之一。而单一的创始人则缺少了这一动力。

2 缺少地利（Bad Location）

并不是所有的地方都适合创业的。硅谷是创业的最佳地点，波士顿其次，再其次是西雅图、奥斯汀、丹佛和纽约。除此之外，几乎没有什么其它的选择了。就算在纽约，初创公司的密度也已经降到了硅谷的二十分之一左右。而在像休斯敦、芝加哥和底特律这样的地方，创业的可能性几乎可以忽略不计。

为什么会有这么大的差别呢？其实，其它的业界也有类似的情况。全美第六大的时装中心在哪儿？第六大的石油，金融，出版中心又分别是哪里？不管答案是什么，可以肯定，这些中心的规模要远远小于榜首的规模。

为什么某些城市会成为初创公司的聚集地呢？这个问题很有意思。我想答案与在其它业界得出的结论类似：因为那里聚集了大批的专业人士。那里的专业水准较高；人们对你所做的东西更容易产生共鸣；你能更容易地找到你想要雇用的人；周边工业也较发达；你有更多的机会碰上跟你在一个领域内的人；等等，等等。天知道这些综合因素是怎样促成了初创公司在硅谷的繁荣，又是怎样让底特律这样的城市黯然失色。不过，数字能够说明一切：在硅谷的初创公司密度远远超出了在底特律得到的数字。
3 领域偏狭（Marginal Niche）

在向 Y Combinator 申请风投的团队里，大多数都犯了一个共同的错误：为了避免竞争而刻意选取那些很狭隘、很冷僻的领域。

如果你看过孩子们打棒球的话，你会发现，在某个年龄段以下的孩子会有些怕球。面对来球，他们的本能反应是躲避。我在八岁的时候当过外野手，不过没有接到过多少球，因为每次球朝我飞来的时候，我总是闭上眼睛，举起手套来保护自己，而不是去力争接到球。

一个初创公司，如果净是挑选那些偏狭的项目来做的话，就跟我在八岁时对付来球的策略一样。要知道，如果你能够有所成就的话，就必然会有竞争者，早晚都要面对。所以说，如果你不想竞争的话，那么你想出来的点子好不到哪儿去。

我想，这种遇到大的困难就退缩的举动，往往是人们在潜意识下作出的。这跟你有一个很大的构想但却决定追求一个较小的较稳妥的目标不同，因为你在潜意识里就拒绝大的构想。解决这一问题的办法是假装你在为别人而不是为自己做策划。想想看，有什么好的主意适合某人去进行创业呢？

4 拾人牙慧（Derivative Idea）

我们收到的许多申请都是在效仿一些已经存在的公司。现有的公司的确能够给你一些想法，但绝对不是最好的。如果你回顾一下那些成功的初创公司，很少是从模仿别人起家的。他们的灵感来自哪儿呢？通常是由创始人发现了一些尚未解决的特定问题。

我们自己的初创公司的业务是编写软件，使之能够生成在线商店的网站。当初我们是独此一家；少数几家支持在线交易的网站都是由互联网的专业设计人员手工编写的，成本很高。我们认识到，一旦在线购物红火起来的话，这些网站必然是要由软件来生成的，所以我们就写了这样一个软件。这个想法的起源很直接，如此而已。

那些对你个人产生影响的问题应该是最好的问题。苹果（Apple）的诞生是因为斯蒂夫·沃兹尼亚克（Steve Wozniak）需要一台电脑；谷歌（Google）则是由于拉瑞（Larry）和谢尔盖（Sergey）在网上找不到他们想要的东西；而 Hotmail 是因为沙比尔·巴蒂亚（Sabeer Bhatia）和杰克·史密斯（Jack Smith）无法在工作中互发电子邮件。

所以，不要去照搬 Facebook，在上面做些零敲碎打的工作；你应该到别的方向上去发掘灵感。也不要受已有的公司的影响，去炒他们的冷饭；你应该去找寻未解决的问题，然后设想一下什么样的公司能够解决那些问题。[2] 你需要弄清楚，人们在抱怨什么以及期待什么？

5 固执己见（Obstinacy）

在某些领域里，成功的途径需要你认准了想做的事情并坚持到底，不管遇到多大的挫折。而创业则另当别论。如果你是想要赢得一块奥林匹克金牌的话，那么你应该咬定目标，决不放弃；因为你的目标十分明确。但是，创业更像是从事科学研究，你更应该遵循自然规律而不是主观臆断。

你应该避免过于坚持原来的计划，因为它可能是错误的。大多数成功的初创公司，最后做的都不是他们刚开始企图做的——而且差别往往很大，以至于你很难把他们同最初的公司联系起来。在创业的过程中，你应该准备好接受任何更好的主意；而最难做到的就是放弃你已有的想法。

当然，这里也有一个度的问题。每周都换一个想法显然也不可能成功。有什么标准能够帮助你做决定吗？一个办法就是衡量那些新的想法是否代表了某种进展。如果你能够利用大部分你所做过的东西，那么你可能是在一个螺旋式上升的过程中；反之，如果你需要从头开始的话，那就不是一个好兆头。

幸运的是，你可以向你的用户寻求建议。如果你转向一个新方向，而用户又对此反响热烈的话，那么你很可能押对宝了。

6 遇人不淑（Hiring Bad Programmers）

在早先的清单里我忘了列上这一条了，因为我所碰到的创始人大多是程序员。对于他们来说，这不是什么大问题。就算他们偶尔雇用了一两个差劲的程序员，也不至于天就塌下来了。紧要关头，他们都可以亲自操刀上阵，力挽狂澜。

不过，当我回溯90年代那些倒闭的电子商务初创公司时，却发现正是差劲的程序员毁了那些公司。很多公司都是由商业领域的人员创办的。他们以为初创公司就是有个好的点子，然后雇用一批程序员来实现它。这真是想得容易做的难。这些商业领域的人员根本就无法区分程序员的好坏。他们甚至接触不到最好的程序员，因为没有哪个程序高手愿意去实现一个商人的构想。

事实是，这些人招募了一些他们以为是好的程序员（至少这些程序员的简历是这样吹嘘的，什么微软认证的开发人员了，等等），但实际上却难副其实。接下来他们就会很困惑地发现，自己的公司就像老牛拉破车一样吱嘎吱嘎，而竞争对手们却跟坐了火箭一样。这种初创公司具有那些大公司的所有缺点，却没有那些大公司所具备的优势。

如果你本人不是程序员的话，怎样才能挑选好的程序员呢？我不认为有什么好办法。我本来想说，你可以找个程序高手来帮你做这件事儿。但问题是，你怎么找到这个最初的程序高手呢？

7 开发平台选取不当（Choosing the Wrong Platform）

同上面一条相关的问题是开发平台选取不当（通常差劲儿的程序员都会犯这个错误）。我认为，在经济泡沫时期，很多初创公司都因为在 Windows 的平台上构建基于服务器的应用而身陷泥沼。Hotmail 在被微软收购若干年之后仍然运行在 FreeBSD （译者：一个 Unix 平台）上，估计是因为 Windows 无法胜任其负荷。假如 Hotmail 的创始人选择了 Windows 的话，他们很可能早就失败了。

PayPal 刚刚躲过了一劫。在同某个ｄｏｔｃｏｍ合并后（译者：这里应该是指ｅＢａｙ，不知道作者同ｅＢａｙ有什么过节？:)），新的CEO 想要转到 Windows 上——尽管 PayPal 的联合创始人马克斯·莱文奇恩（Max Levchin）向他展示过他们的软件系统在 Windows 上的处理能力只有在 Unix 上的百分之一。幸运的是，最终他们换了 CEO，而不是操作系统平台。

平台是一个很模糊的词。它既可以指操作系统，也可以指编程语言，或者是编程语言之上的框架结构。它所隐含的意义，既包含了支持，也包含了限制，就如同房子的地基一样。

你不得不慎而又慎地选择平台。有些平台，对外行来说，似乎是很好的、很负责的选择，就象90年代的 Windows 一样；一旦你选了他们，就无异于自掘坟墓。Java applets 大概是最典型的例子了。它曾经被人们认为是发布应用的新途径。结果却是，100个对此深信不疑的初创公司里，就有100个被毁掉了。

怎样选取正确的平台呢？通常的办法是招些好的程序员来让他们选择。如果你自己不是程序员的话，也有一个小窍门：到顶尖的计算机系里参观一下，看看他们在科研项目里都使用什么。

8 发布迟缓（Slowness in Launching）

所有的公司，不论大小，在完成软件之前都会有一段困难时期。从某种意义上说，这是一种固有的特性；软件的完成度永远都是在85%左右。你需要有极大的毅力来推动软件的完成并向用户发布。[3]

初创公司总是用各种各样的借口来为推迟发布辩解。这些借口跟人们在日常生活中为自己的迟到所找的理由大同小异：总是有一些事儿要在这之前办好。也许吧。不过假如你的软件已经全部完成，按个按钮就可以发布的话，你还会等吗？

尽快发布的一个目的就是迫使你完成应该完成的工作。一个软件，只要还没有发布，就不算真正完成。不管你认为这个软件已经如何完善了，在临发布之即，总还是有一大堆的事儿要做；这种情形已经司空见惯了。发布的另一个目的就是，只有通过用户反馈，你才能真正明白要做什么。

有一些问题，同发布延迟是有联系的：工作节奏太慢，没有真正搞清楚问题，惧怕同用户打交道，害怕别人的评论，分心过多，过于完美，等等。解决这些问题，只需要推动自己尽快发布一些东西就可以了。

9 发布过早（Launching Too Early）

发布过早的情况比发布迟缓要少见得多，不过并不是没有。发布过早的危险是有可能毁掉了你的名誉。早期的使用者在试用了你发布的东西后，如果发现什么不满意的地方，他们可能就不会再来了。

如果你想发布一样产品的话，最低要求是什么呢？我们建议初创公司认真考虑自己想要做的是什么，确定其核心内容；这些核心内容既要本身就能够有用处，又要能够作为基础，在此之上逐渐地拓展成一个完整的项目。一旦确定了这些，就应该尽可能快地完成它们。

我和很多其他的程序员就是按照这一办法来编写软件的。思考一下总的目标，然后动手编写一些有用的最小模块。这些模块早晚是要写的，所以不用担心作无用功。在大多数情况下你会发现，实现这些模块既能够在精神上获得鼓舞，又能够帮助你对余下的部分看得更清楚。

其实，你需要打动的那些早期的试用者们是很宽容的。他们并不期待一个新发布的产品无所不能；但是，多少它应该有点儿用处。

10 没有明确的目标用户（Having No Specific User in Mind）

如果你不了解用户，就不可能作出他们喜欢的东西。在前面我曾经提到过，大多数成功的初创公司，都是从解决创始人遇到的问题开始的。这里面有这样一条规则：你所创造的财富是跟你对问题的理解程度成正比的；而你最了解的就是你自己的问题。[4]

这条理论反过来说就是：如果你试图解决一个你不懂的问题，那无异于往自己的脖子上套绞索。

但是还是有很多创始人，喜欢假定存在某些用户愿意用他们的产品，至于这些用户会是谁，他们也不很清楚。那些创始人需要这些产品吗？不，他们不能算是目标市场。那么会是谁呢？年轻人？对本地活动感兴趣的人？还是商业领域的用户？什么样的商业领域？加油站？电影制片厂？还是军工采购商？

你当然可以为与你不同类型的用户打造产品。我们就曾这么做过。问题是，你必须认识到你踏入了一个危险地带。这就好比你在借助仪表在飞行：你自己的直觉将帮不上任何忙。因此你的每一步操作都必须小心谨慎，并且要经常查看你的仪表。

这种情况下，用户就是你的仪表。你必须遵循“从实践中来”的原则。任何主观猜测都是不允许的；你必须接触用户并考察他们的反应。所以，当你为别人而不是你自己设计产品的时候，你必须去说服一些特定的用户来使用你的产品；如果你做不到这一点的话，那么失败是必然的。

11 筹集的资金太少（Raising Too Little Money）

大多数成功的初创公司到某一阶段都会接受投资。这就跟要有多个创始人一样，从统计上来说，是一个保靠的举措。那么，你应该接受多少投资呢?

初创公司的资金是用时间来衡量的。每个还没有盈利的初创公司（几乎所有的初创公司在刚开始时都不可能盈利）在钱花光之前都会有一段时间。这段时间有时候被喻为“跑道”（runway）。这是一个很好的比喻，它在提醒你，当你钱花光的时候，要么起飞，要么撞毁。

太少的钱意味着你没有足够的跑道起飞。当然，起飞的概念也需要视情况而定。通常你需要更上层楼：从仅仅有个想法和正在实现的原型；到有了原型，正在发布；到已经发布了产品，正处于显著的增长期。这也要看投资者的想法，毕竟他们是你在实现盈利前要说服的人。

如果你是从投资人那里接受资金的话，那么数量至少应该能够支撑你到下一个阶段。[5] 幸运的是，你对下一个阶段是什么以及需要花费多少都有所控制。我们建议初创公司在刚开始的时候把这两项指标都设得低一些：基本上不花什么钱，以及把初期目标定为构造一个坚实的原型。这样做会给你最大的灵活性。

12 花销无度（Spending Too Much）

有时候很难把花销无度和筹集的资金太少区分开来。如果钱不够用了，你既可以说是开销太多，也可以说是筹集的资金太少。区分这两条的唯一办法是跟别的初创公司做个比较。如果你筹集了五百万的资金却还是不够用，那么原因就很可能是花销无度。

现在那些乱花钱的烧包们要比以前少多了。创业者们似乎已经学到了教训；再加上创业越来越便宜。所以在写这篇文章的时候，我并没有发现几个初创公司是在烧钱。我们投资的公司里一个都没有。（不仅仅是因为我们的投资都比较小，也因为许多公司都进行了多轮筹资。）

最经典的烧钱方式是雇用一大批人。这么做会对你造成双重伤害：既增加了成本，又减慢了速度。所以说，钱花得越快，你就得想办法让它撑下去的时间越长。许多软件大师们都懂得这一道理；弗雷德·布鲁克斯（Fred Brooks）在他的《人月神话》（The Mythical Man-Month）中作过详细的解说。

对于招人，我们有三条基本的建议：（a）能免则免；（b）用股份代替工资，这样做不仅仅省钱，更重要的是，你希望你的人是愿意把自己的利益同公司的利益挂钩的人；（c）招的人应该仅限于两类，或者写代码，或者出去拉客户，因为刚开始的时候，你只需要做这两件事情。

13 筹集的资金太多（Raising Too Much Money）

筹集的资金太少显然是不行的，那么太多的资金是不是也有问题呢？

是，也不是。关键不在于钱的本身，而在于随之而来的问题。一个风投曾经说过，“一旦你从我这拿了几百万的资金，那么计时就开始了。”风投们给你投资，并不是让你把钱放在银行里然后整天泡碗面；他们希望钱用在工作上。[6] 最起码，你也要有一个像样的办公室，以及一些工作人员。而这会改变你的工作氛围——并不一定是朝有利的方向。现在，你的大多数人马都是你的雇员了，而不是合伙创始人。他们不可能像你那样投入；他们需要有人来告诉他们做些什么；更糟的是，有人会开始玩起办公室里的那些猫腻。

当你筹集了很多钱的时候，你的公司就会搬到繁华地段，并且开始拖家带口。

而更危险的是，一旦你拿到了一大笔钱，那么你就会尝到船大难掉头的滋味。假设你最初的计划是向公司们出售某种产品。从风投那儿拿到钱后，你雇用了一些销售人员来做这事儿。后来你发现，应该把力量投入到消费者身上而不是那些商业公司。销售方式会有根本的不同。这时候，你怎么办？在实际当中，你甚至可能根本认识不到这点。招的人越多，你就越倾向于沿着既定的方向而不做改变。

争取大笔投资的另一个缺陷就是耗时太长。你能筹到的钱跟你所花的时间是成正比的。[7] 当投资达到上百万时，投资者会变得相当谨慎。风投们从来不会明确地说是或不是；他们会没完没了地约你谈话。因此，从风投那里筹集一笔相当规模的资金是一件很花时间的事情——可能比你创业所需的时间还长。当你的竞争者们争分夺秒于开发产品的时候，我想你不会愿意把你的时间都花在投资人身上。

我们建议那些寻求风投的创业者一旦遇到合适的协议就接受它。如果你能够从一个有信誉的基金那里拿到一笔基本合理的钱，并且没有什么不合情理的条条框框的话，那么成交好了；然后投入到建设你的公司里去。[8] 就算你能够从别的地方拿到多三成的钱，又怎么样呢？创业是一个要么赚得盆满钵满，要么输得精光的游戏。为了一点点小利而在投资者间四处游走无疑是在浪费时间。

14 受制于投资者（Poor Investor Management）

作为公司的创始人，你应该掌握公司的投资者。你不应该忽略他们，因为他们可能提供有见地的建议。但你绝不能把公司运作交到他们手上；那应该是你的职责。如果投资者对于运作其所投资的公司有足够的见地的话，那他们干吗不自己创立一个公司呢？

由于忽略投资者而惹恼他们的后果，要比向他们缴械投降的后果轻得多。我们创业的时候，曾经错误地忽略了投资者。结果，跟投资者的争吵牵扯了我们的很多精力。不过，这也要好过投降许多，那样的话，公司可能就完了。一个知道自己在做什么的创始人，就算只花一半的精力在产品上，也比什么都不懂的投资者花上全部的精力要强。

掌握投资者所花的工夫通常取决于你从他们那里拿了多少钱。如果你筹集的资金有相当规模，那么投资者也相应的得到了相当规模的控制权。如果他们在董事会里占了大多数，那么他们就是你名义上的老板。更常见的情形是，创始人和投资者的权重相等，决定性的投票来自于外部的中立董事。这时候，投资人只需要说服那些中立董事，就获得了公司的控制权。

如果一切都很顺利的话，那么这也无所谓。只要你的进展看上去很迅速，大多数的投资者不会插手你的事情。问题是，对于一个初创公司来说，不可能指望一帆风顺。就算那些非常成功的公司，都曾经被投资者找过很大的麻烦。最有名的一个例子就是苹果。它的董事会曾犯过一个致命的错误：解雇了斯蒂夫·乔布斯（Steve Jobs）。（译者：1985年，因为权力斗争，Steve 被赶出了苹果电脑；1996年，随着他的NeXT公司被苹果收购，他又回到苹果，并在1997年重掌大权。请参见 wikipedia 词条。）即使是 Google，早期跟投资者也有过很不愉快的经历。

15 为（不存在的）利润而牺牲用户（Sacrificing Users to (Supposed) Profit）

我在一开始的时候就说过，如果你做的东西是用户需要的，那么应该没什么问题。你可能注意到，我没有提及任何关于正确的商业模式的事情。这并不是说赚钱并不重要。我并不建议创业者们搞那些更本就没有希望赚钱的公司，然后希冀着在倒闭前把公司卖掉。我们告诉创业者们不要担心商业模式的最初原因是觉得搞出一个人们需要的东西要比这难得多。

我并不清楚这件事儿为什么这么难。看起来应该是一件很直截了当的事情。不过，只有为数不多的初创公司做到了这一点。从这儿你就可以看出这件事儿有多难。

正是因为做出一个人们需要的东西要比赚钱难得多，所以你应该稍后再考虑商业模式的问题，就好比你把一些琐碎而麻烦的功能留给第二版一样。在第一版里，解决那些最核心的问题。对于初创公司来说，最核心的问题就是怎样来创造财富（=人们在多大程度上需要你的产品*需要你的产品的人数），而不是怎样把财富转变为钞票。

能够获胜的都是那些用户至上的公司。以 Google 为例，他们先是开发了搜索引擎，然后才考虑怎么赚钱。总有一些初创公司的创始人认为，不在一开始就考虑商业模式是不负责任的举动。这些创始人通常是被那些思想僵化的投资者所蛊惑。

如果说不考虑商业模式是不负责任的举措，那么不考虑产品本身的不负责任性要十倍于此。

16 自命清高（Not Wanting to Get Your Hands Dirty）

几乎所有的程序员都更愿意把时间花在写代码上而另找人去处理商业上与钱有关的龌龊事儿。这并不是因为懒。Larry 和 Sergey 在刚开始的时候显然也是这么认为的。在开发了新的搜索算法后，他们所作的第一个尝试就是找一家公司买下它。

创办一个公司？算了吧。大多数的程序大师们更满足于仅仅有个点子。不过，正如 Larry 和 Sergey 所发现的，点子是没有什么市场的。没人会去相信一个点子，除非你把它用在你的产品里，并以此获得用户。这样人们才会给你更多的关注。

也许这一点会有所改变，不过我很怀疑。对收购者来说，没有比用户更具说服力的东西了。这不仅仅是因为风险降低了；要知道，收购者们都是人，他们很难把几百万的美金砸到一堆年轻人身上，就为了他们机灵。当点子被一个公司实现并且拥有很多用户时，投资者们可以安慰自己，他们买的是用户，而不是看不见摸不到的机灵。这对于他们来说更容易接受些。[9]

如果你想要吸引用户的话，你可能不得不离开你的计算机，到外面去寻找一些用户。这的确不是一项愉快的工作；不过，如果你能够做下来的话，那么成功的几率就大大增加了。2005年夏天，在我们资助的第一批初创公司里，绝大多数的创始人都埋头于编写他们的应用程序。只有一个创始人，花了一半的时间去同手机公司的执行长官们交谈，以敲定一些买卖。对于一个程序员来说，你能想出比这更痛苦的事情吗？[10] 不过，他的付出是有回报的：那家初创公司看起来是那一批里最成功的，他们获得了一大笔订单。

如果你要创办一家公司的话，就必须面对一个事实：你不可能只是坐在那里写程序。至少你们当中的一位需要花费一定的时间在商业上面。

17 内部争斗（Fights Between Founders）

创始人之间的争斗出乎意料地普遍。我们资助的初创公司中，大约20%的公司都有创始人退出的现象。这种频繁发生的事情让我们更加倾向于股权授让（vesting）。尽管不是必须条件，我们还是建议创始人们授让股权，这样，中途有人退出的话，也不会造成什么混乱。

一个创始人的离开并不会毁了公司。许多成功的初创公司都有过类似的情形。[11] 幸运的是，离开的通常都是投入最少的。
假如有三个创始人，其中一个不是很积极的退出了，没什么大不了的。如果有两个创始人，其中的一个走了；又或者离开的那个具备关键技术，那么就可能会有麻烦。就算这样也还不至于天塌下来。Blogger 曾经走得只剩了一个人，但最后又振作了起来。

如果创始人们能够更加谨慎地选择他们的创业伙伴，那么大多数的争吵都可以避免。多数的争吵并不是因事而起，而是因人而起。也就是说，是早晚会发生的。而大多数因为争吵而一怒离开的创始人，可能从一开始就信心不足，只不过被掩饰起来了。不要掩饰你的疑虑。在公司成立前把问题解决掉要容易许多。所以，不要因为怕疏远你的同屋而拉他入伙；也不要因为某人有某种用得上的技能就一起开公司，而不管你喜不喜欢他。一个初创公司，最重要的因素就是人，所以不要在这上面有什么将就。

18 不能够全时投入（A Half-Hearted Effort）

你所听说过的失败的初创公司，都是一些很特殊的例子。他们实际上是失败者中的佼佼者。最通常的失败者并不是因为犯了这些很特殊的错误，而是因为没有做什么事儿——我们从未听说过这些失败者；他们往往是两三个人，在工作之余，玩儿上一把；从未取得过什么真正的进展，渐渐地也就放弃了。

从统计上说，如果想要避免失败的话，一个很重要的事情就是辞掉你的日常工作。绝大多数失败的初创公司，其创始人都属于业余性质；而那些成功的初创公司，创始人都是全副身家扑在了上面。假如把初创公司的失败比作是疾病的话，疾病控制中心就会贴出一张告示，警告大家辞掉日常工作。

这是不是说，你必须辞掉你的日常工作呢？也不一定。我在这里胡乱猜测一下。我想那些还没有辞掉工作的创始人，大多缺少一种创办公司所必需的决心；他们的意识深处是知道这一点的。他们之所以不敢投入更多的时间是因为他们知道，这不是一个好的投资。[12]

我还猜测，有相当多的人，如果能够迈出这一步而全时去做的话，是能够成功的，可惜的是，他们没有这样做。我不知道这样的人有多少，不过，如果把成功者/骑墙者/毫无希望者做个分布的话，那些如果辞掉工作就可能成功的人，要比那些现实中的成功者多出一个数量级。[13]

如果这是真的话，那么大多数有可能成功的初创公司最终失败的原因都是其创始人不能够全心全意地投入在上面。这跟我所得出的结论也是一致的。绝大多数的初创公司之所以失败，是因为他们做不出用户需要的东西；而之所以做不出来，是因为他们的努力不够。

换句话说，创业跟做其它事情一样。你可能犯的最大错误就是不够努力。如果有什么成功的秘诀的话，就是不要否认这一点。

注释

[1] 这个清单并没有列出所有的原因，只列出了那些你能够掌控的因素。有些事情是你没法控制的，比如说，能力不足或是运气不好。

[2] 好笑的是，从 Facebook 衍化出来的一个可行的点子，就是针对那些非在校学生的 Facebook。

[3] Steve Jobs 曾试图用“Real artists ship”来鼓动人们。这是一个很漂亮的句子，可惜并不代表事实。艺术里面的很多著名作品都未完成。对于有明确期限的领域来说，比如建筑和制片，这句话可能是对的。不过就算在这些领域里，人们也总是能拖就拖。

[4] 这里也许还有另一个因素：初创公司的创始人们一般都站在技术的最前沿，他们所面临的问题往往具有很特殊的价值。

[5] 你所筹集的资金，应该比你认为所需要的要多，大概多50%到100%吧。因为编写软件所花的时间往往比你估计的要长很多。

[6] 人们有时候会把我们也叫作风投，我这里要声明一下，我们并不算风投。风投的手笔很大，而且花的是别人的钱；而我们花的是自己的钱，数量也很小，更像是天使投资。

[7] 当然并不是线性的，不然你永远也筹不到五百万美金。不过在实际操作中，你会觉得真的是没个尽头似的。

就算你把风投不可能投资的情况也考虑进去的话，对于一般情况来说，你也会觉得费时太长。而追求大的投资的危险不仅仅在于花费的时间很长，更严重的是，你可能花了时间却拿不到一分钱。

[8] 有些风投会故意压低你的价值来试探你有没有胆量去要求更多。这是一个俗不可耐的游戏，不过的确有些风投在玩儿。如果你在同这样的风投打交道，那么应该在估价上进行一番讨价还价。

[9] 假如 YouTube 的创始人在2005年跑到 Google 说，“你们的视频设计太差了。给我们一千万的话，我们就指出你们犯的所有错误。”那他们肯定会受到嘲笑。可是18个月后，为了买这一课，Google 支付了16个亿。也许部分原因是因为 Google 可以安慰自己：我们是在买一种新事物，一个社区，或是类似的某个模糊概念。

我并不是挑剔 Google。他们已经领先于他们的竞争者了。那些竞争者可能已经错过了视频这班船。

[10] 事实上是有的：就是跟政府打交道。不过电话公司会很高兴。

[11] 这种情况比人们看到的要多得多，因为公司们从来不会宣扬这种家丑。你知道苹果最初有三个创始人吗？

[12] 我并不是瞧不起这些人。我自己也缺少这种果断。在 Viaweb 之后，我曾经有两次都很接近于开办一个公司，但每次都打了退堂鼓。因为我意识到，缺少了生存危机，我很难承受创业的那份紧迫感。

[13] 那么你怎么知道你属于哪类人呢？是那些应该辞掉工作的人？还是更大多数的平平稳稳过日子的人？我得说，单凭你自己是很难作判断的。你必须寻求外部的建议。我们自认自己是投资者，不过从另一个角度看的话，Y Combinator 是一项建议人们辞掉或是不要辞掉工作的服务。我们可能会犯错误，而且是经常犯，但至少，我们是根据我们自己的结论来押宝的。

The 18 Mistakes That Kill Startups

Thu, 23 Jul 2009 00:51:59 +0800

《让你的创业失败的18个昏招》英文原版，带下划线的是译者的话。

来源：http://freddy.cc/article/131

Fllowing is an article about common weaknesses of startups, which usually happens in the internet technology companies. This is so useful to us that I can’t wait to paste it into my blog, thanks to the auther: Paul Graham
And there is also a translated one in Yeeyan.com, I’ll get it soon, and thanks to the translator, too.

In the Q & A period after a recent talk, someone asked what made startups fail. After standing there gaping for a few seconds I realized this was kind of a trick question. It’s equivalent to asking how to make a startup succeed—if you avoid every cause of failure, you succeed—and that’s too big a question to answer on the fly.

Afterwards I realized it could be helpful to look at the problem from this direction. If you have a list of all the things you shouldn’t do, you can turn that into a recipe for succeeding just by negating. And this form of list may be more useful in practice. It’s easier to catch yourself doing something you shouldn’t than always to remember to do something you should. [1]

In a sense there’s just one mistake that kills startups: not making something users want. If you make something users want, you’ll probably be fine, whatever else you do or don’t do. And if you don’t make something users want, then you’re dead, whatever else you do or don’t do. So really this is a list of 18 things that cause startups not to make something users want. Nearly all failure funnels through that.

1. Single Founder

Have you ever noticed how few successful startups were founded by just one person? Even companies you think of as having one founder, like Oracle, usually turn out to have more. It seems unlikely this is a coincidence.

What’s wrong with having one founder? To start with, it’s a vote of no confidence. It probably means the founder couldn’t talk any of his friends into starting the company with him. That’s pretty alarming, because his friends are the ones who know him best.

But even if the founder’s friends were all wrong and the company is a good bet, he’s still at a disadvantage. Starting a startup is too hard for one person. Even if you could do all the work yourself, you need colleagues to brainstorm with, to talk you out of stupid decisions, and to cheer you up when things go wrong.

The last one might be the most important. The low points in a startup are so low that few could bear them alone. When you have multiple founders, esprit de corps binds them together in a way that seems to violate conservation laws. Each thinks “I can’t let my friends down.” This is one of the most powerful forces in human nature, and it’s missing when there’s just one founder.

2. Bad Location

Startups prosper in some places and not others. Silicon Valley dominates, then Boston, then Seattle, Austin, Denver, and New York. After that there’s not much. Even in New York the number of startups per capita is probably a 20th of what it is in Silicon Valley. In towns like Houston and Chicago and Detroit it’s too small to measure.

Why is the falloff so sharp? Probably for the same reason it is in other industries. What’s the sixth largest fashion center in the US? The sixth largest center for oil, or finance, or publishing? Whatever they are they’re probably so far from the top that it would be misleading even to call them centers.

It’s an interesting question why cities become startup hubs, but the reason startups prosper in them is probably the same as it is for any industry: that’s where the experts are. Standards are higher; people are more sympathetic to what you’re doing; the kind of people you want to hire want to live there; supporting industries are there; the people you run into in chance meetings are in the same business. Who knows exactly how these factors combine to boost startups in Silicon Valley and squish them in Detroit, but it’s clear they do from the number of startups per capita in each.
3. Marginal Niche

Most of the groups that apply to Y Combinator suffer from a common problem: choosing a small, obscure niche in the hope of avoiding competition.

If you watch little kids playing sports, you notice that below a certain age they’re afraid of the ball. When the ball comes near them their instinct is to avoid it. I didn’t make a lot of catches as an eight year old outfielder, because whenever a fly ball came my way, I used to close my eyes and hold my glove up more for protection than in the hope of catching it.

Choosing a marginal project is the startup equivalent of my eight year old strategy for dealing with fly balls. If you make anything good, you’re going to have competitors, so you may as well face that. You can only avoid competition by avoiding good ideas.

I think this shrinking from big problems is mostly unconscious. It’s not that people think of grand ideas but decide to pursue smaller ones because they seem safer. Your unconscious won’t even let you think of grand ideas. So the solution may be to think about ideas without involving yourself. What would be a great idea for someone else to do as a startup?

4. Derivative Idea

Many of the applications we get are imitations of some existing company. That’s one source of ideas, but not the best. If you look at the origins of successful startups, few were started in imitation of some other startup. Where did they get their ideas? Usually from some specific, unsolved problem the founders identified.

Our startup made software for making online stores. When we started it, there wasn’t any; the few sites you could order from were hand-made at great expense by web consultants. We knew that if online shopping ever took off, these sites would have to be generated by software, so we wrote some. Pretty straightforward.

It seems like the best problems to solve are ones that affect you personally. Apple happened because Steve Wozniak wanted a computer, Google because Larry and Sergey couldn’t find stuff online, Hotmail because Sabeer Bhatia and Jack Smith couldn’t exchange email at work.

So instead of copying the Facebook, with some variation that the Facebook rightly ignored, look for ideas from the other direction. Instead of starting from companies and working back to the problems they solved, look for problems and imagine the company that might solve them. [2] What do people complain about? What do you wish there was?

5. Obstinacy

In some fields the way to succeed is to have a vision of what you want to achieve, and to hold true to it no matter what setbacks you encounter. Starting startups is not one of them. The stick-to-your-vision approach works for something like winning an Olympic gold medal, where the problem is well-defined. Startups are more like science, where you need to follow the trail wherever it leads.

So don’t get too attached to your original plan, because it’s probably wrong. Most successful startups end up doing something different than they originally intended—often so different that it doesn’t even seem like the same company. You have to be prepared to see the better idea when it arrives. And the hardest part of that is often discarding your old idea.

But openness to new ideas has to be tuned just right. Switching to a new idea every week will be equally fatal. Is there some kind of external test you can use? One is to ask whether the ideas represent some kind of progression. If in each new idea you’re able to re-use most of what you built for the previous ones, then you’re probably in a process that converges. Whereas if you keep restarting from scratch, that’s a bad sign.

Fortunately there’s someone you can ask for advice: your users. If you’re thinking about turning in some new direction and your users seem excited about it, it’s probably a good bet.

6. Hiring Bad Programmers

I forgot to include this in the early versions of the list, because nearly all the founders I know are programmers. This is not a serious problem for them. They might accidentally hire someone bad, but it’s not going to kill the company. In a pinch they can do whatever’s required themselves.

But when I think about what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That’s actually much harder than it sounds—almost impossibly hard in fact—because business guys can’t tell which are the good programmers. They don’t even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?

7. Choosing the Wrong Platform

A related problem (since it tends to be done by bad programmers) is choosing the wrong platform. For example, I think a lot of startups during the Bubble killed themselves by deciding to build server-based applications on Windows. Hotmail was still running on FreeBSD for years after Microsoft bought it, presumably because Windows couldn’t handle the load. If Hotmail’s founders had chosen to use Windows, they would have been swamped.

PayPal only just dodged this bullet. After they merged with X.com, the new CEO wanted to switch to Windows—even after PayPal cofounder Max Levchin showed that their software scaled only 1% as well on Windows as Unix. Fortunately for PayPal they switched CEOs instead.

Platform is a vague word. It could mean an operating system, or a programming language, or a “framework” built on top of a programming language. It implies something that both supports and limits, like the foundation of a house.

The scary thing about platforms is that there are always some that seem to outsiders to be fine, responsible choices and yet, like Windows in the 90s, will destroy you if you choose them. Java applets were probably the most spectacular example. This was supposed to be the new way of delivering applications. Presumably it killed just about 100% of the startups who believed that.

How do you pick the right platforms? The usual way is to hire good programmers and let them choose. But there is a trick you could use if you’re not a programmer: visit a top computer science department and see what they use in research projects.

8. Slowness in Launching

Companies of all sizes have a hard time getting software done. It’s intrinsic to the medium; software is always 85% done. It takes an effort of will to push through this and get something released to users. [3]

Startups make all kinds of excuses for delaying their launch. Most are equivalent to the ones people use for procrastinating in everyday life. There’s something that needs to happen first. Maybe. But if the software were 100% finished and ready to launch at the push of a button, would they still be waiting?

One reason to launch quickly is that it forces you to actually finish some quantum of work. Nothing is truly finished till it’s released; you can see that from the rush of work that’s always involved in releasing anything, no matter how finished you thought it was. The other reason you need to launch is that it’s only by bouncing your idea off users that you fully understand it.

Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.

9. Launching Too Early

Launching too slowly has probably killed a hundred times more startups than launching too fast, but it is possible to launch too fast. The danger here is that you ruin your reputation. You launch something, the early adopters try it out, and if it’s no good they may never come back.

So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible.

This is the same approach I (and many other programmers) use for writing software. Think about the overall goal, then start by writing the smallest subset of it that does anything useful. If it’s a subset, you’ll have to write it anyway, so in the worst case you won’t be wasting your time. But more likely you’ll find that implementing a working subset is both good for morale and helps you see more clearly what the rest should do.

The early adopters you need to impress are fairly tolerant. They don’t expect a newly launched product to do everything; it just has to do something.

10. Having No Specific User in Mind

You can’t build things users like without understanding them. I mentioned earlier that the most successful startups seem to have begun by trying to solve a problem their founders had. Perhaps there’s a rule here: perhaps you create wealth in proportion to how well you understand the problem you’re solving, and the problems you understand best are your own. [4]

That’s just a theory. What’s not a theory is the converse: if you’re trying to solve problems you don’t understand, you’re hosed.

And yet a surprising number of founders seem willing to assume that someone, they’re not sure exactly who, will want what they’re building. Do the founders want it? No, they’re not the target market. Who is? Teenagers. People interested in local events (that one is a perennial tarpit). Or “business” users. What business users? Gas stations? Movie studios? Defense contractors?

You can of course build something for users other than yourself. We did. But you should realize you’re stepping into dangerous territory. You’re flying on instruments, in effect, so you should (a) consciously shift gears, instead of assuming you can rely on your intuitions as you ordinarily would, and (b) look at the instruments.

In this case the instruments are the users. When designing for other people you have to be empirical. You can no longer guess what will work; you have to find users and measure their responses. So if you’re going to make something for teenagers or “business” users or some other group that doesn’t include you, you have to be able to talk some specific ones into using what you’re making. If you can’t, you’re on the wrong track.

11. Raising Too Little Money

Most successful startups take funding at some point. Like having more than one founder, it seems a good bet statistically. How much should you take, though?

Startup funding is measured in time. Every startup that isn’t profitable (meaning nearly all of them, initially) has a certain amount of time left before the money runs out and they have to stop. This is sometimes referred to as runway, as in “How much runway do you have left?” It’s a good metaphor because it reminds you that when the money runs out you’re going to be airborne or dead.

Too little money means not enough to get airborne. What airborne means depends on the situation. Usually you have to advance to a visibly higher level: if all you have is an idea, a working prototype; if you have a prototype, launching; if you’re launched, significant growth. It depends on investors, because until you’re profitable that’s who you have to convince.

So if you take money from investors, you have to take enough to get to the next step, whatever that is. [5] Fortunately you have some control over both how much you spend and what the next step is. We advise startups to set both low, initially: spend practically nothing, and make your initial goal simply to build a solid prototype. This gives you maximum flexibility.

12. Spending Too Much

It’s hard to distinguish spending too much from raising too little. If you run out of money, you could say either was the cause. The only way to decide which to call it is by comparison with other startups. If you raised five million and ran out of money, you probably spent too much.

Burning through too much money is not as common as it used to be. Founders seem to have learned that lesson. Plus it keeps getting cheaper to start a startup. So as of this writing few startups spend too much. None of the ones we’ve funded have. (And not just because we make small investments; many have gone on to raise further rounds.)

The classic way to burn through cash is by hiring a lot of people. This bites you twice: in addition to increasing your costs, it slows you down—so money that’s getting consumed faster has to last longer. Most hackers understand why that happens; Fred Brooks explained it in The Mythical Man-Month.

We have three general suggestions about hiring: (a) don’t do it if you can avoid it, (b) pay people with equity rather than salary, not just to save money, but because you want the kind of people who are committed enough to prefer that, and (c) only hire people who are either going to write code or go out and get users, because those are the only things you need at first.

13. Raising Too Much Money

It’s obvious how too little money could kill you, but is there such a thing as having too much?

Yes and no. The problem is not so much the money itself as what comes with it. As one VC who spoke at Y Combinator said, “Once you take several million dollars of my money, the clock is ticking.” If VCs fund you, they’re not going to let you just put the money in the bank and keep operating as two guys living on ramen. They want that money to go to work. [6] At the very least you’ll move into proper office space and hire more people. That will change the atmosphere, and not entirely for the better. Now most of your people will be employees rather than founders. They won’t be as committed; they’ll need to be told what to do; they’ll start to engage in office politics.

When you raise a lot of money, your company moves to the suburbs and has kids.

Perhaps more dangerously, once you take a lot of money it gets harder to change direction. Suppose your initial plan was to sell something to companies. After taking VC money you hire a sales force to do that. What happens now if you realize you should be making this for consumers instead of businesses? That’s a completely different kind of selling. What happens, in practice, is that you don’t realize that. The more people you have, the more you stay pointed in the same direction.

Another drawback of large investments is the time they take. The time required to raise money grows with the amount. [7] When the amount rises into the millions, investors get very cautious. VCs never quite say yes or no; they just engage you in an apparently endless conversation. Raising VC scale investments is thus a huge time sink—more work, probably, than the startup itself. And you don’t want to be spending all your time talking to investors while your competitors are spending theirs building things.

We advise founders who go on to seek VC money to take the first reasonable deal they get. If you get an offer from a reputable firm at a reasonable valuation with no unusually onerous terms, just take it and get on with building the company. [8] Who cares if you could get a 30% better deal elsewhere? Economically, startups are an all-or-nothing game. Bargain-hunting among investors is a waste of time.

14. Poor Investor Management

As a founder, you have to manage your investors. You shouldn’t ignore them, because they may have useful insights. But neither should you let them run the company. That’s supposed to be your job. If investors had sufficient vision to run the companies they fund, why didn’t they start them?

Pissing off investors by ignoring them is probably less dangerous than caving in to them. In our startup, we erred on the ignoring side. A lot of our energy got drained away in disputes with investors instead of going into the product. But this was less costly than giving in, which would probably have destroyed the company. If the founders know what they’re doing, it’s better to have half their attention focused on the product than the full attention of investors who don’t.

How hard you have to work on managing investors usually depends on how much money you’ve taken. When you raise VC-scale money, the investors get a great deal of control. If they have a board majority, they’re literally your bosses. In the more common case, where founders and investors are equally represented and the deciding vote is cast by neutral outside directors, all the investors have to do is convince the outside directors and they control the company.

If things go well, this shouldn’t matter. So long as you seem to be advancing rapidly, most investors will leave you alone. But things don’t always go smoothly in startups. Investors have made trouble even for the most successful companies. One of the most famous examples is Apple, whose board made a nearly fatal blunder in firing Steve Jobs. Apparently even Google got a lot of grief from their investors early on.

15. Sacrificing Users to (Supposed) Profit

When I said at the beginning that if you make something users want, you’ll be fine, you may have noticed I didn’t mention anything about having the right business model. That’s not because making money is unimportant. I’m not suggesting that founders start companies with no chance of making money in the hope of unloading them before they tank. The reason we tell founders not to worry about the business model initially is that making something people want is so much harder.

I don’t know why it’s so hard to make something people want. It seems like it should be straightforward. But you can tell it must be hard by how few startups do it.

Because making something people want is so much harder than making money from it, you should leave business models for later, just as you’d leave some trivial but messy feature for version 2. In version 1, solve the core problem. And the core problem in a startup is how to create wealth (= how much people want something x the number who want it), not how to convert that wealth into money.

The companies that win are the ones that put users first. Google, for example. They made search work, then worried about how to make money from it. And yet some startup founders still think it’s irresponsible not to focus on the business model from the beginning. They’re often encouraged in this by investors whose experience comes from less malleable industries.

It is irresponsible not to think about business models. It’s just ten times more irresponsible not to think about the product.

16. Not Wanting to Get Your Hands Dirty

Nearly all programmers would rather spend their time writing code and have someone else handle the messy business of extracting money from it. And not just the lazy ones. Larry and Sergey apparently felt this way too at first. After developing their new search algorithm, the first thing they tried was to get some other company to buy it.

Start a company? Yech. Most hackers would rather just have ideas. But as Larry and Sergey found, there’s not much of a market for ideas. No one trusts an idea till you embody it in a product and use that to grow a user base. Then they’ll pay big time.

Maybe this will change, but I doubt it will change much. There’s nothing like users for convincing acquirers. It’s not just that the risk is decreased. The acquirers are human, and they have a hard time paying a bunch of young guys millions of dollars just for being clever. When the idea is embodied in a company with a lot of users, they can tell themselves they’re buying the users rather than the cleverness, and this is easier for them to swallow. [9]

If you’re going to attract users, you’ll probably have to get up from your computer and go find some. It’s unpleasant work, but if you can make yourself do it you have a much greater chance of succeeding. In the first batch of startups we funded, in the summer of 2005, most of the founders spent all their time building their applications. But there was one who was away half the time talking to executives at cell phone companies, trying to arrange deals. Can you imagine anything more painful for a hacker? [10] But it paid off, because this startup seems the most successful of that group by an order of magnitude.

If you want to start a startup, you have to face the fact that you can’t just hack. At least one hacker will have to spend some of the time doing business stuff.

17. Fights Between Founders

Fights between founders are surprisingly common. About 20% of the startups we’ve funded have had a founder leave. It happens so often that we’ve reversed our attitude to vesting. We still don’t require it, but now we advise founders to vest so there will be an orderly way for people to quit.

A founder leaving doesn’t necessarily kill a startup, though. Plenty of successful startups have had that happen. [11] Fortunately it’s usually the least committed founder who leaves. If there are three founders and one who was lukewarm leaves, big deal. If you have two and one leaves, or a guy with critical technical skills leaves, that’s more of a problem. But even that is survivable. Blogger got down to one person, and they bounced back.

Most of the disputes I’ve seen between founders could have been avoided if they’d been more careful about who they started a company with. Most disputes are not due to the situation but the people. Which means they’re inevitable. And most founders who’ve been burned by such disputes probably had misgivings, which they suppressed, when they started the company. Don’t suppress misgivings. It’s much easier to fix problems before the company is started than after. So don’t include your housemate in your startup because he’d feel left out otherwise. Don’t start a company with someone you dislike because they have some skill you need and you worry you won’t find anyone else. The people are the most important ingredient in a startup, so don’t compromise there.

18. A Half-Hearted Effort

The failed startups you hear most about are the spectactular flameouts. Those are actually the elite of failures. The most common type is not the one that makes spectacular mistakes, but the one that doesn’t do much of anything—the one we never even hear about, because it was some project a couple guys started on the side while working on their day jobs, but which never got anywhere and was gradually abandoned.

Statistically, if you want to avoid failure, it would seem like the most important thing is to quit your day job. Most founders of failed startups don’t quit their day jobs, and most founders of successful ones do. If startup failure were a disease, the CDC would be issuing bulletins warning people to avoid day jobs.

Does that mean you should quit your day job? Not necessarily. I’m guessing here, but I’d guess that many of these would-be founders may not have the kind of determination it takes to start a company, and that in the back of their minds, they know it. The reason they don’t invest more time in their startup is that they know it’s a bad investment. [12]

I’d also guess there’s some band of people who could have succeeded if they’d taken the leap and done it full-time, but didn’t. I have no idea how wide this band is, but if the winner/borderline/hopeless progression has the sort of distribution you’d expect, the number of people who could have made it, if they’d quit their day job, is probably an order of magnitude larger than the number who do make it. [13]

If that’s true, most startups that could succeed fail because the founders don’t devote their whole efforts to them. That certainly accords with what I see out in the world. Most startups fail because they don’t make something people want, and the reason most don’t is that they don’t try hard enough.

In other words, starting startups is just like everything else. The biggest mistake you can make is not to try hard enough. To the extent there’s a secret to success, it’s not to be in denial about that.

Notes

[1] This is not a complete list of the causes of failure, just those you can control. There are also several you can’t, notably ineptitude and bad luck.

[2] Ironically, one variant of the Facebook that might work is a facebook exclusively for college students.

[3] Steve Jobs tried to motivate people by saying “Real artists ship.” This is a fine sentence, but unfortunately not true. Many famous works of art are unfinished. It’s true in fields that have hard deadlines, like architecture and filmmaking, but even there people tend to be tweaking stuff till it’s yanked out of their hands.

[4] There’s probably also a second factor: startup founders tend to be at the leading edge of technology, so problems they face are probably especially valuable.

[5] You should take more than you think you’ll need, maybe 50% to 100% more, because software takes longer to write and deals longer to close than you expect.

[6] Since people sometimes call us VCs, I should add that we’re not. VCs invest large amounts of other people’s money. We invest small amounts of our own, like angel investors.

[7] Not linearly of course, or it would take forever to raise five million dollars. In practice it just feels like it takes forever.

Though if you include the cases where VCs don’t invest, it would literally take forever in the median case. And maybe we should, because the danger of chasing large investments is not just that they take a long time. That’s the best case. The real danger is that you’ll expend a lot of time and get nothing.

[8] Some VCs will offer you an artificially low valuation to see if you have the balls to ask for more. It’s lame that VCs play such games, but some do. If you’re dealing with one of those you should push back on the valuation a bit.

[9] Suppose YouTube’s founders had gone to Google in 2005 and told them “Google Video is badly designed. Give us $10 million and we’ll tell you all the mistakes you made.” They would have gotten the royal raspberry. Eighteen months later Google paid $1.6 billion for the same lesson, partly because they could then tell themselves that they were buying a phenomenon, or a community, or some vague thing like that.

I don’t mean to be hard on Google. They did better than their competitors, who may have now missed the video boat entirely.

[10] Yes, actually: dealing with the government. But phone companies are up there.

[11] Many more than most people realize, because companies don’t advertise this. Did you know Apple originally had three founders?

[12] I’m not dissing these people. I don’t have the determination myself. I’ve twice come close to starting startups since Viaweb, and both times I bailed because I realized that without the spur of poverty I just wasn’t willing to endure the stress of a startup.

[13] So how do you know whether you’re in the category of people who should quit their day job, or the presumably larger one who shouldn’t? I got to the point of saying that this was hard to judge for yourself and that you should seek outside advice, before realizing that that’s what we do. We think of ourselves as investors, but viewed from the other direction Y Combinator is a service for advising people whether or not to quit their day job. We could be mistaken, and no doubt often are, but we do at least bet money on our conclusions.

Thanks to Sam Altman, Jessica Livingston, Greg McAdoo, and Robert Morris for reading drafts of this.

关于Event的target属性和currentTarget属性

Mon, 06 Jul 2009 00:24:25 +0800

target 返回的是鼠标当前侦听的对象中最底层的事件接收元件，不管嵌套了多少层，都返回当前事件侦听对象的最底层的元件对象。
currentTarget 指向的是添加这个事件侦听的对象本身，如：mc.addEventListener(…) ，则currentTarget返回的是mc本身。

在主时间轴上写stage.addChild(mc)与addChild(mc)有什么不同？

Sun, 05 Jul 2009 15:57:48 +0800

容器不同

http://bbs.actionscript3.cn/thread-29081-1-1.html

主时间轴上写的代码最后都是会变成文档类里的代码
因此this就是root，this可省略
而stage是root的父亲
因此stage.addChild(mc)结构是这样
/ mc
stage
\ root
而addChild(mc)结构是这样
stage – root – mc

如果用addChild(mc)，删除的时候用root.removeChild(mc)是不行的，但直接用removeChild(mc)是可以的，为什么

因为root属性的返回类型是DisplayObject
而DisplayObject没有removeChild等相关方法
可以把root强行转换成MovieClip或Sprite等
MovieClip(root).removeChild(mc)
这涉及到oop里面类的多态和类型转换等

FLASH CS4(as3)如何直接载入图片

Sun, 05 Jul 2009 15:49:48 +0800

//加载必要的类

import flash.display.Loader;

import flash.net.URLRequest;

//新建loader

var loader:Loader = new Loader();

addChild(loader);

loader.load(new URLRequest("http://lite3.cn/logo/logo.jpg"));

Flash AS3学习记录——AS3.0如何实现定时

Sun, 05 Jul 2009 15:47:41 +0800

在AS3中使用定时器，用Timer对象，方法如下：

var timer:Timer = new Timer(10000);                                //新建一个Timer对象，参数是定时间隔，单位是毫秒。
timer.addEventListener(TimerEvent.TIMER, timerHandler);   //为此事件添加侦听
timer.start();                                                                  //启动定时
function timerHandler(event:TimerEvent):void{                  //定时调用的函数
        //这里是需要定时处理的语句
        timer.delay += 4000;
}