研发效率破局之道03 | 如何选对指标与方法,真正提升效能?

你好,我是葛俊。今天,我来和你聊聊如何正确使⽤效能度量。 
在上⼀篇⽂章,我给你介绍了效能度量的定义、作⽤,以及⼏个使⽤误区。我们先简单回顾⼀下: 
  • 软件系统异常复杂,度量指标⽆法覆盖其所有参数,从⽽容易被“数字游戏”欺骗。 
  • 竖井指标的提⾼不等于全局指标的提⾼,局部优化不等于全局优化。 
  • 研发效能度量指标⼀般⽤来衡量软件产品的⽣产过程和产品质量,但公司真正需要关注的是能否产⽣⽤户价值。这两者之间存在着难以跨越的鸿沟。
正是因为这种种看似难以解决的问题,业界甚⾄有⼈认为研发效能的度量是⼀个⽆解的问题。但我并不这样认为。如果使⽤得当,效能度量可以给公司的研发 带来⾮常⼤的好处。 
举⼀个真实的例⼦。国内⼀个⼤概 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 个度量使⽤⽅法。 
效能度量的推荐⽅法 
第⼀,⽬标驱动,度量对的事 
提供⽤户价值是公司存在的根本,因此与之相关的指标是最最重要的。这⼀点⾮常好理解。从这个⻆度来看,以下⼏个相关度量指标⽐较有效: 
1. 净推荐值 (Net Promoter Score,NPS),是通过调研了解⽤户满意度,实⽤性很强。如果你不了解的话,可以看⼀下这篇⽂章对 NPS 的介绍。 
2. 系统 /App 宕机时间 (System/App Downtime) 和严重线上事故数 (Incidents),衡量的是系统的可⽤性,通常与⽤户价值直接挂钩。 
3. 热修复上线时间 (Hotfix Time),指的是⼀个热修复从编码完成到部署到⽣产的时⻓,关系到解决重⼤缺陷的效率,与⽤户价值强相关。 
我的建议是,你可以再去看看准确度的其他衡量指标,根据团队情况,找到能够最直接衡量产出有效性的指标,⽽不是⼀定要采⽤上⾯这 3 个指标。 
第⼆,先从全局上找瓶颈,再深⼊细节 
前⾯提到过,在度量效能时,很多团队往往是⼀上来就不加辨别地扎到某⼏个竖井⾥去寻找问题。这样的局部优化往往对全局优化⽆效,还会影响团队之间的 关系,带来负⾯效果。正确的做法应该是,先检查全局,找到关键瓶颈之后,再进⼊细节分析和解决的环节。 
具体实现起来,⽅法也很简单,就是收集产品周期中每⼀个阶段所占⽤的时间,包括计划的时间和最后实际花费的时间,然后寻找问题最⼤的地⽅。 
具体的耗时收集⽅法,⼤致有两种: 
1. ⼈⼯收集。⽐如,⽂章开头提到的项⽬经理⼿⼯收集研发过程中每环节的耗时。 
2. 通过⼯具收集。⽐如,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 种推荐的度量⽅法 
研发效能的度量很灵活,也很容易踩坑。所以,我希望上⾯的这些原则和⽅法能够作为你实施度量的参考,从⽽达到以下⼏个⽬的: 
  • 跟踪团队的表现、提⾼团队的绩效; 
  • 提⾼项⽬计划的精确度; 
  • 了解流程是否⾼效,寻找需要改进的关键领域。
最后,我来分享⼀下我个⼈对效能度量的两⼤感受: 
1. 度量只是⼯具,不是⽬的。切记度量的真正的⽬标是提⾼效能,不要舍本逐末。⽐如说,如果度量花费的时间超过了收益,那就不要去做。 
2. 虽然我们推崇数字驱动,但在效能的度量上,不要迷信数字,适当使⽤主观反馈效果反⽽更好。 
思考题 
你能从下⾯这张累积流程图中,看出什么问题吗? 
感谢你的收听,欢迎你在评论区给我留⾔分享你的观点,也欢迎你把这篇⽂章分享给更多的朋友⼀起阅读。我们下期再⻅!

发表评论

您的电子邮箱地址不会被公开。