职场之锤
怎么把技术债讲到老板也点头说，赶紧做！！
虎头锤 · Staff Engineer本文另有英文译文 · 阅读英文版 →
某次周会，我跟老板说：“这个接口堆了太多逻辑了，要重构。”
老板皱了下眉：“有用户反馈问题了吗？”
我说：“还没，但迟早要出事。”
老板沉默两秒，说：“那先放一放吧。”
如果你也在项目里背着一堆技术债，一定对这个场景不陌生。
我们明明知道某个模块风险很大，写的人也早就离职了；知道上线前总有临时打 patch 的需求，每次都手忙脚乱；知道系统扩展越来越慢，重构已经箭在弦上……
但只要一句“这影响用户了吗？”、“有具体损失吗？”、或“现在不重构会怎么样？”
就把你的技术债焦虑压成了“下次再说”。
技术债不是不能讲，而是要换种方式讲。
这一篇，我们就来拆解——怎么把技术债讲到老板也点头说“赶紧做”。
- 技术债不是技术的事，而是组织的事 我们常把技术债想成一堆代码问题，但技术债的本质，其实是组织的决定。
项目抢时间，为了交付选了捷径。
人走茶凉，没人维护老代码。
上线前才发现数据结构扛不住业务变化。
甚至有时候是流程漏洞：review 只是走个形式，测试不给 staging 留时间...
这不是某一段代码写得烂，而是某段时间里，我们为业务增长或者交付速度，主动牺牲了系统的健康性。
Martin Fowler 就曾用一个象限图，定义了不同类型的技术债：
Reckless / Deliberate: 我们知道后果，但仍然选择这么做，例如“没时间设计，先拼起来再说”
Prudent / Deliberate: 我们知道会产生债务，也预估了风险，打算后面偿还
Inadvertent: 我们根本没意识到是技术债，等问题暴露了才恍然大悟
[[techDebtQuadrant.png]] 不同的技术债需要不同处理策略：鲁莽型需紧急偿还，谨慎型可规划处理。
了解技术债的成因，是沟通的第一步。但真正落地，还得看怎么讲、怎么选、怎么改。
- 怎么讲：别讲欠债，要讲避险 很多技术人讲技术债时会说：“这段逻辑太老，得重构”；
“这块用的框架早就没人维护了”；
“性能太差，每次高峰都在赌运气”。
老板听到这些的第一反应是：“能不能别吓我？”
第二反应是：“听不懂、看不出影响，那先别动。”
所以讲技术债，不能从技术角度讲，要从组织风险讲。要讲为什么要做，做了有什么好处。
举几个例子。
比如不说“这块逻辑太耦合了”，改成“上线改一个字段，要动七八个模块，回归测试要花两天，修改窗口越来越小。如果我们能够解耦，那么字段的改动就会限制在一个模块，用单元测试就能搞定绝大部分场景，回归测试半天都可以完成。”
还有把“这个库过时了” 换成“官方已经停止支持，再出一个安全漏洞我们没补丁可打，只能手动打补丁。这个新的库，社区很活跃，版本很新，使用量很大，不但可以消除安全隐患，避免compliance的问题，还有不少改进的功能”。
再来一个，别用“现在实现不优雅”来展现自己的技术洁癖，改成“每次上线要人工改配置，已经有两次差点改错，如果换成自动化流程能降低这个人力依赖，而且还可以整合到pipeline里面，部署的时候一键搞定”。
我们不是要夸大技术债的后果，而是把“工程上的痛”翻译成“组织的代价”。
要让老板看到：“这不是你写得不满意，而是公司在承担不必要的风险”，他自然会认真听怎么解决。
- 怎么选：不是都做，而是优先做高风险+高回报 技术债永远不可能全部还完。
所以要还的，不是最碍眼的那笔，而是最可能暴雷、且一改收益大的那笔。
可以用两个维度来评估技术债的优先级：
第一个是上面提到的技术债四象限（即 Martin Fowler 模型）
这有助于厘清责任和治理方式：是我们有意识的放弃，还是认知不到位？是可以规划偿还的，还是只能临时补锅？
第二是实用的Effort × Impact工具（x轴是Effort，Y轴是Impact) (感谢@Angeline提供的框架）
[[Effort-Impact 工具.png]] 判断标准可以参考这几条： 是否每月都有人踩坑？（现实中的重复代价） 是否每次上线都得改？（直接影响开发效率） 是否一改就能解除工程锁？（让系统变得更可扩展或测试更简单） 是否容易造成安全/数据问题？（组织负面影响不可控） 真正优先级高的技术债，往往是那种：
解决成本不高，但风险巨大，收益又明显。
真正能说服老板的技术债，不是看不下去的，而是再不改就出事的。
- 怎么改：别靠个人英雄主义，要靠机制 有的团队技术债压了三年都没人动，有的团队却能把重构变成常规流程。
差别在哪？
就在于有没有把还债变成组织机制，而不是靠某个人良心发现。
可以建立技术债登记表。 不需要高大上工具，一个共享文档就行，写清楚：问题描述；风险级别（高/中/低）；是否已有 workaround；推荐解决时间和潜在收益。
拉上老板做一次债务盘点会议。像产品部门定 roadmap 一样，技术团队也可以每月做一次工程健康盘点，每次只讲 1~2 个最可能出事的点。
用债务 Sprint机制。 把还债变成可预期、可被支持的开发周期，比如每个季度安排 1~2 周专项还债，或者每个Sprint做一到两个卡。只要有节奏地做，老板一般不会反对。
还可以把技术债纳入绩效指标。很多还债工作老板不支持，是因为看不见成果。如果能量化，比如“减少工单处理时间”、“降低功能出错率”、“提升上线效率”等，慢慢也能建立组织信任。
- 改的是系统，更是文化 技术债不会一夜清零，但一个团队如何对待它，能看出这个组织的工程成熟度。
是视而不见，等出事了再背锅？
还是持续盘点，把还债机制化？
是谁发现谁负责？
还是工程质量是整个团队的责任？
改变，从来不是喊口号，而是我们有没有从写代码走向建系统。
哪怕今天我们只能还掉一笔债，只要这笔债的价值是组织认可的，明天再多一笔就会更容易。
当老板也能说出：“这个风险是该还了”，
当产品也会主动问：“这次上线会不会加重技术债？”
我们才真正从修 bug变成了经营系统。
下次当你再说起技术债，不如换种方式讲：这不是我个人的不满，而是组织正面临的一种风险。 我们可以用更稳健的方法，把它控制住。不是喊痛，是建机制；不是全还，是有选择地还；不是等爆雷，而是提前治理。 你会发现，那堵技术和老板之间的墙，其实能拆。