用业务语言讲技术债
向非技术干系人沟通技术债时，技术术语会直接阻断理解。有效的翻译方向是把债务换算成对方已经在意的量：交付速度、故障概率、合规风险、维护成本曲线。同时要给出选项与代价——维持现状、分期偿还、集中专项，让对方在知情的情况下做选择，而不是技术团队单方面宣示要清债。
沟通三要素
| 翻译 | 利息换算为每次需求的额外天数，或故障发生概率 |
|---|---|
| 选项 | 维持现状、分期偿还、集中专项，各自列明代价与收益 |
| 交付 | 偿还后的可验证收益，例如改动耗时下降的观测方式 |
典型使用场景
- 季度规划会：用一个高频模块的额外工时数据说明利息，争取偿还配额
- 事故复盘后：把根因改进项换算成风险敞口，争取专项投入
- 面对业务负责人：用交付延期天数与故障影响面表达，避免谈代码结构
- 跨部门协调：说明连锁影响，解释为什么某模块的改动需要更多评审
- 资源受限时的取舍：给出三档方案，让对方按风险偏好选择
沟通模板
沟通模板
现状：结账模块每次改动平均比同类模块多 3 天（近 6 次改动样本）
选项 A 维持现状 预计下半年额外消耗约 18 人日，故障概率不变
选项 B 分期偿还 每迭代投入 2 人日，约 3 个迭代后改动耗时回落
选项 C 集中专项 投入 10 人日一次到位，期间功能交付让位
建议：B。风险分散，收益持续，且不阻断当前交付节奏术语翻译对照
| 技术说法 | 业务说法 |
|---|---|
| 模块耦合严重 | 改一处功能要连带验证好几处，每次交付时间更长 |
| 缺少自动化测试 | 每次上线依赖人工回归，出问题的概率与人力成本都更高 |
| 技术债利息高 | 同样的需求，在这个模块上要多花固定比例的工时 |
| 需要重构 | 在不改变功能的前提下整理内部结构，目的是后续改动更快更稳 |
| 架构腐化 | 新增能力需要绕开现有结构，越往后成本越高 |
数据比形容词有说服力：改动耗时对比、缺陷集中区、门禁红项数量都是可核对的依据。若暂时没有数据，先安排两周采集，再谈预算，讨论会更容易收敛。
只报问题不给选项，等于把决策责任推回给技术团队。给出两到三个选项并说明各自代价，让对方明确选择，后续执行时也更容易获得配合。
落地检查清单
- 用对方熟悉的量表达影响，而不是用代码术语
- 数据来源可核对，样本量写清楚
- 提供选项，并说明每个选项的代价与收益
- 记录对方的选择与理由，作为后续复盘的依据