工程交付指标入门：如何重新掌控软件交付

对于希望提升研发效能、优化 DevOps 实践和加快软件交付速度的工程团队来说，工程交付指标正在变得越来越重要。它们不仅能帮助团队观察交付流程中的瓶颈，也能让工程管理者更清楚地判断：团队到底是被流程拖慢，还是被系统复杂度、协作方式或发布机制限制住了。

在加入海外某支付科技公司之前，我曾在海外某音乐科技公司负责工程团队的搭建、扩张和管理，时间接近四年。回头看，那段经历中最具挑战性的工程管理问题之一，是如何在团队从 5 人快速增长到 55 人以上的前 18 个月里，继续提升软件交付速度。

随着工程团队迅速扩张，我们的软件交付能力一度几乎停滞。公司规模较小时行之有效的流程，已经无法支撑这种爆发式增长。我们必须找到重新回到正轨的方法。

后来，通过持续关注工程交付指标，我们显著提升了软件交付速度。你不必只相信我的描述。如果查看 2018 年 5 月到 2019 年 4 月的交付前置时间数据，就能清楚看到这一变化。

这张图表展示了我们如何在一年内逐步稳定交付周期。该指标的平均值从数百小时降至数十小时。即便在组织架构频繁调整的情况下，表现最好的交付周也能将交付前置时间控制在 20 小时左右。

更重要的是，我们并不是通过延长工作时间或周末加班来实现这一点的。真正起作用的，是流程优化，以及用指标观察、引导并验证改进方向。

今天，任何工程团队都可以通过理解并采用一些相对简单的工程交付指标，重新掌控自己交付生产可用软件的能力，并以更快、更稳定的节奏推进软件交付。

什么是工程交付指标？

工程交付指标，是用来衡量软件开发中“交付阶段”表现的一组指标。

这里强调的是“交付”，而不是完整的软件开发过程。原因在于，软件设计和产品探索阶段往往存在很大差异。在开发早期，我们通常并不完全清楚最终应该构建什么，需求也会随着用户反馈和业务判断不断变化。

为了让衡量更可控，我们可以先聚焦工程师更容易影响和改进的那部分流程。也就是说，我们可以将交付过程简化为：从代码提交开始，到代码在生产环境中运行结束。

产品设计与开发	产品交付
通过假设驱动的交付方式、现代用户体验方法和设计思维，创造能够解决客户问题的新产品和服务。	通过规范工作流、减少变异性和批量规模，实现从开发到生产的快速流动和可靠发布。
功能设计和实现可能包含此前从未做过的探索性工作。	集成、测试和部署应尽可能快速、持续、可重复地进行。
估算结果存在较大不确定性。	周期时间应尽可能清晰、稳定、可预测。
结果差异可能很大。	结果应具有较低变异性。

在整个交付过程中，我们可以设置很多不同指标。但这些指标是否有效，取决于组织真正想要获得什么结果。

在开始衡量之前，我们必须先问自己一个问题：

我们希望通过这些指标实现什么目标？

指标本身没有绝对的好坏。它们可能带来帮助，也可能造成伤害，关键取决于组织所处的具体情境，以及我们是否有能力正确理解和使用这些指标。

常见的工程交付相关指标包括：

• 构建时间
• 代码变更量
• 代码变更规模
• 合并耗时

如果缺乏上下文，很难判断这些指标是否能带来预期结果。例如，如果我们只衡量代码行数，真的会得到积极结果吗？很多时候，删除代码可能比新增代码更有价值。

为什么要使用工程交付指标？

比起“衡量什么”，更重要的问题是：为什么要衡量？

软件交付是工程团队及其流程自然产生的结果。就像心率是心脏活动的自然结果，能够反映心脏健康状态一样，交付指标也能帮助我们了解工程组织的运行状态。

当指标与明确目标结合起来时，我们就能更清楚地观察组织如何交付软件，并围绕真实流程持续改进。

在前面提到的那家海外公司，我们关注交付指标的目标，是消除工程师在软件交付过程中遇到的障碍，因为我们希望更快地学习。

对于初创公司的产品工程团队来说，每一行被交付给用户的代码，都是一次学习机会。如果我们的目标是“通过更快交付生产可用软件，让组织的学习速度超过市场变化速度”，那么我们就必须找出阻碍交付的因素，并持续改进它们。

当然，如果一家公司主要服务企业客户，关注重点可能就不只是迭代速度，而是服务可靠性、交付稳定性和风险控制。

因此，在选择工程交付指标之前，先明确衡量目的。以下是一些常见目标：

• 提升可靠性
• 提升质量
• 降低投入成本
• 提高吞吐量
• 提升成本效益
• 提升人员配置效率
• 加快学习速度

哪些工程交付指标真正有用？

如果你在网上搜索“工程交付指标”，会看到大量结果。但这些内容并不总是实用，也不一定符合你的组织目标。

当我们刚开始探索这个方向时，我发现最有价值的资料，是不同团队和公司发布的一系列报告。我们必须把这些资料拼接起来，才能形成真正可执行的结论。

幸运的是，海外某位软件交付研究者及其团队已经完成了大量基础研究，并将成果总结在一本关于高效软件交付的经典著作中。在我看来，这类研究标志着工程领导力进入了一个新阶段：学习如何成为优秀工程领导者，不再只能依靠大型科技公司内部的口耳相传，而是可以建立在更系统的研究和实践框架之上。

在这项研究中，研究团队提出了四个核心指标。它们如今也常被视为软件交付绩效指标或 DevOps 指标的重要组成部分。研究团队发现，这些指标能够较好地反映数千家组织的软件交付绩效。基于这些研究，他们还提出了一套能力框架，帮助软件组织提升交付表现，并进一步改善业务结果。

其中一个非常重要的结论是：软件交付能力与组织绩效之间存在显著关系。换句话说，擅长软件交付的公司，往往也更有可能取得更好的整体业务表现。

这四个软件交付绩效指标分别是：

1. 交付前置时间
   代码从提交到进入生产环境需要多长时间。
2. 部署频率
   团队多久向生产环境部署一次。
3. 平均恢复时间
   发生故障后，团队需要多长时间恢复服务。
4. 变更失败率
   有多少比例的变更会导致服务降级，或需要后续修复。

故事点和速度指标能衡量软件交付吗？

敏捷开发中的“速度”并不是衡量软件交付流程的理想指标，因为它最初是作为容量规划工具设计的。

当我们用速度来衡量生产力时，问题主要出在两个方面。

首先，速度是一个相对指标，并且高度依赖具体团队。不同团队面对的业务环境、系统复杂度、技术债务、协作方式和外部依赖都不一样，因此不同团队之间的速度并不能直接比较。

其次，一旦速度被用作生产力指标，团队就会很自然地想办法“提高速度”。他们可能会放大估算，优先完成更多用户故事，甚至减少与其他团队的协作。因为跨团队协作可能会降低本团队的速度，却帮助其他团队提升速度。

这样一来，速度不仅失去了原本作为规划工具的意义，还可能破坏团队之间的合作关系。

应该如何使用工程交付指标？

如果不了解你和团队面临的具体问题，很难给出真正有效的建议。因此，我曾向一些工程负责人询问他们在使用交付指标时遇到的困惑，并从中发现了几个常见问题。

如何说服团队接受交付指标？

过去几年，我曾为多家公司提供过交付指标相关咨询。几乎所有领导者面临的第一个挑战，都是如何让团队接受这些指标。

根据我的经验，团队是否愿意接受指标，很大程度上取决于两件事：他们是否理解指标的目的，以及他们是否信任你。

遗憾的是，很多组织曾经把指标用于评判个人绩效，而且评判维度并不真正反映工作价值，比如代码行数。这类糟糕的管理实践，会削弱管理层与工程师之间的信任。因此，工程师对指标保持怀疑，是完全可以理解的。

如果想成功推动团队采用交付指标，你必须明确说明指标的用途，并给出充分理由，解释为什么这些指标能够帮助团队实现预期结果。

你可以向团队解释以下问题：

• 我们为什么需要这些指标？
• 我们具体要衡量什么？
• 谁可以看到这些指标？
• 为什么选择这些指标，而不是其他指标？
• 我们准备如何推进指标体系建设？
• 这些指标会如何影响个人？

工程经理应该用和工程师解决技术问题相同的标准，来解释管理问题：清晰、严谨、有推理过程，并允许讨论和质疑。

就我个人而言，撰写一份 RFC 形式的提案，帮助我厘清了许多模糊细节。而团队成员通过提出问题，也让这份提案变得更加完善。

在部署交付指标的过程中，我学到的最重要一课，是信任的重要性。

要让指标真正发挥作用，我需要团队相信我的意图，并愿意接受我提出的策略。尤其是在一开始，我自己也无法完全确定最终结果会是什么。

你不仅要能回答上面列出的问题，还要准备好回答更多问题。更重要的是，这些回答必须让团队相信：即便具体做法还需要探索，整体方向也是值得信任的。

作为工程师，如何避免交付指标被用来“对付”自己？

我从一线工程师那里听到的最常见问题，是如何避免这些指标对自己产生负面影响。

我认为最好的方式，是始终围绕指标的预期结果提问，并通过问题反推出衡量目的。

在这个过程中，你可能会发现，管理者引入指标的真实目的，是评估个人绩效。如果是这样，你很可能遇到了一位误解交付指标及其适用场景的经理。

根据你所在组织的情况，以及你与经理之间的关系，你可以尝试鼓励对方重新思考这种做法，或者把相关资料推荐给对方阅读。当然，这并不是一个容易解决的问题。

工程师还可能遇到另一种情况：团队对外部承诺或预期管理不善。

这时，引入指标的目的并不是为了帮助团队改进，而是为了安抚外部利益相关者。团队被要求拿出数据证明自己“正在变快”，但并没有真正获得资源、时间或授权去解决交付瓶颈。

这种做法非常危险。指标不是为了随意调整，以取悦他人；指标的意义，是让团队观察阻碍前进的因素，并据此采取行动。

如果没有改进计划，单纯衡量只会让团队失去动力和参与感，最终适得其反。

管理团队决定采用交付指标，实际上意味着他们承诺投入资源，加速软件交付流程。他们应该明确分配人员和精力来推进这项工作。否则，这就只是监控，而不是团队加速。

如果你作为个人贡献者遇到这种情况，可以尝试依靠资深工程师的支持，并主动参与指标改进计划。这可能有助于避免指标被错误使用。

但也要记住：指标不只是管理工具。恰恰相反，交付指标可以让工程师更清楚地看到团队是如何交付软件的。

交付指标的重要价值之一，是它为团队提供了一套共同语言，让每个人都能基于数据讨论：哪些工作对大规模交付高质量软件至关重要。

例如，你可以用周期时间说明：如果一个项目只有一名工程师单线推进，代码审查资源不足，很可能会拉长交付周期。为了按计划推进，团队可能需要增加协作者，或者减少并行工作量。

掌控你自己的指标，并用它们帮助团队清除障碍。

如何真正衡量自己想衡量的软件交付能力？

我在帮助不同组织衡量交付表现时发现，另一个常见问题与衡量方法有关。

作为工程师，我们往往过于关注工具。但事实是，每个组织的交付流程都不一样。即便在同一家公司内部，不同团队的流程也可能存在差异。不同团队使用不同任务跟踪工具的情况并不少见。

如果一开始就从工具出发，你可能很难真正聚焦自己想达成的目标。因为你最终可能会把大量时间花在工具配置上，或者为了适应工具而调整流程，反而忽略了团队真正需要解决的问题。

工具当然重要，也确实有些工具比另一些更好用。但就像任务管理软件一样，它们是否合适，取决于你的具体需求。对于希望把工程交付指标真正落到日常研发流程中的团队来说，PingCode 这类智能化研发管理工具可以将目标、需求、开发、测试、发布和 Wiki 知识沉淀等环节连接起来，并打通研发工具链，让交付过程中的数据更容易被追踪、分析和持续改进。

在购买昂贵的 SaaS 工具之前，一个简单的方法或许就能帮助你看清真正需求。

几个月前，我采访了一位长期研究软件交付绩效的海外学者，请她为想要衡量团队绩效的领导者提供三条建议。她的回答非常值得参考。

1. 一份调查问卷就足够了

通过调查团队成员的软件交付体验，你就能相当清楚地了解问题在哪里。

这位研究者还提到，相关研究团队曾公开过用于收集四项软件交付指标的调查问卷。现在，这些资源还增加了交互式快速检查和基线数据，可以帮助团队更低成本地开始衡量。

2. 接受现状，即便它并不好看

一个基准线，即便是很糟糕的基准线，也能帮助你前进，因为它提供了参照框架。

例如，你原本设定的目标是每天部署多次，但实际测量后发现团队每月只能部署一次。此时最重要的不是美化数据，而是调整预期，接受现实，并制定改进计划。

如果你对当前表现没有清晰认识，就永远不知道应该改进什么。同样重要的是，你也无法判断后续努力究竟取得了哪些成果。

3. 持续改进胜过五年规划

假装自己已经知道所有需要改进的地方，往往会带来问题。

与其制定一个宏大的多年交付加速计划，不如围绕预期结果持续迭代。小步改进、持续反馈，通常比一次性规划更有效。

与这位研究者讨论这些建议很有意思，因为我自己也经历过类似过程。除了调查问卷这一点之外——我真希望当时我们做的是调查，而不是试图把代码托管平台的数据导入数据仓库，再用可视化工具绘制图表。

一开始，我凭感觉设定了一个周期时间基准：36 小时看起来不错。但后来我们发现，这个数字还可以继续优化。

我们还组建了一个专门团队，在其他产品工程团队支持下，持续推进指标改进。工程师被赋予了调整流程的权力，因此交付流程才能随着时间推移不断优化。

如何用交付指标管理团队？

答案是：不要这样做。

交付指标的目的，是帮助你和团队发现交付流程中的改进机会，进而减少流程摩擦，把更多精力投入到真正重要的产品问题上。

试图用交付指标管理个人，就像试图测量单个心肌细胞的心率一样，并没有太大意义。

我不建议使用部署频率或周期时间来衡量个人交付表现。现在，许多软件工具都在尝试提供个人层面的交付洞察，但根据我的经验，我建议你谨慎对待这种做法，甚至尽量避免。

解决个人绩效管理问题有更好的方式，例如提升管理者能力，为团队设定合理目标和期望，并通过持续反馈进行管理。

交付指标不应该取代管理判断。

结语：用工程交付指标持续提升研发效能

工程交付指标如果与明确的组织目标结合起来，可以显著提升组织的软件交付能力。

得益于海外软件交付研究者和一线工程团队的实践积累，我们现在拥有了一套更成熟的语言和工具，可以在工程团队内外讨论软件交付，也能更好地理解如何打造高效工程组织。

例如，我们可以利用周期时间分析“单人单线推进项目”对交付的影响，因为代码审查人员不足往往会延长软件交付时间。我们也可以审视自身流程，而不必一开始就构建复杂工具或采购昂贵的 SaaS 服务。

既然这些指标已经可用，作为领导者，我们就有责任确保它们被正确使用。

真正有价值的工程交付指标，不是用来给个人施压的，也不是用来向外部证明团队“看起来很忙”的。它们应该帮助我们更可持续地交付高质量软件，帮助团队发现瓶颈、消除阻碍，并服务于我们所领导的个人、团队和组织。

当团队能够正确理解交付前置时间、部署频率、平均恢复时间和变更失败率等关键指标时，软件交付就不再只是依赖经验判断，而是可以被观察、被讨论、被持续改进的工程能力。