如何衡量一个工程组织？工程指标、研发效能与团队绩效度量方法

过去几年里，我一直在组织工程高管学习小组。我们讨论最多的话题，是职业发展：下一步该怎么走？第二常被讨论的话题，则是如何衡量工程团队和工程组织的绩效。

典型问题是这样的：

“我的 CEO 要求我每月汇报工程指标，我应该在报告里放哪些内容？”

任何关于工程组织度量方式的讨论，都会很快引发激烈分歧。

“什么都可以，就是别用 Sprint Point！”

“用 SPACE 框架就行了！”

“要跟踪事故频率！”

“等等，绝对不要跟踪事故频率！”

“做一张漂亮的图表就行了，反正他们也不会认真看！”

这些说法，甚至包括最后一种，都有一定道理。但它们忽略了一个重要前提：衡量工程组织绩效有很多不同原因，也有很多不同的利益相关者会提出指标需求。不同需求，需要不同的工程指标和度量方法。

工程度量没有唯一解。它更像是一组度量模式，每种模式都适用于特定场景。成为一名高效的工程负责人，意味着你需要不断丰富自己的度量工具箱，并根据不同需求灵活选择合适的方法。

本文节选自某海外技术出版社出版的一本工程高管入门类书籍中的相关章节。

先为自己度量工程组织

当你刚担任工程高管时，CEO 很可能会随口说一句：

“你需要准备一份工程方面的幻灯片，用于三周后的董事会会议。”

这句话会立刻让你高度集中注意力：我该如何避免在第一次董事会会议上出丑？

但即便你第一次真正拿得出手的绩效度量成果是一份董事会幻灯片，我也不建议你从“董事会觉得哪些指标有用”开始。

相反，你应该先从自己开始。

你需要哪些信息，才能有效运营工程组织？

在开始明确度量目标时，我建议先从以下四类问题入手。

1. 度量规划：帮助组织做出取舍

你需要哪些指标，才能帮助自己与跨职能利益相关者达成一致，并决定在某个季度、半年或一年内应该交付什么？

这里的重点不是你采用什么交付方式，例如“我们是不是敏捷开发”。真正的目标，是支持项目选择和优先级排序。

你需要一个统一视角，能够展示各项工作对业务、产品和工程的影响。

你可能会认为，规划是产品团队的职责。但只有工程团队能够完整代表自己参与的所有项目。例如，产品团队很可能不会为数据库迁移制定路线图，但这类工作依然会占用大量工程产能，并且对组织长期健康至关重要。

一个简单的起点是：跟踪每个团队已经交付的项目数量，以及每个项目产生的影响。

在研发组织中，这类度量很容易散落在需求、开发、测试、发布和知识库等不同系统里。像 PingCode 这样的智能化研发管理工具，可以把团队目标、客户反馈、需求评审、开发、测试、发布和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，让工程负责人更容易从研发全生命周期视角理解团队产出和研发效能。

2. 度量运行状态：确保团队和系统稳定运转

你需要了解哪些信息，才能确保软件系统和工程团队在日常工作中高效运转？

可以把这类指标视为质量指标。它们背后的真正问题是：

“我们是否应该继续按计划推进路线图，还是应该停下来处理关键问题？”

一些不错的切入点包括：

• 事故数量，并确保每起事故都有对应的事故复盘；
• 面向用户的 API 和网站停机时间，以分钟为单位；
• 面向用户的 API 和网站延迟；
• 按核心业务指标标准化后的工程成本，例如服务最重要 API 的成本，可以用某月 API 请求量除以该月工程支出粗略估算；
• 用户对产品的评价，例如应用商店评分；
• 衡量产品引导流程是否完整的总体指标，例如访问网站的用户中，有多少比例最终成功转化为用户。

这些指标可以帮助你判断，工程组织是在稳定交付，还是正在被隐性问题拖累。

3. 度量研发效能：理解工程效率的反馈回路

你需要了解哪些信息，才能有效投入时间提升工程效率和研发效能？

如果把工程组织视为一个系统，你应该如何理解这个系统的反馈回路？

值得注意的是，这类指标通常也是工程师用来判断自己在公司工作体验的方式。

你可以先尝试 SPACE 框架，或者它的前身 Accelerate。如果这些框架对当前组织来说过于复杂，那么可以先从开发者生产力调查开始。

重点不是一开始就建立完美体系，而是先建立一个能帮助你理解工程体验和效率瓶颈的反馈机制。

4. 度量工程影响力：激励和鼓舞组织

你如何简洁有力地表达工程组织对业务的变革性影响？

你如何让潜在员工、新加入的跨职能高管，或者董事会成员，对工程组织为业务发展做出的贡献感到兴奋？

一种有效做法是维护一份技术投资清单，记录那些让“不可能”变成“理所当然”的技术改进。

例如，过去你可能会说：

“我们无法在不影响所有用户的情况下进行破坏性 API 变更。”

而经过技术投资之后，这件事变成了：

“每个 API 集成都可以根据自身节奏升级 API 版本，而不是被迫跟随我们的统一时间表。”

当你在公司会议上发言时，可以重点强调这类具有变革意义的改进，并力争在每个年度规划周期中，至少包含一项这样的工程投资。

不要试图一次度量所有东西

讨论工程指标时，经常会有人追问：

“这些指标够了吗？我们是不是也应该衡量数据库 CPU 负载、拉取请求周期时间，或者其他更多东西？”

好的度量秘诀在于：真正衡量一些东西。

度量最大的风险在于，你试图衡量所有东西，结果什么都没有真正衡量好。

你当然可以衡量更多东西，而且衡量更多东西也可能有价值。但请通过多次小迭代来逐步扩展，不要害怕今天先衡量一些简单、快速、虽然不完美但有用的指标。

为利益相关者度量工程绩效

相比追求完美度量，更重要的是快速开始度量。原因之一是，公司里有很多人都会希望你提供不同类型的工程指标。

有些指标是你自己认为有价值的；有些是 CEO 要求你提供的；有些是财务部门需要的；有些则是月度业务进展会议上必须汇报的。

虽然需求很多，但好消息是，这些需求在不同公司之间往往很相似，通常可以归为以下四类。

1. 向 CEO 或董事会汇报

许多经验丰富的管理者，包括你的 CEO，都可能采用“通过巡视和检查进行管理”的方式。

这意味着，他们希望你衡量某些指标，设定具体目标，并汇报你实现目标的进展。

他们通常没有足够的工程背景来直接管理你的技术决策，因此会把你实现这些目标的能力，作为衡量你工程领导力的方式。

如果他们深入研究你的指标，他们更关心的通常不是工程日常运作中的微观优化，而是工程组织对业务战略本身的贡献。

这些指标不必是全新的。最好的办法通常是复用你已经在用的度量数据。

最常见的做法，是复用规划指标或运行状态指标。

最大的错误，是要求 CEO 用“优化类指标”来衡量工程效率。虽然从工程视角看，提高效率确实更可能让工程组织产生更大影响，但大多数 CEO 并不是工程师，往往无法直观理解这一点。

此外，高效率只意味着工程组织“可能”产生影响，并不等于它已经产生了实际影响。

2. 为财务部门提供度量

财务团队通常会向工程部门提出三个主要问题。

第一，实际员工人数与预算员工人数相比，趋势如何？

第二，实际供应商成本与预算供应商成本相比，趋势如何？

第三，哪些工程成本可以资本化，而不是费用化？如果遇到审计，我们如何证明这种做法合理？

通常情况下，你需要按照财务部门的预算流程与他们沟通。各家公司预算流程不同，但同一家公司内部通常会有统一规则。

资本化与费用化的问题更复杂，也值得深入讨论。需要指出的是，默认做法往往比较繁琐，但财务、审计和工程团队的优先事项，几乎总能找到一个合理平衡点。这个平衡点通常能满足各方基本需求，同时也让各方都略微感到不满意。

虽然财务部门很少主动要求，但我认为，工程负责人应该与财务部门就工程组织的投资理念达成一致，以便合理分配不同业务优先级和业务单元所需的工程产能。

公司内部各业务单元迟早会开始争论，工程成本应该如何分配到不同项目中。因为工程成本很高，如果成本分摊过多，一个原本看起来很有前景的新项目，可能会变成严重亏损。

一份清晰的成本分配原则，可以让这些讨论更具建设性。

3. 与战略型同级组织协作

最理想的同级组织，是积极主动的合作伙伴，它们致力于最大化工程组织对业务的影响。

乐观地看，这是因为这些部门由有远见的业务领导者领导。更现实地看，是因为它们自身的影响力受到工程组织影响力的限制。因此，优化工程组织的影响力，也会同时优化它们自己的影响力。

产品、设计和销售等部门，通常都具备与工程组织建立战略合作关系的良好条件。

在大多数情况下，你可以使用与规划相关的同一组指标，来与战略型同级组织进行有效协调。

这些指标能帮助大家围绕影响力、优先级和资源分配进行讨论，而不是陷入局部目标冲突。

4. 与战术型同级组织协作

战略型同级组织可能愿意用工程工作的业务影响来衡量工程绩效，但战术型组织往往会要求更具体的结果指标。

例如，客户成功团队可能希望用用户工单接受率和解决时长来衡量工程绩效。

法务团队可能希望用法律工单解决时长来衡量。

这些组织之所以是战术型，并不是因为它们缺乏战略思维，而是因为它们自己的绩效评估标准本身就是战术性的。如果它们为了最大化工程影响力而牺牲自身指标，它们反而可能被认为表现不佳。

战术型部门需要对具体明确的指标负责。相应地，工程组织也需要对自身的具体指标负责。

你需要找到双方都能接受的指标，确定多长时间讨论一次这些指标是否仍然能反映跨部门实际需求，并随着时间不断迭代。

为利益相关者做绩效度量通常很耗时，有时甚至会让人觉得是在浪费时间。

但如果方法得当，它虽然仍然耗时，却能节省大量反复沟通的时间。因为它能把繁琐重复的争论，简化为更清晰、更可预测的协议：我们将围绕哪些具体、可衡量的结果来协作。

在这类跨部门协作中，指标本身只是起点，后续还需要持续推进任务、沉淀文档、安排会议、跟踪审批和同步目标。Worktile 这类通用项目协作系统，可以把任务、项目、文档、IM、目标、日历、工时和审批等协作信息集中起来，帮助战术型同级组织围绕明确结果形成稳定协作节奏。

调整工程指标的度量顺序

仅仅为了满足自身管理需求，需要衡量的指标清单就已经很长了。再加上利益相关者的需求，这份清单可能会变得异常庞大。

事实上，几乎每位工程负责人都会遇到这种情况：你总觉得还需要更多工程师来帮助自己衡量那些“必备指标”。

你永远不可能衡量所有你想衡量的东西。

但经过一两年，你可以对最重要的指标建立仪表盘，不断迭代改进，并逐渐建立起对这些指标真实含义的信心。

我曾尝试列出一份具体清单，告诉你应该优先衡量哪些指标，以避免分散精力。但后来发现，这并没有太大作用。因为每个组织的背景差异太大，死记硬背清单根本行不通。

因此，我更建议遵循三条度量顺序原则。

原则一：难以衡量的东西，只有在会影响决策时才衡量

有些事情很难衡量。只有当你真的打算把这些数据纳入决策过程时，才值得投入精力去衡量。

如果你不太可能根据数据改变方法或优先级，那就先衡量一些简单指标，即使它只是一个替代指标。

原则二：容易衡量的东西，可以先衡量起来

有些事情很容易衡量。即使你认为这些衡量结果并不完全准确，也应该勇于先衡量起来，用它来建立与利益相关者之间的信任。

大多数利益相关者更关心你的意图和努力，而不只是最终结果。

度量结果表明，你愿意对自己的工作负责。它不是对被衡量对象的终极证明，而是一种建立透明度和责任感的方式。

原则三：一次只新增一项重要度量

尽可能一次只承担一项新的度量任务。

度量工作比想象中更具挑战性。埋点可能会出错，仪表盘可能会坏，数据也可能存在不易察觉的错误。

同时引入多项新度量，会大量消耗你或组织中擅长验证新数据的人的时间。而且对于大多数组织来说，同时推动多项度量本身就是一项挑战。

更好的做法是，先在每个类别中选择一项指标进行衡量，建立这些维度上的基线。

完成之后，你很可能会重新开始下一轮迭代，只是优先级和关注点会有所变化。

度量不是一次性项目，而是持续迭代的过程。你的组织总会有一些特殊背景，这些背景会促使你优先选择略有不同的衡量方法。

这没关系。你不必完全照搬任何计划，只需要取其精华，并根据自己的情况调整。

工程度量中的常见反模式

工程度量中有很多反模式。度量出错的方式数不胜数，但有些错误出现得如此频繁，值得特别指出。

反模式一：过度关注指标，却忽略信任缺失

有时，你会陷入指标循环。

CEO 要求你提供工程指标，你提供了指标。但 CEO 并没有因此满意，反而要求你提供另一套不同的指标。

这种情况下，问题的根源往往不是指标不够，而是缺乏信任。

指标确实有助于建立信任，但仅靠指标本身通常远远不够。

更好的做法是，继续追问 CEO 或其他利益相关者的真正担忧，直到你弄清他们所谓“指标需求”背后隐藏的真实问题。

反模式二：让完美主义阻碍进展

很多度量项目之所以停滞，是因为最佳方案需要你现在并没有的数据。

收集这些数据的工作虽然被列入计划，但始终没有得到足够优先级。一年后，你可能什么都没有真正衡量起来。

更好的做法是，即使方案有缺陷，也要坚持推进一个合理版本。

先开始，比等待完美方案更重要。

反模式三：用优化指标评判绩效

人们很容易忍不住用优化指标来评判个人或团队绩效。

例如，如果一个团队提交的拉取请求数量远少于其他同等规模团队，人们很容易就认为这个团队效率较低。

这或许是真的，但也未必如此。

更好的做法是，根据团队的计划指标或运行状态指标来评估团队，而不是直接用局部优化指标下结论。

反模式四：衡量个人，而不是团队

软件编写和运维是一项团队活动。

当一位工程师专注于写代码时，另一位工程师可能正在提供支持，让第一位工程师能更专注地工作。

查看个人数据对于诊断问题可能有用，但它不是衡量绩效的有效工具。

更好的做法是，专注于组织和团队层面的数据。如果发现异常，再深入分析个人数据进行诊断，但不要直接用于绩效评价。

反模式五：过度担心数据被滥用

许多领导者担心 CEO 或董事会会滥用数据。

例如，他们可能看到很多工程师每周只发布两次代码，就大发雷霆：“这是不是说明工程师很懒？”

这类讨论确实令人沮丧。但回避并不能解决问题。

更好的做法是，花时间教育那些用错误方式解读数据的利益相关者。同时保持开放心态：即使某种解读方式是错误的，你也总能从中学到一些东西。

反模式六：独自制定指标，而不是和团队共创

我建议你在做度量时，先明确自己认为哪些方法有效。但这绝不意味着你应该独自完成整套指标体系。

尤其是在你刚加入一家公司时，很容易把上一份工作的理解投射到新组织中，这会削弱信任。

更好的做法是，通过多轮反馈和迭代，把团队成员和同事的意见纳入进来，用参与感来建立信任。

如果你能避开这些反模式，虽然不能保证一定走在正确道路上，但大概率已经离正确方向不远了。

附言：建立对工程数据的信心

当你推出新的工程度量之后，可能会发现它们并没有立刻发挥作用。

原因可能是，不同部门对这些指标的解读不同。

例如：

“为什么财务部门对数据库供应商成本上涨如此不满？我们的总成本明明仍在预算之内。”

也可能是，这些指标与团队使用系统的真实体验相冲突。

例如：

“为什么某个语言团队一直在抱怨构建延迟，而平均构建延迟却在下降？”

事实上，度量本身没有价值。只有持续挖掘数据价值，才能从中获得真正收益。

下面是一些挖掘数据价值的建议。

每周定期查看数据

确保你查看的数据能够反映过去一个月、一个季度或一年内的变化。

尽可能设定一个明确目标作为对比。设定目标，以及未能达成目标，都能帮助你专注于最需要学习的领域。

始终对数据变化提出假设

当数据变化与你的假设相悖时，要深入挖掘，直到你能够解释自己错在哪里。

例如，你可能假设：

“每秒请求数增加时，每次请求的成本应该下降。”

但在某个案例中，成本却随着每秒请求数增加而上升。此时，你就需要继续追问：

“为什么会这样？”

利用这些新见解，完善你的假设和后续跟踪的指标。

不要独自研究数据

避免一个人花太多时间研究数据。

你应该邀请持有不同观点的人，一起深入分析数据。

这样可以汇集对数据变化的多种解释，也能让团队共同学习。

对数据进行细分

数据需要细分，才能捕捉不同用户或团队的真实体验。

如果你的数据中心和大多数用户都位于美国，那么欧洲用户的可靠性和延迟问题可能会被平均值掩盖，甚至可能已经非常严重。

同样，不同编程语言的测试和构建策略也可能完全不同。平均构建时间缩短，并不意味着所有工程师的构建体验都变好了。

比较客观数据与主观体验

你需要讨论客观度量结果，是否与数据所代表的主观体验相符。

如果构建速度确实变快了，但触发构建的工程师并没有感觉到速度提升，那就应该继续深入探究：

到底是哪一个环节出了问题？

当然，还有很多其他方法可以深入挖掘数据。但遵循这些方法，能帮助你更好地理解数据的细节和局限性。

如果你不花时间研究数据，即使你掌握了大量信息，也很容易得出错误结论。

一些最严重的管理失误，正是源于对存在细微缺陷的数据过度自信。但只要多花一些精力，这些失误往往可以避免。