原则（译）

Tue, Mar 21, 2023
阅读时间 1 分钟

太长不读版总结：

本周作者继续战略循环，进入了“法”的阶段。“法”即基本原则，作者给出了一份原则清单，通过地图实例介绍了其中一部分原则的应用。重点介绍了将系统拆分成小组件和对应的小单元，分别运用不同能力和三种心态、形成演进闭环的结构。

以下总结来自NotionAI：

这篇文章介绍了Wardley地图中的文化和原则。作者提到了一种文化结构（开拓者、定居者、城市规划者）和一些基本原则，如关注用户需求和持续演变刻意设计。作者还在第一张地图上展示了如何应用这些原则。最后，作者建议读者练习将这些原则应用到他们自己的地图上。

我画好了第一张地图，按照我的理解把一些可能会造成影响的基本规律应用到了地图上。规律无法控制，但可以预测。地图上的组件都会因为市场行为而演变，不会以我的意志为转移。虽然我无法控制市场的行为，但我可以控制自己的行为。我也许能够通过行为来影响环境，我可以决定如何自组织，我可以决定公司内部强调的原则还有运营方式。

我的选择有些只和特定背景有关，只有知道对手在哪才能做出侧翼包抄的决定。这并不是说所有行动都和特定背景有关。业务上也有每个人都应该应用的有效原则。这些原则就是“法”，本章我们将重温这一段旅程（见图29）。

学习原则

“法”是适用于所有行业的通用基本原则，和环境或背景无关。这并不是说这些原则是绝对正确的，只是目前看来这些原则一直都是有效的。未来一定会出现更好的原则。和基本规律一样，我们先介绍一些原则的基本形式，后面的战略循环再来逐步深入。

原则：聚焦用户需求

只有满足他人的需求才能创造价值。即便是通过画图来理解环境，我们首先也需要定义用户需求，因为这是整张地图的参照物（见图30）。“不要像竞争对手那么烂”这样的话虽然说不出口，大家却心照不宣。这句话换个说法就是“我们必须做到最好”，我们必须了解我们需要成为什么才有可能做得到。但当我要求某家公司或某个项目解释他们的用户需求时，大家却总是面面相觑。我见过许多上亿美元的大项目，规范文档堆积如山，而这些消耗和文书只是为了掩饰他们无法解释用户真正需要什么。

显然，无法满足用户需求的创意是糟糕的，尤其是竞争对手能够做到的时候。你不会自负地假设竞争对手只是在努力尝试满足用户需求吧？如果市场中所有人都忽视用户需求，或者只是告诉用户他们想要什么（而不管用户需要的是什么），大家都别想战胜对手。

但我们如何找到这些用户需求呢？这非常棘手，因为我们总会带着自己的偏见。首先要了解我们谈论的用户是谁？——是顾客、行业监管机构、股东、员工，还是企业自己？如果是顾客，我们就需要关注他们的需求而不是自己的业务需求，例如收入和利润就不是顾客的需求。只要满足了顾客需求，我们的业务需求就能达到收入和利润目标，而不是反过来。

但我当然应该先专注于自己的业务！这是流动的话题，我们将在后面章节介绍。看一看地图，你会发现每个组件都代表一种资本储备（包括物资、财务或是其它形式）。组件之间的连线表示资本在组件之间流动。对一项业务来说，你肯定希望资金（即收入）从顾客流向自己。这样的话你就得不满足用户的需求，因为用户不太可能白白掏钱。除非你处在一个人人都忽略顾客或者告诉顾客需要什么的奇怪市场。

因为这种流动，我发现确定用户需求最好是从组织与用户之间的交易开始。你能从交易里知道应该提供什么，什么才重要。下一步就是搞清楚这些交易中顾客的旅程。不断地质疑旅程并和顾客讨论，经常能会发现毫无意义的步骤、没有得到满足的需求、本不该满足的需求。我还发现另一种方法也特别好使，那就是画出用户的地图，尤其你的用户是其他企业时。我发现这些用户大多数情况下完全不知道他们真正需要的是什么。如果你是供应商，和这些公司讨论时，往往只能聊聊他们想要的东西和他们认为必要的东西，而不是他们需要的东西。画出他们的地图就可以澄清他们真正需要的是什么，而我们可以在这个过程中寻找全新的业务机会。

讨论和数据收集是确定用户需求的关键，一定要和用户、和领域专家沟通。但这里有一个问题。他们多数时候都是错的！什么鬼？你竟然说他们都错了？是的，用户和专家在描述自己的需求时通常会犯两种错误。碰巧这两种错误对于战略打法来说是致命的。

第一个错误出现在组件正在两个阶段之间演变的时候，比如从定制变成产品或者从产品变成商品（公共服务）时，特别是后者。这里的问题是已经打好的基础会产生惰性，抵触变化。用户总是钟情于过去的遗产，他们总会有些偏见。这就好比用户对亨利·福特说：“我们不想要汽车；我们想要一匹更快的马！”这种偏见是一种叫做共同演变的规律导致的，但目前我们只要警惕这种带有偏见的老思想就好。

第二要注意未知领域的需求。这些需求既罕见又高度不确定，这意味着我们必须赌一把。用户对新鲜事物的实际需求没什么好方法来确定，因为他们也不了解自己的想法。因此，时刻准备好转向。你认为正在建造的是一台可以阻止所有战争的机器（这是莱特兄弟发明飞机的初心），但其他人却找到了另外的用途，于是有了战斗机、轰炸机。

未知领域、过渡阶段和工业化领域各有各的需求处理方法。未知领域必须赌一把。用户和专家除了含糊其辞外，实际上并不知道需要什么。过渡阶段必须倾听。跟着用户和专家的指引去满足他们的需求。工业化领域早期必须注意用户和专家会因为过去的成功养成惰性，进而产生偏见。你已经知道了用户需要什么，但必须能够大规模地运营并建立足够的基础。

原则：使用共同语言

面对公司中的不同职能背景的人，同一件事不应该使用不同的方式来解释，而是应该使用同一种方式来解释，例如地图。如果一方使用的是业务流程图，另一方使用的是IT系统图，最后一定会发生翻译错误、错位和混乱。协作很重要，但克林贡语碰上精灵语就是鸡同鸭讲，很难协作。面对现实吧，财务对IT来说就是克林贡语，IT对财务来说就是精灵语。能在多个领域之间转换的人往往更吃香，就是因为这个原因。但是陆军不会开船也可以与海军一起工作，水手不会发射迫击炮也能与陆军合作。他们通过地图协作并协调。业务的问题是缺乏通用语言，缺少一种地图（Mapping）。如果无法把正在做的事情画成地图，那么我建议你不要采取行动，先花几个小时画一下地图。

原则：透明

把地图分享出去，让更多人来挑战和质疑你的假设。这是必经之路，只有这样我们才能学习并完善我们的地图。分享地图带来的负面影响是你的假设会被其他人挑战和质疑。这会让许多人觉得很不舒服。作为公司CEO，我真的希望经验比我少的人用我画出来的地图摧毁我的战略吗？是的，让人指出来我们的战略是在趟雷，总好过自己发现这一点。但是，在组织内部建立这种透明度非常困难，不能轻视这个问题。

原则：挑战假设

聚焦用户需求，使用地图这种共同语言，并在组织中透明地分享，但如果没人愿意挑战，一切就失去意义了。公司中的每一员都有责任来挑战。我不在乎这是否是我的个人项目，我需要大家开诚布公地告诉我他们认为我错在哪里。这不仅需要透明，还需要信任。因为挑战招致报复或歧视都是伤害公司的致命罪行。作为CEO，2004年我就让我的CFO成为副官（XO）。他的职责之一就是挑战我的决定，而且还要鼓励大家提出类似的质疑。

原则：消除重复和偏见

地图不仅需要分享，还需要汇总到一起来消除重复和偏见，如重复造的轮子或自己构建已经商品化的东西。画图本就是一个迭代的过程，而且长久以来决策很可能都是在不了解环境的情况下做出的。因此，我们不需要画出完整的环境后才做决定，而是应该把地图当作指引边用边完善，用得越多，发现就越多。

画完第一张地图，你可能会质疑用户需求是否得到了充分地满足，或者质疑我们对待组件的方式。画完更多不同系统或业务线的地图后，你会发现同一个组件会出现在好多地图里。图31中我用绿色标出了一些反复出现的组件。

现在，不同的地图上可以出现同样的组件，除非它们是组件的不同实例。例如，如果十张地图都出现了数据库、呼叫中心、打印设备这些组件，那么这不一定是问题。但如果说我们有数十个不同的数据库运行在数十个不同的系统上，这可能就是问题了。重复有重复的理由，比如地点不同，但即使出现重复，你也希望看到的是数十个相当标准化的打印设备，而不是数十个高度定制的打印设备。

在石化或银行这些拥有架构师委员会的大型组织里，十倍十倍的重复并不常见。然而，根据我的经验，在通过收购或联合业务部门建立起来的全球化组织中，重复又何止百倍。（一家化学公司）有380个孤立团队定制构建380个ERP系统来满足380个不同系统同样的用户需求，还有什么比这更糟心。我遇到的最糟糕的例子是一家能源公司，系统重复了740次。现在我还知道有一家银行甚至可能打破这个记录，他们拥有1000多个风险管理系统。这些天，我得知一家大型的全球性组织已经减少了几十个重复的组件，甚至还精简了几个部门，这让人欣慰。当然，要注意的是大多数公司都会声称减少了重复，但实际上他们并不清楚自己有多少重复，并且会严重低估这个问题。

我发现了一种可以突显重复问题的技术：创建一幅剖面图。我只需要把地图汇总到一起，找到其中共同的组件放在剖面图上。这样重复和偏见我就可以一目了然。在下面图32的剖面图中，我们可以发现：

图32 剖面图

第一，我们记录了每个公共组件重复出现的次数。出现多次不一定是问题。或许重复是必要的，又或许不同的地图上出现的其实就是同一个组件。这个例子中，网站（Website）在不同的地图上一共出现了七次。

第二，记录组件的演变情况可以让你了解组织内部的偏见。上图中，用户注册（User Registration）一共在地图中出现了六次。其中一次和其余五次距离较远。这可能是因为有个团队的地图中用户注册是一项独特的活动（事实并非如此）；或者五个团队使用了公共服务，而另一个团队自己构建了服务。他们这样做也许有正当的理由，但值得再推敲一下。

第三，合并地图一般可以帮助我们建立公共词典（Lexicon）。一个组织中同一件事经常会用不同的术语来描述。

第四，电子邮件（Email）在地图中出现了七次。希望不同地方使用的是同一个电子邮件系统（尽管有时候事与愿违）。有些时候也会存在一些偏见，大多数团队认为电子邮件更像公共服务，但有一个团队认为电子邮件是还在不断发展的产品。这时应该有所警觉。

第五，数据中心（Data Centre）出现了五次。还是希望这是出于不同地理位置的需要而建造的。可叹的是建立数据中心好像成了许多大型企业的流行运动，就好像他们是史上首批建立数据中心的公司一样。我见过最糟糕的情况是，一座精心创建的数据中心，进到机房后发现空荡荡的大厅中央孤零零立着一台可怜的机架。机架上的服务器名字一点创意也没有，Seven、Janeway，Paris、Chakotay（全都是《星际旅行：重返地球》电视剧里的角色）。

地图和剖面图可以指导你消除重复和偏见。这是高效运营的必要条件。然而，重复不仅应该被当成财务成本，它还会影响我们开发出更复杂的能力。拥有1000个风险管理系统的银行一定会面临发布的问题，任何发布都会有问题。

我发现这种分散的结构的另一个作用是帮助我们确定团队所需的能力。例如，图33中的地图在显眼的位置加上了客户旅程和相关的能力。这张地图来自Methods Group公司的真实案例。这张地图中客户旅程（描述为服务模式）放在了顶部显眼的位置，我们不仅要关注满足高阶系统需求的技术，还要关注高阶系统本身，例如管理呼叫、确定赞助。出于保密原因，很多术语都被替换或删除了。

只要把这些地图汇总在一起形成能力剖面图，就可以了解公司的实际工作和现有能力（见图34）。

图34 能力剖面图

你可能已经发现，公共能力通常是定制的（需要提供一系列投资），但实际上它们的定义会更清晰。你还可能发现大量提供单项能力的定制化技术是重复的，应该简化。我总是感到惊讶，一项功能有限的简单业务背后总有一堆定制解决方案的大杂烩，把业务搞得异常复杂和缓慢。

原则：量体裁衣

（第三章）图22中有一条基本规律：不能一刀切。如果想通过直接挑战，或是通过多幅地图汇总形成的剖面来消除地图上的偏见，接下来的问题便是用什么方法合适？最常见的错误就是使用外包。问题不外包身上，问题在于我们总是喜欢把并不了解的系统整个外包出去。我们总是寄希望于他人。

我们来想象一下，一个系统有多个组件分布在各个演进阶段，但我们没有地图。现在让我们把一个高度结构化的流程应用到这个系统上，通常是通过详细的合同来说明应该交付的内容。可是，我们并不知道有些组件还在未知领域，本质上还不确定。这些组件会发生变化，这会带来某种形式的变更控制成本。对任何包含多个未知组件的复杂系统来说，这些都是巨大的开销。于是买方和供应商之间往往会发生争执。可惜，占上风的是供应商，他们可以拿出合同，表明那些没有变化的组件交付是有效的，只有变化的组件额外产生了成本。“如果一开始就讲清楚”、“你的想法一直在变”这些老掉牙的说辞总会让买家感到内疚。这是他们的错，要是他们再详细点就好了！这就是在PUA。

问题是，在工业化组件上应用包含详尽规格说明的高度结构化流程是正确的，但是这种技术如果应用于本质上还不确定还在不断变化的组件上，就不对了。这些变化的组件买方永远也无法确定。把结构化流程用在不断变化的组件上必然会产生过高的变更控制成本。错误在供应商，他们应该知道一刀切是不行的。可惜他们不会讲出来，因为这里有利可图。

更可怕的是，如果供应商的PUA成功了，特别是当供应商还愿意承担部分成本摆出“善意”的姿态时，买家下次一定会努力地把系统规格描述得更详细。他们通常会花钱请供应商或相熟的咨询公司来做这件事。可惜，这些详细的规格依然包含了未知的组件，而这些组件将发生变化，变更成本还是不可避免。解决这个问题只有一个方法，将系统分解为多个组件，每个组件量体裁衣，使用不同的方法，如图35所示。

在上面2005年的这个例子中，电力（Power）应该外包给公共服务供应商，而CRM、平台（Platform）、数据中心（Data Centre）和计算（Compute）应该使用现成的产品或租赁解决方案（例如托管），把变更降到最低。迅速变化的在线照片存储和图像处理组件理应由我们自己的工程师采用敏捷方法内部开发构建。我们可以给出数据中心等项目提供详细具体的合同（托管），但也发现目前我们还无法完全给出图像处理的规格。如果2005年我们把图中的整个系统外包，并使用单一的、需要提供详细规格的、高度结构化的方法，我可以保证图像处理和照片存储一定会产生大量的变更成本。

错误外包的问题是在是太普遍了，我们再用一个简单的例子来加深印象。图36是自动驾驶汽车的线框图（线框图常常被用来描述IT系统）。但我把组件的描述翻译成了精灵语，前面说过，大多数IT系统对业务人员来说都是精灵语的天书。我希望你看着这张图并回答图上的问题1和问题2（我们应该外包还是自建）。

图37把线框图换成了地图，但还是使用精灵语。现在看看你能回答问题1和问题2了吗？

你应该发现问题1和问题2现在可以给出一些合理的答案了。如果给不出答案，请对照（第三章）图22。

问题1的参考答案是我们自己的工程师以敏捷方式在内部构建，而问题2的参考答案是外包，采用定义明确的结构化流程或采购商品。图38是同样的地图，但没有使用精灵语，大家可以验证一下自己的答案。

让你找到精灵语语感的是代表着演变方向的横轴。可惜，我见过的派给外包的工作大都是线框图或业务流程图（如图39）。但是这些图都没有表明重要的运动特征。线框图和业务流程图实际上不是地图，你只能靠图上的文字信息理解上下文（比如理解付款流程是一种服务）。这些图本身无法提示组件该不该外包。

聘请相熟的咨询公司或供应商来绘制地图时一定要三思而后行，因为你关心的和他们关心的不一定一样。挑战公司地图上存在的偏见也很重要。负责构建给自己供电的能力的团队可能会争辩说电力不是一种商品，而要我们自己定制。常识加上（第二章）图17中的速查表，再加上地图汇总形成的剖面图（图32）足够你来挑战这些偏见了。

这时总会有人说“放心，我们不会的”，但是请先问问自己你们已经有多少个企业内容管理（ECM，Enterprise Content Management）系统了？经验表明，一家典型的有些规模的全球性公司可能有5到8个。实际上可能是40到250个定制版本，有3到5个独立团队在互不知情的情况下同时构建全局ECM。问题在于大多数人都不了解自己的重复工作或偏见。当然，人们总会找到各种各样的借口，不把整个系统分解为组件再选择合适的方法。我最喜欢的几个借口如下：

“我们需要更好的专家和规格”，这是不作为。这就好比清理失败死星项目的死星项目失败了，我们还要再造一颗新的死星！爱因斯坦的名言“每天都做这重复的事情却期待有一天出现不同的结果”说的就是这种愚蠢的行为。

“系统太复杂了，拆分后难以管理”，此地无银三百两，假装看不见系统包含了100个不同的、不断运动的组件。我们不会假装是制造汽车是一件事；实际上供应链非常复杂，不同组件的不同需求需要适合组件的尺寸和协议。是的，确实需要对正在构建的系统了解得更深入一些，如果你投入了大笔的资金，知道这一点准没错。

“组件化会造成混乱”，老掉牙的“街头骚乱”说辞。建筑、汽车还有很多行业都没有因为组件化变得混乱，我看也不会有人有这种混乱的念头。事实上这更像是希望被“卡脖子”，尽管还是有公司会使用一家供应商通过适当的方法构建所有组件。

“最后的结果是几百家实验性的创业公司”，这是超现实主义。如果把一个复杂的系统分解成组件，一些未知的组件就是实验性的。这不是问题，这是正常的。这些组件可能会使用敏捷技术在公司内部实现，或者使用更敏捷的专业公司。但是你不会把所有组件都交给这家公司，因为大多数组件一般是高度工业化的，你会使用亚马逊等成熟的服务供应商来提供计算基础设施。我不知道这些人的脑回路是怎样的，从如何从组件化一下子跳跃到全都交给“几百家实验性初创公司”。这一般都是安于现状的想法在作祟。

“接口管理起来太复杂了”，这是我最喜欢的借口，把超现实主义提升到了全新高度。一个由100个组件组成的复杂系统，组件有未知的也有工业化的，组件之间通过接口交互。假装这是一个完整的、不存在接口且可以用一套方法搞定的系统，就是在异想天开。组件和接口就在那里，复杂性不会因为“外包”就消失了。你只是假装正在构建的复杂系统很简单，因为这样你会觉得更容易管理。这就好比宝马或苹果把整个产品线外包给其他公司，当个甩手掌柜就好了，因为管理简单了。

原则: 从小处着眼

从小处着眼才能找到合适的方法。不能把整个系统当作一件事，而是要把系统分解成组件。我经常会针对特定的组件提供局部的小合同。深入细节才能做好形势管理。但还可以更进一步，使用类似细胞的单元团队。这一方面最著名的可能就是亚马逊的两张披萨团队和海尔小微团队了。

这些团队在各自的领域里被授予了自主权，团队需要提供定义明确的接口给其他团队使用，还要使用某种形式的适应度函数（Fitness Function）来定义边界，即围绕特定领域制定目标并定义出交付指标。地图不仅可以帮你识别出应该构建的团队，还可以识别出这些团队需要构建的接口（见图40）。

原则：能力和心态一样重要

假设你想从小处着眼，开始搭建一个单元组织架构。每个单元都需要不同的技能，即能力。但这里另一个因素——心态——也很重要。我们从地图上知道了活动在未知领域和工业化领域之间演变，演变的不同阶段需要的方法和技术也是不同的。活动刚兴起的时候需要实验，需要一种特定形式的工程能力，比如敏捷工程。相反，构建高度工业化的活动所需的工程能力重点在于规模化运营和消除偏差，比如六西格玛。同样是工程能力，心态却不同。对任何能力来说，心态都很重要，财务、工程、网络或营销都是如此。IT、财务或营销都不是一件事，而是好几件事。

单元需要不同类型的人（开拓者、定居者和城市规划者）来解决问题。每个人的心态不一样，有些人适应混乱、实验和失败，而有些人适合处理繁重的建模、严谨的规模化运营和度量。你需要不同能力（例如工程、金融）和不同心态（例如开拓者、定居者）的聪明人。

开拓者（Pioneer）是聪明人。他们能够探索未知的土地上以前从未发现的概念。他们能发现奇迹，但会经历很多次失败。他们的成果一半都不会正常工作，很难让人放心。他们总是产生“疯狂”的创意。这种创新就是我们所说的核心研究。有了他们的工作，未来才有可能成功。我们面对他们时大多会惊叹“什么？”、“我不懂？”、“这么神奇吗？”。第一个电源（公元400年帕提亚时代的电池）和第一台数字计算机（1943年的Z3）都是他们创造出来的。在过去，他们要么被烧死在火刑柱上，要么在新发现的沼泽中死于疟疾。

定居者（Settler）是聪明人。他们可以把不成熟的东西的受众变得更广范。他们给了我们信心，他们让我们能够理解。他们让未来变成了现实。他们把原型变成了可以制造的产品，他们倾听客户的意见，让产品盈利。他们的创新是应用研究和差异化。第一台计算机产品（例如IBM 650系列）和第一批发电机（从伊波利特·皮克西发电机到西门子发电机）都是他们制造的。他们排干沼泽，在沼泽之上建立起定居点。

城市规划者（Town Planner）是聪明人。他们利用规模经济实现产业化。这里需要的技能不胜枚举。他们建造的东西让人放心。他们想方设法让事情变得更快、更好、更小、更高效、更经济、更充分。开拓者依赖的组件由他们制造。他们的创新是产业研究。他们把已经存在的东西变成商品或公共服务（比如爱迪生、特斯拉和西屋电气对电力的发展）。他们是我们依赖的产业巨擘。是他们建造了罗马。

2005年我们就知道一种文化是行不通的，掌握三种心态中的一种似乎更让人快乐、专注。把一种心态的人放到需要另一种心态的领域一定会出问题。你可以自己试一试。在公司里找一位开拓者型的软件工程师，一个习惯于实验和敏捷开发的人，送他去参加三周的ITIL课程。看他回来时有多惨。再找一位城市规划者型的人做相反的尝试，让他花三周的时间参加黑客日课程，并在完全不确定的领域里进行实验、经历大量失败。他脸上的笑容也会逐渐消失。

不仅要根据地图分解组构建对应的单元，还要考虑心态，如图41所示。

构建（Build）和运营（Operate）新事物的开拓者非常重要。开拓者只负责开拓。他们会消费定居者（例如产品或图书馆）和城市规划师（例如工业化服务）制造的组件去完成开创性工作。相反，城市规划者构建和运营的是大规模的工业化组件。不要像开拓者那样构建出新东西交给其他人运行或运营，那一套在这里行不通。

区别三种心态也不是什么新方法。稍微做点研究，你就会发现在1993年出版的《意外的电脑王国》（Accidental Empires）中，作者罗伯特·X·克林格利（Robert X. Cringely）就描述了三种不同类型的公司，分别是步兵、突击队和警察。先驱者、定居者和城市规划者就是源于这个想法，只不过在2005年应用到了一家公司上。强烈推荐读一下这本书，里面讲到（译注，以下摘自《意外的电脑王国》中文译文）：

“不管是入侵一个国家还是市场，第一波派遣出去作战的部队是突击队员。突击队员利用晚上空降到敌后或者悄悄摸上海岸。速度是突击队员生存的要件。他们卖力工作、行动敏捷、代价便宜，但是专业水准往往较低，而这是无所谓的，因为专业能力是非常昂贵的。他们的工作是以奇袭和团队合作，尽力破坏敌阵，在敌人知道之前就建好滩头堡。他们以创意去破坏竞争对手。

[指软件业务]可是他们所做的看起来也许像是个产品，运作起来也像是个产品，通常却不是真正的产品，因为那里面还是有一些错误，还有一些突击队员看不到的大败笔。也许，这些东西运作起来很不错，可是如果不重新审计，真正生产之后，不会有利润。对于后面这些事情，突击队员无用武之地，他们很快就会觉得厌烦。

解散突击队很容易。毕竟，大部分的企业和战争都是很传统的。但是，沒有突击队，你永远无法抢上海滩。等突击队员做好份内的工作，在岸上集结，准备进行第二波攻击的是步兵。这些人大量登岸，拼命巩固初步的胜利，在突击队给他们奠下的初步基础上更上一层楼。第二波部队拿了原型、加以测试、改良、让它能夠生产、撰写手冊、上市，而且当然要赚到钱。这些兵那么多，勤务各异，所以必须半步龟腚和作业程序，才能把事情做好-—所有这些事情都是突击队员所讨厌的。就是因为这个理由，第二波的军人虽然可以跟第一波的军人合作，但是大致来说，不敢信任后者，可是突击队员根本不会注意这种事情，因为到这个时候，他们已经厌烦了，希望找个门到外面透透气。虽然突击队员奠下了成功的可能，让成功实现的却是步兵。

接下来的事情，是突击队和步兵推進到新的战场，一再执行相同的工作。后头留下的占领区，还是得派兵驻守。这就是第三波的军队，他们痛恨情况改变。我们可以说他们不是军队，而是更像警察。他们希望成长，但不是靠攻城掠地或者抢登更多的沙滩，而是在既有的土地上添增人口、建立经济和大规模的王国。”

原则：针对持续的演变设计

一切都被竞争驱动着不断地演变。从企业为了应用新的外部范式不断地调整重组就可以看出来。最新的云计算和社交媒体公司聘请的总裁和之前的电力和电话公司没什么不一样。如今又多了首席数字官。这些新东西未来会变成遗产，这就带来了一个问题。我们可能会引入单元组织架构，既考虑了能力，也考虑了心态，但地图并不是静止不动的。我们需要在公司内部以某种方式模仿公司外部不断演变的状态。解决这个问题的方法是引入一种窃取机制，新团队成立并从前面团队窃取成果。也就是说，定居者从开拓者那里窃取成果并将其产品化，倒逼开拓者继续前进。同样地，城市规划者从定居者那里窃取成果并将其产业化，倒逼定居者继续前进，但他们也在为开拓者提供组件服务。这就形成了图42中的闭环。

第一，城市规划者制造了某种形式的工业化组件，这些组件以前是产品。这个组件提供的是公共服务。

第二，开拓者现在可以使用该组件快速构建高阶系统。

第三，随着新的高阶系统的演变，定居者找出了其中的新模式，创建产品组件或可以复用的库组件。

第四，随着产品或库的发展，城市规划者创建了工业化形式的组件（第一点），完成了整个闭环。这就形成了一个由分散的工业化组件组成的、不断扩张的平台，开拓者可以在平台的基础上继续创新。

地图这一过程很好的切入点。地图还可以提供每个单元的使命（Purpose），因为他们知道了自己的工作是整体业务的一部分。单元组织架构只是这种结构的基础，单元还需要在其业务范围内拥有自主权，它们必须自治（Autonomy）。单元之间的接口被定义了适应度函数，但如果一个单元发现他们在自己的范围内有了战术优势（他们通过地图建立了整个业务的大局观），就应该发挥优势。单元不仅有正确的能力，而且有正确的心态（开拓者、定居者和城镇规划者）。这样人们能够专精（Mastery）各自的领域，专注于他们擅长的事情。你应该让他们自己选择并调整心态，直到他们找到真正满意的状态。真正做得好的就要奖励。使命、专精和自主是丹尼尔·H·平克（Daniel H.Pink）的《驱动力》（Drive）一书的主题。

系统外部出现的新事物会流经这个系统。这种结构不需要不断更新的附属品。首席数字官、首席电话官、首席电力官、首席云官统统不需要。单元的规模可以扩大，但最终还是要拆分成较小的单元，而地图可以帮你拆分。要注意哈克曼（译注，Richard Hackman，著有《Leading Teams》）问题，团队数量增加会造成沟通渠道呈指数级增长。美国海豹突击队很早就发现“最优的作战团队规模”是4。

然而，你会感觉要把单元间的通信和监察组织起来十分需要层级结构，是的，这说明单元结构之上确实需要构建层级结构。我发现可以模仿组织结构来设置管理层结构，如首席执行官、首席开拓官、首席定居官和首席城市规划官。但是，你也可以会使用听上去更传统的职务，例如首席运营官、首席科学家等等。我们这样做了。我不知道为什么，现在我也不在意这些；我只是让结构更清楚了。他们各自还需要支持结构来强化文化并为资源池（会形成新单元）提供培训。

与主流的文化理念相反，这种结构导致三种文化各自蓬勃发展。这有点违反常理，文化源于结构，而不是反过来。这也意味着公司维护的并不是一种文化，而是多种。我在图43中给出了这种文化理念的基本元素。

最后，我只是在少数情况下使用这种结构（开拓者、定居者、城市规划者）取得了显著的效果。这可能是“瞎猫碰上死耗子”。但过去十年里，我没有看到任何结构有相近的效果，我看到的只是无穷无尽的矩阵结构或双重架构的系统，它们总有些问题。当然还会有更好的结构出现。然而，援引康威定律，如果你不在沟通机制中模仿演变（例如通过窃取机制），那么你将永远无法应对组织外部的演变。

这种结构常见吗？特定圈子之外这种情况极为罕见。我最多也就看到有些公司在试水，老实说这种结构非常不错，也许你应该采用。如果管理者听到他们的公司需要三种文化、三种心态、窃取系统、环境地图和高水平的态势感知，一般就开始打退堂鼓了。这种结构不适合四象限就可以搞定的简单场景。许多组织来也不需要，如果竞争对手的态势感知和自适应结构水平旗鼓相当，或者处于激烈竞争的风口浪尖，高水平的态势感知和自适应结构就够了。对于大多数公司来说，我的个人建议是使用单元结构，读一下GCHQ（英国政府通讯总部）的论文“Boiling frogs?”。这篇文章干货不少，提供了很多思路，其中也介绍了类似的结构。

我注意到近年来很多人都在谈论双重结构。从我的角度和经验，不得不说双重结构有根本缺陷，你会被带偏。只管理两个极端情况是不够的，两者之间的过渡阶段也必须管理起来。否则，你创建的组织就无法应对演变。如果只关注两个极端，那么最重要的中间阶段就会被削弱，这会导致派系斗争，因为开拓者的组件永远无法演变（城市规划者会说这些系统“一碰就散”），你创造的只是一个永远不会增长的平台，而在此之上构建的一个又一个新系统堆成了意大利面。2003年我就亲身经历过这种情况，开发缓慢停滞的情况无法挽回，有人呼吁建立一个超大规模的死星项目来打造“未来的新平台”。我从来没有见过这种项目能成功。

原则分类

原则（“法”）是普遍的，适用于所有环境（“地”），尽管许多原则要结合地图才能充分发挥作用。这里值得区分（来自Trent Hone）。虽然“法”是基本原则，但情况不同，这些原则的应用方法也不同。比如，“关注用户需求”并不意味着我们都关注同样的用户需求，而是会随环境和目标变化的确切的用户需求。汽车公司的用户需求就和茶馆不同。同样，“肯特最好的茶馆”的用户需求与“肯特最方便的茶馆”的用户需求也不相同。因此，“法”可以细分为原则（Principle）本身（如“关注用户需求”）和实现（Implementation）（即“肯特最方便的茶馆的用户需求”）。

还有，原则是你所选择的方向上的一套信念。原则不是规律，无论你怎么选规律都会起作用，而原则会应用于你的组织。我们对任何地方都有效的信念也会用原则来表达。我在图44中列出了本书介绍的“法”的基本形态（原则），我们刚刚读过的那些原则标成了橙色。这份清单并不完整，但目前够用了。后面的章节我们将回顾这一部分，随着内容展开我们将不断完善这些概念和原则的要素。我按照原则的主要影响进行了分类，供参考：

沟通方式
开发或构建事物的机制
组织运营
我们如何组织自己的架构
我们学习的方式
我们如何领导

在第一幅地图上运用原则

这份清单中的原则听起来就像常识。大多数原则确实都是常识，但话说回来，这些常识落地很难。必须付出很多才能落到实处。例如“消除重复和偏见”这条原则就没法应用到第一幅地图上，只有一幅地图是不够的。但再简单的地图也可以应用一部分原则。我在（第三章）图28中已经应用了常见经济规律的地图上展示了相关的原则，如图45所示。

第一，聚焦用户需求。地图的参照物是用户，这个例子中就是顾客。

第二，地图提供了共同语言。地图提供了一种挑战假设的可视化方法。

第三，量体裁衣（敏捷、精益还是六西格玛，内部开发还是外包），不要尝试在整个环境中采用一套方法

第四，把地图上的元素当成小组件，对应成小团队（例如Team 4）

第五，不仅要考虑能力，还要考虑心态（开拓者、定居者和城市规划者）

第六，为持续演变刻意设计。组件将不断演变，可能需要组建拥有新的心态的新团队（如Team 8）。

图45值得多花些时间观察。我们有用户需求、满足这些需求的组件、影响它们的常见经济规律，还有对变化的预期、我们需要的组织结构，甚至还有合适的方法和文化。一张图就包含了所有结构。实践中，我们通常只在地图上展示和手头任务有关的结构，比如我们在预测变化的时候就不会展示单元、心态和文化等结构。但要知道这些结构都是可以展示的，勤加练习，你就会掌握分寸，什么时候该展示什么结构。几年之后所有结构你都将了然于心，这时的挑战就是要记住把对应的结构展示出来，方便给那些还没有习惯这种思维方式的人理解。

截止到现在，我们已经可以了解环境，可以预测基本规律导致的某种变化，还了解了能够帮我们自组织的基本原则。我们终于可以开始学习特定背景下的打法了，而这才是战略核心。学完打法的基本课程后，我们就做好了行动的准备。

留给读者的练习

第三章我曾要求你将一些基本经济规律应用到第二章的作业上。如果这些练习你都跳过了，现在是时候补交作业了。只靠阅读是成不了地图专家的，必须动手运用才能学会。

现在对着画好的地图，看着图44中的标成橙色的原则，试着和其他人一起把这些原则应用在地图上。你考虑了用户需求吗？你挑战了假设吗？你会如何自组织？你知道细节吗？

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

这个系列的帖子

Wardley Maps 战略翻译