团队交付的速度变慢了，我该怎么办？

随着团队的发展，他们会放慢脚步。一个更大、更成熟的、负责更大代码库的团队，比一个小型初创公司中的团队需要关注更多的东西，以便更加快速地行动并找到市场匹配度。这需要构建和维护具有更长寿命的复杂系统的专注力。避免过多的技术债务和确保系统的安全性和性能变得越来越重要。所有这些都需要时间和精力，对于技术团队以外的人来说，这可能表现为交付速度的放缓。

虽然速度放缓似乎是不可避免的，但这并不意味着团队停止交付就可以推动未来业务增长的价值。作为一名技术管理者，在你的职业生涯中，你的 CEO 或业务领导可能会问：“为什么一切都这么慢？”你该如何回答这个问题？你怎样提前做好准备？怎样才能让你的团队以最快、最可持续的速度前进？

通常情况下，当团队迅速扩大规模时，例如随着对公司投资和技术团队的增长，交付速度通常会开始变慢。我相信有很多原因导致团队在快速发展的环境中慢下来。

随着团队规模的扩大，随着越来越多的人加入到团队中，沟通变得越来越困难。例如，一个 3 人的团队将有 3 个主要的沟通路径，而一个 17 人的团队则有 136 个可能的沟通路径！因此，要了解正在发生的事情变得越来越难，在不引起认知负担的情况下传播信息也越来越难。

随着团队规模的扩大，不一致性也会成为一个大问题。如果团队和团队成员没有就优先级和下一个任务达成一致，就会导致工作浪费，并产生团队进度变慢的感觉，因为他们没有向产品交付任何价值。例如，在微服务架构中，团队 A 可能正在修改一个服务，而这刚好是团队 B 需要构建的特性的一部分。除非两个团队都意识到协调工作的必要性，否则在测试特性时，如果团队 A 的解决方案中出现了 bug，就很有可能出现不一致，要么工作被浪费掉，要么需要返工。如果团队 A 比团队 B 更早地交付了他们的工作，那么他们很可能需要花费相当多的时间和精力来返工，特别是如果他们已经转移到新的工作上了。我还发现这在更传统的、功能性的团队中也是一个问题，开发后端平台的团队和开发 Web 应用程序的前端团队之间的不协调常常会导致一种感觉，即前端团队交付速度很慢，但其实他们只是在等待后端团队的进度。

在考虑团队需要关心哪些问题时，认知负担也是其中一个。是考虑整个系统（通常会在规模扩大时快速变大）还是将范围限制在系统的一部分？快速扩张的公司经常用技术债务来换取速度，随着系统变得越来越难以维护，开发者体验也变得越来越差，专注于系统更小部分的需求变得更加重要。没有明确内部领域所有权的大型单体代码库意味着工程师需要了解系统的大部分东西。随着代码库的扩大，要在理解系统的大部分东西与对特定部分有更深入的理解之间做出平衡变得不太可能，这也是为什么将单体拆分为服务或微服务变得如此有吸引力。

此外，在初创企业中，其他重要的技术方面的责任，如维护运行应用程序的平台，通常落在一个团队身上。随着团队的快速扩展，在为越来越复杂的平台提供支持的同时构建新功能通常会导致交付速度变慢。引入专门的角色，如平台运维人员，可以减轻工程师的负担，让他们能够专注于软件工程。这确实有助于整个组织加快交付速度。

最后，有时候这只是一个感知或优先级问题。快速扩张的公司的管理者通常习惯于事无巨细地了解正在发生的事情，因为在这些公司规模还很小的时候，这很容易做到。但随着公司规模的扩大，不可避免地会让人感觉交付速度变得不那么快了。因此要学会总结技术团队在发展过程中变慢的原因，并确保直接商业驱动的工作和战略技术工作都得到优先考虑，这样交付的速度就仍然是可预测的。

为了了解交付速度是否在变慢或本来就慢，我们需要知道如何衡量它。

交付速度对不同组织中不同的人来说有不同的含义。关键在于要了解自己的期望是什么、应该追求什么，并弄清组织的规范是什么。

我曾在诺基亚这样的大公司工作过，速度不是他们的首要任务（但肯定曾经是），我也曾在像 Bloom & Wild 这样的快速扩张的初创公司工作过（这样的公司要找到适合的市场，然后快速增长，这意味着执行速度是关键）。那么他们的期望是什么？合适的交付速度应该是怎样的？问问你的领导他们希望看到什么样的结果，然后你就可以做一些更简单的事情来衡量你朝着结果前进时所取得的进展。

至于如何衡量你的速度，我发现有两个很好的着手点。首先是专注于 Nicole Forsgren、Jez Humble 和 Gene Kim 在《加速》一书中提出的指标。在这本伟大的著作中，DevOps 研究和评估（DORA）团队（一个在 2018 年被谷歌收购的研究项目）描述了如何使用四个指标来持续改进实践，更快地交付软件，并保持可靠性。这四个指标是：

• 变更交付时间（Change Lead Time）——从变更请求启动到将变更部署到生产环境中的时间；

• 部署频率（Deployment Frequency）——团队将代码部署到生产环境的频率；

• 变更故障率（Change Failure Rate）——这些代码推送中有多少比例会导致生产问题，如事件、回滚或一般性故障；

• 平均恢复时间（Mean Time to Recovery）——从触发发生到事故被解决的时间。

我建议将这个作为想要衡量团队交付速度的人的着手点。你可以在 InfoQ 的 《加速》书评 中找到更多信息。

最近，《加速》一书中的想法得到了扩展，包含了有助于提升团队绩效和幸福感的其他指标，特别是更多地关注开发者体验。新的 SPACE 框架建立在 DORA 工作的基础上，并建议使用更为广泛的度量指标。

• 满意度和福利（健康检查、开发者效能等）；

• 绩效（结果，即可靠性、客户满意度）；

• 活动（例如部署频率）；

• 沟通和协作（显示谁与谁以及如何连接的网络指标，上手时间等）；

• 效率和流程（例如流程中的转交次数）。

我建议从小处开始，在花时间设置能够进行实际度量的指标之前，先专注于如何让团队了解为什么你要收集这些指标，以及它们将如何帮助团队做出改进。

随着团队的发展，他们会放慢脚步。一个更大、更成熟的、负责一个更大的代码库的团队，比一个小型初创公司中的团队需要关注更多的东西，以便更加快速地行动并找到市场匹配度。他们需要把更多的精力放在构建和维护具有更长寿命的复杂系统上。他们还需要避免过度的技术债务，并确保系统的安全性和性能。这些都需要时间和精力。通常情况下，系统架构会成为进一步改进交付速度的障碍。例如，在一个快速扩展的公司中，一个过于复杂的单体架构会迅速降低团队的交付速度，因为团队的变更不能孤立地进行，或者系统部分之间的过度依赖需要高水平的跨团队协调。

组织的设计在防止交付速度变慢方面起着重要作用，限制人们需要关心的事情的范围是关键。如果每个团队成员都需要维持太多的沟通路径或关系，就会出问题。

例如，在 Bloom & Wild，我们的团队是跨职能的，当团队成员达到 8 个人左右时，我们会将其他人分到新的团队中。我们相信 8 个人的团队既具备取得成功所需的技能，同时又不会让人感觉团队变得迟钝。当一个团队让人感觉到迟钝时，你就会发现，每天的站会变得无聊，参与度下降，保持沟通也变得困难。

我们还限制了团队需要关注的事情的范围。团队拥有一项产品或客户体验的一部分，包括产品和技术领域的东西。我们希望它们的寿命更长，并且尽可能独立地运作，毕竟，那些开发网站或移动应用程序产品页的人怎么会真正去关心运营中心是如何打印东西的呢？

我们把顾客的体验分成五个部分——从发现品牌到收到包裹。这包括从为花束采购花茎到客户账户管理的所有步骤，以及两者之间的所有东西。

我们的工程团队被分成两个不同的部分，每个部分都映射到不同的小组，并且越来越多地映射到不同的应用程序和技术平台。电子商务部门负责我们的核心电子商务领域和平台，从营销技术到跨 Web 和移动应用程序的采购和客户管理。我们的运营技术小组负责内部客户和第三方合作伙伴使用的采购、产品管理和履行平台。

工程团队由平台运营团队（拥有我们的底层基础设施）、IT 团队（拥有我们的 IT 资产）、数据科学团队（与工程团队在基于机器学习的解决方案上紧密合作，为整个公司使用的商业智能系统提供动力）提供支持。

我们对这种团队设置的主要灵感来自伟大的《团队拓扑》一书。上面的模型与业务导向（Stream-Aligned）团队和平台团队的概念存在紧密的映射关系。《团队拓扑》书中提到的业务导向团队是一个与业务变更的主要流程保持一致的团队，具有跨职能技能，并且能够在不等待另一个团队的情况下进行增量交付。平台团队负责底层平台，为业务导向团队提供支持。之所以出现重叠，主要是因为平台简化了原本复杂的技术，并为使用它的团队减少了认知负担。要了解更多信息，我建议从 InfoQ 的 《团队拓扑》书评 开始。

我们还关注产品和技术团队之间的协调。我们发现目标、关键结果和关键绩效指标对我们很有效，不管是让团队在重要的事情上保持一致，还是通过 KPI 来跟踪和纠正整个周期。我们的 KPI 主旨是“技术和团队实现快速和安全的大规模变更”，我们发现给它们打上口号确实有助于在技术团队内外落地。

我们已经在整个公司范围内采用了季度计划周期，这非常有效地确保了所有团队在重要的事情上保持一致，并确保在整个组织中有一个明确的交付节奏。在这个框架中，我们有一个明确的机制来确定工作的优先级，这与利益相关者的理解保持一致，所以如果我们无法为利益相关者确定工作的优先级，我们很清楚是为什么，也很清楚下一个优先级窗口将何时打开。

基于定期的、季度性的计划周期设定明确的预期是最重要的一致性保持点。我们的产品团队在协调利益相关者方面做得很好，采用自上而下的 OKR 方法，确保利益相关者的期望与公司战略和我们的交付能力保持一致。

我所看到的是，当需要考虑技术债务或战略性技术工作优先级但却不清楚这些工作的价值时，会出现更多一致性方面的问题。我们与我们的团队合作，确保他们能够以一种利益相关者和产品团队成员都能理解的方式来有效地解释技术工作的价值。我想说的是，人们在游说需要完成的工作时应该能够“像决策层那样说话”，量化工作的价值是很重要的，无论它是直接由商业驱动的还是对技术策略有利。这意味着需要理解什么对公司来说是重要的，以及团队如何做出贡献。这也意味着需要理解人们真正关心的是什么，这通常不是代码库的状态或是否使用了最新的前端框架，而是将消息转化为业务结果和投资回报的支持，这是利益相关者真正关心的。

就像其他很多事情一样，这是关于如何讲好故事。我们发现使用 KPI 作为当前状态的框架有一定的帮助。周期时间就是其中的一个 KPI，表示从开始工作到在生产环境中实现价值的时间。当改进能够对团队所交付的东西起到明显的作用时，构建关于工作将如何改进正在进行的周期时间或提高团队效率的对话可以真正地吸引利益相关者。让利益相关者成为故事的英雄，是实现最大价值的人，这样真的很管用！

对于我来说，第一个关键点是确保期望是明确的。我发现，如果你是团队的一员，共同创建团队章程确实有助于团队在设定团队的常态和建立“游戏规则”时让成员有参与感。

团队章程应该由团队来制定，由团队所拥有，并且不仅要对团队可见，也要对所有与他们一起工作的人可见。章程定义了他们是谁以及他们喜欢的工作方式。这也是当人们加入或离开团队以及团队动态发生变化时应该重新审视的东西。我介绍了更多关于 定义和使用团队章程) 的方法，如果你想了解更多，可以了解一下它们。

作为我们季度计划周期的一部分，我们还在每个团队中进行团队健康检查，因为虽然交付速度很重要，但这个速度需要是可持续的，我们不要忘记了团队是由人组成的。我们使用了由 Henrik Kniberg 在 Spotify 所创造的 团队健康检查模型 的一个版本，即我们向团队提出一些关于团队、组织和代码库健康等方面的问题。我们的问题与 Henrik 的文章中提到的问题类似，只是针对 Bloom & Wild 环境进行了一些小的调整，所以如果你也想做一些调整，我建议使用 Spotify 的问题作为起点。关键在于要在每个团队中使用相同的问题，这样可以让管理团队的工程经理与团队在特定的行动点上合作，也让技术领导团队在团队之间找到趋势，即行动可能产生最大影响的地方。我们发现，健康检查是提高团队自我意识和集中指导精力的一个很好的工具。事实上，我们在每个季度的计划和交付周期结束时在我们的团队、社区和高级技术领导团队中使用它们。

加强团队之间的沟通也很重要，因为整个组织的速度取决于最慢的团队。建立论坛至关重要，方便团队之间沟通交流。我认为它就像胶水，你需要用胶水把东西粘在一起！我们用一套既适用于团队也适用于实践社区的原则和实践将团队“粘”在一起。

实践社区就是志同道合的人（例如我们所有的 Ruby 工程师）的论坛，他们定期会面，为他们的代码库制定短期和长期的技术策略。它们也是获得支持、指导和建议的地方。它们由我们的技术领导负责运营，将社区紧紧地联系在一起。我们发现这种设定有助于保持团队的独立性，让他们能够以可持续的速度进行交付，同时确保团队中的工程师得到他们需要的支持。

我们发现 Bloom & Wild 已经能够变得更加专注，通过技术内部的协调活动，我们的团队也能够变得更加专注。我们的季度周期是一个关键的推动因素，我们的 KPI 有助于我们在整个周期中保持在正确的轨道上。

通过限制团队成员需要关心的事情的范围，以及通过设计组织来约束团队的产品和技术环境，我们已经能够减轻团队成员的认知负担。这意味着他们可以专注于重要的事情，为公司内外的客户设计和提供更好的体验。

希望你的 OKR 和 KPI 能够告诉你该怎么办，但通常情况下，它首先会从利益相关者那里显露出来。如果一个利益相关者问“为什么技术比以前慢了？”，首先你需要问问自己他们问的问题是不是对的。可能确实需要更长的时间来交付工作，你需要讲述一个故事来解释为什么会这样。在一个快速扩张的公司中，你的利益相关者很可能在他们的团队中也经历过这种情况，所以要找到与他们的经历相似的方法。注重对工作投资回报的理解和协调，利益相关者通常不太理解设计和开发软件所需要做的事情，在这些方面分享更多的信息确实会有所帮助。有时候，向他们解释交付一个特性所要耗费的成本和原因可能意味着这个特性随后根本就没有优先级！

不要认为这是利益相关者的问题。看看你的团队中是否有可以优化的地方。KPI 和历史数据真的可以起到一些作用，它能够让你主动识别问题所在并改变前进方向，可以帮助你形成一种叙事技巧，向你的团队讲述一个关于变更需求的故事，并向利益相关者说明为什么变更是有价值的。

总的来说，这是关于确保你能够理解团队可持续交付的节奏，并利用这一点来优先安排更有影响力的工作。如果你能做到这一点，那么你很可能就会发现利益相关者不会再问“为什么一切都这么慢”这样的问题。

作者简介

Steve Janaway 是欧洲最大的消费者花卉品牌 Bloom & Wild 的工程副总裁，他通过技术将人民更贴心地联系在一起。他对在建立可持续的、快乐的、高效的团队的同时如何利用技术来推动可能性边界充满了热情。他经常撰写和发表关于领导力和软件的文章，并在 Twitter（@stephenjanaway）上谈论有关技术的一切。

原文链接：

https://www.infoq.com/articles/measure-optimise-delivery/

相关阅读：

研究了代码质量后，开发速度提高了 2 倍，bug 减少了 15 倍

有度量才有真管理 研发效能的度量体系建设实践 

做到这 4 点，才是真正的持续交付 | 研发效能提升 36 计（https://xie.infoq.cn/article/99eadb43f1b13fbafc441507a）