软技能系列第 3 章。如果说技术汇报是「向上讲」，这一章是「横向推」——你认定一项技术改造（重构、上监控、治理技术债）是对的，但业务不陪你、产品不配合、别的团队不动，怎么办？
先接受一个现实：没有人「应该」配合你
技术改造的失败，八成不是技术方案不行，是推进方式错了。常见心态是「这是技术正确的事，他们凭什么不支持」——这句话一出口，协作基本就输了。
事实是：业务团队有业务团队的 KPI，产品有产品的排期，别的技术团队有自己的烂摊子。你的技术改造是「你的目标」，不是「他们的目标」。 跨团队协作的本质，是把你的目标翻译成他们的目标。
四个步骤：把「我的事」变成「我们的事」
第一步：找到对方的「痛点语言」
别用技术语言开场。想清楚你的改造帮对方解决了什么：
- 重构支付模块 → 对业务说「缩短新需求上线时间」，不是「去掉面条代码」。
- 上监控告警 → 对产品说「上线后出问题能提前发现，少背几次锅」，不是「建设可观测体系」。
- 治理慢查询 → 对业务说「页面快一倍，转化有空间」，不是「优化 SQL」。
心法：对技术团队讲「技术债的利息」，对业务讲「利息最后谁付」——把技术改造翻译成对方能感知的价值，而不是你自己的信仰。
第二步：找一个「利益同盟」
单打独斗推不动任何跨团队的事。找到这几类人：
- 被同一个问题困扰的兄弟团队（你治慢查询，他们也慢——一起推才有分量）；
- 业务里最痛的那个负责人（他的一句话顶你十次会议）；
- 你的 leader（让他知道这件事的价值，拿到组织层面的支持）。
第三步：把改造变成「对方的里程碑」
不要以「我这边改造上线」为终点，要设计成对方的可感知节点：什么时候他们的指标会变好、出问题他们能得到什么承诺（回滚保障、值班支持）。给对方「参与的理由」和「安全网」，他们才愿意陪你走。
第四步：透明与止损
- 定期同步进展和风险，别让协作方在「黑盒」里等你。
- 效果要用数据兑现承诺：上线前后对比，把功劳算到协作方头上——下次你还有事要推，这就是信用存款。
- 发现方向不对（对方业务变了、价值不成立），及时止损并说清楚，比硬撑到失败体面得多。
常见的推进陷阱
- 把「开会对齐」当「推进」：会议只是同步，真正的推进发生在会前的一对一沟通里。
- 用「技术正确」压人：赢了争论输了协作，技术改造短期靠方案，长期靠关系。
- 只对上不对平：leader 拍板了，但执行层不认，改造照样推不动——横向团队里，执行层的认同比领导的批示更重要。
落地清单
- 用对方的语言重写一遍改造的价值（写下 3 句）
- 找到至少 1 个利益同盟
- 设计「对方可感知」的里程碑与承诺
- 每两周同步一次进展与风险
- 效果数据兑现承诺，功劳归协作方
相关：技术人如何做技术汇报 ｜ 冲突与需求博弈见技术沟通