研发效能最前线 | 第13期 - 《践行者》

践行者第13期直播回放来啦！

这次我们特别邀请了资深一线研发效能专家伍雪锋老师，一同聊聊什么是研发效能，以及研发效能的关键等各类极具实战干货的话题。相信本次“研发效能”的话题能够给大家带来不一样的收获！

一、研发效能最前线

“研发效能”是什么？对于这个较为抽象的问题，伍老师通过一个形象的例子进行了解释：假设软件开发就像一只鹅下蛋，如果这只鹅在平时能够吃到好的草、好的虫子，或者生活在一个良好的生态环境中，那么它在逐渐膘肥体壮的时候产蛋，这个是效能。但这只鹅每天最多只能产一个蛋，这就是效率。我们可以通过这个故事来理解效率和效能的区别。一般来讲，我们在提研发效能时，很容易混淆效能和效率的概念。简单来说，研发效能就是指软件从需求到真正交付给客户的价值之间的相关能力。

同样，提高研发效能一般会关注哪些维度呢？伍老师对此进行了回答：

第一个关注维度是外部感知。所谓的外部感知，就是指客户能够感受到的变化，比如价值交付速度的提高。举个例子：传统制造业的汽车企业与新能源汽车企业的打法其实很不一样。所以，如果我们想改变外部感知，就需要提高企业的人机交付速度和软件交付速度。假如原来是半年，那提效后，现在是按周或按天迭代，这就是企业提高研发效能的方式之一。

第二个关注维度是内部管理诉求。例如管理者想知道团队的整体交付情况，这时管理者通常会问一个问题，即团队的效能如何？这也是我们关注研发效能的过程中，需要回答的问题。

二、干货实录

Q1：怎么保证数据真实性？

A：在进行研发效能度量时，无论做得好与坏，总会有人质疑数据的真实性。举个例子，如果有人的表现垫底了，他第一时间不会去查看数据，而是会直接质疑数据的准确性。

当我两年前开始做这项工作时，我就预见到了一定会出现这种情况。因此，我们进行了一些小小的设计。在真正推出研发效能可视工具或仪表盘之前，我们需要给大家一个心理安全期。我们在上半年研发了一些效能可视工具，希望能帮助Team Leader或PM。但在此时，我们不要全员开放，而是根据整个团队的运作健康程度先进行小范围试点。例如，我发现在这个过程中，团队成员可以看到自己团队的数据。当他们发现数据不准确时，他们肯定会提出“在这个试验过程中，我发现需求交付周期有问题”等问题。

我们就需要确定到底是数据更新不准确，还是数据计算逻辑不合理，或者其他别的原因。在这3-6个月的试点过程，我们基本可以把数据不准确的顾虑打消。

在许多情况下，与数据不准确无关，而是有些人认为之前的工作是不可见的，现在这些工作变得可见了，这种变化对他们的工作构成了威胁。

Q2：数据采集时，需要研发配合来及时改变需求流转状态。但研发甚至Team Leader认为这会增加额外的工作量，不愿意配合。老师有没有什么方法能让研发接受？

A：我先就自身的经验讲一下吧。在提高研发效能的过程中，首先需要实现工作可视化。在进行可视化的过程中，我们并不是一开始就有这些线上的平台、工具。相反，我们通过采用一些直观的方式，如看板墙、每日早会等。这些方式让整个价值流动必须依靠人力频繁地做这些动作，从而形成了一种仪式感，让我们知道自己的任务和需求必须流动。

当有一天出现一个平台可以减轻人们的移动负担时，逻辑上是比较容易接受的。如果真的引入这个平台，我们也可以想出一些方法来确保数据及时刷新。例如，通过某种工具，当需求的代码部署到测试环境时，如果单元测试和接口测试都通过了，那么该需求的卡片会自动变为“测试中”等等。这些平台、工具的出现让我们不需要通过手动更改状态来控制这些需求的流转，这样会提高大家的接受度。

Q3：研发人员效能低会导致敏捷跑不动吗？

A：

伍雪锋老师：

近两年来，研发效能成为了一个热门话题。在外部环境不好的情况下，许多企业开始将注意力转向内部，以提高研发效能。实际上，研发效能早在很久以前就已经存在了。社区中有许多老师早就在做相关的工作，例如持续集成和实践推广等，这些都是提高研发效能的方法。

研发效能与敏捷是否有关系呢？在当前大家都追求效益的背景下，极限编程和SAFe等敏捷方法都是不错的选择。对于组织遇到的问题，只要能解决企业的问题，叫什么都无所谓。

陈连生老师：
敏捷和效能应该是相辅相成的关系，我们的目标是提升效能。如果一个团队遇到了问题，即使团队已经尽力了还是无法确保每个迭代都有增量交付，你可能会判定他们的效能不够高。一个团队因为效能达不到而遇到问题，这种情况下，有什么建议可以帮助他们改善呢？

伍雪锋老师：
出现这种问题的原因是多方面的。如果你是教练或PM，可以深入团队了解情况。在迭代回顾时分析问题，例如我们在一个迭代内做了哪些事情导致我们没有增量交付。这里可能有很多情况，其中最常见的是能力不足。当我们在计划时间内无法准备好需求时，原计划四周要交付的需求现在仍然需要被接受，而我们也没有进行需求置换。另一个场景是我们对Sprint有误解，而客户并不关心企业的迭代周期，只关心产品何时能交付。

我们内部的迭代只是为了保持研发的节奏，让小团队在工作时有节奏感。这不是说每个迭代必须有产品发布，而是每个迭代都应该有一些可以内部验收的东西。因此，我们需要清晰地定义DoD。其次，我们需要深入团队了解问题的根本原因，是技术问题还是需求问题。只有这样，我们才能找到解决问题的方法。

Q4：卷体力和卷智力哪一个更有成效？有不卷且借此机会反思和回顾的企业吗？

A：我的第一份工作是在华为做项目时，我接触到了研发效能理念。当时提出了一个观点：我们不必等到所有准备工作都做好了才能引入新的实践或提升，我们可以随时回顾复盘并持续改进。

起初，我感到有些自卑，因为整个团队没有流水线，我不会做持续集成，也不会做单元测试。有一些理论中的事情我们做不到，如每天面对面沟通之类，就会想“我们都做不到，是不是不适合这样做”。这时团队的顾问给我们打了一个强心针，“一个正常的团队任何时候都可以在做中学、学中做，这是相辅相成的过程。”有时候我们可能没有那么好的运气，但我们可以主动尝试一些变化，比如我们现在发现整个社区的研发效能或敏捷项目的实践可以帮助我们更好地工作，提升我们的幸福指数，就可以做一些主动的尝试。

回到之前提到的卷体力和卷智力，我认为这实际上是两种状态。在“口罩”期间，大家居家办公，公司的仓库和生产线停了，公司就会提出一些行政命令，比如大家必须在20:30之后基本加班。这其实就是卷体力，但卷体力本身就是一件不太增值的事情。在这期间，很多企业会发现这是一个危机，但如何将危机转化为机会呢？这可能需要在这个时间节点上思考，是否可以发展一些线上业务，重新设计业务流程以支持这些业务，并尽可能减少业务受到的影响。这其实是在卷智力。我个人认为卷智力会比卷体力更有成效。

Q5：研发效能要不要度量到人？

A：
伍雪锋老师：
研发效能通常与组织的绩效考核方式有关。传统的方式偏向于KPI，但KPI往往与个人绑定。在考虑研发效能时，我们应该避免直接将其与绩效考核绑定。研发效能更多地是一种牵引作用，不建议直接与绩效考核挂钩。如果我们具体到个人，可能会出现一种情况：大家会关注代码行数或人均代码行数。这种情况下，我们可能会忽略真正的牵引作用，例如一个常规产品或现金流产品，它的架构很成熟，但新业务量很少。如果我们追求代码量，可能会导致明明可以很简洁的一个代码，结果变得很复杂，导致动作变形，这与我们的初衷不符。因此，我建议在考虑研发效能时，应该从团队维度入手，首先观察团队的趋势。例如，在一个产线中有五个团队，我们可以了解每个团队的效能情况。团队的Team Leader或PM通常很了解团队的真实情况，如果一个团队的效能很差，我们可以考虑采取哪些管理或工程改进措施来提高效能。总之，我们应该让研发效能的过程可见，但避免将其具体到个人，以免牵引作用失真。

东伟老师：
你一般使用哪些指标来衡量团队的效能，以便确定它的高低？

伍雪锋老师：
这个没有标准的答案。我之前在IT部门和研发部门工作过，我认为衡量团队效能的指标应该根据目标来定。例如，IT部门主要是为业务部门提供支持，作为业务部门的贴身管家，需要及时响应需求。因此，衡量团队效能的指标可以包括需求响应时间、客户满意度等结果指标等。而在研发部门就不能仅看单一指标，如代码行数或过程指标，而是应该做一些趋势分析（比如流动速率、流动负载），更注重需求的整体趋势。总之，衡量团队效能的指标应该根据具体目标和情况来定，既要客观可衡量，又要能够反映团队的整体表现。

陈连生老师：
作为团队领导者或管理者，如何通过这种方式了解每个团队成员的表现？

伍雪锋老师：
在组织层面，我们可以通过研发效能仪表盘或研发驾驶舱等可视化工具来了解团队的表现。这些工具可以汇聚团队的数据，包括个人的数据。为了避免一些负面情况的出现，我们一般在向管理层展示数据时会将个人数据的权限屏蔽，只向最紧密的Team Leader或向PM提供数据。如果团队的敏捷教练、Scrum Master或PM都不了解团队成员的情况，这也是很危险的。

Q6：研发的产能如何计算呢？如何根据研发资源的产能对业务需求进行预排期？

A：有些人将研发人员称为研发资源，这种说法并没有将人员视为独立的个体，而是将其视为可调配的资源。这种观念可能与敏捷开发的理念不太一致。当然，这是没有对错的，不同的人有不同的价值观。我们可以看研发人员的产能与吞吐量，比如每月一个迭代，一个5个人的团队能做多少需求等等。在这种情况下，如果开发周期是固定的，那么我们可以根据团队的表现来推算出团队能够完成多少需求。如果有一个大项目或关键客户，我们可以根据历史速度来预测完成时间。即使在销售导向的情况下，客户先下单了，我们也可以根据团队的历史速度来倒推预测交付时间。这种方法可以帮助我们更好地规划工作，确保按时交付。

Q7：DoD包括测试自动化的完成吗？DoD定义全公司都用一样的标准吗？

A：大家如果对敏捷中的极限编程或其他方法有了解的话，会知道其实完成的定义（DoD）也分不同的维度。例如，我们知道有迭代的DoD、需求的DoD和版本级的DoD。由于不同业务属性的存在，整个公司可能无法使用相同的DoD。

如果真的有可以统一的东西，那可能就是我们所说的研发红线或质量红线。这些是整个公司需要共同遵守的。

DoD的设计建议也是先完成再完美，随着团队的成熟度提升不断迭代，并非一成不变。在前期，我们需要确定几个关键点，以建立信心。举个例子，新组建的团队需求总是不能完成，我们就会定义需求的DoD中要有清晰的验收标准（AC）。在下一个阶段需求不再是瓶颈的时候，我们可能需要自动化测试，并相应地调整DoD在需求设计阶段就考虑是否要做自动化测试。因此，DoD是一个随着团队的成长而不断调整的概念。

Q8：团队如果出现问题后会追责到个人，个人效能如何提升？

A：这个问题我觉得可能与个人效能无关，先暂时一放。

在提高团队效能时，我们需要关注领导的态度。如果领导直接指责团队表现不佳，这可能会让团队成员感到不安和不满。相反，领导应该关注团队的长处和优势，以激发团队成员的积极性和幸福感。在这种情况下，个人的效能才能得到充分发挥。

当然，责任也是需要落实的。如果团队表现不佳，领导应该从团队成长的角度出发，帮助团队找到改进的空间。这样，个人的效能才能得到充分发挥。

Q9：团队效能提升最终还是要落到个人效能提升，老师可以提供一些个人效能提升的方法吗？

A：我坚信一个原则：整体大于个体之和。因此，我们不能仅口头上说要提高效能，更要创造条件来实现这一目标。

我们可以先借助工具来解决团队成员“忙于救火”或“死亡行军”的困境，从而为提高效能创造时间。在个人方面，一方面我们可以借助工具来提高效率，例如AI、Code Review，构建CI/CD等；另一方面需要解决沟通和协作问题。在团队中，我们如何更好地面对面沟通，消除内耗？在需求产生、传递和实现的过程中，我们可以通过用户故事地图来减少歧义性，讲故事的过程中就能够理解需求，既见森林又见树木。

多年来，我们总认为Scrum Master应该承担团队效能提升的责任。直到我读到了《专业Scrum》后才了解到，除了Scrum Master外，团队成员都应该积极参与，共同努力提升效能。因此，团队成员需要提升以下几个能力：

（1）教授能力
Scrum Master、PO、成员等都可以为团队教授。教授并不是简单的演讲，而是通过实践和探索来更有效地进行，通过建立与已知事物的联系来学习新知识。

（2）引导能力
举个例子，当团队在回顾会议上保持沉默或者认为已经做得很好，没有任何问题时，作为专业的引导者，你可以帮助团队尽可能地避免回顾会议的24个反模式。

我推荐大家阅读章鱼书《回顾活动引导：24个反模式与重构实践》，这本书可以帮助我们更好地了解如何引导回顾会议，个人可以在这方面做的比我们想象的要多得多。

（3）教练能力
例如，在PO和开发团队讲解需求的时，技术不同业务，业务不懂技术，作为教练如何来引导谈话的进程。

（4）技术卓越
要想做好Scrum，你需要展现出技术卓越的能力，包括工程实践、编程语言、产品管理和质量保证等方面。你需要持续不断地影响团队中的每个人，让他们了解什么是持续集成和持续交付，并将技术卓越变成一种文化。

（5）服务型领导力
当成功取决于其他人的行动时，我们很容易陷入指挥他们的误区。但是，当你想要提升团队每个人的效能时，作为一个有责任心的Scrum Master，你应该具备下述行为表现：

营造安全环境，确保每个人被尊重；
促进团队达成共识，Focus，明确决策和责任；
不亲自解决问题，致力于提高透明度、自组织；
接受失败和模糊性，帮助团队学习和成长；
对成员关心，帮他突破舒适区；
对组织级的阻碍表现出较低的容忍度，并主张消除这些阻碍，使团队能取得更好的结果。

Q10：业务结果没有变化的问题如何解决？

A：业务结果的变化取决于商业模式、组织心智、执行能力、宏观环境等。当我们无法在这些层面做决策时，那在当下的事情里找一个自己最拿手最开心的事情，持续深耕也很好。

我之前容易专注于团队内部，比如研发内部的敏捷运作是否顺畅，需求储备是否足够，能否准时发布等等。这些有没有意义呢？有。但能力与业务结果是否有必然联系呢？并不尽然。现在我们尝试从产品经营视角组建经营团队，每周开一个早会对齐经营结果，比如产品竞争力目标、技术竞争力目标、产品&技术的口碑目标、经营目标、研发效能目标，每个专项目标的衡量指标、完成值，当前的风险和阻碍是什么，我们的应对措施是什么……我们会尽可能把外部目标的进展同步给大家，这样大家能够往一处使劲儿。

Q11：关注研发效能后，关键指标会有多大效果？比如质量、效率、交付周期等。

A：研发效能的关键是要建立持续反馈的机制，能够牵引团队，比如下图中研发效能七巧板中的定期检视和正向反馈：

研发效能汇总表

在我做过的真实项目里，通过半年的牵引，交付周期、质量、效率整体上提升20%-50%是可以达到的。

研发效率

Q12：不同团队的对比怎么能让大家认可?

A：在公司层面横向拉通的指标必然是一些人畜无害的指标，它有三个特征：

没有办法作假；
平台较为容易抓取；
能做趋势分析。

趋势分析类的指标（比如：需求储备情况）数据是实事求是的，但对大家又没有什么伤害，所以能够作为一个牵引，给大家正向反馈。

需求储备情况

三、送给大家的一句话

做研发效能与变革一样。你会选择晴天还是雨天去修屋顶呢？我认为在晴天修屋顶更为适宜，一方面这种方式更容易接受；另一方面，我们不必等到火烧眉毛才去解决，这样确保我们的工作行稳致远。

研发效能最前线 | 第13期