测量一个工程组织。 – 搞英语 → 看世界

在过去的几年里，我与工程主管一起开展了一个学习圈。出现频率最高的话题是职业生涯管理——接下来我该做什么？第二个最常见的话题是衡量工程团队和组织——我的 CEO 让我报告每月的工程指标，我应该在报告中实际包含什么？

任何关于衡量工程组织的讨论都会迅速挖掘出强烈的意见。除了冲刺点之外的任何东西！只需使用空间！跟踪事件频率！等等，绝对不要跟踪事件频率！做个漂亮的图表就行了，反正他们也不会看！所有这些答案，即使是最后一个，都有一定的道理，但他们跳过了一个重要的警告：衡量工程有很多原因，许多利益相关者要求指标，并且解决每个问题需要不同的方法。

工程测量没有唯一的解决方案，而是有多种工程测量模式，每种模式都适用于给定的场景。要成为一名高效的工程主管，就要为您的工具包添加更多方法，并在为任何给定请求部署哪些方法方面保持灵活性。

您可以使用Engineering Metrics Update 模板来报告这些措施。

为自己测量

当你担任新的执行职务时，你的 CEO 可能会随口说你将“需要为三周后的下一次董事会会议准备一张工程幻灯片。”那是一个非常专注的时刻——我如何避免在我的第一次董事会会议上让自己尴尬！——但即使你对测量的第一个具体证明是一张董事会幻灯片，我也不建议你通过对董事会会发现的东西进行检测来开始你的测量工作有用。

相反，首先要为自己测量。有效运营工程组织所需的信息是什么？当您开始记录您的衡量目标时，我建议从这四个不同的桶开始：

从衡量到计划：什么可以帮助您与跨职能的利益相关者保持一致，以决定在给定的季度、半年或一年内交付什么？至关重要的是，这与您的交付方式无关（“我们在使用敏捷吗？”），而是您的目标是支持项目选择和优先级排序。您需要一个地方来展示工作对业务、产品和工程的影响。您可能会争辩说计划是产品团队的责任，但只有工程才能代表工程所从事的全部项目（例如，产品不太可能为您的数据库迁移制定路线图）。

首先按团队跟踪已交付项目的数量，以及每个项目的影响
运营衡量：您需要知道什么才能确信您的软件和团队每天都在有效运营？将这些视为质量措施可能会有所帮助，因为它们背后的真正问题是：您如何知道您应该遵循计划的路线图而不是蜂拥而至来解决关键问题？

一些不错的起点是：跟踪事件的数量（每个都与事件审查报告相关）、面向用户的 API 和网站停机时间的分钟数、面向用户的 API 和网站的延迟、根据核心业务指标标准化的工程成本（例如，为您最重要的 API 提供服务的成本，只需将每月的 API 请求数除以该月的工程支出即可计算得出）、您产品的用户评分（例如应用商店评分），以及衡量您的产品的入门循环是否有效的广泛指标完成（例如，访问您网站的用户成功转化为用户的百分比是多少？）
优化措施：您需要知道什么才能有效地投入时间来提高工程生产力？如果您将工程视为一个系统，您将如何理解该系统的反馈循环？值得注意的是，这往往是工程师自己衡量他们在贵公司工作经验的方式。

从SPACE或其前身Accelerate开始。如果这些太重，则从开发人员生产力调查开始
激励和渴望的措施：您如何简明扼要地传达工程对业务的变革影响？您将如何激励潜在雇员、新的跨职能主管或董事会成员，让他们了解工程对使业务成为可能的贡献？

维护一份技术投资清单，将不可能的事情（“我们不能在不对我们的整个用户群造成生产影响的情况下进行重大 API 更改”）变成如此明显以至于不值得一提的事情（“我们允许每个单独的 API集成以在方便时而不是在我们的时间表上升级 API 版本”）。当你在公司会议上发言时，着眼于这些世代相传的改进，并尝试将至少一项此类改进纳入每个年度计划周期

当你讨论测量时，一个经常反驳的问题是你是否测量得足够多——我们不应该测量数据库 CPU 负载、拉取请求周期时间等。良好测量的秘诀实际上是测量一些东西。最大的测量风险是什么都不测量，因为您试图测量所有内容。你总是可以测量更多，测量更多是有用的，但是要测量许多小的迭代，不要害怕今天快速简单地测量一些东西。

为利益相关者衡量

专注于快速测量而不是完美测量的原因之一是您公司中有很多人希望您测量东西。有些东西您发现有内在价值需要衡量，但也有些东西是您的 CEO 希望您衡量的，财务部门要求您提供的，在每月状态会议上展示的，等等。

虽然有很多要求，但好消息是这些要求在公司之间很常见，通常可以映射到以下四个类别之一：

衡量您的首席执行官或董事会。许多经验丰富的经理，可能包括您的 CEO，都通过检查进行管理。这意味着他们希望你衡量一些东西，为它设定一个具体的目标，并分享你在实现该目标方面的最新进展。他们没有工程背景来管理您的技术决策，因此他们会将您针对这些目标执行的能力视为您工程领导质量的代表。如果他们深入研究您的衡量指标，他们将专注于工程对业务战略本身的贡献，而不是工程日常工作方式的微观优化。

这些度量不需要新颖，最好的办法是为自己的目的重复使用度量。最常见的是重复使用您的措施进行规划或运营。

要避免的最大错误是要求您的 CEO 通过您的Metrics 来衡量工程以进行优化。尽管直觉上你可以同意提高效率可能会使工程更有影响力，但大多数 CEO 不是工程师，通常无法凭直觉实现这一飞跃。此外，高效仅仅意味着工程可能具有影响力，而不是它实际上具有影响力！
财务措施。财务团队通常会向工程部门提出三个主要问题。首先，与预算人数相比，实际人数趋势如何？其次，与预算的供应商成本相比，实际供应商成本的趋势如何？第三，哪些工程成本可以资本化而不是费用化，在审计的情况下我们如何证明这一点？

您通常必须在预算流程中与财务部门会面，这些流程因公司而异，但通常在任何给定公司内都是统一的。资本化与费用化的问题更加微妙，值得详细讨论；我会说默认方法往往很麻烦，但在财务、审计师和工程师的优先级之间几乎总是存在合理的交集，在满足各方要求的同时略微让各方感到失望。

尽管我很少收到财务方面的要求，但我发现在工程投资主题上与财务保持一致以跨业务优先级和业务部门分配能力特别有价值。在某些时候，您公司内的业务部门将开始争论如何在不同的计划中分配工程成本（因为工程成本足够高以至于分配太多会使他们的新计划遭受重大损失而不是显示出希望），并且有一个明确的记录在案的分配将使对话更具建设性
战略同行组织的衡量标准。您最好的同行组织是积极主动的合作伙伴，可以最大限度地发挥工程的业务影响。乐观地说，这是因为这些职能是由开明的商业远见者领导的。更实际地说，这是因为他们的影响受到工程影响的限制，所以通过优化工程的影响，他们同时优化了自己的影响。找到适合与工程部门建立战略合作伙伴关系的产品、设计和销售职能部门是很常见的。

您通常可以使用规划所需的相同指标，以有效地与战略同行组织保持一致
战术同行组织的衡量标准。虽然战略同行组织可能同意根据其工作的影响来衡量工程，但更具战术性的组织通常会要求根据更具体的结果来衡量工程。例如，客户成功组织可能会推动通过用户工单接受率和解决时间来衡量工程。法律部门可能同样想用合法的票务解决时间来衡量你。战术组织不是战术性的，因为他们缺乏战略思维能力，而是因为他们的组织是以纯粹的战术方式分级的。如果他们与工程部门保持一致以最大限度地提高工程的影响力，他们的组织将被视为成绩不佳。

战术组织对特定的、具体的数字负责，同样希望工程部门对他们自己的特定、具体的数字负责。找到您和同行组织能够达成一致的内容，确定讨论该措施在代表真正的跨组织需求方面的有效性的节奏，并随着时间的推移进行迭代

为利益相关者进行衡量通常很耗时，有时甚至感觉有点浪费。如果处理得当，它仍然很耗时，但可以节省时间，因为它将混乱的、反复出现的讨论整合为更简单、更可预测的关于维护特定、可衡量结果的合同。

对你的方法进行排序

为您自己的目的而衡量的东西列表已经足够长了，一旦您添加了利益相关者的要求，合并后的列表可能会特别长。事实上，工程主管一定需要更多的工程师来支持衡量他们现有的“必备”指标列表，这是一个公认的事实。你永远不会真正衡量你想要的一切。然而，在一两年的过程中，您将能够检测最重要的内容，对其进行迭代，并对它们的实际含义建立信心。

我试图创建一个具体的列表，列出您应该首先测量的内容，以避免将自己分散得太细，但它并没有那么有用。死记硬背的上下文太多了。相反，我提供了三个规则来排序您的测量要求：

有些事情很难衡量，只有在您真正将这些数据纳入决策制定时才能衡量这些事情。如果你不太可能根据数据改变你的方法或优先级，那么衡量一些简单的东西，即使它只是一个代理指标
有些事情很容易衡量，愿意衡量这些以与您的利益相关者建立信任，即使您没有发现它们特别准确。大多数利益相关者将更多地关注意图和努力，而不是实际输出。这是对你愿意为自己的工作负责的肯定，而不是对被衡量事物的证明
只要有可能，一次只承担一项新的测量任务。测量具有惊人的挑战性。仪表可能会出错。数据可能会出现微妙的错误。一次采取许多新措施会花费您或组织中具有验证新数据才能的子集的大量时间，并且一次采取许多措施对大多数组织来说都是一个挑战

通过衡量每个类别的内容来建立跨这些维度的基线。然后，您可能想要重新开始，而不是结束，尽管优先级和关注度较低。测量不是一次性任务，而是持续的迭代。您的特定情况总会有情境背景，这可能会导致您优先考虑略有不同的测量方法。

没关系！不要拘泥于完全遵循这个计划，选择最有用的部分。

反模式

反模式的测量已经成熟。弄乱测量的方式确实数不胜数，但有些情况经常发生，值得大声疾呼：

过于担心测量被滥用。许多领导者担心他们的 CEO 或董事会会滥用数据。例如，他们可能会抱怨许多工程师每周只发布两次代码：这是工程师懒惰的标志吗？认识到这些讨论是非常令人沮丧的，但避免它并不能解决问题！

相反，花时间教育以非建设性方式解释数据的利益相关者。保持开放的心态，总有一些东西要学，即使某个特定的解释是错误的
不要让完美成为优秀的敌人。许多测量项目从未取得进展，因为最好的选择需要您没有的数据。检测该数据进入路线图，但并没有得到优先考虑。一年后，你没有测量任何东西。

相反，推进任何合理的事情，即使它有缺陷
单独而不是在社区中决定措施。我确实建议以清晰的观点来衡量您所看到的效果如何，但这绝对应该与多轮反馈和迭代相结合。特别是当你刚加入一家公司时，很容易将你对上一份工作的理解投射到新工作上，这会削弱信任。

相反，通过吸收团队和同事的反馈来建立信任
使用优化指标来判断性能。人们很容易想使用您的优化指标来判断个人或团队的表现。例如，如果一个团队产生的拉取请求远少于同规模的其他团队，则很容易判断该团队的生产力较低。这可能是真的，但也可能不是。

相反，根据他们的计划或运营指标评估团队。
衡量个人而不是团队。编写和操作软件是一项团队活动，虽然一名工程师可能专注于在这个冲刺中编写代码，但另一名工程师可能专注于成为粘合剂，让第一个工程师能够集中精力。查看单个数据可能有助于诊断目的，但它不是衡量性能的好工具。

相反，专注于衡量组织和团队级别的数据。如果出现问题，请考虑挖掘个人数据进行诊断，但不要直接评估。

如果你避免了这些，你不能保证走在正确的道路上，但很有可能。

后记：建立对数据的信心

推出新的工程措施后，您可能会发现它们不是很有用。这可能是因为不同的各方以不同的方式解释它们（“当我们的总成本仍低于预算时，为什么财务部门对数据库供应商成本的增加如此不满？”）。甚至可能是这些措施与团队使用系统的经验相冲突（“为什么 Scala 团队在平均构建延迟下降时一直抱怨构建延迟？”）。

事实上，测量本身并没有价值，只有反复推动数据，您才能从中获得真正的价值。推动数据从中提取更多价值的一些建议：

每周检查一次数据。确保审查着眼于数据在上个月、季度或年度的变化情况。在可能的情况下，还要建立一个明确的目标进行比较，因为设定目标和未实现的目标都有助于专注于您最需要学习的领域
保持数据变化原因的假设。如果数据的变化违反了你的假设（“当每秒请求数增加时，每个请求的成本应该下降，但在这种情况下，成本随着每秒请求数的增加而增加，这是为什么？”），然后挖掘直到你能完全解释为什么你错了。使用新的洞察力来完善您的假设和跟踪的指标
避免花太多时间单独处理数据，而是让持不同观点的其他人一起推动数据。这将汇集许多关于数据如何反应的不同假设，并允许小组一起学习
细分数据以获取不同的体验。如果您的数据中心和绝大多数用户都在美国，那么欧洲的可靠性和延迟将是无形的——而且可能非常糟糕。同样，Scala、Python 和 Go 也会有不同的底层测试和构建策略；仅仅因为构建时间平均减少并不意味着 Scala 工程师拥有良好的构建体验
讨论客观测量如何与数据所代表的主观体验一致或不一致。如果构建速度越来越快，但触发它们的工程师并不觉得更快，那么深入研究一下——你错过了什么？

当然，还有更多方法可以推送数据，但遵循这些方法将使您走上正确的道路，了解数据的细节和限制。如果你不在数据上花费这样的时间，那么很容易被数据驱动，消息灵通，也很容易得出错误的结论。一些最严重的执行错误源于过于依赖有细微缺陷的数据，但只要稍加努力就可以避免。

原文： https://lethain.com/measuring-engineering-organizations/