超级访谈：对话毕玄_14_08基础团队研发效能部门解决不了研发效能问题
你好，我是叶先。
上一讲呢，我们聊到碧璇从研发转到运维的经理，对于当时成长空间极其严峻的团队啊，他选择兵行险招，解散掉了统一的运维，然后把人还给了所有BU,尝试去改变研发乃至集团对运维团队的价值认知。
毕竟只要研发觉得自己能干的事都很难做。
但是运维之后呢，他又去了更惨的研发效能团队，要给研发和运维做工具。
对于这个难度简直高到天的新团队。
这一次他要面对的是什么样的新难题呢？他又是如何发挥自己的长板，分析运维未来的成长空间，找到那几个能够体现团队价值的亮点的呢？我们开始今天的对谈，所以你是好不容易从运维出来的，然后结果你又去研发效能了。
那个时候应该是一六年。
嗯，对，其实就是运维拆完，然后就开始去带系统软件事业部跟研发效能部。
嗯，那个时候你的新团队大概是多大？一开始的话，大概三四百人啊，后面有五六百了。
那你当时去带这两个部门的目标是什么？当时安排我去带这两个系统软件是有明确目标的，就是要做好统一调度。
嗯，因为刑天上任作为CTO啊，给阿里定的两个最重要的事儿啊，一个是统一存储，一个是统一调度。
那统一存储呢就是盘古统一调度，就是我嗯啊所以这个系统软件的成立很清晰。
研发效能是因为之前基础设施的运维在阿里云集团各有一个团队啊，现在最大的诉求是整合在一起，做统一化。
那至于这个研发工具侧没有太多的诉求。
当然我带团队以后肯定是嗯不希望没有任何目标啊，还是希望能够解决研发效能的团队的定位的问题，这就是我的第二个目标了。
嗯，呃这个定位问题也是就是类似当时运维团队当时的那个价值没有展现出来嘛。
对研发效能也是做研发工具的，跟运维一样。
嗯，啊大家也会觉得啊这个团队人很多都觉得一个研发工具团队两百多人简直太多了。
没有一个人觉得你手上的人少，那我以前在带运维，在外围的时候也是这么觉得的。
哎呦，这个研发工具团队，人怎么这么多，因为给我点人来做工具，给一半人就挺好。
那等我带的时候一看，哇，这个人这个团队人也太少了，我带的这两个团队简直了啊啊。
研发效能他人少的点是什么？因为研发工具链条特别差啊，研发工具你想包括什么哈？首先是代码托管代码编译，然后是需求管理，要做整套需求管理的系统啊，需求出来之后，你要做项目管理啊，还要对研发模式做管理。
那像阿里啊研发模式不同，一那有无数种这个研干开发呀、敏捷开发呀、敏捷开发呀，各么都支支持。
那研研一下，你每最后发现哎，有团队里做每一项功能的，可能就只有俩人，然后就活不下去了啊。
我说这团队太难带了，因为跟运维一样，大家也会觉得你的价值对公司有限。
但事实上呢，你又必须存在，你你盘点觉得呃自己人很少，但公司觉得很多其他团队也都认为你人很多，那你就很尴尬。
嗯，其实本质上其实是人多人少，不是尴尬的点，尴尬的是人多，别人还觉得你没价值。
对，就是因为这个团队除了支持以外，确实是很难找到新目标。
他原来做的工作就支持。
那研发完对我有什么需求？像编译以前只支持java,现在你要c那团队的规模就会越来越大。
那google的编译团队就上百人了。
所以你看我们人很多，但把这个功能点全部拆开啊，类比其他的公司，我们根本就没有人哪有人就是但是如果你啊像运维一样，永远被别人定义成一个支持，团队就很惨，你的价值永远得不到大家认可。
所以我们就想尝试改变嘛。
因为如果你不做出改变，人就永远不够。
所以你当时想怎么办了？后时代研发效能的时候，就在想这个短期就能不能稍微集中出力量，要做出一两个亮点。
只要有一两个亮点，就足以证明这个团队对公司的整体研发效能是有价值的，这个团队还是有意义的。
嗯，啊后来我们认为对工具层面的研发效率来讲，代码方向是最好的。
嗯，然后就谈了一些人看做代码搜索呀、代码智能化呀，啊其他地方我们很难解。
那当时你是怎么分析的？可以具体说一下吗？嗯，核心就是想清楚你到底真正解决研发的什么效率问题。
那第一个最大问题肯定是写作效率嗯，啊这个但这其实是一个研发模式的问题。
阿里因为强制统一成一套系统了，所以这套系统压力非常大。
你看啊就是一是阿里太复杂了，各个业务的状况不一样啊，有些是创新业务，有些是成熟业务，有些呢可能是晚期业务啊，每个都得来不同的。
嗯，二呢你想呃任何一个团队说，我觉得现在的研发模式不好，想换一个，那你的系统就得支持吧，对吧？因为你挑战不了它，所以我们当时说的想改变这个局面。
只有一种可能就是研发模式，我们比他们还懂啊，就是对阿里各种不同阶段的业务，你能定义哪个最合适。
嗯，但是你去定义这种是不是也挺难的，很不容易啊。
就是因为这么多年了，那全世界只有某几位顶尖的天才。
软件工程大师，偶尔提出一两个开发模式去改变整个业界的协作模式和研发模式嘛。
嗯像linux提出gate对吧？彻底是颠覆了以前的CVSFSVN.嗯，那除非能做这种，那你团队的这个影响力绝对一流。
嗯，那是这太难了，培养出一个大师的可能性不是很大。
嗯，对，而且研发模式很复杂，因为他其实是一个协作模题，像敏捷在中国多少年了。
包括呃google讲代码仓库应该是一个大的仓库去提高整体的研发效率。
但是你看中国有多少公司是一个大仓库呢？阿里也想做，但是也很难。
因为理论上呢google讲的有ABCD多少好处啊，我们也觉得哦google讲的很有道理。
嗯，但关键是工程有个落地的问题，你有这个想法怎么走到那儿啊，这就是工程。
但协助这个工程挑战非常难，我们觉得几乎不可能。
嗯，所以第一个问题协作效率短期是不可能的。
想要解决这个协作效率啊是一个长期的活，我们就不纠结了。
嗯，啊囤移两个这个业界挺有名的理论专家去尝试看看有没有机会提出像敏捷发发精开发的这个思想，去影响研发线，让他们接受。
但说实话，我们没有抱抱，这个太大希望，就公司有这么多类型的业务，要去高度去抽象出一个很好的协作模式。
太难了，就到今天为止啊，我觉得这个局面也很难改变，毕竟这相当于是你要比他们研发团队还专家毕是第一个协作效率，这一点短期就pass掉了。
那第二个是什么？第二个对于这个研发来说哈，毕竟慢一最影响效率的什么什么就其实是测试啊，测试是个大问题，到现在也是很多公司，尤其服务化以后更加严重。
因为你原来就一个系统测试还好啊，不存在相互的这个干扰啊。
服务化之后以后好了，哎，有几百个上千个系统，那完蛋了，一放到测试环境你都不知道谁影响了你。
所以说各家就搞出了这个n套的方案，来解决这个互相干扰的问题。
比如说阿里以前是先搞了一套测试的环境啊，很多人在上面放新的代码。
但是慢慢的大家就发现，哎，这环境还是不要用了，没法用啊，全是异常。
你查问题的时候呢，可能发现根本就不是你的代码的问题，都是别人的，但是别人不理你啊，这就没办法搞下去了。
所以我们又搞了一套这个日常环境啊，日常环境是比较稳定的，里面只允许放呃测试过的正常代码。
但是前面的测试环境不受大定的认可，所以大家就时不时的在日常环境里面跑，然后又尴尬了嘛。
就是日常环境也就慢慢的对，就慢慢变成测试环境了。
对，但是一旦又变成了这个测试环境又很乱。
嗯，后来呢希望从这个中间件的这个层面去解决，我们把这个叫二套环境。
比如说在这个环境里，你现在是测试，但是别人调用的时候不会调用到，你会调用一个稳定的解本。
但是中间件要解决很复杂，因为不光有服务调用，还有消息各种各样的问题。
所以呃最后我觉得也解的不是很好。
嗯，所以阿里后来都是已经直接到预发环境去测预预发是指线上环境吗？就是线上生产环境，只不过用户访问不到。
但是我们内部能访问，因为用的是线上可以确保，如果出问题应该就是我的问题。
但是后来预发环境也乱套了。
嗯，因为反正是呃为了一个环境问题，尝试了不知道多少年。
但是应该还有个团队尝试新的就专注，怎么去解决环境的干扰问题。
我们跟很多这个做研发工具的团队说啊，就是如果能解好这个你们工具啊一定很好卖。
中大厂都是这个问题。
因为测试的效率如果很低，那就意味着最终上线的周期肯定会被拉长。
所以我们简单说一下，就是前面总结的问题倒是很多。
第一个是协作效率，就是开发模式的问题。
第二个是测试的干扰问题，但是短期都不是很好解。
对，我们后来就觉得呢就是对研发来讲，我们真正能做的是给他的工具啊，你想研发的一天，除了协作这些乱七八糟事情之外，核心的时间啊肯定还是花在写代码编译打包测试上。
嗯，所以我们就在想，这四个我们能干啥啊？测试那前面说了只看环境问题，怎么能缓解解决问题？不太可能啊，剩下就是写代码、编译打包啊，这三个环节能不能尽量为你缩短啊，这就是我们探索的编译呢。
我们觉得可以搞一下像google battle,那提高编译的这个速度，那我们也投入了一些资源，确实是有效果。
那代码的编写方面也是在做的。
不管是这个ID的改进啊，还是做这个代码的智能化啊，重点的力量开始投向这些。
其他的呢就是支撑好这个业务和需求就行了。
再想不出有什么创新的情况下，我们也别纠结，就当是个支持好了，那但但是在这几个地方，我们还是有机会做出亮点了，然后这几个亮点就就够了吗？对，那说实话就是对公司来讲，一个团队啊，一个这么大的一个团队，其实有一个亮点就够了，就可以解读这个团队存在的必要性。
最怕的就是它一个亮点都没有啊。
那像代码这个亮点啊，是因为呃研发天天用，如果能够去有效提升的话，作用很大。
因为代码方向啊，我们觉得就智能化是突破点，像代码托管就没有突破点啊，github就是天花板啊。
我你说我最多去做一个中国的github,那等一个机会做备胎。
又或者说你指望git之后又来了一个新东西啊，但是这需要另外一个天才，那git只是linux随便玩玩做的东西啊，这就是天才，你没有。
但是代码智能化啊，其实像阿里的工程师质量已经是中国中上了。
那事实上呢，所有工程师写代码的水平也是有很大的差距的。
我们希望呢是用工具把代码的平均质量给拉高。
比如说从现在的五十分拉到一个六十七十分，那对公司来讲就很好了。
嗯，你要说做到比优秀的程序员还好，也不现实。
而且这是在阿里如果做的好呢，这套工具啊对外可能会把别人从二十直接是拉到六十啊，那就完全不一样了。
嗯，啊这个事儿呢在阿里我们觉得是非常有机会能够做成的。
因为呃你的代码想智能化啊比你自己写的更好。
首先呢你需要有一个优质的这个代码仓库，嗯，然后这个是需要积累的，阿里是绝对具备的。
因为阿里的绝大数多数的代码都是中国的中上的优秀工程师写出来的。
嗯，而且这些代码呢又是在这个生产环境运行的，是被实际论证过的。
啊，那我们还能捞到这些代码运行的这个实际数据嘛，就能够知道哪些代码其实是更优秀的。
比如说这段代码每天被访问了很多次，但是消耗的资源很少，而且响应的时间很快，那说明写的挺好的。
所以我们可以很好的去训练AI什么叫做代质代码。
但是其实是需要一个代码仓库，所以github呢也在做一个代码智能化的工具和pilot.那现在要收费了。
嗯嗯，github那个pilot是就是做自动补全的那个它基于的是大量的public的仓库代码，那这个代码的水平你很难说。
当然github有些高水平的开源质量不错，但是你还是没有办法跟有实际生产环境数据去论证的比啊，这是不在一个水平线的。
而且我们觉得阿里还有最后一步，就是如果实在不行，那可以时不时的搞这个选阿里的代码review比赛。
那选阿里大家公认的几个写代码，非常好的人来评审，然后把这些反馈给AI啊，那这个AI就更加的智能。
嗯，对，那所以说阿里走通这条路的可能性啊，要比多数公司要高非常多。
嗯，那当然大公司都有这样的体会啊，google、腾讯都一样，因为大家确实是偏中上水准，嗯，就是说有多年的代码积累，然后又有生产的检验，加上现在AI技术也比较成熟嘛，如果最后实在不行，还能够加人工去做评分。
对，这个呢如果有机会做好，可以让这个阿里所有的工程师在写代码的时候有自动的辅助。
嗯，那你写的时候呢，我就能够猜出你下面要写什么，然后给你一段相对优质的代码参考，那你只要去改一改就可以了。
那像这个工具如果真正做出来了，研发也是比较愿意用的吗？哦，研发对于这些接受度很高啊，你能帮我写的更快，还能够写的更好。
那好啊，所以说githhop ical pilot t要收费了嘛。
那我看很多程序员群里看到都是愿意去这个付费知识的，而且说实话我觉得他做的也没有那么好。
那离我们当时想象的那个代码，智能化的工具还是有差距的。
很多协作的工具，像office、飞书啊等等这些为什么受欢迎？是因为能够提高我的协作的效率，那对研发也是一样的。
那如果有个东西能够提高我写代码的效率，我愿意付钱啊，个人都行，都不需要公司。
其实IDE不就是这样子嘛，就是以前很多人觉得啊我用记事本写代码很牛，我们说那是傻，对吧？工具能够极大的提升你的效率，干嘛不用呢？那不就傻吗？所以说IDE每年能收这么多钱，那你问工程师IDE到底有什么好，那就是因为它能够让我们写代码的效率更牛工具就是这样子。
所以研发效能部的目标终于比较清晰了。
短期就是去重点做啊代码智能化，然后作为一个团队亮点，然后长期呢可能就是去探索一下像研发模式啊，然后测试环境的干扰啊这些。
嗯，那当时你们有做到什么程度吗？嗯，我们就做了一年多，因为一两年后我就不带这个团队了。
但现在这个团队应该还在阿里，前段时间好像对外发了一个代码智能化的开放工具。
嗯，那你们当时做了这么多，你觉得就是研发效能这个团队价值有明显提高吗？还是很难？因为研发效能这个东西很难被衡量。
那大家最常见的对就是衡量研发对需求的实现速度嘛，对吧？比如说一个需求过来，原来是一周啊，你现在变成两天。
嗯，但这里有个问题，就是需求的力度是什么？那运维或者说产品提一个需求过来，你很难拿什么东西去衡量这个需求的力度。
那最后到了研发这边就是其实就没法衡量，那这是一个非标。
嗯，那大家没有一些公认大概的指标吗？没有我觉得只有一些小点。
比如说大家公认的这个google的编译做的非常好，就battle.那但这并不代表研发效率啊，研发的效率是一个综合的话题。
而且像我们投入了很多去做代码啊，你觉得自己做了一个特别牛的，在全球都很领先的工具。
但是呢对研发来讲没用。
对于研发侧来说，他们认为啊我效率的核心不在这儿。
阿里的研发抱怨最多的最影响它效率的是什么呢？是前面的环节。
所以呢我们这种团队很尴尬，嗯，就是说前面那个需求搞不清楚对，是需求和协作。
那这这种环节你说你能帮他啥嗯，对吧？对研发说我最大的问题就是一天写代码时间很少，大部分时间都在开会。
嗯，那我说说这涉个管理问题，你想为什么一家创业公司研发很快呢？以前淘宝也很快，上午提需求下午就上线了。
为什么？因为以前根本就不需要评审，也不需要各种环节。
那你过来说一下，我立刻就开始写代码。
现在怎么可能？现在呢就是你一个需求提过来啊，背后可能涉及十个团队。
那这十个团队我得先讨论一下吧，还得排个期吧，那开会就已经好几天了啊，这还做个啥呀，就两周做完一个需求就不错了。
所以现在的问题是没有做出东西很尴尬，但是做出的东西感觉你们好像还是挺无力的那这怎么办？这就要看这个团队的定位了。
如果说对公司来说，能够接受这个团队在某些点上能够做到全球top,不需要我们去论证这个自己做出来东西的价值。
那这个团队存在的空间就有了。
嗯，啊像美国很多的公司都认为啊工具才是核心，不需要说来论证一下，你为什么做了这些工具，你效率提高多少。
那他们信仰只要说工具做好了，效率就提高了。
那我以前拜访facebook,那他们的工具团队啊就很受重视，大家都很向往啊，觉得他们简直太牛了。
因为他觉得我用的都是你们团队做的东西，但中美在软件这一侧的这个信仰差别是很大的。
美国可能因为人太贵了，所以他们一开始就特别相信工具啊，中国相对来说来讲，就是人的成本就低一些嘛。
所以说一开始中国不觉得工具有多重要，就是大家一一般都是堆人。
对啊，只有等到两种情况，就是一发现这个堆人也解决不了问题。
二是感觉到这个堆人的成本啊，嗯只有这两个阶段才会觉得哦，那我们得做好工具。
但是这个时候呢，他对工具的期望就太大了。
所以这个工具团队很难做。
因为工具并不能说是真的是彻底解决问题，如果能彻底解决，那也太简单了。
所以很可能是这个团队解的是研发效率里最小的那个环节嗯，最大的环节根本上还是公司层面的问题。
嗯，就美国是比如说大家很向往工具团队，但是中国是你们作为保姆团队该给我支持。
而且还觉得哎你们做的太烂了。
研发就是那句话，就是只要是我自己没空干啊，否则呢我一定是写的比你更好。
嗯，高层呢你又很难向他证明为什么工具很重要。
Office的故事，本来我们觉得可以一直讲，你说office重要吗？嗯，肯定很重要啊，office当然重要是吧？那所以你愿意付费，那为什么研发工具你就不愿意呢？对吧？ Office,你论证过吗？你也没有啊，你就是相信了吗？就相信真的很重要。
海外对于这个开源到商业也是信仰，他相信你开源做好了，接下来的商业化一定能做好。
但是在中国这个是要被论证的，但论证很难，它就变成了一个悖论。
嗯，中国像to c不也是这样吗？就是最早的这个to c能够吸引大量的免费用户。
但你要去论证你吸引这么多的免费用户，为什么你最终能够赚钱？其实没有证明。
所以说淘宝最早是被无数的人去质疑，你每年亏这么多钱到底能不能盈利啊，这就必须要感谢雅虎，就是那个广告模式。
对，雅虎是创造了这个互联网的广告模式，嗯，直接是把免费的流量转移成羊毛出在猪身上。
所以说后来做to c的人就不用证明能不能盈利这个事儿只要你能够做到用户量很高，大家就觉得你一定能赚钱。
当然啊也不一定，那就像共享单车用户量是做的很高，但是最后还是没有盈利。
但是他一开始是不用解读的这就是相信啊，这在软件上很明显，就国外是又相信了。
但是在中国是要面临很大的挑战。
所以中国各家做工具的团队都过得不是很好像现在大家看各个厂好像都比较重视，去提研发效能。
这个事情大家这么重视去提是不是也是分阶段的对大公司是肯定会提的研发效能。
每年确实是被提的核心话题，嗯，像去年好像提的更多一点，是因为疫情原因吗？嗯，没有没有我觉得是都会提。
嗯，为什么大厂现在是总提研发效能，因为大厂到了后面的人效比是下降的，所以只要过了那个点，很多公司都会提。
因为他每年都会觉得我的业务的增长是这样，但是你的研发人员怎么还在不断增长啊，那他当然觉得有问题，加上这个研发还比较贵，成本比较高啊。
他就会说呃你们研发的效能得提高呀。
但关键是研发的效率到底怎么提高，那大家就都指望那个研发效能团队，但其实那个团队根本就承担不了。
这活他承担的只是很小的一部分，最大的部分其实是管理问题。
或者说到了这个阶段，其实很多公司是不是都找不到更好的方式去盈利了。
研发砍十个人啊，公司搞不好就盈利了。
那阿里砍掉这一轮，可能这个季度的利润都要增加一些。
因为研发太贵，所以要说起来他们不应该老去挑战这个研发效能啊啊，想快的还不如直接是给产品线就砍掉一半，研发效能立刻就能提高了。
嗯嗯，因为无效的需求太多了啊，只要产品经理够多啊，研发就永远不够。
毕竟产品经理只要人在，他就会想需求。
那既然经过这么久的实践检验，为什么大家还是会就是去去一直说这个话题？因为大家还是幻想能够有一个解决方案，毕竟一旦是解决好了，必须说对公司的这个帮助啊是无比巨大的。
嗯，那你怎么看呢？你是对这个团队有信心的。
对我觉得就是如果你能做一个工具，让研发很喜欢，其实就可以。
至于对公司的价值呢，就看团队的人怎么看了。
嗯，说实话啊，我觉得即使团队在代码层面做的多好，可能在研发团队能看到比较好的口碑。
但是公司也不会觉得你就解决了研发效率的问题。
因为公司层面只看最后的人员增长就很复杂。
所以我就跟他们讲嘛，说研发效率是一个综合的过程，你不能做的，再怎么机歪也没有用啊，但是我们能做的那就尽量做好呗。
啊，如果你能够做到世界顶流，就算不能在公司被认可，但是你在圈子里是会被认可的，就像google做的battle团队，对吧？那你以后的职业生涯是没有问题的那如果在这家公司嗯获取不到，那就在另外一家公司也会获取到，那就说就不用纠结了，关键纠结没啥复杂。
今天的对谈呢到这里就暂时结束了，即选担任研发万能不利德的这段经历啊，确实是让我感受到了为什么很多人会评价他对方向的判断非常好。
我们先简单复习一下。
首先出发点是对公司来讲，一个团队需要有一个亮点，才能够解读这个团队存在的必要性。
那对研发效能这个部门来说呢，他们平时做的事情是给研发提供支持，做研发工具，他怎么找到亮点呢？力玄分析呢核心就是要想清楚这个部门到底能够去解决研发什么效率问题。
一个研发一天的时间，花在写作、写代码、编译、打包测试上。
那么我们继续拆解下去就有这么几个方向。
第一个是协作效率，然后是测试的干扰代码、智能化工具、编译工具等等。
然后我们再针对每一个方向去思考可行性和见效周期。
虽然最后非常现实啊，也没有能够有效提高团队在集团的价值。
虽然毕竟尝试有了效果，后面可能就是时间的事情了。
那回顾你自己代购的团队啊，你觉得有清晰的亮点吗？参考碧璇的分析思路呢，你觉得自己的团队短期能够发力的亮点是什么呢？工具团队呢一般是能够被公司寄予厚望，但是却又很难被认可价值。
那么你在工具团队做过吗？有遇到什么比较尴尬又很难解的问题呢？欢迎在留言区分享你的思考和故事。
如果有其他感兴趣的话题呢，也记得留言下一讲，我们会聊一聊碧璇做统一调度的故事。
下一讲见拜拜。