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