当谈论研发效能时,我们到底在谈什么?|大咖圆桌精华回顾

cf1ba3c7d1015c9e9009988dfb00e2f7.gif

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

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

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

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

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

6a661d649b6e0b9950c5b8e1098f870b.png

fed7029a662313a89bb3aebc36863e5d.png

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

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

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

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

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

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

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

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

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

再进一步想,我们提效的最终目标是什么?我们在谈 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 该怎样去复盘,怎么改进整个流程。要从整体的效能上来看局部,要从整体的成本来算我们过程中出现的问题。

cbb3ccb2ba9744225edf321dc73b7516.png

如何打造高效能团队?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

94743968c35721eb152b84fffd3bafef.png

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

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

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

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

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

aa5648eabb968fb42025ef036ebe399b.png

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

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

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

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

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

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

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

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

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

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

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

46fdebaebe836178837dc7a71e023148.png

大咖荐书

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 开始,自上而下,大家在思想上保持高度地一致,从整体来提高效率。

0bb16fb3826eb32b80a755269e7d4f1a.png

c1ab0ca55592b3aae4b585041e8cac67.png

74e88fb11624e5067f02b77748b4d84f.png

b327133fd83c07338504e247b8e1d265.png

87392036bebd396b8699b03777b98434.png

c94ecad0c09e1bd6b2d4a6bcf7a98cc7.png

9da0121692e8058a9848b0d85c1af7a8.gif

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值