打法与行动决策（译）

Mon, Apr 3, 2023
阅读时间 1 分钟

太长不读版总结：

这一章主要介绍的是战略循环中的打法。通过地图了解了环境之后，就可以选择从哪里进攻，运用特定背景下的打法了。作者结合自己的经历介绍了两种打法，并给出了一份打法的总结清单。

以下总结来自NotionAI：

这篇文章讲述了作者创立的公司Zimki的失败经历，主要原因是作者低估了母公司的影响和对核心业务的关注。文章提供了一些打法分类，包括改变用户认知、演变加速器、演变减速器、处理毒性的方法、营销战术、防守战术、进攻战术、生态模型、定位战术和毒药机制。

在前面四章中，我介绍了地图的基础知识、通用的经济规律和原则。然而，这些业务地图并没有告诉你该怎么做，军事地图也不能告诉海军上将如何赢得战斗。这些地图只是指南，采取什么行动、攻击目标、还有如何在商业竞争的惊涛骇浪中航行都得靠自己。也就是说，你必须思考、做出决策，再付诸行动。本章将介绍我在战略循环中这一段的经历（如图46）。

寻找机会

商业上有两个为什么：目标为了什么（如赢得比赛）和行动为了什么（如把棋子走到某个位置）。这里讨论的重点是为什么行动，要做到这一点，我们必须首先了解环境，把自己放到环境中，然后才能确定从哪个位置发起进攻。

2005年之前，很多会议上我都是坐在那里和高管团队面对提案，根据财务论据、直觉和核心理念来做选择。我们做决策从来没有借助对环境的理解。这是第一次，也是一次学习。这里我展示的是2005年那幅最早的地图，地图上标出了我们认为可以发起进攻的四个位置。还有很多位置没有标出来，但为了方便介绍，我只能尽量保持简单。这四个位置见图47。

第一个位置，我们现有的在线照片服务有些疲软，但我们还是可以把这里作为重点。这个领域的竞争对手很多，有的资金充足（比如 Ofoto），有的产品做得比我们好（比如Flickr）。我们还发现了没有得到满足的用户需求。作为一家公司，我们构建了很多能力，除了在线照片业务之外，团队还开发了许多不同类型的系统。母公司的在线照片服务也是由我们构建和运营，这就出现了内部冲突。我们的照片服务面向大众开放，但母公司的服务只针对他们的相机用户，于是我们不得不谨慎行事，避免左右互搏。虽然上面的地图中没有展示，但我们有两类外部用户（大众客户和母公司），他们的需求互相冲突。如果通过公开网站满足了大众消费者的需求，母公司的服务价值就不那么明显了。例如，方便大众消费者从手机上传图片这件事，不会对母公司相机的销量有任何帮助。

第二个位置，我们预测代码执行平台将成为一种公共服务（这个概念现在叫做无服务器）。注意这还是2005年，AWS Lambda等系统还要很久才会出现。这方面我们的技术储备很足，但最重要的是，我们从各种痛苦的大杂烩“死星”项目中学会了哪些事情不该做。我们可以利用产品供应商抗拒变化的惰性在这个领域攻城拔寨。但使用现有产品的客户的惰性让事情变复杂了，因此我们必须把重点放在初创公司上，尽管需要一些营销手段才能接触到他们。这背后还有一些看不到的取舍，因为任何平台最终都将建立在某种形式的基础设施服务上，而我们自己构建的Borg系统（我们运营的一个私有计算环境服务，基于Xen按需提供虚拟机）将会节省一些投资。母公司要求我们每个月都要盈利并保持团队规模，因此我们没有扩张的空间，尽管银行账户上有储备资金，但任何投资都必须来自每个月的利润。平台打法有机会降低其他系统的成本，提高其他创收项目的开发速度，从而多释放一些团队的宝贵时间，直到平台本身能够自给自足。

第三个位置，我们预测基础设施公共服务会出现。我们积累了一些这方面的经验，但我们缺少投资。我还发现母公司中的某些小圈子认为我们只是需求管道末端的开发商店，而母公司与一家外部托管公司还有大量合作。在这种情况下，母公司的需求（其中许多可以认为是政治上的需求）可能会和我们的业务需求发生冲突。可惜，我之前为了“活下来”所做的努力把自己限制在了一个角落里。如果采取这一举措，这些问题很多本质上和第二个平台举措也会遇到，但平台会带来更多灵活性。我们最大的挑战不是来自现有产品（例如服务器制造商）或租赁供应商（例如托管公司），而是来自进军这个领域的谷歌等公司。我们预计他们很快就会行动，显然我们没有足够的财力和他们竞争。等着对手采取行动然后顺势而为似乎更加保险。这种选择确实有些吸引力，值得考虑。美中不足的是，团队中好些成员都对安全问题和系统可能被滥用提出了担忧。即便有了Borg，我们过去使用产品（即服务器）获得的成功似乎也让我们产生了惰性，没有了战斗欲望。与各种惰性和母公司作斗争的同时，还要面对其它相似服务的竞争，对手还是谷歌，这似乎是下下策。

第四个位置，我们可以在环境服务（基础设施或计算平台）的基础上构建一些新颖的东西。我们知道通过服务降低投资成本是在赌博。构建新事物又何尝不是呢？我们将面对许多公司的竞争。还好，我们非常擅长敏捷开发，还有许多值得尝试的疯狂点子，这些点子都是我们在定期举行的黑客日中产生的。这可能是闭上眼睛碰运气，但我们不应该轻易放弃。“静观其变”，我们可以继续构建新事物，等待市场推出服务让我们使用。可我不想步人后尘。

地图上有四个明确的“位置”可以进攻。我们可以对着地图讨论每个举措的利弊，不只是局限于“这有投资回报率吗？它是核心吗？”这样的问题。我们利用环境来预测机会和进攻方向。我突然觉得战略不再只是靠直觉或是复制别人的“黑话”，战略变得更有意义了。我们现在思考的是位置和运动。我想起了多年前在巴塞罗那艺术酒店的电梯里遇到的那个聪明的高管，当时他正在测试新人（也就是我），我找到一点感觉了。这种感觉真不错，但我还想更进一步。我该怎么决策？

处优而怠

造成选择困难的的一大障碍往往是过去的成功，以及成功带来的舒适感。我们已有的照片服务以及其他业务线收入都很可观，赚得盆满钵满，生活也很惬意。对我来说，继续做我们一直在做的事情不是更好吗？为什么要自找麻烦呢？何况改变方向会带来风险。然而，我最近目睹了另一家公司在变革管理上的失败，敏锐地意识到保守不愿冒险的危害。这家公司就是柯达。

作为一家在线照片服务公司，我们亲眼见证了2000年到2005年之间图像市场翻天覆地的变化。人们曾经把照片看得很重，因为获得一张照片要花费很多精力和金钱，去照相馆、洗印胶卷都需要成本，还要等待照片邮寄回来。这一切的中心是胶卷，等待胶卷洗印已经够烦了，要是度假时胶卷刚好用完连照片都拍不到了。我有很多次都是因为胶卷快用完了，不得不得放弃很多美妙的瞬间。然而，实际上对于分享经历这件事来说，图像和胶卷只是完整需求的一部分。图像也正在从模拟胶片进入到全新的数字世界，我可以先拍照再删除不喜欢的照片。虽然存储卡也有容量限制，但我可以把照片传到电脑上与他人分享，不再需要洗印胶卷了。

我在图48中给出了根据不断变化的环境创建的地图，在介绍更多对柯达的感受时，我会将这幅地图作为参考。模拟图像已经是过去时（图中第一点）。我们和朋友家人坐在沙发上，大家互相传递相册来分享精彩时刻。胶卷本身需要照相馆这样的实现机制。然而，相机行业正迅速工业化，一次性相机已经够用了。图像也在从模拟世界走向更加数字化的世界（图中第二点）。从照相机发展而来数码相机（DSC，Digital Still Camera）越来越普及（图中第三点）。通过电子邮件就可以把图像方便地分享给其他人。20世纪70年代中期，柯达就率先进入了这个充满挑战的新世界，但不知怎的最后却输给了索尼和佳能等公司。

数字图像的发展和互联网的普及促成了在线照片服务的形成，而在线照片服务提供了更加简便的打印和分享图像的方法。打印到分享的转变非常明显。你可以建立社交网络或者亲密的朋友圈并通过图片来分享爱好。2001年被柯达收购的Ofoto就是最早涉足这个领域的一。柯达也在那个时候传递出了变化的信息，开始向经历和时刻分享倾斜。然而，这个领域并不是只有柯达，而且和许多竞争对手不同，胶卷洗印给柯达带来了非常可观的收入，这成了一个问题。图49展示了这个问题，还有在线照片服务的兴起（第四点）和成就造成的惰性（第五点）。

虽然柯达在数码相机和在线照片服务领域一时无两，但它似乎并没有最大限度地利用这个优势。竞争对手们正在迅速缩小差距并超车。我只能认为柯达过去在胶卷上取得的成功惰性太强了，我怀疑他们组织内部有人反对这种变化。我能想到“数字化只是小菜一碟”、“照片才是真正的生意”、“我们的业务会被蚕食”等等经典台词肯定都被搬出来了。当局者迷旁观者清，柯达确实有些自相矛盾。Advantix相机系统的发布就非常明显，这是一种奇葩的混合数码相机，居然可以生成洗印用的胶片。一只脚迈进了数字世界，还有一只脚仍留在模拟世界，这种尝试不伦不类：“这是像旧相机一样的新相机！”

尽管柯达传递出了变化的信息，但发出的声音却是矛盾的，组织一边似乎在推动数字化，而另一边似乎在抵制数字化。2003年柯达终于推出了Easyshare Printer Dock 6000，消费者在家就能把数码图像打印成柯达的照片。当我第一次听说这个消息时，以为柯达终于克服了惰性，在冲印和数字业务之间找到了折衷（图50中的第六点）。从数码相机到在线服务再到照片打印机，一套完备的柯达系统才是未来。但这里又出现了一个问题。结合手机和数码相机两条价值链的“拍照手机”出现了。我们的在线网站见证了手机拍摄图像的快速增长（第七点）。

“拍照手机”当时并不常见，但它们似乎预示着未来人们将用手机拍照并在线分享。现在我们很少听到拍照手机的叫法了，大家都是直接叫手机。似乎每部手机都是相机。

然而，当时的趋势很明显，打印照片的市场未来没有什么发展可言，和分享数字图像的巨大市场相比这只是一个小众市场。柯达似乎是向惰性妥协了，这意味着它投资的未来市场没有可能。2005年初在我们看来，从冲印（Fullfilment）到照片打印机（Photo Printers）、到相机、到胶片、到数码相机（DSC）（第八点），整个行业的未来都蒙上了阴影。

对我们来说，图52才是图片的未来，打印照片几乎没有价值，除非专注于利基市场才有利可图。

无论怎么选，我都必须注意惰性，要小心对待过去的成功。躺平不动可能很舒服，但这并不意味着美好的未来会砸到你的头上。如果我们拥抱拍照手机的未来，母公司照片服务的问题就会越来越多，而我们将和核心数码相机业务发生正面冲突。但柯达的前车之鉴又告诉我们，面向未来行动太慢是不行的，要么被惰性拖累，要么因为妥协押错宝。但也许我们可以找到另一个未来，但我们应该向前看多远呢？

近忧、远虑、狂想

上世纪90年代末，我就对3D打印产生了浓厚的兴趣。2000年初我决定加入这家快要破产的在线照片服务，主要就是因为我憧憬着物体也能通过图像分享的未来。我想了解图像分享这个领域。当世界上最大的打印机制造商之一收购我们时，我欣喜若狂。我以为他们会和我一样斗志昂扬。我多次在母公司内外分享了这个主题，但是墙里开花墙外香，这让我很沮丧。2004年我在Euro Foo上做了3D打印机未来的主题演讲。当时这个话题非常火爆，我还发现布雷·佩蒂斯（Bre Pettis）也在听众当中，他当时正在展示他的马克笔打印机DrawBot。布雷创立的MakerBot后来震撼了3D打印世界，他来听讲让我感到十分荣幸。

我不仅对3D打印充满热情，也对印刷电子兴致盎然，特别是Sirringhaus和凯特·斯通（Kate Stone）在该领域获得的成果。我开始使用这些概念来描述未来世界的制造业将如何变化。图53提供了一些基础知识，我们将深入地图上的每个步骤。我觉得读者们看到地图会越来越亲切，所以我们单刀直入。

我们先从用户对某些设备（Device）的需求出发（第一点）。这里指的是通用设备，因为我想讨论的是制造本身，并不局限于某一种设备特定用途。我们的设备有物理元素，包括电子原件以及与之交互的软件。物理和电子元件通常会用某种形式的计算机辅助设计 (CAD) 图描述，提供构建说明，这会和软件结合，软件就是代码（Code）（第二点）。

物理形式（Physical Form）的实物一般由工厂（Factory）制造，制造时会按照规范的定制化流程使用通用机器完成。然而，随着数字工厂还有3D打印机（3D Printing）等新鲜概念走下神坛（第三点），情况开始变化了。这预示着未来世界中的工厂将高度工业化，无需为每种产品的生产进行大量的调整改造。此外，自2001年Sirringhaus首次实现喷墨印刷晶体管以来，塑料和印刷电子（Printed Electronics）等新领域正在迅速发展（第四点）。电子制造（Electronics Manufacture）正在走向工业化，电子产品只需要打印出来，不再需要在电路板上焊接各种定制化或工业化的电子元件，而这些电路板也不再需要在每次生产都要调整改造的装配线上生产了。

我个人感兴趣的是物理形式和电子形式的结合。2005年，我了解到有几所大学在主导混合物件（Hybrid Object）研究，包括打印物理实物和电子元件混合的接线盒（第五点）。混合打印也将逐步工业化，未来整个设备都是打印出来的，而不是工厂组装出来的。现在新型材料和元件（Novel Materials & Components）表现出了巨大的潜力，混合物件也有机会从根本上改变设计概念。

物理实物、电子元件和设备交互软件组合起来才能完成设备提供的功能。随着混合打印机（Hybrid Printers）的工业化，设备功能将以纯数字方式来描述：可以打印的CAD（指令集）加上可以执行的代码（指令集）。要改变设备功能，只需要改变其中一套指令集并调整两者之间的交互。我们一般倾向修改软件，因为修改成本低，但硬件也会越来越容易改变，未来这种偏见也会被打破。也就是说，我们可以直接描述想要的设备功能，让编译器来决定应该如何使用指令集进行实例化。

假设我想在手机上增加一个日晷，通过软件、电子或物理方式或它们的组合就可以实现，而编译器将会为我计算出决策树。这可能会开辟出一种全新形式的编程语言，它可以编译成物理、电子和代码形式，而设计师只用专注于描述设备的功能，甚至还能做到在物理世界中继承对象。我给这种理论上的编程语言起了个名字，叫做Spime Script（第六点），这个名字来自布鲁斯·斯特林（Bruce Sterling）精彩的《Shaping Things》一书（译注：SPIME这个概念可以参考豆瓣上本书的评论）。这也是我在2006年Euro OSCON上演讲的中心主题。

然而，我也在母公司内部发起过讨论，也意识到虽然我们可以预判未来的长期变化，但想得越远就越发现这些想法的基础就越不确定，对其他人来说就越陌生，越不舒服。我们走得越远，想法就越疯狂，人们也就越害怕。这对于朝着一个目标实现的团队来说本身就是一个障碍。因此，我要选择一个既能打破障碍又不至于太过天方夜谭的行动方案。

下面这些位置让我有点不自在：

第一个位置，由于惰性和冲突，只能专注于在线照片服务。

第四个位置，基于未来的工业化服务构建一些新东西，太遥不可及。

现在问题变成了：我们的选择能否影响市场，让我们受益？这能作为我们决策这些行动的理由吗？

学习特定背景下的打法

特定背景下的打法：加速器、减速器和约束

我明白竞争是一切演变的驱动力，历史上的例子数不胜数，电力、螺栓螺母都是如此。问题在于我能影响这个过程吗？我这里碰巧有个开源的例子。2001年初开始，我们不仅使用开源技术，也开始贡献开源技术。我们参与了Perl语言等许多开源项目。

2002年到2005年，我有意将参与开源作为优势吸引并招募优秀的团队。但我同时观察到开源的开放协作产生了令人惊叹的技术，在许多领域甚至都超越了专有团队。很多领域的开源技术正在成为事实标准，甚至变成了公共服务。如果开源行为能够创造出足够强大的社区，似乎就能把不可思议的奇迹商品化。似乎开源应用到活动上，就能够加速对竞争的响应。

我还亲眼目睹了害怕、犹豫和怀疑等反作用力的冲击。供应商往往会利用这些反作用来攻击开源项目，他们放大了人在面对变化时的惰性来阻挠开源。他们总是指责开源项目不安全、会被黑（这更像一种侮辱）、来源不正、存在风险。但对我们以及使用我们服务的数百万用户来说，开源技术是整个拼图中不可或缺的一块。一次偶然的机会，围绕开源的斗争让我对知识产权有了更深刻的认识。我看透了，专利经常被当成阻止竞争对手发展的壁垒。这是竞争让人窒息的另一面。我开始形成一个观点：一些行动可以加速竞争并将组件推向商品化，另一些行动则会让组件的演变放缓。环境是可以操纵的。

我还注意到，某些活动在变得更加工业化、更加普遍的同时，具备匹配技能的人也越来越难找，其依赖的基础组件也会越来越匮乏。因此，组件所依赖的组件（例如知识）可能会约束其演变。我把这些发现总结到了第一张地图上，如图54所示。

第一点，开放的方法能够加速组件的演变，开放源代码或是开放数据都可以。

第二点，惰性带来的害怕、犹豫和怀疑，利用专利构建的技术壁垒，都会让组件的发展放缓。

第三点，组件的演变可能会受到底层组件的约束，例如计算转变为公共服务的同时，需求可能快速增长（因为在这种服务上可以构建新的未知组件或满足之前未满足的长尾业务需求），但这又需要构建数据中心。虚拟机创建是很快，但数据中心要建起来可没有那么快。

我开始进一步探索地图，寻找其它可以利用的路径。

特定背景下的打法：创新、杠杆和商品化

我经常被教育，快速跟进要比第一个吃螃蟹好。但真的是这样吗？地图告诉了我一个稍微有些复杂的故事。探索未知领域肯定存在很大的不确定性，必须投入大量的研发成本。让别人承担这些风险，再以某种方式获得这种能力，听起来当然很好。研究人员和公司创造的新事物源源不断，挑出那些能够成功的也需要不少成本。而且同样想法的公司可不止我们一家，这一点从收购的成本上就可以看出来。如果我们想这样玩，在怎样判断未来能否成功这一点上就得比其他人更有把握。

相比之下，把组件从产品变成公用服务时，组件已经有群众基础了。产品阶段的组件定义清晰，也有存量市场，但是会有惰性。我意识到两者有关联，而答案就在我们眼前。开拓者、定居者、城市规划者结构让我们能够应对演变，在两个极端之间过渡。定居者只需要找出未来的成功模式，不断打磨产品或库组件来加深理解。2005年，我们的定居者实际上叫做框架团队，他们的成功就是理解开拓者（我们的开发团队）构建的模式。开拓者是我们的赌注。

然而，如果开拓者不是我们而是其他公司呢？我们的定居者能否去伪存真，找出成功的模式？问题当然是我们要看哪里？我们可以像其它产品供应商那样发放市场调查问卷，了解组件的使用情况，但这种方法又慢又麻烦。幸运的是，在线照片服务给了我们答案。

2003到2005年间，我们通过URL请求和API向其他人公开了部分照片服务。我们很快就意识到，监控API的使用情况就可以实时地识别出哪些公司取得了成功，不用再依靠又慢又花钱的市场调查。这就是创新、杠杆、商品化 (ILC，Innovate，Leverage and Commoditise) 模型。一开始我使用的是创新、过渡、商品化三个词，这里我要感谢马克汤普森，他说服我把过渡换成了更有意义的杠杆一词。ILC模型如图55所示，我们接下来将介绍这个模型如何运作。

把一个相对明确且普遍的已有产品变成工业化的公共服务（从A1变到A2），这种服务应该暴露成便于使用的API。然后鼓励并支持其他公司再基于此服务进行创新（B1），比如通过这种服务来提高他们的灵活性，降低他们的失败成本。这些建立在服务之上的公司就是“外部”（Outside）开拓者，这就是我们通常所说的“生态”（Ecosystem）。

服务支持的公司越多（即生态越大），“外部”开拓者建立的东西就越多，创新的范围就越广。“外部”生态实际上成了感知未来方向的引擎。监控元数据（例如公共服务的消耗）就能判断哪些公司做得比较好。你不需要收集“外部”公司的业务数据，只需要收集元数据就可以了，这一点非常关键。因为这样才能在感知未来方向的同时兼顾安全性。你应该利用这些元数据识别出适合作为工业化组件（从B1变到B2）的新模式。一旦找到了未来的模式，就应该把这些模式工业化变成独立的公共组件服务(B3)，暴露成API。现在，你提供的组件更多了（A2、B3），它们变成了一个不断增长的组件服务平台，而其他公司则在这个平台上构建自己的东西（C1）。接下来要做的就是重复这种良性循环。

显然，如果所处的领域被你工业化了（B2变到B3），这些公司可能会抱怨：“他们抢了我们的饭碗”。所以你必须谨慎，在收购他们和自己实施之间做出选择。平台中提供的组件服务越多，对其他公司的吸引力就越大，这是好的一面。你需要像园丁一样维护整个生态，呵护新作物（“外部公司”）的生长，不要涸泽而渔。独立的组件服务（例如存储、计算、数据库）松散地聚集出了一个不断扩展的平台，但这种平台不是代码执行平台（比如编写代码使用的框架），请注意这一点。

ILC模型有一种微妙的美感。建立在我们提供的离散组件服务之上的这些公司如果称之为生态，那么生态越大，则：

我们的基础组件的规模经济就越大
用来识别未来模式的元数据越多
建立在服务之上的创新组件的范围就越广，可感知的未来环境就越广

换句话说，我们将组件工业化为规模经济的商品化形式的同时，这件事的效率也会越来越高，而利用元数据杠杆来寻找他人想要的未来模式也让我们更加聚焦于客户。最终，因为其他公司在平台上的创新，我们在其他人的眼中也是高度创新的。只要我们深耕元数据当个好园丁，随着生态规模的扩张，好事就会纷至沓来。

不断地第一个吃组件工业化的螃蟹会带来巨大的优势，让我们能够快速跟上未来的成功并创造财富。我们构建的生态越大，收益就越大。这里有一种网络效应，这种模式和我被教育的对比鲜明：你应当快速跟上，同时你还可以做到高度创新、高效、以客户为中心。对照地图我就明白了，只需要稍微使用一些技巧就可以给人留下这三个印象，我是工业化的先行者和未知领域的快速追随者。我一般会用同心圆来表示这种特殊形式的生态模型（还有许多形式）。我把前面的图55转换成了环形并加上了一些说明，如图56所示。在这个世界中，你可以让其他公司成为开拓者，把“开拓者”推到组织之外。

计划：特定背景下打法的运用

到了这个时候，我已经搞清楚了特定背景下的打法，于是我和詹姆斯、我的副官，还有我们的首席科学家一起坐在董事会办公室推演场景。我们开始整合计划，而公司进行的各种实验让计划更有说服力。我记得最清楚的是，框架团队的负责人走进来告诉我们，他们刚刚证明我们可以使用Javascript来开发整个应用程序（包括前端和后端）。

在不断完善打法的同时，我也在鼓励团队开发代号为LibApi的组件服务，就像它的名字Liberation API一样把我们从无休止的重复任务和现有的业务模型中解放出来。欣喜若狂都不足以表达我对这次实验的感受。这一偶然事件直接让我们总结的计划（见图57）板上钉钉。我将详细打开这份计划，一点一点地解释。

第一点，公司的重点是提供一个公共服务形式的代码执行平台，同时提供常见工作的工业化组件服务，比如计费、消息传递、对象存储（键-对象存储API）、电子邮件等等，不断地扩大这些服务覆盖的范围。所有组件都将暴露公开API，而且服务支持使用一种语言（JavaScript）开发整个应用程序。之所以选择JavaScript，是因为它应用广泛，JS引擎具备安全性，而且使用同一种语言构建的前后端代码可以消除转换错误。JavaScript操作、网络流量和存储是整个环境的收费依据。没有物理机或虚拟机的概念。

第二点，整个服务将完全开源，加速平台的发展。这样其他公司也能建立相似的服务参与竞争，但这是计划的一部分，我们是有意为之。

第三点，我们的目标是创造一个竞争激烈的提供商市场，而不是创建Zimki服务（平台的名称）。我们期望自己的公共服务能够在市场上开枝散叶，吃掉大蛋糕中有利可图的一小块，然后将我们的技术开源出去。为了防止其他公司把我们的产品改头换面，整个系统必须遵循开源许可，我们想让竞争发生在运营层面，最大限度地减少产品之间的功能差异。GPL似乎是不错的选择。

我们仍然会面临市场被服务提供商区分并破坏的问题。但我们也有对策。我们采用测试驱动开发，而且整个平台都有开放的API。这样在开发过程中，我们同时创建了一个完善的测试套件。这个测试套件将用于区分社区平台提供商（那些使用开源代码但进行了重大修改的提供商）和认证的Zimki提供商（那些符合测试套件要求的提供商）。只有Zimki提供商才能使用注册商标，这样我们就强制实施了一定级别的可移植性。

在Open Zimki基金会支持下创建的市场，让我们克服了一种惰性（对单一提供商的依赖），也让其他公司能先在内部尝试搭建自己的平台，并为我们创造出新的机会，包括应用程序商店、市场报告、交换服务、代理能力、培训支持和可以预装的独立Zimki集群。考虑到我们面临的约束，这种方法也将减少我们的资本风险。

第四点，我们需要建立生态，这样我们就能够确定未来应该创建什么样的服务，因此我们必须建立ILC模型。显然，我们能够直接观察到的只有那些使用我们服务的公司的消费数据，但其他Zimki提供商的数据要怎么观察呢？

我们提供了GUBE（Generic Utility Billing Engine，通用服务计费引擎）等通用服务，还提供了应用程序商店、组件库（相当于Perl程序库CPAN），最后还提供了代理功能，这样我们就创建了多个元数据源。我们在是否单干这个问题上反复讨论了很久，但我认为我们没有品牌知名度。我们需要的是建立市场，市场的潜力才是巨大的。我估计整个公共计算服务市场（即云计算）在十年后的2016年将达到2000亿美元的规模，而我们只能占据一小部分市场份额。

我们的长期目标是成为市场的推动者，最终建立某种形式的金融交易机制。由于我们面临的约束，我们需要外部力量的帮助才能实现这一目标，但我们决定先不声张，因为对大多数人来说这个想法“太遥远，太疯狂了”。

第五点，在平台上构建整个应用程序要做到简单、快速、低成本。我们不得不无情地砍掉开发活动中“给牦牛剃毛”（Yak Shaving）的全部工作（不舒服、不必要的重复活动）。有一个开发团队构建出了可以在客户端预览的全新形式的Wiki，而且从构思到实时发布在网络上只用了不到一小时。这证明了我们的潜力。Pre-Shaved Yaks（先给牦牛剃毛）成了描述我们服务的代名词，2005和2006这两年我们还把这句话印在了T恤上。

第六点，我们预测还会出现基础设施公共服务。我们需要利用这些服务，在这些服务之上构建自己的平台。我们多年以来在构建计费服务（根据服务创造的价值收取一定比例的费用）方面的经验让我们得心应手，我们知道如何平衡平台使用者的收费，和花在基础设施公共服务提供商上的可变运营成本，这一点我有信心。

如果我们的平台建立在基础设施公共服务之上，除了平台可以不断增长之外，我们还拥有了切断提供商与元数据的能力。如果我们做得足够好，也许能以被收购的方式退出。如果我们真的要成功，那么我需要在未来的某个时候脱离母公司的控制。

第七点，我们明白基础设施公共服务是建设数据中心的约束，而且计算的需求是弹性的。这给我们提供了反制手段，比如发动价格战迫使需求迅速超出单家提供商的供应能力。但为了让提供商们互相较量，我们要为他们提供进入市场的路径。好在我们还有Borg系统，尽管我们已经开始和一家知名的大型硬件提供商（他们一直抵制效用计算的想法）接触，但我们可以把Borg开源（第八点）来催熟市场。基础设施公共服务提供商存在细分市场，对我们必要时的反击手段有利。我们的目标应该是不让这一领域被一家公司完全控制。

考虑到我们的能力，这个选项看起来很不错，既有可行性，也考虑到了我们所面临的限制。这似乎是最佳的前进方向。这意味着公司重心的调整，逐步放弃在线照片网站之类的服务，把其它挣钱的服务收缩到最小，直到平台业务发展起来让我们可以放弃这些服务。万事俱备，只欠东风。

打法对目标的影响

行动决策会影响公司的目标，战略循环不只是一次又一次的迭代，还是首尾相连的循环。于是我们的目标从毫无意义拼凑起来的“创意解决方案公司”转变为了“服务平台提供商”。口号喊得再响也没用。如果我想赢得这场战斗，就得让每个人都参与进来，让目标变得有意义。我必须创造道德义务、行动理由，未来愿景，摇旗呐喊，来一次我们自己的十字军东征。

我们把这一切都浓缩在“Pre-shaved Yaks”这句话当中了。我们打算消除编码道路上一切无休止的烦人工作。我们将构建这样一个世界：只需要打开计算机和浏览器就可以开始编码。规划容量、配置程序、安装机器等等烦恼都烟消云散。你编写的每一个函数都可以作为Web服务开放。你可以通过共享资源轻松添加其他人编写的例程库，写出整个应用程序。这一切不用几个月、几周或几天，只用几个小时。这就是我们的目标。我们踌躇满志。

接下来的故事

说干就干。

我重新调整了公司的重心，去掉了无关紧要的业务，开始开发我们的平台。截止2006年2月18日，我们已经有了平台、核心API服务、计费系统、门户和三个基本的应用程序参考实现。我们于2006年3月正式上线了Beta版（Alpha版几个月前就上线了），这比Google的AppEngine领先了整整两年。2006年9月我们的平台在dConstruct上正式公开发布。

截止2006年4月18日，我们收获了30个客户、7个基本应用程序和每月60万次的API调用。到了2006年6月19日，我们的API调用达到了280万次。我们的增长速度惊人，2007年第一季度开发者人数已经破千，他们在我们的平台上为自己的用户构建系统。经过初期的缓慢增长之后，我们的增长远远超出了最乐观的预测（见图58），我原本以为还有非常大的教育障碍需要突破。

那段时间里还发生了一些特别的事情。2006年8月25日，亚马逊率先推出了EC2，而不是我之前预测的谷歌。我再次兴奋不已。亚马逊是一家大公司，他们能保障公共计算服务的即时可信度，我们立即着手将平台移植到EC2上。那时只要我们参加活动，展位前总是人头攒动，里三层外三层围了个水泄不通。公司已经拥抱了新的方向（虽然还有少数人掉队），越来越受关注。虽然我们的体量仍然非常小，还需要越过面前的大山，但我们已经迈出了第一步（宣布开源项目、获得2007年OSCON最高奖），准备迎接挑战。就在这时，“休斯敦，我们遇到问题了”。

问题出在哪里？

问题出在我这里，我严重低估了母公司目标的影响。我曾经花了三年时间（2002年到2005年）不断游说母公司3D打印的美好前景，最近我还在说服他们相信手机将主导相机市场，我应该吸取这些教训。母公司已经专注于SED电视并集中精力发展核心市场（相机和打印机）。尽管我看到了平台的潜力，但这对母公司的核心业务来说越来越不重要，他们已经开始抓效率并削减了一部分研发工作。他们引入了一家外部咨询公司来评估我们的平台，并得出了结论：计算服务没有未来，云计算（后来被人熟知）的潜力虚无缥缈。注意这是2006年。亚马逊才刚刚起步。即使到了2009年，一些知名的咨询公司仍然在向企业传递公共云服务没有未来或至少还有很长一段路要走的信息。

母公司打算把我们的业务线外包给系统集成商 (SI，Systems Integrator)，他们这样跟我说的：“Zimki的整体愿景远远超出了他们的业务范围”。

这里我碰到了几个问题。首先，母公司不会投资我们的服务，显然母公司内部已经做出了关于核心业务的更高决策。他们关心的是我们的业务线能否顺利移交给SI。这样才能支持他们的核心目标和诉求。当我提出引入外部投资的想法时，问题就变成了他们不会在他们认为非核心的业务上持股。

当我向管理层提出收购的想法时，他们总是强调2016年的2000亿美元市场，虽然这个数字在他们口中“虚无缥缈”。当然，我愿意相信未来的市场前景，但要是为刚起步的市场中一家初创企业支付一笔不菲的费用？没有哪一家风投会单方面如此离谱地赌博。每次总有人告诉我，这件事可以留到还在挣钱的核心服务移交给SI之后再讨论。言下之意就是“哪凉快哪呆着去”。

直到一位董事会成员告诉我，他们决定推迟开源我们的平台，并要求我立即签署合同，取消我们的盈利服务，具体日期不详，稍后再补上，我才如梦方醒。一般我才是董事会上拿主意的人，我对自己的选择和自己被打了个措手不及感到恼火。当我满怀热情地创造一个关注用户需求和有意义方向的未来时，鬼使神差地忘记了实现这一目标还需要政治资本。我找到了坚定的目标并建立了一家能够实现目标的公司，却在董事会这个重要环节上搞砸了。这不怪他们；他们应该关注母公司的核心和需求。

这些董事会成员都是母公司的高层，他们必然会坚持立场。我意识到我从来没有让他们真正地参与进来，只是全神贯注地为他人做嫁衣。我甚至没有完全向他们解释地图，只是给他们讲故事，但这是因为我还没有意识到地图的真正用处。在我看来，地图只不过是我解释战略的方式，因为我还没有学会其他高管在商学院学到的神奇魔法。董事会和母公司是一个强大的用户群体，我没有考虑他们的需求。这是新手才会犯的低级错误。我终于背上了冒牌CEO的骂名。

事情已经到了无可挽回的地步，他们坚持自己的立场并拥有强制执行的全部权力。2007年就在我要踏上OSCON（O’Reilly开源会议）的讲台时，我不得不放弃精心设计的演讲，并宣布我们的平台将放弃开源，未来也不会创建竞争性的公共服务市场。他们希望我违背对客户的承诺，但我很清楚推迟只不过是“永远不会”换了个好听的说法。我不认同意他们选择的方向，双方僵持不下。我的立场站不住脚，于是我辞职了。

公司的服务很快就外包给了SI，员工们也接受了裁员计划，这一切我走后几天就开始了。当年年底平台就关门大吉了。然而，这些概念并没有消失，其中一些想法被詹姆斯·邓肯（James Duncan）带到了ReasonablySmart（后来被Joyent收购），我的另一位好友詹姆斯·沃特斯（James Watters）则进入了Cloud Foundry。现在Pivotal及其平台业务的估值已经超过了25亿美元，而无服务器这个概念在2016年快速流行起来。至于SED电视？有人赢就会有人输。

至于咨询公司，我所有的挫败感都可能会产生误导，因为我才是失败的那个人。领导公司是我的工作，失败的并不是为我工作的人，包括董事会。

在开头这几章中，我展示了我是如何理解竞争环境、预测未来、学习如何应用原则，找到特定背景下的打法，创造未来，最终因为忽略了某类用户功败垂成的整个过程。Zimki会发现自己的潜力并大获成功吗？我们不得而知，但它曾经有过机会。这是我第一次经历战略循环，至少我对自己在做什么有了一个模糊的概念，而不是年轻时懵懂的答案“我觉得还可以”。我和电梯里那位自信的高管还差了十万八千里，但我决心下次要做得更好。幸运的是我还有下一次，但那是另一个故事了。

打法分类

打法和特定背景相关。要先了解环境才能行动。先确定可能发起进攻的“位置”（这需要理解地形并根据常见经济规律预测变化），再来选择能够创造出最大优势的行动。随着本书内容的展开，各种打法都将被覆盖，前面讨论的概念也会不断完善。我在图59中总结了一些打法的基本形式，好让读者们对我们将要覆盖的内容先有个了解。我用橙色标记出了前面提到的打法。

我把各种形式的打法按照它们的主要影响进行了分类：

改变用户认知
演变加速器
演变减速器
处理毒性的方法（比如遗留问题）
营销战术
防守战术
进攻战术
生态模型
定位战术
毒药机制（防止竞争对手钻空子）

我一定要再次强调，每走过一次战略循环，我就成长一次。我们也会沿着同样的路径前进，不断加入更多经济规律、规则和特定背景下的打法，同时深入研究之前忽略的内容或是早期总结的通用概念。但和所有的旅途一样，我们得坚持走大路，不要抄近道。我们迈出的每一步都是值得的，每一处落脚点都是学习的机会。

留给读者的练习

希望到目前为止，你已经绘制过一两幅地图。运用本章介绍的概念，审视你的地图，先试着确定你可能发起攻击的位置。现在可以运用图59中的打法，尝试一下，看看哪些位置可以用到这些打法，有没有清晰的路线浮现出来。与他人一起确实事半功倍，正好地图也为你提供了交流、协作和学习的途径。

原文作者为Simon Wardley，本译文作者为覃宇，分享需遵循CC BY-SA 4.0许可。

这个系列的帖子

Wardley Maps 战略翻译