思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章，浅剧透一下 4.0 的新鲜功能。
最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric（目标-问题-指标），是一套构建软件研发效能度量的系统方法。简单来说，GQM 方法强调面向清晰具体的目标，自上而下拆解，通过问题建立研发的度量模型 + 基于量化数据分析来回答问题，自下而上解读并达成目标。更多解读可以查看《研发效能度量体系构建的根本方法——GQM 从入门到精通》。
相比大多数所谓『数据看板』，GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水，而是用来回答具体场景、具体度量目标下的某个具体问题。
我们相信，优秀的效能度量，一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者，也能低成本理解每个指标的含义和指标给出的信息，实实在在将度量用起来，解决他们在研发管理中的遇到的各类“看不清”“说不明”。
接下来的内容，我们将介绍 GQM 看板中的『项目交付效率看板』。
0. 研发效率，为什么总被抱怨？
工程师们有时可能不理解：明明研发团队已经像开足的马达全速运转，每个人都在认真积极地工作，为什么业务侧还在抱怨研发效率低？
其实，就和大多数消费者更关注车速，而非马达转速同理。从业务同事到最终用户，他们可能没那么关心研发团队是否全情投入、工程实践如何先进高效、技术层面的指标有了多少提升，而更关心他们的需求能多快被满足。
如果各方在对“效率”的定义上未达成共识，沟通障碍当然在所难免。
阿里的何勉老师曾分享过研发效率的两个视角：资源效率与流动效率。前者着眼于资源的利用率，后者则更关注端到端的价值交付。项目本就是为了给用户交付价值，当我们度量“项目效率”时，很有可能会优先关注后者。
可以说，交付效率数据是串联起研发与业务部门间理解和沟通的桥梁。它将研发产出翻译为业务侧可理解的语言——研发团队是否能按预期交付功能？交付需要多长时间？研发团队近期的工作重心是什么？
基于对这些关键信息的共识，业务与产研可以打出默契配合，在对的时间把对的产品推向对的市场。而对于研发团队自身来说，不仅能够对“前线炮火声”更敏捷地做出响应，也是让合作方看到研发团队价值的好机会。
接下来我们回到看板，详细聊聊“认知各项目的交付速率”这一目标下的几个具体问题。首先，我们会从事务交付出发，度量端到端的交付情况；其次，我们会回到代码交付的视角，尝试分析研发团队的改进方向，以支持更高效的交付。
1. 项目的事务交付速率如何？
从交付视角看效率，事务（issue）自然是最重要的度量单位之一。事务可以是一个需求/一个待修复的缺陷/一个任务，比代码行数更具有业务意义，能够更好地反映项目的交付工作量和进度。
为了回答“事务交付速率”问题，我们选取了三个指标：事务吞吐量、事务前置时间（P85）和事务颗粒度。
- 事务吞吐量：即单位时间事务交付的数量，在图中表现为纵轴坐标。
- 事务前置时间（P85）：即使产量不低，如果每个事务都得等上几个月时间，业务方依然会叫苦不迭。事务前置时间即事务从提出到交付上线的总时长，在图中表现为横轴坐标。P85 表示项目中前 85%事务能在该时间段内完成交付，相比中位数，85%分位值更能反映事务交付速率的普遍情况。
- 事务颗粒度：事务颗粒度即事务平均代码当量，在图中表现为圆点的大小，在第二节会有更详细的介绍。
这个指标，一是起到交叉验证、辅助说明的作用：如果某个项目（例如图中右下角的场景团队）事务拆分不够细，可能会导致任务高度耦合、测试成本高、修改难度大，不仅事务交付数量下降，前置时间也会显著拉长；二是起到保障度量可信的围栏指标的作用：如果事务本身大小不一，那么基于事务数度量的交付效率是否可靠都要打个问号。
将三个指标放在象限图中，能够帮助研发团队横向对比阶段/业务属性/规模相似的项目，并快速找到交付偏慢、需要重点关注的项目。
点击项目圆点，即可下钻了解该时间段内该项目的迭代表现，包括研发各环节时长、迭代计划达成情况等，再进一步下钻找到卡点。
2. 项目的事务颗粒度是否控制在合理区间？
前面提到了用事务数来评估交付速率。实际上，很多项目管理工具也能直接统计事务数。你可能要问，那思码逸的交付效率看板有什么区别呢？
关键在于，对于许多团队而言，“事务”这个工作量单位本身就不稳定，基于事务的度量也就不那么可信。如果需求颗粒度上下波动大，有些事务的交付周期长达几个月，另一些只需几小时，用简单一个事务数来概括显然是不合理的。
如果您的团队正属于这种情况，可以先选用事务与代码脱钩版本的交付效率看板，同时开始度量事务的颗粒度，并逐步控制到合理区间内。
思码逸使用代码当量指标（如果您不太了解代码当量，可以查看【代码当量的链接】）来度量事务的颗粒度大小。您可以在看板中看到：
- 不同项目的事务颗粒度分布是否合理。
- 某项目的事务颗粒度的历史变化趋势
- 某项目的事务颗粒度在不同区间内的分布
- 某项目中哪些事务的颗粒度偏大，以及这些事务在代码工作总量中的占比
通过层层下钻，研发团队可以快速找到需求颗粒度欠佳的项目>找到这些项目中具体待改进的事务>对这些事务进行针对性的复盘分析>得出具体的改进措施。
合理控制需求颗粒度，是得到项目交付效率度量的前提。不仅管理者可以看到更有参考价值的度量结果，一线的开发者们也将受益于更准确的交付带宽估算。
3. 研发资源是否能支持更快交付？
有时会出现这样的情况：事务吞吐量挺高，前置时间也短，这下交付效率总该过关了吧？正准备美美表扬下自己和研发同事们，业务同事又友好地出现了：
为什么研发团队交付又快又多，但业务方还在抱怨慢？
可能性一，受客观因素影响，研发交付物不得不频繁偏离预期。本来迭代计划了五个新功能，事实上事故一个接一个，工程师们忙着救火都来不及，新功能只能在喘气的间隙穿插着做。到了迭代结束，只能交付一个功能。对于期待着新功能的用户和业务方来说，体感上交付效率就是慢了几倍。
可能性二，产研重心和业务战略重心没能对齐。比如，当前阶段业务重心在于改进用户体验，提高留存率，而产研侧忙着埋头开发新功能。劲没往一处使，可能就会事倍功半。
以上两种情况，研发资源是足以支持更快交付的，但宝贵的研发资源或多或少被临时挤占或错配，才导致效率不如人意。
思码逸以代码当量为基础数据，关联分析事务交付与代码产能，分析研发团队在新功能、缺陷、线上事故等不同事务上的工作量分布。如果是经常忙着救火，也许可以考虑留出一段时间做质量专项改进，帮助团队在后续工作中轻装上阵；如果是重心出现了偏差，那么可以及时转舵，帮助团队集中精力于最关键的交付。
可能性三，研发团队自身的交付效率是没问题的，是任务频繁变更导致研发的许多辛勤工作都成了无用功。这种情况，卡点主要是在研发以外环节，就需要与业务和产品部门一起坐下来聊聊需求质量如何优化，调动上下游协同提效。
可能性四，对比历史数据，当前产能已经处于较高水平，交付也符合预期，那么交付效率方面的提升空间已经不大了。要满足业务侧的需求，则需要结合人效再进一步分析，想办法提高产能。
以上两种情况，研发团队可以使用代码产能趋势图，来佐证代码交付处于健康状态。
需要提醒的是，数据分析更多起到的是客观度量、提供建议、排除部分可能性、并引导层层下钻的作用，其本身往往难以直接得出行动项。不管交付效率的具体阻碍项是什么，在排查的过程中，由开发者参与的复盘和讨论是必不可少的。
总结
项目交付效率度量的是业务侧和终端用户可理解的研发产出，其端到端的全局视角能够协助研发团队制订出真正有效的改进目标，这也是许多高层管理者最关心的部分。但改进目标如何实现呢？这也是交付效率的局限所在：
交付效率只能在产能不变的前提下，帮助研发团队调整重心，交付更有价值的产物。但效率提升，很多时候还是离不开产能，也就是人效/资源效率方面的提升。在寻找具体的改进方向时，研发团队需要将综合分析交付效率与人效，下钻分析找到关键症结，进而找到最适合自己的提效路径。
下一篇内容，我们将介绍 GQM 看板中的『项目人效看板』。
在线客服.png)
