一个项目里有三家服务商：我们做服务侧，一家做订单，一家做数据。上线前一周，订单侧改了字段，我们这边解析失败，数据侧跟着报错。三方开会开了两次，谁都不认为自己该先动。
3 个协作卡点
1 份接口契约
2 条协作规则
1. 多方协作的真实卡点
不是接口不会写，而是改动带来的风险没人愿意先承担。先改的一方要承担联调失败、返工、工期延误的责任，后改的一方可以等。理性选择就是都等，项目就停在那里。
2. 要有一份带版本的接口契约
字段、类型、必填与否、错误码、变更流程，都写在文档里并标注版本。有了契约，讨论就从你改还是我改变成按契约该谁改。缺了它，每次协调都靠人情和职级。
3. 变更要走通知，不走群消息
接口变更提前书面通知，给出兼容期，旧版本保留一段时间。群消息里说一句我们改了个字段，等于没通知。这条规则看着繁琐，实际能省掉大量深夜排查。
4. 甲方要当协调人，不能只当验收人
三方各有各的合同边界，只有甲方能压住整体节奏。可行的做法是让甲方主持双周接口会，把待决事项列成表，逐条定责任人和时间。没有人居中协调，三方协作基本靠运气。
5. 把联调环境单独拉出来
多方项目里，容易出事的是拿生产环境做联调。单独准备一套联调环境，各方按同一份测试数据跑通再上线，能挡掉大部分低级故障。这笔投入比事后救火便宜得多，也免了各方在故障归因上互相推的时间。
结语
多方项目里，技术问题往往一天能解，协调问题能拖一个月。先把契约和变更规则立起来，再谈进度。