关于研发管理:困在系统里的研发效能度量该如何自救-IDCF

9次阅读

共计 4014 个字符,预计需要花费 11 分钟才能阅读完成。

之前读了一篇文章:“外卖骑手,困在零碎里”,引发了我很多的思考,起初有幸和作者有过一次交换更是让我印象粗浅。而后我写了一篇文章“如何用研发效力搞垮一个团队”引起了业界同行大量的探讨与关注,明天想借此持续来聊聊研发效力晋升过程中另一个无奈回避的的话题:“度量”。

一、历史上度量失败的案例

先看一张图,这是英国街头的屋宇,你可能好奇这些屋宇的窗户为什么都被封了起来。

这其实是“窗户税”所引发的不良后果。

1696 年之前,英国政府对于集体屋宇的税收采纳的是“壁炉税”,也就是依据屋内的壁炉数量来计算应缴税费的,这就要求税务员进屋查看,这无形中就减少了税收的难度,所以 1696 年之后,改为了计算窗户数量来计算应缴税费的“窗户税”,这样税务人员就不须要进门,能间接在街道上数窗户就行了。

面对此种“度量”伎俩,为了少缴税的房东也没闲着,除了买油灯、堵窗户以外,在屋顶开天窗也逐步风行了起来。后果,除了在暗淡的房屋里搞出了一大批近视眼,由此刺激了照明业和眼镜业的倒退外,税收机构简直满载而归。

二、身边度量失败的案例

再来看看咱们身边的案例:海底捞。

海底捞 CEO 张勇为了进步用户的满意度,一度在用餐体验方面花了很多心理,并要求服务员严格遵守。

比方只有是来吃火锅的戴眼镜的客人,都要给他一块眼镜布;杯子里的饮料低于 1 /3,就要连忙给客人加饮料;如果客人带了手机,把手机放在桌上,要连忙用一个塑料袋把它给套上。如果做不到,就扣服务员的服务分,最初间接反映在工资绩效上。

这样的“度量”体系设计间接导致了服务员为了绩效而一直地“骚扰”顾客。顾客吃完筹备走了不须要饮料了,不行,必须加满能力走。顾客不喜爱用塑料袋把手机套上,不行,我的地盘我做主,必须要套上。后果间接导致了一系列用户体验的问题。

其实,还有很多因为度量体系设计不当而引发“内卷”等不良行为的案例。如果想进一步理解,能够关注一下美国的历史学家杰瑞缪勒写的《指标陷阱》一书,保障你会“大开眼界”。

三、度量失败的根本原因

这些度量为什么都会失败呢?正如我在之前那篇文章中提到的,面对改革,最重要的并不是办法和技术的降级,而应该是思维模式的降级。咱们身处数字化的改革之中,须要转换的是本人的思维模式,咱们须要将工业化时代科学管理的思维彻底转为字节经济时代的全新思维。

对于软件研发效力的度量,绝大多数时候咱们都还在用工业化时代造成的治理理念来试图改良字节经济下的研发模式。时代变了,很多事物的底层逻辑都曾经变了,工业化时代造成的科学管理理念在字节经济的明天是否还仍然实用?值得咱们沉思。

四、研发效力度量的常见误区

上面咱们就研发效力度量过程中常犯的谬误来展开讨论,心愿能借此引发大家的思考。

4.1 应用容易取得的量化指标

度量数据收集的难易水平不同,容易收集的数据往往实用价值低(比方代码行),难收集的数据往往度量价值更高(比方:产品用户价值,NPS 等)。咱们通常有一种人造偏向,就是把焦点放在最容易量化的指标上,把它作为解决简单问题的抓手。用不了多久,人们就只器重那些可量化的指标,而疏忽那些不可量化的指标。

  • 首先,那些容易量化的主要指标(比方:代码行人天),会逐步排挤掉那些难以量化但十分重要的指标(比方:代码影响力)。
  • 其次,容易量化的指标(比方:集体工作时长)往往是部分指标,而难以量化的指标(比方:我的项目价值交付)往往是整体指标。部分指标更容易达成,工夫久了当前,部分指标就会排挤掉整体指标。
  • 最初,容易量化的指标(比方:缺点数量)往往是短期指标,而难以量化的指标(比方:长期品质)往往是长期指标。短期指标往往关注当下的绩效,属于“救火”的领域,而长期指标则属于“防患未然”的领域,人的短视很容易让短期指标排挤掉长期指标。

4.2 试图通过繁多维度进行度量

试图通过繁多维度去做度量也是十分不可取的,因为事物往往具备多面性,事物自身的复杂度就决定了度量也必须是全方位,多维度的。因而,咱们更应该建设度量的雷达图,从事物的多个维度来进行度量。雷达图中度量矩阵的设计要做让各个度量指标之间有互相牵制的作用,比方当你人为“粉刷”其中某个度量值的时候,其余的度量值将会“出卖”你。图中的度量雷达图就是一个很好的例子。

  • 当你的“缺点数量”低的时候,不能间接得出你写代码品质高的论断,而要联合“实现的需要点数”来做综合判断。
  • 当你的“加班时长”长的时候,不能间接得出你是高绩效员工的论断,而要联合“实现的需要点数”、“代码影响力”和“缺点数量”来做综合判断。

由此可见,如果你想同时人为优化所有指标,那简直是不可能的,这正是度量雷达图的魅力所在。

4.3 研发过程数据采集须要依赖人工录入‍

在企业中,度量数据的获取肯定要实现自动化,如果你的度量数据都依赖于工程师的手工录入来获取,一方面工程师会对此种工作模式非常恶感,另一方面会让后续的度量剖析齐全失去意义,因为人工录入的数据或多或少曾经存在了很多失真,而且很多数据的录入工夫是有很大参考价值的,如果数据不是实时获取,而是人工填充的,那么数据自身就失去了度量的意义。

在 Scrum 团队,有个很好的例子能够阐明这点。燃尽图是用来反馈迭代工作实现状况的全局视图,现实中的燃尽图应该是下图中的上半局部,然而理论我的项目中的燃尽图往往看起来更像下图中的下半局部。起因很简略,因为工程师不会实时去更新工作的实现状态,而是等到迭代快要完结的时候,批量集中地人工更新工作状态,所以燃尽图就成为了这种到了最初一天断崖式降落的样子。试想一下,这样的过程度量是不是就齐全失去了本来的意义,而且这些获取的数据也不能用来做进一步的剖析,因为工夫维度重大失真了。

要解决这一问题,必须让研发过程数据采集通过工具平台主动实现,而不能依赖人工录入,腾讯的“研发效力双流模型”就提供了很好的思路。比方在双流模型的反对下,当 feature 分支胜利合并到 master 的时候,就会被动触发需要状态的流转,从原来的“开发中”转到“待测试”,能够完满实现了“需要价值流”和“研发工程流”两者之间的联动。

4.4 将度量与集体 KPI 绑定

关于度量有一句名言是这么说的,你度量什么,就会失去什么,而且往往是以你所不期待的形式失去的。我始终说一句话,当你把度量变成了集体考核的时候,永远不要低估人们在谋求指标方面“创造性”,当然这个创造性是打了引号的。所以我始终拥护将度量与集体 KPI 绑定,因为度量自身很难做到主观和公正,如果间接作用于集体,而且强绑定集体绩效可能反而会事与愿违,容易导致工程师纯正面向指标去发展工作,而不是面向后果。

虽说不倡议将度量和集体绩效绑定,然而将度量和团队绩效绑定还是很有必要的,通过度量可能反馈团队宏观层面问题,进而能够采取有效措施去改良。要留神的是,团队度量仍然无奈做到主观和公正,然而这些不够主观和不够公正的因素能够在团队 lead 层面进行弥补和调整。而后在团队外部消化掉。

4.5 把度量当成指标
度量从来不是指标,而应该是实现目标的伎俩。度量是为指标服务的,所以好的度量设计肯定对指标有正向牵引的作用,如果度量对指标的负向牵引大于正向牵引的话,这样的度量实质上就是失败的。

举个例子,当初国内很多软件企业都应用 Sonar 来实现代码动态品质的把控,为了推动 Sonar 在团队内的遍及,不少企业会用“Sonar 我的项目接入率”这样的指标,也就是有多少百分比的我的项目曾经在继续集成 CI 中启用了 Sonar,来掂量动态代码查看的普及率。这个指标看似中肯,实际上对于实现最终目标的牵引力是比拟无限的。应用 Sonar 的最终目标是晋升代码的品质,只是接入 Sonar 并不能理论改善代码的品质,而且还容易陷入为了接入而接入的指标比赛。了解了这层逻辑,你会发现应用“Sonar 重大问题的均匀修复时长”和“Sonar 问题的增长趋势”其实更有实际指导意义。

所以,一个好的度量,肯定要为解决实质问题服务,并且要可能疏导出正确的行为。

4.6 采纳“追星式”的度量

咱们看到一个人取得了胜利,就会立即认为他过来所有的行为都是那么地有情理。咱们看到一公司取得了胜利,就会感觉他们采取的策略和工程实际是如许无效。这正是“比拟思维”的可怕之处。实际上,没有哪家企业是通过盯住竞争对手而获得成功的。

OKR 在 Google 的胜利利用使得很多公司对此实际趋之若鹜,然而通过应用 OKR 取得成功的企业又有多少?这种“追星式”的度量只能让你陷入更深的内卷。

对于研发效力的度量体系,切记不要自觉生吞活剥“大厂”所谓的最佳实际,也不要拿本人的度量实际去和大厂的比拟,你们的上下文不同、组织生态不同,这药给大厂吃能够治病,给你吃可能致命。

4.7 自觉建设度量数据中台

不要在没有任何明确改良指标的前提下发展大规模的度量,因为度量是有老本的,而且这个老本还不低。很多大型组织往往会花大老本去建设研发效力度量数据中台,指望通过研效大数据的剖析来获取改良点。这种“广撒网”的策略尽管看似无效,实则收效甚微。事实证明,度量数据中台的建设老本往往会大幅度高于理论获得的成果。

比拟现实的做法应该是通过对研发过程的深度洞察,发现有待改定的点,而后寻找可能证实本人观点的度量汇合并采取相应的措施,最初再通过度量数据来证实措施的理论价值,这种“精准捕捞”的策略往往更具实用价值。

好了,明天咱们就先聊到这里,感谢您的浏览,当前有机会我会对研发效力度量的话题做更多的分享。

起源:QECon 质效前沿
作者:茹炳晟(腾讯 T4 级技术专家,腾讯研究院特约研究员,业界出名实战派研发效力和软件品质双领域专家。)
申明:文章取得作者受权在 IDCF 社区公众号(devopshub)转发。优质内容共享给思否平台的技术伙伴,如原作者有其余思考请分割小编删除,致谢。

IDCF DevOps 黑客马拉松,2021 年度城市公开赛,11 月 6 - 7 日,深圳站,企业组队参赛 & 集体参赛均可,一年等一回,错过等一年,连忙上车~ 公众号回复“黑马”退出

正文完
 0