learn-tech/专栏/超级访谈：对话毕玄/08基础团队：研发效能部门，解决不了研发效能问题.md

                            
                            因收到Google相关通知，网站将会择期关闭。相关通知内容
                            
                            
                            08 基础团队：研发效能部门，解决不了研发效能问题
                            
你好，我是叶芊。-
　-
上一讲我们聊到毕玄从研发转到运维，对于当时成长空间极其严峻的运维团队，他选择兵行险招，解散掉统一的运维团队，把人还给了所有BU，尝试改变研发乃至集团对运维团队的价值认知，毕竟只要研发觉得自己能干的事，都很难做。-
　-
但是运维之后，他又去了更惨的研发效能团队，给研发和运维做工具。-
　-
对于这个“难度简直高到天”的新团队，这次他要面对的是什么样的难题？他又是如何发挥自己的长板，分析运维未来的成长空间，找到那几个能体现团队价值的亮点呢？


　-
极客时间：好不容易从运维出来，结果你又去研发效能了？那个时候应该是2016年？

毕玄：对，其实就是运维拆完，我开始带系统软件事业部跟研发效能部。

极客时间：新团队多大？

毕玄：一开始大概三四百人，后面有五六百。

极客时间：你当时带这两个部门的目标是什么？

毕玄：当时安排我去带这两个，系统软件是有明确目标的，就是要做好统一调度，因为行癫上任作为CTO给阿里定的两个最重要的事，一个是统一存储，一个就是统一调度，统一存储就是盘古，统一调度就是我。所以系统软件的成立很清晰。

研发效能是因为之前基础设施的运维，在阿里云、集团各有一个团队，现在最大诉求是整合在一起，做成统一化。至于研发工具侧，没有太多诉求，当然我带团队以后肯定不希望没有任何目标，还是希望能解决研发效能团队的定位问题，这就是第二个目标。

极客时间：定位问题？也是像运维团队一样，研发效能当时的价值没有展现出来吗？

毕玄：对，研发效能是做研发工具的，跟运维一样，大家也会觉得这个团队人很多，都觉得一个研发工具团队200多人？简直太多了，没有一个人觉得你手上人少。

我以前带运维在外围的时候也这么觉得：研发工具团队人怎么那么多，应该给我点人来做工具，给一半就挺好。等我带的时候一看，哇这个团队人也太少了。我带的这俩团队简直了（笑）。

极客时间：研发效能人少的原因是什么？

毕玄：因为研发工具链条特别长。

研发工具你想包括了什么？首先就是代码托管、代码编译，然后需求管理，要做整套需求管理的系统，需求出来了以后你要做项目管理，还要对研发模式做管理，像阿里研发模式不统一有无数种，主干开发、分支开发、敏捷开发……各种都得支持。列举一下你最后就发现，团队里做每一项功能的可能只有俩人，然后就活不下去了。

我说这团队太难带了。因为跟运维一样，大家也会觉得你的价值对公司很有限，但事实上你又必须存在，你盘点觉得自己人很少，但公司觉得很多，其他团队也都认为你人很多，那你就很尴尬了。

极客时间：本质上，人多不尴尬，尴尬的是人多，别人还觉得你没价值。

毕玄：对，因为这个团队除了支持以外，确实很难找到新目标。他原来做的工作就是支持，你研发完对我有什么需求？像编译，以前只支持Java，现在你要C，那团队规模就会越来越大，Google的编译团队就上百人了。所以你看我们人很多，但把功能点全部拆开，类比其他公司，我们根本没人，哪有人？

但是如果你，像运维一样，永远被别人定义成一个支持团队就很惨，你的价值永远得不到大家认可。我们就想尝试改变，因为你不做出改变，人永远不够。

极客时间：所以这个问题，你是怎么办的？

毕玄：我当时带研发效能就在想，短期能不能稍微集中力量做出一两个亮点，只要有一两个亮点就足以证明这个团队对公司的整体研发效能是有价值的，这个团队还是有意义的。

后来我们认为对工具层面的研发效率来讲，代码方向是最好的，就谈了一些人开始做代码搜索、代码智能化，其他地方我们很难解。

　



　

极客时间：当时你是怎么分析的，可以详细讲讲吗？

毕玄：核心就是想清楚你到底能真正解决研发的什么效率问题。

第一个最大的问题当然是协作效率。但这其实是个研发模式问题。

阿里因为强制统一成一套系统了，所以这套系统压力非常大，一是阿里太复杂了，各业务的状况不一样，有些是创新业务，有些是成熟业务，有些可能是晚期业务，每个都得来不同的。二你想任何一个团队说我觉得现在研发模式不好，想换一个，那你的系统就得支持吧，因为你挑战不了他。

所以我们当时说：想改变这个局面，只有一种可能——研发模式我们比他们还懂，就是对阿里各种不同阶段的业务，你能定义哪个更合适。但说实话这并不容易。

这么多年了，全世界只有某几位顶尖的天才软件工程大师，偶尔提出一两个开发模式，改变了整个业界的协作模式和研发模式，像Linux提出Git彻底颠覆了以前的CVS、SVN，除非能做这种，那你团队影响力绝对第一流。但这太难了，培养出一个大师的可能性不是很大。

而且研发模式很复杂，因为它其实是个协作问题。像敏捷在中国多少年了，包括Google讲代码仓库应该是一个大仓库提高整体的研发效率，但你看中国有多少公司是一个大仓库，阿里也想做，但也很难，理论上Google讲了有A、B、C、D多少好处，我们也觉得Google讲的很有道理，但关键是工程有个落地问题，你有这个想法，怎么走到那？这就是工程。但协作这个工程挑战非常难，我们觉得几乎不可能。

极客时间：所以第一个问题协作效率，短期是不可能了。

毕玄：想解决好协作效率是个长期的活，我们就不纠结了，囤一两个业界挺有名的理论专家尝试看有没有机会提出像敏捷开发、精益开发的思想去影响研发线，让他们接受。

但说实话，我们没抱太大的希望，公司有这么多种类型的业务，要高度抽象出一个很好的协作模式，太难了。到今天为止我觉得这个局面也很难改变，毕竟这相当于你要比他们研发团队还专家。





　

极客时间：第一个协作效率短期PASS，第二个是什么？

毕玄：第二个对研发来说以前阿里最影响的效率是什么呢？其实是测试。

测试是个大问题，到现在也是，很多公司尤其服务化以后更严重。因为你原来就一个系统，测试还好，不存在互相干扰，服务化以后好了，有几百上千个系统，那完蛋了，一放到测试环境，你都不知道谁影响了你，所以各家公司就搞出了N套方案，来解决互相干扰的问题。

比如阿里以前先搞了一套测试环境，所有人都在上面放新的代码，但慢慢的大家就发现这环境还是不要用了，没法用，全是异常，你查问题可能发现根本不是你代码的问题，都是别人的，但别人不理你，这就没法搞下去了。

所以，我们又搞了一套日常环境，日常环境是比较稳定的，里面只允许放测试过的正常代码，但因为前面的测试环境不受大家认可，所以大家就时不时在日常环境里跑，然后就又尴尬了（笑），所以日常环境也慢慢。

极客时间：变成测试环境了。

毕玄：对，但一旦变成测试环境就又很乱。

后来希望从中间件的层面去解决，我们把这个叫二套环境，比如在这个环境里，你现在是测试，但别人调用的时候不会调用到你，会调用一个稳定版本。但是中间件要解决，很复杂，因为不光有服务调用，还有消息各种各样的问题。最后我觉得也解的不是很好。

所以阿里后来都已经直接到预发环境去测了，预发其实就是线上生产环境，只不过用户访问不到，但我们内部能访问。因为用的是线上，可以确保如果出问题，应该就是我的问题。但是后来预发环境也乱套了（笑）。

反正为了一个环境问题，尝试了不知道多少年，现在应该还有个团队尝试新的，专注怎么解决环境干扰问题。我们跟很多做研发工具的团队说，如果能解好这个，你们的工具一定很好卖，中大厂这都是核心问题，因为测试效率如果很低，意味着最终上线的周期肯定会被拉长。





　

极客时间：前面分析的问题倒是很多，一协作效率开发模式，二测试的干扰问题，但是短期都不好解啊。

毕玄：后来我们就觉得，对研发来讲，我们真正能做的是给他的工具。

你想研发的一天，除了协作这些乱七八糟的事情以外，核心的时间肯定还是花在写代码、编译、打包、测试上，所以我们就在想这4个我们能干啥。测试，前面说了只能看环境问题怎么缓解，解决不大可能。

剩下写代码、编译、打包这三个环节，能不能尽量为你缩短，这就是我们探索的。

编译，我们觉得可以搞一下，像Google Bazel提高编译的速度，我们也投入了一些资源，确实有效果。代码编写方面也是在做的，不管是IDE的改进，还是做代码智能化，重点力量开始投向这些。

其他的，支撑好业务和需求就行，在想不出什么创新的情况下我们也别纠结，就当就是个支持好了。但在这几个地方，我们是有机会做出亮点的。说实话对公司来讲，一个团队，一个这么大的团队，其实有一个亮点就足够了，就可以解读这个团队存在的必要性，最怕的是它一个亮点都没有。

极客时间：判断代码方向是亮点，是因为研发天天用，如果能有效提升的话，作用很大吗？

毕玄：因为代码方向，我们觉得智能化是突破点。

像代码托管就没有突破点，GitHub就是天花板，你最多说我做一个中国的GitHub，等一个机会做备胎；或者你指望Git之后又来了一个新东西，但这需要另外一个天才，Git只是Linus随便玩玩做的东西，这就是天才，你没有。

但代码智能化，即使像阿里的工程师，质量已经是中国中上了，事实上，所有工程师写代码的水平也是有很大差距的，我们希望用工具把代码的平均质量拉高，比如从现在的50分拉到60、70分，对公司来讲就很好了，你说要做到比优秀程序员还好，也不现实。而且这是在阿里，如果做得好，这套工具对外可能会把别人从20直接拉到60，那完全不一样。

这个事，在阿里我们觉得是非常有机会做成的。因为你的代码想智能化，比你自己写得更好，首先你需要有一个优质的代码仓库。

极客时间：代码仓库是需要积累的。

毕玄：阿里绝对具备，因为阿里的大多数代码就是中国中上的优秀工程师写出来的，而且这些代码又是在生产环境运行的，是实际被论证过的。

我们还能捞到这些代码运行的实际数据，就能知道哪些代码其实是更优秀的，比如说这段代码每天被访问了很多次，但消耗的资源很少，而且响应时间很快，那说明写得挺好的。所以我们可以很好地训练AI什么叫优质代码，但这需要一个代码仓库。所以GitHub也在做一个代码智能化的工具Copilot，现在要收费了。

极客时间：GitHub Copilot那个自动补全的？

毕玄：它基于的是大量Public的仓库代码，但这个代码的水平你很难说，当然GitHub有些高水平开源质量不错，但你还是没办法跟有实际生产环境数据论证的比，这是不在一个水平线的。

而且我们觉得阿里还有最后一步，如果实在不行，可以时不时搞全阿里代码Review比赛，选阿里大家公认的几个写代码非常好的人来评审，然后把这些反馈给AI，那这个AI就更加智能了。

所以阿里走通这条路的可能性比多数公司高非常多。当然大公司都有这样的体会，Google、腾讯都一样，因为大家确实是偏中上水准。

极客时间：有多年代码积累，有生产检验，加上AI技术现在也比较成熟，最后实在不行还能加人工评分。

毕玄：对，这如果有机会做好，可以让阿里所有工程师在写代码的时候有自动辅助，你写的时候我就能猜出你下面要写什么，然后给你一段相对优质的代码参考，你只用改一改就可以了。

极客时间：这种工具，研发认可吗？愿意用吗？

毕玄：研发对这些接受度很高，你能帮我写得更快还写得更好，那好的。所以GitHub Copilot要收费了，我在很多程序员群里看到都是愿意付费支持的。而且说实话我觉得他做的也没有那么好，离我们当时想象的那个代码智能化工具还有差距。

很多协作工具像office、飞书等等为什么受欢迎？是因为能提高我协作的效率，对研发也一样，如果有个东西能提高我写代码效率，我愿意付钱的，个人都行，都不需要公司。其实IDE 不就是这样子，以前很多人觉得我用记事本写代码很牛，我们说那是傻，工具能极大提高你的效率，干嘛不用呢？那不是傻吗？所以IDE 每年能收这么多钱，你问工程师IDE 到底有什么好？就是因为它能让我们写代码的效率更高。工具就是这样。

极客时间：所以研发效能部的目标终于很清晰了，短期重点代码智能化做亮点，长期做研发模式、测试环境干扰。当时你们做到什么程度呢？

毕玄：我们就做了一年多，因为一两年之后我就不带这个团队了，但现在这个团队应该还在，阿里前段时间好像对外发了一个代码智能化的开放工具（云效Codeup）。





　

极客时间：亮点仔细分析了，也做了很多工作，你觉得研发效能的团队价值有明显提高吗？

毕玄：还是很难，因为研发效能这个东西很难被衡量。

大家常见的是衡量研发对需求的实现速度。比如一个需求过来原来是一周，你现在变成两天，但这里有个问题，需求的粒度是什么？运维或者产品提一个需求过来，你很难拿什么东西去衡量这个需求的粒度，最后到了研发这边其实就没法衡量。这是个非标。

极客时间：大家没有公认的大概指标吗？

毕玄：没有，我觉得只有一些小点。比如说大家公认Google的编译做得非常好，就Bazel，但这并不代表研发效率。研发效率是个综合话题。

而且像我们投入很多去做代码，你觉得自己做了一个特别牛的、在全球都很领先的工具，但对研发来讲，没用，对于研发侧来讲，他们认为我效率的核心不在这，阿里的研发抱怨最多的、最影响他效率的是什么？是前面的环节。所以这种团队很尴尬。

极客时间：抱怨最多的，是前面的需求搞不清？

毕玄：对，是需求和协作，这环节你说你能帮他啥？研发说我最大的问题是一天能写代码的时间很少，大部分时间在开会。但我说这是管理问题。

你想为什么一家创业公司研发很快？以前淘宝也很快，上午提需求，下午就上线了，为什么？因为以前根本不需要评审，也不需要各种环节，你过来说一下，我立刻就开始写代码。现在怎么可能？现在你一个需求提过来，背后可能涉及十个团队，那这十个团队我得先讨论一下吧，还得排个期吧，开会就已经好几天了，这还做个啥？两周做完一个需求就不错了。

极客时间：所以总的来看研发效能，没做出东西很尴尬，做出了东西还是挺无力的，这怎么办？

毕玄：就看团队定位了，如果对公司来说，能接受这个团队在某些点上能做到全球TOP，不需要我们去论证自己做出来的东西的价值，那这个团队的存在空间就有了。

像美国很多公司都认为工具才是核心，不需要说来论证一下你为什么做了这个工具？你效率提高了多少？他们信仰，只要工具做好了，效率就提高了。我以前拜访Facebook，他们的工具团队很受重视，大家都很向往，觉得他们简直太牛了，因为他觉得我用的都是你们团队做的东西。

但中美在软件这一侧的信仰差别是很大的。美国可能因为人太贵了，所以他们一开始就特别相信工具，中国相对来讲人的成本低一些，所以一开始中国不觉得工具有多重要，我就是堆人。只有等到两种情况：一发现堆人也解决不了问题，二开始感受到堆人的成本，只有到这两个阶段才会觉得那我们得做好工具。

但这个时候他对工具的期望太大了，所以这个工具团队很难做，因为工具并不能真的彻底解决问题，如果能彻底解决，那也太简单。因为很可能这个团队解的是研发效率里最小的那个环节，最大的环节根本是公司层面的问题。

极客时间：美国是很向往工具团队，但中国是你们作为保姆团队该给我支持？

毕玄：而且还都觉得你们做的太烂了。研发就是那句话，只是我没空自己干，否则我一定能比写得你更好，高层，你又很难向他证明为什么工具很重要。

office的故事本来我们觉得可以一直讲，你说office重要吗？Office当然重要，所以你愿意付费，那为什么研发工具你不愿意？office你有论证过吗？你也没有，但你就是相信了。相信真的很重要。

海外对开源到商业也是信仰，他相信你开源做好了，接下来的商业化一定能做好。但在中国这个是要被论证的，但论证很难，它就变成了一个悖论。

中国像ToC不也是这样，最早ToC能吸引大量的免费用户，但你也要论证，你吸引了这么多免费用户为什么最终你能赚钱？其实没有证明，所以淘宝最早被无数人质疑，你每年亏这么多钱，到底能不能盈利？这就必须感谢雅虎。

极客时间：广告模式？

毕玄：对，雅虎成功创造了互联网广告模式，直接把免费流量转移成羊毛出在猪身上，所以后来做ToC的人就不用证明能不能盈利这个事，只要你能做到用户量很高，大家就觉得你一定能赚钱，当然也不一定，就像共享单车，用户量做得很高，最后还是没有盈利。但是他一开始是不用解读的，这就是相信。

这在软件上很明显，国外就相信了，但在中国要面临很大挑战，所以中国各家做工具的团队都过得不是很好。

　



　

极客时间：近几年，业界特别重视提研发效能，这种关注度是不是也是分阶段的？

毕玄：对，大公司肯定会提的，研发效能每年确实是被提的核心话题。

极客时间：去年好像提的更多一点，是因为疫情吗？

毕玄：没有，我觉得都会提。

为什么大厂现在总提研发效能，因为大厂到了后面人效比是下降的，所以只要过了那个点，很多公司都会提，因为他每年都会觉得我业务增长是这样，但你研发人员怎么还在不断增长，他当然觉得有问题，加上研发又比较贵，成本比较高，他就会说你们研发的效能得提高啊。

但关键是研发效率到底怎么提高？大家就指望那个研发效能团队，但其实那个团队根本就承担不了这活，他承担的只是很小的一部分，最大的部分实际是管理问题。

极客时间：或者说因为到了现在这个阶段，其实很多公司都找不到更好的方式去盈利了？

毕玄：研发砍十个人公司搞不好盈利了，阿里砍掉这一轮，可能这个季度的利润都要增加一些，因为研发太贵。

所以要说起来，他们不应该老挑战研发效能，想快的，还不如把产品线砍掉一半，研发效能立刻就提高了，因为无效需求太多了，只要产品经理够多，研发就永远不够，毕竟产品经理只要人在，他就会想需求。

极客时间：既然经过这么久的实践检验，为什么大家还是会对研发效能关注这么高？

毕玄：因为大家还是幻想能有一个解决方案。毕竟一旦解决好了，必须说对公司的帮助无比巨大。

极客时间：那你怎么看，你对这个团队是抱有信心的？

毕玄：对，我认为如果你能做一个工具，让研发很喜欢，其实就可以，至于对公司的价值，就看团队的人自己怎么看。

说实话，我觉得即使团队在代码层面做得多好，可能在研发团队能得到比较好的口碑，但公司也不会觉得你解决了研发效率的问题，因为公司层面只看最后的人员增长，就很复杂。

所以我跟他们讲，研发效率是个综合过程，你不能做的，再怎么叽歪也没用，但我们能做的，那就尽可能做好呗。如果你能做到世界顶流，就算不能在公司被认可，但你在圈子里是会被认可的，就像Google做Bazel的团队，你以后的职业生涯是没有问题的，如果在这家公司身上获取不到，在另外一家公司身上也会获取到。那就别纠结了，关键纠结也没啥用。

　

水友讨论区

今天的对谈到这里就暂时结束了，毕玄担任研发效能部Leader的这段经历，确实让我感受到了为什么很多人会评价他对方向的判断非常好。

我们先简单复习一下。首先，出发点是对公司来讲，一个团队需要有一个亮点，才能解读这个团队存在的必要性。那对研发效能部门来说，他们平时做的事是给研发提供支持、做研发工具，如何找到亮点呢？

毕玄分析核心就是想清楚这个部门到底能解决研发的什么效率问题，一个研发，一天的时间花在协作、写代码、编译、打包、测试上，于是拆解下去有了这么几个方向：协作效率、测试的干扰、代码智能化工具、编译工具等，再针对每一个方向思考可行性和见效周期。

虽然最后非常现实，也没能有效提高团队在集团的地位，但毕竟尝试有了效果，后面可能就是时间问题了。


回顾自己呆过的团队，你觉得有清晰的亮点吗？参考毕玄的分析思路，你认为自己团队短期可以发力的亮点是什么呢？
工具，被公司寄托厚望却又很难被认可价值，你在工具团队做过吗？有遇到什么尴尬又难解的问题吗？


欢迎在留言区分享你的思考和故事。如果有其他感兴趣的话题，记得留言。

下一讲我们会聊一聊毕玄做统一调度的故事，下一讲见。

拓展阅读

1. 如果你对测试环境的难题感兴趣，可以看阿里开发者的这篇：在阿里，我们如何管理测试环境？

2. 关于工具的作用，毕玄之前写过一篇小短文：程序员的生产力工具