极客时间已完结课程限时免费阅读

03 | 效能度量：如何选对指标与方法，真正提升效能？

03 | 效能度量：如何选对指标与方法，真正提升效能？-极客时间

03 | 效能度量：如何选对指标与方法，真正提升效能？

2019-08-28 葛俊 来自北京
《研发效率破局之道》
课程介绍

讲述：葛俊

时长16:53大小15.47M

你好，我是葛俊。今天，我来和你聊聊如何正确使用效能度量。
在上一篇文章，我给你介绍了效能度量的定义、作用，以及几个使用误区。我们先简单回顾一下：
软件系统异常复杂，度量指标无法覆盖其所有参数，从而容易被“数字游戏”欺骗。
竖井指标的提高不等于全局指标的提高，局部优化不等于全局优化。
研发效能度量指标一般用来衡量软件产品的生产过程和产品质量，但公司真正需要关注的是能否产生用户价值。这两者之间存在着难以跨越的鸿沟。
正是因为这种种看似难以解决的问题，业界甚至有人认为研发效能的度量是一个无解的问题。但我并不这样认为。如果使用得当，效能度量可以给公司的研发带来非常大的好处。
举一个真实的例子。国内一个大概 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 多个指标，从名字上可以看出它们大概要度量什么。
在后面的度量指标推荐时，我也会与你讨论其中几个指标。如果你不清楚哪条指标的具体含义，可以自行查阅，或者留言给我。另外，你现在只需要对这些指标有个整体概念，用到时再回过头深入研究，选出适合自己的就可以了。
图 1 研发效能度量指标分类
接下来，我就直接和你推荐度量效能的一个原则和四个使用方法。

效能度量的原则

效能度量不与绩效挂钩，是正确使用效能度量最重要的一点，再怎么强调也不为过。所以，我向你推荐的效能度量的原则就是：效能度量不要与绩效挂钩，而应该作为参考和工具，帮助团队提高效能。
因为无法覆盖 100% 的度量指标，把度量与绩效挂钩就一定会产生“做数字”的现象。这时，使用效能度量非但起不到正面效果，还会对公司和团队造成伤害。管理者常常倾向于使用度量与绩效挂钩这种方法，是因为它能具体到数字方便管理。这种错误，我们一定要注意避免。
如果你只能记得这篇文章的一句话，那我希望这句话是“效能度量不要与绩效挂钩”。
Facebook 就刻意避免把效能度量跟绩效挂钩。比如，代码审核相关的效能度量页面，并没有包括审核的提交个数、代码审核的时长、代码审核通过率这些常见指标。
如果有团队提出要获取这些数据，那么我们工具团队只会提供一些脚本，由团队主管自己去获取所需数据，而且获取的方式并不那么方便。同时，团队成员也不能在 Phabricator 网站上直接看到这些数据。
这是一个比较典型的主动避免度量，从而避免它与绩效挂钩的例子。
不能把效能度量与绩效挂钩，那怎样才能使用度量提高效率呢？答案是：提供度量作参考和工具，帮助团队提高效能。
度量一旦与绩效脱离关系，就可以作为重要参考和工具，帮助团队持续进步。比如，下面这些度量指标:
缺陷密度，可以让团队了解产品质量的走向。
新旧 Bug 占比，一定程度上可以反映技术债的严重程度。
即使是代码行数这样臭名昭著的度量指标，如果只是用作参考，都可以帮助团队和成员提高。
在 Facebook，有超过 4 套的数据展示面板工具。这些面板工具使用起来非常灵活，开发人员可以定制面板，展示对自己有价值的效率度量，比如上线前高优先级 Bug 数、未完成 Bug 数、燃尽图等。我们每个团队都是主动使用这些面板，来帮助团队达成业务目标。
下面，我就来向你推荐 4 个度量使用方法。

效能度量的推荐方法

第一，目标驱动，度量对的事

提供用户价值是公司存在的根本，因此与之相关的指标是最最重要的。这一点非常好理解。从这个角度来看，以下几个相关度量指标比较有效：
净推荐值 (Net Promoter Score，NPS)，是通过调研了解用户满意度，实用性很强。如果你不了解的话，可以看一下这篇文章对 NPS 的介绍。
系统 /App 宕机时间 (System/App Downtime) 和严重线上事故数 (Incidents)，衡量的是系统的可用性，通常与用户价值直接挂钩。
热修复上线时间 (Hotfix Time)，指的是一个热修复从编码完成到部署到生产的时长，关系到解决重大缺陷的效率，与用户价值强相关。
我的建议是，你可以再去看看准确度的其他衡量指标，根据团队情况，找到能够最直接衡量产出有效性的指标，而不是一定要采用上面这 3 个指标。

第二，先从全局上找瓶颈，再深入细节

前面提到过，在度量效能时，很多团队往往是一上来就不加辨别地扎到某几个竖井里去寻找问题。这样的局部优化往往对全局优化无效，还会影响团队之间的关系，带来负面效果。正确的做法应该是，先检查全局，找到关键瓶颈之后，再进入细节分析和解决的环节。
具体实现起来，方法也很简单，就是收集产品周期中每一个阶段所占用的时间，包括计划的时间和最后实际花费的时间，然后寻找问题最大的地方。
具体的耗时收集方法，大致有两种：
人工收集。比如，文章开头提到的项目经理手工收集研发过程中每环节的耗时。
通过工具收集。比如，Trello 的任务显示看板，或者 Jira 的看板，都可以清楚地看到每个环节有多少任务以及流动情况，从而直观地识别瓶颈。
收集到了每环节的耗时之后，下一步就是去发现瓶颈。除了直观的观察之外，我推荐一个工具：累积流程图（Cumulative Flow Diagram)。具体方法是：横轴是日期，纵轴是每天统计的各节点任务数量，绘制出来就形成了累积流程图。比如，我们统计待办（Backlog）、开发（Dev）、测试（Test）、生产（Production）这几个节点，累积流程图如下所示：
图 2 累积流程图示意图
从水平方向看，待办和生产这两条线的距离就是交付时间（Cycle Time），也就是从开始开发到交付的时长。垂直方向的距离代表 WIP，也就是系统中的任务数。通过这张图，我们就可以一目了然地看到任务在流程中的流动情况，并直观地发现问题。比如，WIP 数值变大大、交付时间变长通常都代表研发效能下降。
可以看到，累积流程图对于查找全局瓶颈非常有用。实际上，我们还可以通过它预估发布日期，查看开发是否被阻塞等。这里有一篇文章，讲述了如何通过累积流程图，找到问题并进行调整，供你参考。

第三，通过主观的方式来评价、提高效能

没有客观的方法去衡量开发人员的生产效率，并不意味着你无法衡量它。 一个办法是，你可以尽量公平地去主观地测量它。事实上，平时工作中我们也确实是这么做的。
比如，在一个团队里面，大家通常都能对谁是技术大牛达成共识。这是我们的大脑依据平日收集的点滴事实做出的判断，也是因为当前还没有 AI 系统能够自动做出这样的分析，才显得非常主观。
所以，我推荐收集人工反馈的办法，来帮助我们做出尽量公平的主观评价。
针对研发环境、流程、工具的效能进行评价，可以使用公司成员对研发效能满意度的净推荐值。虽然现在还没有很强的理论依据可以证明，这个指标可以大幅提高研发效率，但从我看到的许多真实案例来说，事实确实如此：满意度让员工工作更积极，而工作积极又能提高满意度，是一个良性循环。
我在 Facebook 内部工具团队工作时，我们每个季度都通过调查问卷收集开发人员的建议，另外，我们还有 IRC 聊天室类似的工具供讨论和吐槽。这些反馈，都会成为工具团队调整工作内容和优先级的依据。
至于调查问卷的内容，具体来说可以关注以下这几个方面：冲刺的准备充分度、团队沟通有效性、冲刺过程效率、交付价值如何、交付信心如何、对产品方向及路线的兴奋度等。
针对个人研发效能作评价，可以采用类似 360 度绩效考评的方式来收集同事之间的评价。评价的标准基于在用户价值输出上做出的贡献，包括自身产生的价值，以及帮助团队成员产生的用户价值。如果一个员工可以很好地产出用户价值，那他的研发效率通常不会差。其实，Facebook 就是使用这种方式来评价员工效能的，虽然主观但很公正。
我整理了一张表格，列了一些可以用来收集反馈的问题，涵盖开发效率、质量、团队贡献等方面。
图 3 可以用来收集反馈的问题

第四，关注个人维度的指标提高效能

个人效能相关的度量，直接反映开发人员的开发效率和满意度，对团队产出影响很大。所以，作为管理者 / 内部效能团队，应该关注开发人员的高频活动，并自动化和优化这些步骤，让开发人员能专注开发。
一般来说，“个人调测环境构建速度”是一个比较重要的指标。它描述的是开发人员在本地做好一个改动，到能够进行本地调测的时长。开发人员每次修改自行验证都要经历这个步骤，对它进行优化非常有用。
我以前在 Facebook 的时候，后端代码及网站的绝大部分修改都可以在一分钟之内在本地开发机器上使用线上数据进行验证，非常爽快，效率极高。
但是，我曾经在其他公司见到过这样一种情况：一个修改需要在本地编码，上传到服务器编译，再通过工具下载到另外一个机器上验证。这个过程至少需要一个小时，在这种情况下，即使是在验证时发现一个简单错误，修改后简单验证也需要再花费一个小时。
不难想象这种情况下开发者的沮丧心情。如果能解决个人效能维度上的痛点，必然对提高产出和士气有重大作用。

小结

好了，这就是我今天要和你分享的效能度量的指标和方法了。接下来，我与你总结下今天的核心知识点。
首先，我将度量指标分为了准确度、速度、质量和个人效能 4 个方面，并列举了 40 多个具体指标。然后，我根据软件研发以及效能度量的特点，给出了 1 个原则和 4 种建议的度量方法。原则是不要与绩效挂钩；度量方法包括：目标驱动，度量对的事；先从全局上找瓶颈，再深入细节；通过主观的方式来评价、提高效能；关注个人维度的指标提高效能。
我把这 4 种方法，以及基本思路总结成了一张表格，方便你理解与记忆。
图 4 4 种推荐的度量方法
研发效能的度量很灵活，也很容易踩坑。所以，我希望上面的这些原则和方法能够作为你实施度量的参考，从而达到以下几个目的：
跟踪团队的表现、提高团队的绩效；
提高项目计划的精确度；
了解流程是否高效，寻找需要改进的关键领域。
最后，我来分享一下我个人对效能度量的两大感受：
度量只是工具，不是目的。切记度量的真正的目标是提高效能，不要舍本逐末。比如说，如果度量花费的时间超过了收益，那就不要去做。
虽然我们推崇数字驱动，但在效能的度量上，不要迷信数字，适当使用主观反馈效果反而更好。

思考题

你能从下面这张累积流程图中，看出什么问题吗？
感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 9

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
02 | 效能度量：效果不好甚至有副作用，怎么回事？
下一篇
04 | 流程优化：怎样才能让敏捷、精益真正为我所用？
 写留言

精选留言(34)

  • 陈磊@Criss
    2019-08-28
    问题：dev工作block了

    作者回复: 对啦。厉害！

    共 2 条评论
    10
  • Xin
    2019-08-28
    需求评审完后在开发过程中频繁加需求及修改，开发过程中不停应对不同部门的咨询打断各种都强调优先级，这是最痛的😂

    作者回复: 这个问题在开发资源被共享的情况下的确是很常见，也很棘手。我看到有两个可能的处理办法，第一个是。有一个统一的接口人来对接这些优先调节优先级的要求，挡住一些，并且根据全局情况进行合理调节。第二个方法是改变开发资源的共享方式，从按智能划分团队，转变成按产品划分团队，或者是矩阵式管理。

    共 3 条评论
    7
  • 囧囧冰淇淋
    2019-08-28
    老板：效能度量不能与绩效挂钩，那我怎么知道你们提高了啊？我现在看到的就是，我们的产品经常上不了线，产品部和运营部那边经常抱怨。我看了下XXX公司（同行但非顶尖），他们用的这套绩效考核很有用，我们要多向他们学习学习，这套指标先定下了。 在小公司比较容易发生，老板会拿比自己好一些的同行对比。大公司不知道会不会发生这种质疑：因为业务的进展缓慢，从上至下产生不信任感，导致团队开始埋怨和打混。 以下是自我理解： 老板： 1.需要开明，问题可以从外部去参考，但不能直接套用到团队上，要考虑公司整体情况。比如需求经常被更改，经常着急上线，那就要把产品，运营，软件一起叫进来讨论，坚决抵制互相甩锅，而是每个团队做哪些可以便利下一个部门效率，形成一个整体提升。 2.允许员工反对，倾听员工的想法，让相关人员围绕问题一起谈谈，可以不用马上得到答案，把它当成一种倾听、持续改进的沟通方法。 3.允许一定的失败，小公司是在磕磕碰碰中长大的，经验欠缺，人员不齐，不要出了问题就大骂一通。 4.关心员工，成功或者失败了，大家都付出了努力，还可能经常加班，加班可是没有工资；失败后的大骂，成功后的轻描淡写都让给团队丧气。 5.提供一些工具或者课程帮助员工。 6.公司和团队成长后提供更好的待遇。
    展开

    作者回复: 从我的经验看，对开发工作，绩效考核通过360反馈，通过相对主观的方式，反而比较有效。

    共 7 条评论
    5
  • Johnson
    2019-08-28
    本地构建是指的工程师在自己的笔记本上？还是说工程师通过本地笔记本登录到的开发服务器上？工程师的笔记本环境有可能有多种，比如有的同事入职时选的PC，有的选的MAC，如果在笔记本上构建，那这个环境很不好维护啊

    作者回复: 本地构建指的是在自己的开发机器上，也就是代码所在的地方进行构建。如果代码是在远程的开发服务器上，那这个本地指的就是远程的服务器，如果代码是在笔记本上，那这个本地就是笔记本。 在你的例子当中，如果大量的开发都是在笔记本上进行的。那么虽然环境维护有一些麻烦。还是很值得投资的。大不了在Windows上面做一套环境，在Mac上面做一套环境。具体方法，最直接的是使用脚本自动化。 另外这个环境最好和你们的生产环境保持一致。避免在本地构建出来的东西，在生产环境上会出现因为环境不同而造成问题。

    共 3 条评论
    5
  • 舒偌一
    2019-08-28
    大概在11前产生了大量的bug，之后在修改之前的任务，dev没有接受新任务。

    作者回复: 答对了！赞

    3
  • Geek_eddy
    2019-08-28
    本地开发机使用线上数据验证对开发来说确实很爽，Facebook是如何保证线上数据安全性？

    作者回复: 这一部分我也不是特别了解细节。但是知道主要原则大概有几个： 1. 数据库中都有特定的Field指出是否是测试数据 2. 能够快速恢复。这个是基本 3. 强大的监控。开发人员账号触碰到生产数据，如果是TA本人不应该有权限的，必须要有任务ID才能有Access。这些行为都会被记录下来。

    共 2 条评论
    3
  • 小炭
    2019-12-14
    问下，调查问卷有推荐的方法和工具吗

    作者回复: 方法的话NPS不错：https://community.verint.com/b/customer-engagement/posts/net-promoter-score-nps-criticisms-and-best-practices 国内的问卷星还是不错的。

    2
  • witluo
    2019-08-28
    看质不看量，都是耍流氓
    共 3 条评论
    2
  • 传说
    2019-08-28
    思考题分析啊～ 1.dev休假 2.购买了软件产品 3.需求做不了

    作者回复: 从图上看到的是开发被阻塞了，没有接受新的开发任务。你这个直接给出开发被阻塞的三个可能原因，哈哈，厉害 ：）

    2
  • xin1195
    2020-05-20
    研发效率的提升来源于这样的一个个小的优化点，看起来小，但是对效率提升确实很大。应该给与足够的重视。 这个列子让我想起在工作中遇到的同类型案列：当时在shein工作时，由于灰度环境只有一个，每次发版都的协调灰度环境的使用权和使用时间，如果前面的使用者超时，就会导致我们的灰度测试时间不够，甚至影响到我们的上线时间。而且每次灰度测试的发布时间都在半小时以上，非常影响到研发测试的效率。当时也和公司提过在搭一套灰度测试环境，但是公司给的回复是非常麻烦，也就不了了之，现在想想，是自己当时的认知不够，不能从更高的角度看待这个问题，才会导致可以改善的点，因为一点点挫折，就放弃了。反思：全体员工的认知不够，是导致这个问题长期存在的关键。
    展开

    作者回复: 在一个环境时间时间长，往往会习惯当下的环境，觉得常态就是这样。这个时候就需要能够跳出来。推荐阅读关于黑客之道的内容：https://time.geekbang.org/column/article/162869。

    1
  • 章皓
    2020-05-16
    老师，关于累积流程图由几个问题请教： 1、请问有什么工具比较方便产生这个累积流程图 2、纵轴的任务数量，由于任务有大小之分，统计时应该是每个任务有时间估算，然后估算时间加总作为纵轴数值；要画出这个图需要需求，开发，测试都做好时间估算才行；目前在团队中，大家都不太愿意花时间去做估算工作

    作者回复: （不好意思回复较晚。最近特别忙） 1.1 In Jira: https://confluence.atlassian.com/jirasoftwareserver/cumulative-flow-diagram-938845656.html 1.2 Excel 模版：https://hakanforss.wordpress.com/2011/06/17/cumulative-flow-diagram-how-to-create-one-in-excel-2010/ 2. 关于任务大小不同，实际上，任务大小不会影响从中观察交付周期、WIP等数据。事实上你可以从图中看到不正常的情况，倒退回去查看当前是不是有和其他任务大小差别很大的任务存在。 如果希望看到稳定的flow，如果团队任务数量多的话大小，这些任务的平均值会减少影响。如果还是不行的话，有两个办法，第一就是要估算工作量然后进行加权，但是更好的一个办法是在任务拆分时大小差别不要太大。 另外，画这个图的时候，是根据已经发生了的情况进行统计，不需要事前估算。只需要一个人搜集历史数据制作这个图即可。

    1
  • 二狗
    2019-09-30
    在编码和编码设计以外消耗的时间，主观感受浪费的时间占工作时间的大多数

    作者回复: 这个是比较常见的一个状态 😟 团队管理者在这个方面比较能够进行改变。作为个人，也能做一些努力，我在后面的个人效能部分会给一些建议，比如深度工作，多了解业务等。

    1
  • 寒光
    2019-08-28
    整体审视，发现局部问题。 以终为始，不拿度量数据做考核。 工具辅助，人工度量相结合。 没有银弹，找到适合自己的。 想问下老师，像传统的企业软件或者IT管理类软件，用户体验指标往往反映不出真实的价值，因为极端点讲，强调的是管控，体现的是企业管理者意志。开发人员往往是初级程序员，创造性要求也不那么高，所以，很容易让管理者进行“量化管理”，于是，各种管控指标就出台了，但往往违背了初心。关于这类情况的度量指标，老师是否有相关的建议？因为它和互联网软件的确有太多的不一样。
    展开

    作者回复: 用户体验好，应该长期会和销量挂钩吧。 退一步说，如果用户体验指标反映不出真实的价值，那就说明用户体验不重要，这个时候就需要寻找到真正的价值去衡量产出。在你们的具体情况下，产品的什么方面是真正的价值？

    1
  • 李双
    2019-08-28
    学习！每个方面都是内功和外功的修炼！

    作者回复: 👍👍

    1
  • 金阳光
    2021-11-03
    1.研发10-15号集体隔离 2.研发大佬带团队被竞争对手集体挖走了
  • Alex
    2021-03-24
    您好，能否介绍下您列举的度量指标，每个是什么含义，如何度量。谢谢
  • 刘威
    2021-02-06
    葛老师，这里准确度里面： 工单返工率： 用户支持工单数 冲刺准备充分度 冲刺健康程度 这几个是啥意思呢？和业界的好像不太一样？
    展开
  • Joey
    2021-01-01
    更新下之前的问题：如何衡量一个研发组织的创新度？请老师指导下，谢谢
  • Joey
    2021-01-01
    请教老师：怎么衡量一个组织的创新程度？
  • iMARS
    2020-10-23
    对于360°打分，应该以全流程和系统的监控、度量作为前提，否则主观打分都会变成你好、我好、大家好的状况，团队的研发效能并未真正提高。~个人浅见。

    作者回复: 是的，管理层从上到下都要对下级给别人写考评的质量进行管控。否则会出现一团和气的情况，这样就失去了价值。