极客时间已完结课程限时免费阅读

08｜基础团队：研发效能部门，解决不了研发效能问题

08｜基础团队：研发效能部门，解决不了研发效能问题

08｜基础团队：研发效能部门，解决不了研发效能问题

2022-09-28 毕玄 来自北京
《超级访谈：对话毕玄》
课程介绍

讲述：正霖，叶芊

时长25:24大小23.21M

你好，我是叶芊。
　
上一讲我们聊到毕玄从研发转到运维，对于当时成长空间极其严峻的运维团队，他选择兵行险招，解散掉统一的运维团队，把人还给了所有 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. 关于工具的作用，毕玄之前写过一篇小短文：程序员的生产力工具
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 13

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
07｜运维团队：我能干，只是我不想干而已
下一篇
09｜统一调度：只是问题非常多而已，摔出来就行了
unpreview
 写留言

精选留言(14)

  • 法师
    2022-09-29 来自浙江
    阿里云智能编码插件（Alibaba Cloud AI Coding Assistant）是一款AI编程助手 提供代码智能补全和代码示例搜索能力，帮你更快更高效地写出高质量代码。https://developer.aliyun.com/tool/cosy
    16
  • 拭心
    2022-10-09 来自上海
    在工具团队做过，价值难以量化是个大问题。
    4
  • 孜孜
    2022-10-30 来自辽宁
    哈哈哈，主要大部分公司内部工具和业界的相同顶尖的服务差别有点大。肯定开发者会抱怨的。
    1
  • sesamegu
    2022-10-07 来自浙江
    研发效能团队的权责不对等，阿里的研发效率瓶颈主要在协同和沟通上，这个不是这个团队能解决的。另服务化下，阿里测试环境是个痛点，一直没有解决。反观蚂蚁在这个问题上就解决的很好，背后的原因值得探讨
    共 1 条评论
    1
  • Junjie.M
    2023-01-11 来自上海
    在公司整体业务快速上升期，你哪怕什么也不做，外面都会觉得你产生很大价值了；在业务疲软期，你做的再厉害，最终评价都不会太好。
  • alex
    2022-12-03 来自福建
    在几家不大不小的公司，担任技术管理；也在大公司的独立团队干过技术经理；文章中提到的对工具的信任差异，我觉得更像是管理层面的缺失；大家关注结果，比如项目最终是否验收，至于过程混乱也还好，虽然我们都知道过程要有序能更好交付，但实际上还是没那么理想；而工具恰恰是过程管理。爷爷说过一句话：不管黑猫白猫，能抓住老鼠都是好猫。于是，这句话就成了一些人的尚方宝剑。再者，存在幸存者偏差：你看那XXX团队，也就是这么搞的，你看现在都上线发布了。于是。。。 举个例子，jira和禅道，禅道拿过来自己开玩，而jira在配置一个项目的时候，需要提前预设好各种流程；都是项目管理/需求管理工具，但风格啥很大差异；我觉得可能是双方在研发流程管理理解上的差异；国内大部分公司（中小公司，甚至是大公司的某些独立团队）的研发流程管理其实是缺失的，当一个代码写的相对好，或者是效率搞的人，被提升为leader之后，并没有想着怎么提升协作，对于团队作战也有不清楚的时候，就急需一个工具开箱即用，直接用就可以了，禅道可以满足（给个jira可能还搞不清楚啥是啥）。 从我自身的经历来看，中小厂商的研发，或者技术领导者可能着眼点会在：需求的变更、需求的不确定性、研发代码质量；其实国内大厂最近几年一直在持续输出一些思想、方法论、工具，也让中小厂商受益良多，比如好几年前阿里出来的 java代码规范。 研发效能，大厂因为环境复杂，各方耦合很多，协作上的需求很高，工具价值，大量应用的发布、监测、运维，毕竟到了一定规模，就不是堆人解决的了。 中小公司做项目，研发过程的管理，如果依赖于人治（团队小，项目规模小，协作喊喊就能解决），就严重依赖于一名靠谱的技术leader（懂点研发管理流程的）。在早些年，中小公司，一线技术领导由于自身环境的因素，受困与这些知识面的获取。现在其实好了许多，国内各种大会，各类知识网站的兴起，对这方面有了很多的布道。 计算机/软件工程专业的人员出来之后，对于真正工程化的知识要学习到位，感觉我们过于重视技术，对于工程化反而忽略了。打个比方，过于重视怎么开好挖掘机，而忽视了安全生产条例（可能不恰达，就这个意思）；
    展开
  • jjyyun
    2022-11-28 来自浙江
    确实，花时间最多是在编码之前的沟通过程中，一些跨部门的项目更难。
  • Sam_Deep_Thinking
    2022-11-07 来自广东
    讨论研发效能的，目前这篇是我见过，讲的最实在的了。挺好的文章，接地气哈。
  • 刘宇涵
    2022-11-06 来自广东
    怪不得中国工具这么少……各种框架呀，现在的k8s都是外国的
  • 孜孜
    2022-10-30 来自辽宁
    cosy 还是和copilot 还是有点差距的。目前只支持Java。
  • 术子米德
    2022-10-26 来自浙江
    🤔☕️🤔☕️🤔 【R】一个团队，必须有个亮点，才能解读团队存在的必要性。 【.I.】研发效能，很热门的词，很吸引眼球的词，但是在我的经验里，字面意思不足以体现它的魔力，切换到动机层面，反而会有些发现。试问，谁对研发效能在意？公司和组织，它们当然在意。但是，它们更在意的，大概率却是，为啥研发效能无法量化，而不是研发效能本身。当无法量化时的研发效能进入考核时，各种稀奇古怪的招式都会冒出来。然后，结论大概率还是，研发效能这玩意儿无法量化。再试问，对于每个工程师而言，尤其对于每个有家庭的工程师而言，研发效能意味着什么？干活时，能专注在一条主线，不干扰不等待，当然也不因等待而刷手机。提交时，曾经手动完成的事情，逐渐由系统的自动化辅助，非人参与的事情做过三遍以上，就可以融入到提交流水线。问题时，现场信息采集、现场复现，测试查用例遗漏、尝试复现，开发分析潜在原因、启动复现，多条线同时推进。对于某个工程师而言，研发效能就是仅把个人适当的精力，以不费心，以不闹心，以很省心的方式，投入在研发工作方面。这么说来，去问研发人员，如何能让他早点回家，但依然在现有的投入下，持续略有提高，需要哪些方面的改进或辅助，估计能得到更真实的答案。 【.I.】一个团队，需要亮点，具体个人，需要记忆点。在技术行业，遇到什么问题，想来想去原来还有这么号人可以求助，想起他的点，就是每个技术人都要努力，让自己身上具备的记忆点。 【.I.】效能工具，付费，为何难。一方面，我觉得是技术人员的自负，觉着吧人家也是代码编写，为何我自己不写个出来，不都是文本编辑器里敲代码嘛，然后大概率写出个四不像。另一方面，我觉得是成本意识不够，尤其是机会成本概念没有建立起来，如果意识到我花钱，能够省下多少精力、以我的擅长去赚得更多我所需时，立刻就会考虑购买方案。 【Q】上午提需求、下午就上线、晚上不合适再改改、明天就是个略好的版本，然后持续越改越好。这样的开发模式，容易被说业余（备注：我个人很喜欢）。可是在各种评审加入后，就真的更专业，还是更低效。据老师的经验，评审在其中发挥的作用，什么样的团队规模，引入比较合适，什么时候发挥最佳，什么时候会变成瓶颈？ —— by 术子米德@2022.10.26
    展开

    作者回复: 关于评审这个，一方面是引入专业角色的评审，例如安全，数据库等；另一方面是对设计，代码的评审，提升平均水平。 评审的效果呢，主要取决于评审人员或系统的能力，多数公司随着发展，增加的评审环节越来越多主要的原因还是对系统的要求上升了，例如系统的可用性，安全性、合规性等，这个对效率确实一定程度会有影响，但对公司业务来说通常发展到一定阶段后也是必须的，所以也没办法。

  • 骑着🚀看银河
    2022-10-13 来自上海
    有点大炮打蚊子得意思
  • 码小呆
    2022-10-02 来自广东
    https://github.com/alibaba-cloud-toolkit/cosy, 还不错
  • 业余草
    2022-09-29 来自上海
    一个团队需要有一个亮点。“亮点”既是一个结果指标。“亮点”的意义不仅在于取得不平凡的工作结果，更重要在于员工为“亮点”所付出的努力。