【背景】
我做了 5 年 TPM，最典型的日常场景大概是这样的：
工程同学拉我进会，说：「这个订单服务的技术债再不还，下个大促大概率炸。我们需要 3 周做一次超时链路 + 连接池的重构。」
产品同学同一周跟我说：「竞品下周上了一个新功能，用户已经在论坛催了，我们能不能也排上？」
两边都是对的。但我不可能同时满足两边。
这不是某个团队的问题，是几乎所有「既做业务又做技术」的团队每周都在经历的拉扯。
【常见的几种「解法」】
我观察下来，团队处理这类冲突大概分三种流派：
-
排期优先流：先上 feature，技术债记入 backlog，"下个大版本再还"。好处是业务节奏不断；坏处是"下个大版本"经常变成"下一个季度"甚至"永远"。我见过一个团队的 backlog 里躺着 14 条 P1 技术债，标了 8 个月没人动。
-
技术优先流：暂停 feature 排期，先还债。好处是风险不累积；坏处是业务侧觉得"你们技术团队永远在搞自己的东西，不产出用户能感知的价值"，下季度 budget 审批时很难看。
-
折中并行流：feature 正常排，同时抽调 1-2 人做重构。听起来最"合理"，但实际执行中经常变成两边都做得半吊子——feature 延期一周、重构做到一半被线上 incident 打断，最后两边都没交付完整。
【我的倾向】
我比较倾向第三种（折中并行），但有一个前提条件：技术债必须被翻译成业务语言，带上"价格标签"再上桌。
什么意思呢？不是跟产品说"我们的 P99 会抖、线程池会打满"，而是说：
"如果不修，按去年大促数据推算，当天预计有 12%-15% 的下单请求会触发超时重试，用户端表现为'下单失败请重试'，保守估算损失 8-12 万 GMV，客服工单增加约 200 条。"
当技术债有了"价格标签"，它就不再是"技术团队的内部事务"，而是一个可以跟 feature 的"预期收入 / 用户增长"放在同一张桌子上比较的决策。产品同学也好、CTO 也好，面对的是"8 万 GMV 风险 vs 15 万预期新增收入"，这个选择题比"要不要重构"容易做得多。
但说实话——这个翻译过程本身就很费劲。不是所有技术债都能算出价格。有些"架构腐化"的风险是概率性的、长尾的：你很难跟业务说"有 3% 的概率在 6 个月后发生一次 P0 故障，届时影响面不确定"。这种"说不清价格"的债，往往只能靠信仰驱动，或者……等它真的炸了才有人拍桌子。
【想听大家】
所以我想问问各位——不管你是 PM、架构师、Tech Lead 还是开发：
- 你们团队里，"技术债 vs 排期"的裁判到底是谁？是 Tech Lead 拍？CTO 拍？还是 PM 自己拍？有没有一个明确的"升级路径"？
- 你们有没有遇到过"技术债修了 80%，剩下 20% 永远没人管"的情况？那 20% 后来怎么样了——是变成了事故，还是被"自然消解"了？
- 对于"算不出价格"的架构级技术债（比如某个核心模块的设计已经不适配业务方向了），你们怎么让它进入决策视野？靠 Tech Lead 的"信仰"，还是非得等一次线上事故？
- 你们有没有试过给技术债"定价"？效果怎么样？产品/业务同学买账吗？
我特别想听不同角色的视角。因为这个问题，PM 看到的、架构师看到的、一线开发看到的，可能完全是三张不同的脸。