用精益思想塑造创新型组织

发布者

Jie (Jeff) Xiong

发布于: April 18, 2014

自从彼得·德鲁克提出“创新型组织”的概念，它就成了企业管理者们口中的热词。尤其是IT企业，家家都希望打造出一支极具创新活力的团队。但一直以来，关于创新型组织的理论讨论多，关于“如何打造创新型组织”的实践讨论少。创新型组织仍然像天上的月亮：看上去很美，但是不知道该怎么抓在手里。

笔者作为一家跨国IT企业成都公司的负责人，在经营这间分公司的过程中一直把提升组织创新能力作为工作重心之一，也获得了一些成果。本文将与读者分享这些成果和我们打造创新型组织的实践经验。

一个创新型组织的案例

Thoughtworks成都公司是Thoughtworks全球28个分公司中的小字辈。从2011年底开始筹建，2012年4月正式营业，如今这家公司才刚刚度过了自己的周岁。依托成都优秀的教育资源和产业环境，这家新公司在它的第一年里茁壮成长。现在Thoughtworks成都公司有超过90名IT专业人士为来自海外及国内的客户提供服务，其中80%以上是在成都本地招聘的员工。在办公室里，除了英语和普通话以外，四川话也是随处可闻的通用语言。

就是这样一家成立时间不长、本地化程度颇高的企业，在短短的一年时间中不仅达成了生存与发展的业务目标，而且发展出了一些在IT业界、甚至更大范围内具有影响力的创新，例如：

一位员工郑晔深感于系统集成难于测试，开发了一个名为“Moco”[1]的测试工具。几个月内，该工具被全球多个商业软件开发项目所使用，一篇介绍如何使用该工具提高集成测试效率及有效性的文章在著名IT专业网站InfoQ发表[2]，旋即又翻译成英文发表在InfoQ全球站[3]，并被软件大师Martin Fowler在Twitter上推荐。
王秋、张玳、陈显军、刘旸、曾学海等员工创造性地用先进的IT技术帮助公益组织规划、设计、开发和运营IT系统。他们帮助立人公益图书馆开发了图书捐赠的iOS应用[4]，使爱心捐赠更加有组织、有目的、有效果。他们还帮助教育大发现社区开发了体验式教学在线平台“新的课堂”[5]，该项目得到公益界的一致好评，获准于今年7月1日起免费入住公益组织服务园，并可获得该园区提供的资源对接、项目扶持、资金支持和团队管理等多方面的支持。

除了这些已经小有成果的创新，成都公司还有很多创新点子正在萌芽状态，其中一些已经以文章或公开演讲的方式开始产生影响，例如姚瑶的演讲《如何规划企业在线数字渠道战略》[6]、刘冉的文章《如何选择服务器性能测试工具》[7]、陈显军的演讲《透过现象看本质：如何真正实现数据可视化？》[8]等等。还有更多创新点子尚且“养在深闺人未识”，正在跃跃欲试地等待破土而出的时机。

即使在Thoughtworks这样一家素来以技术领导力和创新思维为旗帜的跨国企业中，像这样整个分公司快速而密集地产出创新成果的先例也不多见。这使得Thoughtworks成都公司成为一个值得关注的案例：这家企业是如何成为一个具有强烈创新活力的组织的？

创新型组织的意义

在深入探讨“如何打造创新型组织”之前，有必要先回答一个问题：为什么创新对于Thoughtworks如此重要？结合这个问题的答案，读者也可以比照自己企业的情况，考虑创新能力对于自己有多重要、值得投入多少注意力和资源。

对于Thoughtworks而言，创新能力是企业自身、客户和员工三方共同的诉求，可以说是这家企业的核心竞争力之一。

从企业自身的角度，Thoughtworks是一家IT专业服务企业，主要的业务包括IT战略咨询、产品规划与设计、定制软件交付、IT组织转型和流程再造咨询等。简言之，Thoughtworks并不是一家以销售打包软件为主营业务的软件企业，它的核心竞争力正是来自于这家公司能借助IT技术与技能，用创造性的方式解决客户的问题。而这些“创造性的方式”很快就会成为行业最佳实践，被客户和竞争对手学会。例如敏捷软件开发，这种缩短交付周期、降低交付风险的软件开发方法在十年前只有以Thoughtworks为首的少数企业掌握，现在已经成为业界普遍使用的开发方法，从高端技术变成了家常便饭。因此，对于Thoughtworks而言，创新就是企业的生命线。只有不断找出更新、更好的解决方案，才能保持自身“高端IT专业服务”的地位。

对于Thoughtworks的客户而言，他们选择与这家公司合作，本身就有很高的期望：他们需要的不是若干能开发软件的人手，更重要的是具备IT专业技能与创新能力的专家；他们需要这些专家帮助他们以创造性的方式来解决问题，乃至用IT创新驱动业务创新。因此对于这些客户而言，Thoughtworks的创新力是他们选择与之合作的重要原因之一。

对于加入Thoughtworks的员工而言，在日常工作中寻找改进与创新的机会、尝试用新的方式解决问题，这不仅能帮助他们快速提升自己的能力与职业竞争力，而且使工作本身变得更加有趣。这种鼓励创新的氛围也是Thoughtworks能不断吸引优秀软件人才的原因之一。

综上所述，由于Thoughtworks自身的市场定位，创新能力对于这家企业、它的客户和它的员工都至关重要。因此，一间Thoughtworks分公司的负责人把“打造创新型组织”作为自己的重要职责也就不足为怪了。

创新的迷思与真相

提到“创新”这个词，人们脑海中往往对之又敬又畏，似乎那是一件很了不起、非常人所能及的事。在IT行业里，对于创新存在着一些常见的迷思：

“改变世界的新东西才叫创新”。很多人相信，像iPhone、Google Glass这样彻底颠覆世人生活的发明创造才叫创新，因此不敢开始创新。实际上，这种宏大的、改变世界的创新只是冰山浮于水面的一角，支撑它们的是数量庞大的微创新、微改进。这些微小的创新往往不为大众所知，但它们同样给企业和客户带来价值。
“创新靠的是灵感”。也有很多人认为，创新的点子来自于灵光一闪，而这种灵光一闪是不可言说、不可预期的，也就是说，创新活动本质上是不可管理的。实际上，创新点子最丰沛的来源恰恰是日常的工作与生活。会让一个人、一个团队感到痛苦的事，很可能正在同样困扰很多人、很多团队。用挑剔的眼光看待每件小事，善于发现日常工作中的痛点，就会有源源不断的创新点子冒出来。而“分析日常工作发现痛点”这件事，是完全可以预期、可以管理的。
“创新只能在车库里进行”。这种观点的背后，是对成熟企业环境的不信任：成熟的企业不允许犯错，不鼓励尝试新的方式，反应慢，墨守成规……总之一句话，成熟的企业不适合创新。但要看到硬币的另一面：成熟的企业能提供更多的资源来支撑有风险的创新活动，能提供更广阔的舞台（例如接触优质客户的机会、媒体的曝光）来促进创新的发展。只要转变保守、迟缓的行事方式，成熟企业同样是创新的温床。
“绝大部分创新会以失败告终”。也许是听说过太多创业公司失败的故事，很多人相信，创新是“一将功成万骨枯”的残酷战场，只有极少数胜利者能取得成就，大多数创新尝试以惨淡的失败告终。这也是很多人不愿将精力投入创新的原因之一。实际上，如果采用适当的方式来实施和管理创新，小步前进、持续交付，创新的每一个步骤都能取得实实在在的成果、并得到真实的反馈。即使在某一个步骤停下，此前的工作也能为企业、为客户、为个人带来收益，不会被白白浪费。

从事IT行业的员工通常拥有较高的教育水平，又经常接触最新的资讯，本应是最具创造力的一个群体。很多IT企业缺乏创新活力，不是因为员工没想法，而是因为固有的思维习惯和组织的工作方式束缚了他们。打造一个创新型组织，就要破除这些迷思，鼓励和帮助员工从日常工作中寻找创新点，以渐进的、可控的方式进行微创新，并将有潜力的微创新推广发展成为更具影响力的“大创新”。为此，企业需要一套支撑创新的方法学。

精益思想与创新漏斗

2012年，《精益创业》这本书突然变得很流行。建立在精益生产思想的基础上，这本书倡导用精益的方法来创业，使创业成为一件渐进的、可控的事。精益创业思想的精髓，就在于“构建=>度量=>学习”的循环，就在于小步前进、快速反馈。企业的创新，同样适用这些原则。

正如前文所说，具有广泛影响力的“大创新”是建立在大量微创新基础上的。在发展和推广的过程中，绝大部分微创新会停留在某个阶段，在较小范围内创造价值，而不会发展成为“大创新”。可以把创新的发展历程想象为一个漏斗，它由以下几个阶段组成：

“创新漏斗”这个模型有助于我们理解打造创新型企业的关键点：第一，保障源头丰沛，有大量的创新点子被发现出来；第二，保障流通顺畅，消除各个阶段之间的障碍。具体而言，创新漏斗分为五个主要的阶段：发现痛点、解决问题、分享经验、泛化、推广，各个阶段有不同的关注点。

发现痛点

每个项目都有一堆问题，每个团队都有若干抱怨，这已经是大家习以为常的事。如果从创新的角度来看，每个问题、每次抱怨都可能是一个创新的契机。换上这样一个视角，项目中存在的问题就不再令人烦恼和沮丧，反而值得兴奋了。

首先要发动项目团队自己来总结身边存在的痛点，敏捷软件开发提倡的“回顾会议”就是一个很好的时机。在一次典型的回顾会议中，团队会首先回顾前一个迭代（通常是一到两周）中做得好的方面，给团队增加信心；接着就会回顾做得不够好的事情，寻找改进的机会。在这种频繁的、对事不对人的回顾中，团队成员就会坦诚地指出项目中存在哪些问题和痛点。

有时团队成员习惯于项目的情况，感觉不到有痛点存在，这时就需要组织多个项目组互相交流。在Thoughtworks成都共有十余个各自独立的项目，各个项目的团队领导每两周有一次碰头会，交流各自项目的收获与疑问。往往从分享中，团队领导们能发现痛点的存在。例如在一次碰头会上，一个项目组分享了他们加速测试运行、缩短构建时间的经验，于是其他几个项目组突然都意识到：构建时间长是一个痛点。

即使有了团队内部的回顾和团队之间的分享，由于能力和眼界的局限，有些深层次的、大范围的痛点仍然不易被发现。举例来说，Thoughtworks成都有四个项目组在为同一个客户的同一个品牌开发不同的软件应用，由于每个项目组关注自己负责的应用，大家都没有注意到几个应用之间观感和用户体验的差异。然而从消费者的角度，这几个应用是他在整个业务流程中会先后使用到的，这种观感和体验的差异会使消费者感到不适。为了暴露这些深层次、大范围的痛点，需要有项目之外经验丰富的人来帮助项目组探索和发现问题。

Thoughtworks成都采取了一个名为“Technical Deep Dive”的实践，由Thoughtworks中国区技术委员会（China Technical Council，CTC，由中国区技术水平突出的员工组成的一个松散组织）成员到选定的项目入驻两周，其间进行访谈、探索工作坊、架构评审、代码评审、流程评审等活动，从中发现隐藏较深、不易发现的痛点。

解决问题

发现了若干痛点之后，必须要及时解决，员工才能从中获得成就感。否则，问题暴露得越来越多，员工的工作感受毫无改善，“发现痛点”这个环节就只会让员工士气低落，不会成为创新的源头活水。

然而时间受限是一个普遍存在的问题。尤其像Thoughtworks这样的专业服务公司，每天8小时要为客户提供服务，用什么时间来解决项目中存在的问题？这时企业、客户、员工三方需要彼此信任，为持续改善创造空间。

项目组采取的第一个措施是记录技术债（technical debt）[9]。针对发现出来的痛点，项目组与客户展开讨论，识别造成痛点的根因，将其作为项目的技术债记录下来，放入项目的backlog，与其他任务（例如待开发的用户故事）一起管理，这样项目组就可以在项目的正常计划里对项目进行改善。由于技术债本身会对项目的速度和质量造成损害，在短期收益（只顾交付功能）和长期收益（偿付技术债）之间取得平衡本来就是项目组与客户必须共同达成共识的一件事。

有些痛点不容易在日常工作中以小任务的方式加以改善，而是需要一段集中的时间，例如需要开发工具软件为改善提供支撑。对于这种情况，可以考虑组织周末的code jam活动，买来啤酒和披萨，针对项目面临的问题，大家开发一个开源软件来解决。同时，Thoughtworks成都的客户也会每个季度组织一次“创新日”活动，鼓励所有人用这两天时间实现自己的点子。把团队的痛点与创新日活动结合起来，经常能收到出乎意料的好效果。

分享经验

当团队的痛点得到解决，不管这个痛点多么琐细、解决方案多么粗糙，都值得向公司中的其他团队分享。这种分享有两方面意义：首先，这是对项目团队的鼓励，让员工从同事的掌声中感到发现痛点并持续改进是被赞赏的行为；其次，在分享的过程中其他团队可能会发现自己也有同样的问题，就使得解决方案有了被复用的可能性。

很多技术人员个性内向，不愿主动站在众人面前分享经验。为了鼓励大家开始分享，Thoughtworks成都组织了每周一次的“项目巡展”：每周一个项目组，轮流展示自己项目中取得的成果——不是指“按时上线”，因为按时上线只是一个项目“不失败”的最基本要求，不能算任何成果。在这个巡展上，项目团队会展示他们解决问题的新方法、开发出来的新工具、项目中使用的新技术等等。这个分公司里共有十余个项目，也就是说每个项目每过三个月都有一次机会来展示。这个固定的机制不仅鼓励了团队成员站上讲台来分享，也刺激着每个团队不断改进，才不至于在三个月一次的巡展中无话可说。

在项目巡展中，有时会听到另一个项目组说“我们有一样的问题”，现成的解决方案可以直接被复用；更多的时候你会听到“我们有相似的问题，但这个解决方案好像还不完全适合我们”。这样的反馈是一个契机，意味着这个解决方案很可能是一个萌芽状态的创新点子，只是需要更多的培养。

泛化

老话说“太阳底下没有新雪”，恐怕没有谁遇到的问题是全世界独一无二的。一个人、一个团队为之受困的痛点，很可能还有千万人、千万个团队同样为之痛苦。不过另一句老话说“没有两片完全相同的树叶”，相似的问题在不同团队那里会有不同的呈现，适用于一时一地的解决方案未必同样适用于其他团队。解决方案需要被抽象泛化才能发挥其影响力。

测试工具Moco的发展历程是一个对改进和创新不断抽象泛化的好例子。最初郑晔只是感到在项目中进行集成测试很麻烦：速度慢，测试上下文不易准备，而且测试环境不稳定。为了简化集成测试，他开发了这样一个工具，最初只提供API的使用方式。随后在与其他项目团队分享时他发现，不仅用JUnit编写的集成测试有这些痛点，用Cucumber、Concordion等工具编写的功能测试也有类似的问题存在。由此他意识到，可以将这些问题抽象为“包含集成点的测试难以开展”，并促使他开发了Moco的独立运行（standalone）模式。出乎他的意料，拥有独立运行模式之后的Moco被好几个移动应用开发者用来模拟服务器端行为，简化他们的日常开发工作。这就是对问题进行抽象之后的收益。

随后在另一个项目中使用Moco时，随着对集成测试问题的深入思考，我发现集成测试的困难主要并不在于测试工具本身，而是在于测试策略，而测试策略又受到软件设计的影响。所以要解决集成测试的难题，关键在于正确地设计集成点，从而设计一个良好的测试策略。经过项目的实际验证，我总结出了一套集成点的设计和测试策略，对项目的集成测试改进非常明显。于是我写了一篇题为《企业系统集成点测试策略》的文章发表在InfoQ。此时Moco已经由最初的一个简单的集成测试工具演变成一套完善的集成点设计与测试方法中重要的组成部分。作为一个整体，这套设计与测试方法具有更为普遍的适用性，这也正是这篇文章得到InfoQ编辑认可的原因。

必须承认，即使有这样一个成功案例，对于“如何对痛点和解决方案进行抽象”这个问题，我们仍然没有找到答案。目前在我看来，这种抽象泛化的产生仍然依赖略显神秘的“灵光一闪”。即便如此，仍然有方法可以增加“灵光一闪”出现的几率。在Thoughtworks成都，我们会鼓励每个微创新的所有者和经验丰富的同事（特别是CTC成员）频繁进行小范围的交流，这种交流不必看重演讲技巧，关键是整理思路：面临什么痛点，痛点的根因是什么，用什么方式解决，还可能适用于什么场景。脑图（mind map）和白板就是最好的承载工具。在这样的思维碰撞中，就可能产生创新的火花。

推广

当一个微创新已经得到抽象泛化，能够（潜在地）适用于很多人、很多团队，就需要及时地对其进行推广，使之发挥出最大的影响力。推广时需要考虑两个主要的问题，其一是渠道，其二是内容。

在Thoughtworks成都，推广的渠道分为三个方向：向公司内部推广、向客户推广、以及向外部推广。在Thoughtworks内部，一个创新很可能不仅对一个项目、一个分公司有用，而且对中国区的其他分公司、甚至对全球的其他分公司都有用。借助公司内部的沟通渠道，例如内部论坛、邮件列表、CTC等，可以有效地把创新点子推荐给全球的同事。向客户的推广也类似：客户企业的内部论坛和邮件列表同样向我们开放，此外还可以通过Thoughtworks的客户主管（Client Principal）向客户的高管推荐。客户选择Thoughtworks作为合作伙伴，本来就期望获得创新性的想法，因此这些高管也乐于听到这样的信息。

上面两类推广渠道还算是在“内部”，一封语言清晰的邮件就可以达到目的。而在向企业外部的行业社区进行推广时，内容的组织就显得尤为重要。常见的对外推广的渠道有微博、博客、公开演讲、文章、书籍等，这里不必赘述每种渠道的特点，反而值得指出这些渠道的相关性：实际上，有机地用好这些渠道，有助于组织作者的思路和获得反馈，从而获得更好的内容。

个人而言，当一个内容结构在我脑海中出现时，我会快速地在微博上把它写出来。140字的限制恰好有助于我厘清最核心的要素，从而形成一个可以在30秒内讲出来的电梯演说（elevator pitch），随时可以跟任何人介绍我的想法。随后我会用脑图把内容结构整理出来[10]，再用一篇不超过2000字的博客来阐述这个结构[11]，其中只有最简单的介绍，不做任何展开。这样一篇博客已经足以唤起有类似痛点的读者的共鸣，他们会给作者提供反馈。

随后，作者就可以把这篇博客交给媒体——包括在线媒体和印刷媒体——的编辑，看这个内容对他们是否有吸引力。如果某个媒体愿意发表这样一篇文章，就可以根据该媒体的特点在内容骨架的基础上增加阐述和实例，形成一篇文章并发表。与此同时，基于同样的内容骨架，作者也可以做出一份演讲稿，写文章时用到的阐述和实例即可填到PPT的“演说者备注”当中。于是当文章完成时（实际上，通常在文章完成之前），你就会得到一个结构严整内容丰富的演讲稿，到各种有影响力的行业会议（例如InfoQ举办的QCon）去提交你的演讲话题吧。

在Moco这个例子上，我们做的还不止这些。在InfoQ中文站发表了一篇文章之后，为了让客户看懂，Thoughtworks成都的两位同事银大伟和崔鹏飞把这篇文章翻译成了英文，随后我们意识到：这篇英文的文章同样可以发表。于是我们又联系了InfoQ全球主站的编辑，向他们投稿，并且再次被采用了。经过几轮反馈和修改，这篇文章在InfoQ全球主站发表了。我们还提名Moco参加Oracle主办的“Duke选择奖”（Duke’s Choice），并最终获奖。至此，Moco已经由一个籍籍无名的内部创新变成了具有较大业界影响力的开源项目。

领导者的职责

Thoughtworks成都公司的例子证明：之所以大多数组织还不能算是“创新型组织”，原因并不在于员工的能力水平，而是在于没有给这些员工一个支持创新的环境。创造支持创新的环境、消除阻碍创新的因素，是组织中所有成员的责任，首先是这个组织的领导者的责任。

首先，领导者要让员工意识到，创新是被鼓励的。有趣之处在于，所有组织都宣称自己是鼓励创新的，没有任何一个领导者会说“不要创新”。所以创新意识的建立，靠的不是空口说白话，而要靠实实在在的行动。

创新就意味着用不同于以前的方式来做事，就意味着会增加犯错误的可能性。如果一个组织不允许犯错误、犯错误会受到责罚，那么员工就不会创新。在我的日常工作里，我会不断地询问每个项目组：你们还有哪些地方可以改进？你们想尝试用什么新方式来做项目？如果某个项目组捅了篓子，我的第一个问题是：你们从这个经验中学到了什么？通过这些谈话，我希望作让员工感受到：犯错误是被允许的，而保持现状不思进取不是。

员工需要了解自己日常工作之外更多的上下文，才会有创新的想法出现，因此一个创新型的组织首先应该是一个透明的组织，各种信息都是可以获得的。在Thoughtworks成都，每个月都会有一次全办公室的信息更新（office update），把企业运营相关的所有信息向所有人公布，其中不乏传统意义上认为的“敏感信息”：销售进展、客户的反馈、人员安排、财务数据等等。日常的管理类会议，例如每周的人事例会、每月的市场与销售例会、财务与运营例会等，也开放邀请任何员工参与旁听。通过公开所有信息，我们希望让员工掌握更多日常工作之外的上下文，从而催生出新的联想。

有了信息，员工的视野也会限制创新的产生。作为通常比较资深的员工，领导者需要帮助经验较浅的员工扩展视野。帮助技术人员了解软件技术对于业务的影响，帮助基层员工了解企业运营的背景，帮助内部员工通过发表文章、公开演讲等方式走到企业之外去展现自己，这都是领导者帮助员工扩展视野的方式。

当员工有了好点子冒出来，领导者需要保障他们获得足够的资源支持去实现这些点子。在微创新还未成型之前，员工最需要的资源就是时间：发现项目中的痛点、实现解决方案、分享经验……都可能会占用工作时间。领导者需要给予员工足够的支持，让他们能把创新向前推进。

但需要注意，不要过早地提供过多的资源，这反而会扼杀创新的动力。正如每家公司都宣称鼓励创新，每个人也都宣称自己有很多创新的点子。然而很多人对于创新的“热情”只停留在口头，三分钟热度过去以后就置之不顾了。而判断一个人的热情，他本身的投入（commitment）是一个很重要的标准。所以，组织对创新点子的投入也应该遵循精益创业的原则，当创新者自己白手起家创造出一些东西、摸清了方向、只要投入资源就能快速见效时，才对其投入必要的资源。

那么，为什么创新者们会愿意白手起家、甚至用自己的业余时间来实现自己的点子？除了创造的快感之外，很重要的原因是创造的产物可以帮助别人。所以，在一个创新型组织的文化当中，“助人为乐”是一个根本的要素。乐于助人的员工，会痛苦于别人的痛苦，既包括客户、同事的痛苦，也包括更大范围的IT行业中的同行、乃至社会上的弱势群体等等，并用自己的努力去帮助别人。这样的员工，更有可能得到有意义的创新点子，并最终将其实现。这样的员工、这样的创新，是领导者最应该扶植的；这种助人为乐的氛围，也是领导者最应该鼓励和培养的。

小结

本文介绍了Thoughtworks成都公司在打造创新型组织方面取得的一些成果。尽管创新是所有企业、所有人都喜欢的一个好词，但一些流传已久的迷思使很多人对创新感到敬畏。本文打破了一些常见的迷思，基于精益创业的思想建立了一个“创新漏斗”模型，并介绍了Thoughtworks成都公司应用这个模型的一些经验。

在组织的建设中，领导者起到的作用很重要。但一个组织的文化是由其中所有成员共同决定的，领导者更多扮演“使能者”（enabler）的角色，把关注点放在排除障碍上，给员工充分的信息和自由度，鼓励和宣传他们取得的每一个创新成果，这样一个组织就更有可能具有创新的活力。

参考信息：

[1] https://github.com/dreamhead/moco

[2] http://www.infoq.com/cn/articles/enterprise-systems-integration-points

[3] http://www.infoq.com/articles/testing-enterprise-integration

[4]详见《技术创新的公益步伐》一文，发表于《社会与公益》2013年7月刊，“企业与产业”栏目。

[5] http://newclass.org/

[6] http://www.csdn.net/article/2013-04-25/2815048-CMDN-26th-Thoughtworks-yaoyao

[7] 发表于《程序员》2013年7月刊。

[8] http://www.csdn.net/article/2013-05-30/2815495-CMDN-28th-Thoughtworks-chenxianjun

[9] InfoQ有一篇题为《管理技术债》的文章值得参考：http://www.infoq.com/cn/articles/managing-technical-debt 。

[10] 在整理脑图时，我发现《麦肯锡方法》一书中提倡的“MECE”（彼此独立，完全覆盖）原则非常有用。