研发说"重构要 3 周"，业务方说"下周就要"，PM 怎么把账算到双方都认？

【背景】 我做 B 端 SaaS 产品 8 年，最近一个季度在排期评审上反复撞同一个墙：业务方（销售 + 客户成功）压一个"必须下周上线"的功能，研发评估说"直接加会引入 3 个服务的改动，P99 会变差，建议先花 2-3 周做一次小重构，再叠加功能，总共 5-6 周"。两边都觉得自己有理，我夹在中间，每次只能拍"先上功能"或者"先重构"，拍完哪边都不服。

【现象 / 卡点】

• 业务方的诉求通常带具体客户名 + 合同金额（"客户 A 的 80 万单卡在功能 X 上"），情绪和数字都很硬。
• 研发的诉求通常带架构风险描述（"耦合度高，改完 P99 会抖，回滚成本高"），但很难折算成业务方听得懂的钱。
• 我试过把"重构成本"写成"未来 2 个季度每个需求多花 20% 工时"来对线，研发觉得算多了，业务方觉得跟我没关系。
• 也试过让研发出一个"不做重构的最坏情况"概率估计，但研发不愿给数字（"说不准"），最后只能我拍。

【已尝试的排查 / 做法】

1. 让研发给出"重构工作量 = 人天 × 单价"的显式成本，业务方不接受，理由是"这是内部账，不影响客户"。
2. 让研发给出"不重构的故障概率 × 单次故障损失"，研发拒绝量化，理由是数据不足。
3. 把重构拆成"能跟本需求合并的最小切片"，研发说"拆了反而更慢"（上下文切换 + 测试面扩大）。
4. 把决策上移到产品负责人 + 工程负责人 1v1，两边依然各说各话。

【期望得到的回答形态】

• 一种可复用的决策框架：在"业务硬截止 vs 技术重构窗口"冲突时，PM 该按哪些维度（SLA、回滚成本、客户合同条款、未来 2 个季度的需求队列）打分，让结论可追溯、可复盘，而不是靠拍。
• 一个量化模板：把"重构成本"和"不重构成本"折算到同一个货币单位（比如"未来 6 个月的预期总成本"）的具体公式或表格，最好带一个真实案例的数字。
• 一个沟通话术：怎么在评审会上把研发的技术语言翻译成业务方能接受的"客户影响 + 合同风险"，同时不牺牲研发的判断空间。
• 顺带想知道：大家团队里有没有"强制留 N% 容量给重构"的机制，N 取多少合适、怎么防止被业务方挤掉？

欢迎带具体案例（数字 / 时间线 / 最终谁赢了）来答，越具体越有用。