企业领导者如何赋能软件交付团队？

一份提升软件交付效能、促进价值流动的实践指南

摘要：对于企业领导者而言，赋能软件交付团队的关键，不只是要求团队更快交付，而是通过科学的衡量指标、持续改进机制和健康的组织文化，提升软件交付效能，促进价值持续流动。

对于希望打造高效软件交付团队的企业领导者而言，衡量指标至关重要。没有合适的指标为改进提供方向，团队就很难从实验中获得有效反馈；更严重的是，未经衡量和验证的尝试，甚至可能让结果变得更糟。

因此，我们需要先厘清一个关键问题：衡量“生产力”和衡量“交付效能”，会如何影响软件交付团队实现组织目标的能力？

生产力与软件交付效能

生产力通常用于衡量商品或服务的生产效率。在投入和产出之间关系清晰的场景中，增加投入往往能够带来更多产出。例如，投入更多材料，就能生产更多烤面包机。

但软件交付并不是这样的生产活动。

在软件领域，组织很难找到一种固定的投入组合，使其只要增加投入，就必然产出预期结果。软件团队交付的并不是一批又一批完全相同的实物产品。十行代码如果能带来 10 美元收入，并不意味着一千行代码就能带来 1000 美元收入。事实上，更多代码还可能增加系统复杂性，降低可维护性，甚至削弱业务收益。

因此，在软件交付流程中引入衡量指标时，更健康的方式不是片面追求“生产力”，而是关注“软件交付效能”。

用四项关键指标衡量软件交付效能

海外某项长期研究发现，软件交付效能与组织成果之间存在密切联系。当团队在软件交付方面表现出色时，组织更有可能实现甚至超越既定目标。对于承担关键决策责任的企业领导者来说，这一发现非常重要。它意味着，只要将关注点放在交付效能上，领导者就能够做出更高质量的决策，从而更有效地推动商业目标和非商业目标的实现。

这类研究通常以团队层面的表现为基础。这里所说的团队，是指一个跨职能团队，团队成员共同负责某个产品或服务的持续开发、交付与改进。

自 2014 年以来，海外相关研究持续完善了一套软件交付效能模型。该模型包含四项关键的软件交付指标，通常包括部署频率、变更前置时间、变更失败率和服务恢复时间，以及一组已被证明能够影响和预测交付表现的关键能力。

接下来，我们将分别看看组织中不同层级的企业领导者，如何运用这些洞察来了解并提升软件交付团队的效能。

软件交付经理：从“催进度”转向“建能力”

软件交付经理常常因为尽快完成待办事项而受到肯定，却又会在后续出现质量问题时承担责任。这种评价方式很容易让团队陷入短期交付压力，阻碍更深层次的改进。

如果希望获得长期成功，经理需要关注的不是一时的交付速度，而是可持续的团队效能。而这种效能，只能通过持续投资团队能力来实现。

四项关键指标是评估软件交付效能的有效方法。软件交付经理可以通过这些指标，了解每个应用或服务当前的交付表现，并与团队一起寻找改进机会。海外相关研究提出的核心模型，也提供了一组能力维度，可帮助团队形成具体的改进思路。

例如，团队可能发现部署频率偏低的原因在于部署自动化能力不足。此时，经理可以推动团队围绕部署自动化开展改进，并持续观察这一改进是否真正带来了交付效能的提升。在这一过程中，企业也可以借助 PingCode 这类智能化研发管理工具，将团队目标、客户反馈、需求清理、评审排期、开发、测试、发布和 Wiki 知识沉淀串联起来，让研发过程中的数据更顺畅地流动起来。

需要注意的是，这些指标最适合用来跟踪同一应用在一段时间内的变化趋势，而不是用来进行简单的横向排名。

软件交付效能也不是个人绩效指标。它衡量的是团队修改、更新和交付应用的整体能力，而这种能力只能由团队共同创造。比如，一名工程师的提交速度较慢，原因可能并不是个人能力不足，而是代码评审流程过慢、依赖协调成本过高，或测试反馈周期太长。

因此，作为团队管理者，软件交付经理应始终保持好奇心。在把问题归因于个人之前，先去识别系统内部造成效能差异的根本原因。

总监：为软件交付团队创造提升效能的环境

随着管理者在组织层级中继续向上，关注重点也会自然发生变化。如果软件交付经理向总监汇报，那么总监的核心职责，就是帮助这些经理打造更成功的软件交付团队。

总监经常需要回答这样的问题：某个应用的运行状况如何？某条产品线是否健康？团队的交付能力是否正在改善？四项关键指标的趋势变化，能够为这些问题提供重要线索。

海外相关研究的核心模型揭示了不同能力对组织成果的影响。总监通常处在更适合推动这些能力建设的位置，也更有条件引导软件交付经理为团队创造提升效能的环境。

总监可以鼓励团队围绕关键能力开展实验，也可以帮助不同团队围绕组织目标形成共同愿景。当跨团队协作涉及任务、项目、文档、目标、日历、工时和审批等多个管理要素时，Worktile 这类通用项目协作系统也能帮助团队减少信息分散和协作断点，让管理者更容易看到工作推进的整体状态。

这样的参与方式，能够让总监比传统的年度考核周期更快获得反馈，并在同级管理者或高管层提出变革要求时，更迅速、更有依据地做出回应。

在总监层面，尤其要避免对不同团队的数据进行简单汇总，也要避免在不同情境之间进行粗暴比较。不同应用、不同团队的表现，往往受到技术架构、业务复杂度、团队结构、依赖关系和历史包袱等多种因素影响。

因此，更有价值的做法，是观察同一应用、同一团队在不同时间段内的变化，以此判断软件交付团队是否正在持续改进。

高管领导层：把软件交付效能与组织目标连接起来

在高管层面，软件交付效能应当结合软件本身的目标来衡量。换句话说，组织投资软件一定有其原因，而这个原因本身就应该被持续跟踪和评估。

高管层需要看到交付效能、投入成本与组织目标之间的关系。但需要特别注意的是，不能简单假设“增加投入就一定能提升效能”。

如果某个软件系统的建设目标是缩短响应时间，那么就应该衡量响应时间是否真正缩短。
如果某个软件产品的目标是对外销售并创造收入，那么就应该跟踪其盈利表现。
如果某个平台的目标是提升内部运营效率，那么就应该关注它是否真正减少了等待、返工和人工协调成本。

对于高管领导者而言，持续改进非常适合作为 OKR 的方向之一。在市场快速变化、并购频繁发生、业务重点不断调整的时期，组织推动变化的能力本身，就是一项客观而重要的竞争力。

海外相关研究的核心模型表明，持续改进需要对特定能力进行投资。软件交付经理需要评估这些投资对软件交付效能的影响，而高管层则应进一步关注这些投资是否真正推动了组织绩效提升，也就是是否帮助组织实现了商业目标和非商业目标。

卓越组织如何通过软件交付效能取胜

拥有健康组织文化和高员工满意度的团队，往往能够帮助企业取得优于竞争对手的表现。对于软件交付团队而言，细致而恰当的衡量指标，有助于他们提出更高质量的改进方案，并持续优化价值流动。

但指标也存在风险。

那些对高效能和良好成果至关重要的指标，如果使用不当，也可能反过来破坏成功所依赖的组织文化。例如，当指标被用于简单排名、问责或施压时，团队可能会为了“让数据好看”而采取短期行为，甚至牺牲质量、协作和长期可持续性。

真正有效的做法，是让目标一致性与团队自主性相互结合。

软件交付效能与组织成果之间存在紧密联系，这意味着领导者不应把指标当作控制团队的工具，而应把指标作为帮助团队理解系统、发现瓶颈和推动改进的工具。

优秀的企业领导者，会帮助团队明确共同目标，同时赋予团队足够的自主权，让他们能够反思自身实践，持续实验，持续学习，并在时间推移中不断提升软件交付效能。

归根结底，赋能软件交付团队的关键，不是要求团队交付更多代码，也不是单纯追求更快速度，而是帮助团队更稳定、更高质量、更可持续地推动价值流动。