尊重人性，敬畏物性，研发效能提升从点滴做起
近几年，业界对研发效能的关注度与日俱增，众多工程人员和学者进行了大量的思辩悟，我们对这一“盛世”喜闻乐见，虽然百家争鸣的背后也可能伴随着偏见和纠葛，但恰恰是这些不同的声音，造就了软件研发效能的进步和反思，也启发着我们进行多元化的思考。
我们从工程角度思考研发效能提升，建设了众多易用的工具平台；
我们从组织优化的角度出发，践行了DevOps等实践；
我们从项目管理的角度出发，推崇敏捷开发，并丰富了度量等手段。
从工具到组织，再到管理，我们做了那么多提升研发效能的事，你也许不禁要问：这些工作究竟是如何作用到研发效能的提升上的？软件研发效能的本质到底是“人性”的，还是“物性”的？
毫无疑问，软件研发是一项人类的活动，然而，在对软件研发这一过程进行考察时，这个几乎毋庸置疑的论断，却是许多人共同的思维盲点，这也许是因为，计算机在这一过程中的作用被过分夸大了。我们总是不自觉的认为我们可以依靠计算机解决所有问题，当然，也包括解决我们自己。
这样的例子很多，管理者喜爱推销自动化测试，认为自动化测试能够替代测试人员的工作，继而降低人员的工作强度，但遗憾的是，我从未见过一位管理者能够真正兑现这一承诺，测试人员或是将精力大量投入在维护因业务迭代而无法执行的自动化脚本上，或是投入在分析自动化执行结果上，从全局视角看，测试人员还是那么忙碌、疲倦和无精打采。
事实上，所有企图单方面用技术手段去消除软件研发过程中人的因素的努力，基本都是以失败告终的。
管理者的美梦也许无法成真，但也并不是完全没有益处，它促进了我们的思考。让我们放下手头的键盘和鼠标，从人性和物性的角度，辩证思考一下我们正在从事的这项工作。
软件研发效能的“人性”
软件研发是人类的智力产物，我想没有人会质疑这一点，而这恰恰也是软件研发最令人感到困惑的地方，它难以度量产出、难以管理、难以控制。
那是不是软件研发效能提升工作就成了一门“玄学”呢？这也未必。解铃还须系铃人，既然软件研发工作是人类的活动，那么在此之上的所有效能提升工作，都要顾及人的基本感受和合理需要。毕竟，人类的所有活动也都是为了自身能更好的存在和发展而进行的，这正是对研发效能提升最人性的解读。
如果我们无视人性，那么不要说研发效能提升，恐怕连其中的某些环节都无法做好。最近关于度量的话题比较热门，我们就一起来看一个关于度量的案例吧。
先介绍一个社会心理学名词——霍桑效应（Hawthorne Effect）。霍桑效应起源于1924年至1933年间的一系列实验研究，霍桑实验最初的研究地点位于芝加哥的一间工厂，实验探讨一系列控制条件（薪水、车间照明度、湿度、休息间隔等）对车间员工工作表现的影响。研究人员研究过程中意外发现，各种控制条件对生产效率都有促进作用，甚至当控制条件回归初始状态时，促进作用仍然存在。
很显然，实验假设的各项控制条件并非是唯一的或决定性的生产效率影响因素。对此，实验的制定者及其助手们所做的解释是：受试者对新的控制条件会产生正向反应，即由于环境改变而改变行为，所以生产率的提高并非由实验操控造成的。这种效果就是我们所称的“霍桑效应”。
在实际工作中，笔者曾在团队内做过一次失败的实验，失败的主要原因正是受到了霍桑效应的影响。
当时，笔者的初衷是希望通过实验的方式验证一些新的效能提升策略（如冒烟测试前置、精准测试等）的效果，我们圈定了一部分业务域的团队试用这些新策略，其余团队则维持原有工作模式不变，经过一段时间后统计各个团队的需求交付吞吐量（单位时间内交付需求的数量）进行对比并得出结论。
理论上，我们期望看到试用新策略的团队的需求交付吞吐量相比其他团队有所提升，但实验的结果却令人大跌眼镜，所有团队的需求交付吞吐量都或多或少地提升了，甚至有的团队提升的幅度比尝试新策略的团队还大。这是因为我们的效能提升策略没有起到作用，还是有其他的因素呢？
后来我们发现，即便不进行任何策略改进，仅仅是定期通晒一下各团队需求交付吞吐量的数据，也能起到一定的正面促进作用。这就是典型的霍桑效应的体现，当人们意识到自己正在被关注时，会不自觉地去改变自己的某种行为。团队知道自己正在被统计需求交付吞吐量数据，于是会更重视这方面的工作，从而促进了需求交付的效率。
这个案例充分体现了尊重人性在研发效能中的重要性，逆人性而为，不仅无法提升研发效能，甚至连获得的度量数据都是错误的。我们研发的效能工具平台、推行的流程改进措施、建立的研发技术规范，都应充分考虑人性的因素。此外，渴望尊重和欣赏，是人性的需求之一，适度的关注和赞美能够产生强烈的心理暗示，继而带来效能的提升。从这个层面来讲，合理和适度的座谈会、1对1面谈等形式都是不容小觑的研发效能提升手段，体现了对人性的重视。
软件研发效能的“物性”
在人性的基础上，我们再来思考一下研发效能的物性，究竟有哪些客观存在的规律在制约或促进着研发效能的提升呢？
Intel创始人戈登·摩尔于1965年提出了著名的摩尔定律，有以下三个版本：
1. 集成电路芯片上所集成的电路的数目，每隔18个月就翻一番。
2. 微处理器的性能每隔18个月提高一倍，而同期的价格下降一倍。
3. 用一美元所能买到的计算机性能，每隔18个月翻两番。
摩尔定律揭示了信息技术的进步速度，也预言了行业的发展。在摩尔定律发现长达50多年间，顺应摩尔定律的公司飞速发展，很多公司都成为了业界先驱，而忽略它的公司则举步维艰，无法跟上时代发展的步伐。
不过你是否知道，Google的前CEO埃里克·施密特曾提出过一个与之相对应的“反摩尔定律”，其表述是这样的：“一个IT公司今天要想和18个月前卖掉同样多的、同样质量的产品，那么它的营业额就会下降一半”。
反摩尔定律为所有IT公司敲响了可怕的警钟，因为它一针见血地指出了公司的收入随着时间失效的特点，即在后期一个公司花费同样的劳动只能收到以前一半的收入，公司效益大幅缩水。反摩尔定律，逼迫各公司马不停蹄地跟进摩尔定律所规定的速度，否则就不得不面对被淘汰的危险[4]。
反摩尔定律告诉我们，越迟交付的价值也是越低的价值。这项规律是客观存在的，不为人的意志所转移，它促使人们不自觉的（或者说是被迫的）优化和改进自身工作，尽可能快速地交付高质量的产品。
软件研发模式的变迁就是一个典型的例子。传统的瀑布模型是反“反摩尔定律”的，我们通常说“瀑布”是不敏捷的，因为瀑布模型把开发分成一系列阶段，包含需求、设计、开发、测试等工序，每个功能都需要经历这些阶段之后才能上线。
瀑布模型最大的问题在于，各阶段的划分是完全固定的、线性的，且粒度较粗，大批量的产品功能都需要经历整个周期到最后才能交付，且应对需求变化和风险的能力较弱，最终影响效能。
一种有效的改进手段叫作迭代式开发，即把开发工作拆分成多个迭代，每个迭代交付一部分价值，更早的交付往往意味着更多的价值。就这一点来说，相对于瀑布开发，迭代式开发能做到更小批量的快速交付，从而更早获取更多价值。
敏捷开发将效能提升至另一个高度，也囊括了迭代式开发的一些优点，它是以人为核心、迭代、循序渐进的开发方式。敏捷开发最大的目标之一就是更快地交付价值，这里的“快”指的不是绝对速度，而是更早地交付。
从软件研发模式的变迁，我们可以看到，人们始终在致力于尽快将有效且高质量的产品交付，以追赶摩尔定律的速度，抢占市场先机。
对研发效能提升起到潜移默化影响的“物性”规律还有很多，包括：康威定律（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足够“死板”，不同性情的程序员也很难写出风格迥异的代码。
我们时常会听到这样的说辞：“一个软件系统往往运作不超过三年就会被重构，因此代码写得太好没有什么必要”。我们暂且不论这一说辞是否有物性（超过三年依然健康发展的软件产品也有不少），但它一定是反人性的，破窗效应告诉我们，当公认的行为准则遭到破坏而又不及时纠正的时候，人们就会潜意识的遵循破坏后的行为准则去行事。如果我们在项目中不做控制和约束，那么在软件从业者的日常工作中就很容易带入这些随心所欲的不良习惯，指望日后能够腾出一段时间专注于还技术欠债，一般都是自欺欺人的说辞罢了。
相反，如果在软件研发工作伊始就进行合理的控制和约束，在团队形成良好的氛围和习惯后，遵循规范和良好的习惯就成了水到渠成的事，并不会带来额外的成本和工作负担。
奖惩分明
无论团队以何种方式组织，激励手段和惩罚手段都是必不可少的管理方式，正确的激励手段能够激发团队的动力和上进心，使其产出最大化；适当的惩罚措施能够让团队及时纠正错误，在未来做得更好。
我们也来看一个案例，某公司的业务发展速度非常快，服务资源消耗大幅上升，公司希望能够提升服务资源利用率，鼓励各业务团队投身服务性能优化，避免简单扩容。于是，公司推行了一个政策，如果在一个业务团队中，有一个服务通过优化手段能够缩容一定的资源，那么这部分资源不会被回收，而是可以用到这个业务团队的其他服务中，甚至还会奖励一部分资源。
这种共享资源配额的激励做法，起到了立竿见影的效果，业务团队不再纠缠于公司为何不直接提供扩容资源，而是想尽办法榨取自身服务性能的可优化之处，以应对业务自然增长带来的服务资源压力。
定期组织一些轻松诙谐的仪式，将奖惩措施融入其中，也是不错的团队激励方式。比如，举办“红烂草莓”的评选活动，根据团队各成员的工作成果和效率，结合高等级评委的打分，评选出若干做得好的“红草莓”和做得差的“烂草莓”，在部门例会时进行颁奖。在聚光灯下，做得好的员工能够保有高度的荣誉感，做得不好的员工也能够有所警醒。这些举措反映到组织建设上，就能带来高效的结果（回想一下霍桑效应）。
鼓励“小轮子经济”
我们经常听到这样一句话：“不要重复造轮子”，这个说法本身是正确的，重复造轮子会导致无谓的人力投入和成本浪费，这是我们需要规避的。但在这里，笔者想输出的一个观点是：“不应一刀切地拒绝重复造轮子”。一个高效的组织，必然是充满活力的组织，有些工具或工作虽然表面上看是重复轮子，但其中有一些局部创新点会为研发效能的提升带来潜在的价值。如果我们从一开始就以避免重复造轮子的名义将这些“小轮子”扼杀在摇篮里，效果往往会适得其反。
那么这个“度”怎么把握呢？建立虚拟团队，作为支持这些小轮子的“孵化器”，是个不错的做法。虚拟团队的组建有助于各组织保持沟通，展示各自的工作内容，简而言之就是“透明化”。同时，对于处于创新萌芽阶段的“小轮子”，可以统一协调资源支持与协助，待这个轮子长大以后，再统一规划抽象到通用工具中。这样，就形成了良性循环，既鼓励小轮子经济，又避免了重复造大轮子。
参考
[1] 我们并不否认自动化测试的价值，自动化测试能够取代测试人员的部分工作，但它无法改变“人作为软件工作的一大要素”这一事实，因而也无法消除它。
[2] Gerald M. Weinberg. 程序开发心理学（银年纪念版）[M]. 电子工业出版社, 2015:2-3
[3] 车文博. 心理咨询大百科全书[M]. 浙江科学技术出版社, 2001:183
[4] 反摩尔定律[J]. 中国经济和信息化, 2011(18):76-76.
▊《软件研发效能提升之美》
吴骏龙 茹炳晟 著
如果你想了解更多软件研发效能的系统知识和趣闻轶事，或正在从事软件研发效能相关工作，希望进一步深造学习，请不要错过这本《软件研发效能提升之美》。
本书由两位行业知名专家联袂编写，汇聚了行业前沿的研发效能提升实践与案例，同时提炼出大量方法论和经验反思，以诙谐幽默而又不失严谨详实的风格，全方位多角度覆盖研发效能领域的核心知识，深入浅出，发人深思。收录作者行业知名大会热门演讲精华内容，集合研发效能提升的前沿技术与理念，40余名行业专家与企业高管倾情推荐。
做好研发效能提升是不容易的，我们需要的不仅仅是前沿技术的加持，更重要的是理念的更新换代和优秀实践的传承，而这些，正是本书所希望带给读者的核心价值。我们不仅会告诉你“怎么做”，还会告诉你这么做的“缘由和故事”，呈现所有人都能学得会且带得走的研发效能实践。这样，也许若干年后你重读本书，依然能够时读时新，有全新的收获。