‍

阅读本文你将收获：

1、了解研发效能中的摩尔定律

2、如何从现实中的点滴做起提升研发效能

‍

作者简介

茹炳晟，腾讯Tech Lead，腾讯研究院特约研究员，业界知名实战派研发效能和软件质量双领域专家。中国计算机学会CCF TF研发效能SIG主席，腾讯云、阿里云、华为云最具价值专家，年度 IT 图书最具影响力作者，畅销书《测试工程师全栈技术进阶与实践》、《软件研发效能提升之美》、《软件研发效能提升实践》和《高效自动化测试平台：设计与开发实战》作者，极客时间《软件测试 52 讲—从小工到专家的实战心法》作者。

本文来源：转载茹炳晟老师的公众号内容：《尊重人性，敬畏物性，研发效能提升从点滴做起》；

‍

敬畏物性，研发效能中的摩尔定律

‍

Intel创始人戈登·摩尔于1965年提出了著名的摩尔定律，有以下三个版本：

‍

1. 集成电路芯片上所集成的电路的数目，每隔18个月就翻一番。

2. 微处理器的性能每隔18个月提高一倍，而同期的价格下降一倍。

3. 用一美元所能买到的计算机性能，每隔18个月翻两番。

摩尔定律揭示了信息技术的进步速度，也预言了行业的发展。在摩尔定律发现长达50多年间，顺应摩尔定律的公司飞速发展，很多公司都成为了业界先驱，而忽略它的公司则举步维艰，无法跟上时代发展的步伐。

‍

不过你是否知道，Google的前CEO埃里克·施密特曾提出过一个与之相对应的“反摩尔定律”，其表述是这样的：“一个IT公司今天要想和18个月前卖掉同样多的、同样质量的产品，那么它的营业额就会下降一半”。

反摩尔定律为所有IT公司敲响了可怕的警钟，因为它一针见血地指出了公司的收入随着时间失效的特点，即在后期一个公司花费同样的劳动只能收到以前一半的收入，公司效益大幅缩水。反摩尔定律，逼迫各公司马不停蹄地跟进摩尔定律所规定的速度，否则就不得不面对被淘汰的危险

‍

反摩尔定律告诉我们，越迟交付的价值也是越低的价值。这项规律是客观存在的，不为人的意志所转移，它促使人们不自觉的（或者说是被迫的）优化和改进自身工作，尽可能快速地交付高质量的产品。

‍

软件研发模式的变迁就是一个典型的例子。传统的瀑布模型是反“反摩尔定律”的，我们通常说“瀑布”是不敏捷的，因为瀑布模型把开发分成一系列阶段，包含需求、设计、开发、测试等工序，每个功能都需要经历这些阶段之后才能上线。

‍

瀑布模型最大的问题在于，各阶段的划分是完全固定的、线性的，且粒度较粗，大批量的产品功能都需要经历整个周期到最后才能交付，且应对需求变化和风险的能力较弱，最终影响效能。

‍

一种有效的改进手段叫作迭代式开发，即把开发工作拆分成多个迭代，每个迭代交付一部分价值，更早的交付往往意味着更多的价值。就这一点来说，相对于瀑布开发，迭代式开发能做到更小批量的快速交付，从而更早获取更多价值。

‍

敏捷开发将效能提升至另一个高度，也囊括了迭代式开发的一些优点，它是以人为核心、迭代、循序渐进的开发方式。敏捷开发最大的目标之一就是更快地交付价值，这里的“快”指的不是绝对速度，而是更早地交付。

‍

从软件研发模式的变迁，我们可以看到，人们始终在致力于尽快将有效且高质量的产品交付，以追赶摩尔定律的速度，抢占市场先机。

‍

对研发效能提升起到潜移默化影响的“物性”规律还有很多，包括：康威定律（Conway’s Law）、布鲁克定律（Brook's Law）、霍夫施塔特定律（Hofstadter's Law）、克努特优化法则（Knuth's Optimization Principle）等等，它们是研发效能提升的导流线，敬畏规律，顺势而为，有利于研发效能的提升；违背规律，断鹤继凫，只会使研发效能坠入万丈深渊。

‍

尊重人性，研发效能提升的点滴之举

‍

让我们把视角拉回到现实，如果你能深刻理解并尊重研发效能的人性和物性，那么你就会发现，研发效能的提升并不非得兴师动众或大兴土木，即便是一件很微不足道的小事，或是一个小小的改变，都能对研发效能起到可观的促进效果。下面，我们一起来看一些可以从你我做起的点滴之举。

‍

不要制定冲突的目标

‍

也许你听说过目标制定的SMART原则，其中有一项原则叫相关性（Relevant），它指的是实现该目标与其他目标的关联情况。比如说，某个目标实现了，但是与其他目标的关联度都比较小，那么即便这个目标达成了，意义也不大。

‍

在实际工作中，我们可能还会遇到更极端的情况，即多个目标之间存在冲突。举个例子，研发团队制定的目标是：“半年内人均产生的高危Bug数量小于10个”，而测试团队制定的目标则是：“半年内人均发现的高危Bug数量大于10个”，这就是一组典型的冲突目标。如果团队遵循这样的目标，结果往往就是，测试团队和研发团队逐渐开始对立，或者个别团队成员间达成某种“私下交易”来美化数据。

‍

目标间的冲突对研发效能的损害是极大的，好比你在全速冲刺时，总有人在边上拽你的衣角。要避免制定冲突的目标，以下思路可以参考：

‍

• 目标通晒优于目标拆解：要避免目标冲突，首先要识别出目标冲突。一种比较经济的做法是，在逐层拆解目标前，先在当前层级进行目标通晒，确保无冲突后再向下拆解，这样就可以确保及早发现冲突。

• 向上寻求共同目标：识别到目标冲突后，如何化解冲突呢？答案就是向上寻求共同目标。就拿上面关于Bug数量的目标来说，很显然，研发团队和测试团队的共同目标都是及早交付高质量的产品，以这个共同目标再去审视各自的细分目标，就更容易规避冲突。

‍

规避形式主义

‍

形式主义是组织建设效能低下的万恶之源，特别是当管理者为了实施所谓的科学管理而设定各种不切实际的条条框框时，团队成员就会陷入极其痛苦的状态，最终影响整个团队的工作效率和工作状态。

‍

考虑到软件研发过程中人的因素起到的决定性作用，形式主义在软件研发中的危害相较于其他行业更甚。例如：“领导不下班，我也没法下班”，“上级规定周报必须写满1000字”，“不管单元测试怎么写，覆盖率必须达到90%”，等等。这些案例的共同点，都是在迫使团队成员做一些冗余和无效的工作，来迎合管理者的“懒政”或“个人主义”。如果一个团队充斥着诸如此类的形式主义，团队效率之低可想而知。

‍

规避形式主义，关键是要勇于做减法，敢于消除一些不必要的规则，去除冗余的形式。

‍

我们同样来看一个案例，测试用例评审是软件项目流程中的一个常见环节，相关研发人员、测试人员和产品人员都要参与评审，确保用例场景充分，没有遗漏关键信息。这一评审过程一般都比较枯燥乏味，而且很容易演变为走过场的形式主义。

‍

那么，如何提升测试用例评审的效率呢？答案就是做减法。笔者所在的办公楼层，有一台可移动的电视机，我们把这台电视机推到茶水间门口的沙发边上，每人拿上一瓶饮料就开始评审了，除主讲人外其他人不允许带电脑，评审在一小时内完成，偶尔有超时的，另行预约时间。

‍

这种半正式又轻松的评审方式，能够有效地提升团队成员的专注程度和积极性，我们并不需要每次都把所有人拉到会议室，大家正襟危坐、轮流发言，这样反而会限制思维的迸发。

‍

打破边界

‍

如果你前往某个城市去旅游，恰好经过一些行政区域的交界道路，可以细心观察一下这条道路的维护情况。交界道路的管理和维护一直是城市管理的难题，很容易成为被遗忘的地带，道路两侧的区域管理方各执一词，互相推诿的情况屡见不鲜。

‍

解决这一问题的思路其实很简单，落实责任不“划界”的联管模式，打破边界，从谁都不管变成谁都去管，同时辅以一些制度作为保障，就能根治边界管理的难题。这一举措已经在很多城市推行多年，取得了不错的成果，我们相信，它也可以推广到软件研发工作中去。

‍

不过，笔者所在的公司在推广这一举措时，也遇到了一些“人性”的纠葛。有部分员工反映不敢打破边界，害怕最终演变成“走别人的路，让别人无路可走”的境况，也有员工纠结于“打破边界”是否会造成冗余的工作量，反而降低研发效能。

‍

我们认为，打破边界最首要的指导方向，是鼓励人们主动踏出一步去涉足那些无人问津的灰色地带，对于城市来说，这个灰色地带可能是一条边界道路，对于软件研发工作来说，这个灰色地带可能是一个难以解决的技术问题，或是一个没有明确归属的跨团队项目，甚至是一些不完善的分工体系和组织形式。

‍

除此之外，相互补位也是打破边界所倡导的方向。笔者对自己团队成员有一项基本要求是“一专多能”，即除了精于自己的本职工作以外，还应在其他领域具备一定的多样化能力。这样，整个团队的任何工作都不会出现单点依赖某位成员的情况，大家相互补位，协同共进，这对于团队成员个体的职位发展也是大有裨益的。可以想象，如果团队中的每个人都能做到打破边界，这个团队一定是富有战斗力和进取心的高效团队。

‍

控制与约束

‍

破窗效应是一个心理学理论，假设有一栋别墅窗户破损了，如果不及时进行修理，可能会有更多的人破坏其他的窗户，要想避免这种情况的发生，除了要时刻注意，还需要修补好“第一块玻璃”。这个理论认为，假如在集体环境中某处不良现象一直存在，则可能会让更多人开始效仿最终变本加厉，让整体情况更加糟糕。

‍

软件行业从来都不缺天赋异禀的人才，各种奇技淫巧层出不穷，你有10种创建对象的方法，我有20种一致性保障手段。但在多人协作的工程中，如果缺乏约束，大家自由发挥，结果往往都是一团乱麻。有时人们会开玩笑说，为什么在企业级应用中Java比Python更流行，那是因为Java足够“死板”，不同性情的程序员也很难写出风格迥异的代码。

‍

我们时常会听到这样的说辞：“一个软件系统往往运作不超过三年就会被重构，因此代码写得太好没有什么必要”。我们暂且不论这一说辞是否有物性（超过三年依然健康发展的软件产品也有不少），但它一定是反人性的，破窗效应告诉我们，当公认的行为准则遭到破坏而又不及时纠正的时候，人们就会潜意识的遵循破坏后的行为准则去行事。如果我们在项目中不做控制和约束，那么在软件从业者的日常工作中就很容易带入这些随心所欲的不良习惯，指望日后能够腾出一段时间专注于还技术欠债，一般都是自欺欺人的说辞罢了。

‍

相反，如果在软件研发工作伊始就进行合理的控制和约束，在团队形成良好的氛围和习惯后，遵循规范和良好的习惯就成了水到渠成的事，并不会带来额外的成本和工作负担。

‍

奖惩分明

‍

无论团队以何种方式组织，激励手段和惩罚手段都是必不可少的管理方式，正确的激励手段能够激发团队的动力和上进心，使其产出最大化；适当的惩罚措施能够让团队及时纠正错误，在未来做得更好。

‍

我们也来看一个案例，某公司的业务发展速度非常快，服务资源消耗大幅上升，公司希望能够提升服务资源利用率，鼓励各业务团队投身服务性能优化，避免简单扩容。于是，公司推行了一个政策，如果在一个业务团队中，有一个服务通过优化手段能够缩容一定的资源，那么这部分资源不会被回收，而是可以用到这个业务团队的其他服务中，甚至还会奖励一部分资源。

‍

这种共享资源配额的激励做法，起到了立竿见影的效果，业务团队不再纠缠于公司为何不直接提供扩容资源，而是想尽办法榨取自身服务性能的可优化之处，以应对业务自然增长带来的服务资源压力。

‍

定期组织一些轻松诙谐的仪式，将奖惩措施融入其中，也是不错的团队激励方式。比如，举办“红烂草莓”的评选活动，根据团队各成员的工作成果和效率，结合高等级评委的打分，评选出若干做得好的“红草莓”和做得差的“烂草莓”，在部门例会时进行颁奖。在聚光灯下，做得好的员工能够保有高度的荣誉感，做得不好的员工也能够有所警醒。这些举措反映到组织建设上，就能带来高效的结果（回想一下霍桑效应）。

‍

鼓励“小轮子经济”

‍

我们经常听到这样一句话：“不要重复造轮子”，这个说法本身是正确的，重复造轮子会导致无谓的人力投入和成本浪费，这是我们需要规避的。但在这里，笔者想输出的一个观点是：“不应一刀切地拒绝重复造轮子”。一个高效的组织，必然是充满活力的组织，有些工具或工作虽然表面上看是重复轮子，但其中有一些局部创新点会为研发效能的提升带来潜在的价值。如果我们从一开始就以避免重复造轮子的名义将这些“小轮子”扼杀在摇篮里，效果往往会适得其反。

‍

那么这个“度”怎么把握呢？建立虚拟团队，作为支持这些小轮子的“孵化器”，是个不错的做法。虚拟团队的组建有助于各组织保持沟通，展示各自的工作内容，简而言之就是“透明化”。同时，对于处于创新萌芽阶段的“小轮子”，可以统一协调资源支持与协助，待这个轮子长大以后，再统一规划抽象到通用工具中。这样，就形成了良性循环，既鼓励小轮子经济，又避免了重复造大轮子。

‍

我们并不否认自动化测试的价值，自动化测试能够取代测试人员的部分工作，但它无法改变“人作为软件工作的一大要素”这一事实，因而也无法消除它。

‍