软件研发效能的底层逻辑
最近两年软件研发效能很热,这也促使我去年发起了 全球软件质量&效能大会(QECon)但凡某件事太热,就很容易走火入魔,更多人被带入误区,有点像当初Agile、DevOps一样,把所有好东西都往自己篮中装,想包罗万象、想一网打尽 …… 其实,许多优秀的实践早已存在,不管Agile/DevOps在与不在。当初IBM RUP也想一统天下,如今安在?
整整20年过去了,多少Scrum敏捷教练前赴后继,但Scrum敏捷开发模式在国内实施的效果如何?其实,效果一般。根据去年 和今年 的调查数据,至今天真正实施Scrum敏捷开发模式的组织只有28%左右,这其中估计还有一些是伪敏捷。
1. 究竟什么是研发效能?
如果考虑到商业环境变化比较快,还需要考虑研发是否有能力适应环境的变化、是否能与时俱进,保持稳定的、有价值的交付,即我们经常所说的可持续性发展或进步。这和研发效能有关系,但其实是另一个问题,只是影响研发效能的一个重要因素。
2. 研发效能如何落地?
这就需要讨论研发效能的底层逻辑,那么底层逻辑是什么呢?
回到前面的定义,就是要有更高的产出,且产出的价值越高越好,在保证目标正确的情况下产出的速度、效率越快越好;可以通过内建质量(如降低复杂度、提升代码质量)、让员工保持高度的注意力等不断提升效率......这样我们就可以归纳出研发效能的底层逻辑就是:做正确的事,然后正确地做事,再追求速度。但这三层逻辑都依赖于人,人是决定的因素。所以研发效能的底层逻辑第一条是选对人、好好培养人。
基于这样的逻辑,研发效能的落地可分为四个层次:
选对人、好好培养人,如审视公司的招聘流程、培训和绩效考核制度;
做正确的事,如澄清业务战略,明确问题、业务需求和用户需求;
正确地做事:如确定/选择正确的开发模式,制定有效的组织结构和流程;
追求速度/效率,如不断提高研发人员的技能,开发/购买 研发平台,搭建DevOps工具链,实现高度的自动化(包括构建、部署、测试、运维)。
原则4 高质量软件是可以实现的(我们早就知道,但现在不想,代价太高)
原则8 与客户/用户沟通(哪个团队不去和客户/用户沟通?一个动作不适合原则,原则要有明确的态度,告诉我们要做什么、不做什么,如必须和客户/用户沟通面对面沟通、每天和客户/用户保持沟通)
原则34 软件文档都要有索引(不一定,今天有全文搜索功能,或者 画一个思维导图,只要有关键字,但不是索引)
原则44 确定子集
......
3. 研发效能底层逻辑第1层:解决人的问题
仅仅写人是决定的因素,大家印象还不深刻,甚至还不同意这点,我还不得不说:需求是人挖掘出来的,设计也是人做的,代码也是人写的,测试也是人干的..... 流程也是人制定的、还需要人去执行,工具也需要人去开发和使用,总监、经理也都是人......此时你该认可:研发效能底层逻辑第1层是解决人的问题,对吧?
昨天听一个线上讨论研发效能的直播节目,有两点很深刻:
听众急着要度量指标,想了解如何度量效能;
一位嘉宾说,有的公司把员工不当人看、当成工具。
要招对人,这点可以学学亚马逊,之前文章 亚马逊QA/测试工程师面试究竟考察应聘者哪些能力?有详细介绍,招一个人要经过5~6个环节(不算多),其中有一个环节比较特别,就是设置Bar raiser。Bar raisers是一群在各个岗位都是精英的评估人,对应聘者录用与否拥有表决权,保证亚马逊能招聘到优秀人才。国内公司流行谁用人,谁最后面试、谁最后决定,这很容易让一些不合格的人进入公司/团队,因为用人部门一般是缺人才招人,常常会因为任务急着有人去干,就放松标准、降低要求,让不合格的人进入自己的团队。甚至有些团队Lead怕比自己更厉害的人进来抢走自己的位置,招进的人的水平都会比他/她低。
做正确的事,即方向正确,做的事有价值,相当于在 000…000 前面加上1,加更多个0,是下面第3层、第4层去实现的,但没有这个1,做得再快、再持续改进,依旧是0。同时,做了正确的事,就减少了返工,也提高了效率、降低了成本。
基于对软件研发的正确理解,需求是源头,是研发的输入,“需求定义得是否正确” 显得非常重要。开发的需求对客户的价值越高,开发效能就越高,这也符合我们平时特别强调需求的优先级,按优先级来规划我们版本发布计划。只是这里的优先级不取决于单个业务人员是否强势或催得是否急、也不取决于哪个客户叫得凶不凶,而是取决于解决客户/用户的问题是否到位、是否值得优先解决。如果研发团队独立,需求来自业务部门或客户,而且没有回旋的余地,在这层逻辑,研发效能就取决于架构设计的质量、代码的质量,那意味着做出正确的架构设计、写出正确的代码,即我们常常强调的内建质量(Built-in quality)。
做正确的事,传统领域有好的实践,也有好的方法,你可能觉得不适合软件研发,没问题,软件研发也有自己好的实践,至少我觉得3个实践比较可行有效:
ATDD(验收测试驱动开发),通过明确需求的验收标准,来澄清需求,让业务、产品、研发、测试等达成共识;
亚马逊的逆向工作法,见下面插图,只有三步,也容易记住、容易实施。
研发流程形成闭环,实时做日志分析、及时获取客户的反馈,送入下一个迭代的输入。
这就回到刚才说的第1点 “听众急着要度量指标,想了解如何度量效能”。
许多公司就像这位听众一样,抓研发效能,首先想到的就是要抓研发效能度量,急着确定度量指标,其次想到的就是建研发效能平台、搭DevOps工具链,忘记了“人是决定的因素”,也忘记了“先要有明确的业务目标”,度量、工具链都是手段,不是目标。只有搞清楚研发的效能业务目标是什么,然后看要达成这些目标的障碍是什么、问题在哪里,然后去想如何清除障碍、解决问题。
正确地做事,如前所说,包括选择正确的开发模式、制定有效的流程等。不是别人都用Scrum,我也用Scrum,而是分析自己研发(流程)中的主要问题是什么、如何解决这些问题,有没有现成的框架可以解决这些问题,是需要改进还是需要变革?
正确地做事,就是要用系统工程的方法解决问题,有良好的系统性思维、结构化思维,还要经过 “目标设定-问题分析-方案设计-评估指标建立-多个方案评估-选择最优方案” 等问题分析与解决的基本流程。如果要学习Guide tot he Systems Engineering Body of Knowledge,有1100+页,估计你没时间。
方法优于工具,工具是方法的固化。我们需先制定良好的方法,然后再开发出易用的、高效的工具。像Google研发效能在技术上也只有三大招:
使用单体代码仓库(管理公司的大部分代码);
使用高效的声明式定义bazel构建,支持精准测试;
主干开发
招对了人、培养好了人,差不多就能做正确的事、正确地做事。
如果还不行,就有前面的一些思路、方法供参考。实现了 “做正确的事、正确地做事”,效能已经很高了,当然我们还不满足,需要不断地提升研发效能,这时需要做好下列三件事:
需要落实研发效能度量,可以参考 只要五步,研发效能度量就能成功落地!
持续改进流程,闭环反馈周期越来越短、越来越准确;
持续技术创新或引进新技术(如AI技术),完善研发平台和DevOps工具链,中间可能包含了“固化,破局,再固化,再破局”的过程。