引言
几个月前，笔者参加了QETalk x QECon 的一场直播，主题是《研发效能提升的道与术》，还是挺有收获的，想着等有空时写篇同名文章来总结一下，但一转眼就到了现在。
在信息技术日新月异的时代，企业级研发效能的提升已不仅是需求，而是生存和发展的必要条件。面对这一挑战，我们不得不在快速交付和持续改进之间找到平衡点，这正是研发效能提升的道与术。
道的思考
对于研发效能提升来说，道关注内在规律、理念和核心价值观，是其本质的内容。
如何取舍交付与改进
很多团队一直忙于项目的交付，很难抽出时间和精力来做改进，尽管团队也知道改进很重要，但总想着等交付轻松一些了再做。然而，随着时间的推移，交付并没有变得轻松，反而越来越笨重：架构越来越腐化，故障越来越多，维护成本越来越大，功效比越来越低，等等。团队好像进入到了一个恶性循环，每个成员都不堪重负，于是有了“大型重构”的想法。
这好比一个人，年轻的时候对事业比较拼，明知道身体很重要，但没有太多的时间锻炼身体。当身体出现一些发症状以后，以为是小问题，就先吃药缓解，还是比较拼。随着时间的推移，症状变得越来越重，总有一天不堪重负，于是有了“动大手术”的想法。
是长期仅保交付，还是交付与改进并举？小到一个团队，大到一个企业，是宏观层面的战略选择，是价值观的体现。交付当然重要，但改进也不容忽视。作为一个企业，需要成立相关的组织，建立对应的流程和机制，以确保项目交付的可持续发展。
如何取舍交付与改进，就好像在风中走钢丝一样，需要根据风向和风速的变化来调整身体的倾斜度，以便时时刻刻的保持平衡，一步一步的接近成功的彼岸。
提升的路径是什么
研发效能提升的路径是自上而下，还是自下而上？就是说，研发效能的推进是从上层领导组织开始往下推，还是从下面的基层团队往上推？
首先，研发效能提升的主要路径是自上而下，这需要组织层面的规划和资源投入：
- 对于企业来说，每到年底的时候都会输出总结规划，各级组织都设定了改进性专题，其中大多数是以上统下的。比如今年火爆天际的LLM提效专题，从企业到部门层层推进，各级组织的专题负责人都由重要角色兼任，并有一定的资源支撑，先通过评优孵化出了很多最佳实践，然后在度量看板驱动下快速横推这些最佳实践。
- 很多同学可能看过或听说过《高效能团队模式》这本书，书中在基本团队拓扑中提出了赋能团队模式。高效能团队支持软件快速高质量交付，但负责交付的业务团队总是工作在交付压力之下，需要快速交付和响应变化，哪有时间去调研、探索、学习和实践新技能呢？赋能团队由特定技术领域或产品领域的专家组成，可以由他们来提供帮助。赋能团队进行调研工作，尝试不同方案，并在工具、实践、框架和技术栈等方面给出高质量建议。赋能团队模式在企业内获得了组织层面的认可，很多部门都在尝试相关的实践。比如我们部门这一年也尝试了赋能团队的建设，包括赋能团队成员的选拔和激励、业务团队赋能课题的收集和排期、赋能团队固定时间的集体学习、周期性封闭2周的GoSee投入，取得了一定的成果，为多个业务团队解决了交付痛点，受到了组织的充分认可。
其次，研发效能提升的次要路径是自下而上，很多企业都有从基层团队触发改进的文化传统：
- Google允许工程师拿出20%的时间来研究自己喜欢的项目，也就是相当于每周有一天的时间，这些“Googlers”可以做自己感兴趣的事情。Gmail、 Adsense、语音服务Google Now、谷歌新闻和谷歌地图等都是20%时间的产物。
- 代码打靶是一项提升代码评审能力的重要实践，但这项实践要落地的话需要工具的支撑，否则消耗太大，导致很多项目不愿意投入。看到该工具的价值后，笔者在公司内发起了打靶服务（CodeShooting）的共创共建项目，吸引一些技术爱好者在业余时间参与工具的孵化及演进。经过两年的努力，CodeShooting助力代码打靶实践在公司内规模化落地，提升了公司开发人员的代码评审能力，获得了员工的一致认可。除过应用于能力提升外，我们还将代码打靶实践通过CodeShooting应用于日常评审流程，并基于评审数据进行用户画像，接着根据弱项推荐专项靶子进行提升。我们打造代码评审的闭环改进循环，并在LLM加持下，工程化落地AI建靶和AI打靶，让这个改进循环更加快速和高质量。
可见，企业研发效能提升的主要路径是自上而下，但自下而上也是重要的组成部分，这与企业的文化传统强相关，并且自下而上的路径在产生规模性的效果后也有可能会升级为自上而下。
提升的难题是什么
对于规模化组织效能提升，最突出的难题是团队之间的水平参差不齐，无法采用一刀切的方式进行规划。我们需要先找到主要矛盾及其主要方面，建立一个基本的共识和底线。度量指标支持不同团队根据具体情况可进行适度裁剪，并可以驱动团队达成改进目标。比如单元测试覆盖率，可能80%以上就可以了，要求过高就会导致ROI太低，要防止一些团队仅片面的追求单元测试的超高覆盖率，而测试有效性却很差，同时测试的维护成本也很高。
另外，可持续性也是一个挑战。资源总是有限的，企业在一项改进上投入的资源不会一直很多，我们要考虑将改进内嵌到研发流程，并通过项目化运作和工具支撑来实施，建立反馈闭环，持续改进。比如代码打靶，我们已经将故障转靶内嵌到研发流程，提升一次性将事情做对的能力，同时团队以打靶的方式进行日常代码评审，提升了代码评审的质量和效率。
术的思考
对于研发效能提升来说，术关注方法和技术，是其具体的行为和方式。
如何衡量做的好与不好
对于研发效能提升，首先要了解现状、梳理问题和痛点，并明确目标和可达路径，任务分解有助于更精细化的掌控可达路径。我们可以设计一套合理且全面的度量指标，实时反馈我们是否朝着目标前进、我们的进度是否符合预期和我们还有哪些改进点等。
度量指标设计应遵守七个原则：
- 结果指标 over 过程指标 ：通过结果指标评估效能水平，根据过程指标指导改进；
- 全局指标 over 局部指标：避免过度的局部优化；
- 定量指标 over 定性指标：尽量使用定量指标，但也不排除部分综合评价的定性指标；
- 团队指标 over 个人指标：个人指标仅用于个人的持续改进；
- 指导性 -> 可牵引行动：适当设定缺陷类指标可以促进质量内建能力建设
- 全面性 -> 可互相制约：常见的可互相制约的指标包括需求交付周期与线上缺陷数量、需求吞吐率与需求规模、研发周期与技术债务等；
- 动态性 -> 按阶段调整：随着团队能力提升，指标也需要随之进行适当调整，从而促进团队的持续改进。
如何规划与演进工具
在企业内部，团队都会开发一些工具用于研发效能提升，但很多工具在完成从0到1的过程后就停滞不前，导致工具不仅易用性差，并且其他团队难以复用，于是同质化的工具会被不同的团队开发出来，这显然是一种资源浪费。可以成立企业级工具委员会，以上统下，将企业的主航道工具管理起来，统一规划和演进，明确守护方和共创方，并对组织进行考核和激励。不仅避免了重复建设，而且使工具的规划与演进更合理。
除过主航道工具，还有与业务强相关的工具。对于这类工具的规划与演进，各业务单位都比较积极主动，因此可能出现工具过多的问题，即在研发价值流各阶段需要将所有工具协作起来才能完成交付，但在协作过程中工具的切换有一定的成本，并且工具间的数据交换也很难打通。可以打造企业级一站式研发平台WebIDE，使用IDE插件将各个工具串联起来，各业务单位能灵活编排和裁剪研发流程，并且能用私有工具覆盖默认工具。不仅降低了工具的切换成本，而且让数据交换形成为自然而然的管道。
ChatGPT带来的影响是什么
这一年，以ChatGPT为代表的AI大模型对软件研发行业影响非常大。
在代码生成方面，ChatGPT的应用已比较成熟，可以生成可读性高且效果好的代码。但在需求、设计、测试和运维方面，ChatGPT的理解还有限，暂时不能满足用户诉求。尽管ChatGPT在这些领域的发展速度很快，但目前的效果还不尽人意。
ChatGPT的发展速度之快令人惊叹，OpenAI刚发布2000亿参数的GTP3.5没几个月，就又发布了100万亿参数的GTP4，现在功能更强大的GTP5已箭在弦上，估计这几个月发布。很多开发人员对ChatGPT的发展除过感到惊叹外，也倍感焦虑，他们担心自己的工作会被取代。虽然ChatGPT在演进和迭代中变得越来越强大，但它的发展仍然是渐进的，在软件研发各个价值流阶段的落地都会遇到诸多挑战，无法完全取代人类。只要保持开放的态度，拥抱新技术，不断更新领域知识和AI的使用方法，我们就能跟上时代的步伐，失业的风险就不会那么高，因为AI不会取代开发人员，但会使用AI的开发人员会取代不会使用AI的开发人员。我们需要学会如何与AI高效协同，将其作为辅助工具提高工作效率，逐步从繁重低价值的重复性工作中解放出来，投入更多的时间和精力到高价值的工作中去。
未来的软件架构可能与现有的软件架构有很大不同，提示工程变得越来越重要，不再需要大量人力编写代码，甚至不需要普通的开发人员理解编程语言（类比现有的汇编语言）。这也许意味着我们需要重新评估和调整研发流程，以适应新的软件架构模式。因此，我们需要同时关注基于现有软件架构的研发效能提升和基于未来软件架构的新一代研发流程的讨论。
小结
企业研发效能提升的目标是可持续快速低成本交付价值，我们需要将道与术层面的核心问题考虑清楚，并在实践中将两者融为一体，确保企业在变革的浪潮中立于不败之地，与个人共同赢得辉煌未来。
