技术债的谈判技巧：和研发站在同一边

微信扫一扫，分享给好友

关闭

「这个需求要两周」「为什么这么久？」「因为之前的代码太乱了」——这段对话在每个团队反复上演。技术债的本质是：过去的快，变成了现在的慢。而多数PM对技术债的态度是矛盾的：知道它重要，但排期时永远排不进去。

先理解技术债的类型

类型一：有意的债。为了赶窗口期，明知设计不完美但刻意为之，比如临时活动页。这类债有明确的「还款计划」，相对可控。

类型二：无意的债。写代码时的好方案，随着业务演进变成了坏方案。这是最常见的一类，无法归罪于任何人。

类型三：复杂的债。核心模块经过多人多轮修改后的熵增状态，重构风险高、收益不直观。

把技术债翻译成产品语言

研发说「这个模块太乱了需要重构」，PM听到的是抽象的技术诉求。谈判技巧的第一步是要求翻译：这个债会导致什么产品后果？

通常答案会落在三类：迭代变慢（新功能开发时间从3天变成2周）、稳定性风险（月均3次线上故障）、性能体验差（页面加载4秒，流失率升高）。一旦翻译成产品语言，技术债就能进入正常的需求竞争。

量化方法：用「债务利息」排期

每个技术债项估算两个数：

月度利息：它每月造成的额外开发成本（比如让所有相关需求多花20%工时）。

还款成本：一次性还清需要的工时。

如果一项债的月度利息是2人日，还款成本是10人日，那么还款的回本周期是5个月。把所有债项按回本周期排序，优先还回本最快的。这套方法让还债决策变得和功能决策一样可讨论。

建立「结构性配额」

比个案谈判更有效的是机制：约定每个迭代固定20%的工时用于技术优化。好处有三：研发有稳定的还债节奏；PM不需要每次为还债单独立项；需求排期时自动考虑了这20%，预期更健康。

红线机制

有些债不能只靠配额慢慢还。当出现以下信号时，应触发专项重构：某个模块的需求开发时间连续两个季度上升；同一模块每月出现重复类型的事故；新人接手某模块的熟悉时间超过两周。

写在最后

技术债不是研发的私事，它是产品迭代速度的隐形税单。PM的角色不是在「快」和「好」之间站队，而是帮团队把这笔账算清楚、排进日程。当研发发现PM主动为还债争取空间时，信任关系的改善会超乎想象。