当谈论研发效能时，我们到底在谈什么？｜大咖圆桌精华回顾

不知不觉，「ONES 研发效能大师课」已经来到了本季的最后一期。在前面六期课程，张乐、冯斌（Kid）、董晓红三位老师深度讲解了研发效能的现状、改进实践与提升瓶颈。

在这个过程中，我们也发现对于效能改进实践中的问题，还有很多同学格外地关注。所以本期大师课，我们一改以往的课程范式，采用圆桌对话的形式，邀请三位不同领域的行业大咖作为对话嘉宾，对大家在研发改进场景中的共性与个性问题进行探讨、解答。

这三位老师分别是张乐（DevOps 与研发效能资深技术专家）、黄良懿（前 OPPO 平台技术高级总监）、谢孟军（积梦智能 CEO）。此外，ONES 联合创始人兼 CTO 冯斌也在本次对谈中担任主持人。

在筹备这次圆桌对话之前，我们发放了一份问卷，调研大家在研发效能上最关注的问题都有哪些。很开心，我们收到了非常多真诚且详细的反馈，包括「当我们谈研发效能时，我们到底在谈论什么」、「如何打造高效能团队」、「如何选用效能工具」。

接下来，他们将以「穿越经济周期，研发如何降本增效」为核心主题，就当下企业效能改进中的实际问题进行探讨，同时也将对大家提出的问题给予针对性的解答。

怎样的效能算是好的效能？

当我们谈研发效能时，我们到底在谈论什么呢？在聊具体的提升效能方法之前，或许更值得我们追问的是研发效能的目标和定义问题。对此，三位老师都给出了自己的思考和见解。

张乐：在降本增效的大背景下，一方面我们要想办法让企业有更高的效能，另一方面我们也会感觉到越来越大的效能压力。因为软件会越做越复杂，相应地，研发人员也会越招越多，软件也会越做越大。但是从结果上看，效能的表现很有可能不升反降。

就像我经常听到有同学，「你看我们公司也没少招人，会也没少开，代码也没少写，工具也没少用，最终问题并没有变少，到底是什么原因」？对于这种现象，行业里称之为「研发效能的鸿沟」，意思是说我们期望的效能与业务发展不能匹配。

如果从宏观的角度来看这个问题，我们就要思考了：效能问题是不是只有现在才有？其实并不是。研发效能是一个历史悠久的话题，很久之前软件行业就在谈论这个话题，但是，为什么之前没有考虑「研发效能鸿沟」的问题呢？

当业务还在迅猛发展的时候，效能问题是可以被掩盖的，比如说通过在短时间内拼研发人力就能解决。但这种解决是「表面」的，问题在事实上仍然存在。所以当问题野蛮发展到不可把控的时候，就暴露出来了。这正是我们在当下谈降本增效的时候，为什么尤其重视效能的原因之一。

此外，对于研发效能的目标和底层逻辑，我们也要有一个比较清晰的认知。效能到底是什么？效能真的等同于效率吗？其实不一定。

前一阵双十一，我在刷京东图书的排行榜发现有一本书经久不衰，就是《人月神话》。这应该是我们软件行业人手一本的书，里面有一句话我记得特别清楚：「产品开发过程中如果只有一件事最困难，那困难的到底是什么？是写代码吗？是提需求吗？不是，是精准地决定你要做什么。」

所以当我们谈论效能的时候，不应该只看效率，还要看我们的方向是否正确，以及追求什么是正确的事情。比如说如何找到一个靠谱的需求呢？从这个角度讲，研发效能要解决的是「效率+有效性」的问题。

再进一步想，我们提效的最终目标是什么？我们在谈 DevOps 时往往过于局限，把 DevOps 简单地看成 CI/CD 等工程层面的技术实践。对于工程师来说这可能是比较友好的，但实际上 IT 是一个黑盒，业务方看不到里面的内容。从这个层面看，我们提效的最终目标「并不是产出更多，而是要交付更好的业务价值」。

再从中观层面来看。企业在提效上推行了很多理念，敏捷、看板等，但实际效果并没有预期得那样好。在我看来，这是局部优化导致的问题。

我们做了很多动作，比如拼命写代码，用各种快捷键和炫酷的工具，好不容易节省了 10 分钟，但这 10 分钟，很可能被一个低效的会议就抵消了。再比如，我们在 CI/CD 里持续优化编译的速度，终于把编译的时间压缩了 30 分钟，而这 30 分钟，可能又被一个需求的变更吃掉了。

这是一种误区，局部优化感觉有效，但实际上很可能没有效果，因为工作的流动效率很低。从这个角度看，我倒觉得效能主要的优化方向应该是「价值流思维」。

当我们在研发过程中遇到瓶颈时，根据约束理论，在瓶颈之前、之后的任何优化都没有用，而只有在瓶颈这个点上的优化才是有效的，这就需要我们在理念上有所转变。不光是资源效率、工时打卡，还要流动效率。而流动效率，说到底就是「增值活动占总时间的占比」。这个数字我在业界看过很多相关统计，一般来说，30% 到 40% 的流动效率就是一个很好的水平，不过大多数企业会更低。

最后从微观来看，研发效能这些事儿都是由工程师去干的，那从「人」的层面上来看，研发效能得不到提升的原因可能是什么呢？在工程师层面，我认为可能跟管理者与一线工程师的思想脱节有关。比如管理者要求研发人员把单元测试覆盖率提到百分之多少，可能执行层并不是特别理解为什么要完成这个指标，便通过相对容易的办法来应付。这样的话，好的管理思路就没有真正渗透到一线工程师的思想里。

另外，基层也存在很多脱节，比如管理层既让提升效能，但是又不给工程师留时间，这就是典型的既让马儿跑，又不给它吃草。那么管理者可能要做出权衡，想办法把这种脱节给紧密地连接起来。

还有一些更常见的问题，比如在管理工具还没有准备好的情况下，管理层就一声令下，单纯靠人力去推行一些好的工程实践、好的研发理念。结果可想而知。

所以从微观来讲，对于每一个执行的研发人员，我们都要考虑是否能因人而异地给工程师更多的帮助和赋能，让工程师有驱动力去主动提升效能。

黄良懿：当谈论研发效能的时候，我觉得有「广义」和「狭义」两个层面的理解。狭义的理解比较简单，指传统的从开发到发布的研发交付流程，围绕的核心就是研发工程师的知识领域和技术交付活动。

而广义上的研发效能，其实是从需求阶段开始一直到完成设计、上线发布，都应该是我们研发人员考虑的事情。我们能给业务创造多少价值？甚至再往前一点，我们对业务产生了什么影响？

比如说我们实施 CI/CD，这是我们研发人员的自娱自乐，还是真正帮助解决了一些业务上的问题呢？今年创新迭代的次数，与去年相比变多了还是更少了？再直接点儿，我们能不能告诉业务一个数字（带来了多少收入、增加了多少利润）？

你会发现，从「我做了什么」，到可以告诉业务「我对你产生了什么影响」，这里就有一个很高的对于业务理解能力的要求。之前我听过许式伟老师讲的一个观点，「没有任何一个足够 Professional 的架构师，是可以脱离对业务的深度理解而单独存在的」，我非常赞同。我们要先和业务方有共鸣，这个共鸣包括共同的知识背景和共同的理解。以此为前提，我们工作所产出的结果才能与业务方对业务价值的追求保持一致，这才是一个非常好的研发交付。

你会发现，广义和狭义最大的区别就在于对业务的理解能力。这个过程当中有一些具体的方法，可以帮助我们和业务方有更充分的沟通。比如说我们在重要的项目上，要求业务方在一开始就告诉我们准备撬动什么指标，以及对于指标的期望是多少。

最开始大家可能都估不准这些数字，但是多做几次，估算会变得越来越准。以我的实际经验来看，到后来我们估算的偏差率可以在 15% 以内。所以还是要从全局的视角去看待整个研发过程，然后通过量化，帮助我们找到每个阶段的问题是什么，在此基础之上再去重点解决和突破。

提升业务理解能力，在我看来这也是一个持续修炼的过程，还有个最简单的办法——找业务同学多交流多吃饭。（更详细的方法分享在视频里，你可以点击观看👇）

谢孟军：在我看来，我们软件行业的研发效能提升应该向制造业学习。在我们软件行业，大家更多时候是去试错，允许发布带有 Bug 的产品。但是在制造业，拥有一套非常完善和严谨的流程，他们内部叫小批量的 P1、P2、P3。

举个例子，我原来在 Apple，要做出一个好的手机，需要经过好多个版本，从小批量的测试到最后大批量的测试，这是一个非常严谨的过程。在军工行业里，还有「归零分析」，意思是如果所有东西全部停止，该怎么从头到尾一步一步演化出来，流程非常之严谨。还有航空航天等行业，他们的制造中始终有一个 100% 的概念，以此保证最后的成功。但在软件行业，是快速上线，是让用户来提 Bug。虽然有所谓的 CI/CD，但实质上还是在让用户来帮助测试，有问题的话再去快速响应。

我们软件行业追求的是速度，比如能够快速上线。但从整个研发的成本来说，快速上线未必能给我们带来大的收益。假设上线后发现有 Bug，对用户造成了损失，这其实也应该算到成本里。而在制造行业里，一个零部件虽然只有一块钱的价值，但是在生产制造过程中如果能被识别出来，那损失也就只有一块钱。一旦一辆车卖出去，最后因为质量问题召回的话，那损失可能会被放大千倍万倍。

所以当我接触到制造业后，就觉得咱们还是太肤浅了，应该向制造行业学习，遇到这种 Bug 该怎样去复盘，怎么改进整个流程。要从整体的效能上来看局部，要从整体的成本来算我们过程中出现的问题。

如何打造高效能团队？

所有效能的提升，包括软件研发协作的过程，其实都是「人」来做的，而我们「人」所做出的决策不仅是主观的，还会受到各种客观因素的影响。所以接下来第二个话题，我们就来聊聊如何高效管理团队，包括如何组织架构，如何选人育人，等等。

黄良懿：选人用人，我觉得这对于所有团队来说都是非常重要的话题。我先分享一个很有感触的小故事吧，有个部门有一年拿到了年度奖，他们的 Leader 上台发言，说他觉得过去一年最大的变化，就是自己的部门变成了正规军。

很有意思，什么叫「正规军」呢？我觉得至少包含三个特征：它是专业高效的，是标准规范的，是一个持续学习型的组织。这是一个组织应该拥有的文化价值观，以此为前提，才能帮助业务获得价值增长。

那么在选人用人上，我们该怎么具体去落实，才能让团队形成一个正规军呢？

第一个事情是「人岗匹配」。在选人方面，我们着重考虑了一个问题——对于一个研发工程师而言最重要的数字项是什么？接着我们进行了优先级排序，排在最高的是热爱技术、富有自驱力，第二位是快速学习、善于总结，第三是逻辑清晰、思维缜密。之所以这样去排序，是因为我们更多考虑的是哪些事情是难以改变的。因此我们要选对人，「是这样的人，将来才会有很好的成长，在岗位上做出好的成绩」。

可能很多时候我们会把逻辑清晰放在前面，或者把快速学习放在前面，但是如果没有对于技术的热爱，就没有自驱力，那么天花板相对来说就没有那么高。所以有了数字项的识别后，专业面试官应该考察什么，Junior 级别的领导应该考察什么，HR 应该考察什么，都非常清楚了。

在「用」的层面上，比较重要的是在不同方式下该使用何种管理手段，做到因「人」制宜。比如对于不太具有创意的岗位，可能命令式的沟通会更有效一些；而对于 Junior 的同学来讲，那这种沟通手段就并不高效；还有对于一个很成熟的管理者来说，我们要允许他可能会犯很小的错误，更多时候还要给予一些支持和帮助。

当然，通过选和用，也可以形成一个传帮带的成长型团队氛围。从 Junior 到 Senior 的过程中，我们应该学什么？同样，我成长了以后应该给其他人分享什么？哪怕我不是特别资深，但我在项目中踩过一些坑，是不是也可以输出一下？通过分享和学习，逐渐形成一个相对体系化的知识框架和组织氛围。

在「留」的方面，我觉得可能要做到三点。一是要给予足够的成长空间；二是让他能够获得与能力和成长相匹配的薪酬、激励；三是别让他受委屈。其实很多团队里的人员流失，都是受了委屈以后才开始考虑离开的，而不是因为市场上有人给了更具竞争力的薪酬。

谢孟军：在打造高效能团队的时候，我觉得很重要的是流程。有了这套东西，很明显的好处就是「权责利分明」，让大家知道这个事情应该归谁做，做了到底该由谁来负责，从而在最大程度上激发出每个人的积极性。

这里我想通过例子来说明这一点。（你可以观看如下视频，了解更多👇）

当然，一说到流程，可能大家会想起很多负面的词汇，比如觉得流程不靠谱，研发人员的执行成本太高。这些并不能说明流程没有用，只能说明流程没有用好。一个有效的流程，其中的关键就是「节点」。节点可以保证流程可以一直往下走，从而「挤」出效率。就像华为当年进行流程再造，从而激发出组织的活力，这是很值得我们其他企业学习的地方。

张乐：谢老师讲的这些，其实我特别感同身受。我们有时候需要向制造行业学习，是因为相互之间很多底层原理是相通的。制造行业从 80 年代开始就在用精益的方法去管理，把生产过程看作一条价值流，并相信拉动式的生产能够带来好的业务结果。此外，这条价值流要不断改进，以求尽善尽美。可以说，「做流程设计不是为了流程，而是为了促进价值的流动」。

我前一阵翻译了一本书，叫《价值流动：数字化场景下软件研发效能与业务敏捷的关键》。原作者是一位搞软件研发的创业者，他也提到了类似的观点。他曾经去参观宝马汽车的工厂，发现整个设计是完全按照一个汽车价值的流动来安排生产的，以此来促进不同车间的任务流转。最厉害的是，厂房可以根据不同的用户需求灵活调整。

除了价值流动外，还有经营生产的理念也同样值得学习。比如在制造业的流程中，要一次做对，不往下游传递任何一个有问题的东西。我知道在丰田的工厂，可能安灯拉绳一天被触发上千次，把质量中很小的瑕疵都认为是可以持续改进的。而不是说产品出来之后再去追溯、检测，再去召回。

流程，可能听起来会给人一种固化、官僚、僵化的印象，但事实上，对于流程的调整应该是我们日常每天都要做的事情。让流程保持流动，让一个需求没有等待地往下流动，在每一个环节都能产生增值，最终交付给用户。

就像刚才谢老师说的，我们并不是要做得更快，而是让等待的环节更少。有可能我们的产出还是那么多代码，但是用户侧的感知是完全不一样的，所以大的原则就是保持流动。

该如何选用工具以提升效能？

在我们回收的问卷里，有不少同学还很关注工具的选择问题，比如：没有自动化规则，建议用何种方式或工具支持，来解决人工更新多项状态不及时的问题？接下来第三个话题，我们就来聊聊工具那些事儿。

谢孟军：工具的话，我觉得最主要的工具还是源码管控，源码管控里有 Review，还有测试、 CI 这一整套。第二个就是文档化。一个项目中有很多人，这个迭代阶段完成后，很可能就会调到另一个项目中去。如果这个项目又有了一些新需求，可能就需要新的人来接手，这个时候就会有上下文的问题。如果团队中有文档化内容的沉淀，就可以避免很多麻烦。

黄良懿：工具很多，但是所有这些工具背后都是数字的量化和理解。彼得·德鲁克曾经说过，「If you can't measure it，you can't manage it（如果没有办法量化它，你就没有办法管理它）」。

所以我们更多时候需要用数字去发现问题。每次面临一个问题，而我们有两三个不同方案的时候，可以试着将这些方案的各项数据进行对比，算它的 ROI，来帮助我们做决策。我们之所以不太确定这件事情应该怎么做，很大原因是没有对这件事形成清晰的认识。没有足够多的量化数据，确定性就会非常低，仅此而已。

效能改进过程中的常见问题和风险

我们都知道，理论与实践之间存在着一条巨大的鸿沟，当理论回归实践，很有可能产生变形，那么从各位老师的实际经验出发，都经历过哪些坑呢？接下来我们就来聊聊这个话题。

张乐：刚才我们聊了工具和数据，我来延续这个话题，聊聊关于工具产生的数据问题。我们确实需要数据才能做改进或管理，但指标跟考核、绩效关联得非常紧密的情况下，很容易出现一些走形。从这个角度讲，企业怎么度量研发效能就变得尤为关键了。

对于效能的度量问题，我还有更多的分享。（点击如下视频即可了解👇）

谢孟军：不正确的 KPI，会误导执行层的工程师为了完成这个 KPI，而有不正确的做法。我们以前就犯过类似的错误，一味地追求速度，把项目交付的时间点认为是最重要的，由此导致后续很多评估指标跟不上，甚至有可能是错误的。

当我们去提升研发效能的时候，要从整体去考虑，思考我们设计指标，以及最终想要达到的目标是什么，把大的目标确定好。大的目标如果不能确定，只是去改进某一两个小目标，反而会让工程师的动作变得畸形。还是我们今天一直强调的，研发一定要为业务服务。

黄良懿：去年我在看一本书时，里面提到的一个观点让我挺震惊的——「如果一个东西不能讲清楚，也许它就并不存在」。我们在做研发效能提升的过程中，很多时候研发团队会非常兴奋，觉得做这件事肯定会对业务很有帮助，能产生很大的价值。

跟业务方说明后，很可能对方只是基于对我们过往成绩的信任，暂时认同了我们所说的结果，而并没有真的理解了可以产出什么样的价值。这个观点让我意识到，我们研发团队跟业务方很多时候并没有做到很好的、充分的沟通。

我们公司曾经做过一个实验，把工程师派到运营同学的工位上，然后不允许运营人员做任何他日常的工作，只能站在工程师的背后说，「你把鼠标移到那里，点一下这个，拖到那里去，再点一下那个按钮，填写材料，然后提交」。基本上工程师坐在这个位置上不会超过 15 分钟，就会马上央求着说，「你把我放回去，我马上帮你发一个版本，操作起来绝对流畅得很，这种问题不会再出现了」。

要把我们研发团队跟业务方的目标去同频好，最终才能产出高的业务价值。具体来说，第一，必须有数据量化的指导思想，帮助我们决策。第二，决定要做这件事情的时候，一定要跟业务有充分的沟通。也就是说，这个东西为什么要进到我的研发池子当中，占一些资源？这件事情为什么如此地重要？做好之后会对业务产生何种价值？对后续的业务有什么帮助吗？

还是回到那句话，「如果你不能讲清楚它，那它也许就并不存在」，这可能是过往工作当中没有注重横向上的沟通导致的。我们所有的优化，应该是一个团队奔着一个共同的目标，但如果这个共同目标没有沟通清楚，那它就不是共同目标。

大咖荐书

NO.1：张乐老师推荐的书是《软件研发效能权威指南》。

推荐理由：这是我们这两年组织国内行业专家共同撰写的一本书，也是目前业界第一本比较权威、全面、与时俱进的与研发效能强相关的书籍，希望能为我们研发效能相关人员提供一个系统化的指导框架。

在此基础之上，书里还有一些在企业里落地的方法、实践和困惑，也都作了梳理和说明。毕竟理论归理论，大家在实践的时候肯定会有很多变通，所以我们在书里为大家呈现了大公司是如何实践这些理论的，改进过程中是否有改变，甚至说是否需要做出一些迫不得已的调整。简单来讲，它是一本软件研发效能领域的百科全书，同时你也可以把它当作一本工具书。

NO.2：黄良懿老师推荐的书是《数据化决策》。

推荐理由：行业内一直有个说法就是数据有时候并不可信，数据也会骗人。我想澄清一下这个概念，数据是不会骗人的，数据工作的核心价值是降低不确定性，让决策做得更加精准，能让我们在一系列的决策中最终得到一个更好的价值，而不是消除不确定性。

这本书里介绍了很多种降低不确定性的方法，作者甚至提到连「爱」和「喜欢」都可以用数据量化的方式去衡量、区别。

我们软件人员普遍有理工科的学习背景，也很容易理解数据是怎么被生产出来的，但我们很少去理解数据该如何应用于决策之中，来帮助我们把事情做好、做对，从而为业务赋能。

举个例子，需求在很大程度上会影响整体的效能，但是什么样需求的优先级才是高的呢？这个时候数据会起到一个很好的辅助性作用。

NO.3：谢孟军老师推荐的书是《复盘》。

推荐理由：现在的时代具有很大的不确定性，加上每个人的职业经历都不同，所以对于过往成功的经验，我们其实很难可以借鉴，而只能靠自己摸索。怎么摸索呢？一个行之有效的办法就是「先经历，然后复盘」。

《复盘》这本书的副标题是「把经验转化为能力」。对于研发效能来说，我们现在缺少的就是把过去的经验进行总结与内化，我们需要通过跟团队一起去复盘，把自己经历过的东西沉淀为可复制的经验，继而转化为能力，然后改进、提升。

NO.4：冯斌（Kid）推荐的书为《卓有成效的敏捷》。

推荐理由：这本书是去年才有的中文版，作者是史蒂夫·迈克康奈尔，他的另外一本书估计大家会比较熟悉，叫《代码大全》。

这是一本非常好用的工具书。这种书的好处是，当在实际工作中遇到某个问题时，你可以在任何碎片化的时间翻开，然后根据目录找到相关章节，最后肯定会有所收获。每一个小章节都为我们提供了一个小洞见，给我们解疑答惑。

Q & A

Question 1：研发人员对于需求处理有什么好的办法吗？软件研发人员不知道怎么做好需求澄清，也不知道怎么写好用户故事，导致人员资源在迭代里的分配不均衡。

张乐：我觉得这跟这些年敏捷提的很多理念是相似的。有两点，第一要及早参与，共同讨论。如果拿到需求后，我们只是听产品经理讲一讲，或者评审一些，那不可能了解其中的细节。对于我们研发人员来说，最主要的还是得往前走，走到需求定义的大前方，参与到需求梳理和确认的过程当中。

第二，业内有很多更具象的实践和方法可以作为参考。比如实例化需求，就是我们把一句话的需求转化成一个可以执行的需求。那么这里有三个步骤：确定这个需求的目标；把需求所涉及的业务流程画出来，描述清楚；把需求相关的业务逻辑一条一条列出来，并用例子的方式去说明。

光看文字很容易看晕，那不如举几个例子，正例，反例，各种异常情况，帮助业务、开发、测试人员达成共识。而达成共识的过程，其实也是需求理解更加深刻的过程，可以帮助我们产出验收条件，转化成测试用例，形成需求管理的闭环。

Question 2：多线项目并发，但人员不足，只能串行，如何评估优先级？

黄良懿：在优先级的确定中，有一个很有名的方法论，叫「四象限」，把任务分成紧急且重要的、紧急不重要的、重要不紧急的，以及不重要且不紧急的。

但是实际中要评估的话，我觉得还要综合项目的成熟度来判定，比如大公司和小公司肯定是不一样的处理方法。对于大公司而言，线上业务出现任何问题都是优先级极高的事情，因为它意味着重大产出部分受到了威胁和挑战。但对于一个创业型企业来讲，可能你的版本发出去，线上也就几十个用户。

这里就有一个很有意思的问题了，在不同的组织中，紧急的事情是有区别的，那要怎么判定事情的优先级呢？我觉得很重要的一个依据是，可以通过对最终影响的收益或利润的量化来衡量。

另外，我一向认为一个健全的正规军团队，应该要做到极度重视「重要而不紧急」的事情，也就是第三象限。一般来讲，第四象限是我们砍需求的象限，意味着基本上可以忘了这件事，不需要考虑那么多，不做就是最好的选择。但是很多时候，很明显有不少事情处在第一象限。

第一象限，听起来是比第三象重要。但是如果一个团队长期有事情处在第一象限，这意味着我们一定没有重视好第三象限，也就是「重要而不紧急」的事情从来没有得到及时处理，所以才会有那么多「重要又紧急」的事情。而这可能就要从机制上去解决。

但是这些事情，很难被团队内部自发地解决掉，哪怕我们今天停下其他手头工作来专门处理，也很难完全处理掉。举一个例子，我当年接手 OPPO 运维团队时只有两个人，后来很迅速地又增加了一个人。但我的判断是，我们从两个人增加到三个人，哪怕增到到八个人，这几百台服务器还是会把大家的工作量撑满，也就是说工作的缺口依然很大。

所以当时有一个比较重要的决策，就是让其中一个人来缓解问题，然后再申请一个 Head Count，也就是第 4 个人，只负责处理事故级别的问题。除此以外，第 4 个人只能去做提升效率的工具。第一个月，团队整体的工作效率并没有明显的提高；第二个月，很明显就会发现另外三个人可以松口气了；第三个月，大家的工作强度降下来了，效率可以达到 30% 以上的增长。

过了一段时间就发现，第 4 个人已经扛起原来需要 8 个人的工作了，甚至还有点余力去看日志了。这就是一个破局的思路，把现在着火的事情换一个角度去看，就发现并不一定是每一处都起火了，而且也不需要马上灭火。先把一些能力建设起来，铺长线。

Question 3：制定了这些体系规则流程之后，执行的人他们有抵触心理。不按照这个这些规则这些流程来去做导致，其实后面我们增加了很多的成本，有没有一些破局的方法？

谢孟军：规则流程的建设，我觉得是个一把手工程，必须要 CEO 来推动。制定好规则之后，我们就是这么玩了。如果说只是内部的某一个流程，那大家可能就会有抵制心理。为什么？因为领导不重视，那最后对我的考核都是可有可无的。所以要从 CEO 开始，自上而下，大家在思想上保持高度地一致，从整体来提高效率。