原创 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年国内软件质量调查”

软件研发效能的底层逻辑相关推荐

细数软件研发效能的七宗罪
之前写了两篇文章,分别介绍 "软件研发效能的负面清单"."软件研发的十大浪费",今天算是对软件研发效能的负面东西做一个总结,挖掘出背后的原因.从本质上看,都是人 ...
软件研发效能的负面清单：哪项是头号敌人？
随着企业的规模越来越大.外部竞争越来越激烈,越来越多的企业关注软件研发效能,之前我也写了几篇有关软件效能的文章,例如: 软件研发效能的底层逻辑直击灵魂:软件研发的第一性原理与10倍效能今天从逆向思 ...
从底层逻辑聊日报设计与公司治理
原创不易,求分享.求一键三连当业务复杂到一定阶段的时候,效率问题会首当其冲,基本解法是化整为零.分赛道,对应的产物可以是子公司.事业部.业务单元.项目组. 好处是目标聚焦.问题也会聚焦:工作内容闭环 ...
光环：软件研发效能特征与度量——王一男
摘要:文章内容主要来源于光环国际2022年第三届中国科创者大会王一男老师的分享,原分享名称为"研发效能大数据管理与应用实际".通过将软件研发和制造生产进行横向比较,得出软件研发是一 ...
管理95后员工，管理者必知的4条底层逻辑
95后员工普通受教育程度更高,需要的是尊重,相信的是平等,更看重价值观,追求自我实现. 这些特征决定了过去的管理手段在新生代员工身上不再适用了.在这个新时代,如何管理好95后员工? 你要能给出清晰明确 ...
把用户体验设计放到底层逻辑架构设计的前面去做
1."还在考虑一些底层的逻辑关系问题,暂时不要去考虑交互设计的事情"."底层的逻辑架构,在很大程度上决定了发展方向,而表现层修改的成本不高"."我们的 ...
读书 | IT人如何直击本质洞察底层逻辑？
[好书共读]| 作者/Edison Zhou 作为IT技术人,我们不仅要精进技术,也要在技术之外修炼自己的软能力.本质思考,是一种直击事物本质的能力,是思考"思考的方法",是一切思 ...
转载|网络编程中阻塞式函数的底层逻辑
逛知乎看到的,觉得写的挺透彻的,转载一下,原文链接:Unix网络编程里的阻塞是在操作系统的内核态创建一个线程来死循环吗? 原文以阻塞式的recv函数作为讲解,但是所有阻塞式的api底层逻辑基本相通. ...
洞察设计模式的底层逻辑
简介: 设计模式是开发同学经常聊到的话题,也经常被用到实际的开发项目中,熟练的人可以做到信手拈来,不熟悉的人陷入苦思冥想中.笔者认为,不仅仅要掌握设计模式的用法,更要洞察设计模式的底层逻辑,只有那样, ...

软件研发效能的底层逻辑

原创 Test Ninja 软件质量报道 2021-12-24 07:48

软件研发效能的底层逻辑相关推荐

最新文章

热门文章