导语:红杉资本上周紧急召集旗下投资组合成员公司的CEO开会,向他们强调经济形势的严峻性。会上,红杉资本还致信旗下公司CEO,提醒他们在经济寒冬该如何慎用资金: 亲爱的红杉公司CEO,
现在到了十分危急的时刻。大家注意到谷歌、雅虎和思科等公司最近的股价了吗?他们全都暴跌。谷歌的市盈率已跌至只有原来的二十分之一。你们知道这意味着什么吗?红杉资本合伙人的净资产总计损失达几十亿美元。数十亿美元啊!遭受如此大的损失,我们现在都不再是亿万富豪了。当初,纳斯达克突破2500点时,我们公司至少有六个亿万富豪。现在一个都没有了。也就是说,本打算50出头退休的我们,现在若想实现亿万富豪的人生目标,大多数人只能继续奋斗下去。我们也许再也看不到10亿美元了?还是打消这种想法吧。
大家应该了解的另一件事是,在我们有限的投资者面前,我们再次显得山穷水尽了。我们在互联网泡沫破裂时也曾遭遇类似的危机,当时,我们过于自信,在那种情况下还坚持收购了Webvan和eToys。尽管我们的创始人唐·瓦伦丁(Don Valentine)早在1999年中期就预测“将有许多互联网公司破产”,但我们仍做出这些投资。现在全世界都知道,我们是惨败而归。我们不得不站在所有投资者面前,对我们如此愚蠢的行为表示歉意。想想吧,红杉资本竟然公开道歉!
也许,一系列投资的成功冲昏了我们的头脑,让我们不知不觉放松了警惕。我们在YouTube的投资带来了8亿美元的回报,投资其他Web 2.0公司也让我们获利数百万美元。我们本应该更早敲响警钟,现在,我们想提醒大家再次注意红杉资本对我们所投资的公司的各项要求:
1、市场规模和时机就是一切!我们不会花钱去告诉人们,他们为何要喜欢你们的产品。很多VC在刚起步的公司身上浪费了几十亿美元,这些公司在市场尚未形成之前便去开发产品。
2、我们还要重申一下第一点的重要性,也就是说,市场规模比你们本人更加重要。正如我们一向说的那样,你们不能改变市场机遇,但可以撤换CEO。
3、我们的投资理念是,仅仅用一根火柴点燃地狱般的火海。假如你们不理解这个类比,我们再解释一遍,那就是产品一定要做到节约,节约,再节约!任何刚刚起步的公司只有两项任务:一是“生产产品”,一是“销售产品”。如果你们的团队中有人做不到这两点,那就炒他的鱿鱼。
4、不要租用昂贵的办公楼,不要铺张浪费。
5、聘请一些年轻聪慧的移民。他们的薪水比最低工资水平稍高,每周可以工作100个小时以上——相信我们。红杉资本有个秘密:过去15年,在我们多数最划算的投资交易中,对方的创业团队中都有二十出头、很有拼劲的年轻移民,例如谷歌的塞吉·布林(Sergey Brin)和YouTube的陈士骏。
6、一旦产品开发出来,你们就应该考虑减少工程师数量,因为他们中很多人已不再有用。工程效率才是至关重要的!
7、管理层每一个人都应参与产品销售,这样,管理人员才能真正了解自己所销售的产品以及如何成功进行销售。这件事情必须在扩大销售团队之前进行。
8、解散吃得肥头大耳的销售团队,硅谷到处充斥着这些拿着高额底薪和奖金的销售人员。把底薪控制在最低水平,在销售人员实现较高的销售目标后再给予他们大量奖励。
9、要明察市场,打击竞争对手,揭露他们的缺陷,在经济不景气的情况下更要如此。他们受伤了,才会安静下来。绝不能像他们一样。要么进攻,要么等死。
10、现金比你妈妈更重要!(你们已经领会到这一点了吗?)
现在的确已到了危急时刻。与其它所有投资集团一样,我们也通过PowerPoint解释当前世界上正在发生的事情,但我们也不知道到底怎么了。我们唯一清楚的是,将类似YouTube这样一家已没有多大盈利空间的公司以超过16亿美元价格卖给谷歌的日子已经一去不复返了,至少现在来说是这样的。如果你们仍对自己的公司抱有这种幻想,那么在下一轮融资行动中,你们可能要到Kleiner Perkins碰运气了,我们将不再向你们提供资金。
让我们重申一次:在用光我们提供的资金之前,你们的现金流仍没有什么起色的话,那就不要再伸手向我们要钱!(杨琳)
图片出处http://www.gracecode.com/Archive/Display/495
也许这张图告诉我们,怎么样去成为一个自己,也怎么样成为一个优秀的团队成员,也告诉我们怎么样去创造一个优秀的团队!
SNS这个看上去很美的东西,这个东西能够代替掉现有的社区和BBS吗?能够代替掉网络游戏吗?或许SNS只是一种概念…尤如沿途的美丽风景,在走远后,什么都不存在了。。
WEB2.0这个很值钱的东西,并不是说他很赚钱。但是他能够带来很多具体的东西,而这个东西可以快速地应用到很多产品当中,也可以与很多行业相互之间合作,带来美好的钱途。
有人问一个网络游戏应该往哪发展?大多数人都会回答很多很好的玩法和和功能,更加拉风的运营模式,这些一直是网络游戏的发展趋势吗?那么一个游戏社区网站又能提供什么?伴随着各大游戏厂商都推出自己的社区系统。
玩 家在网络游戏社区2.0中不再以游戏功能为导向,而是以同在游戏内的其他玩家为导向。网络游戏社区2.0提供的是一个场所,一个话题,一个工具把玩家聚合在一起,所有玩家享受的是由其他玩家创造的乐趣。而它是一个大社区,由人组成,不管是网络游戏本身还是网络游戏社区活动,都真正为玩家服务,推动刺激玩家贡献出他们的力量,而后连接起庞大的用户群体。
而众多公会发展到今天,都有自己独立的一个群体,有自己独立的一个BBS,有独立的语音频道。怎么样为他们创造平台?创造利益是我们当前所应该注册与想到的,也许这就是一个出发点。而我相信这些游戏网这个团队都能够做到,我们在通向成功的道路上曲折前进,坚持自己的理想!
本 文来自于 Rational Edge:像 Rational 统一过程(RUP)和 Zachman 这样的架构框架能够帮助我们了解大型系统,以及如何查阅系统的依赖关系。但是当一个分析团队在检验一个真正的系统模型时,模型里的不同视图究竟表达了什么 信息,分析团队成员在这方面彼此仍然会有误解。本文提出了一个改进方法来描述一个复杂系统模型所涉及的这些方面。
在 我从事的许多项目里,与我的同事们进行的关于系统模型和如何将它们划分成几部分的讨论通常令人困惑而且不是很有效果。我认为问题之一是我们缺少组织和操作 模型以及考虑其结构的通用方法。因此,在这篇文章里,我将就此问题提出我的观点并提供在操作系统模型和软件时对我来说十分有用的四个维度。
最具代表性的是,一个系统模型包含系统的许多 方面。为了传达所有这些方面的信息,我们需要以某种方式组织模型,这意味着模型必须根据一些层次的规则被分成几部分。有许多关于这些规则的层次设置,最具 代表性的是“架构框架”。一个架构框架提供关于一个系统模型应该由哪些部分组成以及模型因此应该描述系统哪些有趣的方面的信息。一个架构框架可能也会提供 其他一些东西,但这篇文章的目的是将重点放在模型划分方面。
IEEE1471层次
实际上有一个软件系统架构描述的层次:IEEE1471-2000。这个层次定义了一些术语,如系统、架构、架构描述、模型、视图、观点等等。同时也在“架构描述的概念模型”上详细说明了这些术语之间的关系,如图1所示。
注释:mission:任务;architecture:结构样式;stakeholder:利益相关;
图1:IEEE1471概念模型
现在,让我们考虑图1用到的一些术语。我将在下面一一讨论。
模型
正如我早期所提到的,模型是将要建立的系统的抽象。它们可以通过使用一些技术,包括统一建模语言(UML)被创建出来。
一个系统和它的架构描述可以创建在一个或多个模型中。有许多方法将这一描述划分到独立的模型中,但是至少从概念上来说,我们通常可以将所有的模型信息视为一个单独的模型。
视图
视图代表了信息表述,您将在模型中查找到的描述或者某个维度的独立片断。模型中一个特定的信息片断可能被视为是零个、一个或者更多的视图。如果您为我们的模型使用统一建模语言,大多数视图将以一些类型的统一建模语言图的形式呈现。
观点
如果模型是信息的来源而且视图包含了信息的表述,那么观点就是定义应该如何生成这些视图表述。观点可以被认为是关于在每个视图里要表述什么类型的信息以及如何进行表述的规则集合。我们可以认为模型和视图是我们所看到的东西,而观点就是我们看到这些东西的眼镜。
如图1所示,IEEE1471层次规定每个观点应该表达对一个或多个涉众的关注。这意味着应该了解观点和涉众之间的映射关系。
架构框架的例子
正如上面所提到的,可以得到许多种架构框架。在这里我将描述一些框架的各个维度,在下部分将谈论我是如何看待将模型划分几个部分的。
IBM Rational 统一过程?或者 RUP(Rational Unified Process,统一软件开发过程,统一软件过程)),包含一个被称为“软件架构4+1视图”的架构框架。 2 这个框架为软件架构描述了五个必要的视图(或者更准确的说法是IEEE1471意义上的观点)。这些视图(观点)如图2中所示。
图2:软件架构的4+1视图
在4+1视图架构框架里,视图包括:
用例视图(use-Case view)
处理系统应该做什么,通过遵循层次的用例建模技术,用参与者和用例来表示。
逻辑视图 (Logical View)
处理系统的逻辑架构——例如,系统如何被划分成逻辑子系统、它们的关系以及它们的相互作用。
进程视图(Process View )
处理系统运行的控制线程,根据进程和线程来表示。
实现视图 (Implementation View)
解释系统如何根据文件结构来实现。
部署视图(Deployment View)
处理系统如何在计算机和这些计算机的网络连接上运行。软件架构的4+1视图很好地为以软件为中心的系统工作。如果系统更加复杂——例如由硬件、软件、可能还有人组成的分布式系统——那么需要一个更加复杂的架构框架,这将我们带入下一个架构框架。