[2023] 上册：研发效能100问

研发效能100问 12 位研发效能专家，为你答疑解惑 共探效能度量方法与实践 第一本研发效能领域的问答工具书，集结业界多位研发效能专家，结合自身研发效能度量方法与落地实践，解答研发效能领域Top100高频问题，为正在做研发效能建设的你答疑解惑。 序言 与巴菲特齐名的投资大师查理 · 芒格说过“系统学习、掌握前人发现的最有用的知识，才是靠谱的学习方法”。这句话也适用于现在正方兴未艾的研发效能领域，我们需要不断从前人那里汲取经验，才能消除自身的盲点。消除盲点才能更好地理清思路，发现到更多解决问题的角度和维度，找到最合适的解决方案。 本书就是为了尽可能多地消除构建研发效能体系的盲点问题而撰写的。分为上、下册，收集和梳理了目前我们看到、听到的业界朋友们问的最多的100 个问题。我们不确定本书足以解答所有人在各自业务中遇到的问题，毕竟建立研发效能体系的过程中，由于行业、业务、战略等层面的差别，也让大家遇到问题千差万别。但我们希望，这本书能在一定程度上消除大家在构建研发效能体系过程中一些常见的盲点，帮助大家向系统化地构建研发效能体系共同迈进。 为了解答这些问题，我们邀请了12位研发效能领域的专家老师，分享对不同问题、观点的认知和思考，以及他们深耕研发效能领域的实践和经验。其中，不仅包含『怎么做』，更包括实践背后以目标为导向的思考脉络和深化改进的实现路径。 如果这本书中只有一部分的问答内容，能在你构建研发效能体系的过程中，起到参考作用，那也便完成了它的使命。我们也期待听到大家的反馈，以及更多在研发效能领域遇到的问题。同时，我们也正在筹备《研发效能 100问》的下册，预计在下半年推出。在此期间，如果大家有相关疑问，或希望以专家身份参与共建，欢迎扫码填写表单，共同提升认知，消除盲点。 最后，也是最重要的，我们要感谢通过本书为研发效能同仁们贡献知识的专家们，包括张乐、茹炳晟、管俊、应阔浩、王蕾、余伟、费解、单虓晗、艾辉、张超、关钦杰和任晶磊 12位老师的辛苦付出，以及为行业的发展做出的贡献。 《2023 研发效能100问》上册 联系电话400-863-7426 出品人张乐 鸣谢以下各位老师参与共创 应阔浩自如互联网技术平台高级总监王蕾贝壳工程效率负责人余伟微众银行研发效能负责人张乐腾讯资深技术专家茹炳晟腾讯Tech Lead管俊戴尔中国卓越研发集团 DevOps架构师张超思码逸高级咨询顾问关钦杰思码逸咨询总监任晶磊思码逸创始人兼 CEO费解前有赞效能改进团队负责人单虓晗字节跳动研发效能资深架构师艾辉前知乎研发效能负责人 嘉宾推荐语 推荐每位对研发效能感兴趣、正在落地相关实践或遇到了棘手难题、困惑的朋友阅读“研发效能100问”。 这本书收集了推进研发效能提升过程中（尤其是效能度量领域）的常见问题，并把行业专家针对这些问题的独到见解和实战经验进行了汇总和整理。 无论你遇到的是怎样的问题，无论你正困于过程中的哪个阶段，“研发效能100问”都能为你指明方向，引领你快速地找到有效的解决方法。这本书能帮你避开落地过程中潜藏的各种陷阱，让你能站在前人的经验之上，减少试错成本，节省宝贵时间，更有效的达成效能提升的预期目标。 ———张乐腾讯资深技术专家 、《研发效能100问》出品人 技术不息，效能不止，各个行业逐步开始重视研效，领域虽然不同，遇到的研效问题共通性却有很多。从理念到实践，《研发效能100问》聚集了业界典型的案例和方法，帮助你解决如何选指标、如何建系统、如何用数据和如何做决策的问题。从实践出发，一百问一定让你在研效提升之路事半功倍！ ———应阔浩自如互联网技术平台高级总监 随着DevOps、研发效能在各行各业越来越多的企业内部开始落地，在这种规模化的背景下，作为一名相关从业人员，你是否在日常工作中遭遇到许多难题和困局？是否苦于没有合适的渠道去寻求参考答案？那请允许我向你推荐这本《研发效能100问》，由思码逸编撰，以问答的形式收集整理了行业专家针对研发效能落地过程中诸多问题的独到的观察洞见、精辟的分析思路和干货满满的实战经验，我相信你一定能从中觅得破局之道。 ———管俊戴尔中国 卓越研发集团 DevOps架构师 你是否正在关注研发效能领域，但对于研发度量还存在一定的困惑？如果是，那么这本《研发效能100问》绝对不容错过。它集合了多个企业在效能度量领域的实践案例常见问题，并配以多位行业专家的深入解读和回答。那么不如从问题出发，有的放矢。这本书将为你提供实用的指导和深刻的理解，是研发效能领域不可或缺的参考书。无论你是研发管理者、从业人员或相关领域学者，都能从中受益匪浅。拥有它，让它成为你的copilot，助你一起推进研发效能提升与落地。 ———王蕾贝壳工程效率负责人 《研发效能100问》，针对研发效能领域的问题进行深入的探讨。本书跟进技术发展趋势，深入剖析研发团队面临的挑战，提供切合实际的解决方案；以系统的方式组织研发效能领域知识，帮助读者建立完整的研发效能框架；各位行业专家用简洁明了的语言解释了复杂问题，让读者能够轻松理解。我相信，阅读这本书将带给你启发和帮助，提高你的研发效率，为你的职业生涯增添价值。无论你是在研发领域寻求提升的团队领导者还是团队成员，我都强烈推荐你阅读这本书。 ———余伟微众银行研发效能负责人 当软件研发领域不再以英雄式的天才程序员示人，转而走向综合低效的流程化分工协作的产业形态时；当外部环境处于百年未有之大变局，经济放缓导致生产力过剩，职场频唱「毕业歌」时——只有通过提升研发效能实现降本增效，才是企业唯一的出路。于是，我们有必要蛰伏下来，好好研读这本《研发效能100问》，汲取优秀同行的智慧，剖析成功失败的案例，通过三分理论加七分实践的能效管理工作，赋能企业度过寒冬、走出困境。 ———费解前有赞效能改进团队负责人 这是一本内容丰富且全面体系的研发效能技术著作。通过由浅入深、层层递进的方式剖析了研发效能的体系知识。书中就效能理念及文化、效能度量建设、研发效能应用等都做了较精要的解答。本书非常适合想要了解、学习以及从事研发效能、研发数字化转型、DevOps的同行阅读。 ———艾辉前知乎研发效能负责人 目录 第一章效能理念与文化 01度量成本投入&价值/ 0102如何达成共识/ 0303效能度量风险点/ 06 第二章效能度量建设 01效能度量的构建方法/ 0902效能度量的平台实现/ 1403验证度量有效性/ 17 第三章研发效能应用 01效能度量的应用方法/ 19 第一章 效能理念与文化  度量成本投入&价值 如何达成共识 效能度量风险点 第一节度量成本投入&价值 01在一个研发团队中，业务开发和效能度量应该按多少比例投入？ 在一个研发团队中，开发人员与负责研发效能的人员（其中包含做效能度量的人员）的比例并没有固定的标准，因为这取决于多种因素，如公司规模、产品复杂性、团队专业背景等。但是，我们可以从一些标杆企业的实践中寻找借鉴。记得之前有资料显示，谷歌、微软等公司有3%~5%的工程师专注于提升工程生产力，也有其他来源的分享提到大约每5~7名软件工程师中就有一名专门负责工程生产力的工程师。这个比例可能会随着团队规模和项目的不同而有所变化，这取决于团队对这方面的关注程度。 效能度量是在团队内部做好一点还是有专门的效能团队更合适？ 这取决于组织的规模、复杂性和当前的需求。效能度量可以在团队内部进行，但有时候设立一个专门的效能团队会更合适。比如，小型或初创公司可能只需要在团队内部进行效能度量。在这种情况下，成员可以一边承担日常职责，一边度量和促进效能提升。而对于大型企业和复杂产品/项目，设立一个专门的效能团队可能更合适。这样可以确保效能度量的专业性和一致性，由专门的效能团队更系统地识别瓶颈、制定改进措施，并监控持续改进过程。 另外，这里要注意的是，无论是在团队内部进行度量还是设立专门的效能团队，都需要做到度量 指标的设置与组织目标保持一致，并确保改进措施能够有效落地实施。 03怎么平衡研发效能度量和管理成本，当我们致力于通过数据度量研发效能的时候，怎么知道这件事情是有收益的呢？ 度量是有成本的。收集数据这件事本身就是有成本的。当我们收集了大量数据，并试图通过这些数据分析和改善问题的时候，如果你收集数据的成本已经高于你通过改善问题能带来的收益，这种度量就是得不偿失的。 我以前看过一部周星驰的电影，电影里有一个人很厉害，能知道战场前发生的情况，当他把耳朵贴到地上的时候，说即将有三匹战马来袭，结果一抬头，马已经站在他面前了。这其实就是一个典型的得不偿失的例子。度量是为了解决问题，度量本身是没有意义的，度量能解决问题才是有意义的，所以在很多情境下我们没必要去搞大而全的度量数据中台，因为度量数据的收集、计算、分析、挖掘的成本很高，小公司可能根本承担不起。更落地的一个平衡成本的做法，就是直接基于我们通过眼睛和直觉发现的问题设计度量指标，而不是去做广泛的、大而全的数据收集。这是我的第一个观点，也就是不要广撒网，而是应该针对问题有的放矢。 第二个观点就是关于度量数据本身，不能依赖人去提交。当这些数据是依靠人来收集、计算和分 析的时候，这个成本必然是很高。而且这些数据也会严重失真，因为大家都喜欢报喜不报忧，在层层上报的过程中一定会失真，最后老板会看见一个很乐观的数字，但其实下面的问题已经非常严重了。所以度量数据要变得有意义，或能指导工作实践，度量数据的自动获取是我们在做度量实践时一定要获取的能力。也就是说，不管获取的数据是什么，获取数据本身对工程师来说必须是零投入和零感知的。 04有些量化很难得出准确结论，领导也有比较多的质疑，遇到这种情况该怎么处理？ 用于组织内部的度量系统实际上也应被看作为一个面向内部用户的产品。既然是产品，那么就要弄清楚它对应的用户群体和实际需求。 回到问题本身，第一个难点——量化（或指标）很难得出准确结论。那么我们要分两个层面考虑 ： 第一，这个指标本身有对应的用户吗？谁会关心这个指标？如果问了一圈都找不到谁可以用到这个 管俊 指标，那么我们不如就不要纠结了，把它废弃掉或者在用户界面上隐藏起来。事实上我自己负责构建指标系统的时候，也经常会根据自身兴趣附加一大堆指标，但最终能落地的指标，还是贴着目标用户（例如发布主管、部门经理、Scrum Master等）的诉求产生的。 第二，指标本身没问题，有用户关心和使用，但是结论不准确。那么不准确的原因是什么？是数据 采集不准确？那么就修正采集方面的问题；是数据来源的脏数据多？那么可以尝试基于这个不准确的数据去汇报异常点，反向推动日常的项目运作，使数据来源更干净；如果数据来源和计算都没问题，但无法从结论清晰地推导出问题或改进方向，那么我建议暂时不要将其纳入指标系统。随着组织发展情况的变化和数据的积累，未来的某一天也许有机会能重新付诸应用。 第二个难点是领导的质疑。这个问题我们要从用户的角度去看。领导提出质疑，是不是因为这个指 标对于领导来说，他不关心或者解读太费力，包含太细节。这里我也结合自身的经验来谈，我自己在为组织设计指标系统、分析需求的时候，首先就是对系统的角色进行划分，然后对不同层级的角色提供不同粒度的指标。这些指标一定是要能直接契合相关用户的目标的。譬如，我的领导关心“不同项目的人员分配是否合理”，那么我就需要构建一个人均产出的指标，并且基于项目做聚合和比较，这样他就能直观地看到是否存在人员空转的情况，是否有人虚报了工作的预估量等等。 总之，指标制定或量化的工作中，这样的情况非常常见，但只要能秉持产品思维，持续贴合目标用 户的需求，就一定能不断地提高指标的普及率与准确度。 05如何衡量研发效能度量的价值？ ÕØ提升组织价值交付的能力。 研发效能度量可以帮助组织更好地评估研发活动对业务目标的贡献，并为价值交付能力提供客观反 馈。比如，可以发现资源利用不均衡的问题，使资源更加合理地分配到关键项目；可以识别和优化关键流程，缩短交付时间、提高产