4.0 功能抢先看 | 读懂一个项目的研发效能 之 项目交付效率

思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章，浅剧透一下 4.0 的新鲜功能。

最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric（目标-问题-指标），是一套构建软件研发效能度量的系统方法。简单来说，GQM 方法强调面向清晰具体的目标，自上而下拆解，通过问题建立研发的度量模型 + 基于量化数据分析来回答问题，自下而上解读并达成目标。更多解读可以查看《GQM 概述：构建研发效能度量体系的根本方法》。

相比大多数所谓『数据看板』，GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水，而是用来回答具体场景、具体度量目标下的某个具体问题。

我们相信，优秀的效能度量，一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者，也能低成本理解每个指标的含义和指标给出的信息，实实在在将度量用起来，解决他们在研发管理中的遇到的各类“看不清”“说不明”。

接下来的内容，我们将介绍 GQM 看板中的『项目交付效率看板』。

0. 研发效率，为什么总被抱怨？

工程师们有时可能不理解：明明研发团队已经像开足的马达全速运转，每个人都在认真积极地工作，为什么业务侧还在抱怨研发效率低？

其实，就和大多数消费者更关注车速，而非马达转速同理。从业务同事到最终用户，他们可能没那么关心研发团队是否全情投入、工程实践如何先进高效、技术层面的指标有了多少提升，而更关心他们的需求能多快被满足。

如果各方在对“效率”的定义上未达成共识，沟通障碍当然在所难免。

阿里的何勉老师曾分享过研发效率的两个视角：资源效率与流动效率。前者着眼于资源的利用率，后者则更关注端到端的价值交付。项目本就是为了给用户交付价值，当我们度量“项目效率”时，很有可能会优先关注后者。