作者|姚安峰长期以来，如何有效衡量软件研发的有效性一直是所有研发管理者的心头之患，却始终是一个悬而未决的问题。从早期的人均代码行数，到人均功能点的公式计算，再到基于故事点的迭代率或人均吞吐量，业界一直在探索。如果以人均代码行数这个有偏差的指标作为关键指标，违背了更好的程序员应该使用更优雅、代码更少的逻辑，将软件编程的脑力劳动与速度等同起来显然是不合理的。砌砖的。功能点的计算是根据需求分析设计后确定的需要修改的页面数量、接口数量等多种因素，通过复杂的公式计算。看似客观，却忽略了软件开发工作的多样性。渠道端应用接口较多，功能点数量可能会更多，但也有后端开发、基础平台开发、数据及报表开发、算法开发、前端开发等多种工种。结束发展。由于差异，不可能用几个公式来客观衡量团队的生产力；此外，越来越复杂的计算公式依赖于精确的设计，每个人都很难理解，需要人们投入专门的时间进行计算。没有价值创造的工作本质上是一种浪费。随着敏捷开发的发展，故事点作为一种基于团队集体评估复杂性的工具，可以用来衡量细粒度需求的大小。然后，一些经理考虑根据每个员工的故事点来衡量生产力。但故事点数没有单位，不同团队的故事点数基准可能不同，评价的主观性特点使得人均故事点数和迭??代率很难作为绩效衡量的关键指标。关键研发绩效指标设定经过多年的探索和总结，DevOps社区提出了衡量IT绩效的四个关键指标，包括交付周期（或交付周期）、部署频率、部署失败率和在线故障恢复时间，简称为“4个关键指标”。这是一个很好的方向。但在实践中，我们发现需要关注的关键指标不止这四个。例如，生产缺陷率是一个必不可少的关键结果，而需求吞吐量往往是人们非常关心的问题。以下是实践中常见的研发过程指标，其中一些是反映最终结果的关键绩效指标。评估有效性的关键原则要观察和评估研发有效性，首先要定义什么是有效性？总之，有效性是团队持续快速交付价值的能力。目的是传递价值，其研发核心能力在于“响应性”和“鲁棒性”。同时，响应性的概念可以从“流量”和“资源率”两个维度来观察。前者是指从价值明确到交付给用户的周期时间，后者是指单位时间内单位人力资源交付价值的数量。对创新和敏捷性的要求使得前者比后者更重要。因此，评价绩效有几个关键原则：任何单一的指标都不能合理地观察和评价一个团队的绩效，否则会产生副作用。比如只看吞吐量，会驱使团队盲目拆解需求，或者牺牲质量；如果只看交付周期时间，可能会驱使团队减少需求流入。尽可能通过查看整体结果而不是阶段性性能来评估性能。迁移测试的通过率等指标通常非常重要，反映了开发阶段内建质量的效果，但不适合评估绩效，因为它不能反映团队的整体绩效。绩效评估的原始数据应该是来自工具的客观记录，不需人工计算，不浪费评估时间，对所有团队一视同仁。考虑到软件研发岗位的多样性和以脑力劳动为主的工作性质，研发成效的观察更应该关注团队的提升趋势，而不是横向比较的绝对值。那么如何才能更合理有效地达到观察和评价绩效的目的呢？最直接，也是最理想的方式，就是学会观察和分析一组核心指标，比如同时取出4个Metrics的数据趋势，或者分析观察关键绩效指标的数据趋势在上图中。一些成熟的公司会将这些关键指标做成一个Dashboard（仪表盘），方便观察者一目了然地分析全局。这就像做数字化运营的数据分析。只有通过一组数据的对比分析，才能得出相对有效的见解。强烈建议每个绩效经理和流程改进者都以推动改进为目标，学习并习惯以这种方式评估团队的绩效。观察绩效的综合评价指标，但这种理想的方法对观察者的要求很高，需要充分理解每个指标的含义和内在逻辑，这样一套核心指标不够直观，无法反映宏观绩效提升趋势，认知负荷有点高。尤其是一些管理人员和外部人员，很难看出整体业绩是好是坏。想解决这个问题，我想到了一些类似的解决方案。国家需要一些指标来持续观察一个经济体的整体经济状况。典型的例子有居民消费价格指数（CPI）和购买力平价指数（PPP），它们是根据一定的内在逻辑使用一揽子指标组合而成的综合指标。优点是虽然不能说明问题的根本原因，但可以更直观地反映整体表现，其变化可以综合多种因素的影响，可以反映不同因素对整体评价的影响，减少使单个指标看起来不错的片面行为。因此，在实际案例中，我们设计了如下概念公式，结合六大要素生成一个综合评价指标（R&DeffectivenessCEI），可以按周或按月统计：Rate)/(DemandDeliveryCycleOnlineStabilityDebtBacklog)交付吞吐量反映资源率，通常指单位时间内交付需求的数量，但它是六大要素中最难有效计算的。因为跟需求的粒度有关。功能点和故事点都需要人工评价，存在上述一些问题。所以使用一个自然发生的近似值：故事开发时间，即从开发开始到开发完成的时间，是通过在看板中拖动故事来生成的。虽然这个时间长短可能会受到个体开发效率的影响，但是在统计意义上可以大概代表需求的大小。开发时间还受同时并行工作的故事数量的影响，同样规模的并行度越多，开发时间越长。因此，交付吞吐量的人均值计算如下：交付吞吐量=交付故事数×（平均故事开发时间/平均人均故事开发WIP）/团队规模部署频率。该指标是人均部署单位数量。理论上，团队规模越大，可以交付的需求越多，特性交付的频率也应该更高。该指标促使团队拆分部署单元以提高频率。考虑到部署频率对整体性能评估的重要性不如吞吐量和周期时间，其影响因幂函数而降低。DeploymentFrequency=(DeploymentUnitDeployments/TeamSize)^(1/e)发布成功率是一个比较简单的指标，即每次上线发布的成功率。只要出现回滚或者新版本出现重要故障，就视为无效。成功。由于该指标是百分比率，比率越高，越难提升，所以采用如下指数函数参与计算：发布成功率=e^版本发布成功率需求交付周期这是一个反映流量的关键指标，即从需求确认到需求上线的周期长短，衡量团队对价值的响应速度。这里的需求统计规模不是用故事，而是可以独立推出的功能或用户需求。需求交付周期=平均特征交付周期在线稳定性在线稳定性的衡量可以从不同角度结合几个基本指标，例如人均生产缺陷数、停机时间和在线故障恢复时间。考虑到人均生产缺陷数、停机时间、在线故障恢复时间的数值可能为0，而且数值越小越难提升，而且这些指标波动非常大，所以降级通过以下幂函数。在线稳定性=(((生产缺陷数+1)/团队规模(停机时间+1)(在线故障的平均恢复时间+1))^(1/e)DebtBacklog我认为需要考虑的最后一个因素补充进来。这里所谓的“债”是指各类团队应该及时解决的未解决问题，包括需求积压、缺陷积压、技术债，团队在快速推进的过程中可能会欠下很多债交付。如果忽略技术债，对于缺陷的积压，一段时间的高速其实只是在掩盖问题。对于需求的积压，即使团队认为效率很高，从从业务方的角度来看，其性能仍然不能满足需求，感知效率不高。缺陷积压是指未解决的缺陷；需求积压是业务提出但尚未进入交付的需求在一定的时间限制后；技术icaldebt是目前比较容易量化的代码债务，比如Sonar扫描的结果，如果可能的话，还可以包括architecturaldebt的数量。当然，考虑到这几类积压的重要性，给予了一定的权重。人均Backlog计算如下：DebtBacklog=(RequirementsBacklogx50%+DefectBacklogx30%+TechnicalDebtAmount/10x20%)/Team最后，考虑到分子和分母计算都有两个team参与计算的尺寸，可以考虑相互简化和相互抵消，形成如下最终计算公式：以下是实践中根据实测数据形成的综合评价指标曲线和来源数据示例。我们可以直观的看到综合多种因素后球队整体表现的变化。图中自动生成一条额外的红色趋势线（虚线），可以反映一段时间内业绩的整体变化趋势。或者变化的变化和幅度。由于团队工作的多样性，不同类型团队计算出的指标结果可能存在较大差异。因此，这条曲线主要用于与自己过去的团队进行对比，或者工作性质相似的研发。团队之间的横向比较。综合指标应用场景及意义通过综合指标的统计和观察，可以有效解决以往单一指标和人工统计的问题，能够反映不同维度指标因素对综合表现的影响。那么这个指标趋势对谁有用呢？在实践中，有几种应用场景：对于高层管理人员或不熟悉绩效数据分析的人员，可以直观地展示团队和组织的绩效变化，作为沟通研发绩效的依据；对于部门和团队领导和教练，能够快速了解??团队绩效的整体变化；当曲线波动较大时，深入分析是哪些因素导致整体结果波动，从而采取改进措施；当部门或团队制定绩效提升目标时，比如OKR，可以用综合指标作为衡量目标达成情况的关键结果，避免团队片面关注单一指标的提升，而是专注于综合结果。在着力提升单项指标的同时，还要保证其他关键指标不下降。这个指标公式还有很大的改进空间。例如，不同的公司和部门对绩效的解读不同，或者对不同关键指标的重视程度不同。公式中的影响因子或权重可以适当调整。或者，对于发布成功率、生产缺陷等因素如何影响最终结果的算法，可能有更科学、更准确的公式，也可以改进。欢迎提出建议。原文链接：研发效果趋势观察与评估（qq.com）
