去年冬天的一次季度排期会，我把「支付对账模块重构」写在 P1，理由只有一句：这块代码没人敢动。产品负责人问，不做会怎样。我说会更烂。他点点头，把那一行划掉了。
那次之后我改了做法。我不再讨论代码好坏，只讨论两列东西：多花的人天，和会延期的需求。技术债能不能排上，本质上是一次翻译工作——把工程师眼里的「烂」翻译成业务眼里的「贵」。
先把「技术债」这个词拆开
混在一起投票，结果一定是可预测的：最虚的那类先被砍，最急的那类靠救火插队，中间那类永远排不上。我现在会把债分成三种，它们的沟通对象完全不同。
第一种是正在流血的。 上个月对账出了两次差异，财务人工核了三天。这类不需要论证优先级，它是事故，走故障流程而不是排期流程。如果一件事已经在产生可计量的损失，还拿来和需求抢名额，那是团队的问题，不是债的问题。
第二种是收利息的。 每加一个支付渠道，都要在四个地方改 if-else，还要补两处测试。它不致命，但每次改动都要多付钱。这类债的对手盘是产品经理，因为利息最终体现在他们的交付周期上。
第三种是期权型的。 框架版本停在两年前，现在没影响，明年某天可能一次性爆炸。这类只有技术负责人自己在意，通常应该放在「记账但不排期」的池子里，等到有具体触发条件再捞出来。硬把它塞进季度排期，会消耗掉你为前两类争取来的信任额度。
利息怎么算：一个粗糙但能用的公式
我用的算式很简单：
半年利息 = 单次改动的额外成本 × 未来半年预计触发次数
具体点。新增一个支付渠道，正常估 3 人天，实际要 5 人天。多出来的 2 天里，大概 1.5 天花在改散落的 if-else 和补测试上。下个半年的 roadmap 上有 4 个渠道要接。半年利息就是 6 人天。而把那块逻辑抽出来重写，需要 12 人天。
这个账不一定划算——12 换 6，回本周期一年。但它把讨论从「代码烂不烂」变成了「什么时候回本」。有了回本周期，产品负责人就能做判断：如果这半年只接 1 个渠道，那别做，记着就行；如果接 6 个，那就该做。
我想强调两点。一是估算一定要写下来，哪怕很粗。写在文档里的 6 人天会被质疑、被修正，留在嘴上的「这块很费劲」只会被忽略。二是我会标一个置信度：触发次数来自已排期的 roadmap，置信度高；单次额外成本来自我自己的体感，通常标低。低置信度的数字不该用来做决策，但可以用来争取一次更细的评估。
收益侧，别算「避免了多少损失」
「避免了多少潜在故障」这种数字没人信，包括我自己。故障本来就没发生，你无法证明是重构挡住的。
我换成一个反向问题：如果这笔债不还，下季度已经承诺出去的三件事里，哪件会延期？
这个问题的好处是逼你把债挂到具体的 roadmap 项上。挂不上的，说明它暂时没有业务归属，那就进 backlog，不占排期名额；挂得上的，它就不再是「技术团队的诉求」，而是「那件事的前置条件」。
举个真实发生过的：产品想在 3 周内上一个多维报表，但数据层每次加维度都要改存储过程，实际得 5 周。这时候两个选项是并列的——延期两周，或者先花 4 天把维度表抽出来。后者是技术债，但它此刻有了明确收益：把 5 周变回 3 周。这种提案几乎不会被拒，因为它没有让对方做选择题，而是给了一个更便宜的答案。
一张表，每季度重算一次
我维护一张很土的表格，列是：债的描述、类型、单次额外成本、未来半年触发次数、半年利息、修复成本、回本周期、挂靠的 roadmap 项、置信度。
规则只有一条：挂靠 roadmap 项那一列填不出来的，不进排期会。 这条规则帮我省掉了大量争论，也逼我在提之前先想清楚它到底服务谁。
每季度重算一次触发次数，因为 roadmap 会变，利息跟着变。有一次我算完发现某笔债的回本周期是 14 个月，就自己把它撤了——留着表格里，等触发次数涨上来再说。
沟通上有几个细节我踩过坑：
- 不要用「重构」这个词，它听起来像没有边界。改成「把 X 从 A 挪到 B」，范围小到能估、能验收。
- 一次只推一条。三条一起上，会被当成技术团队在要预算。
- 主动给出「不做的版本」，也就是这笔债不还，需求怎么排、会延期多久。对方有退路，才愿意听你的方案。
- 允许自己被说服。我现在的判断标准是回本周期在 6 个月内才主动推，超过的只登记。这个阈值是我拍的，还没有足够数据支撑，可能需要按团队规模调整。
下一次排期会我只带三行，每行都有回本周期和一个挂靠的需求名。如果三行都被划掉，那说明我的账算错了，或者这个季度的业务确实不该还债——两种结果我都接受，至少比「代码很烂」这四个字有用。
评论