mod

极客时间专栏/研发效率破局之道/研发效能综述/01 | 效能模型：如何系统地理解研发效能？.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="01 | 效能模型：如何系统地理解研发效能？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/65/93/65974b88cd7ad1d8f788f889a3baad93.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊什么是研发效能，以及研发效能的模型，这些内容是理解整个专栏的基础。
+
+今年的3月26日，一位昵称为996icu的用户，在GitHub上创建了996.ICU项目，自此996这个话题被推上了风口浪尖。目前，这个项目已经拿到了24万多颗星。朋友们也常常问我：硅谷的公司有没有996？
+
+其实，在硅谷，很少有公司要求996。不过，在初创公司，因为业务紧张、同事间的竞争，加班也很常见。但是，硅谷和国内的公司有一个很大的区别，就是硅谷的公司一般是任务驱动，只要完成任务就行，不管你花了多少时间。而国内很多实行996的公司不仅仅是要求完成任务，更强调工作时长。但其实，专注时长的这种操作在软件开发行业是不合理的，因为长期加班不能保证持续的高效产出。
+
+从我以及身边许多开发者的经验来看，每天能够高效地产出代码五六个小时，已经相当不错了。短期突击加班会有效果，但如果长期加班，通常效率、质量会下降，产生了Bug就要花费更多的精力去修复。如果这些Bug发布到了用户手上，损失就会更大，得不偿失。
+
+长期加班还会出现无效加班的结果。比如，有个朋友在一家国内一流的互联网公司工作，据他反馈，公司实行996，很多人加班其实是磨洋工，低效加班非常明显。可想而知，其他推行996工作制的公司，大概率也会存在这种问题。
+
+**那么，长期加班效果不好，面对激烈竞争，我们到底应该怎么办呢？**在我看来，这个问题还是要从软件开发本身的特点来解决。
+
+## 为什么要关注研发效能？
+
+软件开发是一个创造性很高的过程，开发者之间的效率相差很大。就比如，10x程序员的生产效率可以达到普通开发者的10倍。其实，不仅是个人，团队间的效率相差也很大。**所以，相比工作时长而言，公司更应该关注的是研发效能**。
+
+接下来，我们再回顾一下我在开篇词中给研发效能的定义：
+
+> 
+研发效能，是团队能够持续为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三方面。简单来说，就是开发者是否能够长期既快又准地产生用户价值。
+
+
+硅谷的很多知名公司，比如Google、Facebook、Netflix等，在研发效能上做得很好，是研发效能的标杆。这，也是它们业务成功的重要因素。
+
+以我在开篇词中提到的Facebook的部署上线流程为例。Facebook在2012年达到10亿月活的时候，部署人员只有3个，达到平均每个人支撑3.3亿用户的惊人效率。举个形象的例子，如果全中国每一个人都使用Facebook，那最多只要5个部署人员就够了。
+
+Facebook做到这一点的基础，就是不断提高研发效能。还是以上面的部署流程为例，原来的部署已经非常高效，但是在2017年，Facebook又引入了持续部署，做了进一步的优化，实现了更高效率的部署上线。试想一下，如果Facebook选择堆人、堆时间的话，那需要增加多少人、多少加班才能做到呢？
+
+**所以在我看来，如果研发效能提不上去，单靠加人、加班根本不可能解决问题。**
+
+**注重研发效能的另一个巨大好处**，是开发者能够聚焦产出价值，更容易精进自己的技术。于是，团队容易建立起好的氛围，进而又能促进生产效率的提高，形成良性循环，支撑持续的高效开发。
+
+所以，国内公司近一两年越来越注重提高研发效能，许多公司甚至专门成立了工程效率部门。但是，在真正开展研发效能提升工作时，它们却常常因为**头绪太多无从下手，或者对方法了解不够，导致画虎不成反类犬的效果**。这，又和软件研发的高度创造性和灵活性紧密相关。
+
+自软件行业诞生起，开发者们就发挥聪明才智，不断创造新的方法、流程和工具来适应和提高生产效率。互联网产业爆发以来，这一趋势更是明显：从最初的瀑布研发流程到敏捷到精益，从持续集成到持续发布到持续部署，从实体机到虚拟机到Docker，从本地机器到数据中心再到云上部署，从单体应用到微服务再到无服务应用。新的工具、方法，可谓层出不穷。
+
+面对如此多的选择，如果能处理好，则开发体验好，产品发布速度快，研发过程处于一个持续的良性发展情况。但处理不好，就会事倍功半，出现扯皮、重复劳动、产品质量不好、不可维护的情况。
+
+微服务的不合理引入就是一个典型的例子。自从亚马逊成功大规模地应用后，微服务逐渐形成风潮，很多公司在不清楚适用场景的情况下盲目采用，结果是踩了很多坑。
+
+比如，我见过一个初创公司，在业务还没开展起来的时候，一上来就采用微服务，因为没有要求一致的技术栈，也没有限制服务的大小，于是开发人员怎么方便怎么做，只考虑局部优化而忽视了全局优化。半年下来，20人的开发团队搞出了30多个服务和5种开发语言。服务之间的调用依赖和部署上线越来越复杂，难以维护，每次上线问题不断，经常搞通宵才能让服务稳定下来。同时，知识的共享非常有限，有好几个服务只有一个人了解情况，一旦这个人不在的时候这个服务出现问题，解决起来就基本上成了“不可能的任务”。这样的错误使用微服务的公司非常普遍。
+
+那，到底怎样才能有效地提高研发效能呢？硅谷的业界标杆公司又是怎么做到高效能的呢？
+
+## 只有深入研发活动的本质，才能提高效能
+
+我的建议是，提高研发效能，需要**深入了解研发活动的本质，从纷乱的表象和层出不穷的方法中，看到隐藏的模型，找到根本原则**，然后从这些原则出发，具体问题具体分析，找到合适的方法。这样做的原因是，软件研发很灵活，在实践的时候总会遇见各种不同的情况。越是灵活的东西，就越需要理解其本质，这样才能做到随机应变。
+
+在Facebook的时候，我们做事时都遵循一些基本原则。比如，有一个原则是“**不要阻塞开发人员**”，贯穿在公司的很多研发和管理实践中。接下来，我给你举两个具体的应用场景，来帮助你理解这个原则。
+
+**第一个应用场景是，本地构建脚本的运行速度要足够快**。开发人员在自己的开发机器上写完代码之后，都要运行这个脚本进行构建，把新做的改动在自己的开发机器沙盒环境上运行起来，以方便做一些基本检查。
+
+这个操作非常频繁，所以如果它的运行时间太长，就会阻塞开发。因此，确保这个脚本的快速运行就是内部工具团队的一个超高优先级的任务。我们对每次脚本的运行进行埋点跟踪，当运行时长超过1.5分钟后，就会停下手中的工作，想尽一切办法给这个本地构建加速。
+
+**第二个应用场景是，商用软件的采购**。对一定数额下的软件购买，开发人员可以自行决定，先斩后奏。而且那个数额还蛮高的，覆盖一般的软件完全没问题。
+
+我个人就经历过两次在晚上加班时，要购买一个商业软件的情况。如果等主管审批，就需要到第二天。但，公司信任工程师能够在这样的情况下做出利于公司的决定，所以我可以直接购买并使用。这样一来，除了能提高这几个小时的开发效率外，更重要的是，我觉得自己拥有信任和权力，工作积极性更加高涨。
+
+这两个应用场景差别很大，却都是基于“不要阻塞开发人员”这个原则。Facebook之所以会有这个原则，正是因为它认识到了，**开发流程的顺畅是生产优质软件的关键因素，只有这样才能最大程度地释放开发者的创造性和积极性**。相比之下，很多公司更注重强管理下的流程和制度，而忽略了开发的顺畅，结果是开发人员工作起来磕磕绊绊，又谈何高效率呢。
+
+看到这里你会说，我已经很清楚地知道，要想提高研发效能，就必须理解软件开发的本质。那么，软件开发的本质到底什么呢？
+
+接下来，**我就和你探讨一下软件开发的本质特点，然后基于这些特点，搭建出一个研发效能的模型，希望你可以灵活运用，找到提高研发效能的主要着力点。这个思路，将是贯穿整个专栏的主线索。**
+
+## 研发效能的模型是什么？
+
+在我看来，**软件开发本质上就是一条超级灵活的流水线**。这个流水线从产品需求出发，经过开发、测试、发布、运维等环节，每一个环节的产出流动到下一个环节进行处理，最后交付给用户。
+
+<img src="https://static001.geekbang.org/resource/image/3a/b7/3afb132da674578627c30272dd8504b7.png" alt="">
+
+另外，这条流水线的每个环节都还可以细分。比如，本地开发环节可以细分为下面几个部分：
+
+<img src="https://static001.geekbang.org/resource/image/44/28/44e048f968b603e49136b10f5dbdf728.png" alt="">
+
+这种流水线工作方式，在传统的制造业中很普遍，也已经有了很多经验和成功实践。最典型的就是汽车生产中使用的丰田生产体系（Toyota Production System，TPS）。所以，**我们可以参考传统制造行业的经验来提高效能**。
+
+事实上，瀑布模式就类似于传统流水线的处理方法：它强调每个环节之间界限分明，尽量清晰地定义每一个环节的输入和输出，保证每一个环节产出的质量。但，**和传统制造业相比，软件开发又具有超强的灵活性，<strong>体现在以下4个方面**。</strong>
+
+1. 最终产品目标的灵活性。传统流水线的目标确定，而互联网产品的最终形态通常是在不断地迭代中逐步明确，相当于是一个移动的标靶。尤其是最近几年，这一灵活性愈发明显。比如，在精益开发实践中，常常使用MVP（最小可行性产品，Minimal Viable Product）来不断验证产品假设，经过不断调整最终形成产品。
+1. 节点之间关系的灵活性，比如流水线上的多个节点可以互相融合。DevOps就是在模糊节点之间的边界，甚至有一些实践会直接去掉某些环节，或者融入到其他环节当中。
+1. 每个节点的灵活性。每一个生产环节都会不断涌现出新的生产方式/方法。比如测试，最近十多年就产生了测试驱动开发、Dogfood（狗粮测试）、测试前移等方法；最近又出现的测试右移，开始强调在生产环境中进行测试。
+<li>每个节点上的开发人员的灵活性。跟传统制造业不同，流水线上的每一个工作人员，也就是每个开发者，都有很强的灵活性，主要表现在对一个相同的功能，可以选择很多不同的方式、不同的工具来实现。<br>
+比如，之前我在Facebook做后端开发的时候，同样一个代码仓，有的同事使用命令行的编辑环境VIM/Emacs，有的使用图形界面IDE，有的使用WebIDE；在实现一个工具的时候，大家可以自己选择使用Python、Ruby或者PHP。这其中的每一个选择，都很可能影响效能。</li>
+
+基于这些特点，我们可以从以下4个方面去提高研发效能。
+
+<img src="https://static001.geekbang.org/resource/image/68/51/68f278d53b0441413842539ed8919c51.png" alt="">
+
+1. 优化流程，主要针对特点1和2，也就是最终产品目标的灵活性和节点间关系的灵活性，进行优化。具体来说，针对最终产品目标的灵活性，主要是提高流程的灵活性，让它能聚焦最终产生的用户价值，以终为始地指导工作，击中移动的标靶。而针对节点之间关系的灵活性，则主要聚焦流水线的顺畅，以保证用户价值的流动受到的阻力最小。
+1. 团队工程实践，主是针对特点3，也就是每个节点的灵活性进行优化，聚焦每一个生产环节的工程实践进行提高。
+1. 个人工程实践，主是针对特点4，也就是每个节点上开发人员的灵活性，来提高个人研发效能。争取让每个开发人员都能适当地关注业务、以终为始，同时从方法和工具上提高开发效率，实现1+1&gt;2的效果。
+1. 文化与管理。任何流程、实践的引入和推广，都必须有合理的管理方法来支撑。同时，文化是一个团队工作的基本价值观和潜规则。只有建立好文化，才能让团队持续学习，从而应对新的挑战。所以，要提高效能，我们还需要文化和管理这个引擎。
+
+优化流程、团队工程实践、个人工程实践，以及文化和管理，就是我们提高研发效能需要关注的4个方面，也就是我们所说的研发效能模型。
+
+在接下来的文章中，我会以这个模型为基础，从以上这4个方向与你介绍硅谷公司，尤其是我最熟悉的Facebook的成功实践，并着重向你讲述这些实践背后的原理。因为只有理解了这些原理和原则，我们才有可能在这个超级灵活和高速发展的软件开发行业里见招拆招，立于不败之地。
+
+## 总结
+
+在今天这篇文章中，我和你再次强调了研发效能是团队能够持续为用户产生有效价值的效率，包括有效性、效率和可持续性3个方面。
+
+而关于如何提高效能，我的建议是深入了解研发活动的本质，从纷乱的表象和层出不穷的方法中，看到隐藏的模型，找到根本原则，然后从这些原则出发，具体问题具体分析，找到合适的方法。
+
+最后，我借鉴传统制造业流水线的形式，并结合软件开发的特定灵活性，总结出了研发效能的模型，主要包括优化流程、团队工程实践、个人工程实践、管理与文化。专栏的后续内容，我将分为这4大模块，帮助你提高团队和个人的研发效能。
+
+其实，研发效能对于硅谷的公司和个人来说，已经是常识，而我在美国工作的10多年，也已经习惯了这种工作方式。回国之后，我深入了解了国内的开发情况，对效能关注不到位的现状颇为吃惊。因为这不符合软件开发这个行业的基本特性，也限制了国内软件行业的发展。
+
+同时，我也对国内开发人员的生存环境，感到些许遗憾。本来软件开发是一个可以充分发挥创造性的、有趣的行业，技术的发展有无尽的空间。但是，开发人员却常常被业务拖着跑，技术发展和创造性都被限制住了。另外，因为拼时长的做法，也伤害了开发者的身体健康和家庭关系。
+
+正是因为这些惊讶和遗憾，我将这十几年对研发效能的理解与实践，做了一次系统梳理，于是就有了今天提到的研发效能模型。我希望这种系统化的模型方法，能够为国内软件团队的效能提升提供一些参考和引导，也希望能够提升开发者个人的技能，以节省出时间来体会研发的快乐，提高生活的幸福感。
+
+## 思考题
+
+你有见过996对团队和产品造成伤害的具体事例吗？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/研发效能综述/02 | 效能度量：效果不好甚至有副作用，怎么回事？.md

@@ -0,0 +1,123 @@
+<audio id="audio" title="02 | 效能度量：效果不好甚至有副作用，怎么回事？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/59/af/5947c186d71f13281914a84479f059af.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊研发效能的度量。
+
+在和技术管理者，尤其是高层管理者聊起研发效能的时候，常常提起效能的度量这个话题。管理学大师彼得 · 德鲁克（Peter Drucker）曾经说过，“一个事物，你如果无法度量它，就无法管理它”（If you can’t measure it, you can’t manage it）。要想提高研发效能，自然要首先解决效能的度量的问题。
+
+在软件研发过程中，数据驱动的手段被大量采用，比如说通过使用漏斗指标和A/B测试，用数据来指导产品的方向。按理说，软件开发行业是数据驱动的高手，用数据驱动来理解研发效能应该早被研究透了啊。
+
+但事实上，效能的度量却是一个出了名的难题，至今没有哪个公司敢号称已经找到了效能度量的完美答案。不仅如此，绝大部分软件公司在使用研发效能度量这个工具时，不但没有起到正向作用，还伤害了产出和团队氛围。
+
+所以，在今天这篇文章中，我就与你一起看看研发效能度量到底是什么、常见错误，以及度量困难的原因。
+
+## 研发效能度量的定义和作用
+
+首先，我来介绍一下效能度量的定义和作用。
+
+研发效能的度量代表一组可量化的数据或参数，用来跟踪和评估开发过程的“健康”状况。 换句话说，**研发效能的度量，从应用程序开发的生命周期中获取数据，并使用这些数据来衡量软件开发人员的工作效率**。我们希望通过这样的度量，能够根据客观的数据而不是个人的主观意见去决策，从而实现以下几点：
+
+1. **跟踪团队的表现、提高团队的绩效。**通过确定研发效能指标，公司可以明确团队和成员的工作预期，从而使得开发人员能够目标性更清晰地投入研发。同时，这些生产指标可以作为“晴雨表”，帮助团队定位影响工作效率的不良因素，从而帮助团队消除这些因素，最终达到团队更快乐、绩效更高的目的。
+1. **提高项目计划的精确度。**团队负责人可以通过度量来估算一个需求端到端的成本，包括收集成本、设计系统成本、开发测试成本，以及运维成本等，来了解每项活动在项目总成本中的占比，从而更好地确定这些活动的优先级。同时，我们可以了解哪些步骤有较大风险和不确定性，从而提高预测项目进展的精准度。
+1. **了解流程是否高效，寻找需要改进的关键领域。**我们可以衡量进行每项研发活动所需的时间，并估算其对质量和生产效率的影响，然后比较成本和收益，最终确定哪些步骤是高效的，以及哪些步骤是需要改善的。我们还可以对不同的实践进行A/B测试，以此来选择更好的方法。
+
+提高团队绩效、提高计划精确度，以及寻找关键的待改进领域，这三个因素的结合有助于简化工作流程，发现瓶颈，帮助团队持续改善现有产品的生命周期，从而更高效地生产出质量更好的产品。
+
+## 效能度量的错误案例
+
+因为上述作用，绝大多数公司都非常重视研发效能的度量，并且基本上所有公司都或多或少地采用了度量。但遗憾的是，能够将其用好的公司少之又少，而且我见到的公司中还存在大量误用的情况。
+
+接下来，我与你分享一些真实案例，我们一起来看看它们错在哪里，以及可以如何调整。
+
+### 案例1：全公司范围内推行一套效能度量指标
+
+某大型公司为了提高效能，专门成立了一个不小的团队，通过详细调研，制定了一组研发效能度量指标，并引入和开发了相应的工具。客观来讲，这些度量方式的质量很高。
+
+准备就绪后，这个公司找了几个团队做试点，把这些效能度量数据作为参考提供给它们使用。三四个月下来，试点效果不错，这几个团队的产出速度有了一定的提高。于是，公司高层决定在全公司范围内推行这套方案。
+
+但，随着大范围的推广，一些团队发现，它们的研发流程跟试点团队差别较大，需要花费相当多的时间去收集度量数据，受益却不明显，甚至是得不偿失。
+
+更极端的情况是，有一个团队的开发环境和这套效能度量工具的环境差别实在太大，所以不得不专门为这个工具部署了一个环境。然后每周六，他们就要到这个环境里，为度量系统提供数据，还常常被迫提供一些“假数据”，以满足度量系统的需求。
+
+因此，这些团队觉得这套方案并不适合自己，公司内逐步出现了些许反对声音。但是，公司推进这套流程的态度非常强硬，为了顺利推进，还把这套流程与团队绩效绑定到了一起。一旦某个团队的指标未能达到要求，就直接实行绩效扣分。由此，效能度量的负面作用逐渐凸显。大量团队为了好的绩效，而被迫去玩数字游戏。
+
+全公司范围推行这套方案的一年多，可以说是怨声载道。明明是一套高质量的度量系统，却阻碍了团队业务的发展，并严重伤害了员工的积极性。直至最后这个实际情况被反馈到一位高管那里，这套度量系统才被完全取缔。
+
+### 案例2：一个中型公司推行质量方面的指标
+
+一个500人左右的公司，公司的组织架构按照职能进行水平划分，并没有进行矩阵式管理。为了提高公司的产品质量，QA团队提出了一组软件质量方面的度量指标，包括Bug严重性定义、每一个发布里不同级别的Bug的未解决率，以及上线的一些质量流程。QA团队得到了公司高层的支持，强制推行这些指标。
+
+这些指标针对的主要是开发活动，但开发团队却认为，这些度量用处不大。他们认为，公司研发过程中的真正问题在于产品定义变化过快，常常是在冲刺开始后还不断更改需求。这就导致开发和测试团队即使拼命加班还常常错过发布日期，产品的Bug也不少。所以，开发团队提出，真正应该度量的是产品需求的稳定性。但是，公司高层认为需求变化是为了满足用户需求，所以没有批准开发团队的这个要求。
+
+结果是，研发人员觉得公司效能度量只是用来束缚他们的，根本不能帮助他们工作，于是工作积极性下降，离职率上升。同时，产品质量也并没有因为这些度量指标的推行而提高。直到我写下这篇文章的时候，这个公司还是这个情况。
+
+### 案例3：某创业公司聚焦度量开发、测试、上线准确度等指标
+
+一个由10多个人组成的、拿到了Pre-A投资的创业公司，正处在研发产品寻找市场吻合度的阶段。掌权的CEO和产品副总坚信数据驱动，于是对研发流程定义了严格的度量和指标，比如App上线周期准时率、Bug的关闭速度、性能参数，等等。
+
+整个团队很专业，也很敬业。他们花了很多精力去严格完成这些度量指标，做到了绝大部分情况下准时、高质量地上线产品。但是，CEO和产品副总并不是产品专家，只关注了开发过程中的数据，却没有收集其他步骤的数据去快速试错和寻找产品方向。
+
+结果就是，虽然产品的每一个发布都很准时，质量也非常高，但因为公司在寻找市场需求吻合度方面动作迟缓，导致用户增长缓慢。因此，一年半以后，资金耗尽，投资人失去信心，公司倒闭。
+
+这3个案例只是不同规模公司的几个典型场景，类似的失败案例数不胜数。那么，上面这些案例的问题出在什么地方？效能度量为什么这么难？
+
+## 效能度量被大量误用，问题究竟出在哪儿？
+
+**研发效能难以度量的最根本原因在于**，软件开发工作是一项创造性很强的知识性工作，非常复杂且伴随有大量不确定因素。
+
+比如，软件产品的需求变化很快，需求文档的更新常常滞后于工程实现，甚至有的敏捷方法论提倡完全抛弃需求文档。
+
+又比如，软件产品的实现方式有很大的不确定性。一个相同的功能，可以采用多种语言、框架、平台，使用各种不同的研发流程生产出来。在这种情况下，我们很难通过度量来衡量这些不同研发方法和中间过程的优劣。
+
+**面对这样的一个复杂系统，我们不可能覆盖其全部参数。而如果这时，研发人员的利益和这个度量结果相关，那么他就很可能会通过“做数字”来欺骗度量系统。**
+
+关于这个主题，美国著名学者罗伯特 · 奥斯汀（Robert Austin）写过一本书，叫作[《衡量和管理组织绩效》(Measuring and Managing Performance in Organizations)](https://amzn.to/2IxXjR9) 。他在这本书中给出的结论是，如果你不能度量一个事物的所有方面，那就不要去度量它。否则，你将得到“做数字”的欺骗行为。
+
+这里有一组有名的Dilbert漫画，讲的是一个公司宣布使用Bug修复数量做度量，每修复一个Bug奖励10美元，消息一出，开发人员欢呼雀跃。一个程序员当场表示，当天下午就要给自己写出一辆汽车，因为他很容易就可以写出很多简单的Bug，然后马上去修复它们。
+
+通过这个例子，我想要和你说明的重点是：度量与绩效挂钩，结果是指标上去了，却没给软件产品带来任何好处。
+
+<img src="https://static001.geekbang.org/resource/image/58/89/58261fef0dd2ecaab2a986f0b21e1e89.png" alt="">
+
+> 
+备注：图片来自[https://dilbert.com/strip/1995-11-13](https://dilbert.com/strip/1995-11-13)
+
+
+而我刚刚和你举的大型公司全公司范围内推行一套度量指标的案例，正是犯了度量与绩效挂钩的错误，这种情况下，很容易出现“做数字”的不良行为。这也是使用度量时最常见的错误，我们一定要留意。
+
+**研发效能难以度量的第二个原因**，和上面提到的根本原因相关，但有其特殊性。很多公司有竖井（silo）存在，所以常常会把注意力放到某一两个竖井上，进行局部优化。但是，局部优化并不代表全局优化，甚至会让全局恶化。
+
+上面那个中型公司推行质量方面指标的案例，就是在进行局部优化，不但没能提高产品质量，反而导致员工积极性受损，同时影响了团队之间的关系。
+
+这样的问题，在按职能划分团队的公司很容易出现。因为在这样的组织划分下，更容易出现竖井，自然就更容易按照竖井来考虑小团队的表现。如果你的公司基于职能划分，一定要多加留意。
+
+**研发效能难以度量的第三个原因在于**，度量指标一般用来度量软件产品的生产过程和产品质量，但是公司真正需要关注的是产品能否解决用户问题，也就是说能否产生用户价值。技术产品输出和用户价值输出之间的沟壑难以打通。
+
+上面案例中那家创业公司聚焦度量开发测试指标，就是犯了这样的错误。产品质量再好，发布再准时，如果没有用户价值也是白费工夫。
+
+当然了，研发效能难以度量还有一些其他原因，比如：
+
+- 度量数据的收集难易程度不同，人们倾向拿容易收集的数据去关联效率，但事实上难以收集的数据对度量可能才真正有用。比如说代码行数容易衡量，但是用处很小。相比之下，产品用户价值的度量要困难得多，但用处却大得多。
+- 软件开发和实践有一个滞后效应。比如，在团队中引入代码审查，在刚开始实行的时候，总体效率会出现短时间的下降，一两个月后才会逐步显现正面效果。那么，你现在要怎么度量它才好呢？
+
+## 总结
+
+在今天的分享中，我给出了效能度量的定义及作用，列举了三个典型的失败案例，并通过这几个例子和你详细分析了度量困难的几个主要原因。
+
+研发效能的度量一直以来都是个难题，很多业界大佬也都发表过“研发效率不可度量”的观点。比如，马丁 · 福勒（Martin Fowler）在一篇叫作“[无法衡量生产效率”](https://martinfowler.com/bliki/CannotMeasureProductivity.html) (CannotMeasureProductivity)的文章中指出：这是我认为我们必须承认无知的地方。
+
+周思博（Joel Spolsky）在一篇名为“[飙高音](https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/)”（做到最好，Hitting the High Notes）的文章中写到，衡量程序员的工作效率相当困难，原因如下：
+
+- 几乎任何你能想到的指标（比如，调测过的代码行数、功能点、命令行参数的个数）都很容易被“做数字”；
+- 我们极少要求两个程序员做完全相同的事情，所以很难获取大型项目的有价值度量数据作为参考。
+
+那是不是说在研发软件时，我们就不能使用度量效能的方法来指导工作了呢？如果是的话，这对于软件团队管理者而言，将会是一个难以接受的事实。
+
+这个问题的答案，我们就留到下一篇文章再揭晓吧，敬请期待。
+
+## 思考题
+
+你在工作中有没有经历过研发效能度量的失败案例？如果有的话，你觉得失败的原因是什么？关于度量谜题怎么解决，你有没有什么建议？
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+

极客时间专栏/研发效率破局之道/研发效能综述/03 | 效能度量：如何选对指标与方法，真正提升效能？.md

@@ -0,0 +1,176 @@
+<audio id="audio" title="03 | 效能度量：如何选对指标与方法，真正提升效能？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/19/01/19af57fa963560b23e3749d4d8d12701.mp3"></audio>
+
+你好，我是葛俊。今天，我来和你聊聊如何正确使用效能度量。
+
+在上一篇文章，我给你介绍了效能度量的定义、作用，以及几个使用误区。我们先简单回顾一下：
+
+- 软件系统异常复杂，度量指标无法覆盖其所有参数，从而容易被“数字游戏”欺骗。
+- 竖井指标的提高不等于全局指标的提高，局部优化不等于全局优化。
+- 研发效能度量指标一般用来衡量软件产品的生产过程和产品质量，但公司真正需要关注的是能否产生用户价值。这两者之间存在着难以跨越的鸿沟。
+
+正是因为这种种看似难以解决的问题，业界甚至有人认为研发效能的度量是一个无解的问题。但我并不这样认为。如果使用得当，效能度量可以给公司的研发带来非常大的好处。
+
+举一个真实的例子。国内一个大概20人的研发团队，研发流程混乱，产品发布经常推迟，但是大家都不清楚问题出在哪儿。于是，团队负责人决定引入数据驱动开发：项目经理正式跟踪研发过程中每部分的耗时，并在功能发布后复盘。复盘时大家发现，整个研发过程耗时分布如下：
+
+- 开发耗时1周；
+- 联调耗时1周；
+- 测试、发布耗时1周。
+
+大家一致认为联调耗时一周，是最需要优化的地方。于是对联调部分进行深入讨论，发现根本原因在于前后端沟通不顺畅：常常出现后端改动API，但前端不知情的情况，这是耗时最主要的原因。
+
+为解决这个问题，团队最终引入了一个Mock Service，并规定：在每个功能开发之前，前后端要规定好API格式，并由后端产生一个Mock Service，让前端从一开始就有明确的API可以调用。后端如果要改变API格式，必须通知整个团队，并立即更新这个Mock Service。这就最大程度地避免了沟通不畅造成的时间浪费。
+
+两个月以后，这个团队的平均开发周期有了明显改善，分布如下：
+
+- 定义和生成Mock Service耗时1天；
+- 开发耗时1周；
+- 联调耗时1天；
+- 测试、发布耗时3天。
+
+可以看到，虽然定义和生成Mock Service需要额外的一天，但是联调周期缩短了4天，测试、发布周期也缩短了2天。所以，整个开发周期从3周降到2周，效果显著。
+
+在这个成功使用度量的例子中，该团队主要做对了以下三点：
+
+- 从全局的角度考虑度量指标，度量产品生产周期中各个阶段的数据，而不是直接查看某个竖井；
+- 使用度量来寻找问题而不是用来做绩效考评；
+- 使用度量来检验改进措施的效果。
+
+从我的经验看，成功使用度量的关键在于：首先要对度量的分类有一个比较系统的了解，然后根据效能度量的特点，以及自己团队的目标来选取度量指标和方法。
+
+## 效能度量的指标分类
+
+在我看来，要真正发挥度量的作用，找到合适的度量指标，必须先对指标进行分类。我推荐从团队和个人这两个维度对度量指标进行分类，其中团队维度中又分为速度、准确度和质量3类，所以一共是4类。
+
+- **速度**：天下武功，唯快不破，速度指标主要用来衡量团队研发产品的速率。比如，前置时间，从任务产生到交付的时长。
+- **准确度**：关注产品是否跟计划吻合，跟用户需求吻合，能否提供较大的用户价值。一个例子是功能的采纳率，也就是有百分之多少的用户使用了功能x。
+- **质量**：如果质量有问题，产品的商业价值会被大打折扣。质量包括产品的性能、功能、可靠性、安全等方面。
+- **个人效能**：个人开发过程中的效率指标，比如开发环境生成速度、本地构建速度等。
+
+根据经验，我总结了一张导图，展示了这4个方面的度量指标，供你参考。可以看到，我一共给出了40多个指标，从名字上可以看出它们大概要度量什么。
+
+在后面的度量指标推荐时，我也会与你讨论其中几个指标。如果你不清楚哪条指标的具体含义，可以自行查阅，或者留言给我。另外，你现在只需要对这些指标有个整体概念，用到时再回过头深入研究，选出适合自己的就可以了。
+
+<img src="https://static001.geekbang.org/resource/image/96/8f/967061c8d8d4ee26a34b5e7411fcf28f.png" alt="">
+
+接下来，我就直接和你推荐度量效能的一个原则和四个使用方法。
+
+## 效能度量的原则
+
+效能度量不与绩效挂钩，是正确使用效能度量最重要的一点，再怎么强调也不为过。所以，我向你推荐的效能度量的原则就是：**效能度量不要与绩效挂钩，而应该作为参考和工具，帮助团队提高效能。**
+
+因为无法覆盖100%的度量指标，把度量与绩效挂钩就一定会产生“做数字”的现象。这时，使用效能度量非但起不到正面效果，还会对公司和团队造成伤害。管理者常常倾向于使用度量与绩效挂钩这种方法，是因为它能具体到数字方便管理。这种错误，我们一定要注意避免。
+
+**如果你只能记得这篇文章的一句话，那我希望这句话是“效能度量不要与绩效挂钩”。**
+
+Facebook就刻意避免把效能度量跟绩效挂钩。比如，代码审核相关的效能度量页面，并没有包括审核的提交个数、代码审核的时长、代码审核通过率这些常见指标。
+
+如果有团队提出要获取这些数据，那么我们工具团队只会提供一些脚本，由团队主管自己去获取所需数据，而且获取的方式并不那么方便。同时，团队成员也不能在Phabricator网站上直接看到这些数据。
+
+这是一个比较典型的主动避免度量，从而避免它与绩效挂钩的例子。
+
+不能把效能度量与绩效挂钩，那怎样才能使用度量提高效率呢？答案是：**提供度量作参考和工具，帮助团队提高效能。**
+
+度量一旦与绩效脱离关系，就可以作为重要参考和工具，帮助团队持续进步。比如，下面这些度量指标:
+
+- 缺陷密度，可以让团队了解产品质量的走向。
+- 新旧Bug占比，一定程度上可以反映技术债的严重程度。
+
+即使是代码行数这样臭名昭著的度量指标，如果只是用作参考，都可以帮助团队和成员提高。
+
+在Facebook，有超过4套的数据展示面板工具。这些面板工具使用起来非常灵活，开发人员可以定制面板，展示对自己有价值的效率度量，比如上线前高优先级Bug数、未完成Bug数、燃尽图等。我们每个团队都是**主动**使用这些面板，来帮助团队达成业务目标。
+
+下面，我就来向你推荐4个度量使用方法。
+
+## 效能度量的推荐方法
+
+### 第一，目标驱动，度量对的事
+
+提供用户价值是公司存在的根本，因此与之相关的指标是最最重要的。这一点非常好理解。从这个角度来看，以下几个相关度量指标比较有效：
+
+1. 净推荐值(Net Promoter Score，NPS)，是通过调研了解用户满意度，实用性很强。如果你不了解的话，可以看一下[这篇文章](https://zhuanlan.zhihu.com/p/38117396)对NPS的介绍。
+1. 系统/App宕机时间(System/App Downtime) 和严重线上事故数(Incidents)，衡量的是系统的可用性，通常与用户价值直接挂钩。
+1. 热修复上线时间(Hotfix Time)，指的是一个热修复从编码完成到部署到生产的时长，关系到解决重大缺陷的效率，与用户价值强相关。
+
+我的建议是，你可以再去看看准确度的其他衡量指标，根据团队情况，找到能够最直接衡量产出有效性的指标，而不是一定要采用上面这3个指标。
+
+### 第二，先从全局上找瓶颈，再深入细节
+
+前面提到过，在度量效能时，很多团队往往是一上来就不加辨别地扎到某几个竖井里去寻找问题。这样的局部优化往往对全局优化无效，还会影响团队之间的关系，带来负面效果。正确的做法应该是，先检查全局，找到关键瓶颈之后，再进入细节分析和解决的环节。
+
+具体实现起来，方法也很简单，就是收集产品周期中每一个阶段所占用的时间，包括计划的时间和最后实际花费的时间，然后寻找问题最大的地方。
+
+具体的**耗时收集**方法，大致有两种：
+
+1. 人工收集。比如，文章开头提到的项目经理手工收集研发过程中每环节的耗时。
+1. 通过工具收集。比如，Trello的任务显示看板，或者Jira的看板，都可以清楚地看到每个环节有多少任务以及流动情况，从而直观地识别瓶颈。
+
+收集到了每环节的耗时之后，下一步就是去**发现瓶颈**。除了直观的观察之外，我推荐一个工具：累积流程图（Cumulative Flow Diagram)。具体方法是：横轴是日期，纵轴是每天统计的各节点任务数量，绘制出来就形成了累积流程图。比如，我们统计待办（Backlog）、开发（Dev）、测试（Test）、生产（Production）这几个节点，累积流程图如下所示：
+
+<img src="https://static001.geekbang.org/resource/image/0e/a1/0eb672f2d6784b919a8032cfce68e2a1.png" alt="">
+
+从水平方向看，待办和生产这两条线的距离就是交付时间（Cycle Time），也就是从开始开发到交付的时长。垂直方向的距离代表WIP，也就是系统中的任务数。通过这张图，我们就可以一目了然地看到任务在流程中的流动情况，并直观地发现问题。比如，WIP数值变大大、交付时间变长通常都代表研发效能下降。
+
+可以看到，累积流程图对于查找全局瓶颈非常有用。实际上，我们还可以通过它预估发布日期，查看开发是否被阻塞等。这里有一篇[文章](https://ruddyblog.wordpress.com/2018/04/23/%E7%B4%AF%E7%A9%8D%E6%B5%81%E7%A8%8B%E5%9C%96-cumulative-flow-diagram-%E8%A7%A3%E5%AF%86/)，讲述了如何通过累积流程图，找到问题并进行调整，供你参考。
+
+### 第三，通过主观的方式来评价、提高效能
+
+没有客观的方法去衡量开发人员的生产效率，并不意味着你无法衡量它。 一个办法是，你可以尽量公平地去主观地测量它。事实上，平时工作中我们也确实是这么做的。
+
+比如，在一个团队里面，大家通常都能对谁是技术大牛达成共识。这是我们的大脑依据平日收集的点滴事实做出的判断，也是因为当前还没有AI系统能够自动做出这样的分析，才显得非常主观。
+
+所以，**我推荐收集人工反馈的办法，来帮助我们做出尽量公平的主观评价。**
+
+针对研发环境、流程、工具的效能进行评价，可以使用**公司成员对研发效能满意度的净推荐值**。虽然现在还没有很强的理论依据可以证明，这个指标可以大幅提高研发效率，但从我看到的许多真实案例来说，事实确实如此：满意度让员工工作更积极，而工作积极又能提高满意度，是一个良性循环。
+
+我在Facebook内部工具团队工作时，我们每个季度都通过调查问卷收集开发人员的建议，另外，我们还有IRC聊天室类似的工具供讨论和吐槽。这些反馈，都会成为工具团队调整工作内容和优先级的依据。
+
+至于调查问卷的内容，具体来说可以关注以下这几个方面：冲刺的准备充分度、团队沟通有效性、冲刺过程效率、交付价值如何、交付信心如何、对产品方向及路线的兴奋度等。
+
+**针对个人研发效能作评价，可以采用类似360度绩效考评的方式来收集同事之间的评价**。评价的标准基于在用户价值输出上做出的贡献，包括自身产生的价值，以及帮助团队成员产生的用户价值。如果一个员工可以很好地产出用户价值，那他的研发效率通常不会差。其实，Facebook就是使用这种方式来评价员工效能的，虽然主观但很公正。
+
+我整理了一张表格，列了一些可以用来收集反馈的问题，涵盖开发效率、质量、团队贡献等方面。
+
+<img src="https://static001.geekbang.org/resource/image/f4/1e/f4767b13d8f1eba1ec08a0c88f3d511e.png" alt="">
+
+### 第四，关注个人维度的指标提高效能
+
+个人效能相关的度量，直接反映开发人员的开发效率和满意度，对团队产出影响很大。所以，作为管理者/内部效能团队，应该关注开发人员的高频活动，并自动化和优化这些步骤，让开发人员能专注开发。
+
+一般来说，“个人调测环境构建速度”是一个比较重要的指标。它描述的是开发人员在本地做好一个改动，到能够进行本地调测的时长。开发人员每次修改自行验证都要经历这个步骤，对它进行优化非常有用。
+
+我以前在Facebook的时候，后端代码及网站的绝大部分修改都可以在一分钟之内在本地开发机器上使用线上数据进行验证，非常爽快，效率极高。
+
+但是，我曾经在其他公司见到过这样一种情况：一个修改需要在本地编码，上传到服务器编译，再通过工具下载到另外一个机器上验证。这个过程至少需要一个小时，在这种情况下，即使是在验证时发现一个简单错误，修改后简单验证也需要再花费一个小时。
+
+不难想象这种情况下开发者的沮丧心情。如果能解决个人效能维度上的痛点，必然对提高产出和士气有重大作用。
+
+## 小结
+
+好了，这就是我今天要和你分享的效能度量的指标和方法了。接下来，我与你总结下今天的核心知识点。
+
+首先，我将度量指标分为了准确度、速度、质量和个人效能4个方面，并列举了40多个具体指标。然后，我根据软件研发以及效能度量的特点，给出了1个原则和4种建议的度量方法。原则是不要与绩效挂钩；度量方法包括：目标驱动，度量对的事；先从全局上找瓶颈，再深入细节；通过主观的方式来评价、提高效能；关注个人维度的指标提高效能。
+
+我把这4种方法，以及基本思路总结成了一张表格，方便你理解与记忆。
+
+<img src="https://static001.geekbang.org/resource/image/a5/9e/a52387c453af2f78e3e68842dd19569e.png" alt="">
+
+研发效能的度量很灵活，也很容易踩坑。所以，我希望上面的这些原则和方法能够作为你实施度量的参考，从而达到以下几个目的：
+
+- 跟踪团队的表现、提高团队的绩效；
+- 提高项目计划的精确度；
+- 了解流程是否高效，寻找需要改进的关键领域。
+
+最后，我来分享一下我个人对效能度量的两大感受：
+
+1. 度量只是工具，不是目的。切记度量的真正的目标是提高效能，不要舍本逐末。比如说，如果度量花费的时间超过了收益，那就不要去做。
+1. 虽然我们推崇数字驱动，但在效能的度量上，不要迷信数字，适当使用主观反馈效果反而更好。
+
+## 思考题
+
+你能从下面这张累积流程图中，看出什么问题吗？
+
+<img src="https://static001.geekbang.org/resource/image/2a/67/2a25cdb23692a921f6b20af9bfe76b67.png" alt="">
+
+感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
+
+