研发效率破局之道02 | 效果不好甚至有副作用,怎么回事?

你好,我是葛俊。今天,我来和你聊聊研发效能的度量。 
在和技术管理者,尤其是⾼层管理者聊起研发效能的时候,常常提起效能的度量这个话题。管理学⼤师彼得 · 德鲁克(Peter Drucker)曾经说过,“⼀个事 物,你如果⽆法度量它,就⽆法管理它”(If you can’t measure it, you can’t manage it)。要想提⾼研发效能,⾃然要⾸先解决效能的度量的问题。 
在软件研发过程中,数据驱动的⼿段被⼤量采⽤,⽐如说通过使⽤漏⽃指标和 A/B 测试,⽤数据来指导产品的⽅向。按理说,软件开发⾏业是数据驱动的⾼ ⼿,⽤数据驱动来理解研发效能应该早被研究透了啊。 
但事实上,效能的度量却是⼀个出了名的难题,⾄今没有哪个公司敢号称已经找到了效能度量的完美答案。不仅如此,绝⼤部分软件公司在使⽤研发效能度量 这个⼯具时,不但没有起到正向作⽤,还伤害了产出和团队氛围。 
所以,在今天这篇⽂章中,我就与你⼀起看看研发效能度量到底是什么、常⻅错误,以及度量困难的原因。 
研发效能度量的定义和作⽤ 
⾸先,我来介绍⼀下效能度量的定义和作⽤。 研发效能的度量代表⼀组可量化的数据或参数,⽤来跟踪和评估开发过程的“健康”状况。 换句话说,研发效能的度量,从应⽤程序开发的⽣命周期中获取数 据,并使⽤这些数据来衡量软件开发⼈员的⼯作效率。我们希望通过这样的度量,能够根据客观的数据⽽不是个⼈的主观意⻅去决策,从⽽实现以下⼏点: 
1. 跟踪团队的表现、提⾼团队的绩效。通过确定研发效能指标,公司可以明确团队和成员的⼯作预期,从⽽使得开发⼈员能够⽬标性更清晰地投⼊研发。同 时,这些⽣产指标可以作为“晴⾬表”,帮助团队定位影响⼯作效率的不良因素,从⽽帮助团队消除这些因素,最终达到团队更快乐、绩效更⾼的⽬的。 
2. 提⾼项⽬计划的精确度。团队负责⼈可以通过度量来估算⼀个需求端到端的成本,包括收集成本、设计系统成本、开发测试成本,以及运维成本等,来了 解每项活动在项⽬总成本中的占⽐,从⽽更好地确定这些活动的优先级。同时,我们可以了解哪些步骤有较⼤⻛险和不确定性,从⽽提⾼预测项⽬进展的 精准度。 
3. 了解流程是否⾼效,寻找需要改进的关键领域。我们可以衡量进⾏每项研发活动所需的时间,并估算其对质量和⽣产效率的影响,然后⽐较成本和收益, 最终确定哪些步骤是⾼效的,以及哪些步骤是需要改善的。我们还可以对不同的实践进⾏ A/B 测试,以此来选择更好的⽅法。 
提⾼团队绩效、提⾼计划精确度,以及寻找关键的待改进领域,这三个因素的结合有助于简化⼯作流程,发现瓶颈,帮助团队持续改善现有产品的⽣命周期, 从⽽更⾼效地⽣产出质量更好的产品。 
效能度量的错误案例 
因为上述作⽤,绝⼤多数公司都⾮常重视研发效能的度量,并且基本上所有公司都或多或少地采⽤了度量。但遗憾的是,能够将其⽤好的公司少之⼜少,⽽且 我⻅到的公司中还存在⼤量误⽤的情况。 
接下来,我与你分享⼀些真实案例,我们⼀起来看看它们错在哪⾥,以及可以如何调整。 
案例 1:全公司范围内推⾏⼀套效能度量指标 
某⼤型公司为了提⾼效能,专⻔成⽴了⼀个不⼩的团队,通过详细调研,制定了⼀组研发效能度量指标,并引⼊和开发了相应的⼯具。客观来讲,这些度量⽅ 式的质量很⾼。 
准备就绪后,这个公司找了⼏个团队做试点,把这些效能度量数据作为参考提供给它们使⽤。三四个⽉下来,试点效果不错,这⼏个团队的产出速度有了⼀定 的提⾼。于是,公司⾼层决定在全公司范围内推⾏这套⽅案。 
但,随着⼤范围的推⼴,⼀些团队发现,它们的研发流程跟试点团队差别较⼤,需要花费相当多的时间去收集度量数据,受益却不明显,甚⾄是得不偿失。 
更极端的情况是,有⼀个团队的开发环境和这套效能度量⼯具的环境差别实在太⼤,所以不得不专⻔为这个⼯具部署了⼀个环境。然后每周六,他们就要到这 个环境⾥,为度量系统提供数据,还常常被迫提供⼀些“假数据”,以满⾜度量系统的需求。 
因此,这些团队觉得这套⽅案并不适合⾃⼰,公司内逐步出现了些许反对声⾳。但是,公司推进这套流程的态度⾮常强硬,为了顺利推进,还把这套流程与团 队绩效绑定到了⼀起。⼀旦某个团队的指标未能达到要求,就直接实⾏绩效扣分。由此,效能度量的负⾯作⽤逐渐凸显。⼤量团队为了好的绩效,⽽被迫去玩 数字游戏。 
全公司范围推⾏这套⽅案的⼀年多,可以说是怨声载道。明明是⼀套⾼质量的度量系统,却阻碍了团队业务的发展,并严重伤害了员⼯的积极性。直⾄最后这 个实际情况被反馈到⼀位⾼管那⾥,这套度量系统才被完全取缔。 
案例 2:⼀个中型公司推⾏质量⽅⾯的指标 
⼀个 500 ⼈左右的公司,公司的组织架构按照职能进⾏⽔平划分,并没有进⾏矩阵式管理。为了提⾼公司的产品质量,QA 团队提出了⼀组软件质量⽅⾯的 度量指标,包括 Bug 严重性定义、每⼀个发布⾥不同级别的 Bug 的未解决率,以及上线的⼀些质量流程。QA 团队得到了公司⾼层的⽀持,强制推⾏这些指 / 标。 
这些指标针对的主要是开发活动,但开发团队却认为,这些度量⽤处不⼤。他们认为,公司研发过程中的真正问题在于产品定义变化过快,常常是在冲刺开始 后还不断更改需求。这就导致开发和测试团队即使拼命加班还常常错过发布⽇期,产品的 Bug 也不少。所以,开发团队提出,真正应该度量的是产品需求的 稳定性。但是,公司⾼层认为需求变化是为了满⾜⽤户需求,所以没有批准开发团队的这个要求。 
结果是,研发⼈员觉得公司效能度量只是⽤来束缚他们的,根本不能帮助他们⼯作,于是⼯作积极性下降,离职率上升。同时,产品质量也并没有因为这些度 量指标的推⾏⽽提⾼。直到我写下这篇⽂章的时候,这个公司还是这个情况。 
案例 3:某创业公司聚焦度量开发、测试、上线准确度等指标 
⼀个由 10 多个⼈组成的、拿到了 Pre-A 投资的创业公司,正处在研发产品寻找市场吻合度的阶段。掌权的 CEO 和产品副总坚信数据驱动,于是对研发流程 定义了严格的度量和指标,⽐如 App 上线周期准时率、Bug 的关闭速度、性能参数,等等。 
整个团队很专业,也很敬业。他们花了很多精⼒去严格完成这些度量指标,做到了绝⼤部分情况下准时、⾼质量地上线产品。但是,CEO 和产品副总并不是 产品专家,只关注了开发过程中的数据,却没有收集其他步骤的数据去快速试错和寻找产品⽅向。 
结果就是,虽然产品的每⼀个发布都很准时,质量也⾮常⾼,但因为公司在寻找市场需求吻合度⽅⾯动作迟缓,导致⽤户增⻓缓慢。因此,⼀年半以后,资⾦ 耗尽,投资⼈失去信⼼,公司倒闭。 
这 3 个案例只是不同规模公司的⼏个典型场景,类似的失败案例数不胜数。那么,上⾯这些案例的问题出在什么地⽅?效能度量为什么这么难? 
效能度量被⼤量误⽤,问题究竟出在哪⼉? 
研发效能难以度量的最根本原因在于,软件开发⼯作是⼀项创造性很强的知识性⼯作,⾮常复杂且伴随有⼤量不确定因素。 
⽐如,软件产品的需求变化很快,需求⽂档的更新常常滞后于⼯程实现,甚⾄有的敏捷⽅法论提倡完全抛弃需求⽂档。 
⼜⽐如,软件产品的实现⽅式有很⼤的不确定性。⼀个相同的功能,可以采⽤多种语⾔、框架、平台,使⽤各种不同的研发流程⽣产出来。在这种情况下,我 们很难通过度量来衡量这些不同研发⽅法和中间过程的优劣。 
⾯对这样的⼀个复杂系统,我们不可能覆盖其全部参数。⽽如果这时,研发⼈员的利益和这个度量结果相关,那么他就很可能会通过“做数字”来欺骗度量系 统。 
关于这个主题,美国著名学者罗伯特 · 奥斯汀(Robert Austin)写过⼀本书,叫作《衡量和管理组织绩效》(Measuring and Managing Performance in Organizations) 。他在这本书中给出的结论是,如果你不能度量⼀个事物的所有⽅⾯,那就不要去度量它。否则,你将得到“做数字”的欺骗⾏为。 
这⾥有⼀组有名的 Dilbert 漫画,讲的是⼀个公司宣布使⽤ Bug 修复数量做度量,每修复⼀个 Bug 奖励 10 美元,消息⼀出,开发⼈员欢呼雀跃。⼀个程序 员当场表示,当天下午就要给⾃⼰写出⼀辆汽⻋,因为他很容易就可以写出很多简单的 Bug,然后⻢上去修复它们。 
通过这个例⼦,我想要和你说明的重点是:度量与绩效挂钩,结果是指标上去了,却没给软件产品带来任何好处。 
备注:图⽚来⾃网络
⽽我刚刚和你举的⼤型公司全公司范围内推⾏⼀套度量指标的案例,正是犯了度量与绩效挂钩的错误,这种情况下,很容易出现“做数字”的不良⾏为。这也是 使⽤度量时最常⻅的错误,我们⼀定要留意。 
研发效能难以度量的第⼆个原因,和上⾯提到的根本原因相关,但有其特殊性。很多公司有竖井(silo)存在,所以常常会把注意⼒放到某⼀两个竖井上,进 ⾏局部优化。但是,局部优化并不代表全局优化,甚⾄会让全局恶化。 
上⾯那个中型公司推⾏质量⽅⾯指标的案例,就是在进⾏局部优化,不但没能提⾼产品质量,反⽽导致员⼯积极性受损,同时影响了团队之间的关系。 
这样的问题,在按职能划分团队的公司很容易出现。因为在这样的组织划分下,更容易出现竖井,⾃然就更容易按照竖井来考虑⼩团队的表现。如果你的公司 基于职能划分,⼀定要多加留意。 
研发效能难以度量的第三个原因在于,度量指标⼀般⽤来度量软件产品的⽣产过程和产品质量,但是公司真正需要关注的是产品能否解决⽤户问题,也就是说 能否产⽣⽤户价值。技术产品输出和⽤户价值输出之间的沟壑难以打通。 
上⾯案例中那家创业公司聚焦度量开发测试指标,就是犯了这样的错误。产品质量再好,发布再准时,如果没有⽤户价值也是⽩费⼯夫。 
当然了,研发效能难以度量还有⼀些其他原因,⽐如: 
  • 度量数据的收集难易程度不同,人们倾向拿容易收集的数据去关联效率,但事实上难以收集的数据对度量可能才真正有用。比如说代码行数容易衡量,但是用处很小。相比之下,产品用户价值的度量要困难得多,但用处却大得多。
  • 软件开发和实践有一个滞后效应。比如,在团队中引入代码审查,在刚开始实行的时候,总体效率会出现短时间的下降,一两个月后才会逐步显现正面效果。那么,你现在要怎么度量它才好呢?
总结 
在今天的分享中,我给出了效能度量的定义及作⽤,列举了三个典型的失败案例,并通过这⼏个例⼦和你详细分析了度量困难的⼏个主要原因。 
研发效能的度量⼀直以来都是个难题,很多业界⼤佬也都发表过“研发效率不可度量”的观点。⽐如,⻢丁 · 福勒(Martin Fowler)在⼀篇叫作“⽆法衡量⽣ 产效率”(CannotMeasureProductivity) 的⽂章中指出:这是我认为我们必须承认⽆知的地⽅。 
周思博(Joel Spolsky)在⼀篇名为“飙⾼⾳”(做到最好,Hitting the High Notes)的⽂章中写到,衡量程序员的⼯作效率相当困难,原因如下: 
  • 几乎任何你能想到的指标(比如,调测过的代码行数、功能点、命令行参数的个数)都很容易被“做数字”;
  • 我们极少要求两个程序员做完全相同的事情,所以很难获取大型项目的有价值度量数据作为参考。
那是不是说在研发软件时,我们就不能使⽤度量效能的⽅法来指导⼯作了呢?如果是的话,这对于软件团队管理者⽽⾔,将会是⼀个难以接受的事实。 
这个问题的答案,我们就留到下⼀篇⽂章再揭晓吧,敬请期待。 
思考题 
你在⼯作中有没有经历过研发效能度量的失败案例?如果有的话,你觉得失败的原因是什么?关于度量谜题怎么解决,你有没有什么建议? 
感谢你的收听,欢迎你在评论区给我留⾔分享你的观点,也欢迎你把这篇⽂章分享给更多的朋友⼀起阅读。我们下期再⻅!

发表评论

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