软件研发效能的底层逻辑

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

软件研发效能的底层逻辑_第1张图片

最近两年软件研发效能很热,这也促使我去年发起了 全球软件质量&效能大会(QECon)但凡某件事太热,就很容易走火入魔,更多人被带入误区,有点像当初Agile、DevOps一样,把所有好东西都往自己篮中装,想包罗万象、想一网打尽 …… 其实,许多优秀的实践早已存在,不管Agile/DevOps在与不在。当初IBM RUP也想一统天下,如今安在?

整整20年过去了,多少Scrum敏捷教练前赴后继,但Scrum敏捷开发模式在国内实施的效果如何?其实,效果一般。根据去年 和今年 的调查数据,至今天真正实施Scrum敏捷开发模式的组织只有28%左右,这其中估计还有一些是伪敏捷。

软件研发效能的底层逻辑_第2张图片

在软件研发效能没走火入魔之前,我觉得有必要和大家谈一谈 软件研发效能的底层逻辑,拨开云雾,看清软件研发效能的本质,澄清软件研发效能的是是非非,有利于提升软件研发效能,有利于软件研发团队做好明年或未来的研发计划。

之前写了 软件测试的底层逻辑 和 软件质量管理的底层逻辑 ,今天所写的软件研发效能的底层逻辑,就作为底层逻辑三部曲的最后一篇,算是2021年的收官之作,可能会比较犀利些,不妥之言,望多多包涵。欢迎留言参与讨论。

1. 究竟什么是研发效能?

维基百科给效能(efficacy)的定义是:事物产生功效的能力,常用于通识教育、医学和药理学,可以忽略。然后看百度百科的定义,基本靠谱:效能是指有效的、集体的效应,即人们在有目的、有组织的活动中所表现出来的效率和效果,它反映了所开展活动目标选择的正确性及其实现的程度

普华永道给出“组织效能关注组织效率、竞争力和员工贡献度”,谷歌(Google)的GSM(Goals-Signals-Metrics)框架,关注目标的达成,并转化为研发效能五个核心元素:代码质量、工程师注意力、智力复杂性、速度与速率、满意度。

其实在我之前写的一篇文章已讨论过,但还是要在这里澄清一下,这也是我们后面讨论的基础。概念不同,相互争辩就没有意义。研发效能(R&D Effectiveness)是指研发团队对业务有实际价值的产出,如果需要加上限制,可以说效能单位时间内研发团队对业务有实际价值的人均产出,效率关注速度、生产力,而缺乏关注目标选择的正确性、输出价值。

如果考虑到商业环境变化比较快,还需要考虑研发是否有能力适应环境的变化、是否能与时俱进,保持稳定的、有价值的交付,即我们经常所说的可持续性发展或进步。这和研发效能有关系,但其实是另一个问题,只是影响研发效能的一个重要因素。

研发效能强调效率和效果、正确性、竞争力以及对企业效益的贡献,我们非常关注研发效能,也就毋庸置疑。

2. 研发效能如何落地?

这就需要讨论研发效能的底层逻辑,那么底层逻辑是什么呢?

回到前面的定义,就是要有更高的产出,且产出的价值越高越好,在保证目标正确的情况下产出的速度、效率越快越好;可以通过内建质量(如降低复杂度、提升代码质量)、让员工保持高度的注意力等不断提升效率......这样我们就可以归纳出研发效能的底层逻辑就是:做正确的事,然后正确地做事,再追求速度。但这三层逻辑都依赖于人,人是决定的因素。所以研发效能的底层逻辑第一条是选对人、好好培养人。

基于这样的逻辑,研发效能的落地可分为四个层次:

  1. 选对人、好好培养人,如审视公司的招聘流程、培训和绩效考核制度;

  2. 做正确的事,如澄清业务战略,明确问题、业务需求和用户需求;

  3. 正确地做事:如确定/选择正确的开发模式,制定有效的组织结构和流程;

  4. 追求速度/效率,如不断提高研发人员的技能,开发/购买 研发平台,搭建DevOps工具链,实现高度的自动化(包括构建、部署、测试、运维)。

这里虽然比 “大象装进冰箱” 多了一项,但还好,大家还是比较容易记得住,容易实施。比我最近批评的一本书《软件开发的201个原则》要好得多,正如网友说,原则太多,就没有原则。打开书,其中有些原则真不像话,如:

  • 原则4 高质量软件是可以实现的(我们早就知道,但现在不想,代价太高)

  • 原则8  与客户/用户沟通(哪个团队不去和客户/用户沟通?一个动作不适合原则,原则要有明确的态度,告诉我们要做什么、不做什么,如必须和客户/用户沟通面对面沟通、每天和客户/用户保持沟通)

  • 原则34 软件文档都要有索引(不一定,今天有全文搜索功能,或者 画一个思维导图,只要有关键字,但不是索引)

  • 原则44 确定子集 

  • ......

3. 研发效能底层逻辑第1层:解决人的问题

仅仅写人是决定的因素,大家印象还不深刻,甚至还不同意这点,我还不得不说:需求是人挖掘出来的,设计也是人做的,代码也是人写的,测试也是人干的..... 流程也是人制定的、还需要人去执行,工具也需要人去开发和使用,总监、经理也都是人......此时你该认可:研发效能底层逻辑第1层是解决人的问题,对吧?

昨天听一个线上讨论研发效能的直播节目,有两点很深刻

  1. 听众急着要度量指标,想了解如何度量效能;

  2. 一位嘉宾说,有的公司把员工不当人看、当成工具。

第1点留到后面去讨论,首先讨论第2点:把员工不当人看、当成工具,要求员工听话,遵守流程、遵守工作纪律,员工只会干活,缺乏思考,没有创新、发展的空间。其次,招聘流程过于粗暴简单、入职培训缺失、绩效考核唯KPI指标..... 等等,没有把 “招对人” 、“培养人” 放在第一位。

要招对人,这点可以学学亚马逊,之前文章 亚马逊QA/测试工程师面试究竟考察应聘者哪些能力?有详细介绍,招一个人要经过5~6个环节(不算多),其中有一个环节比较特别,就是设置Bar raiser。Bar raisers是一群在各个岗位都是精英的评估人,对应聘者录用与否拥有表决权,保证亚马逊能招聘到优秀人才。国内公司流行谁用人,谁最后面试、谁最后决定,这很容易让一些不合格的人进入公司/团队,因为用人部门一般是缺人才招人,常常会因为任务急着有人去干,就放松标准、降低要求,让不合格的人进入自己的团队。甚至有些团队Lead怕比自己更厉害的人进来抢走自己的位置,招进的人的水平都会比他/她低。

软件研发效能的底层逻辑_第3张图片

良好的组织文化的培养、人员技能的培养(包括人才规划、培训体系建立、课程设置,虽然70%是在工作中学)等等 要紧抓不放,时刻不松懈,微软的愿景之一:帮助员工发挥最大潜能,微软有一套很好的胜任力建设和评估体系,见下面插图,之前在某人才培养峰会上,我曾详细介绍过。由于篇幅所限,以后有机会再谈。

软件研发效能的底层逻辑_第4张图片

4. 研发效能底层逻辑第2层:做正确的事

做正确的事,即方向正确,做的事有价值,相当于在 000…000 前面加上1,加更多个0,是下面第3层、第4层去实现的,但没有这个1,做得再快、再持续改进,依旧是0。同时,做了正确的事,就减少了返工,也提高了效率、降低了成本。

基于对软件研发的正确理解,需求是源头,是研发的输入,“需求定义得是否正确” 显得非常重要。开发的需求对客户的价值越高,开发效能就越高,这也符合我们平时特别强调需求的优先级,按优先级来规划我们版本发布计划。只是这里的优先级不取决于单个业务人员是否强势或催得是否急、也不取决于哪个客户叫得凶不凶,而是取决于解决客户/用户的问题是否到位、是否值得优先解决。如果研发团队独立,需求来自业务部门或客户,而且没有回旋的余地,在这层逻辑,研发效能就取决于架构设计的质量、代码的质量,那意味着做出正确的架构设计、写出正确的代码,即我们常常强调的内建质量(Built-in quality)。

做正确的事,传统领域有好的实践,也有好的方法,你可能觉得不适合软件研发,没问题,软件研发也有自己好的实践,至少我觉得3个实践比较可行有效

  1. ATDD(验收测试驱动开发),通过明确需求的验收标准,来澄清需求,让业务、产品、研发、测试等达成共识;

  2. 亚马逊的逆向工作法,见下面插图,只有三步,也容易记住、容易实施。

  3. 研发流程形成闭环,实时做日志分析、及时获取客户的反馈,送入下一个迭代的输入。

这比向你说一套需求工程来得简单、容易。如果你还做不好,就得好好学习需求工程。

软件研发效能的底层逻辑_第5张图片

(亚马逊的逆向工作法)

5. 研发效能底层逻辑第3层:正确地做事

这就回到刚才说的第1点 “听众急着要度量指标,想了解如何度量效能”。

许多公司就像这位听众一样,抓研发效能,首先想到的就是要抓研发效能度量,急着确定度量指标,其次想到的就是建研发效能平台、搭DevOps工具链,忘记了“人是决定的因素”,也忘记了“先要有明确的业务目标”,度量、工具链都是手段,不是目标。只有搞清楚研发的效能业务目标是什么,然后看要达成这些目标的障碍是什么、问题在哪里,然后去想如何清除障碍、解决问题。

正确地做事,如前所说,包括选择正确的开发模式、制定有效的流程等。不是别人都用Scrum,我也用Scrum,而是分析自己研发(流程)中的主要问题是什么、如何解决这些问题,有没有现成的框架可以解决这些问题,是需要改进还是需要变革?

软件研发效能的底层逻辑_第6张图片

(方法是否正确,此图可引发你的思考)

正确地做事,就是要用系统工程的方法解决问题,有良好的系统性思维、结构化思维,还要经过 “目标设定-问题分析-方案设计-评估指标建立-多个方案评估-选择最优方案” 等问题分析与解决的基本流程。如果要学习Guide tot he Systems Engineering Body of Knowledge,有1100+页,估计你没时间。

软件研发效能的底层逻辑_第7张图片

(系统工程方法)

方法优于工具,工具是方法的固化。我们需先制定良好的方法,然后再开发出易用的、高效的工具。像Google研发效能在技术上也只有三大招:

  1. 使用单体代码仓库(管理公司的大部分代码);

  2. 使用高效的声明式定义bazel构建,支持精准测试;

  3. 主干开发

虽然软件系统很复杂,但许多时候就是我们自己没有正确做事而造成的。如果是遗留系统,没有太多的好方法,可以慢慢重构,或老系统不动,重新写一套新系统。今后,我们需要每时每刻都应该在想:高内聚低耦合,为可靠性而设计/编程、为性能而设计/编程、为弹性而设计、让别人看懂代码比写代码更重要...... 那么正确做事的方法总是有的。更何况人类有53年的软件工程经验与教训(虽然人类有健忘症)、有成千上万人的软件研发工作经验的积累?许多优秀的实践可以尝试,大部分工作都有优秀实践参考,而不需要每件事都靠自己发明创造,更不需要自己不断挖坑、不断填坑。

6. 研发效能底层逻辑第4层:追求速度/效率

招对了人、培养好了人,差不多就能做正确的事、正确地做事。

如果还不行,就有前面的一些思路、方法供参考。实现了 “做正确的事、正确地做事”,效能已经很高了,当然我们还不满足,需要不断地提升研发效能,这时需要做好下列三件事

  1. 需要落实研发效能度量,可以参考 只要五步,研发效能度量就能成功落地!

  2. 持续改进流程,闭环反馈周期越来越短、越来越准确;

  3. 持续技术创新或引进新技术(如AI技术),完善研发平台和DevOps工具链,中间可能包含了“固化,破局,再固化,再破局”的过程。

如果用底层逻辑的语言,可以概括为一句话—— 持续反思、持续创新、持续改进,其目标就是更好地确保组织的一致性,持续地做对事情、正确地做事,产生飞轮效应。

这篇文章算是一气呵成。虽然文章不算长,但我讲清楚了研发效能的底层逻辑(4层)。如果您读到这里,还感到意犹未尽,请点击文章最前面的 “研发效能、底层逻辑” 标签,参考更多资料,更欢迎您留言参与讨论。

PS:欢迎参加 “ 2021年国内软件质量调查”

你可能感兴趣的:(7.软件工程,scrum,研发效能)