技术债不是债，是被推迟的产品决策——5个让研发与产品双赢的实操建议
微信扫一扫，分享给好友
关闭
开篇：为什么"技术债"的争论总是没有赢家
每个产品经理都经历过类似的会议：
研发说"这功能不能再加了，现在的代码已经是一团乱麻"；产品说"你们就是不愿意承担业务诉求"；研发继续说"现在不做重构，三个月后整个系统要崩"；产品回应"崩不崩我不懂，反正用户不会等三个月"。
会议结束，没人满意，技术债的优先级继续往后排。
技术债的争论之所以总是无解，是因为它被双方各自框定为"对方的问题"——研发认为是产品的"急功近利"，产品认为是研发的"教条主义"。但实际上，技术债不是研发问题，也不是产品问题。
技术债是被推迟的产品决策。
观点一：技术债的本质是"未来代价的预支"
当你为了今天快速上线一个功能，而选择了一个"现在能跑、未来会痛"的实现方案时，你不是在欠技术债，你是在为今天的速度，透支明天的灵活性。
这两个东西在本质上是同一种决策：
产品决策：是现在做一个不完美的功能满足用户？还是花时间打磨一个长期更稳定的方案？
技术决策：是用一个简单粗暴的写法快速上线？还是投入架构设计让代码更健壮？
它们都是"现在 vs 未来"的取舍。所以技术债应该被放进产品决策的框架里讨论，而不是被踢出去给"研发自己解决"。
观点二：把技术债翻译成"业务风险"
研发讨论技术债时，习惯说"我们要重构XX模块"。这个词对产品和高管来说毫无意义——它听起来像"研发想偷懒不做业务需求"。
高明的 PM 会把技术债翻译成业务语言：
错误说法："我们需要2周时间重构支付模块"。
正确说法："现在支付模块的代码结构，让我们每次新增支付方式都要花3人周。短期内我们只能支持微信和支付宝，未来一年如果要拓展海外支付、B2B分账、信用卡接入，每次都要排期且可能影响线上。如果现在投入2周优化，后续每个新支付方式的接入成本会降到5人天，整体节省约40人天/年，且不会有线上风险窗口。"
把技术债重新定义为"业务速度损失 + 线上风险"，它就成了产品决策，而不是研发诉求。
观点三：用"20%时间规则"让偿债变成制度
技术债永远会被业务挤压。一个常见的治理方式是"20%时间规则"：每个迭代预留20%的研发时间给技术债偿付。
但更聪明的做法不是简单的"时间配额"，而是"配额使用和决策权"。具体来说：
- 技术债项目和业务项目一起进入优先级排序
- 偿还技术债要明确产出：是降低未来成本？减少线上风险？提升性能？
- 如果某个迭代没有技术债可做，开发时间可以"溢出"到业务方做高 ROI 的小需求
这种做法的精髓是：技术债的优先级不靠研发去"争"，而是靠产品决策机制把它纳入统一排序。
观点四：识别"高利贷"和"低利贷"
不是所有技术债都一样。技术债的利率是不一样的——有些债再拖下去会"爆雷"，有些债其实可以慢慢还。
一个简单的分类：
高利贷（必须尽快还）：
- 影响线上可用性的债（如性能瓶颈、单点故障）
- 阻碍高频业务变更的债（如一个被多处调用的底层服务设计不合理）
- 有数据丢失风险的债（如数据校验不严格）
低利贷（可以慢慢还）：
- 不影响业务的内部代码整洁度问题
- 只影响开发体验而不影响产品能力的工具债
- 不再迭代的旧功能模块
重组（直接核销）：
- 完全不再使用的老代码
- 已经被新产品形态取代的旧模块
PM 应该和研发 leader 一起维护这份"债清单"，每个季度复盘一次"哪些债的利息在下降、哪些在上升"。
观点五：技术债的可视化沟通
技术债最难解决的问题不是"不知道要还多少"，而是"看不见代价"。研发知道代价，但产品、高管、其他协作方看不见。
可视化技术债的三种做法：
- **事故归因**：每次线上事故都做归因分析，把事故成本（用户数 * 时长 * 客单价）和技术债关联起来。一个重大事故往往能换来一个季度的技术债预算。
- **需求成本看板**：每个业务需求的技术实现时间，标注"其中多少是因为技术债导致的额外成本"。累积下来就是一个很直观的可视化数据——"我们过去半年因为技术债多花了多少时间"。
- **新员工上手时间**：一个新研发上手一个产品需要多长时间，是技术债最直观的体感指标。如果一个高级工程师上手时间从2周变成6周，说明技术债在快速恶化。
把技术债从"研发的事"变成"所有人都能看见的代价"，偿还的优先级就不再需要研发去争了。
实操：5个立即可用的建议
- **下次需求评审带上技术债列表**：把债清单和业务需求一起排序，让偿还决策自然发生。
- **每个迭代预留15-25%的技术时间**：但允许"溢出"到其他高ROI工作，避免制度被钻空子。
- **建立"技术债事故归因"机制**：把每次事故的根因和债清单做关联，让数据说话。
- **大型需求强制技术评估**：超过3人周的需求，必须附带"技术实现选项"——包括"快速实现"和"健壮实现"两种，让产品决策层看到真实代价。
- **每季度做一次技术债回顾**：PM + 研发 leader + 1名高管共同参与，识别"高利贷"优先偿还。
写在最后：技术债不是研发要解决的问题，是产品决策的输入
最危险的不是技术债，而是把技术债排除在产品决策之外的思维方式。
当研发说"这个设计不能做"时，他们不是在反对业务，是在说"这个做法会增加未来成本"。当产品说"用户不会等三个月"时，他们是在说"今天的业务收益比未来的灵活性更值钱"。这两种声音都没有错，错的是把它们当作对立的立场。
真正优秀的 PM，能把两种声音放进同一个决策框架，让"现在 vs 未来"的取舍变得可见、可讨论、可量化。
技术债不是债，是被推迟的产品决策。当我们重新这样定义它，研发和产品的关系就从"对抗"回到了"协作"。