谢谢程冲。首先呢，我觉得我先在开始之前表达一下我激动的心情！其实我跟这个群非常有渊源。因为2014年的时候，当时是喜鸿和我，我们作为顾问的评委，实际上是启动了当时中兴企业级敏捷教练的认证。那么，两年后的今天，就在春生跟我提起咱们这个群体的时候。我根本没有意识到我们这个群体已经有近两百位教练。这可以说是我在职业的咨询生涯里面第一次，真正的确实看到了一支能够改变一个万人企业的改进队伍。所以在开始分享之前确实我想说一下我非常激动。
这次分享我想主要还是因为有很多其他群都在围观，但是我们针对的主要群体还是咱们教练，我希望除了标题党以外，我也写了一篇应该说软文性质的吧，有公司的成分在里面。但是我希望这次分享的主要是通过我自己这些年的心得体会，和大家来探讨一下，精益企业到底说了些什么？以及在转型工作中，因为作为教练来讲，我们的最主要的一份工作就是带领着这个企业去转型，那么他可以给我们带来些什么样的启示。
因为时间有限，这种分享的方式的缺乏了肢体语言的交流，所以我想简化一下结构。那么我就从为什么我们在这儿谈精益企业？以及精益企业的一些要点是什么？最后呢我们来谈一下作为教练，我个人的观点是应该注意什么样的方向，如果我们认可精益企业，我们要向精益企业的方向去发展。
在第一部分也就是why。我接下来希望通过我自己在过去的七八年时间里面思想认知的一些变迁，来帮助大家理解一下精益企业是怎么来的，我也想给大家一个感受就是这个精益企业本身理论的提出绝非是一蹴而就或者凭空的某种创新，他其实是很有历史渊源的。那么他其实也标志着我们这种敏捷的思想进入到了另外的一个层面，也就是说我们真正意义上开始关注整个企业的运作。
这一张照片，我故意放的很有趣哈！其实就是在我刚开始做敏捷教练零八年左右的时候。最害怕的一件事情，因为当时所有的转型过程中，都会有不同层级的领导过来问一件事情，就是怎么度量?我们花了高价钱，请了这样的敏捷教练，到底你们要告诉我怎么才算是转型成功了？这个问题一直是非常困扰我的。而这些领导都希望我能够拿出一个什么呢，比如说我们实现效率提升了百分之五十，我们的质量变好了百分之三十，这样的一个指标。
这几年其实已经不用这样回答了，但我记得当年的时候隐隐约约，我尝试找这篇文章已经找不到了。大概在零九年一零年的时候，有一个领导把我逼得很厉害。当时没办法，我在网上四处搜索。很高兴那天晚上我记得很清楚搜索到一篇文章是微软和IBM。当时这两家企业好像都在自己的内部团队做了一系列的统计。统计说明他的需求实现快了，效率也高了。由此我就用这样的文章，当年是用这样一系列的证据去证明你们走敏捷这条路就是没错。
但当时很有意思的一点，实际上我自己内心隐约感觉到了，做敏捷是不是就真的让原来需要一百人做的一些功能或产品现在变成五十人。我在我的职业生涯中从来没遇到过，但是我用这些报告去告诉外界这是正确的，敏捷就是让你做得更快。
这个时候直到2010年我记得很清楚。当时的时候Jim High smith老先生，这个老先生是敏捷宣言签署者十七人中年纪最大的。他也经历了从历史上各代的我们软件开发方法这一波一波的风潮。那么老先生的思维是非常深邃的，当时他在做一个适应性领导力的白皮书。这个白皮书是英文的，下发回来的时候说让我们转译成中文的。白皮书并不厚，原版书当时就十页左右，都是A4纸的。然而当时就告诉我们说，你去看一下，肖然就说你看这个书是不是可以翻译。当时看完这个白皮书之后我顿时感觉到恍然大悟。
这里有两点，其实当时恍然大悟说，很多人就是在这个群里面我跟很多人都认识，大家可能听我讲的时候都讲过那个敏捷的新三角。这个是Jim High smith老先生给这个行业最了不起的贡献之一。那么，这里我其实要讲另外一点，他给我的最大的一点感触。
这张照片是当时Jim High smith老先生在帮助管理者理解敏捷的核心思想，其中的主要照片之一。当时这张照片的其实给我很大的一个震撼。Jim High smith老先生指出了其实敏捷是在追求响应力，而且他用了一个响应力、over、效率，这样一个提法。
当然这个话题其实如果我们熟悉精益的话会发现其实这个是一个老话题了。那这个其实并非是敏捷，或者软件开发里固有的一些或者说非常独特的东西。实际上，我在后几年追求从敏捷到精益做一些精益的思考的时候，我会发现精益的思想里边，告诉大家，如果我们是在追求一种高响应力的生产模式的时候，效率和利用率往往不应该是咱们的关注点。
这里面讲一个非常简单的例子，就假设我们的交通，经常我们在谈这个交通，当路面，其实路面就相当于我们的这个资源。当路面车辆达到一定的饱和度的时候，其实这个效率如果我们以单位时间通过路面的车辆来衡量效率的话，是不会再增加的。
而且很有意思的一个现象就是。如果当到达一定饱和的程度的时候对后来的车辆来讲，他的响应力确实是越来越慢的。不但效率没增加响应力还变慢了。
那么，更有意思一点的就是如果我们思考一下这个早高峰和晚高峰大家都会经历这种拥堵的十字路口。有很多的十字路口在缺乏监管的情况下就会形成一种死锁。那就锁住了，双向的车辆都不可通过。
那么在这样的死锁的十字路口其实是非常有意思，当我看到这个时候我在思考。他的利用率实际上是百分百，他的路面始终是被利用的是被占用的。但是很有意思的一点是他的效率为零，那他的响应力为正无穷。除非有一个警察或者有一个热心的群众来重新疏导交通。那么非常有意思一点的就是你会理解到说某种意义上当我们在追求效率和利用率的时候。我们实际上是在丧失一些响应力的。
有了这样的思考的时候我逐渐开始能够正确，至少在讲课的时候我能够正确的去引导大家理解敏捷。那么，每次在讲课的时候，其实我都很容易用上面的案例来说服大家。说在咱们这样一个行业里边，说小一点是软件行业，说大一点是科技行业，其实至少在现在来讲我们更多地强调的是响应力。因为就好像是我们这辆汽车行驶在一个地貌非常多变的情况下，我们要求的这辆汽车并不是看他的马达转的有多快，而是看他的马达能够在多快程度上换挡，以适应不同的地貌情况。那么这两个追求其实是不太一样的。
那接下来还是有一个很有意思的问题，我讲清楚了。我讲得很清楚说软件开发我们要追求的实际上是响应力。但是在这个汇报过程中，或者在具体的当我作为教练一段时间的成果回顾的过程中的时候。我还是经常会遇到外界的质疑声音，说敏捷开发还没效果。我都不知道你们敏捷开发做了些什么东西。或者说你做这种迭代，跟我们以前做的这种wbs工作的分解有什么区别。
那么确实现实情况也是在很多的企业里边，我们实际观察到的现象就是在开发团队里边坐了迭代开发大家都很努力。除了我们发现说合作的氛围，以及大家好像交流沟通的效率提升了以外。在外部看来好像确实没有什么变化。
于是这是我在整个教练生涯中的第二次彷徨期。我开始彷徨说，向外界的时候第一次我们可以解释说敏捷并非是追寻的是效率。或者追寻的是所谓的utilization也就是利用率。我们不应该用这样的指标来度量敏捷的实施。
那么这个第二个问题敏捷开发，既然是追求响应力。既然是追求对市场变化的应对。那我应该怎么样让敏捷开发的落地过程中真正展现出来自己的威力呢。为什么我看到的一些团队就没有把敏捷开发的威力展现出来呢？
这是我第二次开始在思考。那么，这个思考其实是我觉得很大程度上解决这个问题是拜Eric Rise那本精益创业所受的启发。Eric Rise在她的精益创业里边呢其实没有特别多的新东西，对我来说除了那个创新的时候做一些会计理论来讲的话没有看到特别新东西。但是由于他这本书把MVP，最小的可推向市场的产品这个概念深入人心。
其实这一次时候是在跟也是类似于Jim High smith这样的一个管理顾问讨论MVP的时候。当时突然有了一个灵感，那么这个灵感就展现在下面这张照片上。
我相信大家一定看过这张照片的另外一个版本。就说做产品的时候。如果说这个产品的最上层是让用户非常满意的一些用户体验。最下层是基本的功能。我们会说MVP的意思不是让你把最下层的功能做一个最小级出来。而是让你像一个蛋糕一样重切，你在做的这个功能的时候同时拥有最好的用户体验。这样才叫真正意义的MVP。
那当然这个概念当时给我启发最大的时候就是如果把这样一个概念搬到我们转型过程中来。我们可以看到一个企业，我们转型的产品，就是这个企业。在线的各位我们这个群体里面都是教练。那对我们来说对我们的教练工作来说，我们的产品就是这个企业。我们想让这个企业，这个组织或者说小范围的这个团队变得更好。
在一个团队里边的时候可能这个团队里面当年我们做的事情就是需求分析、系统分析、开发、测试、最后的运维。我们认为在一个小团队里边就从我们研发体系来讲的话，我们在这个体系里边把他们做了一个我们叫跨职能协作，这是我们做的一件事情。某种意义上是跟刚才我说的MVP这种思想是一致的。
我们在团队级别的时候我们是理解了如果我仅仅是针对开发或者针对测试做一些实践，我是不可能取得敏捷所提倡的响应力的。
那么当时其实我没有想通的一点呢，但现在看来，觉得这个很简单很多道理都是这个当局者迷，旁观者清，当你跳出来说你觉得这个豁然开朗。那当我们把这样的一个团队放大到一个组织，甚至于说一个类似中心这样一个万人企业的时候。
我们发现我们讨论的不在是开发、测试、运维。我们讨论的是开发、企业运营、产品的设计，我们的市场，甚至于我们的管理决策。我们讨论的是不同的范围，我们的规模在不同的颗粒度上。
所以当年我们提倡的市场、需求分析、开发、测试的跨职能协作。放大到我们的企业里就变成了从我们整个企业运作的各个部门之间的协作。也就意味着说我们的以前这种做敏捷的方法，仅仅是在开发团队。就变成了图左边的这种生产方式。而我们实际上需要的是我们图右边的这种感情方式。
这是我在整个做教练做敏捷这个教练和做咨询顾问生涯中的第二次。我第二次去感受到了说在遇到这个问题的时候第二次比较深入的思考，这是我觉得第二次在我思想上一个巨大的进步。有一个非常有意思的事情就当我意识到这个进步的时候我会发现我自己好像无能为力。我好像改不动企业的其他部门。但甚至于连一些企业的基本的运营我们都改不动。
所以当精益企业这本书问世的时候，我其实很快读了这个当时我是其中的reviewer之一，很快就读了他的草稿，在没发布之前就读到了，读了之后呢，有一种非常豁然开朗的一种感觉。这张图里边的左上角这个房子其实并不在原书里边。只是中国的这个斯沃克中国咨询团队我们根据的体系做了提炼和总结。
原书其实是把各个企业就好像我当时打了一个比方，把北京的眼睛，南京人的嘴巴，四川人的耳朵拼凑在一起。可能把各个企业里边做得好的板块，这些板块都是如果深究的话其实某种意义上都是按照敏捷的这种思想在运作。包括我们的HR甚至于都是说在依托敏捷的思想在运作。把它做了一个总结和打包，然后给个名字叫做精益企业。
那这个时候我的这个感触就说，这个看来不仅仅是我一个人的问题。其实在这个过程中的时候，欧美的走得比较前的一些企业同样有这样的问题。那么如果他们没有面临这样的挑战还没有这样的问题的话就不会有精益企业这本书尝试着把各个企业里边做的好的部分拿出来总结，尝试着把这些部分拼装成一个相对来说比较成功的一个体系。
那么真正意义上，这本书里面如果说给我和我的团队感触最大我们讨论完了之后，其实是这个下面这句话。那么我们可以看到这句话对我们所在的企业和组织做了一个定义，这个定义用上边的中文叫复杂适应系统，我其实自己更希望加一个字叫复杂自适应系统，在生物学里所谓的复杂自适应系统，当我们给定了约束条件的情况下，在系统内部的生物，我们假设这个生物其实都有一定的自立水平，他们会自己找到在这个约束条件下生存的最优解。
当我们都承认我们的这个企业，或我们生存的组织是这样的一个复杂自适应系统的时候。我们所行使的规则以及我们和别人的协作方式就应该发生转变。
那么，这也就过度到了我今天想讲的第二部分。也就是说，在精益企业整个框架下面。我感触最深的四个方面，精益企业里面有很多方面，但是我自己感触最深的是四个方面。
我们的第一个方面，我叫他做“小”产品。我认为正如这张胶片照片所展示的，我们这个行业特别是一些复杂的大型软件或者说是设备制造团队都会面临这样巨大的一个冲击。这个冲击呢，如果我们把收敛一下其实就是工程思维和设计思维的一个碰撞。
我们来理解一下工程性的思维，永远是我希望首先把我的问题收集起来，找到类似的一个数学公式，然后呢，把我的这个公式进行验证，验证完了之后我会做一个实现。
那么在左边这个图里边，我们在现实情况中经常遇到。可能有不同的需求单位给我们提需求。然后呢我们把需求进行了一个打包，做了一个解决方案。这个时候呢我们把解决方案抛给我们的需求单位或者我们一些专家做澄清。
这些需求单位和我们的专家会告诉我们说你的解决方案不完善，你需要再考虑xyz。于是我们把我们的解决方案做的越来越大。
直到我们在有时间压力的时候，我们会把这个解决方案快速的抛给我们的产品生产团队。那么我们这个产品生产团队拿到这个解决方案的时候，理论上讲他应该造出一个产品满足我解决方案里面说的所有内容。
当然这种工程思维的观念，其实在其他的领域里，比如说我们的这个建造业，我们造桥造房子，实际上就是这样一个游戏规则。那么这个游戏规则那当然对比我们现在造软件，其实是很不一样的，这里面的我就不在累述了。我相信我们教练很多都能够理解。
但如果我们看一下右边的这种制造方式，我们并不把每一个业务的需求。当成是我们必须要做的任务，我们把我们的业务的需求当成了我们的一个个产品制造的机会点。对每一个机会点，我们又会产生各种各样的，这在这里没用了一个词语叫hypothesis，就是假说。对为什么是假说呢，因为我们认为说我做这样的事情就能够满足我这样的机会。
那针对机会，针对我提出的假说，我会做一些小的验证。或者做一些价值的优先级排序。我会找出我认为最有可能成功的机会和假说。
当我找出了这样的机会和假说的时候，我会启动我的团队去生产这样的小产品而不是做大。
后续的时候我会通过持续的收集反馈，获取整个产品的良性运转。显然如果我们对比左右两幅图的话，我们可以看到左边的图它的制造效率很可能比右边图的制造效率要高。仅从生产效率而言。但是右边这幅图他的这种制造工艺，其实正体现了我们对响应力的追求。
同时，我们右边的这种制造工艺的方法。更能够适应我们市场的这种持续变化。那么左边的这种图我们以前会说这种制造工艺在一些行业里面是必要的。比我们认为说在这个造桥粱造房子这个阶段我们认为他的确定性很大，所以他就是必要的，但如果我们设想一下。包括室内装修在内的这些以前传统的认为是可以适用于左边的这种制造工艺的。现在正在被所谓的互联网思维所颠覆。
所以这是我们的第一点就是我们要做小产品。
第二点给我非常大的感触的是，我们要重新的思考我们的授权和我们约束条件的设置机制。这个案例给我感触很大。当时是ARM当时打败英特尔的时候，当然现在ARM不是特别景气。当年的时候他们做了一件事情，做一款微处理器的时候他们比英特尔先做出来，他们做的事情，这个说这句话的是他们的一个leader。这个leader告诉我们说，当时他给的团队的条件是缺钱和缺人。
当然在精益的时代的时候，大野耐一说过同样的话。大野耐一说我并没有给你加人减人，并没有给你加时间减时间，也没有加资源减资源，我就是要求你改进。
如果我们来思考，他们到底做了一件什么事情，其实他们做对了两件事情，第一件事情就是授权。以前我们做一个管理的时候，像大野耐一这样的角色的这种高级管理者，他是制定计划的，他说了算。现在不论是在ARM这个例子里面，还是我们精益制造的例子里面，我们都可以显著的看到授权发生了变化。一个一线的团队拥有了更多的自主权利。
第二点的时候我们会发现他表面上说我缺钱，我缺人我不给你资源不给你增加时间，实际上他是在干一件事情，就是在设置一个约束条件。
所以，如果说给我感触最大的第二点就是在精益企业的方向上，我们应该思考如何去授权如何去设置合理的约束条件。
第三点给我感触非常深的是组织结构的松耦合。这个非常有意思，我这个截图是安丰同学利用了Martin Fowler老马同学的这种微服务定义的这篇文章里的两个图。当时总结的非常到位，两句话：组织上应该是反僵化的，架构上应该反垄断。这里我把他再学术提炼一下，其实在现在这个时代，我们如果用敏捷宣言里的排比句，我们实际上是思考清楚了集体智慧，英文叫Collective intelligence。实际上是胜过我们现在的执行力的，这个是实际上如果你是搞清楚了的话，你会发现松耦合的结构是有利于我们集体智慧的。
那么近期的时候呢实际上，如果把这个话题再拔高一点。我们会看到近期在这种松耦合团队组织上的一些巨大的突破。
我给出了大家四种组织结构，这个组织结构今天不多讲，但是我希望我们的教练同学能够去关注倒数第二个叫合弄制，这个是基于在democracy民主制，和Sociocracy社会制之间的。
非常有意思的我们可以看到人类社会的组织结构也在随之发生变化。所以我的个人结论是，无论如何在这个行业里面我们要学会去驾驭或打造这种组织结构上的松耦合和灵活性。
最后第四点，我感触比较深的是利用这个打造我们真正意义上的，能够支持“黑天鹅”，就是创新的孵化。这种事很难的，刚才这幅图已经说明很大一个问题。其实在这种创新的孵化过程中，很多的黑天鹅的尝试都会失败。最后的一个也许在一百个尝试中才会成功一个。这个概念其实也不是最新的，当时在精益制造的时代的时候有一种提法Set-based concurrent engineer，我在做engineer的过程中其实我是在做一个系列，而不是只在做一种产品。
很多人就很多学者在研究的过程中认为精益的成功，其实是来源于他能够在同时做多种工艺，从最简单的，他的一条流水线上面能够产出不同型号的汽车，到甚至于说一条流水线上既能够产出摩托车也能够产出汽车。
所以其实就是最原始的一种心态，我可以理解说这是最原始的一种支持创新的心态。但是在我们这个行业里边的时候，其实我们现在遇到的阻力是非常大的。我们在这方面，其实要想有固定的投入非常难因为我们度量的方式，现在仍然在以前的那个时代的度量方式，我们依然希望说一投资就要谈投资回报率。
时间的原因我就把这四点就讲这四点。那么，最后稍微总结一下what，就给我这个精益企业里面，在这个what部分给我最深的四个方面。第一是做小产品，刚才已经讲到了。第二的是我们要在授权和合理的设置约束条件上去思考。第三部分的是我们组织结构上必须松耦合。第四部分呢，我们必须要打造一种支持黑天鹅也就说支持这种创新的孵化环境。
最后一部分我讲一下我个人认为，如果我们教练认可精益企业叙述的方向，那么我们应该在这个平时在指导团队或者小到一个团队大到一个企业的时候我们应该注重哪些方面。这里边的我讲两个方面。
第一个方面的是我的偶像，借用我的偶像这句话，质量大师戴明同学曾经说过一句话，这句话是反话，当然如果我们正向解读这句话就是告诉你说如果你觉得变化不是必须的，那实际上对一个组织来讲，存活其实也没有必要了。简言之你的企业或你的组织在这样的认知情况下，一定会死亡。这一点，我为什么用戴明的这句话，是想告诉我们所有的教练，改进是团队自己的责任，而不是我们教练手把手天天要在团队里面你们才会改进，对于一个教练来讲， 在前期的时候，如果需要我们切身实地真实展示这种新的流程理念的运作方式我认为是应该的。因为在前期团队需要你去展示正确的做事的方法，看到收益，在团队里边大部分的实践主义者都会看到了成果，才会跟着你一起跑。
但是如果到了中后期之后，这个团队还是依赖于我们教练继续再做改进，没有教练就不做改进。那么这个团队是不可能活下去的。也就意味着说这个团队不是我们在迈向精益企业中需要去打造的这样团队。我们需要打造团队是能够持续自我改进的团队。
这是我认为教练必须关注的第一点。
我认为教练必须关注的第二点，借用了一个比较时髦的现在的一个提法，很多人说这个持续交付现在取代敏捷，我觉得这个提法非常有意思，我个人并不赞同因为敏捷并不是像持续交付的这样所谓的就是敏捷非是一种工程实践，只是提了一种工作的方法和原则。
但是我希望借助持续交付或这幅图画，这幅图是当时斯沃克一个架构师总结的，应该也是一两年前了，所以并不是最新的。
那么但是呢我想用这张图来说明一个问题，就是我们的教练在关注于团队能够做自我改进能够打造这种主动改进的团队的同时，一定要关注我们生产制造工艺的提升。
不管我们用持续交付还是用DY works，还是用这个XP不管我们是谈的是这个面向对象设计能力还是还是函数式设计能力，无论如何我们必然要打造这种核心的工程能力。只有提升了工程能力之后，我们才能够保证我们的团队的持续改进是可以落地的。
当然，很多时候大家会说肖然你这个就是前面那个是管理教练后面这个是技术教练。我个人其实并非是很认同这种观念。
因为我其实不认为我们在座的各位教练应该给自己戴个帽子叫管理教练或叫技术教练。我认为作为教练本身是付能给团队。让团队能够主动的去学习更好的方法以及流程。
为什么产生这个管理教练和技术教练呢？我觉得在如果说在这个咨询行业里面说的过去的，因为客户的时候ok要限定一个范围。从而时候能够说我在请的这个顾问他到底做什么？但是作为我们企业内部的发动机，企业内部的变革组织，我觉得大家应该按敏捷提倡的方法叫 Cross-function跨职能，所以我觉得教练不应该是分上管理教练、技术教练或者以后再来一个DevOps教练。
鉴于时间关系，最后稍微总结一下，今天的分享主要是三个部分。我希望通过Why，让大家理解精益企业这个提法的由来。当然这个过程中我给大家讲了我的两次思想上我认为的进步。第一次是我理解到了敏捷所追求的响应力。那么第二次那是我理解到了转型过程中，同样的MVP适用的原则。第二大部分的时候我讲了给我感触最深的精益企业的里边的what的四个部分。这四个部分再重复一次，第一个是做小产品，那第二个是授权和设置合理的约束条件的。第三个那是我们在组织结构上一定要松耦合一定要灵活，这个提的通俗一点就是我们的社区文化。第四点的是我们要支持这种黑天鹅的创新环境。
那么最后一部分我从我个人做教练的方面讲两方面。第一个方面借用了戴明老先生的观点，改进是团队自己的事情。如果我们教练不能够帮助团队意识到这一点，我觉得我们教练的工作是不成功的。第二部分的时候是作为教练，我们必须持续地帮助团队认清楚持续提升软件制造的工艺，是他们必须做的。只有做到这样的话，这样的团队这样的组织和这样的企业才能逐步的迈向精益企业。
这里我的分享就结束了，现在我们进入到问答时间。
首先回答一下陈冲你的这个提问。跟中心我觉得很有渊源和我们合作很多年。或多或少都有些了解。那么我个人的观点就这个精益企业里边，当然我们可以不谈精益企业这么大。我觉得做小产品这件事情实际上是我们这个教练组里边应该去讨论的。
为什么这样说呢，其实在我接触了很多的中心团队以后。大家的工程实践能力，坦诚讲我觉得比很多的互联网企业都要强。
但始终大家所围绕的问题都是怎么样能够把一个产品的所有的需求都梳理得很清楚。然后呢我们做出来的产品那就是满足所有需求的。很少有人去问我们是不是可以按照另外一种思维观念来做产品。
最老的声音是就几年前，我记得很早之前合作的时候，有些团队告诉我说我们运营商就是这样的。他们的反应周期就是一年，所以就应该这样，所以我的这个需求就是这样量大。
那当然，从世界范围来看这个其实以前没法反驳，以前觉得确实是客观约束条件。但实际上你从这几年的条件来看其实运营商也在改变。那为什么我没有提前一步去转变自己的思维去引领这种改变呢，这个某种意义上是我觉得最值得思考的地方。当时是我记得很清楚在一四年或一五年的时候，我记得谁告诉我说好像在欧美有八百块钱美金的一个鸡蛋吧，这些事情好像是对大家的触动是非常大的。
那么所以说那张照片，做小产品还是大产品，我觉得如果回答陈冲这个问题的话，我们的教练组应该特别去关注。
那么我再来说一下国强你问的这个问题，其实某种意义上现在业内比较流行的一个说法叫做单一关键指标，用中国人的话来讲就是你想追求什么你就得到什么。
那我们来看一下好如果说我们跟团队讲说我们现在要追求效率。那还有一种情况下面就是每个团队中的必然是有角色划分的。那么这个角色的划分就是，每个团队里边你说你要效率，那我就告诉你说我现在需求做的越来越快。或者说测试说我测得越来越快了。但是我是不是一定要关注我跟测试跟开发的合作呢，显然不是。如果放大一点，对我们整个企业来说，那对我前期的市场部门来讲很简单就是我收集到的需求越多越好。
但如果反过来，我们把单一的关键指标变成响应力，我们不再主动去提这个效率。实际上效率是一个间接因素。如果你从这个整个丰田制造或者说从敏捷的这些前辈们身上学到的东西就是他们其实找准了正确的单一关键指标，这个指标就是响应力。
我们可以推测一下，如果说你的响应力提升了。你对客户的响应力提升了，我们可以比较负责任的说至少你质量和你制造工艺得提升吧，要不然响应力怎么提升起来呢？因为我们都知道本身就很复杂，那就好像这个汽车流水线上面，如果现在外部告诉你说我要红色黑色汽车。你要想提升响应力至少你的生产水平和工艺得提升。
另外一点就是我们可以看到说这个响应率和效率其实在某种程度上，当我们去追求的时候特别是我们这个行业，我们的环节比较多的情况下，经过的交接或者握手比较多的情况下，其实如果我们不去关注这个交界的速率，真正关系到这个响应力的结果，我们就很有可能让部门和部门之间自己树立起一个墙，不是他有意要树立的。因为你告诉他说你效率要高，他就要做内部优化，一旦它内部优化了之后他对外部不见得是友好的。
但其实这个也当时就是我的第二个坎，第一个坎迈过去之后，我理解说原来是响应力。这个是我们要追求的东西，在现在这个生产制造行业里边。那么第二个坎就是我怎么样拿到这个响应力，其实当时我们在做很多研发团队的时候也遇到一个问题，我研发团队做得相当不错了。但是外部看来说没什么变化，你到底变了什么，你说版本交付节奏快了。如果站在我们假设站在运营层面来看，版本交付节奏快了对我有什么影响，没有。这个是当时我说这个转型过程中MVP这个理念给我触动非常大的一个方面。
我再回答一下第三个问题，曾亮亮同学提出的。其实这么多年就这个全功能团队，当时engineer提法非常多。这都是一个相对的，在我们做咨询的过程中会发现说这是一个相对的，固然有高手，优良团队是一种幸运，这个团队能力就是很强，他做东西就做的很快。当然这样的一个团队确实存在，我们这个行业里边比比皆是的。确实很强，但是不是在一个团队协作过程中的时候这种全功能真正意义上能够把我的响应力提升的很快呢
这个是打一个问号的，我们很多所谓的全功能团队就是把各个角色放到一起，然后我们说你自己workout，根据刚才那个理论来说，任何企业和组织都是一个复杂自适应系统。那我只要外部约束条件给你设置好了，那你应该就这样表现了，这是我们当时认为就是这样的一个节奏。
但是我们应该反过来看我们给外部设的约束条件，我们其实外部设的约束条件是说经常会团队说你们得考察一下你们这个里边测试的时候发现出现率多少。然后你们这个泄露多少事故，并且你得告诉我你这个过程中的流程和微信。
这些约束条件实际上，正是因为有这些约束条件，我们其实在逐渐的破坏全功能团队。即使我们把所有的角色都放到这个里边来，我们并没有给他很好的条件。
我们可以看两个案例，一个极端案例，比如说亚马逊这是一个非常粗暴简单的一个极端的案例。贝索斯当年做一件事情的就是说我现在不管了，我就把团队化小。然后呢我告诉你说，其他事情我都不管。只要你不出问题你自己玩儿。从需求到最后上线全部你自己负责，出了问题的时候，最好别让我知道。让我知道的话我就是一封邮件回给你的主管，然后打问号，这就是贝索斯的一个做法。
那么他这种简单粗暴的方式在亚马逊其实某种意义上起到了效果，我们现在看到的所谓的亚马逊里边平台我们觉得做的非常不错的东西，其实都是痛苦逼出来的。因为他给的约束条件就是这样的，大家没办法睡不着觉，我也听到亚马逊里边的人的分享，其实就是逼出来的。因为他设置了一个当时在他那个场景企业里边它的企业文化里边，正确的约束条件。
那就这样的约束条件下你会发现谷歌的创新能力很强。我并不认为谷歌就是全功能团队，而我们一些大型的电信设备团队就不可以做全功能团队。我认为恰恰是我们外部的一些约束条件造成的团队无法真正意义上成为全功能。
那么从另外一个角度如果从教练的角度，我还是比较坚持，至少现在我给团队坚持两点，第一点就是我认为一个全功能的团队，你就应该可以有持续改进的动力，因为你们角色在一起的时候你们要持续改进互相之间的协作。也就是说你们握手和交接棒的速度就是我关注的，那我希望你们自己改进。第二点就是我觉得这个团队，你是否可以持续的提升软件或者你的这个生产制造工艺。如果您持续这样做，然而这两点你都做得很好，我认为这样的团队，我们不用去追求她是否全功能。
第四个问题，左杨梅同学问的这个问题。就是在这些方面。这本书在当时在审稿的时候，review的时候我就发现一个问题，我在内部开了一个玩笑，我说这本书方向是正确的。但是他有个问题就是他只是罗列出来了各个企业里面做的一些好的方面。然后希望把这个人拼凑出来。但是在一些真正意义上比如说我们现在看到这个机翼。甚至于说在业内那现在比较有名的几家这个大型的企业在做这种敏捷方面做的不错的。其他有些东西可以借鉴，比如说在财务行业里边在欧洲做得比较好就是这个beyond budget超越预算。
那这块，至少我们看了之后还是比较认可的。你说他现在有没有像敏捷工程制造方面的实践呢，我觉得还远远没到，不一定。
在运营系列里边的其实已经有了，这本书其实有个浅涵的意思，就运营方面精益做的非常好。在我们可以回过去看这个整个精益的体系。精益的体系并没有告诉你很多财务和战略方面的其实他告诉你更多的是运营方面，也就是说它的整个运营机制是完备的。
如果来看他的运营机制里面有两个非常关键的东西，第一个我已经讲了就是质量大师戴明提的那句话。那就如果说你团队认知不到持续改进是你的责任的话，比你的本职工作还要重要的话，你的团队是没有希望的。那么第二点就是团队里面的每一个管理角色不但要懂这种理念，同时要去教这种理念，就是精益的这个运营过程中最重要两点。
在这个其他的战略方面其实这一方面，当时安峰分享的时候他给了一些模型，我觉得这个战略的却是现在在目前来看在我这个制造行业里面你比较难于驾驭。比如麦肯锡分享的是麦肯锡一个三个地平线模型，就是123，大家可以去查，然后也有这种类似于Boston Consulting提出的四个项线模型，这些都是战略思考的。但我个人觉得不论是这些所有的框架里边，其实有最大的一个方面可能这一两年都是需要去理解的，我强烈建议大家看一下那个我说的合弄制Holacracy，大家去看一下，合弄制里的核心组织观念就是这几年我们比较重要的一个话题就是创新。创新在一个组织里边应该怎样对待，像中心这样的一个万人的组织里边，那这个创新我应该怎样才能鼓励创新，是不是我一定要像一些互联网企业里边搞类似于竞争，或者搞赛马我才能有创新，是不是我可以有其他的一些机制，这个是我觉得战略里边目前来看还是缺失的一个版块。
最后说一句说如果说业界哪些可以借鉴的，我觉得可大家可以去看GE，GE是一个很让人吃惊的一个企业，到目前来看，就是他放弃了自己最赚钱的投资这个版块，把他彻底给卖了，回归到了真正意义上的科技板块。当然很多中国企业已经在学了，学着这种方式变成一个科技企业。也就是我们经常说的现在很多企业说我其实不是做这个行业的我是科技企业。原因是如果我拥有科技的话我就可以做任何事情。
那其他的方面我觉得未来一两年可能会出现很多的一些案例，这个呢大家应该关注一下。包括在人力资源或者在一些其它领域我觉得会冒出来不少根据框架的结构下会冒出很多的不同的总结。
1050
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
