破解研发效能度量悖论

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 每一个精心设计的度量模型都是为了提升团队的研发效能,每一个精心设计的度量模型都会驱使出现“高分低能”的团队。

破解研发效能度量悖论

每每说到研发效能的度量指标,每个人都有自己的看法,管理人员看数、工程师造数,那么掩盖在“数”下的是每个角色的小心思。这里面有管理人员的团队的心思、工程师维持自己不垫底的心思、建立度量指标的人给管理者“鱼”的心思等等。所以每一个“心思”都没有办法评价是对是错,都是当前团队管理、协作的必然产物,但是每一个都有其局限性。

研发效能度量悖论:选择度量指标普遍面临的问题

研发效能度量悖论:每一个精心设计的度量模型都是为了提升团队的研发效能,每一个精心设计的度量模型都会驱使出现“高分低能”的团队。这是因为在追求优秀的度量指标时,团队可能会倾向于追求表面上看起来很好的成绩,而忽视了实际的研发能力提升。

一个典型的例子是项目进度的度量。如果团队的度量模型过于关注项目的进度和时间节点,团队可能会被激励在短时间内快速交付,以获得高分。然而,这可能导致一些问题,比如牺牲了代码质量、忽略了测试的深入等。在长期内,这样的做法可能会导致系统的不稳定性和未来需求的无法适应。另一个例子是代码行数的度量。有时候,团队可能会将代码行数作为一个衡量工作量和贡献的指标,而不是关注代码的质量和可维护性。这可能导致开发人员追求数量而非质量,写出冗余且难以维护的代码。虽然这在度量模型上可能会得到高分,但实际上并没有提高整体的研发效能。

研究表明,在一些强调速度和产出的团队中,尽管项目可能按时交付,但由于忽略了质量和可维护性,最终可能需要更多的时间和资源来修复和维护项目。因此,解决这一悖论的关键在于建立平衡、可自我检查的度量模型,不仅仅关注短期目标的达成,还要考虑到长期的研发效能和质量。

度量模型中“测谎”指标

在上述研发效能度量悖论的基础上,提出一个短期避免悖论出现的方法:“测谎”指标,以此加强度量模型的准确性和全面性。测谎指标的目的是防止团队通过操纵某些表面上看似优秀的度量指标而忽略实际的研发能力提升。这样一来,度量模型不仅仅关注表象,更注重团队的实际贡献和能力。

一种可能的测谎指标可以是代码审查的深度和频率。过于频繁的代码审查可能是为了满足某个度量指标,而忽略了真正需要关注的问题。在实际情况中,数据显示出,一些团队在短期内可能会大幅度增加代码审查的次数,但却没有相应提升代码质量。通过观察代码审查的深度,即是否真正关注到了潜在问题和质量标准,可以更好地了解团队的实际贡献。另一个测谎指标可以是项目的测试代码覆盖率。在追求短期快速交付的情况下,一些团队可能会缩短测试的时间,从而提高交付速度,但这可能会导致潜在的缺陷和质量问题。通过测谎指标,我们可以监测回归测试的真实覆盖范围,以确保项目的交付质量不会因为追求速度而牺牲。通过在度量模型中引入测谎指标,可以更全面、准确地评估团队的研发效能,避免“高分低能”的困境。这一方法不仅有助于提升短期绩效,更能够确保团队在长期内保持可持续的创新和高水平的研发能力。

度量模型的信度和效度决定模型的价值

但是这种度量模型中的”测谎“指标也是一个指标不治本的方法,要想从根本上避免研发效能度量悖论应该为考察度量模型的信度和效度。在度量模型的设计中,信度和效度是两个关键概念,它们对于确保度量模型的准确性和全面性至关重要。

  • 信度(Reliability):信度是指在相同条件下,测试能否产生相似或一致的结果。如果一个测试具有高信度,那么在不同的时间和环境下,同一个人做相同的测试应该得到类似的结果。举例来说,想象一把尺子,如果这把尺子是信度很高的,那么无论我们在什么时候、什么地方使用它,它都会给出相似的测量结果。
  • 效度(Validity):效度是指测试是否能够测量到我们想要测量的东西。如果一个测试具有高效度,那么它应该能够准确地反映我们想要了解的特质或能力。以智力测试为例,如果我们要测量桌子的长度,那么这把尺子就是有效的。但如果我们用它来测量温度,那么它就不是有效的,因为它并不能提供我们需要的信息。

信度和效度的高低直接影响到度量模型的质量。如果一个度量模型在信度和效度上表现出色,那么它更有可能提供准确、可靠的信息,避免了悖论的出现。在研发效能度量中,如果我们将信度和效度作为优化的关键目标,就可以在度量模型中避免“高分低能”的困扰。例如,可以通过持续优化技能评估工具,确保它们在不同时间和不同环境下都能提供一致的结果,以此提高信度。同时,确保这些技能评估与实际研发能力的关系明确,以提高效度。考虑到信度和效度的重要性,我们可以通过以下方式解决研发效能度量悖论:

  • 定期评估信度:在度量模型中引入信度评估,通过重复测试或观察,确保度量模型能够在不同条件下产生一致的结果。
  • 验证效度:确保度量模型中的指标与实际研发能力相关联,以提高效度。
  • 综合使用多个指标:避免过于依赖单一指标,通过综合多个信度高、效度高的指标来全面评估团队的研发效能。

通过注重信度和效度的建设,度量模型将更具可靠性和全面性,从而在避免研发效能度量悖论的同时,为团队提供有力的数据支持,推动持续的研发能力提升。这样的方法更有可能在长期内实现研发效能的可持续增长,避免了仅仅依赖表面指标导致“高分低能”的困境。

总结

在研发效能度量的探讨中,我们面对的不仅是团队成员各自的期望和小心思,还有度量模型本身可能引发的悖论。管理人员渴望数据来评估团队表现,而工程师则希望保持个人不受歧视。这种差异导致了度量模型的设计存在一定的困境,容易使得团队在追求表面上的优秀成绩的同时忽视了实际的研发能力提升。为了短期避免悖论的出现,引入“测谎”指标成为一种方法。然而,这种方法仍然是治标不治本,因为它未能解决度量模型本身的信度和效度问题。我认识到度量模型的信度和效度是关键的。信度保证了度量结果在不同时间和环境下的一致性,而效度确保了度量结果与实际研发能力的相关性。通过定期评估信度,验证效度,并综合使用多个指标,我们可以建立起更为可靠和全面的度量模型,避免了“高分低能”的困扰。
最终,一个良好设计的度量模型应该既满足管理人员对于数据的需求,又考虑到工程师的实际贡献和团队的长期研发效能。通过注重信度和效度,度量模型将更具有指导性,不仅提供短期的绩效评估,更为团队提供了持续发展的方向。在这个过程中,我们能够理解每一个“心思”都是团队管理和协作的产物,而度量模型的优化则需要在综合各方利益的基础上进行,为团队的成功和创新提供更为有力的支持。

目录
相关文章
|
16天前
|
搜索推荐 程序员 测试技术
研究思考|关于软件复杂度的困局
本文重点围绕软件复杂度进行剖析,希望能够帮助读者对软件复杂度成因和度量方式有所了解。
|
9月前
|
Go
团队的温度-霍桑实验对绩效管理体系的启示
团队的温度-霍桑实验对绩效管理体系的启示
|
数据可视化 Devops 程序员
研发效能度量:单人效率考核内卷?(1)
研发效能度量:单人效率考核内卷?
189 0
|
运维 监控 数据可视化
研发效能度量:单人效率考核内卷?(2)
研发效能度量:单人效率考核内卷?
151 0
研发效能度量:单人效率考核内卷?(2)
|
搜索推荐 程序员 测试技术
研究思考丨关于软件复杂度的困局
研究思考丨关于软件复杂度的困局
1229 1
研究思考丨关于软件复杂度的困局
|
算法 决策智能
运筹优化学习22:新项目研发项目进度制定与优化研究(二)
运筹优化学习22:新项目研发项目进度制定与优化研究
运筹优化学习22:新项目研发项目进度制定与优化研究(二)
|
监控 算法 安全
运筹优化学习22:新项目研发项目进度制定与优化研究(一)
运筹优化学习22:新项目研发项目进度制定与优化研究
运筹优化学习22:新项目研发项目进度制定与优化研究(一)
|
监控 项目管理 决策智能
运筹优化学习22:新项目研发项目进度制定与优化研究(三)
运筹优化学习22:新项目研发项目进度制定与优化研究
运筹优化学习22:新项目研发项目进度制定与优化研究(三)
|
程序员
你都不知道自己有多强,衡量程序员生产力的标准是什么?
如果你用谷歌搜索“mearsuring software developer productivity”,那么你会发现出来的全都是一些废话,一点用处都没有的废话。——Nick Hodges,《Measuring Developer Productivity》 所以现在你知道了吧,原来我们并没有办法来衡量程序员的工作效率。
|
敏捷开发 运维
优云软件又双叒通过CMMI ML3评估 , 研发和质量管理水平创新高
2017年第三季度,SEI授权的主任评估师对优云软件研发中心进行了CMMI软件能力成熟度模型评估,优云软件顺利通过复评。 这是继2011年12月优云软件首次通过CMMI ML3级的评估认证以来,第二次成功通过复评工作,再一次证明了优云软件研发中心已建立符合CMMI-DEV成熟度3级的目标和要求的研发体系,基于敏捷研发过程的管控,确保产品研发能力,最终为用户提供了高质量的产品和服务。
1961 0