背景：我做了 3 年技术 PM，几乎每个季度规划都会卡在同一个问题——技术债要不要单独立专项迭代去还？这事在我们团队吵过至少 4 轮，每次结论都不完全一样，今天拿出来对线。
常见的三种做法：
- 专项派：每个季度固定留 20%–30% 的容量专门还债（比如一个 8 人团队，每季留 1.6–2.4 人月）。优点是债有确定性、能盯指标；缺点是业务方会问"这 20% 产出了什么功能"，PM 背 KPI 时很被动。
- 顺手派：不单独排期，谁路过谁顺手修。优点是零额外成本、上下文熟悉；缺点是没人真的去修，债只增不减，半年后变成"不敢动"的禁区。
- 永不派：能跑就行，除非出事。优点是短期交付最快；缺点是事故概率随债线性甚至指数上升——我见过一个老服务，单测覆盖率 11%，每次改一个字段要回归 3 天。
我的倾向与理由：我选"专项 + 顺手"混合，但有一条硬规则——专项只还"会出事"的债，不还"只是不爽"的债。具体怎么算：
- 先给债打分：用"事故概率 × 影响面"估期望损失。比如一个没有幂等的支付回调，事故概率我估 5%/年、单次影响约 8 小时停机 + 人工补偿，期望损失很高 → 进专项；
- 一个纯代码风格、没人碰的模块 → 不进专项，谁路过顺手改；
- 专项容量我压到 15%（不是 20%），剩下的靠"顺手"和"重构搭车"（做相邻需求时顺带清 10%–20%）。
- 关键动作：每个专项债还清后，必须补一个能"锁住它"的自动化测试或监控告警，否则还会再烂回去。这一步我们漏过两次，债直接复发。
补一组跑了 3 个季度才敢贴的复发数据（这是上版没写、但最值钱的部分）： 我们把"还清的债"按还清方式分成两组，回看 6 个月内是否复发：
- 专项还清：62 条，复发 5 条，复发率 ≈ 8%；
- 顺手还清：26 条，复发 9 条，复发率 ≈ 34%。
差异来自一个很朴素的点：专项还清时我们强制补了"锁"（回归测试 or 告警），顺手还清时 7 成没补。所以那条"必须补锁"的硬规则，3 个季度里至少帮我们省了 4 次回炉。反过来讲：如果你团队"顺手还清"的债也补了锁，顺手派完全够用，专项就不是必需的——真正的自变量不是"专项 vs 顺手"，而是"有没有锁"。这是我上版没讲清、这次修正的结论。
再补一个漏掉的坑（专项容量会被"征用"）： 专项 15% 听着挺高，但大促前 2 周几乎必然被临时挪去堆需求，实际还债率只有 9%。我们改成两条才稳住：
- 大促/版本冻结窗口前 2 周，专项容量直接冻结（提前 4 周排进 roadmap，而不是事后挪用）；
- 专项债设"过期日"：进专项的债如果 2 个迭代内没还清，自动降级回 backlog 并记录"为什么没还"，防止专项变成"永远在还但永远还不完"的口袋。
一句话总结：别争论"该不该留迭代"，先问"这条债有没有锁、锁得住吗、补锁的成本是不是低于利息"。有锁就专项，没锁先补锁，补不起锁的债就老实承认它是"只能顺手慢慢磨"的债。
想听大家：你们团队还债是专项、顺手还是永不？还清的债有没有补"锁"？在什么场景下你会专门留迭代去还、什么场景下直接放弃？小团队（3–5 人）和大团队（20+）的做法是不是完全不同？欢迎拿你踩过的真实例子来对线。
0赞
0收藏
0楼层