点这里👇星标关注,获取最新资讯!
蒋德富,中航信重庆分公司,研发效能负责人、 研发效能(DevOps)技术工程师(中级)学员
引言
研发效能度量工作应该如何开始,有些方法和注意事项? 团队度量是否可以纳入考核,对考核有哪些影响,如何避免? 如何评价研发度量改进的有效性?如何维持持续化能力改进? 如何避免无异议度量,持续提升度量有效性? 度量指标太多?如何决策哪些应该优先管理和度量?等
构建效能度量应用框架 度量应用技术实践 度量应用治理策略
一、构建效能度量应用框架
“三”是经营目标形成目标分解结构,按照经营价值树的原则把经营目标层层分解并关联到研发能力行为结构上,为管理提供一个直观管理指标度量结构。其中包括经营类指标,其来自企业经营的目标直接价值体现,比如研发合约收入、上级对单位考核成绩、客户投诉和安全故障等;管理类指标,是通过经营目标转为成内部管理指标,比如研发过程符合率、研发人员培养周期、研发安全症候事件等;研发类指标,是从研发交付角度来看研发交付端对端一些研发指标,比如需求交付周期、版本交付吞度量、缺陷密度、开发周期、发布频率等;
“五”是指研发度量应用五个维度,通常是指“多、快、好、省、能”,其中“多”可以体现在产能上,反应交付成果,重点体现研发交付需求对用户或业务带来的效果;“快”可以体现在效率上,反应软件研发交付需求的快慢;“好”可以体现在交付质量上,反应软件研发交付需求的好坏;“省”可以体现在成本上,反应软件研发交付需求的开销;“能”可以体现在能力上,反应软件软件研发交付需求的能力可持续性,同时能力维度指标更偏向于过程指标,通过能力维度指标改善可以促进其他四个维度的结果性指标的提升。
“四”是指软件度量应对管理对象,度量指标根据不同对象有不同加工计算策略,针对企业组织结构,通常分为“整体效能、部门效能、团队效能、个人效能”四个对象层级,当然结合康威定律,可以对度量对象层级进行动态优化,但不建议超过4层,越复杂的度量管理对象,会对指标计算应用造成指数级的复杂度影响。
“四”是指软件度量应用控制策略,在面对不同度量状态时针对不同指标的目标要求需要使用不同度量策略,包括“建议改进、推荐改进、重点改进、控制保障”,以实现对度量目标有效层次化引导,但无论是控制和改进都是最基础应用策略,为增强指标应用能力通常结合数据可视化管理会扩展使用指标的评价和预测能力,以达成度量目标有效管理。
二、度量应用技术实践
遵守研发度量第一性原理,度量应用目标不是单单改善某个指标,而是需要达成既定目标或解决实际的问题,通过现象看到问题的本质。
GSM实践,“GSM”是Google提出的一种自上而下度量用户行为的方法,通常用于衡量产品/项目目标的实现程度。通过对目标的设定来倒推过程,是设定指标体系的一种量化研究方法;
G-Goal: 目标,即期望的最终结果 。它是根据您想要在高层次上理解的内容来表述的,不应该包含对衡量它的具体方法的引用;通常目标来着上级或外部客户对事情的期望,对应“三五四四”经营类型的指标,衡量组织绩效或收益,当然目标也可以来着生产交付本身存在的问题转化形成的目标。
S-Signal: 信号,他是判断达到最终结果的一些行为表现或效果现象。 这些现象下的信号是我们想要测量的东西,但它们本身可能是不可测量的,这也就是我们会陷入某些表现努力改进而不得其果的原因之一,片面追求可能促使其目标达成变得适得其反。因此我们在选定信号时,需要考虑信号系统性,从多个角度考虑起问题正负相关性,形成相互约束。
M-Metric: 指标集,它们是信号的代理,是实际上可以测量指标。为能更好衡量信号,可以考虑使用北极星实践进行系统性设计,以促进其指标足够接近目标,也能反应一些现实性制约关系。但同时在使用指标时我们也需要注意,不要轻易忽视一些不可度量的信号影响。
通过GSM实践可以防止路灯效应,回归研发度量的第一性原理,聚集于本质目标 。例如“在路灯下找钥匙”假如你只在你能看到的地方找丢失的钥匙,那么,你很可能找错地方了。原因是对于指标,容易陷入轻松获得的指标进行管理改进,然而可能其本身并不是目标的本质,往往产生为了度量而度量情况;相反,GSM迫使我们思考哪些指标实际上将帮助我们实现目标,而不是简单地考虑我们现有的指标,通过信号现象聚集有效的指标表现,从而防止指标蔓延和指标偏见。
检查研发度量持续改进闭环,度量应用不是研发目标达成就结束,而是一个长期的管理过程,从持续改进到持续控制,需要一个驱动力形成可持续性。
PDCA实践,也叫“戴明环”,是一个悠久优秀实践,但它依然能帮助在研发效能管理向良性循环的方向持续发展。针对研发效能应用而言,其本质的目的就是改进,应用PDCA实践可以有效帮助交付达成改进的两大核心属性:闭环、持续。PDCA实践分为四个阶段八个步骤,由于资料较多这里不再过多介绍,但在使用PDCA时有一些需要实践注意地方,重点补充三点。P-PLAN, 在开展进行改进计划时,我们容易陷入事物判断的主观论,从而制定丰富而详尽计划,导致改进周期长,效果不足。 在实践操作上,一方面建议在问题现象分析时提供数据支撑并配套相关数据报表,建立基线管理,并尽量通过数据或现象寻找根本原因。另一方面不要陷入因果线性分析单存关系,尊重事物本质复杂性,从核心原因入手形成一个迭代改进计划,使用设计阶梯上升环或系统改善环策略促进研发能力持续提升。
C-Check, 检查是持续改进重要的一个环节,既是对阶段目标达成情况验证,也是对改进过程复盘,从而促进快速改进调整。改进结果检查时一些场景量化技术,不仅仅是使用一些数据图表和单纯的目标论,而是需要使用统计性的技术进行系统性样本分析。如单元测试分支覆盖率大于30%,在分析目标达成时不要只是通过一些折线图或柱状图来判断30%的达成情况,还需要通过SPC统计策略一些控制图或箱线图查看一下单元测试分支覆盖率的变化规律,如查看半年内,单元测试分支覆盖自身中位值的变化情况趋势对比,与组织级统计的数据基线进行横向对比,观察目标达成过程合理性,甚至必要时使用统计样本的T检验查看改进数据样本变化的显著性。
探索研发度量系统性实验,度量应用不是简单线性问题,而是随着研发软件研发持续开展软件研发复杂性会持续递增,并展现出一个较为繁杂的系统性问题。
(1)基于从组织角度围绕经营目标,开展系统性数据建模实验,实践步骤如下:
组织模型系统性实验是基于组织级所有数据基线而建立,通常需要较多项目的数据支持,对组织而言,这也是对组织级所有数据进行系统性复盘的过程,数据质量评价的过程,从而避免陷入一叶障目管理误区。在系统性数据建模过程中,需要注意模型的数理关系需要符合研发过程客观规律性,如果数据相关性违背了研发本质特性,此时组织可以考虑纳入组织治理干预策略。系统性模型实践成本较大,不是一个短期的过程,通常由组织级管理团队组织人员长期开展,这也是持续为团队构建合理性研发度量保障环境基础。
(2)基于组织级PPM模型,团队需要开展系统性实验,实践步骤如下:
三、度量应用治理策略
内部经营决策者高度支持
研发效能体系建设是需要有企业核心管理层直接参与的,需要协调各方资源深度优化研发能力的过程,其研发度量管理也是作为企业级数字化转型重要组成部分。但需要注意的是,度量不是免费的,需要投入大量资源构建数据治理体系和治理工具,需要跟多人力成本投入和持续维护,这是不可忽视核心保障;在研发度量应用时切记避免度量作为管理人员考核工具,片面应用开展绩效评定,这样会导致研发效能在内部推进遇到阻碍,同时会影响数据对现实问题客观展示,陷入一种虚拟的数据世界中。
构建内部度量思维和文化
应用数据是度量管理必修课,塑造组织内部管理文化,培养管理者正确的数据思维,是应用数据的基础,包括数据可视化管理、数据反馈周期、数据分层度量、数据系统性等。在塑造度量思维和文化时,需要建立起组织制度和规则,比如汇报数据一致性、标准语义词汇等;需要构建随处可以动态数据环境,让数据在办公场景下随时可以触及,比如电梯间的数据大屏、办公桌面数据助手、过道中数据报表等;需要经常性扩展数据应用场景,延展到研发服务周边环境,让数据流动起来,比如办公出差数据化场景、请假调休应用场景等。
优秀实践评选树立标杆
度量应用管理是一个长期过程,可以通过组织开展持续优秀实践评选活动,树立起团队度量实践标杆,让后来者看到前面灯塔。优秀实践评选也可以不断促进团队复盘思考,可以持续深化团队回顾会机制,促进内部量化实践应用精益求精,提升工程实践应用能力。另外组织级优秀实践沉淀也为沉淀为AI时代积累更多优秀实践语料库,知来路而谋未来。
构建驻场和培养服务机制
团队能力的转变不是一蹴而就的,前期通常需要人扶着看着,基于量化教练团队和配套服务机制也是促进度量应用管理重要策略之一。通常会提供咨询、评估、驻场、培训等多项服务,量化教练可以随时抽调实践支撑团队,促进团队理解中心度量框架和团队度量应用实践方法,和服务团队一起成长,帮助团队进行改变并固化能力,也可以汲取实践经验和建议,并反哺组织开展组织级的持续改进。
参考文献
[1] 团队标准《软件研发效能度量规范》(T IQA 15-2022)
[2] 茹炳晟, 张乐, 等. 软件研发效能权威指南 [M]. 北京:电子工业出版社, 2022: 552-559.
[3]贾新章, 游海龙, 等. 统计过程控制理论与实践 [M]. 北京:电子工业出版社, 2017:14-26.
[4]刘子昱. 基于 CMMI 模型的软件开发过程改进管理研究 [D]. 四川:电子科技大学, 2021:1-78.
[5]Titus Winters / Tom Manshreck / Hyrum K. Wright.Software Engineering at Google. O'Reilly Media,2020-3-3
IDCF