共计 7040 个字符，预计需要花费 18 分钟才能阅读完成。
德鲁克在《21 世纪的治理挑战》一书中指出：“治理的第一个工作是规定组织的功效和绩效，而任何有这方面教训的人都能够证实，这本质上是一项最艰巨、最有争议的工作，但同时也是最重要的工作”。
常识工作的不确定性更高、组织成员互相协同更简单，因而，为常识工作者设计绩效更加艰难。人力资源共事搜索枯肠，但研发管理者和研发团队又感觉指标定义不合理，一直探讨、斗争的后果是，许多企业最初在应用一份有几十个指标的度量体系，治理老本高但激励成果又不显著。
笔者依据多年企业一线征询教训，给读者倡议了一个研发绩效度量框架作为参考。
- 第一节将介绍这个框架的设计准则，便于读者将来依据企业本身特点对这个度量框架进行定制和调整；
- 第二节将介绍框架中波及的三种指标类型；
- 第三节将具体介绍这个研发绩效度量框架的具体指标和算法。
一、研发绩效度量体系设计五准则
1.1 外部性
同样在《21 世纪的治理挑战》这本书中，德鲁克指出，任何组织的绩效都只在内部反映进去。以一个咖啡厅为例，客户等待时间、咖啡口感、价格，这些都是客户可感知的内部指标。研发组织也应优先选取其客户可感知的内部指标作为研发组织绩效指标，这里客户包含但不限于业务人员、产品经理、最终用户等。
1.2 有害性
管理学有一个准则“你考核什么你就会失去什么”，绩效指标对团队行为具备很大的牵引作用。设定一个指标后，须要首先思考负向牵引作用，即团队会采取哪些短期行为来试图迅速达成绩效指标？评估一下这些短期行为对组织的挫伤有多大？
举个例子，如果用开发代码行数来评估开发工作量，就会对开发工程师产生一个显著的负向牵引作用，让开发工程师失去进行优雅设计或重构代码从而让代码更精简的能源。因而，绩效度量体系应尽量选取一些难于伪造或者伪造行为对组织挫伤比拟小的绩效指标。
1.3 整体性
软件研发组织是一个简单零碎，各岗位间界线很难齐全明确。管理者要克服将绩效指标合成到不同岗位，甚至合成到集体的激动。这种有效的指标合成往往会导致局部优化，即各岗位仅仅为本人的绩效而优化工作办法，反而升高了组织的绩效。例如，将进度和品质两个相互牵制的指标，割裂开调配给开发测试，这造成开发只关怀进度，漠视移交品质，而光靠测试来保证质量。这种形式是不可能取得高质量软件的，也不可能达到疾速交付的目标。
1.4 制衡性
研发组织没法用繁多指标来掂量，而须要用一组指标来互相制约以求得均衡。例如，单纯谋求交付速度是危险的，必须用质量指标来均衡。
1.5 演进性
绩效指标应该随着组织的倒退一直调整，须要定期增减订正指标，放弃指标体系精简，升高治理老本。
二、三种绩效指标类型
理解了定义研发绩效体系的五个准则后，还须要介绍一下绩效指标的三种类型：
2.1 适应性指标
反馈组织是否适宜生存，这些指标因组织的特点不同而不同。例如，对于一个 pizza 外卖商家而言，pizza 送达时长、送达准时率和价格就是它的适应性指标，但 pizza 口感就不那么重要。然而，对于一家 pizza 精品餐厅而言，pizza 口感就变得十分重要，而上菜等待工夫就变得绝对不那么重要了。好消息是，因为研发比拟同质化，研发组织适应性指标绝对对立。
2.2 衰弱度指标
反映组织的衰弱水平，就如同一个人的心率、血压，血脂指标一样。衰弱度指标往往是外部指标，非客户可见，因而须要十分小心掂量指标的有害性和整体性。衰弱度指标也须要一直调整，一旦一个指标常常放弃失常，就能够将它从绩效指标体系中剔除。举个例子，代码冗余度（有多少代码是反复的）就是一个有用的代码衰弱度指标。
2.3 杠杆指标
反映组织的重点改良方向。很多时候，须要进行某项改良，通过杠杆指标来撬动适应性指标改良。例如，往年要推广接口测试自动化，就能够将接口测试代码覆盖率作为一个杠杆指标，这一指标的晋升有利于保障生产品质。杠杆指标个别是外部指标，所以同样要保障有害性和整体性。一旦改良流动告一段落，杠杆指标可能会变成衰弱度指标，也可能间接被剔除。
三、参考绩效指标体系
有了下面的实践铺垫，能够进入正题，介绍给读者参考的研发绩效度量指标体系。这个体系的指标分成四组，上面将一一具体介绍：
- 响应力，反映研发组织响应市场要求的能力，包含需要消耗时长，时长分布图 K 值两个指标；
- 品质，反映研发组织交付品质，包含生产缺点需要比，测试缺点需要比两个指标；
- 可用度，反映研发组织治理的零碎或服务的稳定性，包含零碎可用度或服务可用度指标；
- 效力，反映研发组织的交付效率，包含需要吞吐率，流动效率两个指标。
3.1 需要消耗时长
需要消耗时长反映研发组织交付需要的速度。为了计算需要消耗时长指标，须要计算一段时间内所有需要的消耗时长，计算繁多需要消耗时长的公式非常简单：
例如，需要 A 提出工夫为 12 月 5 日，需要 A 上线工夫是 12 月 30 日，那么，需要 A 消耗时长就是 25 天，这里，需要提出工夫是指业务人员和研发人员开始廓清需要细节的工夫。
在计算出一段时间内，所有繁多需要消耗时长之后，能够用以下公式计算需要消耗时长：
例如，有 10 个需要，繁多需要消耗工夫别离是 23，42，45，45，45，47，50，62，70，123 天，那么取 85% 百分位数，就相当于取这个数列的第 9 个数（10*85% 后四舍五入得出），最终需要消耗工夫是 70 天，这意味着，85% 的需要是在 70 天内交付的。
需要消耗时长是一个典型的适应性指标，合乎外部性和整体性，研发组织的客户都十分关怀，它代表研发组织的疾速响应能力。在理论应用中，如果研发组织内存在多个不同需要类型，（惯例需要、紧急需要和缺点）那么就须要将这个指标分成几个不同的指标，如惯例需要消耗时长，紧急需要消耗时长以及缺点修复时长等。
需要消耗时长是反映组织麻利度的重要指标，因为须要所有角色群策群力能力优化这一指标，所以所有相干角色都应该对这个指标负责，包含业务人员，产品经理，架构师，开发工程师，测试工程师，运维工程师。开发测试及架构师对这个指标的奉献比拟容易了解，但产品经理和运维工程师对这个指标也有独特的奉献：产品经理须要保障需要尽量明确，对开发工程师提出的疑难疾速响应，对开发完的需要尽快验收；而运维工程师须要在放弃零碎稳固的前提下，尽量放慢移交速度。
需要消耗时长的一个相似指标是需要完成度，例如 2 个月需要完成度，就是计算有百分之多少需要能够在 2 个月内实现。我不举荐应用需要完成度这个指标，因为这个百分比指标会疏导团队谋求 100% 需要完成度，这不合乎软件开发中不确定治理的思路，也疏忽了上面一节探讨的需要消耗工夫散布剖析。
3.2 需要消耗时长散布 K 值
需要消耗时长散布 K 值反馈需要消耗时长的散布特色。为了计算需要消耗时长散布 K 值，须要先绘制需要消耗时长分布图。分布图是一个柱状图，横轴上 X 地位柱状高度是需要消耗时长为 X 天的需要的个数，例如，假如四个需要的消耗工夫，别离是 8 天，8 天，9 天，11 天，那么画出分布图就如下图所示：
下图是一个理论团队的需要消耗时长分布图，合乎韦伯散布（Weibull Distribution），其一个重要特点就是有一个众数尖峰和一个长尾。众数代表大多数需要能够在一个时长区间内交付，是研发零碎交付常态；而长尾代表交付零碎的意外状况。在下图中能够看到因为长尾的存在，导致需要消耗时长的均值大于中值，85% 百分位数大于均值 20%，而 98% 百分位数三倍于均值。
韦伯散布是瑞典工程师韦伯在 1930 年钻研轴承寿命时发现的，他采纳了“链式”模型来解释寿命问题。这个模型假如一个构造是由 n 个小元件串联而成，于是能够形象地将构造看成是由 n 个环形成的一条链条，其寿命取决于最单薄环的寿命。软件研发能够看成一个由需要，设计，开发和测试等环节形成的链条，任何一个环节出问题，软件则无奈按时交付，这是为什么需要消耗时长也合乎韦伯散布的根本原因。
韦伯散布有两个参数，一个是 λ，一个是 k。λ 决定了众数峰值的高度，k 决定了曲线的形态。下图给出了四种 k 值的韦伯散布曲线：
需要消耗时长分布图的 K 值是一个衰弱度指标，用来判断需要消耗时长散布是否正当，是否合乎可预测性要求。如果 K 值小于 1，那么这个研发交付零碎是十分软弱的，不具备可预测性，需要可能很快交付，也可能会十分慢。如果 K 值大于 2，那么需要交付整体上都很慢，但可预测性比拟强；软件开发组织的 K 值会在 1.0 到 2.0 之间。
3.3 生产缺点需要比
生产缺点需要比反馈了研发组织的交付品质。在给定工夫内，生产缺点需要比能够这样计算：
例如，全年生产缺点 200 个，上线需要 2000 个，那么生产缺点需要比的数值为每需要 0.1 个缺点。在理论应用的过程中，如果企业曾经有一套生产缺点分级机制，那么能够应用生产缺点重大级别对生产缺点数量进行加权计算。举个例子，假如在 200 个缺点里有致命缺点 20 个、重大缺点 50 个、一般缺点 130 个，致命缺点权值为 3，重大缺点权值为 1，一般缺点权值为 0.5，那么加权后的生产缺点个数是（203+501+130*0.5），共 175 个，加权生产缺点需要比就是每需要 0.0875 个缺点。
应用这个指标的一个挑战是如何确定需要规模。这个首先要看企业是不是曾经有一套可行的需要规模估算体系，如性能点，UCP 等等。如果有，就能够连续现有的需要规模估算形式。如果没有，那么我强烈建议，在需要上游对需要进行适当拆分，保障需要规模绝对平均，而后应用需要个数来反映需要规模。这其中的起因在前面计算需要吞吐率时，会具体解读。
有些企业为了躲避需要规模这一难题，应用缺点移除率这个指标。我不举荐这个指标，因为它违反了有害性准则，它会激励测试人员多报测试缺点来进步缺点移除率，这样会侵害开发测试团队配合。
生产缺点需要比这个指标是另一个重要的适应性指标，不同类型的企业会有不同的要求。它也与需要消耗时长造成了一对制衡，要又快又好才行。生产缺点需要比应由所有和交付品质无关的人负责，包含产品经理，架构师，开发工程师，测试工程师。
我征询过程中遇到一些团队，埋怨这个指标曾经十分好了，因为生产缺点都曾经私下解决了，没有在零碎中记录，因而，还想去寻求别的指标。其实这时不须要纠结，而应该保障生产品质的前提下，将注意力转向上面两个方面：
- 1、进一步缩短需要消耗时长，进步需要交付速度；
- 2. 改善开发移交品质，升高测试缺点需要比，升高测试老本。
3.4 测试缺点需要比
测试缺点需要比反映开发团队初始移交品质程度。测试缺点需要比的计算形式和生产缺点需要比的计算形式相似：
须要留神的是，这个指标应由产品经理、开发工程师和测试工程师来独特负责。他们的指标应该是在尽量在保障生产缺点需要比的前提下，尽可能升高测试缺点需要比。例如，去年生产缺点需要比为 0.1 个缺点每需要，测试缺点需要比为 1.5 个缺点，那么往年心愿放弃生产缺点需要比不变，但要把测试缺点需要比升高到 0.5 个缺点每需要。测试缺点需要比和生产缺点需要比形成了一对制衡。
测试缺点需要比是一个杠杆指标，它疏导组织的晋升其内建品质能力，即由开发工程师在开发过程中同步保证质量，而不是先构建再修复。这背地就是 Google 始终崇尚的质量观：品质是开发工程师的神圣责任，而不仅仅是测试工程师的责任；只有将开发和测试齐全地混合在一起，水乳交融，才可能真正取得好的品质。
测试缺点需要比的改善会引发一些关联反馈，例如，因为测试前置到开发环节参加品质晋升流动（如实例化需要，故事验收等工作），一个需要的开发测试工夫比会发生变化。Agilean 团队之前辅导的一个产品，测试缺点需要比降落了 90%，同时开发测试工夫比从 1:1 降落到 4:1。另一个长期可能呈现变动的指标是开发测试人力比。家喻户晓，Google 的开发测试工程师比是 10:1，而 Facebook 简直没有测试。随着内建品质能力晋升，开发测试人力比会逐渐晋升。
3.5 技术债权
技术债权是一个衰弱度指标，它代表代码外在品质的衰弱水平，由圈复杂度、代码反复率、每办法代码行等许多指标形成。开源工具 SonarCube 曾经提供了十分好的能力来量化技术债权。
技术债权和需要消耗工夫是一对制衡。还技术债须要消耗开发人力，缩小以后需要开发人力，短期减少需要消耗时长，但能够优化将来的需要消耗时长。把握好这个衡量次要由架构师和开发工程师来把握。
3.6 可用度
可用度指标反映零碎或服务的稳定性。可用度的计算公式如下：
例如，一个零碎的服务水平协定是 7 天 11 小时，那么全年总可用工夫就是 36511 小时，而假如不可用工夫是 50 小时，那么零碎可用度就是 98.75%。倡议由架构师，开发工程师，测试工程师，运维工程师独特负责改善这个指标，运维工程师次要保障软硬件零碎失常，开发工程师和测试工程师次要保障利用零碎失常，架构师、开发工程师和运维工程师独特实现 DevOps，缩短部署耗时，甚至实现不停机部署。不倡议按不可用起因（软硬件系统故障起因，利用故障起因，部署起因）来对这个指标进行细分，这样会减少团队间的摩擦，不利于团队合作。
可用度是一个适应性指标，它实用于本人运维软件、将软件作为服务载体的企业（例如，银行或保险公司）、不适用于将软件作为产品交付进来的公司。这个指标和需要消耗工夫是一对制衡，发的版本越多，需要期待越少，需要消耗时长越短，但可用度可能越低。
3.7 需要吞吐率
需要吞吐率反馈研发组织的产能。需要吞吐率就是单位工夫内每个开发工程师实现的需要规模，例如每人每月实现两个需要，或者每人每月实现五个性能点。
应用需要个数还是需要估算点数来反映需要规模，次要看企业是否曾经有一套成熟且无效运行的估算机制。如果没有，我会强烈建议应用需要个数而不是需要估算点数来反馈需要规模。应用估算点数，容易产生两种危害：
- 让研发人员产生规模激动，想方法（如把需要文档复杂化）来减少估算点数；
- 催生产品经理和研发人员之间的不信赖，进而产生讨价还价、合同会谈等节约，这违反了有害性准则。
因为上述起因，我倡议由产品经理和研发人员一起，将需要分解成颗粒度绝对平均的需要条目，而后用需要个数来示意需要规模。这个指标可能会促使研发人员用能源去更细地拆分需要，但这个副作用对整个组织无利，更小的需要能够更快地交付业务价值。在国内上，用需要个数来代替需要估算的思潮被叫做“摈弃估算”静止，如果读者感兴趣能够点击文章开端的延长浏览去更多理解。
需要吞吐率是一个适应性指标，它和需要消耗时长造成一对制衡，防止团队单纯改善交付速度，而升高交付数量。然而，研发团队不应该仅仅关注交付需要的数量还应该关怀交付后的功效，我倡议团队每个人也同时须要对业务指标负责。
3.8 流动效率
流动效率反映需要交付过程的效率，流动效率计算公式如下：
需要消耗时长一节中曾经介绍了如何计算需要消耗时长，上面介绍如何计算需要增值时长。计算需要增值时长有三种形式：回忆法、记录法和推算法，上面先用回忆法来阐明。访谈参加需要交付的所有角色，请他们回顾交付过程中，他们理论破费了多少个小时，最初将这些工夫汇总。假如，需要 A 廓清环节花了 3 集体 2 个小时探讨，研发花了 4 + 6 小时，测试花了 4 小时，改缺点花了 2 个小时，UAT 花了 3 个小时，部署花了 1 个小时，总共花了 22 个小时，而需要 A 的交付消耗时长为 25 天，那么需要 A 的流动效率就是：
在上述统计过程中，有两点注意事项：
- 倡议用小时而不是人天为单位，因为研发人员工夫都十分碎片化，应用小时能够促成他们更精确地估算；
- 统计工夫，而不是工时，比方 3 集体花了 2 个小时廓清需要，只是将 2 个小时而不是 6 个小时计入需要增值时长。
理解了如何计算一个需要的效率之后，咱们来看如何计算研发交付零碎的整体流动效率。例如，需要 A 增值时长 22 小时，交付消耗时长为 25 天，需要 B 增值时长 30 小时，交付消耗时长 28 天，创意 C 交付消耗时长 40 小时，交付消耗时长 30 天，那么整体流动效率是：
流动效率是一个十分重要的杠杆指标，实现自主流动是精益思维的外围，而每次胜利的精益改革都得益于通过大幅晋升流动效率来大幅晋升交付时效，例如，福特用流水线形式生产 T 型车，将一辆车从 12.5 个小时缩短到了 1 小时 33 分钟；Zara 通过集中式生产，集中式上下游整合将服装生命周期从 6 - 9 月缩短到最快两周。
下面两个例子都是制造业的例子，然而，软件研发过程中流动效率同样十分低下（有钻研表明，研发全流程流动效率只有 1%-5%），这意味着如果可能对软件研发过程进行精益化革新，同样可能大幅缩短交付时效。软件研发流程的精益化革新尽管复杂程度更高，但同时收益微小，因而曾经成为许多大型企业的钻研重点方向。
四、总结
下表对于那些角色应该关怀哪些绩效指标做了一个总结。这个绩效度量体系中的指标能够用于 KPI，也能够用于 OKR。
尽管花了许多工夫来编写这个指标体系，然而须要申明，最现实的绩效度量体系还是没有指度量指标，团队一起群策群力以业务胜利为导向，这是上策。提出这个指标体系只能算一个中策，至多让团队可能解脱不合理指标体系的荼毒。
起源：Agilean
原文公布：GitChat
作者：吴穹
4 月每周四晚 8 点，【冬哥有话说】DevOps 之庖丁解牛，拆解 DevOps 的工具及具体实战。公众号留言“解牛”可获取地址
- 0401《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》
- 0408《继续交付中的版本治理与基于 Azure DevOps 扩大框架的插件开发》
- 0428(周三)《微服务，多团队合作中的 API 测试怎么做 – Pact 契约测试》
- 0429（周四）《BoatHouse 端到端流水线展现》