【思码逸】[2023] 上册：研发效能100问

第一章效能理念与文化

第一节度量成本投入&价值

01在一个研发团队中，业务开发和效能度量应该按多少比例投入？

在一个研发团队中，开发人员与负责研发效能的人员（其中包含做效能度量的人员）的比例并没有固定的标准，因为这取决于多种因素，如公司规模、产品复杂性、团队专业背景等。但是，我们可以从一些标杆企业的实践中寻找借鉴。记得之前有资料显示，谷歌、微软等公司有3%~5%的工程师专注于提升工程生产力，也有其他来源的分享提到大约每5~7名软件工程师中就有一名专门负责工程生产力的工程师。这个比例可能会随着团队规模和项目的不同而有所变化，这取决于团队对这方面的关注程度。

02效能度量是在团队内部做好一点还是有专门的效能团队更合适？

这取决于组织的规模、复杂性和当前的需求。效能度量可以在团队内部进行，但有时候设立一个专门的效能团队会更合适。比如，小型或初创公司可能只需要在团队内部进行效能度量。在这种情况下，成员可以一边承担日常职责，一边度量和促进效能提升。而对于大型企业和复杂产品/项目，设立一个专门的效能团队可能更合适。这样可以确保效能度量的专业性和一致性，由专门的效能团队更系统地识别瓶颈、制定改进措施，并监控持续改进过程。

另外，这里要注意的是，无论是在团队内部进行度量还是设立专门的效能团队，都需要做到度量指标的设置与组织目标保持致，并确保改进措施能够有效落地实施。

03怎么平衡研发效能度量和管理成本，当我们致力于通过数据度量研发效能的时候，怎么知道这件事情是有收益的呢？

度量是有成本的。收集数据这件事本身就是有成本的。当我们收集了大量数据，并试图通过这些数据分析和改善问题的时候，如果你收集数据的成本已经高于你通过改善问题能带来的收益，这种度量就是得不偿失的。

我以前看过部周星驰的电影，电影里有一个人很厉害，能知道战场前发生的情况，当他把耳朵贴到地上的时候，说即将有三匹战马来袭，结果抬头，马已经站在他面前了。这其实就是一个典型的得不偿失的例子。度量是为了解决问题，度量本身是没有意义的，度量能解决问题才是有意义的，所以在很多情境下我们没必要去搞大而全的度量数据中台，因为度量数据的收集、计算、分析、挖掘的成本很高，小公司可能根本承担不起。更落地的一个平衡成本的做法，就是直接基于我们通过眼睛和直觉发现的问题设计度量指标，而不是去做广泛的、大而全的数据收集。这是我的第一个观点，也就是不要广撒网，而是应该针对问题有的放矢。

第二个观点就是关于度量数据本身，不能依赖人去提交。当这些数据是依靠人来收集、计算和分析的时候，这个成本必然是很高。而且这些数据也会严重失真，因为大家都喜欢报喜不报忧，在层层上报的过程中一定会失真，最后老板会看见一个很乐观的数字，但其实下面的问题已经非常严重了。所以度量数据要变得有意义，或能指导工作实践，度量数据的自动获取是我们在做度量实践时一定要获取的能力。也就是说，不管获取的数据是什么，获取数据本身对工程师来说必须是零投入和零感知的。

04有些量化很难得出准确结论，领导也有比较多的质疑，遇到这种情况该怎么处理？

用于组织内部的度量系统实际上也应被看作为一个面向内部用户的产品。既然是产品，那么就要弄清楚它对应的用户群体和实际需求。

回到问题本身，第一个难点——量化（或指标）很难得出准确结论。那么我们要分两个层面考虑：

第一，这个指标本身有对应的用户吗？谁会关心这个指标？如果问了一圈都找不到谁可以用到这个指标，那么我们不如就不要纠结了，把它废弃掉或者在用户界面上隐藏起来。事实上我自己负责构建指标系统的时候，也经常会根据自身兴趣附加一大堆指标，但最终能落地的指标，还是贴着目标用户（例如发布主管、部门经理、ScrumMaster等）的诉求产生的。

第二，指标本身没问题，有用户关心和使用，但是结论不准确。那么不准确的原因是什么？是数据采集不准确？那么就修正采集方面的问题；是数据来源的脏数据多？那么可以尝试基于这个不准确的数据去汇报异常点，反向推动日常的项目运作，使数据来源更干净；如果数据来源和计算都没问题，但无法从结论清晰地推导出问题或改进方向，那么我建议暂时不要将其纳入指标系统。随着组织发展情况的变化和数据的积累，未来的某一天也许有机会能重新付诸应用。

第二个难点是领导的质疑。这个问题我们要从用户的角度去看。领导提出质疑，是不是因为这个指标对于领导来说，他不关心或者解读太费力，包含太细节。这里我也结合自身的经验来谈，我自己在为组织设计指标系统、分析需求的时候，首先就是对系统的角色进行划分，然后对不同层级的角色提供不同粒度的指标。这些指标一定是要能直接契合相关用户的目标的。譬如，我的领导关心“不同项目的人员分配是否合理，那么我就需要构建一个人均产出的指标，并且基于项目做聚合和比较，这样他就能直观地看到是否存在人员空转的情况，是否有人虚报了工作的预估量等等。总之，指标制定或量化的工作中，这样的情况非常常见，但只要能秉持产品思维，持续贴合目标用户的需求，就一定能不断地提高指标的普及率与准确度。

05如何衡量研发效能度量的价值？

1.提升组织价值交付的能力。

研发效能度量可以帮助组织更好地评估研发活动对业务目标的贡献，并为价值交付能力提供客观反馈。比如，可以发现资源利用不均衡的问题，使资源更加合理地分配到关键项目；可以识别和优化关键流程，缩短交付时间、提高产品质量和客户满意度，从而增加业务价值的竞争力。

2.持续改进组织交付过程。

通过持续监测和分析效能度量指标，可以帮助组织及时识别交付过程瓶颈和风险，及时调整交付策略、协作方式、优化资源配置，并推动研发团队的持续改进。

3.支持管理层的重要决策。

客观的数据洞察可以为决策提供依据和参考，减少主观判断的风险。通过少而精的效能衡量指标及合理的数据洞察，可以支持管理者价值交付的重要决策，如资源分配、项目或业务的优先级调整、研发团队的绩效管理等。

4.协助技术管理者管理团队。

有效的效能度量指标，可以帮助发现团队和个人的技能短板，从而有针对性提升团队或个人能力；可以帮助发现“沉默”的优秀员工，为奖励和晋升提供客观依据，激发团队的战斗力。

总之，通过合理选择和应用研发效能度量，组织可以全面了解研发活动的效能和贡献，从而有效地管理和提升组织价值交付能力。

第二节如何达成共识

06研发效能度量怎么兼顾改变研发效能的同时提高开发的满意度？

这里的关键点是在推动研发效能提升时，不仅要设定团队的效率、质量、产出、成本等方面的目标，还要以人为本，关注工程师的满意度，想办法切实帮助到研发人员。比如，分析他们在研发过程中遇到了哪些困难，有哪些具体诉求，流程、工具、工作环境方面的体验好不好，在技能上是否需要给予培训和支持等。因为只有服务好每位工程师，让他们能高效、顺畅、无障碍的工作，这样才能把精力聚焦在业务逻辑实现，而不是被各种流程或不得不做的杂事打扰，也只有这样才能获得可持续的研效提升。

所以，在设计效能度量时，要在团队效能和开发满意度之间保持一定的平衡，既能通过度量分析和解决一线实际问题，也能获得团队层面的效能提升，最终追求的是双赢的结果。

07研发效能中最难的环节是哪一环？

在研发效能落地实践中，最难的环节可能是视组织和产品/项目而异的。我提出的“研发效能黄金三角”，里面的效能实践、效能平台、效能度量这三个要素，每个要素展开都有很多细节内容，都做好已经很不容易了，而更难的是让这三者形成一种动态的、互动的结构，共同构成可以彼此强化、持续迭代的增强回路。

另外个思路是，我们可以不用纠结于哪个环节最难，而是通过价值流分析等方法，先来找下组织中研发效能的瓶颈点在哪里，比如最慢速的研发步骤、最低效的研发环节或是质量最差的研发过程。有可能是需求分析和管理，有可能是代码质量和可维护性，有可能是技术架构的设计，有可能是测试和质量保障，也有可能是部署和可观测性。无论瓶颈和问题在哪里，我们通过分析都找到了效能提升的一系列线索，然后再针对性考虑效能提升的三要素，并在需要的地方采取改进措施。

08有些团队Leader比较固执，不喜欢自己团队被量化，有何好的办法说服Ta支持自己的量化工作？

确实，这是在推进效能度量过程中非常典型的一个场景，越是优秀的团队越想要透明，不想被量化的有两种情况，一种是不知道量化后对自己有没帮助，害怕浪费时间做无用功，一种是确实知道自己团队做的差、没底气。

对于第一种，需要我们把研效度量的价值和意义更好地体现出来，让他看到并且相信对他的团队、对他的管理是有帮助的，同时花费的成本又不高时，他就会逐步接受，所以这是一个体现投入产出比的过程。要让试点团队看到优质的ROI。

对于第二种其实是比较难的，《跨越鸿沟》中有一条技术成熟度曲线，我们把这种不接受新技术或晚接受新技术的人称之为晚期大众或保守主义者。对于保守主义者，需要先改变其认知，让他不要担心把团队内数据透露数来，不要怕与其他团队比对，不要担心与绩效挂钩，让他看到量化是提效的开始，而不是为了发个跑马图。最后，对于实在特别顽固的，那就不要去改变了，逐步通过平台的覆盖和推广，对他们造成同侪压力，当其他团队都有数据，他的团队没有数据的时候，他自己会主动来接入的。给他们一些时间去接受，“让子弹多飞会儿。

09多时候领导不懂技术，如何说服领导来执行设计的度量方式？

度量的主要目的是为不同角色提供信息需要，不同角色包括技术管理者，也包括非技术出身的业务管理者。面向业务管理者，简洁明了的可视化仪表盘是个不错呈现方式。我们习惯称之为驾驶舱仪表盘，仪表盘上以结果为导向的北极星指标，要能清晰传递组织的效能健康度，如：需求交付速率、价值、质量等结果指标，以及流效率、工作饱和度、资源利用率等性能指标。

在设计度量体系时，以目标为驱动避免与业务及管理目标脱钩是面向业务管理者展示度量价值的关键。实施上，除了利用MVP方法挖掘并聚焦管理需求外，也建议使用GQM模式设计度量体系，使度量体系面向目标的逻辑结构更加清晰。

GQM为度量体系的设计者提供了抓住本质、化繁为简的有效路径。即：明确度量需要刻画的目标（Goal），以及为了客观刻画目标需要回答哪些问题（Question），这些问题可以由哪些指标（Metric）来表征。数据的收集和分析一定要聚焦于清晰具体的目标，每个目标划归为一组可量化回答的问题，每个问题通过若干特定的指标来回答。GQM自上而下为业务管理者呈现看得到现状，以及说得清的问题。

10有时通过某些指标，比如需求交付吞吐量，发现某个团队该指标比较低，可以初步判断出该团队会有一定量人力等待浪费，这个给方研发Leader，对方有时不接受，可以通过什么方式让方接受呢？

对方不接受，首先是要弄清楚不接受的原因——可能是对方觉得数据不准确或者解读不清晰，可能是沟通方式不太对路，等等。大致可以遵循以下思路来解决问题Í

a拿出数据和对方探讨其中是否有和其感知相悖的地方，是度量方法的问题还是数据源的问题¡

b详细为对方解读指标体现的问题，同样要了解指标结论是否和对方的感知符合¡

c针对问题，主动表示将提供更多的支持，提出建议乃至合作意向（构建一些好的案例故事）¡

d始终就事论事，充分倾听对方的意见，毕竟对方是指标系统的用户，是我们需要去服务的对象。

当然，以上是在不考虑政治因素的情况下适用的，同时也建议不要在这样的情况下轻易升级问题到对方的领导。

11研发团队是否接受黑盒的度量方法？

不会接受。研发人员需要知道指标度量的方式，了解指标度量的方式可以帮助研发人员了解如何改进自己的工作方法，以提高研发效率和质量。并且指标只要展示出来，就有一定的对比性，即使效能团队引导做效能提升用，但这个认知渗透还是比较难的。针对于研发团队，它一定想知道你怎么计算的指标，这个指标的合理性，还有不同业务的差异性怎么体现。所以很难接受黑盒度量。

12研发效能数据平台建设的实施策略，如何得到业务方支持？

研发效能数据平台建设是一个复杂且需要多方协作的项目，需要获得业务方的支持以取得成功。以下是一些策略，可以帮助您在实施过程中获得业务方的支持¸

1.建立业务方参与的项目管理组织：确保业务方在项目管理组织中扮演重要角色，以便他们能够为项目提供必要的支持和资源‚

2.定义业务目标并确保数据平台与之相符：与业务方合作，确保数据平台的建设能够满足业务需求和目标。这将有助于业务方认识到数据平台的价值，并为项目提供支持‚

3.建立数据平台的价值主张：向业务方解释数据平台将如何满足业务需求，并量化数据平台将带来的收益。这将有助于业务方理解数据平台的重要性，并愿意为项目提供支持‚

4.建立数据平台与业务的联系：强调数据平台将如何改善业务流程、提高业务效率和降低成本。这将有助于业务方认识到数据平台的价值，并为项目提供支持‚

5.为业务方提供培训和支持：确保业务方了解如何使用数据平台并能够从中获得最大价值。这有助于建立业务方对数据平台的信任和支持‚

6.定期与业务方沟通：与业务方保持定期沟通，确保他们了解项目的进展和数据平台的价值。这将有助于建立业务方对项目的信任和支持‚

7.关注业务方的反馈：倾听业务方的反馈，并根据反馈调整项目计划和实施策略。这将有助于建立业务方对项目的信任和支持。

通过以上策略，您可以获得业务方的支持和参与，确保数据平台建设的成功。

13在研发效能相关实践实施的过程中，如何最大化消除阻力，建立积极的文化氛围？

在贝壳研发效能实践的过程中，我们发现必不可少的四大要素是：工具、规范、管理、文化‚

1.工具：项目管理、DevOps工具、效能度量的看板，都是不可或缺的工具。工具越好用，阻力会变小‚

2.规范：制定贴近业务模式的规范，规范包含公共规范（全员需要遵守）和业务规范（有业务属性的规范），规范的适用性越高，阻力会越小‚

3.管理：以效能提升为管理目标，结合公司的OKR管理，通过奖励和认可机制，激励团队成员参与到效能实践中‚

4.文化：提供培训、研讨，辅助技术运营等方式，建立积极的文化氛围。经过以上四方面的精细化操作与考量，可以很大程度上消除阻力，建立积极的文化氛围。

14研发效能改进，应该由谁来推动？管理层还是项目经理？

研发效能改进需要整个业务团队和效能团队共同努力，但在推进的过程中管理层、项目经理、效能团队都扮演了非常重要的角色‚

1.管理层需要明确效能重要性，参与到效能度量的实践里。在研发人员工作的过程中，积极参与和监督，并对团队的改进成果进行分析和反馈‚

2.项目经理更了解项目团队的信息，并且有非常丰富的技能和经验，例如协同各产研角色的能力、需求规范制订与培训等。能从业务视角与效能团队协作顺畅，并且做好过程改进管理，确保改进措施实施并持续优化‚

3.效能团队，提供专业的研发效能工具和深入的效能分析的报告，让项目团队针对研发效能有更客观的理解。

总之，研发效能改进是整个团队的责任，需要各方合作共同推动。管理层和项目经理应该承担主要的推动责任，效能团队为顾问，但所有团队成员也应该积极参与和支持改进过程。

第三节效能度量风险点

15如何合理设立效能目标？用绝对值评判多个部门的效能程度如何？

设立合理的效能目标对于牵引效能提升的方向、激励团队并持续改进很重要。效能目标一般可以从“多、快、好、省、强”五个维度来考虑。“多”是数量维度，如需求吞吐量等；“快”是效率维度，如需求交付周期等；“好”是质量维度，如客户感知到的质量问题数、SLA的达成情况等；“省”是成本维度，如人力成本和资源成本等；“强”是能力维度，如研发过程中的协作能力、工程能力、技术能力、组织能力等。

另外，目标设定需要具有可衡量性、有挑战性，可以和团队成员一起设定目标，并定期评估和更新目标。

在评判多个部门的效能程度时，用绝对值拉齐一起评估并不适用于所有场景，因为不同部门之间的工作内容和上下文可能差异较大。针对这种情况，可以制定相对性的评价标准，如将各部门的效能指标归一化后，可以根据相对的改进程度进行评估。另外，也可以采用多维度评价，团队效能不仅仅源于单一指标，可以让各个部门根据自己的痛点和目标设定特定的效能指标，但在一个大的框架内对齐即可。

16研发数据要不要跟绩效考核挂钩？

成为高绩效员工、高绩效组织是我们的目标，但绩效管理不能等同于绩效考核，不能单纯依靠数字来做判断。我们建议研发项目和团队按迭代或者月度等固定周期做数据回顾，以客观的数字而非模糊的形容词描述现状、发现问题，并通过数据设立目标、驱动改进，辅助团队或个人获得高绩效。有些组织甚至取消了传统的半年或年度绩效考核，改为更加频繁的及时绩效反馈的方式。

对于绩效考核环节，客观数据可以发挥很好的作用，避免主观判断、个人喜好甚至利益的影响。很多优秀的工程师或工程团队做了实实在在的工作却没能用词藻充分表达出来，或者得不到业务方和管理层的认可，都可以用数据说话。

但要注意两个前提，一是客观数据在评价中的比重要合理，并不能取代人的判断，多数公司选择的比重在15%到30%之间；二是数据来源于系统的度量，而非单一指标，建议涵盖交付效率、交付质量、交付能力、交付价值和人才发展等维度，指标数值也可根据不同角色做归一化处理。