技术质量管理：如何系统提升代码质量与工程质量

当我能够帮助改进一份出发点良好、确实在解决真实需求的提案时，我会感到格外有成就感。

有时，提出方案的团队缺少足够的经验或背景知识，无法制定出真正抓住机会的计划。在这种情况下，一份结构清晰、重点明确的方案，往往既能大幅缩小项目范围，又能最大限度地保留价值，从而更快产生影响。

技术质量管理并不是一次性的代码治理项目，而是一项长期工程。它涉及质量热点、工程最佳实践、架构设计、技术方向、代码质量指标、技术质量团队和跨组织改进计划。

如果说工程师、工程经理和技术负责人之间存在某种共识，那大概就是：一场技术质量危机正在逼近。

一种常见、也看似合理的解释是：工程师没有把质量放在首位，所以公司需要招聘更优秀的工程师，或者重新培训现有工程师。

当然，如果你觉得把“工程师”替换成“产品经理”或“管理者”也同样成立，那也完全可以。

这种说法之所以吸引人，是因为它迅速找到了一个明确的责任人，同时又巧妙地把责任从工程领导层身上转移开了。

但和许多把问题归咎于组织中权力最小者的说法一样，这种解释既无益，也不准确。

一旦你接受“技术质量低下源于错误决策”这一前提，就很容易继续追问：究竟是谁作出了错误判断？

是前任技术负责人？是那个正略带紧张地看着你的工程师？还是所有人都错了？

但如果答案不是这些人呢？更进一步，如果这甚至也不是你的错呢？

在大多数情况下，技术质量不理想并不意味着组织陷入了危机，而是软件系统发展过程中的正常状态。

工程师在作出当时的技术决策时，通常已经基于现有信息作出了合理选择。与此同时，成功的公司也会随着规模扩大、业务转型，或进入更复杂的企业市场，不断提高自身对技术质量的要求。

因此，在一家管理良好、发展顺利的公司里，过去大量合理的技术决策，迟早都会低于今天的质量标准。

这并不一定代表过去失败了。

更准确地说，持续缩小“当前技术质量”与“目标技术质量”之间的差距，本来就是高效工程领导力中一项长期、常规且至关重要的工作。

技术质量管理要解决什么问题

作为工程领导团队，你们的目标是在维持适当技术质量的同时，把尽可能多的精力投入核心业务。

这意味着，你们必须在多个时间尺度上平衡质量投入，而这些不同时间尺度的需求常常彼此冲突。

例如，下面两项工作同样重要，但性质完全不同：

• 确保下周的关键合作项目按时交付；
• 构建一个能够让下季度产品发布速度提升十倍的平台。

正如公司的技术质量标准会随着时间变化，技术质量管理方式也会不断演进。

常见的方法包括：

• 修复当前造成严重问题的质量热点；
• 推广已被证明有效的工程最佳实践；
• 优先投资于能够持续保持质量的关键杠杆点；
• 调整组织整体的软件技术方向；
• 衡量代码质量和技术质量，为更深入的投资提供依据；
• 组建技术质量团队，建设质量相关系统和工具；
• 运行质量改进计划，持续衡量、跟踪并建立责任机制。

在深入讨论这些方法之前，需要牢记一个原则：

优先选择成本最低、最直接、最有可能奏效的方法。

提升技术质量是一个长期过程。

它几乎不存在所谓的“最终胜利”。你能做的，是不断学习、证明当前方法有效，并为自己赢得继续投入和改进的机会。

从轻量级技术质量改进开始

深入研究眼前的问题，直到发现一个值得系统解决的共性问题，这种过程有一种独特的吸引力。

但另一种同样重要的本能是：尽快解决当前问题，然后继续处理下一个最紧迫的问题。

在思考如何为团队和组织改善技术质量时，最有效的方法通常是从最轻量级的方案入手。

只有当这些早期方案在规模压力下失效时，才逐步升级为更复杂、更系统的解决方案。

如果团队连正确的代码检查方式都无法采用，那么试图直接推动一项全面质量改进计划，几乎注定会失败。

后者也许更适合大规模组织，但实施难度也高得多。

所以，先把最容易、最直接的问题解决掉。

即使最初的方法失败了，从一个简单尝试中吸取教训，也比从一个复杂、庞大的失败项目中学习更快。

更重要的是，轻量级方案可以更快迭代，你也能更快推出改进后的版本。

随着时间推移，你确实可能需要采用更全面的方法，但没有必要过早进入重流程。

不要为了追求企业级协调，过早放弃小型组织原本拥有的灵活、简单和高效，尤其是在还没有证明复杂流程确有必要的情况下。

把这些方法描述成一个线性阶梯很方便，但现实中的组织很少会严格按顺序前进。

更常见的情况是：

你先修复几个质量热点，然后推广某项最佳实践；接着开始架构评审，后来又发现架构评审效果不好，于是暂停流程，再重新回到直接解决问题的阶段。

过早引入流程，往往弊大于利，而且通常很快就会暴露出自身的低效。

如果某种方法不起作用，先给它足够时间验证；如果仍然无效，就坦然接受失败，并及时调整。

第一阶段：优先解决技术质量热点

面对技术质量问题时，人们的第一反应往往是寻找流程缺陷，并认为必须通过新流程来解决。

例如，一次部署导致服务中断，于是团队得出结论：

“作者没有遵守正确的测试流程，所以以后每次代码提交都必须包含测试。这样那些不够负责的开发者就会吸取教训。”

有一个关于合规制度的老笑话：

它不能真正降低风险，但至少能在出问题时明确应该责怪谁。

遗憾的是，这种讽刺同样适用于很多组织设计流程的方式。

责任机制当然重要，但更重要的是理解问题真正来自哪里，并尽量直接解决根因，而不是先建立一套以追责为中心的流程。

推动流程意味着要求大量成员改变工作方式，这绝不是一件轻松的事。

因此，与其首先设计流程，不如先采用性能工程师的思维方式：

1. 衡量当前问题；
2. 找出问题最严重的部分；
3. 集中资源解决这个部分。

回到前面的部署事故案例，也许最有效的方法只是直接向相关工程师反馈，帮助他们改进测试习惯。

但也可能存在另一种更好的答案：承认软件设计本身很容易诱发错误，然后从设计层面消除错误发生的可能性。

如果团队遇到开发速度下降，也不一定需要全面改造流程。

问题可能只需要通过以下方式解决：

• 优化测试运行时间；
• 加速构建流程；
• 调整容器构建步骤；
• 找出频繁变化、耦合度过高的关键文件；
• 删除长期制造噪声和失败的低价值测试。

系统思考是我职业生涯中接触过最有改变力量的思维方式之一。

但有时，它也像一种诱惑，让你试图修复一个本来应该被舍弃的系统。

当然，你可以启动新的培训计划，教团队编写更好的测试。

但也许更有效的方式，是直接删除那个造成绝大多数测试失败、却几乎没有实际价值的测试文件。

这就是优先解决热点问题的价值，也是为什么它应该成为提升技术质量时的首选方法。

当组织制造新质量问题的速度，开始超过你修复热点问题的速度时，就说明仅靠局部优化已经不够，接下来需要考虑推广最佳实践。

第二阶段：推广提升代码质量的工程最佳实践

我曾在一家海外公司工作，那里的团队没有统一的规划流程。

随着时间推移，工程负责人越来越无法忍受项目日期不可预测，于是强制要求所有团队采用 Scrum。

管理者把 Scrum 流程写进了 Wiki，公司发布了正式通知，各团队经理也被要求推动执行。

看起来，任务完成了。

但事实上，没有人真正开始使用 Scrum。

大家仍然按照原来的方式工作。

由于承认失败过于尴尬，工程负责人后来甚至把“推行 Scrum”描述成一次重大成功，而其他人也没有指出事实并非如此。

这个令人遗憾的故事，反映了许多公司在推广最佳实践时都会遇到的问题。

它也是“最佳实践”这个词常常令人反感的原因之一。

理论上，组织应该在出现质量问题之前，就提前采用优秀实践。

但在现实中，我更建议先解决几个具体问题，再逐步推广最佳实践。

因为最佳实践能否成功落地，取决于组织和领导层是否具备足够成熟度，而这种成熟度通常需要时间培养。

在推动一项新实践时，需要记住：

好的流程是逐步演化出来的，而不是一次性设计完成的。

一个更可靠的推广方式是：

1. 研究其他组织如何采用类似实践；
2. 记录你计划采取的方法；
3. 在少数自愿参与的团队中试点；
4. 根据反馈持续改进；
5. 补充文档和工具；
6. 再逐步扩大使用范围。

仓促推出的流程，往往注定失败。

同样重要的是，不要同时推动太多新实践。

如果你要求团队同时采用多个新流程，这些流程实际上会彼此争夺成员的注意力。

而且，后续如果你想撤销或调整其中某项做法，也很难判断具体是哪项实践产生了效果。

这听起来也许有些严格，但我逐渐形成了一个观点：

任何时候，组织都应该只重点推广一项新的最佳实践。

与其把资源分散到多个项目，不如集中力量确保一项实践真正成功。

每次只推广一种做法，还会迫使你认真判断：究竟哪一个问题最值得优先解决？

这比听起来要困难得多。

许多所谓的“最佳实践”，只是知名度高、被频繁提及，并不一定真正有可靠证据支持。

真正值得推广的工程实践，应该尽量建立在研究和数据基础上。

在各类行业研究中，以下实践通常尤其值得优先采用：

• 版本控制；
• 主干开发；
• 持续集成与持续交付；
• 生产环境可观测性；
• 由开发者共同承担所编写系统的运行责任；
• 小规模、原子化的软件变更。

当然，还有很多其他实践也值得提倡，例如更完善的内部文档。

但随着经验增长，我越来越不愿仅凭直觉判断哪项实践最值得推广。

从“解决热点问题”过渡到“推广最佳实践”，通常是因为组织的问题已经太多，无法依靠逐个修复解决。

而从“推广最佳实践”转向下一阶段，则往往发生在这种情况下：

你已经在推动一项实践，它尚未真正落地，却又不断发现新的实践也必须采用。

此时，与其继续提高组织同时承载新流程的数量，不如换一种方法，开始寻找技术质量的关键杠杆点。

第三阶段：投资技术质量关键杠杆点

在处理质量热点时，我们采用的是性能工程师的思路：只优化已经被证明存在的问题。

这种方式非常有效，因为性能工程中最大的错误之一，就是把大量精力浪费在尚未发生、也未被证明存在的问题上。

但随着软件系统持续演进，你会逐渐发现，少数关键位置值得提前投入。

因为在这些位置上，一次高质量投资，可以长期维持系统质量，既能避免重大缺陷，也能降低未来维护成本。

我把这些位置称为“质量杠杆点”。

其中影响最大的三个杠杆点是：

• 接口；
• 有状态系统；
• 数据模型。

接口质量

接口是不同系统之间的契约。

优秀的接口能够让客户端与底层实现解耦。

长期稳定的接口应该暴露真正必要的复杂性，同时隐藏实现过程中偶然产生的复杂性。

真正优秀的接口，不只是能够工作，还应该清晰、敏锐，并准确表达系统能力。

有状态系统质量

状态通常是系统中最难改变的部分。

正因为状态具有很强的变更阻力，有状态系统自然成为另一个重要杠杆点。

这类系统比无状态系统更容易积累复杂性，也具有更强的惯性，因此后期改造成本往往非常高。

随着业务逐渐承担更多安全、隐私和合规责任，改变有状态系统会变得更加困难。

数据模型质量

数据模型位于接口与状态的交叉点。

它决定了应用程序认为哪些状态是合法的，也限制了有状态系统能够表达的能力。

优秀的数据模型应该足够严格：

• 只暴露真正支持的能力；
• 防止无效状态出现；
• 允许系统随着时间逐步演进；
• 尽量减少依赖特殊技巧和隐性约束。

当你在工作中识别出这些关键杠杆点时，应该投入更多时间认真设计和验证。

如果是接口，可以让多个真实客户端针对模拟实现进行集成测试。

如果是数据模型，可以模拟多个真实业务场景，验证模型能否覆盖长期演进需求。

如果是有状态系统，则应该重点测试故障模式、一致性行为，并建立接近生产环境的性能基准。

把这些探索结果整理成技术设计文档，与团队分享，并主动收集同行反馈。

即使进入实施阶段，也要持续观察真实情况，并保持接受变化的开放态度。

投资杠杆点的一个重要优势在于：你不需要提前获得整个组织的全面支持。

推动技术愿景或组织级最佳实践，通常需要大范围共识。

但针对某个关键接口、数据模型或状态系统进行高质量设计，往往可以在较小范围内启动。

因此，我通常建议先从杠杆点开始。

只有当局部杠杆点已经被充分利用，仍不足以解决问题时，才需要进一步推动整个组织的技术方向统一。

第四阶段：统一技术方向与工程战略

高效的组织会把大部分精力投入到共同愿景上。

可以把每个技术决策想象成网格中的一个向量。

如果这些向量大多朝着同一个方向，组织长期积累的成果就会非常可观。

反之，即使某位工程师能力极强，能够推动很大的技术变化，但如果方向错误，最终造成的伤害也可能非常大。

我曾见过一些极其优秀的工程师，他们推动的技术向量规模很大，却与组织真正需要的方向相反。

结果是，他们试图领导组织，却反而削弱了组织。

一种确保技术方向一致的简单方式，是把所有重要决策都交给某位“架构师”。

这种方法在小规模环境中可能有效，但很难扩展。

而且，当架构师逐渐远离实际代码和真实开发流程时，决策质量往往也会下降。

另一种极端方式，是让每个团队完全独立决策。

这会带来另一类问题：当每个团队都可以自由选择工具和方案时，组织几乎不可能提供高质量的统一支持。

用于统一技术方向的基本工具包括以下几种。

直接提供反馈

人们发现技术方向不一致时，第一反应往往是设计新流程。

但更好的起点通常是直接向相关人员反馈。

对方不了解你的背景，你也未必理解对方的限制。

一次简短、坦诚的交流，可能避免未来数年的复杂流程。

完善工程战略

工程战略通常可以分为几个层次：

• 技术规范；
• 技术战略；
• 长期技术愿景。

单个技术规范解决局部问题，战略帮助多个决策保持一致，愿景则为整个组织提供长期方向。

把方法嵌入工具和工作流

清晰的愿景当然重要，但总会有人不认真阅读文档。

与培训和文档相比，精心设计的工具往往更容易帮助组织形成正确习惯。

例如，部署新服务时，系统可以要求提交者附上技术设计文档。

又或者，如果某项服务尚未建立值班机制、监控和告警，就不允许进入生产环境。

把正确做法嵌入工具，通常比反复提醒人们遵守规则更有效。

在新成员入职时进行引导

改变已经形成习惯的人非常困难。

如果你试图让他们改变长期使用的工作方式，双方都会感到挫败。

但如果从成员加入团队之初，就向他们明确介绍组织的工程原则和实践，他们更容易自然形成正确习惯。

运用康威定律

康威定律指出，组织设计出的系统，往往会反映其沟通结构。

不合理的组织结构会导致软件过度耦合、边界混乱。

反过来，合理的团队结构也可以促进系统质量。

使用架构评审和技术投资机制

架构评审、技术投资策略和结构化工具引入流程，也可以引导技术方向。

大多数方向偏差并不是因为工程师能力不足，而是因为他们缺少足够背景。

这些机制的价值，在于把组织背景注入技术决策过程。

不过，我建议把这类工具放到较后阶段使用。

如果组织没有清晰愿景，架构评审又该依据什么标准进行？

如果技术策略只在设计完成后才告诉工程师，为什么不在入职和项目早期就提前沟通？

无论采用哪种方法，统一技术方向往往都需要数月甚至数年。

你不可能写完一份愿景文档，整个组织就立即认同并执行。

更常见的情况是：如果你没有持续投入时间争取支持，这份文档会一直被搁置。

多数公司可以结合热点修复、最佳实践和技术方向统一，建立一套有效的技术质量管理方法。

但有些公司会发现，这些方法仍然不足。

此时，下一步应该是衡量。

第五阶段：如何衡量代码质量与技术质量

软件工程对指标的需求，通常远远超过我们真正具备的衡量能力。

一些成熟指标能够衡量交付速度，帮助定位流程和工具问题。

但这些指标大多从代码合并之后才开始发挥作用。

那么，如何衡量代码库本身的质量，以便发现差距、提出改进方案，并评估改进是否有效？

有些流程指标与代码质量存在一定相关性。

例如：

• 每个 Pull Request 修改的文件数量；
• 单个文件的代码行数；
• 变更规模；
• 测试失败率；
• 构建时间。

通常来说，较小的 Pull Request 更容易保持质量，超大文件也更难维护。

这些指标都值得测量。

但它们最多只能作为代码质量的代理指标，而不能直接代表质量本身。

我的经验是，代码质量可以被衡量，关键在于对“质量”进行足够精确的定义。

定义越具体，衡量越有效，也越能指导希望改善代码质量的工程师采取行动。

可以纳入质量定义的指标包括：

• 静态类型覆盖比例；
• 关联测试的文件比例；
• 整体测试覆盖率；
• 模块公共接口的宽度；
• 使用组织推荐 HTTP 库的文件比例；
• 服务冷启动后是否能在目标时间内响应；
• 是否存在危险的读写顺序；
• 是否存在对主数据库的不必要读取；
• 端点是否能在单个事务中完成状态变更；
• 是否存在低粒度锁；
• 是否有少量热点文件出现在大多数 Pull Request 中。

你完全可以不同意其中某些指标。

因为技术质量定义，本来就应该根据具体代码库、业务目标和风险状况制定。

最重要的不是使用哪一套统一标准，而是定义必须足够精确、可衡量。

在制定过程中，团队难免会发生分歧。

随着系统变化，质量定义也一定会持续调整。

完成定义后，真正困难的部分才刚刚开始：建立并维护指标体系。

这通常是落地技术质量衡量时最大的障碍。

但如果能够克服，你会获得一个非常重要的能力：

一个真实、持续更新的质量评分，可以长期追踪，并用来推动方法一致性。

这种基于数据的一致性，远比口头上的概念一致更有力量。

在实践中，团队也可以借助 PingCode 这类覆盖研发全生命周期的管理平台，将质量目标、需求、技术债务、缺陷、测试和版本发布关联起来，并接入代码托管、持续集成等研发工具。这样不仅能够减少数据分散，还能通过统一的研发数据持续观察质量问题的分布、改进进度和交付结果，同时将架构规范、复盘结论和质量标准沉淀到 Wiki 中。

当质量标准和指标明确后，下一步就是决定：

应该组建专门的技术质量团队，还是启动一个跨组织的质量改进计划？

通常来说，专门团队更容易协调，工作量也更可预测，因此更适合作为起点。

第六阶段：技术质量团队做什么

技术质量团队，是专门负责提升代码库和工程系统质量的软件工程团队。

它也可能被称为：

• 开发者效率团队；
• 开发者工具团队；
• 工程生产力团队；
• 产品基础设施团队。

无论名称是什么，它的核心目标都是提升整个公司的软件质量，并帮助系统长期稳定运行。

这并不是传统意义上的质量保证团队。

虽然两类团队都可能投资测试，但技术质量团队的职责范围更广，通常涵盖：

• 开发工作流；
• 构建系统；
• 测试基础设施；
• 持续集成与交付；
• 开发者工具；
• 接口和平台设计；
• 可观测性与运行体验。

组建这类团队时，最好从三到六人的固定团队开始。

小团队规模会迫使你持续对路线图进行优先级排序，确保始终关注高影响、可实现的目标。

随着时间推移，团队会积累越来越多需要维护的系统。

构建集群、测试平台和内部工具，都可能逐渐增加持续维护成本。

因此，团队规模需要根据整个工程组织的发展情况进行调整。

很难给出完全通用的比例，但可以把“每十几位产品工程师配置一位开发者工具或工程生产力工程师”，作为一种粗略参考。

这类团队通常不会配置专职产品经理。

更常见的模式是由一名或多名高级工程师与工程经理共同承担产品管理职责。

有时，团队会引入技术项目经理，但这通常发生在团队开始运行跨组织质量计划之后。

运营技术质量团队时，有几个基本成功要素。

相信指标，而不是只相信直觉

每个项目都应该有明确的衡量方法。

质量是复杂系统，直觉很容易误导人。

随着你在公司中的职位提升，你的个人体验也会越来越不代表普通工程师。

你已经知道系统有哪些缺陷，也知道遇到问题时应该找谁。

但大多数工程师并不具备这些背景。

指标可以帮助你保持客观。

保持对真实开发体验的敏感度

代码和流程会持续变化。

你离产品开发越远，对真实问题的判断就越容易失真。

融入产品团队、定期轮岗，是保持敏感度的有效方式。

你也可以：

• 持续观察工程师的真实问题；
• 定期与产品工程师交流；
• 关注支持渠道和反馈记录；
• 定期查看质量指标和使用数据。

最优秀的技术质量团队，通常会同时做这些事情。

倾听用户，而不是替用户做决定

人们常常把“产品品味”描述成一种天赋。

但真正能够做出高质量开发者工具的人，通常不是因为天生知道什么最好，而是因为他们持续理解用户真正想完成什么。

用户目标应该高于实现上的便利。

易用性比功能强大更重要

功能强大但难以使用的工具，也许能吸引少数高级用户，但大多数人最终会放弃。

因此，要放慢速度，把使用细节做好。

隐藏不必要的复杂性。

观察工程师第一次使用工具时的表现，不要立刻提供帮助。

找出他们卡住的地方，然后改进。

重复多次。

如果不做真实的用户研究，内部工具项目极易失败。

少做事，但把重要事情做好

当你为整个工程组织构建系统时，任何一项优秀工作都会放大整个团队的生产力。

反过来，任何一项做得不够好的工作，也会拖慢所有人。

因此，少数高质量项目，通常比大量平庸项目更有价值。

当工具和流程面向整个组织推广时，这一点尤其重要。

不要垄断技术影响力

集中式质量团队与产品团队之间，天然存在一定张力。

集中团队倾向于追求全局最优，但这种统一方案可能严重伤害那些处于非典型场景的团队。

例如，一家公司为了统一技术栈，不允许机器学习团队使用更适合其工作的生态。

又或者，组织要求所有 API 都采用同一种形式，但某个特定场景其实更适合其他通信方式。

这类问题没有完美答案。

重要的是建立一种审慎的方法，在探索自由与标准化收益之间取得平衡。

一个运作良好的技术质量团队，其整体影响通常会高于同样数量工程师直接参与产品开发。

理论上，可以通过“未来开发效率提升的折现价值”来衡量这类团队。

但实践中，这种计算高度依赖假设，很难准确完成。

即使团队非常成功，也会不断积累高影响、但暂时没有资源完成的工作。

组织资源配置并不总是完全理性。

你可能既没有足够人手完成关键项目，也无法获批扩编。

当团队有大量高价值工作却无法承担时，未必意味着必须扩大团队。

这首先可能说明，你需要更严格地选择项目。

但如果确实存在一批关键质量工作，无法依靠现有团队完成，那么接下来可以考虑启动跨组织的质量改进计划。

第七阶段：如何运行技术质量改进计划

这里所说的“质量改进计划”，不是一段程序代码，而是一项由专门团队领导、面向整个组织的技术质量改进举措。

它的目标，是帮助组织达到明确的软件质量标准。

这类计划并不常见，但很多组织都运行过类似机制，例如：

• 生产事故治理；
• 安全整改；
• 技术栈迁移；
• 合规整改；
• 稳定性专项。

运行质量计划时，首先需要找到一位能够共同领导项目的技术项目经理。

他们负责项目的日常运作和跨团队协调。

没有技术项目经理，你依然可能在初期取得进展，但这往往是一个陷阱。

在大型组织中，单独领导跨团队计划，很容易被大量协调工作压垮。

一个有效的质量计划，通常包括以下核心方法。

找到有影响力的项目发起人

没有一位具备足够组织权力的发起人，很难真正改变组织行为。

组织目前之所以采用某种方式，通常是因为在现有约束下，这已经是局部最优解。

如果没有高层支持，就很难改变这些约束。

建立可持续、可自动生成的指标

有些项目负责人每周花费数小时手动维护数据。

这种方式无法长期持续。

手动数据容易缺失，也无法与自动化流程集成，最终还会消耗负责人本应用于真正改进工作的精力。

更新仪表盘本身没有价值，只有指标推动行动时才有价值。

为每个受影响团队定义明确目标

项目必须为每个参与团队设定具体目标。

例如：

• 降低测试不稳定性；
• 缩短事故修复时间；
• 减少高风险依赖；
• 完成某项平台迁移。

但仅仅给出目标还不够。

你必须同时提供一条清晰的实现路径。

许多项目要求团队参与，却没有告诉他们应该怎样完成。

项目负责人既然是相关领域专家，就不应把策略问题推给每个团队，让大家分别重新发明解决方案。

提供工具、文档和示例

当成功路径明确后，就应该思考如何降低团队改变的成本。

你可以提供：

• 黄金示例；
• 示例 Pull Request；
• 自动化迁移脚本；
• 验证工具；
• 检查清单；
• 参考架构；
• 自动生成的代码修改。

尽量避免让每个团队都必须深入理解整个问题领域，才能完成改进。

建立质量目标仪表盘

在明确项目目标后，提供一个仪表盘，让团队看到：

• 当前状态；
• 目标状态；
• 已完成进度；
• 下一步应该做什么。

理想的仪表盘既是记分卡，也是一份行动指南。

仪表盘通常需要支持三种视图：

1. 全局视图，用于评估整个项目影响；
2. 团队视图，用于帮助单个团队了解剩余工作；
3. 管理视图，用于帮助组织领导者跟踪其负责团队的进展。

自动提醒进度落后的团队

所有团队都很忙，你的项目目标未必总是他们的最高优先级。

有些团队可能曾完成改进，但后来又因为旧习惯而退步。

程序化提醒可以帮助重新引导注意力。

但要谨慎使用。

注意力是稀缺资源。

如果提醒过多、质量过低，团队会很快忽略后续通知。

定期与项目发起人复盘进展

质量计划推动的是组织级优先事项，而团队日常目标往往更偏局部。

许多团队很难主动牺牲局部目标，去完成全局优先事项。

因此，需要定期与项目发起人审查整体进展，并重点关注那些落后的团队和组织单元。

合理使用发起人的影响力，是弥合优先级差异的关键。

从很多方面看，跨组织质量计划就像一场永无止境的迁移。

因此，适用于大型迁移的管理方法，通常也适用于质量计划。

如果上述步骤都做得好，你就能运行一个真正有效的组织级计划。

但这确实需要大量投入。

很多计划都会失败。

最常见的失败原因包括：

• 只关注流程，而忽略真正目标；
• 只关注技术，认为可以跳过沟通、宣传和用户反馈；
• 试图由一个人同时承担技术与组织两种角色。

不要孤军奋战。

糟糕的质量计划，很像低效组织：

目标正确，但大量资源都消耗在计划本身，而不是实际结果上。

无论用什么方式衡量技术质量，都必须牢记：

质量计划不是目标，创造技术质量才是目标。

大型组织计划具有巨大惯性。

即使已经失去价值，也可能在停止推动后继续运行很长时间。

因此，要尽量保持计划轻量，使其可以在必要时被终止。

同时，也要保持足够的自我批判能力。

一旦计划不再真正改善质量，就应该果断停止。

结论：如何持续提升技术质量

当你意识到实际技术水平与目标技术水平之间存在巨大差距时，最自然的反应是惊慌，并立即同时尝试各种方法。

但如果把所有工具和流程一次性引入，结果通常不会理想。

更糟糕的是，你甚至无法判断究竟哪些方法真正有效。

如果你发现组织正受到技术质量问题困扰——而几乎所有组织都会遇到这种情况——请从小处开始。

选择一个质量热点，尝试一种方法，持续迭代，直到它真正奏效。

然后再引入下一种方法，再继续调整。

慢慢建立一套真正有效的技术质量管理体系，即使这意味着你会被批评“进展不够快”。

面对复杂系统和相互依赖的组织关系时，所谓快速行动往往只是表面上的速度。

真正能持续提升代码质量和工程质量的，通常是循序渐进、持续验证和稳定推进。