如何走出死锁的十字路口——肖然《精益企业》分享

Posted 2021-05-01 ThoughtWorks洞见

本文转载自《肖然：精益企业》/中兴开发者社区 ，整理自ThoughtWorks

【分享讲师】

肖然，ThoughtWorks中国区咨询总监

国内最早一批精益、敏捷咨询顾问，参与了电信、金融、保险、物流、企业IT等领域多个大型组织的精益敏捷转型。肖然目前专注于将精益思想引入到企业管理及组织创新过程中，和组织一起梳理、制定目标，并规划迭代的实施方案，致力于打造适合互联网时代的精益企业，在大型组织里植入创新的基因。（扩展阅读：）

【分享大纲】

1、为什么现在提精益企业？

2、精益企业会有什么不同？

3、如何去转型？

【分享内容】

（根据语音整理成文字）

这次分享主要是通过我自己这些年的心得体会，和大家来探讨一下，精益企业到底说了些什么？以及在转型工作中（作为教练，我们最主要的工作就是带领企业去转型），它可以给我们带来些什么样的启示。

 

由于时间有限，这种分享方式缺乏肢体语言的交流，所以我想简化一下结构。那么我就从“为什么要谈精益企业”说起，与大家共同探讨“精益企业的要点是什么”，最后我们来谈一下作为教练应该注意什么样的方向，如果我们认可精益企业，我们就要向精益企业的方向去发展。

 

第一部分是讲why。我希望借助自己在过去七八年中的思想转变来帮助大家理解精益企业的由来，我也想给大家一个感受：就是精益企业理论的提出绝非是一蹴而就或者凭空而出的某种创新，它其实是很有历史渊源的。它也标志着我们这种敏捷的思想进入到了另外的一个层面，也就是说我们真正意义上开始关注整个企业的运作。

这一张照片，我故意放的很有趣哈！其实就是在我零八年刚开始做敏捷教练时最害怕的一件事情，因为在每次的转型过程中，都会有不同层级的领导过来问一件事情，就是“怎么度量？我们花了高价钱，请了这样的敏捷教练，你们要告诉我怎样才算是转型成功”其实这个问题一直非常困扰我。而这些领导都希望我能够拿出一个什么呢，比如说我们帮助企业把效率提升了百分之五十，我们的质量变好了百分之三十，这样的一些指标。

 

这几年其实已经不用回答这样的问题了，但我记得当年的情况。我现在尝试找这篇文章已经找不到了。大概在零九、一零年的时候，有一个领导把我逼得很厉害。当时没办法，我在网上四处搜索。我清楚的记得，那天晚上搜索到一篇文章是关于微软和IBM的。当时这两家企业好像都在自己的内部团队做了一系列的统计，统计说明它的需求实现快了，效率也高了。当时我就用这样的文章与证据去证明，企业走敏捷这条路就是没错。

 

但当时很有意思的一点，实际上我自己内心隐约感觉到了，做敏捷是不是真的能让原来需要一百人做的功能或产品变成五十人来做。我在我的职业生涯中从来没遇到过，但是我用这些报告去告诉外界这是正确的，敏捷就是让你做得更快。

我清楚的记得直到2010年。当时Jim Highsmith，这位老先生是敏捷宣言签署者十七人中年纪最大的。他经历了历史上各代的软件开发方法一波一波的风潮。老先生的思维非常深邃，当时他在做一个适应性领导力的白皮书。这个白皮书是英文的，下发回来的时候说让我们转译成中文的。白皮书并不厚，当时的原版书就十页左右，都是A4纸的。当时他跟我们说，“你去看一下，看这书是可不可以翻译。”看完这个白皮书之后我感觉到恍然大悟。

恍然大悟是因为两点。在这个群里面，我跟很多人都认识，大家可能听我讲过那个敏捷的新三角，这个是Jim Highsmith老先生对这个行业最了不起的贡献之一。这里我要讲另外一点他给我的最大感触。

这张照片是当时Jim Highsmith老先生在帮助管理者理解敏捷的核心思想时用的主要照片之一。当时这张照片给我很大的一个震撼。Jim Highsmith老先生指出了“敏捷”其实是在追求响应力，而且他用了“响应力 over 效率”这样一个提法。

当然，这个话题对于熟悉精益话题的人来说并不新颖。这个并非是敏捷、或者软件开发里固有的抑或是非常独特的东西。实际上，我在以后几年追求“从敏捷到精益”做一些思考的时候，我发现在精益的思想里，如果我们是在追求一种高响应力生产模式时，效率和利用率往往不应该是咱们的关注点。

这里面讲一个非常简单的例子，如我们经常在谈的交通，当路面（其实路面就相当于我们的资源）上车辆达到一定的饱和度时，如果我们以单位时间通过路面的车辆来衡量效率的话，效率是不会再增加的。

而且很有意思的一个现象就是，当到达一定饱和的程度时，对后来的车辆来讲，响应力确实是越来越慢的，这样不但效率没增加响应力还变慢了。

更有意思一点的就是，如果我们思考一下，早高峰和晚高峰时大家都会经历拥堵的十字路口，有很多的十字路口在缺乏监管的情况下就会形成一种死锁。那就锁住了，双向的车辆都不可通过。

这样死锁的十字路口其实是非常有意思的，当我看到这个时候，我在思考：它的利用率实际上是百分之百，它的路面始终是被利用的、被占用的。但很有意思的一点是，它的效率为零，那它的响应力为正无穷，除非有一个警察或者有一个热心的群众来重新疏导交通。那么非常有意思一点的就是你会理解到，在某种意义上当我们在追求效率和利用率时，我们实际上是在丧失一些响应力。

有了这样的思考，我逐渐能够正确地，至少在讲课的时候我能够正确地去引导大家理解敏捷。那么，在讲课时我经常会用上面的案例来说服大家。说“咱们这样一个行业说小一点是软件行业，说大一点是科技行业，其实至少在现在来讲，我们更多地在强调响应力。就好像一辆汽车行驶在一个地貌非常多变的情况下，我们评价这辆汽车如何，并不是看它的马达转得有多快，而是看它的马达能够在多快程度上换挡，以适应不同的地貌情况。那么这两种追求其实是不太一样的。

 

接下来还是一个很有意思的问题。我前面讲得很清楚了，在软件开发方面，我们要追求的实际上是响应力。但是在汇报过程中，或者具体到当我作为教练时，对一段时间成果进行回顾的过程中。我还是经常会遇到外界的质疑声，说：敏捷开发还是没效果，我都不知道你们敏捷开发做了些什么东西，或者说你做这种迭代，跟我们以前做的这种wbs工作分解有什么区别。

确实现实情况也是，在很多企业里，我们实际观察到的现象是，在开发团队里边做了迭代开发，大家都很努力。但是除了合作的氛围，以及大家的交流效率好像有所提升以外，在外部看来好像确实没有什么变化。 

这是我在整个教练生涯中的第二次彷徨期。我开始彷徨。向外界，第一次我们可以解释说敏捷追求的并非是效率，抑或是我们所追寻的所谓的utilization也就是利用率。我们不应该用这样的指标来度量敏捷的实施。

 

那么第二个问题是：敏捷开发，既然是追求响应力，既然是追求对市场变化的应对，那我应该怎么样让敏捷开发在落地过程中真正展现出来自己的威力呢？为什么我看到的一些团队就没有把敏捷开发的威力展现出来呢？

 

这是我第二次开始在思考。我觉得能解决这个问题，在很大程度上受益于Eric Rise的那本《精益创业》。这本书里其实没有特别多的新东西，对我来说，除了那个创新的时候做一些会计理论，没有看到特别新的东西。但是这本书使“MVP”、“最小的可推向市场的产品”等概念深入人心。

 

这一次是在跟类似于Jim Highsmith这样的一个管理顾问讨论MVP的时候，突然有了一个灵感。这个灵感就展现在下面这张照片上。

我相信大家一定看过这张照片的另外一个版本，就说做产品的时候，如果说这个产品的最上层是让用户非常满意的一些用户体验，最下层是基本的功能，我们会说MVP的意思不是让你把最下层的功能做一个最小级出来，而是让你像一个蛋糕一样纵切，做这个功能的时候同时拥有最好的用户体验。这样才叫真正意义的MVP。

 

这个概念当时给我的启发最大，就是如果把这样一个概念搬到我们转型过程中来，我们可以看到一个企业，对于我们而言，也就是我们转型的产品，我们想让这个企业、这个组织或者说小范围的这个团队变得更好。

 

在一个团队里边，我们做的事情就是需求分析、系统分析、开发、测试、最后的运维。我们认为在一个小团队里边，从我们研发体系来讲的话，我们在这个体系里边做了一件被我们称之为跨职能协作的事情。某种意义上是跟刚才我说的MVP思想一致的。

 

从团队级别来说是不难理解的，如果我仅仅是针对开发或者针对测试做一些实践，我是不可能取得敏捷所提倡的响应力的。

当时我没有想通的这一点，在现在看来却非常简单。很多道理都是这样的，当局者迷，旁观者清，当你跳出来时，你觉得豁然开朗。那当我们把这样的一个团队放大到一个组织，甚至于说一个万人企业的时候，我们发现我们讨论的不再是开发、测试、运维，我们讨论的是开发、企业运营、产品的设计、我们的市场，甚至于我们的管理决策。我们讨论的是不同的范围，我们的规模在不同的颗粒度上。

所以当年我们提倡的市场、需求分析、开发、测试的跨职能协作，放大到企业里就变成了从我们整个企业运作的各个部门之间的协作。也就意味着说，我们以前这种做敏捷的方法，仅仅是在开发团队，就变成了图左边的这种生产方式。而我们实际上需要的是图右边的这种方式。

这是我在敏捷教练生涯以及咨询顾问生涯中第二次比较深入的思考，这对于我的思想而言是一个巨大的进步。有一个非常有意思的事情，就当我意识到这个进步的时候，我发现自己好像无能为力。我好像改不动企业的其他部门。甚至于连一些企业的基本运营我们都改不动。

当《精益企业》这本书问世的时候，我是其中的reviewer之一，在没发布之前就读到了草稿，读了之后有一种豁然开朗的感觉。这张图左上角的房子其实并不在原书里边，只是ThoughtWorks中国咨询团队根据我们的体系做了提炼和总结。

原书是把各个企业，就好像我当时打了一个比方，把北京的眼睛，南京人的嘴巴，四川人的耳朵拼凑在一起的。可能把各个企业里边做得好的板块，这些板块，如果深究的话，某种意义上都是按照敏捷思想在运作的。把这些做了一个总结和打包，然后给个名字叫做“精益企业”。

看来不仅仅是我一个人的问题。其实在这个过程中，欧美的走得比较前的企业，同样有这样的问题。如果他们面临这样的挑战还没有遇到这些问题的话，就不会有《精益企业》这样一本书了，它尝试着把各个企业里边做的好的部分拿出来总结，尝试着把这些部分拼装成一个相对来说比较成功的一个体系。

真正意义上，如果要说这本书里给我和我的团队感触最大的，我们讨论完了之后，其实是这个下面这句话。我们可以看到这句话对我们所在的企业和组织做了一个定义，这个定义用上边的中文叫“复杂适应系统”，我自己更希望加一个字，叫“复杂自适应系统”。生物学里所谓的“复杂自适应系统”是，当我们给定了约束条件，我们假设这些生物都有一定的自立水平，他们会自己找到在这个约束条件下生存的最优解。

当我们都承认我们的企业、或我们生存的组织是这样一个复杂自适应系统时，我们所行使的规则以及我们和别人的协作方式就应该发生转变。

这也就过渡到了我今天想讲的第二部分。也就是说，在精益企业整个框架下面，我感触最深的四个方面，精益企业里面有很多方面，但是我自己感触最深的是四个方面。

第一个方面，我叫它做“小”产品。我认为正如这张胶片照片所展示的，我们这个行业特别是一些复杂的大型软件或者说是设备制造团队都会面临这样巨大的一个冲击。这个冲击，如果我们概括一下，其实就是工程思维和设计思维的一个碰撞。

我们来理解一下工程性的思维，永远是我希望首先把我的问题收集起来，找到类似的一个数学公式，然后呢，把我的这个公式进行验证，验证完了之后我会做一个实现。

那么在左边这个图里，我们在现实中经常遇到。可能有不同的需求单位给我们提需求，然后我们会把需求进行打包，做一个解决方案。这个时候，我们把解决方案抛给我们的需求单位或者我们一些专家做澄清。这些需求单位和我们的专家会告诉我们说，你的解决方案不完善，你需要再考虑xyz。于是我们把解决方案做得越来越大。

直到我们在有时间压力的时候，我们会把这个解决方案快速的抛给产品生产团队。那么我们这个产品生产团队拿到解决方案时，理论上讲他应该造出一个产品满足我解决方案里面说的所有内容。

当然这种工程思维的观念，其实在其他的领域里，比如说建造业，我们造桥造房子，实际上就是这样一个游戏规则。这个游戏规则当然对比我们现在造软件是很不一样的，这个我就不在叙述了，我相信我们教练很多都能够理解。

但如果我们看一下右边的这种制造方式，我们并不把每一个业务的需求。当成是我们必须要做的任务，我们把我们的业务需求当成了我们的一个个产品制造的机会点。对每一个机会点，我们又会产生各种各样的，这里用了一个词语叫hypothesis，就是假说。对，为什么是假说呢，因为我们认为我做这样的事情就能够满足我这样的机会。

那针对机会，针对我提出的假说，我会做一些小的验证。或者做一些价值的优先级排序。我会找出我认为最有可能成功的机会和假说。

当我找出了这样的机会和假说的时候，我会启动我的团队去生产这样的小产品而不是做大。

后续的时候我会通过持续的收集反馈，促使整个产品良性运转。显然如果我们对比左右两幅图，可以看到左边图中它的制造效率很可能比右边图的制造效率要高，仅从生产效率而言。但是右边这幅图的这种制造工艺，其实正体现了我们对响应力的追求。

同时，右边的这种制造工艺的方法，更能够适应市场的持续变化。那么左边的这种图，我们以前会说这种制造工艺在一些行业里面是必要的，比如我们认为说在造桥粱造房子这个阶段，我们认为它的确定性很大，所以它就是必要的，但如果我们设想一下，包括室内装修在内的这些以前传统的认为是可以适用于左边的这种制造工艺的，现在正在被所谓的互联网思维所颠覆。所以这是我们的第一点就是我们要做小产品。

第二点给我非常大的感触的是，我们要重新思考授权和约束条件的设置机制。有个案例给我感触很大，就是ARM打败英特尔的时候。当然现在ARM不是特别景气。当年他们做了一件事情，做一款微处理器的时候，他们比英特尔先做出来。说下图中这句话的是他们的一个leader，这个leader告诉我们，当时他给的团队的条件是缺钱和缺人。

当然在精益的时代，大野耐一说过同样的话。大野耐一说我并没有给你加人减人，并没有给你加时间减时间，也没有加资源减资源，我就是要求你改进。

如果我们来思考，他们到底做了一件什么事情，其实他们做对了两件事情，第一件事情就是授权。以前我们做一个管理的时候，像大野耐一这样角色的高级管理者，是制定计划的，他说了算。现在不论是在ARM这个例子里面，还是我们精益制造的例子里面，我们都可以显著地看到授权发生了变化:一线的团队拥有了更多的自主权利。

第二点，我们会发现他表面上说我缺钱、我缺人、我不给你资源不给你增加时间，实际上他是在干一件事情，就是在设置一个约束条件。

所以，如果说给我感触最大的第二点就是在精益企业的方向上，我们应该思考如何去授权、如何去设置合理的约束条件。

第三点给我感触非常深的是组织结构的松耦合。这个非常有意思，我这个截图取自Martin Fowler的《微服务定义》的这篇文章。当时总结得非常到位，两句话：组织上应该反僵化，架构上应该反垄断。这里我再学术提炼一下，在现在这个时代，我们如果用敏捷宣言里的排比句，我们实际上是思考清楚了集体智慧，英文叫Collective intelligence。实际上是胜过我们现在的执行力的，当你搞清楚，你会发现松耦合的结构是有利于我们集体智慧的。

近期，如果把这个话题再拔高一点，我们会看到在这种松耦合团队组织上的一些巨大的突破。我给出了大家四种组织结构，这个组织结构今天不多讲，但是我希望我们的教练能够去关注倒数第二个叫合弄制，这个是处于Democracy民主制和Sociocracy社会制之间的。

非常有意思的，我们可以看到人类社会的组织结构也在随之发生变化。所以我的个人结论是，无论如何在这个行业里面我们要学会去驾驭或打造这种组织结构上的松耦合和灵活性。

最后第四点，我感触比较深的是利用这个打造我们真正意义上的能够支持的“黑天鹅”，就是创新的孵化。这种事很难，刚才这幅图已经说明了很大一个问题。在这种创新的孵化过程中，很多“黑天鹅”的尝试都会失败。最后的一个，也许在一百个尝试中才会成功一个。这个概念其实也不是最新的，当时在精益制造的时代，有一种提法Set-based concurrent engineer，我在做engineer的过程中，其实我是在做一个系列，而不是只在做一种产品。

很多学者在研究的过程中认为精益的成功，其实是来源于他能够在同时做多种工艺，从最简单的，一条流水线上面能够产出不同型号的汽车，到甚至于说一条流水线上既能够产出摩托车也能够产出汽车。

所以其实就是最原始的一种心态，我可以理解说这是最原始的一种支持创新的心态。但是在我们这个行业里边，我们现在遇到的阻力是非常大的。我们在这方面，要想有固定的投入非常难，因为我们度量的方式，现在仍然是以前的那个时代的度量方式，我们依然希望说一投资就要谈投资回报率。

由于时间的原因，我就讲这四点。最后稍微总结一下what，精益企业，在这个what部分给我感触最深的四个方面：第一是做小产品，第二是我们要在“授权和合理的设置约束条件”上去思考，第三是我们的组织结构上必须松耦合，第四是我们必须要打造一种支持“黑天鹅”也就说支持创新的孵化环境。 

最后一部分我讲一下，如果我们教练认可精益企业叙述的方向，那么我们在平时指导小到一个团队大到一个企业的时候，应该注重哪些方面。这里边，我讲两个方面。

第一个方面，是我的偶像，借用我的偶像、质量大师戴明曾经说过的一句话，这句话是反话。如果我们正向解读这句话，就是告诉你说如果你觉得变化不是必须的，那实际上对一个组织来讲，存活其实也没有必要了。简言之你的企业或你的组织在这样的认知情况下，一定会死亡。这一点，我为什么用戴明的这句话，是想告诉我们所有的教练，改进是团队自己的责任，而不是我们教练手把手带着你们，你们才会改进，对于一个教练来讲，  在前期的时候，如果需要我们切身实地真实展示这种新的流程理念的运作方式，我认为是应该的。因为在前期团队需要你去展示正确的做事的方法，看到收益，在团队里边大部分的实践主义者都会看到了成果，才会跟着你一起跑。

但是如果到了中后期之后，这个团队还是依赖于我们教练继续再做改进，没有教练就不做改进。那么这个团队是不可能活下去的。也就意味着说这个团队不是我们在迈向精益企业中需要去打造的团队。我们需要打造团队是能够持续自我改进的团队。这是我认为教练必须关注的第一点。

 

我认为教练必须关注的第二点，借用了一个比较时髦的一个提法，很多人说持续交付现在取代敏捷，我觉得这个提法非常有意思，我个人并不赞同，因为敏捷并不是像持续交付这样的工程实践，敏捷不是一种工程实践，只是提了一种工作的方法和原则。

但是我希望借助持续交付这幅图，它是当时ThoughtWorks一位架构师总结的，应该有一两年时间了，所以并不是最新的。

无论如何我们必然要打造持续交付这种核心的工程能力。只有提升了工程能力之后，我们才能够保证我们的团队的持续改进是可以落地的。

当然，很多时候大家会说，肖然你说的就是前面那个是管理教练，后面这个是技术教练。我个人并非是很认同这种观念，因为我不认为我们在座的各位教练应该给自己戴个帽子叫管理教练或叫技术教练。我认为作为教练本身是赋能给团队，让团队能够主动地去学习更好的方法以及流程。

为什么会产生管理教练和技术教练呢？我觉得如果在咨询行业是说得过去的，因为客户有时候要限定一个范围，从而能够说清楚请的咨询顾问到底做什么？但是作为我们企业内部的发动机、企业内部的变革组织，我觉得大家应该按敏捷提倡的方法叫Cross-function跨职能，教练不应该分管理教练、技术教练或者以后再来一个DevOps教练。

鉴于时间关系，最后稍微总结一下，今天的分享主要是三个部分。第一大部分我希望通过Why，让大家理解精益企业这个提法的由来。当然这个过程中我给大家讲了我两次思想上我认为的进步。第一次是我理解到了敏捷所追求是响应力。第二次是我理解到了转型过程中，同样的MVP适用的原则。第二大部分我讲了给我感触最深的精益企业里边的what四个部分。这四个部分再重复一次，第一个是做小产品，那第二个是授权和设置合理的约束条件的，第三个是我们在组织结构上一定要松耦合一定要灵活，这个提的通俗一点就是我们的社区文化，第四点的是我们要支持黑天鹅的创新环境。

最后一部分我从我个人做教练的经历讲两方面。第一个方面借用了戴明老先生的观点，改进是团队自己的事情。如果我们教练不能够帮助团队意识到这一点，我觉得我们教练的工作是不成功的。第二部分是作为教练，我们必须持续地帮助团队认清楚持续提升软件制造的工艺，是他们必须做的。只有做到这样，这样的团队、这样的组织和这样的企业才能逐步迈向精益企业。

---

- 拓展阅读 -