热门资讯> 平台转移背景下,微软 Office 做出的生死抉择 >

平台转移背景下,微软 Office 做出的生死抉择

转载时间:2021.10.02(原文发布时间:2018.05.04)
353
转载作者:36氪企服点评小编
阅读次数:353次

平台转移背景下,微软 Office 做出的生死抉择

编者按:这个世界上唯一不变的东西只有变化本身。无论是既有者还是颠覆者对变化都很重视。从既有者的角度来说,弄清楚某件事情究竟是平台转移还是系统噪声非常关键。因为如果是平台转移的话,自己就需要未雨绸缪;如果是系统噪声,那就不需要浪费太多的资源去应对。从颠覆者的角度来说,除了弄清楚变化的本质以外,知道颠覆会采取什么样的路径至关重要。因为很多创意的前景总是非常美好的,但道路却是非常曲折的。当我们对AI、区块链之类的新兴技术做出判断时,最好是从过去技术发展史汲取经验。曾领导开发了Office 95、97并担任过微软Windows事业部总裁的Steven Sinofsky回顾了Office一路上曾经遭遇的各种挑战以及生死抉择,是一个很好的案例参考。

平台转移背景下,微软 Office 做出的生死抉择

《星际迷航:可汗怒吼》中小林丸的屏幕上详细列出了Savik面临的一种“无法取胜”的竞争局面。

这是个玩具。它是下一个大事物。技术很神奇。但技术也是很琐细的。在讨论“区块链”时争论很容易陷入到抽象之中。

可是如果你正处在一场技术转变/颠覆之中呢?

这是一个有关微软Office的故事。

似乎每个人对区块链都有自己鲜明的观点,基于跟过去的任何形式的类比。如果有人提出区块链是跟互联网本身一样大的东西的话,按照很多人的说法,这个人既不懂区块链,也不懂互联网。

在这里我想分享一个已经持续进行了25年的故事,一场有可能对微软Office造成“威胁”的平台转移,我的目的是希望你从中可以为像区块链这样的技术在平台转移中如何发展,以及实际的颠覆会呈现出一种非常不同的“形态”提出充分的理由。

这是因为在既有市场里,尤其是大型的既有市场里,“下一个大事物”从来都不是用新技术建造的旧事物的新版本。你必须考虑所有的碟子在空中是怎么旋转的,必须假定一切都有可能发生改变。

到2000年时Office已经连续经历了长达8年的爆发式增长,那年的收入已经达到了100亿美元。产品从个人购买“转型”到企业购买和IT部署。看起来它的情况安全极了。

现在可能很多人都不记得了但微软Office其实是一款消费者产品。整个GTM都是跟零售、大规模市场和个人有关,软件市场就是这样的。在1990年代中后期,Office(以及Windows NT和Exchange)进行了一次所谓的大规模转型,朝着企业端发展,并且建立了一个可管理的账户销售模型。

平台转移背景下,微软 Office 做出的生死抉择

上一代的竞争(Lotus/IBM、Borland、WordPerfect)依然“存在”。新的竞争也来了,也就是开源版的所谓的“开放”Office。我们对自己的执行能力有信心,认为次要/免费产品并不会对我明构成实质威胁。

Office作为个人应用已经发展成羽翼丰满,每一个都承担了某一类别的细分功能或者“直面”了不同的竞争对手。在套件的战争中,没有一个主要竞争对手具备完全的有竞争力的套件(文字处理器、电子表格、图形、数据库,然后是电子邮件)。鉴于这一历史,团队普遍的看法是,直接跟我们冲突的竞争对手或者甚至开源项目对我们构成的竞争威胁都很小。尽管如此,我们还是非常注意OpenOffice,因为他们总是抄我们。我记得有一次在贸易展上我在一个摊位看到了一个演示,我注意到他们的“PowerPoint”菜单跟Office不一样(还有他们的Excel和Word也是)。当我向他们指出这一点时他们感到很震惊,承诺当天下午会“修复”这个问题。我因此反而没那么担忧了,因为他们的想法是克隆Office。

不过它们仍然留住市场上。这里面真正有新意的是这是两种不同的技术路线的首次竞争。

(1)用Java编写的Office(同时也是可能的开源,以及WORE——一次编写随处运行的首次亮相)

(2)给浏览器使用的Office

试着不要用事后诸葛亮的角度去思考该怎么做。

当你已经知道了结果之后是很难从过去的角度去吸取这些经验教训的。这对于商学院的学员组队想从案例研究中学到东西来说是个挑战。但这个案例方法不是跟特定技术的事实有关,重点是要知道经理和领导如何去决定该怎么办。所以我们这里讨论的焦点也会放在这上面。

说到商学院,当时我正在休假去哈佛商学院教书。学生的直接反映差不多是“Office已死”。这令人震惊。我不断地问为什么我还在微软工作。

此外谈到商学院那段时间,1998年我正在休假时正值“创新者的窘境”刚刚冒出来,GBS的走廊里个个都在讨论颠覆。这就是为什么学生和所有的老师都非常确信Office有可能成为第一个也是最大一个颠覆的牺牲品。因为跟Clay(Clay Christensen,创新者的窘境的提出者)只有几门之隔,所以那是个非常令人兴奋的学期,虽然经常要为微软辩护。

Java Office与其说是一个产品不如说是一场运动。很多“applet”(Office是应用,applet是按需的精益的小应用)都要“取代”Office。组件化已经成为运动。微软内部很多人都认为组件架构是未来,尤其对于企业应用来说。

平台转移背景下,微软 Office 做出的生死抉择

复合工作流与应用,以及用小规模的代码(跨任何OS)提供的技术吸引力/狂热非常之高,因为Office是一个庞大的单一程序,是“膨胀软件”。光是运行SETUP就已经够痛苦的了。

但是我们曾经试过用“OLE”开发组件,也试过“编辑由不同部分组成的文档”的办法,结果完全是个失败。神奇的弹出菜单,在小矩形框内编辑……

这整个“组件”运动基本上是技术优先的思路。它几乎是“面向对象”的产物,我在职业生涯的前5年基本上都在“处理”C++(当时对世界来说是个新东西)。认为Office的膨胀和管理困难可以用组件“治愈”的IT专业人士太多了……因为从定义来看组件就应该是更容易或者类似的。

重要的是要认识到IT世界对微软还不习惯,而当时发生的大事是要“减少总拥有成本”——这个基本上由于Windows+Office导致的,当时IT界的观念是应该制订解决方案。认为基于可重用组件开发的解决方案可以促进更快速更灵活的应用。

于是组件双管齐下对现状形成了冲击。同时Java正好又是很新很酷的面向对象编程语言。尽管很多人已经意识到面向对象除了反而拖累了速度并且引入了编程复杂性以外其实对现状并没有什么改变,但这一点也无关紧要。

平台转移背景下,微软 Office 做出的生死抉择

这是Word文档内部一个Excel组件的截屏。其基本想法是这样你就不需要在应用/窗口之间来回切换了因此你的目标就是一份很好的打印文档。只需要点击菜单和工具栏就会切换到“Excel”然后你就可以编辑电子表格之类的东西了。

那如果下次别人也发现了这种做法之后我们是不是应该对他们有可能摧毁我们感到害怕呢?或者这是不是一切的未来的又一个失败的信号呢?

这里面的风险相当高!

像上面例子中的组件完全就是个失败。他们强调PC非常脆弱,而且对于最终用户来说一般非常笨重。他们给一个“套件”做了一个非常棒的演示,但就仅此而已了。此外它们开发和测试也非常复杂,这令仍然专注于遗留竞争对手的团队感到极其沮丧。

顺便说一句,这些Java Applet对资源的占用通常是Office的10倍,但是能力却不及后者的1/100。这样的东西是很难行得通的。这些东西想要成为可靠的替代品或者威胁是非常困难的。

我的天呐这些Java小应用太可怕了。Java很慢,占内存又非常多,而且根本就是很诡异。Office就有很丰富的历史,尤其是第一个Windows应用使用解释型语言(类似C)编写的,团队后来花了好几个产品周期才把解释型语言干掉了。现在Java又跳出来告诉全世界“不,这才是正道。”在我们看来这就是胡扯。@jondevaan的态度尤其鲜明,因为他在解析器上面花费的时间实在是太多了,他一直都想让Excel跑快一点。对我个人来说,Hava也是垃圾回收这一事实也提供了这是胡扯的充分证据,因为它花了很多年时间攻击说C++并没有真正的垃圾回收机制,而真正的面向对象程序员时使用垃圾回收的。

因此你可以看到跟当时WWW和现在的区块链的一些类比,这些新的解决方案在执行那些你知道如何做快的事情上往往执行得非常糟糕。WWW渲染文档格式很慢,这也难怪,因为这种使用ASCII码的协议跟文档格式并没有太大关系。

但这却几乎不能阻止IT、开发者、内部阵营(.net!)的人不断地主张组件以及用这种新方式重写Office才是未来。跟这种声音做斗争的压力很大。

记住,这个我们之前已经试过了,所以显然我们必须早点行动!

极力鼓吹Office应该重写的战略思想家和业界权威的数量之多再怎么夸张都不为过。显然Office已经完蛋了,而他们已经看到了未来。

但是组件、解释器以及垃圾收集就像是三重彩投注一样,从这么一个地方开始作为起点简直是疯了。

与此同时,Exchange邮件团队引领了DHTML/AJAX/XMLHttpRequest的潮流,并且将基于浏览器的电子邮件带上了一个新的台阶(用来用于gmail、google map上),这开辟了重塑Office的又一个前沿,针对的主要是Outlook。(注意基本/高级模式——这在DTTML中是可选的)

平台转移背景下,微软 Office 做出的生死抉择

然后就冒出了Internet Explorer、Dynamic HTML (DHTML)再加上XMLHttpRequest。这似乎就像魔法一样。它还有一个额外好处就是当时它只有在IE浏览器上才能行,IE团队自然喜欢这一点。

这完全是另一种竞争性挑战,也是针对Office的一种架构方案。

所以可以想象这又要连续开很多会来进行讨论。对于微软的观察者来说,.net的人焦点都放在Java而IE的人则关注HTML,两方都希望Office在这些新平台上重写。你可以想象我要出席所有那些会议。

在互联网时代,Outlook是Office新的靠山,所以这里面的风险很大。

但再次地这要面对距离它很遥远的功能子集问题,而Outlook的历史才有3年时间!

尽管这次是一支团队与另一支团队之争。不是组织之间,而是技术策略/架构之争。

Outlook是全新产品。这东西还几乎用不了。97年时对它的评测顶多算是不愠不火(请不要让我Google Walt Mossberg的评测!)。Outlook 98迅速增加了互联网协议,因此引入了困扰微软客户端长达10年的双产品分裂。然后Outlook 2000又带来了2种“模式”等等。换句话说,为了让*Windows*电子邮件能用就够我们忙的了。

但然后引领/发明了AJAX的Exchange团队开发出了完美的API来解决Outlook在Windows上面遇到的问题,做法就是向Exchange服务器发送请求并且显示很多行的电子邮件。这让Outlook看起来很慢!与此同时Outlook已经在客户端实现了一堆的功能,所以客户端/web就很不对称,这正是客户所不想看到的。可以证明为什么开发电子邮件的架构是错误的材料还有很多。

在外部有很多人都在用Ajax开发基于浏览器的创作工具。

这很令IE团队感到沮丧,因为Office团队不做AJAX Office应用。所以自然地IE团队总是非常踊跃地宣传我们的各种“竞争对手”。平台就是这样的!

OWA(outlook web access,无需客户端直接通过互联网读取发送邮件)对于轻量电子邮件很好但不适合支持主流的电子邮件和日历功能。这也是一个很好的IE展示。于是Yahoo、Hotmail、AOL等开始大力宣传使用DHTML,很多很酷的演示开始出现,其中就包括开发类似Office之类的东西。PowerPoint(或者画图)尤其是个目标。

Office支持作为文件格式的HTML,但不支持作为编辑运行时。协作服务器跟Office配合有大量的工作要做。比方说参见edition.cnn.com/TECH/computing……

Office正面临3种竞争性颠覆:

免费版

客户端Java版

浏览器/HTML版

每一种的实质是:

a)下一场重大平台转移

b)完全是个错误的想法

c)可能是正确的想法,但是当时实现还为时尚早

与此同时我们是个体量达100亿美元的业务。

围绕着Java和AJAX的初创企业开始像雨后春笋一样冒出来。大多数都是采取直接山寨Office的方式。当然,这是我们的看法(偏见)所以风险不大。

整个公司对Office业务都感到非常担心。提供了很多“帮助”。大公司就是这么运作的。

想象一下,你正在致力于一项10年间从10亿美元做到了100亿美元并且在每一个细分领域把10多个竞争对手都痛煸了一顿还赢下了Mac和Windows(以及OS/2)两个市场的业务。现在互联网似乎突然之间就冒了出来同时你还面临着Java的架构性竞争以及开源的结构性竞争。而且它们全都直接瞄准了你的薄弱点,拥有成本、复杂性以及膨胀。压力可想而知。

我不断地列举用那些技术做“Office”的所有新产品。任何时候我们的规划文档里面都会有各种大表,我们的产品规划总是在同时研究着十多种竞品。似乎每一次贸易展(我们当时还是通过这种渠道去了解)都报道又有新的基于浏览器或者Java的Office出来了。

与此同时,内部来自技术专家要求作出回应的呼声非常高。销售人员一个都不想要除非时他们正在销售但去掉了他们反对的(膨胀、TCO)东西。

绝对是Office最困难的时候:我们已经成为守江山的人了,现在要面对无数新的/潜在的风险了。

但是所有这些都没有用在任何“真正”的东西上,除了Outlook。Google Maps/Gmail还要几年后才出来呢。

Oracle还折腾“网络计算机”的概念。Office病毒/恶意软件破坏了品质。膨胀软件。WWW机会巨大。

到处都是下一个基本架构。

你能想象Office看起来有多脆弱呢?

机构对今天的区块链又会怎么看呢?

与此同时,那些新东西没有一个能行的。我的意思是说它们真的都不能工作。且不说OpenOffice抱怨的那些大问题(文件格式兼容性),就连基本的编辑功能都是超级笨重。性能很糟糕。此外大多数人的连接都不好,而每一个以浏览器为中心的在线工具都要解决离线使用的问题。这些所谓的颠覆根本颠覆不了。

只是每一位权威和客户都关注未来,要求给出答案。

赌注:我们已经在服务器端协作投入很大的赌注(SharePoint)。

需要对Office的核心价值赌一把。悄然开始我们自己的HTML客户端——Office“伴侣”。

想法很简单:如果有东西正在替代Office的话我们就自己做。

我们的答案是聚焦于我们相信自己能做成的东西。

我们已经开始在HTML身上下注了,那就是很早就在Word和PowerPoint支持它作为一种渲染格式(编辑是后面的事)。冷知识:Word的Internet Assistant for HTML比Netscape 1.0的出来的时间还早。将幻灯片保存为带有导航按钮的一系列的JPEG是早期DIY和企业网站的标志。PowerPoint很早就开发了这一插件而且特别流行。

1998年我们已经收购了Vermeer FrontPage,并且非常努力想要把Office文档的“live web”概念推广到工作场所。这个的第一次迭代是所谓的“Office Web Server(OWS)”后来演变成为了泛化的FrontPage。OWS属于Sharepoint的“团队网站部分”或者我喜欢把它叫做“放文件的地方”。

但新的大赌是开发web版的Word、Excel和PowerPoint——运行在浏览器上面并且使能在OWS/SharePoint内编辑真正Office文档的原生HTML应用。我们知道我们不可能把所有的Office功能都做出来,因为我们已经看到每个人都失败了而且我们还得兼顾现有的业务。

平台转移背景下,微软 Office 做出的生死抉择

这是超级困难的,因为大多数HTML应用都是“免费”的,所以甚至做这些都被认为是有风险的。这个是“免费版的Office”吗?销售根本就不想要这样的东西!

但从产品的角度来说,这是值得投资的而且时机合适。但这还不够。

营销和销售队伍可以说非常害怕“web版的Office”。他们好不容易才在跟这些新流行的竞争对手的战争中“赢下”了客户,所以这帮人最不愿意做的一件事就是回过头来调整原先签订的交易(这些交易是持续多年企业协议的开始,今天我们称之为SaaS,但当时的说法叫“维保”)。他们的假设是如果微软做web版Office的话那应该是免费的。其价格应该要比“完全”版的桌面Ofice低,原因是它能做的事情变少了(你懂的,因为价格是按照代码行数计算的)。

Gmail出来了。Google收购了Writely,2web。并把这些工具植入到gmail1里面。基本上把Office文档从Google webmail流里面挤掉了。花了6年多的时间才看到这一场景实现。

Office的销售仍然不受此任何影响。

然后gmail出来了,后续又集成了后来成为Google App的应用服务的早期版本。当时已经进入到2006年了。

记住,Google Appl还处在beta阶段,直到2009年末才正式推出,直接产生收入更是八字没一撇,直到现在针对企业进行大力营销之后才成为现实。

有人可能在猜那段时间我们有没有进行过任何自己做还是收购别人的决策……当然我们在不断提出这些想法。但从收购的角度来说这些这些潜在收购对象没有一个能行的,而且说实话技术圆锯也排除了这一点可能性。当Google收购web工具时我们的态度是困惑多过担心,但我们也知道他们的CEO长期以来的商业策略就是做点事情(Open Offuce!)来干扰并且/或者阻止微软。所以我们很警觉。而且事实上市面上可以集成进Office Web Sever的Java版或者web版工具都已经被收购完了。所以对既有者来说这是典型的集成挑战。

下一步是把Office Web App的流程植入到基于浏览器的邮件里面。

但是客户那边仍然非常关心在功能上能跟原有Office“平起平坐”,此外他们也很在意经济性(定价)。

在平台转移的时候,产品需要发展哪怕企业不能发展/或者不想发展。

我们很多人已经从类似IE和Office这样的地方转移出去并且现在占据了Windows(以及“Windows Live”)领地工作的地方。所以自然地我们早期做的一件事情是将Office Web App连接上Hotmail和OneDrive(Skydrive),以此来与gmail竞争(当时Hotmail正在与庞大/免费的邮箱做斗争)。

对免费Office的恐惧很强烈。即便web app的存在也被视为有可能对Office的定价形成不好的压力。显然产品团队没有经过销售与营销挑战是普遍认识。

今天的Office大概是350亿美元的业务。Google Docs很大但是甚至连它的10%都不到。Office Web App很棒但绝大部分人的生产力工具仍然以桌面Office为主。

从中可以得到哪些经验教训呢?相当微妙。很容易可以看出这是双向的。

这段时间我们还对Office下了另一个赌注,“托管Exchange”。这是完全是故事的另外一支了,但是故事的脉络跟这个十分类似,也是“必须要”与“不能要”以及“没法用”之间的决策。

不管是有意为之还是出于竞争的必要性因为直接对抗是没有用的,Google Docs(现在的G-Suite)已经走上了一条不同的发展方向。专注于实时协作,淡化跟Office的直接竞争,并且开发不同的功能加上大规模的免费“分发”,这吸引了大量的受众。不过赚的钱就不是很多了。Google并没有报告G-Suite的收入情况但这是Google 40亿美元左右其他业务板块的一部分,里面也许包含了Cloud、硬件等。我这里是猜的。

平台转移已经发生。这不是Office克隆、基于Java的克隆或者基于浏览器的克隆。

它的发展轨迹跟朝着移动、app、聊天应用以及实时协作转移的走势不一样。

工作的本质正在改变,工具也在引领和跟随。

最终平台转移并没有来自Java或者甚至基于浏览器的编辑/创作工具(也不来自DHTML/Ajax)。颠覆之所以发生是因为很多活动件。

尤其是移动形态因子以及聊天app的崛起改变了生产力实质的版图。现在正在发生但一直都在持续进行中。

这里有一篇文章是我写的,里面谈到了工作本质的变化——持续生产力:在新时代工作的新工具和新手段。

关键跟这个话题的始作俑者有关,区块链,这种颠覆发生在另外一个跟传统智慧描述不同的抽象层面。它发生在更高的“app”层面而不是纯粹的技术层面。这是因为新一代的工具制造者的出现以及技术栈和基于此的应用的出现,但是并没有把技术栈视为差异化的因素。关键在于技术栈能做什么。

当重大转变发生时,一切都会变化,不仅仅只是技术。

WWW并不仅仅只是改变了客户端/服务器使用的协议,或者文档的格式。“一切”都变了,只是不是一下子发生的。

未来已来,只是不是均匀分布。

— Gibson//结束

原文链接:https://medium.learningbyshipping.com/microsoft-office-existential-choices-in-the-face-of-platform-shifts-9ed5847593a4

编译组出品。编辑:郝鹏程。


[免责声明]

资讯标题: 平台转移背景下,微软 Office 做出的生死抉择

资讯来源: 36氪官网

36氪企服点评

新锐产品推荐

消息通知
咨询入驻
商务合作