软件研发效能的底层逻辑
原创 Test Ninja 软件质量报道 2021-12-24 07:48
最近两年软件研发效能很热，这也促使我去年发起了 全球软件质量&效能大会（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层）。如果您读到这里，还感到意犹未尽，请点击文章最前面的 “研发效能、底层逻辑” 标签，参考更多资料，更欢迎您留言参与讨论。
PS：欢迎参加 “ 2021年国内软件质量调查”