技术债该不该写进产品路线图？我用 3 个项目的数据算了一笔账

背景：

做了 8 年技术产品，我越来越觉得一个矛盾：技术债是研发最关心的事，但在产品路线图上几乎永远排不上号。每次 QBR 上研发说"这个季度至少 20% 的容量要还债"，业务方一句"客户等着呢"就拍回去了。

我复盘了 3 个 0→1 项目的迭代记录，发现一个规律：技术债不是"做了就消失"的，而是"不做就复利"的。具体数据：

• 项目 A：第一年欠了 12 个"临时方案"（硬编码配置、单点依赖、无降级），第二年还债花了 6 个迭代（约 18 周），占全年产能的 27%。
• 项目 B：第一年就把"不可逆决策点"控制在 5 个以内，第二年还债只花了 2 个迭代（约 6 周），占 9%。
• 项目 C：最惨——第一年"赶 deadline"欠了 23 个临时方案，第二年还债花了 9 个迭代，占 39%，直接砍掉了 2 个客户定制需求。

常见分歧 / 几种做法：

1. 研发自治派：技术债是研发的事，产品不该管，也不该出现在路线图里。理由："路线图是给客户看的，技术债写了客户会问'这是什么功能'。"
2. 产品主导派：技术债本质是"产品能力的上限"，不还清债，新需求的速度和质量都会持续下降。应该写进路线图，用"交付速度"的语言包装。
3. 混合派：技术债不直接写，但用一个"基础能力升级"的里程碑包装，里面包含 3~5 个具体的还债项。

我的倾向与理由：

我倾向第 3 种，但加一条硬规则：

每个季度的路线图上，"基础能力"这个里程碑至少占 15% 的产能（按人天算），且每个还债项要写清楚"不还它，哪个客户场景会受影响、影响多大"。

为什么是 15%？我算过一笔账：

• 如果技术债占代码量 30%（我一般用 SonarQube 的"技术债比率"估算），按每 10% 技术债增加约 5% 的迭代摩擦（这个 5% 是我从 3 个项目复盘里拟合的），那 30% 技术债 ≈ 15% 的额外摩擦。
• 15% 的产能用来还债，刚好抵消摩擦，迭代速度才能稳定在"预期值"附近。
• 低于 15%，技术债会复利增长；高于 30%，业务方会失去耐心（项目 C 就是 39%，直接被砍需求了）。

具体做法（可复现）：

1. 每季度第一个 sprint，研发用 SonarQube 跑一次技术债扫描，按"影响客户场景"排序取 top 5；
2. PM 把 top 5 翻译成"客户语言"（不是"重构订单服务"，而是"客户批量导出超过 5000 条会超时，修完后 5000 条 3 秒内出结果"）；
3. 写进路线图，标注"基础能力"标签；
4. 每个还债项配一个"可观测指标"（如 P99 延迟、错误率、部署频率），下个季度对比。

想听大家在什么场景下怎么选：

• 你们团队的技术债占迭代容量多少？有没有"一个季度完全不还债"的经历？后果是什么？
• 你们怎么把技术债翻译成业务方能听懂的"产品语言"？有没有好用的模板或话术？
• 有没有"技术债还了反而变差"的案例？（我见过一次重构后 P99 反而涨了 12%，因为丢了旧代码里的一个隐式本地缓存）
• 你觉得 15% 这个"最低线"合理吗？你们团队实际跑下来是多少？

欢迎带具体数字和场景来聊，越具体越好。