研发效能度量:单人效率考核内卷?(1)

简介: 研发效能度量:单人效率考核内卷?

编者荐语:

研发效能度量,底层逻辑大于形式,用好手段途径,营造良好可持续的适应性组织文化。

以下文章来源于Agilean,作者程萃

本文通过对研发效能度量领域6个常见问题的分析,阐述了作者对于研发效能度量的6点思考。因部分观点的抽象层次较高,建议收藏后细读,相信对帮助大家理清研发效能度量理念、建立度量体系会有所帮助。

随着近几年市场和政策对于数字化转型的重视,研发效能的话题也是铺天盖地而来,从百度指数可看出,从21年下半年开始,“研发效能”四个字开始成为了热门词汇。

业界里面也因此有了许多的研发效能标准,比如阿里的五组效能度量指标,百度的工程能力白皮书里包含的效能度量体系,腾讯PCG的EPC模型,以及最新出炉的由中国信通院牵头的《研发运营一体化(DevOps)通用效能度量模型》等等。

从这些度量体系的整体架构我们都可以看出整个度量体系的趋势都会是分层、分对象、分阶段,目标管理、动机驱动,从不同的维度去可视化、透明化研发这个黑盒子,回顾历史以期望可以得到预测性。

笔者曾参与国内多家金融企业度量体系建设过程,在此想和大家分享一些在研发效能度量体系建设过程中的思考。


问题一:我们公司想进行敏捷/DevOps转型,已经咨询过好多工具DevOps平台厂商,研发效能度量不就是引入一个工具就可以了么?

理念一:对抗复杂系统的演化需要熵减


虽然大多数组织都有研发的一系列流程、规范,甚至工具的支撑,本质上来说软件开发还是属于一个复杂的领域,而不是类似以往工业时代的有序的、生产线类型的系统。仅仅引入一个工具而不是做研发效能操作系统的整体升级,很有可能达不到最开始所期待的效果。

为何将软件研发定义为一个复杂的系统?

George Rzevski 教授层提供了一套复杂性的最佳标准:

  1. 交互-复杂系统由大量参与丰富交互的不同组件(代理)组成
  2. 自主-代理在很大程度上是自主的,但受制于某些法律、规则或规范;没有中央控制,但代理行为不是随机的
  3. 涌现-复杂系统的整体行为从代理的交互中“涌现”,因此是不可预测的
  4. 远离平衡-复杂系统“远离平衡”,因为频繁发生的破坏性事件不允许系统返回平衡
  5. 非线性-非线性偶尔会导致微不足道的输入被放大为极端事件(蝴蝶效应)
  6. 自组织-复杂系统能够自组织以应对破坏性事件
  7. 共同进化-复杂系统与其环境不可逆转的共同进化

图片来自 cynefin.io

在Joseph多年前在一个大会上和300多名参会的软件开发人员做了一场Cynefin的“Butterfly stamping”工作坊,目的探索软件开发作为一个整体是否可以被认为是一个复杂的领域,他们得到了以下的共识:

  • 软件开发是一个丰富的领域,在所有不同领域都有多个方面和活动。这些方面和活动之间的交互本身往往是复杂的。
  • 软件开发是一个具有自相似特征的多层次领域,即活动通常由子活动组成,每个子活动可能位于与基本活动不同的域中。
  • 活动往往更侧重于繁杂和复杂的领域,与软件开发的编码方面相关的活动落在繁杂(或有时简单)的领域,而与项目管理相关的活动则落在复杂的(有时是混乱的)领域。处理与计算机交互的任务倾向于在有序域中,处理与其他人交互的任务倾向于在无序(即,复杂和混乱)域中。
  • 绝大多数的软件研发任务和活动都属于复杂领域。

复杂系统的演化,我们需要提到另一个概念:熵。

鲁道夫.克劳修斯发现热力学第二定律时定义了熵,熵是无序的混乱程度,熵增是世界上一切事物发展的自然倾向,即从井然有序走向混乱无序,最终灭亡。

如果把一个组织看成生命体:

  • 熵增就是功能减弱,生命体的衰老,也就是组织的懈怠、价值创造乏力等
  • 熵减指功能增强,生命体摄入食物、组织建立秩序等实现熵减、功能增强。

负熵

负熵是指能带来熵减的负熵因子,比如物质、能量、信息等,这些都是人的负熵,新的成员、新的知识、简化管理这些就是组织的负熵。比如说华为公司倡导的“日落法”,每增加一个新的流程环节要减少两个老的流程环节,这些简化管理的动作,也是一种负熵。

说明:本节关于“熵”的内容,参考了纪录片《宇宙的奇迹:时间之箭》,感兴趣的同学,可以自行搜索观看。

当组织的外部业务环境从工业时代转到IT时代,甚至以后会进入数字化智能时代,组织内的员工从70、80后的主力军变换到Z世代时,研发领域的管理方式的探索已经成为了在复杂系统如何更好地进行演化的命题。

我们的观点是,复杂领域下的管理方式就需要不断吸取外部的优秀负熵,以开放的心态和组织形式来促使组织逆向做功,从而让组织从无序混乱转向有序发展。一套工具所收集下来的指标只是助力,组织需要了解这些指标背后设定的含义,以及如何让组织内的成员理解这些度量指标。


问题2:我们老大说2022年的目标就是把那几个北极星指标做到行业第一,这可怎么落地呀?

理念二:负熵也要长期主义


管理大师德鲁克说过,所有企业管理,说到底都是目标管理。许多时候企业乱成一团,都是目标不一致的结果,小张有小张的心思,小李有小李的想法,每个人各有想法,公司就无法聚焦目标,也就无法共同发力。

德鲁克认为,并不是有了工作才有目标,而是有了目标才能确定每个人的工作。企业的使命和任务,必须转化为目标。如果一个领域没有目标,这个领域的工作必然被忽视。

关于目标的设定,史蒂芬.柯维在《高效能人士的七个习惯》中提出的“以终为始”思维方式就是一种很好的实现目标的方式。做事前认清方向,确立目标,逐步推进。比如我们在前几篇文章中谈到,组建产品部落的初衷,也是基于组织业务目标聚合跨职能人才在一起,为了共同的业务目标更实施产品的设计、交付和运营。

那么,组织将研发效能的目标,定义为短期之内提升北极星指标是合理的么?

首先,大多数组织都有提升效能的意愿,从组织面临的内外部因素影响可知,在外部业务已经趋向于饱和或者萎缩时,组织会抓紧时间练内功,也就是聚焦于研发效能的提升。

那什么是研发部门的效能度量目标?我们可以尝试用以下问题和管理层对齐组织效能提升的思路:

  • 如果研发效能提升了,你可以看到哪些方面会有变化?变化的这些方面又会有哪些信号出现?
  • 如果研发效能提升了,在现有的组织关系中,你觉得哪些关系会有变化?
  • 如果10分代表您期待的未来,0分代表最糟糕的情况,您现在可以觉得组织效能是多少分呢?
  • 如果需要提升研发效能,你期望多久可以看到效果?(越快越好的这种答案对这个问题没有帮助)

上述问题,有助于我们去理解组织领导层对于研发效能提升的焦虑度,同时我们也需要了解到,管理者也经常会被追问到的一个问题,就是一段时间内资源投入的合理程度。

ROI是深入人心的衡量方法,合理的资源投入产效管理对组织最终的经济效益的确起到关键作用,原则上来说,产效管理的核心在于科学化的资源规划与分配和数字化的产效衡量与管理,问题在于:

  1. 多长的时间内?
  2. 如何定义合理的资源投入?

简单来说,在管理者的任期内,已经投入了多少研发资源达到了多少业务效果,未来打算投入多少研发资源达到多少的业务效果?

这两个问题中的任何一个,对于管理者来说都不是一个容易回答的问题。

抛开无限游戏的说法,最佳解可能就是在有限的时间以内,分阶段的设置目标。

有些组织出于对研发效能建设短期目标的追求,不是搞单元测试覆盖率,就是CI/CD3个月从零开始覆盖所有系统。如果把每一个工程实践的提升都看做是一个小的变革,首先得考虑组织的变革准备度,以及你打算实施的变革饱和度。

变革饱和度过高时,团队反而会因为要去解决一些不紧急的技术债而拖延业务交付的时间。

整个研发效能的建设就好像是一个基建工程,要想实现飞轮效应,我们就不可能在超短的时间内就达到。

现阶段我们做的大多数还是破除0到1的过程,从靠管理者个人主观的感受团队的忙闲程度,到依据积累的历史数据以及和同行同形态的团队相对比找差异。

受制于组织内部的文化、能力水平,外部的大环境业务形态变化影响,只有当历史数据积累了一定时间以后,组织的合理资源投入才能有一个相对客观的数据展示。


问题3:代码行数、测试案例数、个人所负责的故事这些我们都收集到了,是不是应该针对个人搞个排名啊,年末了也好发奖金。

理念三:关注球队,而非球员


一场球赛结束,你猜上台获奖的会是一个团队还是一个球员?

虽然我们都很通常会很欣赏那些明星球员,但是一场球赛的胜负核心还是在于团队。

图 / 来自Pexels,基于CC0协议

依据真实事件改编的电影《点球成金》中,职业经理人Billy在球队缺钱、明星成员接二连三被挖走的逆境中通过挖掘出一批平凡的选手,这些人或者年龄很大,或身体有恙,或打球姿势诡异,或个人生活混乱,最终依靠这个团队取到了他心中的梦想——冠军杯。

一场球赛中,有的球员负责冲锋,有的负责防守,除了个人能力以外更多是团队的协作。同样的,一个研发团队中,有的擅长编码,有的擅长沟通,有的擅长架构设计,他们也许都称之为程序员,职责也相同,在团队中发挥的作用范围或对象却有可能天差地别。

单人效率考核的内卷

在组织开始注重效能的初期,有的管理者会喜欢对比单个人员的繁忙程度用来衡量“生产率”或“效率”,也就是一个常常加班的员工就比一个正常下班的员工更容易得到老板的欣赏,在“电影院效应”下,组织中重复低价值的工作的场景会越来越多,实际造成不必要的资源浪费,也就是俗称的“内卷”。

当球队管理者不去关注团队进球数多少,而去一心关注单个球员进球数时,球员自身更容易打乱自己的节奏。

因此,在研发效能度量体系中,我们会推荐以团队的效能度量为主,个人的数据可以做极端异常值的分析。

比如一个团队中,若有成员的代码提交量一直保持非常低的水平,可能管理者会需要关注此成员被分配的工作和能力是否匹配,另一个配套的管理手段是把团队人数拆小以后,类似每日站会的实践也能提前发现此类问题。(关于这个问题,可以查看我上一篇小队划分的文章,在文末有链接)

从另一个方面来说,将成员的各项指标建立数据模型,给人物贴上标签,按照团队的需要进行指标选择,从大量以往不可定量中快速找出团队的最优解。这也是电影中Billy给我们的启示,即如何用最低的成本创造最大的价值,更多的是一种商业化的考量。


问题4:我们公司从前年开始就已经有一套完备的指标体系,搞来搞去也没有什么新的指标好添加的,那几个指标大家都看熟了


相关文章
|
1月前
|
测试技术
破解研发效能度量悖论
每一个精心设计的度量模型都是为了提升团队的研发效能,每一个精心设计的度量模型都会驱使出现“高分低能”的团队。
56 0
|
10月前
|
Go
团队的温度-霍桑实验对绩效管理体系的启示
团队的温度-霍桑实验对绩效管理体系的启示
|
7月前
管理者、团队和效能指标
管理者、团队和效能指标
50 1
管理层、团队和效能指标
讲述管理层、团队和效能指标之间的关系
|
10月前
|
程序员 Go 项目管理
恼人的KPI,技术管理者应该如何应对?
恼人的KPI,技术管理者应该如何应对?
|
运维 监控 数据可视化
研发效能度量:单人效率考核内卷?(2)
研发效能度量:单人效率考核内卷?
165 0
研发效能度量:单人效率考核内卷?(2)
|
测试技术 UED
复盘归因,提高交付质量的秘诀
这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物,当然他们有一定的前后依赖关系。
复盘归因,提高交付质量的秘诀
|
新零售 运维 监控
研发效能的度量| 学习笔记
快速学习研发效能的度量
701 0
研发效能的度量| 学习笔记
|
监控 搜索推荐 测试技术
团队协作效率低下怎么办?阿里文娱PMO这么做
在日常工作中,作为产品技术P(鼓)M(励)O(师),经常会收到来自团队五花八门的问题求助, 比如“业务规划不是很了解”、 “客户交付周期比较长”、“约定的里程碑达不成”,这些问题相信大家都有同感。阿里文娱项目管理专家王春丹将和大家聊一聊这些问题的解法,以及如何帮助组织协同提效。
435 0
团队协作效率低下怎么办?阿里文娱PMO这么做
|
数据可视化
研发效能提升 36 计第二课:照亮问题,效能提升从可视化交付过程开始
“提升研发效能”是产品研发的共同目标。但是,应该从哪里开始呢?本次课程,是研发效能提升 36 计系列课程第二课,两位讲师将分享阿里巴巴的经验——从可视化端到端交付过程、暴露问题开始,开启研发效能提升之路。