behind the cloud 读后感

编者按:忽如一夜春风来,千树万树梨花开。SaaS在国内的处境正如诗中所述,正值春天。2014年,中国SasaS蓬勃发展;2015年,会有更多的创业者进入SaaS创业这个领域,也会有越来越多的风险投资进入这个市场,因此,了解SaaS这个行业的来龙去脉,了解SaaS这个领域的一个基本商业常识,就变得非常必要。在这里,OneAPM的创始人何晓阳分享了他的一篇读后感,他所读的书是Salesforce.com创始人马克贝尼奥夫写的《behind the cloud》,中文名字是《云攻略》。Salesforce.com作为全球市值最高的SaaS公司,又是SaaS这个商业模式的开创者,他们的故事一定很值得阅读。

《behind the cloud》中文版读后感

作者:OneAPM 何晓阳

我们人类这个群体,普遍缺乏必要的耐心和想象力。我们总是很容易把自己日常使用的一些东西看的很普通,正所谓“司空见惯”。比如说我们天天使用的手机,比如说我们天天使用的浏览器,比如说我们天天乘坐的汽车和飞机,等等。除了重塑手机的乔帮主,我们也不大知道浏览器的发明者马克.安德森和他的网景公司,我们也不大记得汽车产业的开创者卡尔.奔驰,然而,如果你是一个创业者,你应该知道,这些让人们天天使用的东西,正是商业历史上最伟大的成就和奇迹。我们需要了解背后的故事,以从中获取经验和心得。今天,就有这样一本书,讲述SaaS这个我们今天看来很普遍的东西,到底是如何诞生的。

Salesforce.com,在今天市值接近400亿美元,而且还在不断地突破、创新、发展,我们知道,一家公司,其行为和创始人的性格有非常大的关系。那么,Salesforce.com的创始人马克贝尼奥夫亲手写就的这本书,并且是讲述自己的故事,讲述Salesforce.com Zeroto one的过程,对于任何一个在SaaS领域创业的人来说,不可不读。

本书共分为九个部分,马克分别从初创、市场、活动、销售、技术、企业慈善、全球化、财务和融资、管理这些领域,讲述了自己的心得。难得的是,马克是按照时间顺序来进行叙述的,这让一个创业者可以清晰的比对自己公司的发展阶段。

在初创这一章我们了解了以下事实

马克技术出身,在80年代中期加入Oracle的时候,Oracle只有200人,马克从电话客服和销售做起,业绩优秀,当Oracle直销部门主管Tom Siebel离职的时候,推荐马克接替了职位。马克在这个位置功勋卓著,后来做到了高级副总裁的职位。马克自己除了在Oracle的工作,另外还做一些天使投资的事情,比如他投资了Tom Siebel创立了Siebel公司,并且在Siebel 1996年上市的时候获得了丰厚的回报。

由于经常做天使投资,创业对马克不是一个没有概念的事情。他认为,互联网必将改变传统软件存在的方式,他希望做到的是将消费网站的模式,比如amazon,移植到商业软件领域。在今天我们看到,这已经成为了一个普遍的遍地开花的事实,但在当时,却没有多少人想到。预测未来人类的生活和工作方式,并且从中挑出现在还没有改变的加以改变,是美国创业的主要思路。

马克开始Salesforce.com这件事情,在今天的我们看来,也是一个最正确的逻辑,他自己有相当的经济实力,Oracle老板拉里.埃里森和他是亦师亦友关系,直接给了马克200万美元的天使投资,并加入董事会。马克熟悉销售自动化(SFA)这个领域,知道哪里有优秀的人才,直接把左岸公司这个优秀的SFA领域最优秀的开发团队纳入麾下,并且在拉里的允许下从Oracle公司挑选了自己需要的人才。事实上在我看来,在第一章马克遇到的最大的挑战,就是从Oracle公司离职,全职开始Salesforce.com,而且他的阻碍不是别人,正是自己。对于今天在职场如鱼得水的人们,尽管很多人会有创业的想法,但是可能永远也不会付诸实施。

第二章讲述市场

OK,我们知道Salesforce.com开张了,拿到了投资(别忘了这是1999年),招到了优秀的研发和一些销售,搬到了一个700多平的办公室,开始大张旗鼓的干活了。他们第一个月就做出了一个简单的雏形。那么下面做什么呢?

市场!

是的,对于一个创业公司来说,如果你做事情的节奏对了,在其他领域没有硬伤,那么确实应该在这个时候把主要的时间和精力放在市场上。Salesforce.com在市场这件事情上的做法非常完美,他们成功的做到了很多事情,例如成功的进行了公司的定位:SaaS和SFA行业的先驱者;成功的宣传了自己的理念:No Software;成功的塑造了马克个人的印象:在宴会上身穿军装,扮演革命者;成功的明确了公司的使命。并且,在这一系列的市场行为中,培养了与媒体的良好关系,在一开始,就经常被媒体拿来和行业的强者:Siebel公司进行比较。

Salesforce.com在市场这件事情上,进行了非常多富有创造性的工作,并且,市场行为非常有攻击性,处处针对Siebel,这里有很多精彩的故事,推荐大家重点阅读。

第三章讲述活动

在Salesforce.com创立两年之后,马克第一次统计了他们的市场行为的投入产出比,结果令他震惊了,烧了那么多的钱,但只有14个潜在客户。是的,是时候改变了,市场行为成功的打出了品牌,制造了轰动效应,但这对赢得客户毫无帮助。市场行为进行一段时间之后,需要调整原始的市场策略,变为更加行之有效的市场营销方式。

马克发现,转化率最高的市场营销方式就是两种,一个是新闻报道,新闻媒体上无偏见的商业和科技报道;另外一个是客户推荐,客户之间分享成功经验而形成的口碑效应。因此,Salesforce.com发明了一种沿用至今的方法,就是把现有客户和潜在客户放在一起交流,当然,交流的方式多种多样,城市巡回活动,选择最高大上的场所,通过高档次的体验;另一种是鸡尾酒party,包括主题发言,1~2个客户的报告,一个演示和几倍冰茶。

事实上,做市场活动的时候,有一个简单法则,如果你是一个小公司,那么你要拼命的打击你的最大的竞争对手,如果你已经是这个市场的领导者了,那么不要在意任何竞争对手对你的挑衅,不要回应。优秀的领导者在市场行为上总是善于创新,而平庸的选手只能跟随。

第四章讲述销售

在SaaS的销售领域,有很多规则沿用至今,这些规则很多都是Salesforce.com最初发明的,在本章,我们了解到了这些发明背后的故事以及逻辑。

作为一个SaaS公司,又做了那么多的市场宣传,肯定会有很多潜在的用户来访问你的网站,这个时候需要提供的是免费的试用,虽然现在免费试用几乎是SaaS行业的标准,但是这在当时绝对是一个非常大的创新。当客户试用的时候,通过电话销售团队进行客户跟踪,并将免费客户转化为付费客户。Salesforce.com很快成立了电话销售团队,并使用互联网时代的一切新型手段来和客户联系。从某些意义上来讲,销售是一个数字的游戏,销售人员的数量而非质量决定了公司的收入,一个公司员工基数的20%~50%应该是销售人员,在Salesforce.com,这个数字是50%。

正在Salesforce.com飞速发展的时候,.com crash的时间到了,一夜之间,几乎所有的互联网公司都开始出现资金不足的情况,大多数公司都苦苦挣扎甚至倒闭。在2001年11月份的时候,Salesforce.com每个月要亏损100~150万美元,而且出现了严重的现金流不足,潜在的破产即将到来。不幸的是,这个时候的VC们都成了惊弓之鸟,再也不肯拿钱出来了。这个时候走投无路的Salesforce.com发明了SaaS领域重要的规则之一:按照年来签订合同,并且提前付费。如果客户认可年度付费方案,那么可以得到一个不错的折扣。而且对于销售人员来说,一个提前付费的年度合同可以对应一个立即生效的佣金收入。这个决定成为Salesforce.com收入增长的一个重要分水岭。事实上,如果你能够看到,大多数的SaaS公司都不盈利,但是他们都活的很好,就是因为这个,他们有非常好的现金流

当业务在小型客户中得到认可的时候,就要开始逐渐开始把大客户作为目标。如果以大客户作为目标,就需要一支非常优秀的现场销售团队。(这个逻辑放之四海而皆准,即使是在今天。New Relic上市之后,为了获得更大的客户,他们组建了一个世界级的优秀现场销售团队,这个销售团队的领导者就是原来Salesforce.com的CMO),一个优秀的企业级销售人员,不同于大多数人对销售的认知。这里,书中描述非常准确而精彩,希望大家能够好好吸收。

第五章是讲述技术方面的内容。

除了一些技术圈的常识,比如说要用好既有工具,不要造轮子等之外,主要讲述了三方面的内容。

第一,由于上述销售策略的引进,客户数量和每个签约客户所包含的用户量都在飞速上升,Salesforce.com系统的访问量飞速上涨,很快遭遇了性能瓶颈(咦,怎么这么熟悉,好像在哪里听过^_^)。 Salesforce.com在05年的时候经常宕机,并且被竞争对手落井下石,可靠性问题被多家新闻媒体四处报道,一时之间,他们遇到了***烦,进入了极其艰难的时期。更要命的是,Salesforce.com的技术团队无法确定故障根源之所在,他们开始怀疑目前的代码基础是否可靠,很多团队内部的人开始质疑自己的技术能否适应大规模客户访问的要求。Salesforce.com的工程师团队的选择是尝试重新开发软件的相关功能模块,虽然他们不知道是哪个模块(OMG!),并完成性能测试。他们把所有的技术资源都用于解决这个问题,停止了所有功能的更新,工程师们全天24小时工作来解决问题,其他人则是不知道干什么,因为他们不知道如何面对愈演愈烈的批评。他们停止接听电话,也停止了回复电话。

随着危机的进一步加深,Salesforce.com选择了召集全球250名高级经理开会,商议如何解决系统的可用性和性能问题,就在开会期间,他们遭遇了有史以来最糟糕的服务中断,系统整整宕机了90分钟。宕机期间,媒体联系不到任何Salesforce.com的人,因为他们都正在开会。

【我最近喜欢提一句话,出自我最喜欢的《2001太空漫游》,“他们身处丰饶之中,却逐渐饥渴致死”。 Salesforce.com的技术部门可以说是全球顶级,因为他们很多人都来自于Oracle、SUN、Symantec等公司,但是他们在遇到问题的时候却没有选择正确的应对方式,事实上,应用性能问题就应该用性能管理软件来搞定,而不是瞎猜。当时的APM产品Wily Introscope已经是相当成熟的产品了,他们为什么不一开始就用呢?】

最终Salesforce.com选择了实时监控系统性能并且加以公开的方法解决这个问题,他们采用了类似于statuspage.io的解决方案,把服务可用性状态公开给用户,他们让公众甚至竞争对手可以看到系统每天的运行状况,他们把这个称为信任网站,地址是trust. Salesforce.com。我们打开网站就可以看到:

马克写道:如果我们不是经常改进技术并优化访问速度和可用性,我们就不可能走到今天。2009年第一季度,我们服务可用性超过99.99%,每天拥有2亿交易量,并且响应时间小于1秒。

【这里做个广告:如果你不想在业务飞速上升期重蹈覆辙,请选择OneAPM.com】

第二个方面的内容,是提供API,这点对于大多数国内的SaaS厂商来说,这一章是应该深入学习的一部分,通过提供API来客户自己定制展示和访问的方式,在SaaS领域会远远超过应用本身。这个领域可能国内多数厂商刚刚有意识,其实最快的方式是使用第三方SaaS方式的API Management解决方案,比如Mashery,比如Apigee等,我相信这个领域会是APM之后另外一个受到VC关注的领域。

第三个方面的内容就是做平台,以及提供PaaS解决方案和应用商店,关于这个事情,可能大家理解都比我多,可以自己看书,不多说了。Salesforce.com在这个方面做得非常成功。

第六章是讲企业慈善

如果让你的公司在盈利之余对社会有所贡献,这是一个恒久的话题。SaaS在这个方面走的很远,他们做到了1-1-1的模式,我认为在中国也会非常可行:

第一个1指的是1%的股权,Salesforce.com将1%的原始股权注入到单独成立的慈善基金会。在上市当天,Salesforce.com就为基金募集到了超过1200万美元的资金,按照现在Salesforce.com的市值,这个数字应该已经超过了一亿美元。

第二个1指的是1%的时间,Salesforce.com决定每年让员工将多余1%的时间,也就是每年6天的带薪社区服务时间,用在志愿者服务。

第三个1指的是1%的订单,Salesforce.com每年将1%的订单作为不盈利的产品捐献出去,帮助买不起的客户提高其运作的效率。这些客户主要是一些非盈利组织,包括红十字会(嗯…),斯坦福大学等

最了不起的是,Salesforce.com让他们的合伙人、供应商以及partner们都参与了自己的1-1-1计划,比如Google。今天google.org价值超过20亿美元,而且,google.org为这个世界上亟待解决的问题提供了解决方案。

即使是慈善,也要持续,很多时候,1%订单这一部分,除了捐献之外,还有更多的需求。NGO组织或者高校可以以10%的正常价格购买Salesforce.com的产品,这一部分创造了惊人的收入。

第七章是讲全球化

Salesforce.com对全球化的思考和我自己的观点很相近:必须在公司开始的时候就考虑服务的国际化潜力。

虽然,传统的说法认为,想要成功国际化,创业公司必须现在本国建立一个非常稳固的商业基础,但是马克认为,全世界都需要CRM软件,因此Salesforce.com可以在所有地方获得成功,一个值得注意的逻辑是,马克认为,跨国公司非常需要Salesforce.com提供的服务,机构分布在不同的地理位置的组织为了能够协同一致,也有同样的需求。

至于在每一个地方扩张的过程,请大家自己看书。请重点关注日本相关章节。

第八章是讲财务和融资

马克在Salesforce.com创立的时候投入了600万美元,这些钱一部分是他在Oracle工作所得,一部分是做天使投资赚的(Siebel泪奔),但是,快速成长的公司所需要的资金比他预期的要多得多。有一句著名的格言,一切事情都比你期望的时间和成本要多出两倍。这也许很夸张,但在低估创业成本方面犯错的人很多,错误判断必要的资金数码是一个致命的错误,根据一项研究,79%的小企业都把“用太少的钱起步”作为他们失败的原因之一。

在寻求融资的时候,期初马克很有信心,毕竟在Oracle的背景,以及长期做天使的经历让他和硅谷很多风投都有不错的关系。但是出人意料的是,VC一个接一个的拒绝了他们,为了寻求资金,马克开始求助于朋友和同事,也就是那些相信他和他的创意的人。

即使是在今天,通过身边小圈子融资依然不被大多数今天的创业者看重,然而,这是一个务实得多的策略。总的来说,Salesforce.com在02年之前的5轮融资中一共融到了6500万美元。

如何衡量一个快速增长的SaaS公司,马克给出了他的答案:营收。

后面的几个小节讲述了Salesforce.comIPO的故事,很有戏剧性,大家自己看,值得注意的是,IPO中涉及到了有关SaaS公司营收确认的规则,这个事情,可能大多数国内的SaaS从业者还没有概念,然而,这个在美国是有统一的标准准则,这也是我最近视图弄明白的事情之一,我会在后面的文章中分享给大家。

第九部分,管理攻略

这一章写的非常精彩,而且具备可操作性,我们自己正在实施,推荐给你们。

最后一段,马克写了自己的感触,在所有行业中,尤其是技术行业中,人们高估了你在一年中能做的事情,他们也低估了你10年内能做的事情。

与大家共勉。

时间: 2024-11-08 12:55:01

behind the cloud 读后感的相关文章

spring/spring boot/spring cloud书籍推荐

最近看了一些spring书籍,主要都是工作需要,实话说,没有必要买这么多书,每个主题一本就足够了,其他的补充可以通过项目实战和上网看官网或者博客补充. 说是推荐,其实只是一些简单读后感想而已,每本书都有它的价值,即使有些写得不好,也很难否定作者的努力叫大家不要买,不过既然花钱买书了,我个人意见就是不要省一点点钱,还是买更好的更适合自己的吧. 上个图把. Walls,非常经典的一本书,不用我多说了,如果需要购买spring的书籍,这一本应该一定是首选了.第四版比第三版厚了很多,而且并不是简单的在第

《Spring Cloud》学习(一) 服务治理!

原文:http://www.cnblogs.com/crazycheng/p/10826283.html前言:之前网上学习过Spring Cloud,对于工作上需要是足够了,总归对于一些方面一知半解,最近难得有些闲暇时间,有幸读了崔永超先生的<Spring Cloud 微服务实战>,一方面记录下自己的学习历程和读后感,一方面分享下自己对Spring Cloud微服务的一些见解,写下此文. 注意:本文着重于描述Spring Cloud运行的机制和原理部分,不会涉及到过多的代码,不会演示如何搭建注

Spring Cloud ZooKeeper集成Feign的坑2,服务调用了一次后第二次调用就变成了500,错误:Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.n

错误如下: 2017-09-19 15:05:24.659 INFO 9986 --- [ main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.spring[email protected]56528192: startup date [Tue Sep 19 15:05:24 CST 2017]; root of context hierarchy 2017-09-19 15:05:24.858 INFO 9986 --

笔记:Spring Cloud Zuul 快速入门

Spring Cloud Zuul 实现了路由规则与实例的维护问题,通过 Spring Cloud Eureka 进行整合,将自身注册为 Eureka 服务治理下的应用,同时从 Eureka 中获取了所有其他微服务的实例信息,这样的设计非常巧妙的将服务治理体系中维护的实例信息利用起来,使得维护服务实例的工作交给了服务治理框架自动完成,而对路由规则的维护,默认会将通过以服务名作为 ContextPath 的方式来创建路由映射,也可以做一些特别的配置,对于签名校验.登录校验等在微服务架构中的冗余问题

笔记:Spring Cloud Feign 其他配置

请求压缩 Spring Cloud Feign 支持对请求与响应进行GZIP压缩,以减少通信过程中的性能损耗,我们只需要通过下面二个参数设置,就能开启请求与响应的压缩功能,yml配置格式如下: feign: compression: request: enabled: true response: enabled: true 同时,我们还能对请求压缩做一些更细致的设置,比如指定压缩的请求数据类型,并设置了请求压缩的大小下限,只有超过这个大小的请求才会对其进行压缩,示例如下: feign: com

Spring Cloud官方文档中文版-服务发现:Eureka服务端

官方文档地址为:http://cloud.spring.io/spring-cloud-static/Dalston.SR3/#spring-cloud-eureka-server 文中例子我做了一些测试在:http://git.oschina.net/dreamingodd/spring-cloud-preparation Service Discovery: Eureka Server 服务发现:Eureka服务端 How to Include Eureka Server 如何创建Eurek

03-20 《构建之法》第1,2,3章读后感

第一章读后感: 看了大概了解软件从一个想法到最终成品的一个过程.软件先是由一个想法引出的,有那个想法,你需要一个工具去做什么,然后根据自己想要的功能大概做一个能实现基本功能的软件,再对客户提出的要求进行完善,实现了功能后对软件进行维护.还有做的软件要符合客户的要求,而不是只根据自己的想法去做,要满足大部分的需要,满足客户的需求,在使用过程中发现有bug对其进行修复. 软件工程在社会发展处于什么地位,发展潜力在未来究竟有多大? 第二章读后感: 看完第二章后知道软件是需要单元测试的,之前对这个没什么

《大道至简》第一,二章读后感

注:我忘记老师要求什么时间之前提交了,之所以发了这么晚是因为我觉得要写读后感的话最好还是把一本书读完了再写读后感比较好.但是直到今天晚上我发现,由于我的变成基础并不扎实,编程的造诣也并不深,所以在这短短几天之内根本不可能读完这本书.当然囫囵吞枣不求甚解倒是没问题,但是要大致读懂意思却是几乎不可能.所以只好写读后感写到第一二章. 第一章标题是编程的精义,讲的是如何用最朴素最大众最傻瓜的方法编写出一个程序.以“愚公移山”的故事贯穿全篇.愚公首先有用户需求,即被两座大山挡住了门.有具体的目标,也就是搬

Azure云平台学习之路(三)——Cloud Services

1.什么是云服务? 能够部署高度可用的且可无限缩放的应用程序和API.简而言之,就是你写的CMD程序按照一定的框架进行少量修改就能运行在Azure云平台上. 2.Azure云服务有什么特点? (1)专注应用程序而不是硬件,PaaS的一种. (2)支持多种框架和语言. (3)集成了运行状况监视和负载平衡. (4)自动缩放优化成本和性能 3.建立云服务之前,我们需要建立一个云存储,来记录我们的程序的日志信息(当然,这不是必须的) (1)选择左边导航栏的"存储".主面板上显示的是所有已有的存