最近两年软件研发效能很热，这也促使我去年发起了 全球软件质量&效能大会（QECon） 但凡某件事太热，就很容易走火入魔，更多人被带入误区 ，有点像当初Agile、DevOps一样，把所有好东西都往自己篮中 装 ，想包罗万象、想一网打尽 …… 其实，许多优秀的实践早已存在，不管 Agile / DevOps 在与不在。当初IBM RUP也想一统天下，如今安在？
整整20年过去了，多少Scrum敏捷教练前赴后继，但Scrum敏捷开发模式在国内实施的效果如何？其实，效果一般。根据 去年 和 今年 的调查数据，至今天真正实施Scrum敏捷开发模式的组织只有28%左右，这其中估计还有一些是伪敏捷。
在软件研发效能没走火入魔之前，我觉得有必要和大家谈一谈 软件研发效能的底层逻辑 ，拨开云雾，看清软件研发效能的本质，澄清软件研发效能的是是非非，有利于提升软件研发效能，有利于软件研发团队做好明年或未来的研发计划。
之前写了 软件测试的底层逻辑 和 软件质量管理的底层逻辑 ， 今天所写的 软件研发效能的底层逻辑 ，就作为底层逻辑三部曲的最后一篇，算是2021年的收官之作，可能会比较犀利些，不妥之言，望多多包涵。欢迎留言参与讨论。
1. 究竟什么是研发效能？
维基百科给效能（efficacy）的定义是：事物产生功效的能力，常用于通识教育、医学和药理学，可以忽略。然后 看百度百科的定义，基本靠谱： 效能是指有效的、集体的效应 ，即人们在有目的、有组织的活动中所表现出来的 效率和效果 ，它 反映了所开展活动目标选择的正确性及其实现的程度 。
普华永道给出“ 组织效能关注组织效率、竞争力和员工贡献度 ”，谷歌（Google）的GSM（Goals-Signals-Metrics）框架，关注 目标的达成 ，并转化为 研发效能五个核心元素：代码质量、工程师注意力、智力复杂性、速度与速率、满意度。
其实在我之前写的 一篇文章 已讨论过，但还是要在这里澄清一下，这也是我们后面讨论的基础。概念不同，相互争辩就没有意义。 研发效能（R&D Effectiveness ）是指研发团队 对业务有实际价值的 产出 ，如果需要加上限制，可以说 效能 是 单位时间内 研发团队对业务有实际价值的 人均产出， 而 效率 关注速度、生产力，而缺乏关注目标选择的正确性、输出价值 。
如果考虑到商业环境变化比较快，还需要考虑研发是否有能力适应环境的变化、是否能与时俱进，保持稳定的、有价值的交付，即我们经常所说的可持续性发展或进步。这和研发效能有关系，但其实是另一个问题，只是影响研发效能的一个重要因素。
研发效能强调效率和效果、正确性、竞争力以及对企业效益的贡献，我们非常关注研发效能，也就毋庸置疑。
2. 研发效能如何落地？
这就需要讨论研发效能的底层逻辑，那么底层逻辑是什么呢？
回到前面的定义，就是要有更高的产出，且产出的价值越高越好，在保证目标正确的情况下产出的速度、效率越快越好；可以通过内建质量（如降低复杂度、提升代码质量）、让员工保持高度的注意力等不断提升效率......这样我们就可以归纳出 研发效能的底层逻辑 就是：做正确的事 ，然后正确地做事，再追求速度 。但这三层逻辑 都依赖于人，人是决定的因素。所以 研发效能的底层逻辑第一条 是 选对人、好好培养人。
基于这样的逻辑，研发效能的落地可分为四个层次：
选对人、好好培养人，如审视公司的招聘流程、培训和绩效考核制度；
做正确的事，如澄清业务战略，明确问题、业务需求和用户需求；
正确地做事 ：如确定/选择正确的开发模式，制定有效的组织结构和流程；
追求速度 /效率 ，如不断提高研发人员的技能，开发/购买 研发平台，搭建DevOps工具链，实现高度的自动化（包括构建、部署、测试、运维）。
这里虽然比 “大象装进冰箱” 多了一项，但还好，大家还是比较容易记得住，容易实施。比我 最近批评的一本书《软件开发的201个原则》要好得多，正如网友说，原则太多，就没有原则。打开书，其中有些原则真不像话，如：
原则4 高质量软件是可以实现的 （我们早就知道，但现在不想，代价太高）
原则8 与客户/用户沟通 （哪个团队不去和客户/用户沟通？一个动作不适合原则，原则要有明确的态度，告诉我们要做什么、不做什么，如必须 和客户/用户沟通 面对面沟通、 每天和客户/用户保持沟通 ）
原则34 软件文档都要有索引 （不一定，今天有全文搜索功能，或者 画一个思维导图，只要有关键字，但不是索引）
原则44 确定子集
......
3. 研发效能底层逻辑第1层：解决人的问题
仅仅写人是决定的因素，大家印象还不深刻，甚至还不同意这点 ，我还不得不说：需求是人挖掘出来的，设计也是人做的，代码也是人写的，测试也是人干的..... 流程也是人制定的、还需要人去执行，工具也需要人去开发和使用，总监 、经理也都是人 ......此时你该认可：研发效能底层逻辑第1层是解决人的问题，对吧？
昨天听一个线上讨论研发效能的直播节目， 有两点很深刻 ：
听众急着要度量指标，想了解如何度量效能；
一位嘉宾说，有的公司把员工不当人看、当成工具。
第1点留到后面去讨论，首先讨论第2点： 把员工不当人看、当成工具 ，要求员工听话，遵守流程、遵守工作纪律，员工只会干活，缺乏思考，没有创新、发展的空间。其次，招聘流程过于粗暴简单、 入职培训 缺失、绩效考核唯KPI指标 ..... 等等 ，没有把 “招对人” 、“培养人” 放在第一位。
要招对人，这点可以学学亚马逊，之前文章 亚马逊QA/测试工程师面试究竟考察应聘者哪些能力？ 有详细介绍 ， 招一个人要经过5～6个环节 （不算多） ，其中有一个环节比较特别，就是 设置Bar raiser。 Bar raisers是一群在各个岗位都是精英的评估人，对应聘者录用与否拥有表决权，保证亚马逊能招聘到优秀人才。国内公司流行谁用人，谁最后面试、谁最后决定，这很容易让一些不合格的人进入公司/团队，因为用人部门一般是缺人才招人，常常会因为任务急着有人去干，就放松标准、降低要求，让不合格的人进入自己的团队。甚至有些团队Lead怕比自己更厉害的人进来抢走自己的位置，招进的人的水平都会比他/她低。
良好的组织文化的培养、人员技能的培养 （包括人才规划、培训体系建立、课程设置，虽然70%是在工作中学） 等等 要紧抓不放，时刻不松懈，微软的愿景之一： 帮助员工发挥最大潜能， 微软有一套很好的胜任力建设和评估体系， 见下面 插图 ，之前在某人才培养峰会上，我曾详细介绍过。由于篇幅所限，以后有机会再谈。
4. 研发效能底层逻辑第2层： 做正确的事
做正确的事，即方向正确，做的事有价值，相当于在 000…000 前面加上1，加更多个0，是下面第3层、第4层去实现的，但没有这个1，做得再快、再持续改进，依旧是0。同时，做了正确的事，就减少了返工，也提高了效率、降低了成本。
基于对软件研发的正确理解，需求是源头，是研发的输入， “需求定义得是否正确” 显得非常重要 。开发的需求对客户的价值越高，开发效能就越高，这也符合我们平时特别强调 需求的优先级 ，按优先级来规划我们版本发布计划。只是这里的 优先级 不取决于 单个业务人员是否强势或催得是否急、 也不取决于 哪个客户叫得凶不凶， 而是取决于 解决客户/用户的问题是否到位、是否值得优先解决。如果研发团队独立，需求来自业务部门或客户，而且没有回旋的余地，在这层逻辑， 研发效 能 就取决于架构设计的质量、代码的质量，那意味着做出正确的架构设计、写出正确的代码，即我们常常强调的 内建质量 （Built-in quality）。
做正确的事，传统领域有好的实践，也有好的方法，你可能觉得不适合软件研发，没问题，软件研发也有自己好的实践， 至少我觉得3个实践比较可行有效 ：
ATDD（验收测试驱动开发） ，通过明确需求的验收标准，来澄清需求，让业务、产品、研发、测试等达成共识；
亚马逊 的逆向工作法 ，见下面插图，只有三步，也容易记住、容易实施。
研发流程形成闭环，实时做日志分析、及时获取客户的反馈，送入下一个迭代的输入。
这比向你说一套需求工程来得简单、容易。如果你还做不好，就得好好学习需求工程。
( 亚马逊 的逆向工作法 )
5. 研发效能底层逻辑第3层： 正确地做事
这就回到刚才说的第1点 “听众急着要度量指标，想了解如何度量效能”。
许多公司就像这位听众一样，抓研发效能，首先想到的就是要抓研发效能度量，急着确定度量指标，其次想到的就是建研发效能平台、搭DevOps工具链，忘记了“人是决定的因素”，也忘记了“先要有明确的业务目标”， 度量、工具链都是手段，不是目标 。只有搞清楚研发的效能业务目标是什么，然后看要达成这些目标的障碍是什么、问题在哪里，然后去想如何清除 障碍 、解决问题。
正确地做事，如前所说，包括选择正确的开发模式、制定有效的流程等。不是别人都用Scrum，我也用Scrum，而是分析自己研发（流程）中的主要问题是什么、如何解决这些问题，有没有现成的框架可以解决这些问题，是需要改进还是需要变革？
（方法是否正确，此图可引发你的思考）
正确地做事 ，就是要用系统工程的方法解决问题，有良好的系统性思维、结构化思维，还要经过 “目标设定-问题分析-方案设计-评估指标建立-多个方案评估-选择最优方案” 等问题分析与解决的基本流程。如果要学习 Guide tot he Systems Engineering Body of Knowledge ，有1100+页，估计你没时间。
（系统工程方法）
方法优于工具，工具是方法的固化。我们需先制定良好的方法，然后再开发出易用的、高效的工具。 像Google研发效能在技术上也只有三大招：
使用单体代码仓库（管理公司的大部分代码）；
使用高效的声明式定义bazel构建，支持精准测试；
主干开发
虽然软件系统很复杂，但许多时候就是 我们自己 没有正确做事而造成的。如果是遗留系统，没有太多的好方法，可以慢慢重构，或老系统不动，重新写一套新系统。 今后，我们需要每时每刻都应该在想 ：高内聚低耦合，为可靠性而设计/编程、为性能而设计/ 编 程 、为弹性而设计、让别人看懂代码比写代码更重要... ... 那么正确做事的方法总是有的 。更何况人类有53年的软件工程经验与教训 （虽然人类有健忘症） 、有成千上万人的软件研发工作经验的积累？许多优秀的实践可以尝试， 大部分工作都有优秀实践参考 ，而不需要每件事都靠自己发明创造，更不需要自己不断挖坑、不断填坑。
6. 研发效能底层逻辑第4层： 追求速度/效率
招对了人、培养好了人，差不多就能做正确的事、正确地做事。
如果还不行，就有前面的一些思路、方法供参考。实现了 “做正确的事、正确地做事”，效能已经很高了，当然我们还不满足，需要不断地提升研发效能， 这时需要做好下列三件事 ：
需要落实研发效能度量，可以参考 只要五步，研发效能度量就能成功落地！
持续改进流程，闭环反馈周期越来越短、越来越准确；
持续技术创新或引进新技术（如AI技术），完善研发平台和 DevOps 工具链，中间可能包含了“固化，破局，再固化，再破局”的过程。
如果用底层逻辑的语言，可以概括为一句话—— 持续反思、持续创新、持续改进，其目标就是更好地确保组织的 一致性，持续地做对事情、正确地做事 ，产生飞轮效应。
这篇文章算是一气呵成。虽然文章不算长，但我讲清楚了研发效能的底层逻辑 （4层） 。
