软件研发效率这两年很火，这也促使我在去年发起了全球软件质量与效率大会（QECon）。被引入误区有点像一开始的敏捷和DevOps。他们把所有的好东西都放在篮子里，想要涵盖一切，抓住一切……其实，很多优秀的实践已经存在，不管有没有Agile/DevOps。当初IBM的RUP也想一统天下，可现在呢？整整20年过去了，又传承了多少Scrum敏捷教练，而Scrum敏捷开发模式在中国的落地效果如何？其实效果一般。根据去年和今年的调查数据，今天只有大约28%的组织真正实施了Scrum敏捷开发模式，其中一些估计是伪敏捷。在软件研发效率走火入魔之前，我觉得有必要跟大家聊聊软件研发效率的底层逻辑，拨开云雾，看清软件研发效率的本质，厘清软件研发效率的是非，助力提升软件研发效率有利于软件研发团队做好明年或未来的研发计划。之前写过软件测试和软件质量管理的底层逻辑。今天写的软件研发效率底层逻辑是底层逻辑三部曲的最后一篇。2021年收官之作，可能会更犀利，不当言论还望大家见谅。欢迎留言参与讨论。1.什么是研发效率？维基百科对功效的定义是：某物产生某种效果的能力，常用于通识教育、医学、药理学等领域，可以忽略不计。再看看百度百科的定义，基本靠谱：effectiveness是指有效的集体效应，即人们在有目的、有组织的活动中表现出的效率和效果，反映了活动目标选择的正确性性及其实现的程度。PricewaterhouseCoopers给出“organizationaleffectivenessfocussonorganizationefficiency,competitive,andemployeecontribution”，Google的GSM（Goals-Signals-Metrics）框架着眼于目标的达成，并将其转化为研发效率的五个核心要素：CodeQuality,EngineerAttention，智力复杂性，速度和速度，满意度。其实我在之前写的一篇文章中已经讨论过了，但是我还是想在这里澄清一下，这也是我们后面讨论的基础。如果概念不同，相互争论是没有意义的。研发效能（R&DEffectiveness）是指研发团队的产出对企业具有实际价值。如果要加限制的话，可以说效率是研发团队在单位时间内对业务有实际价值的人均产出，而效率则侧重于速度和生产力。但缺乏对目标选择和输出值正确性的关注。考虑到商业环境瞬息万变，还需要考虑研发是否有能力适应环境的变化，与时俱进，保持稳定和有价值的交付，也就是我们常说的可持续发展或进步。这跟研发效率有关，其实是另外一个问题，只是影响研发效率的一个重要因素。研发有效性强调效率和有效性、正确性、竞争力和对企业利益的贡献。我们非常关注研发的有效性，所以这是毋庸置疑的。2、如何实现研发效率？这就需要讨论研发有效性的底层逻辑，那么底层逻辑是什么？回到前面的定义，就是要有更高的产出，产出的价值越高越好，在目标正确的情况下，产出速度和效率越快越好；可以通过内置质量（如Reducecomplexity、提高代码质量）、保持员工高度专注等方式来不断提升效率……这样，我们可以总结出研发效率的底层逻辑是：做正确的事，然后做正确的事，然后追求速度。但是这三层逻辑都是靠人，人是决定因素。因此，R&D有效性的第一个底层逻辑是选对人，培养好人。基于这个逻辑，R&D有效性的实施可以分为四个层次：选对人，培养好人，比如审查公司的招聘流程、培训和绩效考核体系；做正确的事，比如明确商业战略，明确问题，商业需求和用户需求；正确做事：如确定/选择正确的开发模式，制定有效的组织结构和流程；追求速度/效率，如不断提升研发人员技能、开发/采购研发平台、构建DevOps工具链，实现高度自动化（包括构建、部署、测试、运维）。虽然这里比“Puttheelephantintherefrigerator”多了一项，但好在大家更容易记住和执行。比我最近批评的那本书《软件开发的201个原则》好多了。正如网友所说，原则太多，没有原则。翻开书，有些原则真是离谱，比如：原则4高质量的软件是可以实现的（我们早就知道了，现在不想了，成本太高了）原则8Communicatewithcustomers/user（哪个团队不和customers/Usercommunication？一个动作不适合principle，principle要有明确的态度，告诉我们什么该做，什么不该做，比如必须和principle沟通客户/用户面对面，每天与客户/用户交流）原则34软件文档一定要有索引（不一定，今天有全文搜索功能，或者画个思维导图，只要有是关键词，不是索引）44原则决定了子集...3.研发效能的底层逻辑第一层：解决人的问题只有人是决定性因素。对于这一点，大家并不以为然，甚至不以为然。不得不说：需求是人挖掘的，设计也是人做的，代码也是人写的，测试也是人做的……流程也是人制定的，需要人执行人们。工具也需要被人开发和使用。董事、经理也是人……这时候你应该认识到：研发效率的底层逻辑第一层是解决人的问题，对吧？昨天听了一个讨论研发效率的网络直播节目，深刻的有两点：观众热衷于衡量指标，想知道如何衡量效率；一位嘉宾说，有的公司不是把员工当人，而是当工具。第一点以后再说，第二点先说：把员工当人，当工具，要求员工听话，按流程办事，遵守工作纪律。员工只会工作，缺乏思考，没有创新和发展的空间。.其次，招聘流程过于粗糙简单，缺乏入职培训，绩效考核只有KPI指标……等，“招对人”和“培养人”不是第一要务。要招到合适的人，你可以向亚马逊学习。上一篇亚马逊QA/测试工程师面试考察应聘者有哪些能力？据详细介绍，招募一个人需要5-6个环节（不算太多），其中一个环节比较特殊，就是设置Barraiser。Barraisers是一群评价者，他们是各个岗位上的精英。他们有权投票决定候选人是否被聘用，确保亚马逊能够招聘到优秀的人才。流行于国内公司，谁招人，谁最后面试，谁最后做决定。一些不合格的人很容易进入公司/团队，因为用人部门普遍缺人才招人，他们往往因为着急找人做任务而松懈。设定标准，降低要求，让不合格的人进入你的团队。有的组长甚至生怕有比自己强的人进来抢位，新兵级别比他/她还低。良好组织文化的培养和人员技能的培养（包括人才规划、培训体系建立、课程设置，虽然其中70%是在工作中学习到的）等必须抓紧，绝不松懈。微软的愿景之一：帮助最大限度地发挥员工的潜力，微软有一个非常好的能力建设和评估体系，见下图，我在一次人才培训峰会上详细介绍过。限于篇幅，以后再说。4、研发效率底层逻辑第2层：做正确的事，做正确的事，即方向正确，做的事有价值，相当于000前面加1。.000，并且加了更多的0，就是Layer下面的第三个，4来实现，但是没有这个1，不管怎么快，怎么持续改进，还是0。同时，做正确的事，减少返工，提高效率，降低成本。基于对软件开发的正确认识，需求是研发的源泉和输入，“需求是否定义正确”非常重要。开发需求对客户的价值越高，开发效率就越高。这也符合我们平时强调需求的优先级，按照优先级来规划我们的版本发布计划。只是这里的优先级不取决于单个业务人员强不急，也不取决于哪个客户大声不大声，而是看客户/用户的问题是否解决，是否值得优先事项。如果研发团队是独立的，需求来自业务部门或客户，没有回旋余地，在这个逻辑层面，研发效率取决于架构设计的质量和代码的质量，也就是做出正确的架构设计和编写正确的代码，也就是我们经常强调的内建质量（Built-inquality）。做正确的事。传统领域有好的做法、好的方法。你可能会觉得它不适合做软件开发。没问题。软件开发也有自己的良好做法。至少我认为三种做法比较可行有效：ATDD（AcceptanceTestDrivendevelopment），通过明确需求的验收标准来明确需求，让业务、产品、研发、测试等达成共识；亚马逊的逆向工作法，见下图，只有三个步骤，而且容易记忆和实施。研发流程形成闭环，实时日志分析，及时获取客户反馈，输入到下一次迭代。这比告诉你一套需求工程更简单、更容易。如果还是做不好，就得好好学习需求工程。（亚马逊逆向工作法）5、研发绩效底层逻辑第三层：正确做事。这又回到刚才提到的第一点，“受众渴望衡量指标，想知道如何衡量绩效”。许多公司都像这些听众一样关注研发效率。他们首先想到的是衡量研发效率，他们急于确定衡量指标。他们想到的第二件事是搭建研发效率平台，搭建DevOps工具链。因素”而忘记了“首先必须有一个明确的业务目标”。测量和工具链是手段，而不是目标。只有弄清楚研发的效率和业务目标是什么，然后看看实现这些目标的障碍和问题，然后思考如何排除障碍和解决问题。把事情做对，前面说了，包括选择正确的开发模式，制定有效的流程等等。不是别人都用Scrum，我也用Scrum，但是要分析一下自己研发（过程）中主要存在哪些问题，如何解决这些问题，有没有现成的框架来解决这些问题，有没有现成的框架？需要改进或改变？（方法是否正确，这张图能引发你的思考）正确做事就是用系统的工程方法解决问题，有良好的系统思维和结构化思维，要经过“目标设定-问题分析-方案”的基本过程设计—评价指标建立—多方案评价—选择最优方案等问题分析与解决方案”。如果你想学习GuidetotheSystemsEngineeringBodyofKnowledge，有1100多页，我想你没有时间。（系统工程方法）方法优于工具，工具是方法的固化。我们需要先开发好的方法，然后再开发易用高效的工具。像谷歌一样，研发效率只有三个技术诀窍：使用单一代码仓库（管理公司大部分代码）；有时是我们自己做事不对造成的。如果是遗留系统，好的方法不多，可以慢慢重构，或者在不移动旧系统的情况下重写一个新系统。未来，我们需要时刻思考：高内聚低耦合，为可靠性设计/编程，为性能设计/编程，为灵活性设计，让别人理解代码比写代码更重要。...那么总有办法把事情做好。更何况，人类有53年的软件工程经验和教训（虽然人类有健忘症），成千上万的人积累了软件研发经验？很多优秀的做法都可以尝试，大部分作品都有优秀的实践参考，而不是什么都自己去发明创造，更不用说不断地挖坑和填坑了。6、研发效率底层逻辑第4层：追求速度/效率如果招到合适的人，培养合适的人，几乎就可以做对的事，把事情做对。如果没有，有一些以前的想法和方法可以参考。实现了“做正确的事，正确地做事”，效率已经很高了。当然，我们还不满足。我们需要不断提高研发效率。这时候，我们需要做以下三件事：需要实施研发效率衡量，可以参考只要五个步骤，研发效率衡量就可以顺利实施！不断改进流程，闭环反馈周期越来越短，越来越准确；持续的技术创新或新技术（如AI技术）的引入，完善研发平台和DevOps工具链，这可能包括“凝固、打破、再凝固、再破局”的过程。如果用底层逻辑的话，可以用一句话来概括——不断反思，不断创新，不断改进。目的是为了更好的保证组织的一致性，持续做正确的事，正确的做事产生飞轮效应。这篇文章可以算是一篇连贯的文章。文章虽然不太长，但是我已经把研发效率的底层逻辑（4层）讲清楚了。
