软件工程如何兼顾速度与质量

在软件工程中，交付速度和工程质量常常被放在一起讨论。有些工程师认为非常重要的工作，例如升级依赖、治理技术债务、重构历史代码，往往不会在项目刚启动时立刻显现价值。它们通常会在项目运行数月后逐渐暴露出来：构建变慢、缺陷变多、改一处牵一片、发布风险越来越高。

如果这些问题长期得不到处理，即使工程团队过去交付效率很高，生产力也会很快下降。

于是，团队会站在一个艰难的十字路口。

如果你只关注功能发布，以及那些最重要、最棘手的缺陷修复，工程师可能会逐渐觉得：他们认为重要的技术质量问题，在团队优先级中并不重要。他们甚至会认为，产品经理和业务团队并不真的在乎工程质量。

在这种摩擦之下，工程团队会慢慢放弃对质量的坚持。既然这些事情永远排不上优先级，为什么还要持续投入精力？直到某一天，技术债务累积到足够高，团队的交付效率开始明显下降。讽刺的是，团队原本以为只做“必要工作”可以加快速度，结果却因为质量基础被不断透支，反而陷入停滞。

这会形成一个自我强化的恶性循环：团队越忙于处理不断冒出的 bug 和紧急功能，就越没有时间关注质量；越不关注质量，后续的 bug、返工和维护成本就越多。

但另一方面，如果你把所有精力都投入到技术债务治理上，又会让团队感觉自己在推迟真正重要的事情：为用户和业务创造价值。

这也会让产品团队感到非常沮丧。他们知道用户需要什么，也知道哪些功能和问题最紧急，但却找不到足够的人力去推进。更糟糕的是，当客户期待已久的功能迟迟无法交付，或者长期困扰他们的问题迟迟没有修复时，客户流失就会开始发生。

双速工作模式：速度与质量的常见折中方案

面对这个问题，很多团队通常会寻求某种折中方案：把产品工作和工程工作周期性地穿插安排。

团队可能会维护两套不同的待办事项列表：一套面向产品和客户需求，另一套面向工程改进和技术债务治理。然后，工程经理或敏捷教练会和产品经理、产品负责人讨论，在某个迭代中可以安排多少技术任务，或者是否能在两个迭代之间留出几天“缓冲时间”，让工程师处理他们认为重要的技术事项。

我把这种方式称为“双速工作模式”。因为在这种模式下，团队看起来只有两种工作状态：要么专注于面向客户的产品工作，要么专注于内部工程改进。他们要么在开发新功能，要么在偿还技术债务。

这种方式当然有价值，但它也有明显局限。

1. 它人为制造了交付速度与工程质量的对立

如果团队默认存在两种工作模式：一种是“尽快把功能发布出去”，另一种是“这是工程师做质量改进的安全空间”，那么它很容易带来一些副作用。

产品开发阶段可能会变成：只关注把功能做出来，而暂时忽略质量，因为质量被认为是“之后再处理”的事情。

工程改进阶段则可能变成：因为没有明确的业务截止时间，任务边界变得模糊，探索空间不断扩大，最终耗时越来越长。

这听起来有些奇怪，不是吗？

团队正在慢慢建立一种文化：发布产品意味着先写代码、先上线，暂时不考虑它对现有技术债务的影响，也不认真评估其中可能带来的技术后果。与此同时，工程任务又被塑造成一种“不直接创造业务价值”的工作，而且还会占用不少时间。

长此以往，交付速度和工程质量就被人为地放到了对立面。

2. 它割裂了本应协同的产品与工程责任

双速工作模式还会在工程团队和产品团队之间制造隔阂，并且这种隔阂会随着时间逐渐扩大。

工程团队虽然获得了一些额外时间来处理“自己的事情”，但产品团队和业务相关方往往并不清楚他们在做什么，也不知道这些事情最终会对业务产生什么影响。大家只是希望这些投入最终能够带来好的结果。

工程师也可能因此认为，对于重构、依赖升级、安全漏洞修复等技术驱动型任务，他们不必解释业务价值。因为这些任务本来就属于“工程时间”，只要安排进去就可以了。

但事实上，我们应该鼓励工程师更清楚地思考并表达每一项技术工作的业务影响，而不是削弱这种意识。

3. 它总会让一部分人感到挫败

双速工作模式还会持续制造情绪摩擦。

在产品工作周期中，工程师可能因为无法处理他们认为重要的重构、安全升级或技术债务而感到沮丧。

在工程改进周期中，产品经理又可能因为工程师暂时没有交付新功能而感到沮丧。

无论处在哪个阶段，团队里总会有人觉得自己真正关心的事情没有得到足够重视。这会影响整体士气，也会让团队想要实现的目标和当下实际投入的工作之间出现偏差。

软件工程中有没有更好的工作方式？

双速工作模式并不理想。

它会让产品相关方觉得，项目之所以总是被搁置，是因为工程团队无法快速响应变化。而工程师则会觉得，为了尽快交付产品，他们不得不接受一种固定的开发方式，而技术债务只是这种方式不可避免的副产品。

这时，团队很容易产生一种错觉：如果想在合理时间内交付更高质量、更灵活的代码，唯一的办法就是投入更多时间。但这种做法又会牺牲交付速度，带来新的问题。

那么，有没有一种工作方式，可以让工程团队在质量、速度以及代码库对新需求的适应能力之间取得更好的平衡？产品工程师是否可以在专注产品目标的同时，也自然地推动工程质量提升？

我相信答案是肯定的。关键在于重新定义需求、质量和优先级之间的关系，并把它们整合进同一种工作方式中。

单速工作模式：把质量内嵌到交付过程中

如果团队不再维护两套彼此分离的待办事项列表，也不再把速度和质量视为两种相互竞争的力量，而是尝试把它们统一起来，会怎么样？

这就是我所说的“单速工作模式”。

交付速度和工程质量并不是天然矛盾的。真正需要改变的，是团队的思维方式：从“速度和质量必须二选一”，转向“我们怎样才能同时做到更快和更好”。

这一步听起来可能有些理想化，也有些抽象，但它是后续所有改变的基础。

从个人贡献者完成某项任务后的复盘，到整个团队在项目结束后的回顾，都可以不断追问一个问题：下一次，我们怎样才能更快、更少返工地交付类似成果？

这个问题会激发反思和创造力。团队可能会发现流程上的改进空间，例如：“我们进展缓慢，是因为仍然依赖大量手工测试。”或者：“我们以为已经准备好发布，但上线后才发现很多问题只会在生产环境出现。”

团队也可能发现能力上的改进空间，例如：“我们之所以一直手工测试，是因为还不知道从哪里开始构建自动化测试。”

持续追问“我们怎样才能更快、更好地完成这项工作”，会引导团队找到真正的痛点，而不是把低效、返工和质量问题视为理所当然。

在实践中，团队也需要借助合适的研发管理工具把这些改进沉淀到流程里。例如，PingCode 可以将目标、需求、任务、开发、测试、发布和 Wiki 知识沉淀串联起来，让质量问题、技术债务和交付进度不再分散在不同工具和沟通场景中，而是进入统一的研发流程和数据视图中。

重构和技术债务治理不应该总是事后补救

在我的职业生涯中，我也曾多次陷入一个误区：先把功能做完，然后再做一些“收尾工作”。

问题在于，当截止日期临近时，团队通常已经没有时间做这些额外的收尾工作了。于是，重构被推迟，测试被推迟，质量改进也被推迟。久而久之，它们就变成了更大的技术债务。

如果我们换一种思路呢？

如果我们把这些工作也视为产品优先级的一部分，就需要在一开始规划范围时把它们纳入考虑。

也就是说，与其单独在待办事项中创建一个“处理技术债务”的任务，不如思考这些技术债务正在如何影响其他产品任务。

例如，由于缺乏自动化测试，团队在修改某些模块时会非常谨慎，导致交付变慢。又或者，由于某些核心文件中的实现过于混乱，每次开发相关功能都会产生大量额外沟通、返工和风险。

在这种情况下，团队就可以在推进相关功能、缺陷修复或需求变更时，顺势完成必要的重构和质量改进。也就是说，不是先完成产品工作，再回头治理技术债务，而是在真正触碰相关代码区域时，把改进工作嵌入其中。

有位海外软件工程专家曾提出过一个很有启发的说法：“先让变更变得容易，然后再做容易的变更。”

这种流程上的反转，会迫使团队把工作拆分成更小、更清晰的单元。短期看，它可能让某些任务的边界变得更严谨；但长期看，这些小范围改进会持续累积，最终显著改善代码库的健康状况。

在大多数情况下，频繁发生变更的区域，往往也是最需要保持良好状态的区域。相反，那些你原本想专门创建重构工单的代码区域，如果长期没有产品需求触达，也许并不需要立即调整。毕竟，如果某个模块暂时不需要维护或演进，为什么要优先投入资源去重构它？

技术任务也应该被视为产品优先级

安全升级、弃用库替换、版本升级、数据库迁移等工作，通常会被归类为“技术任务”。

但我们常常忽略一点：这些工作之所以重要，是因为它们最终会影响客户、业务和产品本身。安全漏洞可能带来合规风险，弃用版本可能影响未来维护，数据库迁移可能决定系统是否能支撑新的业务规模。

因此，这些任务不应该被视为与产品无关的内部事项，而应该像功能开发和缺陷修复一样，进入团队的统一优先级讨论。

这也意味着，工程师需要更好地表达这些技术任务的业务影响，而不是简单地说“这是我们必须做的事情”。

例如，与其说“我们需要升级这个依赖”，不如说：“当前版本已经停止维护，如果继续使用，后续安全漏洞将无法获得官方修复，可能增加合规和客户信任风险。”

与其说“我们需要重构这个模块”，不如说：“这个模块目前每次变更都需要额外测试和人工确认，已经影响了相关需求的交付速度。重构后，后续同类需求的开发和发布风险会明显降低。”

当技术任务能够被清楚地翻译成业务语言，它们就不再只是工程师的内部诉求，而会成为团队共同理解、共同排序的产品优先级。

结语：速度和质量不是二选一

速度和质量并不是对立关系。

一款无法适应变化的软件，和一款变化速度超过团队维护能力的软件一样危险。真正理想的状态，是团队能够在交付速度、工程质量和长期可演进性之间找到平衡，让软件始终具备持续交付价值的能力。

要做到这一点，团队需要识别“双速工作模式”带来的挑战，也需要看清背后那些让我们陷入二选一困境的流程、信念和协作方式。

更好的方式，是逐渐走向“单速工作模式”：把质量内嵌到交付过程中，把技术任务纳入产品优先级，把工程改进和业务价值重新连接起来。

因为确实存在另一种方法：一种不再让软件工程中的速度和质量彼此冲突，而是让它们相互支撑的工作方式。