什么是技术债务？

「债务」这个比喻非常恰当。最早提出「技术债务 Technical Debt」比喻的工程师 Ward Cunningham 对此做了详细的解释：

有了借来的钱，你可以比采用其他方式更快地做某件事情，但在还清这笔钱之前，你需要支付利息。我认为借钱是个好主意，我也认为赶快对外发布软件以获得经验是个好主意，但当然，你最终会回到这来，并且随着你愈加了解软件，你会通过重构程序来偿还那笔贷款，以此反映你所获得的经验。

本文将与你讨论技术债是如何产生的。但在那之前，我们先了解一些与技术债的产生原因和本质有关的常见误解。

误区一：技术债务 == 坏代码

到底什么是「坏代码」？

好的代码或许是整洁的代码，也可以概括为不会迫使你在未来做出特定决策的代码，它保留了选择的余地。而坏代码则不留余地，还会强加上一些原本不存在的约束。

我几乎没见过由「糟糕的开发者」编写的「坏代码」，至少在生产项目中没有（这正是代码审查的作用）。我遇到的大多数「坏代码」都出自受到约束影响的优秀的开发者。

误区二：技术债是错误的

技术债务和金融债务一样不分对错好坏。在非理想状态下——即没有足够的「现金」来满足需要——它就是产品开发工具箱中的一个有效工具。

误区三：构建完成就万事大吉

最常见的软件开发的比喻是修建建筑。在建筑行业，工作是按顺序进行的：

• 建筑设计师设计建筑并绘制图纸；
• 工人们挖掘地基、修建上层建筑、铺设管线并进行室内装修；
• 业主和租户高兴地搬进来，如有任何问题，再找维修人员解决。

这是一个通俗易懂的比喻，但却和软件行业不怎么类似。

与建筑相比，软件更像是园艺——它比混凝土更有机。你根据最初的计划和各种条件在花园里种植许多花木。有些花木茁壮成长，另一些注定要成为堆肥。你可能会改变植株的相对位置，以有效利用光影、风雨的交互作用。过度生长的植株会被分栽或修剪，颜色不协调的会被移栽到从美学上看更怡人的地方。你拔除野草，并给需要额外照料的植株施肥。你不断关注花园的兴旺，并按照需要（对土壤、植株、布局）做出调整。——《程序员修炼之道》

在（错误的）建筑比喻中，大部分成本是预先产生的。维护成本要么是名义上的，要么被视作偶发事件而忽略不计。

在园艺的比喻中，构建功能是漫长工作中的一个步骤（就像种植作物）。花园越大，所需的维护就越多。这是在重新种植以改变布局（重构），或扩大花园并种植新作物（添加新功能——这也需要维护）之外的工作。

90% 的软件成本均与维护有关——我很多年前就知晓这个数据，但每每想到还是觉得难以置信。

技术债是怎么产生的？

那么，技术债究竟从何而来？它可以避免吗？

技术债务的另一种理解可能是，项目当前所处的状态与「假设利用积累的知识重新开始而现在应处的状态」之间的差值。

技术债有两个来源：

• 决策的权衡和取舍（鲁莽 vs 谨慎）
• 制定和执行决策时所具备（或缺乏）的知识，即有意和无意

理想情况下，你会在充分了解情况且不向约束条件妥协的前提下做出决策。但现实可能是，你在没有全盘了解信息和背景时就启动了项目，还要根据时间限制（如利益相关者给的截止日期）或成本限制等约束做出权衡。

如何避免技术债是一门学问，而对「技术债可否避免」这一问题，我的回答是：

“可以避免，但技术债是一种工具，不是敌人。”

如何量化技术债？

「现在有多少技术债？」这么抽象的概念真的能被量化吗？

真的很难，或者说你无法可靠地跟踪技术债。如果向软件工程师了解如何实现某个功能或修复产品的某个部分，他们可能会提供一个估算结果，并将需要偿还的技术债务涵盖在内，但你仍然无法追踪它。

Chelsea Troy 提出了一个与技术债务高度相关的可量化指标：维护负载（maintenance load） 。

维护负载描述了开发团队花费多少精力来保持现有功能同以前一样运行。—— Chelsea Troy

维护负载是有关项目年限和构建实践的函数，其衡量单位是持续付出维护精力的开发者数量（ongoing developer effort）。

需要说明的是，维护负载 != 技术债务。

但它依然是一个非常不错的技术债务指标。如果需要更多的工程师来防止系统/项目崩溃，那么很可能意味着你有很多技术债。如果仅靠十几个人就能建立一家价值 10 亿美元的公司，那么他们大概率很好地控制住了技术债。

（作者 Jacob Bennett，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

技术分享 | SpringBoot 流式输出时，正常输出后为何突然报错？

用 MVP(最小可行性产品) 做低成本快速验证，为什么不灵了？

6 大原则！助你构建高绩效的研发强军 | Liga译文

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

然而，尽管出现了许多理念和项目管理框架，例如敏捷（Agile）、Scrum、极限编程（XP）、看板（KanBan）和团队拓扑（Team Topologies）等，但只有少数企业知道如何高效地开发软件。我遇到过许多错误模式，最终导致进度延迟、软件质量恶化和客户满意度下降。为了避免无效管理并达成更优秀的表现，你应该了解软件项目/产品管理的最佳实践、理念及原则。

其中影响范围最大的实践之一是搭建团队结构的方式。许多研究（如康威定律）证明，如果用错误的方式搭建团队结构，团队绩效将受到极大的制约。在本文中，我将根据自己的经验和深入研究，解释能够在组织中构建有效结构的几项原则。

1. 系统设计先行

搭建高绩效研发团队的第一条原则，是在设计团队结构之前，先设计你想要的系统。美国计算机科学家和计算机程序员 Melvin Edward Conway 于 1967 年提出康威定律（Conway’s Law），该定律描述了组织的结构和沟通方式将制约其生产的系统设计。如果一个组织组建了设计团队、业务团队、前端团队和后端团队，那么系统的输出也将是业务文档、设计组件、前端组件和后端组件，这需要大量的团队沟通才能完成最终的整合并交付给用户。康威定律下的团队结构是最普遍的反模式之一，直到今天仍有许多组织在使用。

下面这种团队结构无需频繁交流，也能让团队独立地为用户提供价值（尽管无法做到完全独立）。它也被称为流对齐团队、功能团队或跨职能团队。

2. 考虑认知负荷

Matthew Skelton 和 Manuel Pais 于 2019 年出版的《高效能团队模式：支持软件快速交付的组织架构》描述了软件研发组织中的四种基本团队：流对齐团队（Stream-aligned team） ，使能团队（Enabling team） ，复杂子系统团队（Complicated subsystem team） ，以及平台团队（Platform team） 。这四种基本团队的背后是一个重要的心理学理论：认知负荷——指工作记忆资源的使用量。

上一条原则所解释的团队结构在《高效能团队模式》中被称为流对齐团队。流对齐团队是跨职能的，也是独立为用户提供价值的主力军。然而，流对齐团队太忙了，以致于无法赶上新玩意儿，比如新的技术、管理方法或领导力，也无法处理基础设施。如果把过多的责任压在流对齐团队身上，他们就无法处理任务，团队表现也会变差。 因此，为了减轻他们的认知负担，其余三个团队（使能团队、复杂子系统团队和平台团队）都要前来支援。

• 使能团队帮助流对齐团队学习向用户交付更高价值所需的新事物，诸如技术、架构、UI/UX、管理方法等。使能团队可能由内部/外部导师、教练或顾问组成，他们可以在流对齐团队中教授和实施新事物。
• 复杂子系统团队负责需要特殊技能或可与正常交付隔离的特定组件，例如机器学习模型、特殊图形/动画或认证 API。复杂子系统团队所处理的组件将通过讨论确定，因为它们与流对齐团队之间没有明确界限。
• 平台团队负责构建和提供一个平台，以让流对齐团队可以在该平台顺利地部署和发布，向用户交付价值。 在团队拓扑的背景下，平台是一个包括文档、指南、DevOps 和基础设施的综合概念，旨在帮助流对齐团队顺利部署。

3. 保持团队精干

原则之三是让团队保持「小而精」。 许多研究和知名企业都表明，「小而精」有比「大而全」更高的效率、更好的业绩——这是因为小团队的沟通更加有效，团队中的每个人都能随时了解情况，并提高参与度。亚马逊自创立之初就实行「两个披萨」原则（即组建团队和参加会议的人数不超过 9 人）并取得了真正的成功。

《敏捷革命》的作者 Jeff Southerland 在「Scrum 指南」中也解释说：“Scrum 团队小到可以保持灵活性，大到能够在一个迭代内完成重要工作，通常是 10 人或者更少。总的来说，我们发现较小的团队沟通更顺畅，工作效率更高。”

4. 仆人式领导力

Daniel H. Pink 在《驱动力》一书中提出了「驱动力 3.0」。他认为自工业时代以来，人类的行为动机已然发生了变化，他还审视了驱动力的三大要素：自主、专精和目的——它们可以持续激励我们。

• 自主（Autonomy） ：人类想要决定如何做。
• 专精（Mastery） ：人类想要成长。
• 目的（Purpose） ：人类寻求意义。

由 Robert K. Greenleaf 提出的「仆人式领导理论」正是驱动力 3.0 的体现。这是领导哲学的一种，其主要实践是为团队服务，使团队成员在工作中保持高度的参与度、积极性和可持续增长。在传统的领导方式中，领导者（老板）以命令和控制的方式命令团队成员（下属）做什么以及如何做。传统的领导风格无法激励个人，也无法提高他们的参与度和工作表现。

而仆人式领导者会设定一个目标和愿景（目的），将实现目标和愿景的方法下放给个人（自主），并提供学习新东西的机会（专精） 。

5. 持续改进

截至 2024 年 1 月，丰田是全球最大的汽车公司，其实践和理念一直影响着所有商业行业，如七大浪费、5S（Seiri 整理、Seiton 整顿、Seiso 清扫、Seiketsu 清洁、Shitsuke 素养）和 3M（Muri 超负荷、Muda 浪费、Mura 不均匀）。其中，最著名的理念是 Kaizen（改善）即持续改进业务流程。无论业务类型或情况如何（即使公司拥有行业最高的市场份额），都 100% 有改进的空间。 没有完美的企业，因此必须不断成长。

从长远发展来看，持续改进会产生复利效应。该术语最初来自金融学中的「复利」，意为利息长期呈指数级增长并产生被动收入。同样，如果团队和业务持续改进，他们的业务流程也将大幅改善，销售收入会成倍增加；其弊端在于大多数人由于短期看不到显著效果，会停止持续改进，但长期来看，持续改进所带来的效益是巨大的，因此需要坚持不懈和耐心。

Scrum 是最流行的敏捷框架，起源于丰田，也是持续改进的实践。在 Scrum 中，持续改进发生在「迭代回顾 Sprint Retrospective」中，Scrum 团队讨论他们在未来的工作中可以做得更好的地方。这是 Scrum 解决团队表现问题并成为应用最广泛的敏捷框架的最大原因之一。

6. 稳定性

搭建高绩效研发团队的最后一项原则是稳定性，即团队结构/成员和工作流程应保持稳定。不稳定会使团队混乱，影响工作效率和表现。

首先是团队结构和成员的稳定，这意味着他们不应频繁变动或调动。 比如，如果组织经常在不同团队之间调动开发人员，那么开发者被分配到新团队时就需要重新熟悉工作方式、代码库和文档，从而降低工作效率。

其次是工作流程流转的稳定性。如果工作流程不规范、不统一，团队成员就会对如何工作感到困惑，产出质量也会不一致。 丰田将标准化定义为业务最关键的实践之一，因为大野耐一强调工作应该顺畅地进行，没有阻碍和浪费。作为丰田生产方式（TPS）的成果，用于将工作流程和任务状态可视化的看板（Kanban）应运而生。

总结

在软件研发组织中，构建有效的团队结构对提高团队效率和工作表现至关重要。本文总结了构建高绩效研发团队的六项原则，它们分别是：

原则一： 系统设计应该比团队构建更早完成。

原则二： 充分考虑认知负荷并组建支持团队（使能团队、复杂子系统团队和平台团队），以协助核心团队（流对齐团队）工作。

原则三： 让团队保持在小而美的规模。团队规模越大，沟通也会变得更加复杂，进而降低工作效率。

原则四： 实践仆人式领导，围绕驱动力 3.0 帮助团队提高参与度和工作表现。

原则五： 无论如何都要坚持持续改进。哪怕在行业遥遥领先，也一定有进步空间。

原则六： 维护团队结构和工作流程的稳定性。这对于避免混乱和追赶成本，提高团队绩效非常重要。

（原文作者为 Eiki，内容经 LigaAI 翻译整理）

>> LigaAI 往期精彩阅读 <<

技术分享 | 弹窗开发中，如何使用 Hook 封装 el-dialog？

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

宁波银行：在「金融科技」引擎上，沉浸式提效减负

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

近 20 家科技、金融和制药公司实施了新的研发效能管理方法，并取得了令人鼓舞的初步结果。

大模型和 AIGC 技术催生了软件研发的新范式，也让研发管理的复杂度急剧攀升。尽管有研究称，Copilot X 和 ChatGPT 等生成式 AI 工具有望将开发者完成任务的速度提高两倍，但在引入合适的 AI 应用和工具之前，研发管理者们可能首先要回答，「如何判断 AI 工具确实为组织提效产生了助力？ 」

准「AI 时代」下，「AI + 研发效能」很可能成为企业构建核心竞争力的角逐高地。而如何科学、全面且准确地衡量开发者和研发团队的工作效率与生产力正是研发效能治理中的重要命题。

麦肯锡在最近的一次研究中，对现有的两组生产力指标模型进行拓展和补充，构建了端到端的开发者工作效率与生产力视图。报告称，该方法很容易通过调查问卷或沉淀在研发管理工具中的过程数据进行部署，无需引入大量的技术堆栈或工具设备。

麦肯锡：开发者工作效率与生产力视图

基于 DORA 指标和 SPACE 指标，麦肯锡拓展补充了 4 个以机会为中心的度量指标（Opportunity-focused metrics），并按照系统级、团队级和个人级对所有指标进行分类和归集，最终得到能够确定如何改进产品交付方式以及明确改进价值的开发者工作效率与生产力视图。

01 DORA 指标

DORA 指标由谷歌的 DevOps 研究与评估团队经多年的调研与分析总结提出，是技术领域最接近标准的量化管理框架，它们在衡量研发成果方面表现出色。

DORA 指标涉及吞吐量和稳定性两个方面，包含部署频率、变更前置时间、服务恢复时间和变更失败率四个关键指标。 当 DORA 指标返回的结果不理想时，就意味着需要调查问题的原因，而这通常需要花很长时间。

02 SPACE 指标

SPACE 指标由 GitHub 和 Microsoft Research 提出，用于增强 DORA 指标。SPACE 是满意度（Satisfaction）、绩效（Performance）、活动（Activity）、沟通（Communication）和效率（Efficiency）的缩写；其中每个维度都包含若干个适用于个人、团队或系统级别的不同指标。

• Satisfaction and well-being 满意度和幸福感
• Performance 绩效
• Activity 活动
• Communication and collaboration 沟通和协作
• Efficiency and flow 效率和流程

将个人视角（特别是开发者的幸福感）考虑在内，SPACE 指标能很好地说明组织是否得到优化。

03 机会导向指标

麦肯锡从多个视角对研发过程进行了细致入微的观察，并提出四个机会导向指标：研发内/外循环耗时、开发者速率指数、贡献分析和人才能力得分。

1. 研发内/外循环耗时：Inner/outer loop time spent

报告指出，为了确定需要改进的具体领域，完整的软件开发流程可以视为两个循环。研发内循环包括与创建产品直接相关的活动：编码、构建和单元测试；外循环则包括开发人员将代码推向生产所必须完成的其他任务：集成、集成测试、发布和部署。

于开发者而言，内循环是构建产品，直接产生价值的过程，而外循环虽然必要，但却充满了繁杂琐事。因此从生产力和个人体验的角度来看，企业应尽可能改进外循环的工具和自动化，以便让开发者能在内循环活动上投入更多时间。其中，顶级科技公司的目标是让开发者将多达 70% 的时间花在内循环活动上。

2. 开发者速率指数：Developer Velocity Index

开发者速率指数（Developer Velocity Index，DVI）研究是一项衡量企业技术、工作实践和组织支持程度的调查。

DVI 涉及 3 大方面、13 个能力领域的 46 项驱动因素，并由这 46 项影响因子加权平均而得，可与同行进行对标。 这种比较有助于发现特定的机会领域，如待办事项管理、测试或者安全性和合规性等方面。

3. 贡献分析：Contribution analysis

评估个人对团队待办事项的贡献（从 LigaAI 等研发管理工具中获取数据，并使用专有算法对数据进行标准化）有助于揭示阻碍团队能力优化的趋势，并使团队领导者对产出有清晰的预期，从而提高绩效表现。

此外，它还有助于管理者辨析个人技能提升或培训的机会，重新思考团队内的角色/任务分配。例如，质量保证测试人员是否有足够的工作可做。

4. 人才能力得分：Talent capability score

该得分是基于行业标准能力地图，对特定组织的个人知识、技能和能力的总结。理想情况下，组织应追求「钻石分布」，即大多数开发人员处于中等能力范围。这样有助于洞悉辅导和提高技能的机会，在极端情况下，可能需要重新思考人才战略。

# 写在最后

上周，OpenAI 公布了 GPTs、Assistants API 和 GPT-4 Turbo 模型等一系列关键技术和产品更新，让 AI 圈再次沸腾。

几乎可以预见的，基于大模型的 AIGC 技术和应用会逐步融入开发者和研发团队的日常工作，成为团队基因的一部分。面对来势汹汹的 AI 浪潮，研发管理者正迫切地需要建立科学的度量指标体系，以更直观地洞察开发者和研发团队的工作效率与生产力。或许，这样就能更清晰地回答：

• 影响程序员发挥出最佳水平的障碍是什么？
• 文化和组织在多大程度上影响了开发者创作伟大作品的能力？
• 如何知道程序员的时间和精力是否花在了真正推动价值的活动上？
• 如何知道组织是否拥有所需的所有开发人才？

>> LigaAI 往期精彩阅读 <<

生成式 AI 如何释放开发者的生产力？

新晋技术管理者如何推动组织变革？

向上管理：三个技巧，教会你如何与上级、老板高效协作

了解更多技术管理进阶、研发管理实践、程序员成长 等干货内容 ，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

生成式 AI 可以将程序员的开发速率提高两倍。技术管理者有望通过 AIGC 应用，大幅缩短四类关键开发任务的完成时间，进而提升组织生产力。

——麦肯锡《通过生成式 AI 释放开发者生产力》

01 生成式 AI 将如何影响研发效能？

麦肯锡最近的一项实证研究发现，生成式 AI 工具可以显著提升程序员的开发速率，进而显著提升组织生产力。

该研究对来自美国和亚洲各地的 40 余名开发者展开了观察和实验。参与者们需要执行三种常见的开发任务——代码生成、代码重构和文档编写，而开发者特征、任务的完成时间和复杂性，以及代码质量等数据被科学地记录下来。

研究结果表明，在生成式 AI 的辅助下，可维护性代码文档可以在一半的时间内完成，新代码生成效率提升近一倍，而代码重构类任务的完成时间也节省近三分之一。在新工具和流程的推动下，结合正确的技能提升和企业赋能，这些速度的提升可以转化为生产力的提高，并超越过去工程生产力的进步。

不过，任务完成时间的减少也可能会因开发任务的复杂性和开发者经验而有所差异。对于高复杂度任务，由于开发者缺乏必要的背景知识，其时间节省不足 10%。此外，在某些情况下，使用了 AIGC 工具的初级开发者（指经验不足一年的开发者）比不使用工具要多花 7%-10% 的时间。

研究还发现，当开发者和工具协作时，研发质量并不会因为速度提升而牺牲或降低。有 AI 辅助的代码在缺陷率、可维护性和可读性等方面的表现更佳。参与者们指出，开发者们正在迭代中积极地应用工具以实现更高的质量，是以该技术应该用于赋能开发者，而不是取代他们。

综合来看，想要使用生成式 AI 并最大限度地提高生产力和降低风险，技术管理者需要采取结构化方法，比如生成式 AI 的培训和辅导、用例选择、技能提升和风险控制。

02 生成式 AI 在四个方面卓有成效

1. 更快完成手动和重复的工作

生成式 AI 可以处理常规任务，例如自动填充标准函数、完成键入中编码语句、根据给定提示按一定标准格式书写代码功能文档等。在此过程中，AI 就能解放开发者，让他们能够解决更复杂的业务挑战，快速开发新功能。

2. 更高效地启动新代码的初稿

面对空白文件时，开发者可以在 AI 工具中获得编码建议。参与者反馈到，AI 辅助工具提供了有用的代码建议，这使他们摆脱了写作障碍，可以更快地开始创作。「这类工具使我能够更快地进入心流状态」，一位参与者如是说到。

3. 加速现有代码的更新

如果能提供有效的提示词，开发者使用生成式 AI 还可以更快地对现有代码展开更多更改。例如，为了减少从在线编码库调整代码和改进预写代码的时间，开发者可以将代码作为提示词，提交迭代查询，要求工具根据事先提供的标准进行调整。

4. 提高开发者应对新挑战的能力

虽然生成式 AI 对复杂任务的提升效果比较有限，但它可以帮助开发者快速温习完成工作所需的陌生代码库、语言或框架。在面临新挑战时，他们可以转向工具来获得如概念解释和框架使用指南等帮助，以更好地完成工作。

因此，使用 AIGC 工具执行复杂任务的开发者在规定时间内完成任务的可能性要比不使用工具的开发者高出 25%-30%。

除了生产力的提高，研究还发现，让开发者发挥出最大生产力可以显著改善开发者的体验，从而帮助公司留住并激发最优秀的人才。使用生成式 AI 工具的开发者，其总体幸福感、满足感和心流状态是其他人的两倍多。

03 依赖开发者专业知识的三个领域

生成式 AI 可以做很多事情，但其使用效果取决于使用它们的开发者的技能水平。从参与者的反馈来看，人类的监督和参与在以下三个领域至关重要：

1. 检查代码的漏洞和错误

生成式 AI 有时会提供不正确的编码建议，甚至会在代码中引入错误。一名开发者表示，她必须输入大量的提示来纠正工具的错误假设，然后才能得到答案。

2. 贡献必要的背景信息

虽然现成的 AIGC 应用拥有很多编码知识，但它们不知道项目和组织的具体需求。要确保最终的软件产品能与其他应用程序无缝集成，满足公司的性能和安全要求，并最终解决用户诉求，这些信息必不可少。

开发者需要通过提示词为 AI 提供背景信息，包括代码如何使用、由谁使用、接口类型以及软件将与之交互的其他系统，使用的数据等等。

3. 应对或分解棘手的编码要求

参与者还提到，生成式 AI 更适合回答简单的问题（如优化代码片段），而不是复杂的需求（如将多个框架与不同代码逻辑相结合）。

一位开发者分享到，为了获得可用的解决方案来满足多方面的需求，他首先必须手动地组合各个组件，或将代码分解为更小的片段。「当问题变得更加复杂并且需要考虑全局时，生成式 AI 提供的帮助最小。」

写在最后

ChatGPT 之后，不计其数的 AI 应用和辅助工具涌现，从代码生成、调试到审查、优化，我们都能发现许多令人兴奋的新面孔。也许在不久的将来，生成式 AI 会构建出新的规则，改变代码编写、审查和优化的方式，甚至成为开发者工作的必备工具。

麦肯锡认为，生成式 AI 应该成为开发者探索复杂任务的最强辅助，为其赋能，而不是取而代之。 这与 LigaAI 的观点不谋而合。

作为一款面向开发者的、以人工智能技术为核心的研发管理工具，LigaAI 自成立的第一天起就坚信，开发者最宝贵的时间和精力不该被机械重复的繁杂琐事绊住，形如信息同步、状态更新、任务流转等工作就该交给机器完成。只有这样，开发者才能专注地钻研技术、解决问题、交付价值，释放更多生产力。

相较于上一代工具，LigaAI 创新提出了「智能协作」概念，致力于以 AI 赋能每个用户，真正为研发团队提升效能。如果你正苦于滞后的、失真的进度数据、无法了解团队和项目的真实进展，或者疲于应对各种通知、提醒和干扰，欢迎注册使用我们的产品，体验新一代智能研发协作。

立即注册使用：新一代智能研发协作平台 LigaAI

关于变革的挑战总是复杂，而如何在不同的环境和问题中影响团队也是一项艰巨的任务。在实践中，我发现以更加实际的视角看待问题会有所帮助。

# 技术管理者的工具箱

尽管公司和技术团队各不相同，但大多数情况下，技术管理者有权决定团队如何开展工作，以及如何评估团队成员。这意味着他们拥有三个重要的变革工具：系统流程、行为和奖励。

技术管理者可以通过改进内部流程（System），提升团队的研发效能；通过自身的行为（Behavior），影响成员行动；使用奖励机制（Reward），激励成员做出正确行为。

它们在应对不同挑战时很有帮助。技术管理者了解自己能够撬动哪些杠杆，在行动时也会目标更明确，方向更清晰。那么，在软件开发领域，有关系统流程、行为和奖励层面的变革如何落地？

01 系统流程层面

系统和流程是最常见且讨论得最多的实践方法。每个团队都有很多正式的、非正式的工作流程。技术管理者可以对流程进行优化，以改善预期结果。

尽管我们都知道优化流程非常有效，但实践起来并不简单。我曾经失败过，也目睹过许多失败的流程改进计划。从中，我总结出四条系统优化原则：

• 从问题开始，而不是从解决方案开始

当你有一把锤子时，每个问题都会变成钉子。随着职业生涯的发展，技术管理者将不断地遇到问题、解决问题，同时习得许多行之有效的解决方案。因此，经验固然重要，但更重要的是先了解其他成员是否同意问题的存在。

• 就问题达成共识，并提出解决方案

作为团队领导者，技术管理者有义务帮助研发团队找到解决方案。理想情况是与团队协作共同寻找答案，但鉴于「管理者」在组织中天然具有权威性，你的考量和意见会变得格外重要。

一个有用的原则是，共识不是「每个人都同意」，而是「每个人都感受到自己的声音被倾听和认真对待」。技术管理者的职责是倾听所有观点，并提出一个能够周全考虑所有想法的解决方案。

• 全面地思考，有针对性地解决

尽管针对当前问题评估改进意见很重要，但在决定如何改进时，技术管理者应当考虑整个系统的影响。技术团队使用的大多数策略都取决于团队情况和其他重叠的系统，如果不了解相关背景就盲目遵循「最佳实践」，那么很可能导致不好的结果。

• 变革是痛苦的

「即便所有人都齐心协力，变革仍旧是痛苦的。」

团队流程与习惯一样，改变或塑造都需要反复不断地克服、适应和重新调整；尤其在变革早期，阵痛感会更加明显。我们经常看到一些伟大的变革因为实施时间不够长而失败，团队还没体会到变革带来的任何好处，就又回到了以前的工作方式。

02 行为层面

除了对团队流程/系统采取行动，技术管理者还可以利用团队最宝贵的资源——注意力——来塑造团队行为。领导者的行为会受到团队的观察和效仿，因而技术管理者可以利用这份关注，向团队传达正确的工作与协作方式。

这是一种微妙的、潜移默化的方式，它可以在许多场景下应用。例如，在团队会议上，技术管理者提出的问题会被视为重要问题；在项目中，其关注的领域也会受到更多的关注。

• 场景一：技术升级

如果团队需要优化某个技术领域（如测试或架构），技术管理者可以通过集中提问和讨论，为对话创造空间，推动团队朝期望的方向发展。

• 场景二：流程优化

当团队正在改进流程时，技术管理者可以通过关注流程并提醒团队所需的变化，帮助组织往正确的方向前进。与任何习惯养成的练习一样，定期提醒和小助力将有助于建立新的行为。

• 场景三：定期同步

在所有定期会议上，比如每日站会或迭代回顾会，技术管理者可以对需要关注的重点领域提出问题，引导团队的关注。例如，如果研发团队经常被提醒「质量 ＞ 速度」，那么最终这一原则也会在组织的行为和成果上有所体现。

03 奖励层面

通过提供奖励来影响团队可能是最明显直接的方式。毕竟，技术管理者要负责团队的成员招聘，有权决定岗位晋升以及项目的人员配置；还可以通过将成员安排在特定的职位，影响团队的工作方式。

提到「奖励」，大家通常会联想到大而明显的东西，比如新成员、职场晋升或物质奖励。但有一点经常被忽略：技术管理者可以通过小型反馈循环，为团队注入动力。

大部分人喜欢收到反馈，但却不那么愿意主动贡献反馈意见。我的一个独门秘笈是，在工作中积极地观察成员，并有意识地给予反馈。 举个例子，参加项目同步会议时，认真地做笔记并向大家提供反馈；阅读技术文档时，对内容和文档形式发表意见和看法；主动地表扬在团队聊天中提出问题的成员，给予正向反馈等。

其操作要点是，如何利用奖励并以独特且包容的方式激励团队，而不因个人偏袒产生人际问题。

作为技术管理者，你对团队成员观察得越多，对改进并获得成功的领域越重视，就越容易改变成员们的工作方式，进而改善团队的协作模式。

LigaAI 总结

同任何复杂系统一样，以上三种方法常常相互交叠、相互影响。技术管理者可以综合流程、行为和奖励，推进可能给团队带来重大影响的变革。

透过广阔、宏观的视角看待这些选择，将帮助你决定如何调整自身的管理者行为，提升团队影响力；进而，让组织变革变得更加容易。

>> LigaAI 往期精彩阅读 <<

向上管理：三个技巧，教会你如何与上级、老板高效协作

如何提高技术领导力？与你分享 5 个心得

产品路线图如何制定？斯坦福大学产品管理课程前来支招

「程序员转型技术管理」必修的 10 个能力提升方向

了解更多技术管理进阶、研发管理实践、程序员成长 等干货内容 ，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

在我的职业生涯中，从管理开发团队到管理外包服务商的自由项目，我一直是某种意义上的「技术主管」。但直到近两年，我才正式地成为一名技术负责人。身份和能力的转变带来了很多挑战，我也总结了很多成长心得。

本文将分享探索技术领导力必须了解的 5 件事。

01 领导力与控制无关

首先，技术领导力（以及任何一种的领导力）的核心不在于你对项目和团队的控制。 成为技术管理者不是为了当一个发号施令的人。

技术领导力需要为未来状态描绘愿景（比如项目的完成或者产品的发布），并帮助技术团队实现这一目标。 这不是对细节的微观管理或者让你亲力亲为，而是指导他人的实现过程，以便他们能达到你的效果。

作为技术专家（或个人贡献者），你对团队的贡献无法覆盖很大范围。即便你可以持续精进自己的能力和工作流程，但最终还是会因种种限制而无法快速提高技术领导力。而当累积了足够丰富的经验后，成为技术管理者或许能让你以帮助他人提高效率的方式，增强自己的影响力并提高产出。

02 不惜一切代价清除障碍

任何做过大量编程工作的人都知道，我们很容易会迷失在问题中，花费大量宝贵的时间进行调试。如果不给自己换换脑子、透透气，就容易陷入沮丧或士气低落，最终浪费更多时间。

受阻的开发者是项目中最大的风险之一，而作为技术管理者，你的职责就是向他们提供帮助。

首先，识别出开发者受阻或停滞不前的信号很重要。 他们是否提出了很多看上去互不关联或毫无推进的问题？他们有否表现出沮丧的迹象？他们的状态更新或代码提交消息是否含糊不清并且似乎没有进展？如果你发现有这些症状，那么你的成员很有可能已经陷入困境。

是时候该出手了！但请牢记，你是来清理障碍的，不是来解决问题的。 我的常用做法是提出一系列问题，引导成员突破困境。即使我很快能知道解决方案是什么，我也倾向于指导开发者以我诊断问题的逻辑为参考来解决问题。我希望不只要帮助他们解决当下的问题，还要能为未来吸取经验教训。

即便你不知道如何解决问题，引导式提问和与开发者讨论方案也能帮助他们摆脱并找到解决办法。不要害怕向开发人员提供其他资源，无论是代码片段、文档，还是其他有能力提供支持的成员。

03 传递信心

技术管理者的工作重心不仅是与开发团队合作，还要代表开发团队与项目经理和客户进行沟通。

我非常乐意承认，有好几次当我和别人交流时，我对所谈论的内容和主题并没有太多了解。作为技术管理者，我的工作是成为一名「全才」，不求上知天文，下晓地理，但起码也要略知一二。

而现实是，我们不可能对所有事情都有所涉猎，因此技术管理者必须善于提出正确的问题（或进行一些有效的信息检索），以便快速掌握相关知识，并立即就某个主题展开专业讨论。

你可能会担心「在不了解的领域说错话该怎么办？」别担心，因为很有可能 ，你在谈论项目时所散发的自信要比说话的内容重要得多。

你的团队被视为行业专家，而你的职责就是维护利益相关者对团队的信心，向他们保证你和团队能够掌控一切。有些时候，你可能完全不知道该说什么；此时，你必须训练自己的反应能力，不要惊慌。另外，我建议先与团队协商，晚点再给利益相关者答复。

04 管理好项目预算和时间表

刚开始担任技术管理者时，很多人可能会认为管理项目预算和项目时间表完全是项目经理的责任。项目经理当然需要为此负责，但对非技术人员来说，如果没有一个有开发经验的人提供意见，那他们也不知道如何有效地管理项目预算和时间。

开发者会在约束中成长。因此，当拿到一个大预算和一个大时间表时，他们往往会迷失在细节里，或忘记时间，或在最开始就过度设计，并在项目结束时耗尽时间和预算。

你可以通过将项目分解成小块，辅助解决这个问题。根据经验，技术管理者会查看需求，将项目拆分成若干个可行的小模块，并将它们按照功能或其他更容易分析的方式进行分组。

尽早分解项目有助于开发者了解你的预期，以及你希望他们在哪些方面投入精力。如果你的拆解结果和开发者认为的工作量不匹配，那么就需要进行讨论，以确保双方都了解项目的范围和实现方案。

05 不要成为英雄

每个人都想成为那个让项目顺利进行，或者把项目从困境中拯救出来的英雄；但这不是技术管理者存在的意义。

无论你有多少经验，你都不必（也可能不会）知道所有问题的答案。有时，即使知道答案，也不该为了让研发团队完成项目而直接说出来。

技术管理者最重要的工作，是成为一名推动者——帮助开发者完成他们的工作。对那些程序员出身的技术管理者来说，这是一个非常大的挑战，但这种转变会让他们受益匪浅。

你终将获得属于自己的荣耀与荣光；它源自亲眼见证团队走向成功。

# LigaAI 总结

不可否认，有的人出生自带管理天赋，但没有人天生就是合格的、好的管理者。培养技术领导力是一场漫长的征途，希望这五点经验能让你少走弯路

1. 领导力与控制无关，它源自你对团队的贡献。
2. 培养敏锐的障碍识别能力，并全力扫清障碍。
3. 你代表了专业，请向干系人和客户传递信心。
4. 管理好项目预算和项目时间表，这不只是项目经理的工作。
5. 切忌成为个人主义英雄，「成功团队的养成之路」才是你的主旋律。

（原文作者为 Jeremy Gimbel，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

产品路线图如何制定？斯坦福大学产品管理课程前来支招

「程序员转型技术管理」必修的 10 个能力提升方向

如何用 NPS 确定研发优先级，打破技术与业务的次元壁？

这 4 个系统可靠性评估指标，可能比 MTTR 更靠谱！

LigaAI：从效率、度量和价值维度，成为研发团队的智能医生

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

它们的工作，以及工作所涉及的组织，往往被设计成远离真正使用产品或者为产品付费的人。……其结果是，团队大量炮制出价值可疑的产品功能。这些功能可能不是利益相关者真正需要的。或者它们很好用，但并不能真正帮助用户提高工作效率。这可能是产品开发中最大的浪费：平庸的产品没有提供多少价值。

——《拯救僵尸 Scrum：卓越敏捷团队生存手册》

那么，面对复杂多变的环境，企业应当如何培养并平衡团队的客户视角与商业视角，让组织专注于有效的价值交付而非高效的产出，真正打造利益相关者需要的产品，避免陷入/及时摆脱「僵尸 Scrum」困境？

本文将分享一个能够有效弥合技术和业务部门的理解鸿沟，让研发交付围绕业务和价值展开的管理指标—— NPS。

01 什么是 NPS？

NPS（Net Promoter Score），净推荐值，由 Fred Reichheld 于 2003 年提出，用于评估客户自发推荐产品的意愿强弱/可能性大小，是应用最广泛的客户情绪与客户忠诚度的分析指标。从 AARRR 模型的角度看，NPS 会直接影响企业获客、留存和传播三个环节，因此成为影响业务增长的重要因素。

NPS 将「价值」编译为「客户推荐意愿」，可以为研发组织提供一个以「客户反馈」为中心的直观的定量工具。它能够快速拉齐产研与业务团队对价值和目标的理解，打破跨部门、跨组织协作的信息墙；同时，其清晰的评估结构又能辅助产品团队制定更明智的优先级管理决策，激励组织又快又好地构建价值增量，为业务服务。

02 如何计算 NPS 分数？

「你有多大程度会向朋友或同事推荐我们？」 是 NPS 调研中最基础，也最核心的问题。

受访者需要将自己的推荐意愿量化成 0 – 10 的评分，其中 0 分代表肯定不推荐，10 分代表肯定会推荐。根据打分情况，受访者将被分为三类：

• 9 – 10 分为「推荐者 Promoters」。 他们是企业的忠实用户，很可能是口碑营销的传播者；他们愿意继续为产品/服务付费，并将其安利给更多人。
• 7 – 8 分为「中立者 Passives」。 他们对产品/服务持中立态度，总体感到满意但并不狂热，可能会被其他竞品吸引走。
• 0 – 6 分为「贬损者 Detractors」。 他们对产品/服务不满意，甚至可能传播有关产品的负面评价，阻碍业务增长。

受访者中「推荐者占比」与「贬损者占比」的差值即为产品/服务的 NPS 分值。 举个例子，如果一次 NPS 调研收集了 100 个回答，其中有 50 个推荐者、30 个被动者和 20 个贬损者，那么 NPS 分数就是 50% – 20% = +30%。

NPS 的取值区间是 [ -100%, +100% ]：如果参与调研的受访者中，产品推荐者比贬损者更多，则净推荐值为正数，反之为负数。

「NPS 分值低说明产品不优秀吗？」

还真不一定。

03 NPS 分数达到多少才算好？

Retently 对从 To B 和 To C 领域共 14 个行业收集到的超 10,000 份调查样本进行了研究与分析，整理出 2023 年各行业的 NPS 基准值。

• To B 领域：咨询行业以 67 分夺得第一；B 端软件和 SaaS 行业的平均值为 41 分。
• To C 领域：保险行业以 74 分稳居首位，而互联网软件和服务行业则以 9 分排名最后。

由此可见，优化 NPS 的行业相对值或者变化绝对值或许比追求高分更具实践意义。此外，Retently 还表示，尽管 NPS 分数会受到行业领域和细分赛道的影响，但普遍来说 NPS

• 低于 0 分代表贬损者比推荐者更多，产品急需关注和解决；
• 0 – 30 分代表产品不错，但仍有进步空间；
• 30 – 70 分代表产品表现非常不错，客户满意度较高；
• 70 分以上代表产品口碑非常好，且大多数用户都是企业忠诚者。

04 如何使用 NPS 管理研发优先级？

虽然 NPS 在一定程度上可以反映产品是否存在问题，或客户当前是否对产品感到满意，但作为一个数值，它无法明确地指出问题出在哪里，以及客户为什么（不）满意。此外，除了行业和赛道等外因，NPS 还会受到产品本身、品牌价值观、营销手段、客户服务等不同内因的影响。也即是说，同一个产品的 NPS 值降低并不一定说明产品功能的表现变差了。

因此，我们需要获取更多信息（如受访者的打分动机等）进一步支撑可靠的产品管理分析和决策。常见的补充信息来源有三种。

1. 在问卷中追问开放性问题

在 NPS 调研问卷中追加开放式问题，了解客户打分动机或有关功能/产品的意见和建议是最常用的手段之一。为保证能获取到足够多的真实数据，NPS 调研一般采用只包含 「NPS 值评分 + 开放式反馈」 两道题的精简模式。

企业可以设置不同的触发条件，了解不同用户对产品优化和功能改进的具体建议。比如，向推荐者了解用户眼中的产品价值点，向中立者询问能增强其推荐意愿的进步空间，以及向贬损者请教其不满意的具体原因，捕捉产品短板等等。

2. 结合其他调研数据综合分析

NPS 数据分析还可以适当采纳客户满意度评分（CSAT） 、客户费力指数（CES） 、客户声音（VOC） 等其他调研数据，以便综合全面地掌握真实的客户反馈和客户情绪。

它们可以是关于全局的用户反馈数据，也可以是在特定使用场景下，根据上下文触发的满意度调研。其关键在于，不同调研的受访者属性应尽可能与 NPS 调研保持一致或相似，否则补充数据的可靠性可能会有所降低。

3. 开展定性访谈挖掘深度信息

如果样本量较少，那么主动联系受访者开展深度访谈也是个不错的主意。面对面交流更容易复现客户在产品使用过程中遇到的问题和阻碍，也有助于释放分值评价背后的真实的客户诉求。

拥有充足的 NPS 数据后，我们便可以根据目标推进数据分析和数据解读，而其中一个非常重要的步骤是对受访者进行细分管理。

受访者属性是一个非常宝藏的数据库，它可以帮助我们了解用户的角色身份、所处行业、使用产品的时长和习惯、对产品的主要功能诉求等重要信息。将 NPS 调研数据按照关键属性分组管理，并挖掘其与主观性数据间的正向强关联关系，产品团队将有机会快速识别出高价值的产品优化和改进建议，及时响应真正的客户需求。

接下来，产品团队将结合 NPS 调研结果和时间、资源等限制，提出可行且敏捷的产品策略，包括但不限于现有功能的优化和高价值需求的构建等。

最后，别忘了定期跟踪 NPS 的动态变化，持续关注优化效果，持续进步。

简而言之

使用 NPS 管理研发优先级需要研发团队设置精简且轻量的 NPS 问卷，结合其他可靠的客户反馈数据，在数据的有效细分和精细化管理中找到并构建利益相关者真正需要的功能和需求，让研发交付为价值、为业务服务。

>> LigaAI 往期精彩阅读 <<

这 4 个系统可靠性评估指标，可能比 MTTR 更靠谱！

LigaAI：从效率、度量和价值维度，成为研发团队的智能医生

高绩效团队的 5 个优秀习惯，看看你占了几个？

研发质量指标大 PK：MTTR vs MTBF，谁是靠谱王？

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

MTTR 代表一定周期内可修复系统不可用状态的平均持续时长，可以帮助企业更好地理解技术团队与研发工作，是评估系统可用性和可靠性的重要指标之一。但是，Verica 公开事件数据库（VOID）通过对近 600 个组织共享的超过 10,000 个事件进行研究与分析，发现对复杂的软件系统而言，MTTR 可能不是一个合适的管理指标。他们在 The 2022 VOID Report 中是这么说的：

我们认为 MTTR 对于复杂的软件系统来说并不是一个合适的指标，部分原因是系统无故障时间数据的分布以及系统故障不会（像物理组件或设备一样）随着时间的推移而规律出现。

01 MTTR 不适用于评估复杂系统的可靠性

MTTR 起源于制造业，用于衡量修复物理组件或故障设备的平均耗时。制造业的硬件或设备的磨损/故障周期相对规律，更易于管理且可预测性高，有利于使用 MTTR 展开适当标准化和统一评估。随着时间推移，MTTR 逐渐被引入并应用在软件系统管理方面，软件公司也将其视为系统可靠性和团队敏捷性/有效性的指标。

但是，Verica 研究团队怀疑，使用 MTTR 衡量软件网络故障和中断是不合适的，因为软件系统的「故障」不同于物理制造设备的故障，其每个故障本质上都是不同的。这也是为什么尽管在系统可靠性建设上大力投入，现代软件系统的运营商也仍会被意外和异常故障打得措手不及。

Verica 团队基于 Štěpán Davidovič 发布的 SRE 事件指标研究（Incident Metrics in SRE: Critically Evaluating MTTR and Friends），开展了两次实验以验证 MTTR 的有效性和可靠性。

实验结果表明，无论样本容量的大小如何，将事件持续时间减少 10% 并不会导致 MTTR 显著减少；持续时间数据的极端差异会对 MTTR 的计算结果产生显著影响。

02 是否存在 MTTR 的替代指标？

「哪些指标可以取代 MTTR？」

报告回答道，「研发团队不应该试图使用单一指标衡量或描述复杂的社会技术系统的可靠性。 无论计算出怎样的（不可靠的）MTTR，都需要深入调查事件，并了解系统真正发生了什么。」

Verica 团队称，定性事件分析是寻找替代指标的理想方式。基于事件分析，他们列出了 4 个可以代替 MTTR 衡量软件系统可靠性的指标。

1. SLOs 和客户反馈

SLO（Service Level Objectives，服务等级目标）是服务提供商为确保能为用户提供充分服务（并在需要时投资于可靠性以满足承诺）而做出的服务质量预期承诺。SLO 有助于结合技术系统指标与业务目标，使其成为更有用的可靠性框架。

需要注意的是，SLO 并不是 MTTR 的理想替代品。它具有和 MTTR 一样的缺点：

• 无法捕捉不影响 SLO 的未遂事件。
• 只考虑已发生的事件，不包括有关已知风险的信息。
• 随时间推移，导致 SLO 异常的事件发生的随机性很高，因此存在潜在的信噪比问题。

2. 社会技术事件数据

现代社会复杂系统的问题往往是社会技术性的，涉及代码、机器以及开发和维护的人。但是，研发团队总是倾向于只收集技术数据来评估系统表现。

Laura Maguire 博士对「协调成本 Costs of Coordination」的研究极大地丰富了社会技术数据的类型和来源。这些数据类型包括事件涉及的团队数、人数、工具、沟通渠道和并发事件等等。

在开始收集以上分析数据之前，技术团队无法真正地了解组织响应事件的实际方式。收集有关参与人员及其认知负荷的数据，以及所需的工具和技术资源，将有助于更全面地了解系统和团队的弹性。

3. 未遂事故

从未遂事件和实际影响客户/用户的事件中学习也是一种新兴方法。专注于「未遂事故」可以更深入地了解知识差距、思维错位和其他形式的组织和技术盲点。未遂事件相关的信息有助于推进组织变革，从而避免未来发生类似的、更严重的事件。

然而，发现未遂事故的原因绝非易事。下面是一些场景示例:

• 系统 X 已关闭，但用户没有注意到，因为系统 Y 在持续时间或中断期间提供缓存或通用内容。这是一个事件吗？
• 备份系统一个月前发生了故障，至今没有被技术团队或客户发现。这算事件吗？

4. 事后审查数据

评估组织内部事件分析有效性的另一种方法是跟踪事后审查信息的参与、共享和传播程度，例如阅读报告人数、自愿参加事件后审查会议的人数、与事后审查报告相关的代码注释和提交消息/架构图/其他相关事件的报告的数量等等。

03 LigaAI 总结

Verica 团队通过研究发现，MTTR 无法描述复杂软件系统的可靠性。他们解释道，这与系统无故障时间和故障出现时间的不确定性有关。

研发团队不应该试图使用单一指标来衡量或描述复杂的社会技术系统的可靠性，而是应该全面、深入地了解组织响应事件的真实处理手段和过程，并通过定性分析寻找合适的 MTTR 替代指标。

基于事件分析数据，VOID 报告提出四个可以替代 MTTR 的系统可靠性指标：SLOs 和客户反馈、社会技术事件数据、未遂事故和事后审查数据。

>> LigaAI 往期精彩阅读 <<

LigaAI：从效率、度量和价值维度，成为研发团队的智能医生

高绩效团队的 5 个优秀习惯，看看你占了几个？

研发质量指标大 PK：MTTR vs MTBF，谁是靠谱王？

9 个研发质量管理指标，一次理清！

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

事实上，卓越的团队并不一定在才能、技术或者机会上更有优势，好的工作习惯和工作方式才是他们脱颖而出的关键。 诚然，成员自主的工作文化、组织领导者的支持以及清晰的愿景和目标非常重要，但它们不足以造就优异的、高绩效的团队表现。

除了寻找合适的伙伴并为他们提供恰当的机会，打造一个高绩效团队还要注重培养正确的工作习惯，并要能将其运用在工作和生活中。下面是高绩效团队的 5 个优秀习惯，看看你能 Get 几个同款。

第一点：不做完美的决策，不犯可预见的错误

做出正确的决策是很难的。许多在当下看来正确的选择在未来可能被证明是错误的，而这些失败在事后看来往往又是显而易见的。

高绩效团队不做完美决策。他们与其他团队的不同之处在于，高绩效团队始终在用能消除认知偏见、降低项目风险的方式工作——运用事前分析法（Premortem）评估各种可能性、了解后果、预测失败并寻找规避失败的办法。

事前分析法由美国心理学家 Gary Klein 提出，是一种用于高效评估风险，主动识别潜在阻碍的决策思考方法。它的具体工作方式如下：

1. 将自己置于未来时刻并回顾过去；
2. 假设要做的项目/任务已经彻底失败；
3. 反推可能导致项目/任务失败的错误和原因；
4. 制定解决计划，通过消除已预见的风险和障碍，提高成功几率。

优秀的团队并不总能做出最佳选择，但是他们始终能避免明显的、糟糕的错误。

第二点：以团队利益为先，始终为他人提供支持

判断一个团队健康与否的依据之一，就是看成员们是否愿意公开表达不同意见，并（在立场不合时）能否为对方提供支持。

团队意见相左又无法达成共识时，如果采用「求同存异」的方式继续合作，就很容易产生消极心态。成员们可能无法客观地理解事情本身无关对错，也不分你我，反而会因为无法赞同其他观点而轻视决策，因心存芥蒂而无法向他人提供必要支持。

相比之下，「坚持不同观点但承诺支持」维护了团队团结，它可以成熟地区隔角色和观点，让成员们在各执己见的情况下仍为他人提供支持。它既不掩盖分歧的存在，也不否定不同观点的价值；它只指导成员了解该在何时放下争执，以团队效益为先与他人合作，而不是与之作对。

高绩效团队的成员不会让意见分歧恶化成「赢过对方」的个人执念。他们能够跳出个人立场，认真考虑其他人的看法；当最终决策与预期不符时，也能在坚持己见的基础上，承诺全力支持团队。

高绩效团队成员专注于履行合作承诺，为互相冲突的意见提供支持。他们通常会这么做：

1. 将自己与意见/立场剥离；
2. 分享自己的考量和意图；
3. 调查冲突产生的原因；
4. 评估和理解不同的观点；
5. 表明自己对观点的坚持，同时承诺无论结果如何都会支持最终决定。

第三点：以绝对坦诚的方式提供和获取反馈

得不到反馈的人都有一个共同点——他们将「提供正确反馈」的全部责任推到反馈者身上，让自己置身事外。他们怪别人含糊不清、不诚实或不愿意分享反馈，却忘了自己也承担着接收反馈的责任。

如果缺乏正确反馈，团队就无法知道自己做错了什么、哪些改变可以帮助他们提升和进步；而无法体验及时反馈的好处也反过来阻止了他们与别人分享有价值的信息。

高绩效团队会创造一个利于反馈的环境。他们不仅会不断地向他人汲取反馈和建议，也会毫不犹豫地贡献反馈。这是他们最常向自己和他人提出的两个问题：

• 我们如何更好地工作？
• 我们如何一起提高？

高绩效团队承担起给予和获取反馈的全部责任，以自驱的方式实现个人成长，而不指责别人没有提供足够的燃料。

第四点：能以高能动性应对未知与挑战

高能动性意味着成员会主动出击，自发探索实现目标的途径，而不是一味地等待「完美时机」或者抱怨环境不好。 他们能在逆境中挺身而出，也能想方设法地扭转逆境，实现目标——要么找到一条路，要么造出一条路。

高能动性是一种驾驭未知和挑战的能力，是在条件不完美时主动为成功开路而不空等的态度。它会指导我们牢牢掌握自己的生活、行为和决定的控制权，督促我们努力拓宽能力边界，积极探索未知领域并完成所有成功所需的任务。

高绩效团队拥有将逆境转化为机会的能力。 工作中的很多事情都可能出错，比如优先级冲突、期望不一致、沟通有偏差、任务完不成等等。在别人对此心生抱怨而中途放弃时，高绩效团队则坚持不懈地寻找解决方案，迎风向前；遭遇失败或犯错时，他们也会感到失望和沮丧，但绝不会让负面情绪成为前进的阻碍。

在《明智领袖的 15 个承诺》一书中，Jim Dethmer 称其为「承担根本责任」。他写道，「当我们责备他人时，就会把生活的控制权置于己身之外；当我们承担起责任时，就能在内心深处找回对生活的控制力。」

第五点：将「持续学习」列为首要任务

在工作中，我们需要不断更新技能、职责和工作方式。如果不跳出舒适圈，克服揭开未知的不适感，不学习如何解决复杂问题，也不培养应对不确定性的能力，就无法实现个人成长和职业发展。

高绩效团队深谙此道。他们不断挑战自我，寻找新机会，解决以前从未遇过的问题，并主动完成技能拓展相关的工作。 将长期学习列为首要任务不仅能帮助团队将障碍转变为机会，还能减少成员们的压力和焦虑。

就像运动员从不放弃训练一样，高效能的人永远不会停止主动调节和强化习惯。真正的成功——全面的、长期的成功——不是来自于自然的、明确的、方便的或自动的事情。通常情况下，当目标更大的挑战颠覆了我们对舒适和确定的定义，一趟伟大的旅程便开始了。——布伦登·伯查德

LigaAI 总结

高绩效团队会主动识别潜在问题、评估风险并找到克服的办法；他们通常使用「事前分析法」来完成这一目标。

高绩效团队成员愿意坦诚地分享自己的观点和看法，并承诺全力支持最终决定，哪怕会与他们的预期背道而驰。为了发挥出团队的最佳水平，他们会利用一切机会提供或获取反馈，并对自己的过程和结果负责。

此外，他们还会主动地、有意识地跨出舒适圈，拥抱新机遇，承担更多风险。他们也将学习放在首位，以更好地应对工作和生活中的挑战和要求。

（原文作者：Vinita）

>> LigaAI 往期精彩阅读 <<

研发质量指标大 PK：MTTR vs MTBF，谁是靠谱王？

9 个研发质量管理指标，一次理清！

3 个技巧，让你像技术专家一样解决编码问题

ChatGPT 之后，B 端产品设计会迎来颠覆式革命吗？

了解更多开发者提效、 研发管理、 研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

在研发质量管理中，「提高代码/测试质量」更重要，还是「提升故障响应能力」更重要？

LigaAI 最近和一些朋友探讨了这个问题。一种观点认为提升研发质量应该从代码质量抓起——擒贼先擒王，从源头减少故障发生才是根本之道；

另一种声音则指出，生产故障几乎不可能通过预防完全避免，因为「未知」是无法预测的，因此加强监测与反馈机制，快速识别、快速修复才是真正的有效之治。

从管理指标的角度来看，「提升代码质量」意味着研发团队要尽可能提高 MTBF（平均无故障时间），延长系统可持续运行时间，而「提升响应能力」要求尽可能减少 MTTR（平均恢复时间），将系统不可用时间降到最短以最小化故障影响。

温馨提示：研发团队应当先全面讨论系统「服务时间」「可用时间」和「不可用时间」的定义、事件覆盖范围以及故障等级，并在组织内部建立统一的理解，以确保资源和精力花在最重要的事件上。

尽管在实际工作中，「提高 MTBF」和「减少 MTTR」总是齐驱并进，但在不同发展阶段明确二者的优先级，将有助于研发团队高效专注、有的放矢地实现研发效能管理目标。

MTBF 和 MTTR 将如何影响研发效能？我们先从研发质量管理的三个维度说起。

01 研发质量管理的「RAM」

在管理实践中，我们常用「RAM」评估软件交付性能。这里的「RAM」当然不是 Random Access Memory，而是三个用于描述系统服务质量高低的关键维度——可靠性、可用性和可维护性。

1. 可靠性 Reliability

可靠性是指系统无故障运行的能力——哪怕出现软硬件故障、人为错误等问题，系统仍能正常提供正确服务而不发生服务中断的概率。

它与故障率、容错率、避错力、冗余度等紧密相关。常见的软件可靠性度量指标包括可靠度、失效率、MTBF 和 MTTF 等等。

2. 可用性 Availability

可用性是指在一定时间内，系统能够持续且正确提供符合期望水准的服务而不发生故障和中断的概率，通常用 SLA（Service Level Agreement，服务级别协议）来表示。

系统可用性（或称可用度）可以用系统可用时间占总服务时间的百分比计算得出，即

3. 可维护性 Maintainability

可维护性包含可修复性和可改进性两个方面。前者是指在系统发生故障后，不同人员高效修复故障，使之恢复正常运行状态的难易程度，而后者表示当需求或环境变化时，系统接受功能改进或增加新功能的可能性。

可靠性和可用性都可以展示系统的持续服务能力。区别在于，可用性更加关注系统服务的总体持续时间，而可靠性侧重于描述系统的抗故障能力。《分布式系统原理与范型》为区分可靠性和可用性提供了一个非常直观的例子：

如果系统在每小时崩溃 1 ms，那么它的可用性就超过 99.9999%，但是它还是高度不可靠。与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是高度可靠的，但是可用性只有 96%。

02 如何确定 MTBF 和 MTTR 的优先级？

对于不同组织或者同一组织的不同发展阶段，提升研发质量的有效手段很可能截然不同。那么，是否存在某种范式，可以帮助研发团队科学精准地确定 MTBF 和 MTTR 的管理优先级？

前面提到，可用性的计算公式可表示为系统可用时间占总服务时间的比重，即 MTBF / (MTBF + MTTR)。简单变形后，便可以获得以下关系式：

① MTBF = 可用性 * MTTR / (1 – 可用性)

② MTTR = MTBF / 可用性 – MTBF

对于已知的 MTBF 或 MTTR 值，研发团队可以结合系统可用性增长目标，计算出团队故障恢复能力或系统平均无故障时间的所处水平，并了解量化指标的预期增量。

举个例子。已知研发团队恢复一个故障的平均耗时为一个小时，如果系统每 9 小时出现一次故障，其可用性就为 90%。如果想将系统的可用性提高至 99%，那么故障频率应降低至每 99 小时（即 4.13 天）一次。

同样的，对于故障频率为每周一次的系统而言，如果研发团队能在 1.7 个小时（等价于 102 分钟）内让系统恢复正常工作，则其可用性便能达到 99%。

根据系统的故障频率以及研发团队的故障恢复水平，管理者可以将可用性提升目标翻译成 MTBF 或 MTTR 的优化目标，将抽象指标具象化，并综合目标实现难度、资源可用情况等明确首要优化对象，精准提升效能。

03 MTTR vs MTBF，谁更胜一筹？

Chad Fowler 认为，对大多数组织或系统而言，优化 MTTR 比增加 MTBF 更加有效。DORA 指标同样将 MTTR 视为影响研发效能和软件交付性能的四大关键指标之一。

一部分原因是软件系统不同于物理设备，其故障偶发性强，因而 MTBF 管理的不可控性较高。而恢复故障的工作流程清晰，操作步骤明确，可干预程度高；研发团队可以对各环节展开精细化管理，轻松、高效地达成 MTTR 优化目标。

研发团队可以使用敏捷开发方法、自动化监测和预警工具、自动化部署工具、灰度发布、A/B 测试等，缩短 MTTD、MTTA、MTTI、MTTR（Mean Time To Repair）等时间，以快速识别、定位和修复故障，快速上线。

不仅如此，Sidu Ponnappa 还指出，MTTR 是弥合业务与技术理解鸿沟的关键。它可以帮助企业更好地理解技术团队与研发工作，还可以帮助技术领导者识别系统的薄弱环节以及需要关注的对象，是衡量组织弹性、团队结构和整体健康状况的有力指标。想要改进 MTTR，研发团队必须构建正确的知识，改进质量控制实践，并重视内外部的沟通。

# LigaAI 总结

可靠性、可用性和可维护性是评估研发质量的三大维度，其中可用性可以用 MTBF / (MTBF + MTTR) 计算得出。

在研发管理实践中，优化 MTTR，提高故障响应能力更具指导意义。研发团队可以结合敏捷开发方法、自动化工具等，建立高度自动化的监测、反馈、测试、部署流程，实现高速提效。

>> LigaAI 往期精彩阅读 <<

9 个研发质量管理指标，一次理清！

3 个技巧，让你像技术专家一样解决编码问题

ChatGPT 之后，B 端产品设计会迎来颠覆式革命吗？

产品经理的 5 种错误打开方式，你中招了吗？

了解更多开发者提效、研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！